Linux is the backbone of critical infrastructure, yet it often flies under the radar when it comes to endpoint monitoring. From legacy servers to embedded systems, Linux devices are frequently unprotected, either due to operational risk, overlooked assets, or the false assumption that Linux is “secure by default.”
In this episode, Craig Rowland, founder and CEO of Sandfly Security, introduces an agentless approach to EDR purpose-built for Linux systems. By operating over SSH and running rapid, randomized checks without traditional kernel hooks, Sandfly can monitor unprotected Linux endpoints, detect fileless and dormant attacks, and uncover SSH key-based lateral movement—all without tipping over sensitive systems. Joining Craig are Jerich Beason, CISO at WM, and Steve Zalewski, co-host of Defense in Depth, dive into where this solution fits in the broader Linux security conversation and why it might be the missing piece for OT and critical infrastructure teams.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, Sandfly Security
Full Transcript
[Voiceover] Connecting security solutions with security leaders. Security You Should Know starts now.
[Rich Stroffolino] Welcome to Security You Should Know. Today we’re talking about Sandfly Security and what they’re doing in EDR. Now the problem they’re trying to address is unmonitored Linux devices. You have to mind the penguins, they will get lost and run astray if you don’t. Helping us get answers to these questions are Jerich Beason, CISO over at WM, and Steve Zalewski, co-host of Defense in Depth.
Jerich , I’m going to start with you. Why are we still having problems with unmonitored Linux devices? What is the core of that problem?
[Jerich Beason] Well, despite our advancements, unmonitored Linux devices are still common because they often live in places we underestimate – OT environments, dev test systems, legacy servers, or even embedded systems we’re deploying traditional agents. Is it too risky, too resource-intensive, or simply overlooked?
And then there’s also the case where some people think that Linux is just built secure by design. It’s absolutely not the case, but attackers are taking advantage of that mindset.
[Rich Stroffolino] Steve, I’m going to turn this to you. Why are we still struggling with these unmonitored Linux devices?
[Steve Zalewski] I won’t say we’re struggling with them, right? Ninety-nine percent of the problem are all the Windows boxes. That’s what everybody worries about. And when that is 99% of your problem, it’s easy to just overlook Linux because it kind of takes care of itself, but legitimately, right, it’s another avenue for attacking, can be attacked.
And so, it’s one of those cases where you’re always worried about the problem child, but you have to pay some attention to the good kids too.
[Rich Stroffolino] All right, I love that metaphor and that is a great way to introduce Craig Rowland, the founder and CEO at Sandfly Security. To start out, we’re going to get answers to three essential questions. So, Craig, and these are some big ones, 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 look like? Can you give us some preliminaries?
[Craig Rowland] Sure, so my background, I started off originally working on the red team side, and I eventually moved into writing attack libraries for vulnerability scanners. So, I’m pretty familiar with the attack sequence that goes on in most enterprises, and it always bothered me seeing unmonitored Linux systems because it’s extremely common, especially today.
Windows devices have a lot of antivirus, anti-malware, EDR running on them, where Linux systems frequently have nothing. And I knew as a pentester that when we got on the Linux system, we would be home free.
So, Linux systems are dominant in terms of back-end infrastructure and critical infrastructure for many, many companies, although you might see Windows on the front end because that’s what users interact with. What’s running the database server? What’s running the critical infrastructure? What’s running your routing, networking gear, all this stuff?
That’s going to be Linux almost always. So, our proposition is essentially we’re going to watch these devices without deploying a traditional endpoint agent. And by eliminating the agent, we eliminate all the risks associated with downtime, stability, and performance frequently found with traditional approaches.
Pricing model is typical for what you find with any EDR product, essentially price per endpoint per year, which would be competitive with any other EDR solution you find in the market today.
[Rich Stroffolino] All right, well, we’ve gotten a taste for the solution. We’ve kind of got the origin story and the rationale for it, but I’m sure we have a lot of questions. Steve, I’m going to start out with you. What other questions do you have for Sandfly Security?
[Steve Zalewski] Yeah, so Craig, you position yourself as you’re designed to complement traditional agent-based EDR solutions. Can you expand on that? What does that mean?
[Craig Rowland] Well, we don’t care if you’re running an existing agent. We can run alongside those agents perfectly fine, and we can also run into places where there are no agents. So, to give you an example, a lot of our customers might be running Linux systems that might have 10 or 20% coverage with an agent, but 80 to 90% of those systems might have nothing going on.
So, they can deploy us to watch that 80, 90% of the systems that have nothing, but we can also work alongside the EDR agent because we do more than just EDR. We’re tracking SSH keys that detect lateral movement attacks. We’re doing something called drift detection to find novel, unique malware, people attacking them in unique ways.
We do password auditing. So, we provide a different view that a traditional agent might not even have. And so, when we say we can work alongside these agents, that means we can work alongside all the major players that are out there without interfering with them. And frequently, we augment it by supplying different information that they simply can’t provide to you today.
[Rich Stroffolino] All right, Jerich, what questions do you have for Sandfly Security?
[Jerich Beason] Yeah, I got a number of questions. I’ll start with today, the strength that I’m hearing from your solution is the lack of friction because of no agent, but what do you see from a detection depth perspective compared to other agent-based solutions that have kernel-based access, like a CrowdStrike or a SentinelOne or Azure Defender?
[Craig Rowland] Yeah, so we’ve gone up against these products at bake-offs. We’ve never had a problem detecting exactly what they do, plus much more. So, we feel pretty confident in our detection capability. Even just beyond pure detection capability as well, when customers see the fact that we could track the SSH key positions, which is a really big lateral movement threat, along with some of the other features, we actually do more than just Linux EDR.
So, the EDR side is traditionally, we don’t have a problem with it. We find rootkits. We have many technical articles in our blog discussing rootkit detection using our methods. And the best thing about it, by not tying into the kernel, not sweeping memory, we are extremely safe. We have a reputation that we do not tip systems over.
And that’s why we’re used by critical infrastructures such as telcos, other large manufacturing companies, things like that because they know we’re not going to be the reason why the system’s being woken up at 2:00 a.m. in the morning due to a downtime. We’re not the reason why that happens.
[Jerich Beason] So, naturally, a lot of the time that is due to false positives. And so, maybe you can help me understand how your detection rules are developed and maintained. Is it ML-driven? Is it behavior-based, signature, heuristics? I’m trying to get to how you get to the point where you do have a low false positive rate, but you’re still effective.
[Craig Rowland] Yeah. We’re best defined probably as a tactics hunter, an automated threat hunter. So, we call ourselves EDR because that’s what the industry expects, but we really are behavioral based. And the reason we do it is because Linux attackers work differently than Windows attackers. A lot of open-source malware can be easily changed on Linux side.
So, it’s something that traditional signatures have a very hard time keeping up for in Linux. The other problem with Linux is a lot of attackers work on living-off-the-land techniques. And so, what I say is Linux is not an operating system, Linux is a programming language. So, it has a lot of built-in commands that can become malicious if the attackers decide to make them so.
So, you can’t hunt for traditional malware the way a traditional AV-type EDR product does on Linux. You really have to hunt for the tactics of compromise, and that’s our specialty. So, we tend to focus on behaviors, things that we see that indicate that system’s likely compromised, and then that’s how we work.
[Steve Zalewski] All right. So, you use SSH, right, and Shell to get in. A traditional EDR agent-based, right, sits there and is running real-time, continuously monitoring what’s happened. It doesn’t sound like your solution does the same thing. So, how do you, right, account for the fact that I need real-time identification of an incident as opposed to a periodic analysis of what happened?
[Craig Rowland] Yeah. So, each system has pluses and minuses. So, the real-time agent is watching everything happen in real time, and as a result, it can see these individual actions. We do not. We show up on a random basis. So, why do we do this? We show up on a random basis because, first of all, it lowers our impact.
We’re only on the system for about 30 to 60 seconds, then we get off it. Second of all, it gives us evasion resistance. A lot of attackers today are trying to deliberately disable EDR agents. Our system, when it’s protected by Sandfly, it does not look like it has anything installed. We come over a regular SSH account, so we can actually take people by surprise.
The second thing, when you’re doing an EDR monitoring of system calls, you get a ton of false alarms and a ton of telemetry because they’re only showing part of the data. So, they’re saying, “Hey, someone opened this log file,” and they wrote something. Okay, that’s all well and good, but that happens on Linux all the time.
So, you know, how much data do you want? The way we look at it, we look after the fact. We can say someone opened this log file, they overwrote entry number 32 with a bunch of nulls to hide that they were present, and then they wrote it back to the disk, right? So, this is a much more affirmative way of saying that the system is actually compromised.
So, that’s also why we tend to have a much lower false positive rate because we actually have full confirmation of what actually happened in the attack.
[Steve Zalewski] So, how often do you actually touch the system? Once a minute? Once a day? Once a week? Like how near real-time for my Linux systems can I consider your product?
[Craig Rowland] It just depends on the customer. Look, you could go as short as every five minutes, but you could also extend it out to several hours. It just depends what you want to do. We have some customers that might have windows of time where they don’t want to have any security scanning happening because there’s time-sensitive operations happening during business hours, and then we have other customers that keep us running all the time.
But because we come in, we do small rapid checks many times throughout the day, most customers will never see our impact on the system. It’s much different than an agent that’s there all the time where they say, oh, it’s lightweight. Okay, that’s great if the system’s unloaded, but we’ve had customers say they see 10, 20, 30 percent CPU overhead just from the agent.
So, if you’re running a cloud deployment, what you’re telling the customer or the CISO is basically, I need to allocate 10, 20, 30 percent more CPU capacity in my cloud instances just to offset the impact of the agent, and we do not have that. So, it’s actually a direct cost savings not to have that happening on your systems.
[Jerich Beason] So, you guys have a novel approach, and the first thing I think of is why is this the first time someone has done this? And the first thing that I think is SSH is disabled on my most sensitive assets. So, if SSH is disabled, do you have a fallback approach to performing the functions that you guys perform?
[Craig Rowland] We do need SSH access. That’s the minimum requirement. Most of the time we find customers have SSH in some way or another to access them. If you have systems without SSH, unfortunately, we would not be able to work on those boxes. But a lot of times, even if there’s no SSH publicly, a lot of times there’s admin SSH access, but it just depends on the configuration environment.
But we can work in highly restricted SSH environments using key vaults, key management, key rotation, SSH key certs, anything that the customer has, we can integrate with those authentication mechanisms and work with those systems.
[Jerich Beason] I think that’s pretty reasonable. You guys specialize in Linux, and one of the things that everybody knows Linux for is its open architecture. How open is your architecture? Do you offer APIs, syslog integrations with SIEMs, XDR platforms, or is this more of a standalone platform by design?
[Craig Rowland] Yeah, so we do. We can work, first of all, in a totally air-gapped environment. So, we’re fairly unique in that environment that we do not need to talk to the cloud. So, if you’re working in critical infrastructure’s air gap, we work perfectly fine. We can send data out via syslog, we can send it to Splunk, we can send it to Microsoft Sentinel, we can replicate it out to Elasticsearch.
It’s a JSON format with a full REST API, so you can drive the entire product literally from cURL on the command line if your ops team wanted to. So, the product is completely configurable in that way. We can also send notifications out to Slack and the usual suspects there as well.
[Steve Zalewski] All right, you talk about the platform having 1,100 pre-built detection modules. Do you run all 1,100 or is it something I select? And what are the top 10 that you find to provide 80% of the value?
[Craig Rowland] Yeah, so it just depends what you want to do. You could do manual scans, you could run what you want. Like if you think a system’s compromised, you could say, “I want to run the kitchen sink on this thing right now because I think I have a fire.” The other way in our automated mode, we will pick a random percentage, we will pick a percentage of those to run at random multiple times throughout the day.
So, instead of doing two big scans once a day, like you get the antivirus that does the scan at 10:00 a.m. during your most important meeting of the day, right? It always annoys everyone. We don’t do that. We do very small rapid scans. So, over the day, this gives us an overlying detection net where basically we’re checking for many, many, many problems.
And each one of those checks actually looks for many problems in itself. So, even though we say, oh, it’s 1,100 or 1,300 modules, whatever, it’s actually many thousands of problems we find. So, it just depends on the customer, what they want to do. You can even tie it in with your SOAR that if you see specific network traffic that looks suspicious, you could kick us off, say, “Hey, I want to look at that box right now.
We saw some encrypted traffic go to that system,” and then you could do it that way. So, it really comes down to the customer and what their security workflow needs are.
[Steve Zalewski] Okay, and then I’m going to hold you accountable here, right? Which was of the 1100, which ones are the most important or you find the best value for a customer to use?
[Craig Rowland] It depends what the customer’s doing. Ones that look for process-level attacks are pretty high value because they’ll find a lot of fileless malware and other things that are happening in the process space, right? But we also have another side of our detection. That’s what we call live attack detection.
So, things that are happening right now in the system. And one unique thing about our product is we have what’s also called dormant attack detection. These are things that were done to a host, but they’re not active in memory. And this is something a traditional EDR agent might miss. So, for instance, I leave a binary behind as a payload to run later, but it’s not running.
It’s just sitting in an area of the disk that is suspicious. We would see that type of activity. And also, the other thing unique about us as well is we can run after the fact, meaning that we can scan a system and tell you if it was ever compromised in the past. Where a traditional EDR agent could only look from that point forward, we can actually scan systems and say, “We believe this system was actually compromised.” So, to your question, the process checks are great, but we also have some other ones as well.
It just, again, depends what the customer wants to do. But the process checks find a lot of mischief.
[Jerich Beason] So, I know we haven’t spoken too much about the cloud. How are you handling containers, especially short-lived workloads in Kubernetes or Fargate environments? And I think you said real-time, but I want to be clear. Do you have runtime visibility inside those types of pods as well?
[Craig Rowland] We’re not specifically a cloud workload protection platform. That’s not really our focus. With that said, when we run on the system, if we see Docker [Phonetic 00:14:02] containers on that host, we will mount and check those Docker images as if they were a local system. So, in this way, we do provide the host security, but we can’t scan those Docker images.
We’ll even mount the layers and scan the file system for the dormant attacks, which I just talked about. But the important thing is we want customers to monitor the host operating system because if there’s a container escape, it is totally game over. So, if you’re just looking at containers, that’s great, but the underlying host OS needs to be watched as well.
And this is why we have some cloud providers using our product because yes, the customer is seeing they use a container workload, but they also want to watch the host OS, and that’s something we’re really good at doing. But we can do the containers. But specifically, Kubernetes monitoring, we’re probably not the product for you.
[Jerich Beason] So, I never let a vendor leave a conversation without talking about the roadmap a little bit. I’m curious, with critical infrastructure being pretty much housed on Linux-based technologies, what is your vision for Sandfly in securing critical infrastructure in, let’s say, the next 24, 36 months?
[Craig Rowland] I’ll tell you what’s going to happen when we get at RSA. We’ll be announcing Sandfly 5.4, which is going to start providing coverage for Cisco and Juniper networking gear. So, the Juniper Vault OS and Cisco, I think, XR and Nexus series run Linux. We will be, I think, the first product to be able to monitor those devices to get on them.
We currently monitor other devices as well, like Ubiquiti gear, Synology systems, IP cameras. The IP camera support in a ransomware group recently broke into an IP camera, and they used the built-in Linux SMB commands to mount the Windows shares and encrypt everything. Because there’s no EDR running on an IP camera.
You’re not going to get an agent on a camera, right, just as an example. So, I think you’re going to see that. You’re going to see probably additional features around some response capabilities as well, that I don’t want to get too much into right now, but you’ll be seeing us go down that avenue, plus a few other surprises.
I know you’re asking for 36 months out. I need to be a little bit careful about what I disclose, but basically, you’re just going to see more of our continued coverage.
[Jerich Beason] Dude, you should have led with that. We install appliances left and right and cross our fingers if those appliances are okay. It sounds like you’re coming up with the solution to something that we’ve all given up on for the most part. So, I’m impressed.
[Rich Stroffolino] All right, Craig, what’s one thing we didn’t ask about that we need to know?
[Craig Rowland] Well, I know we talked a lot about EDR, and a lot of people are focused on that, but I think it’s really important to understand that EDR is really, I consider, one piece of the Linux security problem. The other problems that we track are the SSH keys. So, when we see an SSH key in a box, we’re going to audit and tell you where it is, who’s using it, how many systems it has access to.
You can ban that key and show every system where that key is on. We can use that to track it. We also do drift detection, meaning that we could profile a box such as a network router, and then we could tell you if there’s any change in that system. Not just file integrity, but we could say, has a new process started?
Has a new user been added? Has a new SSH key come onto the system? And finally, we do other things as well, such as password auditing. We could audit for weak and default passwords on devices natively right on the device itself, so we could tell you immediately if you have a weak password that’s going to get that device compromised.
So, we have a variety of other things. We really consider the EDR just one small piece of a whole package. Linux is a very broad topic, and so we want to watch it all without deploying endpoint agents.
[Rich Stroffolino] Well, that’s about it for this episode of Security You Should Know. To learn more, head on over to sandflysecurity.com. Thanks to Jerich Beason and Steve Zalewski for helping us learn more about what Sandfly Security is doing, and thanks to Craig Rowland from Sandfly for your time and being game to answering all of these questions.
And 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.