Introductions of the most grandiose kind
Ladies, gentlemen, and all others of varying degrees of morality that may disqualify you from the first 2 categories, welcome back to the little corner of the Internet that is my blog. I hope life is treating you well, or if it isn’t, I hope you are making the best available decisions and actions with the circumstances that surround you. I come before you today, with a proposal to make some security technology better.
“What type of security technology do you propose making better?”
EDR (endpoint detection and response) technology.
“Why should I read this if I’m not developing EDR?”
There are a couple reasons.
- If you use/manage/rely on EDR and think this would be an interesting idea, advocate with the company that makes your EDR to consider this as a feature.
- Leveraging technology to do more than what comes out of the box is fascinating to me. I consider these types of things puzzles to be solved, and the act of finding more value than what is obviously in plain sight is fun. If that is also fun for you, then use this as a catalyst to explore other types of use cases that could be addressed with the tools that are already in our tool belt.
Caveats and money-back guaruntees
To be clear up front, this may not be the greatest idea since sliced bread and maybe it is more valuable just as a thought experiment than implementing in reality. Also, I’m also gonna make some hand-wavy statements for the sake of technical brevity. Please feel free to call me out if I am egregiously wrong, but if your criticism boils down to, (pushes up glasses higher on the nose) “Well aktually it’s more complicated and complex than that!” Just know that I see you but I’m consciously glossing over stuff to prevent this from becoming book 3 of the Encyclopedia Brittainica.
Let us now pull back the curtain and watch as more words fill your screen from stage left.
The premise du jour and definitions
The basic premise is that I think the EDR marketplace could be filling a gap in security capabilities for many of their customers, most specifically in the area of NAC.
Before we go any further, let’s clarify some terms. For this post the main terms I’m going to be relying on are:
- EDR - Endpoint Detection and Response. This is the security agent that runs on endpoints to monitor for and prevent bad activity on the hosts. These agents also usually have an ability to control the firewall on the hosts. This is the thing running on your computer that can see everything that’s happening and actually block stuff that is deemed “bad”. Some of the big contenders in this space are CrowdStrike, Microsoft Defender for Endpoints (MDE), SentinalOne, and others.
- NAC - Network Access Control. One of the big functions of NAC tooling is to try to prevent unauthorized devices from connecting to your internal network. This can happen in various ways, but on a super high level it can boil down to: if someone walks into your office and plugs in their malware-ridden personal computer into an open Ethernet jack in the wall, ideally the network will say: “thou shall not pass”. The big risk this presents is having a malicious and unmanaged device ravaging your internal network from the inside. There are usually ways to circumvent some of these controls, but it requires a higher level of skills and sophistication of attackers, and that’s kinda the point.
- Managed/unmanaged - I’m going to use the terms “managed device” and “unmanaged device”. For the purposes of this blog, I’m going to use the hand-wavy definition of, “if it’s running your security agent, it’s managed. If it’s not running your security agent, it’s unmanaged/untrusted”. I fully recognize that’s not the right terminology for everyone, but that’s as sophisticated of a definition that you’re going to get from me in this article.
I don’t like to complain, but Houston, we have a problem…
For a plethora of reasons, NAC solutions aren’t always prioritized or implemented at companies, and in my informal analysis (read: talking to friends at many places), if you only have one of the 2 technologies above, it’s more likely that you have an EDR solution than NAC. This is where I think there is a fascinating business opportunity for EDR solutions to partially fill the role of a NAC even if a NAC isn’t present.
In order to explore this, there is a feature present in most EDR solutions that is necessary to explain, Neighbor Discovery (or something like that, maybe different EDR’s call it something different).
Some neighbors are creepy, but in tech we call this a “feature”
Neighbor Discovery
For the purposes of this explanation, I’m just going to make up the name of an EDR platform called “LoremIpsum”, but this concept can be abstracted to any EDR platform. One feature in many EDR solutions is that the agent on any computer can see what machines (laptops/desktops/etc) are on the local network next to them. Looking at things like ARP tables and other data points, machines can see what is directly around them on the network.
So let’s pretend there’s a network with 4 different machines, named A, B, C, and D, and they can all see each other. Let’s say the LoremIpsum agent is running on machine A. As part of A checking in to the LoremIpsum platform, it may say, “hey, I see machines B, C, and D”.
Let’s say the LoremIpsum agent is also running on machine B. B will report up to the platform “I see machines A, C, and D”. The same thing for machine C. For this scenario, we’ll say there is no EDR agent running on machine D.
So the LoremIpsum platform then can say, “Hey, I can see that there is A, B, C, and D on this network, and I know that I have security agents running on A, B, and C, so machine D looks like it’s an unmanaged/untrusted device.” So as a security analyst, you can look in the platform and see such things. This is a great way to get a snapshot of if there are machines in your network that need to get managed and get the EDR agent on them, or to be a catalyst to begin an investigation and answer “wtf is this thing on my network?!”.
Bringing it all together
Here’s how I think it all could be pulled together. The EDR platform is able to aggregate all of the above telemetry to paint a picture that, for each machine, which other machines around it are managed/are running the security agent.
Knowing that the EDR platform has the telemetry to indicate which hosts “are managed” as well as the EDR agent itself has the ability to also control the firewall for each host, the main question I have is:
“why can’t the platform use the telemetry of unmanaged hosts in a network to push down firewall rules to each of the managed hosts to block risky traffic originating from unmanaged hosts towards them?”
Let’s revisit our example from above. Let’s pretend that machine D is a mean pentester that social engineered their way into your office. They’re gonna try to connect to machines A, B, and C to see what information it can get from them. Why couldn’t the EDR functionality on them say, “Hey, based on the LoremIpsum platform we see that D isn’t part of our managed fleet, but it’s trying to connect to me on a port used by psexec. By the very nature of knowing it’s not part of our managed systems, we’re gonna block that network connection.”
It doesn’t have to block absolutely all traffic from unmanaged hosts on your network, but I can’t think of a single reason why an unmanaged machine should be connecting to sensitive/administrative protocols on managed internal infrastructure on ports like 135, 445, 3389, or 5986. How awesome would it be to say, “my EDR not only can monitor for badness on my hosts, but it will actually block sensitive network connection attempts from unknown machines on my network.”
Imagine being a red teamer who social engineers your way into a target office, nestle into an office, plug into an open Ethernet port, and get alerted on/chased down the moment you try to scan and connect to anything around you…all without a NAC solution that could be bypassed. As much as I love my offensive brethren, that’s the kind of security level-up that I think would be awesome to see in the world.
Outtro
One outtro point is, I realize it may not be “easy” to implement this, but I feel like the technology and telemetry is all there to make it happen, and it’s a matter of dedicating the engineering resources to make it happen on the EDR side. Maybe it could be difficult to manage just with firewall rules depending on the size of an internal network, but there’s no reason this activity couldn’t be easily identified in near-realtime post processing for alerting and killing of associated processes. I believe there could be some notable increases in security posture/capability by exploring this further.
Another outtro point is, I am not advocating for total network blocking between unmanaged and managed machines. There are definitely use cases where total network blocking may break things (like maybe printers that can’t run a security agent), but if you limit it to certain remote management ports, I’m not seeing the downsides. I haven’t heard a single good argument for allowing an unmanaged machine to connect to remote management ports on your managed infrastructure in an enterprise setting.
Call to Action
There are 3 call to actions I am issuing you if you read through this:
- If you think something like this would be useful and you use an EDR product, request they build this out. They won’t be incentivized to do this if it seems like no one cares about it.
- If I’m majorly wrong about this, please tell me. I accept LinkedIn shaming and scathing hand-written notes sent via carrier pigeon.
- Be good to the people around you.