When I talk about sensor-based products, what I’m specifically referring to is any product that sits outside of the traffic flow, and consumes network traffic either via a TAP/SPAN port, a packet broker or a switch with packet broker capabilities, or through manipulation of a switch’s forwarding plane via OpenFlow or other SDN technologies.
What is a sensor-based product, and why should I care?
There was a lot to unpack there, so let’s take a step back and talk about the implications of each of these:
A sensor sits outside of the traffic flow.
This means that it is not inserted into the network at layer 3 or layer 2. This has a primary benefit of meaning that these products can be added and removed from the network with little to no impact on network function. It also means that overwhelmingly the insights they produce are consumed via product integrations and automation platforms that can react to them to affect traffic.
The sensor gets access to traffic from other devices.
This means that other devices on your network are responsible for either rerouting or more commonly copying packets and delivering them to multiple places. This means that these sensors can be virtualized and reduce the footprint of equipment at your edge, as well as benefit from the flexibility and features of your virtual environment.
Finally, let’s get to the most important part: why should you care?
I care about these new sensor-based products for many reasons. We’ve seen a massive move towards consolidation of what used to be separate products. You used to have a firewall, a URL filter, an IPS, etc. Each of these devices either sat inline or used something like WCCP to affect traffic. Each of them had their support, licensing, management, logging. Each of them could bring down the network.
Nowadays, it’s more common for a customer to license those features from the edge firewall vendor and run them all on the same equipment. This is a tremendous value, and mostly each of these features has become a commodity – vendors are at least consuming URL categorization updates from third-party providers, similarly with AV and IPS signatures. These are useful, sensible approaches to meeting these basic security needs.
What they don’t provide is much in the way of specialization. New features will typically have broad demand, but that doesn’t help when you have a specific, unique security challenge to your environment. It could be a legacy environmental sensor network that you can’t forklift for the next five years, or it could be a backend reporting application that your organization loves but is a little slow at releasing security patches. Perhaps you face a specific threat because of the type of information you keep in your data center. Whatever your circumstance, as much benefit as the push towards a consolidated edge platform brings, your organization will eventually find something that throws your edge for a loop. This is where a sensor-based product can shine.
What’s so special about sensors?
I’ll run through a few sensor-based products on our line card, as examples, but first I’d like to expand on a point from earlier. Because these devices don’t sit in the traffic path, they are typically easier to develop and bring to market. This means that a novel approach to detecting a security event that would otherwise be missed by your edge can plug a hole. It’s a bit like choosing the right tool, and that’s one of the things that I feel sensors bring to the table. Because you can add them a la carte, they will typically be more focused, produce far fewer false positives, and be more cost-effective.
One of the first vendors we signed on that falls into this category is Vectra. They do some exciting things with data sciences to detect breaches based on the shape of network traffic. What’s exciting about them is that these detections rely on behavior that an attacker can’t easily hide, even inside of an encrypted tunnel. This type of analysis is difficult to perform at the edge, assuming your edge device even has visibility to the traffic. It also tends to produce more false positives, because it’s looking at patterns of behavior. Vectra has great integrations with orchestration and automation platforms and provides extremely valuable alerts in terms of investigation.
The other two products I’ll briefly mention are Armis and Forescout. Both have comparable feature sets, and both have virtual or physical appliances that consume network traffic to identify, profile, baseline, and monitor devices on the network. If a device starts behaving in ways that diverge from its baseline, it can react to that. This may use RADIUS to bounce the device into another, less privileged network, or it may merely alert the network team to perform an investigation. The reason I discuss them here is that each of these products gets visibility to a network via these out of band means.
What all of these products have in common is that they are purpose built and low impact. They can be added, removed, and evaluated quickly and easily. They’re meant to be modular and complementary.
So, what’s the point?
The point of all of this is to point out that there are a large number of new, innovative products on the market that are meant to contribute to your security posture, rather than replace large parts of it. These products typically rely on getting access to network traffic, and SDN capable switches can enable that.
If I were asked to make a prediction, I think we’ll see OpenFlow continue to be developed to take advantage of the increasing performance of our commodity network equipment. Soon, you may see an edge firewall product that orchestrates NAT and PF on an edge router, entirely from a VM, and occasionally kills an in-flight connection once it’s been determined to be malicious. We may then see interoperability between modular products, where pluggable components collaborate to assess security posture in real-time and feed that composite determination to a device that can enforce changes to traffic handling.
Much more likely is that you’ll have a line item on your budget for “breach detection” or “IoT Security.” Rather than another inline box, you may end up evaluating one of these sensor-based products. Over time, as orchestration and interoperability continue to grow in importance, our security policy will end up spread across the various products we’ve acquired over time, glued together with orchestration platforms like Demisto, Phantom, or ProofPoint TRAP.
Closing thoughts and unforeseen consequences
The last things I want to point out is that these products are driving requirements for API’s, integration, and orchestration platforms. These are typically concerns reserved for system administrators, not network and security teams. Spending time expanding your fluency with a scripting language like python, debugging tools like Postman, and data serialization formats like JSON or YAML may all help you be more comfortable in this increasingly orchestrated world.
The good news is that being able to select from this broader array of products and evaluate them with less impact on production network traffic is going to slowly remove more of the day to day operational tasks of adding IP’s to blacklists and performing investigations for your security teams. Don’t squander the free time you get from these things, but reinvest in some of the skills I mentioned above. They will pay off in ways that aren’t strictly straightforward, and help you be able to make even better use of some of these new technologies.
For more information on how we can help you protect your network with sensor-based products, please contact us here.
- How DNS Tunneling Can Be Abused - March 21, 2019
- The Rise of Sensor-Based Security Products - March 15, 2019
- Armis Breaks Down Vulnerabilities in the Internet of Things - January 30, 2019