Tackling the Visibility Monolith
Visibility Series Part 1

Until recently, I had only thought of visibility as a monolithic and all-encompassing function – a “catch-all” that various teams dive into when they need a clear view of what is occurring in their network. However, I’ve learned that different teams need different views on how their systems communicate across the entire enterprise. As teams grapple with the concept of what is in the environment, and what needs to be secured, “visibility” is the word everyone comes back to.

In this series, I’ll provide a lens for looking at the objectives of a visibility project and who they benefit, to help focus these undertakings. Let’s begin with the categories of visibility. 

Network Visibility 

In the past, my focus has been network traffic visibility. If an intrusion detection system or intrusion prevention system (IDS/IPS) engine fires an alert, these network traffic tools can help ascertain exactly what happened. Those who respond to alerts trust these engines in most cases, but it is important to ask how real the alert is. For example, if a low-risk alert occurs, did it miss something more serious (for whatever technical reason) or is it really just low-risk? This is where that melding of machine learning (ML) engines and human review looking for anomalies is critical. And humans need actual traffic, not just the records of the traffic, to determine real threats. 

So how is this type of visibility accomplished? That comes into the realm of the network TAP tools and creates important considerations for deployment. Do you have the processing power on switches to copy the data and send it somewhere, or should a piece of physical hardware be installed that copies the electronic signal and sends it to a processing engine of some sort?  

Shadow IT 

The next category of visibility concerns hidden applications – those under-documented network components, or so-called “Shadow IT.” Here, we want to know what IS on the network, what is in use, and where. This category includes a WIDE swath of tools and none of them seem to cover it all by themselves. You can, for example, make some progress in discovering hosts with a vulnerability management solution. However, if networking isn’t aware of a subnet in use, DevOps can spin up systems and that subnet is suddenly returning discovery probes. 

Such a solution is traditionally blind to the unauthorized use of Salesforce or Amazon Web Services (AWS). This is where your cloud access security broker (CASB) and secure access service edge (SASE) solutions can come into play. They often have some sort of detection tool that looks for traffic to these vendors, deployed in some combination of agents or inline, depending on the environment. When deployed with enforcement, they can steer that traffic in such a way as to allow other tools to review it.   

These tools still interest the security folks mostly. To some degree, the networking team will be interested as well, as these tools can find subnets that aren’t well known. The vulnerability side can potentially keep dev and networking on the ‘better’ side of security if it’s well presented and they are able to keep up with findings at a reasonable pace.   

Network Documentation 

This is the category that caused me to consider breaking visibility out into separate categories in the first place. The primary thing any troubleshooting or engineering project wants is the Visio, which answers the questions of how does traffic flows, what devices can filter/block/limit traffic getting from point A to point B, and does it make sense from any criteria that can be leveraged. 

Primarily, this is what is going to interest your networking team. When they get an outage call at 2AM and must figure out why traffic isn’t flowing from A to B, they do not want to have to build a new diagram. Further, as the network grows, the architects want to know what traffic is where. Should it be “moved” or rerouted to improve performance? Is it going through the tools that it should (see above)? 

There are open-source tools, but most of the time, network documentation is a manual and painful process. Sections of the network get diagramed out at various times, covering a specific subnet or three that need communication. A full and complete diagram in a large enterprise is (at best) described as “unwieldly” by providing too much data for the use case at the time. Out comes the Visio or whiteboard and a new diagram is created for the use case. There are some vendors that claim to help with this problem. While it may sound simple as the vendor tells it, I have my doubts when it comes time to configure, maintain, and leverage their tools for this kind of visibility. To some degree, firewall automation tools for segmentation/rule maintenance can help, but that is also not an ideal option. 

Where to Start 

Nexum has helped a multitude of customers reexamine how they are approaching visibility, from an immediate need of getting visibility deployed into new architecture, cloud or on-prem, to whiteboarding a roadmap moving forward. Nexum’s professional services team will help to ensure the solutions of today meet the expected and desired growth of your organization in the future. Talk to an expert for more details.

Jump to –

• Flashlight on ShadowIT: Visibility Series Part 2
• Network Alerting: Visibility Series Part 3
• Documentation from Visibility: Visibility Series Part 4