In today's IT environments, everything is interconnected, and here at ExtraHop, we believe that the best source for visibility into how those interconnected tools are functioning as a whole, is the network. We believe this—not because the network is the first thing everyone blames when there's a problem, even though it is—but because it's the single common denominator for every digital interaction. No matter what tools—third-party or otherwise—are being used in your environment, they all traverse the network at some point. Anytime you, as a user, interact with technology, it has to traverse the network.
That's why I'm fond of saying "If you can TAP a Network, you can TAP a keg."
The concept here is that if I can get some sort of an overview of how things are working in concert to deliver a service or capability, I can understand how it's truly performing. So, if you have good network TAPs in place and you have solid technologies observing all that traffic traversing the network, you have an understanding of how things are operating in your environment that is unparalleled. And maybe, if everything goes as planned, you have the freedom to relax and grab a beer.
When we speak in terms of network TAPs, the Garland Technology and ExtraHop Reveal(x) integration grants network visibility with an end-to-end infrastructure that helps you see into your network blind spots. When you deploy a Garland network TAP, you will get full live wire packet capture, securing the data at the physical layer. By integrating with Garland’s reliable network TAPs, Reveal(x) provides real-time application visibility, monitoring, and analysis for real-time threat detection and intelligent response. Think of your network TAP like a tap on a keg, allowing beer to flow into the glass for the customer—just like your network TAP allows data to flow into Reveal(x).
I've been around long enough to remember when interconnection in IT environments was not the norm. The big shift was with the iPhone and the surge in applications. As more and more services and media were delivered across these devices, it changed the nature of what an application is. It used to just be applications, now the app is the transport, the storage, the server functionality, the front-end application piece, and even possibly the OS of the device you're viewing it from. All of those impact the performance and the usability of whatever technology it is you're trying to use. That merging of disparate technologies to deliver that user experience is where this current inflection point has been created for IT.
I distinctly remember troubleshooting a problem—and this was years ago—where customers were reporting application problems. The first step was to speak with the application folks. From their perspective, the app is working just fine. Next, we ask the network folks—because, as I said earlier, everybody blames the network. Of course, the network is running fine. We then turn to the server folks—because the application that users are complaining about is running on their servers. Everything looks fine on their end as well. It took us a long time to realize that the application was sourcing data that was stored on a storage array. That storage array is running fine overall, but the areas where data for the application is needed are not.
The way I frame it is that the application is all of those things working in concert. If any one of those things is not working properly, you will only see it with the specific tools used to look at that specific technology stack. Also, if it's performing poorly, you won't be able to trap it very easily.
There are a lot of tools out there in the market that let you know how your web server is functioning, but they are pretty old-school solutions. I call them "old-school" because they approach IT the way we did 15 years ago. Solutions that span the entire scope of the network—i.e. Reveal(x)—set you up with a far superior perspective for viewing what's going on inside your environment and for discovering dependencies you didn't realize were there, enabling you to analyze results faster and make better decisions.
Our marketing team at Extrahop dubbed our three-tiered solution approach "Discover. Observe. Analyze." As I like to joke, the acronym for this is D.O.A.—more commonly known as "Dead On Arrival". And with ExtraHop, that's exactly what IT problems are—dead on arrival. We can isolate and resolve problems so much faster than was traditionally possible.
When Extrahop and Garland Technology work together, IT leaders can make faster, better-informed decisions that improve performance, security, and digital experience. Now, I'm not going to say that tapping the network ushers in a golden age of leisure for IT. But it certainly makes what we do as IT professionals a heck of a lot easier, and maybe—just maybe—we'll have time to step away and have a beer.
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.