NetFlow is the Wrong Way to Do Attack Surface Mapping

If your organization relies on NetFlow data for asset management, you're likely overlooking vital information to map your attack surface.

Network engineers commonly rely on listening to Internet packets to identify their organization’s assets. To communicate outside of the internal network, assets must move through choke points, like routers, switches or firewalls, that log packets with information such as the origin and destination addresses.

Network security professionals must ensure they can access everything that traverses their switches or network taps and one way they try to do that is using Netflow data. However, Netflow was never intended to find and catalogue all assets belonging to a company.

Cisco Systems introduced NetFlow for traffic sampling. It was designed to debug traffic flow and see if there were errors in network design/access control lists, and also make sure networks were functioning as designed. Relying on Netflow data to inventory your company's assets can lead to gaps in your attack surface map.

Challeneges of using Netflow data for asset management

NetFlow allows a network device to share a sampling of network traffic as it either enters or exits the device. Typically, a NetFlow setup comprises one or more aggregation systems that present the data in an analysis console for security professionals to monitor.

NetFlow provides the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), source address and port, and the destination address and port. Modern versions of NetFlow also provide information about TCP flags, but those are not useful for attack surface mapping. Let's dig into the significant challenges of using NetFlow for attack surface mapping.

• NetFlow cannot capture your entire inventory: NetFlow relies on a sampling of your network traffic, missing critical details. While this is by design, NetFlow is impractical to gain the broad and accurate picture of every asset needed for your attack surface map.

• NetFlow only uses IP sampling: Today, most network applications use DNS/HTTP sampling. NetFlow can only tell that two IPs are talking to one another, overlooking essential information. Specifically, it misses what is on that IP, whether it is your site, a search engine, a music streaming site, a video game or something else that has nothing to do with your company's assets.

• NetFlow is only useful while running: It's a chicken and egg scenario. NetFlow cannot find sites that you and others in your organization no longer visit. That’s a problem. For example, if your company has been around for a long time or if you acquired an older company, there are likely several assets not captured by NetFlow and they may still have exploitable vulnerabilities.

• Netflow cannot sample multiple locations: Suppose NetFlow is running in location A, but you have staff building websites in location B. In that case, there is no way for a NetFlow exporter to detect traffic from location B. Now, suppose your company has several satellite offices or a remote workforce. NetFlow will miss a significant amount of network traffic unless all traffic is sent through a set of centralized VPN concentrators, decrypted and finally sent through a router/switch that runs NetFlow.

• Netflow cannot run on a serverless or third-party API environment: With no access to a network or arrangements to access vendor networks or API environments, NetFlow is only effective at finding assets it runs over.

While useful, NetFlow requires a lot of work to set up and maintain. It's also expensive to analyze properly. If you or your vendor relies on NetFlow for attack surface mapping, you likely have significant hidden gaps in your environment.

Learn more

Gain visibility across your entire attack surface with Tenable.asm.