Today I’m going to discuss the concept of discovery and its central role in network security. This discussion is part two of a series that looks at those tools and components that are not often thought of as being security focused but play a critical role in network security.
From a tooling point of view, discovery is one of the things that tends to be taken for granted but in order to do anything, whether associated with security or operational activities, you first need to know what you are working with. As a result, almost all network security tools employ some sort of discovery as a first step in whatever process they are responsible for. It’s hard to manage what you aren’t even aware of. So, if discovery is so ubiquitous, why am I taking the time to talk about it?
Well, it is not uncommon that during the process of demonstrating to customers the discovery capabilities of some of the tools that we work with, we uncover significant numbers of devices that the customer was previously unaware of. Even in situations where customers have a good handle on their device inventory, they often have no easy way to provide detailed information on the software versions, configuration states, and/or the relationships between these devices. While they may exist, I haven’t yet come across an organization that identifies discovery itself as a key component of their network security infrastructure.
Part of the problem is that, in most organizations, there are multiple different tools with overlapping discovery capabilities. The lack of coordination between these can cause confusion and lead to both duplications and, worse, blind spots in the view of the network. Another part of the problem is the word discovery itself as it gets thrown around as a single concept but what it translates to in the real world can vary wildly. There are two general dimensions where variability in the definition of discovery is an issue: depth and frequency.
How deep do you go?
One of the common ways to achieve “discovery” at the network level is to carry out a ping sweep of a subnet. This provides an inventory of all the components that respond to the ICMP ping on the network. Unfortunately, this data is very shallow and only lets you know that there is something at a given IP address without providing much in the way of information about what the device is or how it is configured. Worse yet, many network devices are configured to not respond to ICMP and so can be missed with these simple discovery processes.
Some additional information can be gathered through “fingerprinting” where the characteristics of the way that a device carries out a network conversation provides some insight into what it is, but true discovery requires going deeper. For network devices, this means pulling additional information via SNMP, CLI and/or APIs to collect information about device sub-components, software versions, and current and saved configuration of the devices. The configuration details are so important in the identification of security vulnerabilities that I will address configuration management in its own article later in the series. But even without considering configuration data for the moment, being able to identify manufacturers, models, and software versions for network devices has huge benefits. The Common Vulnerabilities and Exposures (CVE) database offers a good example. This is a collection of publicly available cybersecurity vulnerabilities that looks to standardize information from multiple different sources into a collection of security concerns associated with devices. Knowing that a given vulnerability exists for a certain device type and software load is important but has limited real world applicability unless you are able to map these onto actual devices in the network based on data provided through detailed discovery.
Another aspect of mapping CVEs to devices is the challenge of “Latent” security vulnerabilities. Latent vulnerabilities represent opportunities for compromise that may not be currently active but could easily become so during regular operational activities. Good examples of these are service level vulnerabilities on network devices.
Say, for instance, that you have a Cisco device running a particular IOS version that contains a vulnerability in its SNMP service subsystem. A common workaround for this is to disable SNMP on the device in question. From the point of view of security tools that examine devices from the outside, like vulnerability scanners, the device will no longer appear to be vulnerable. However, because SNMP is such a vital component of many organization’s management practices, there is a high probability that the SNMP service could be re-enabled for operational purposes thereby re-exposing the vulnerability. Deep discovery of the device provides insight into the fact that despite the service not being enabled, the device still harbours a latent vulnerability based on its model and software version.
Leveraging internal device information for topology
An additional benefit of a deeper level of discovery is that, particularly with network devices, it can give you access to additional mechanisms for identifying other devices on the network. This can help mitigate the challenge of identifying active nodes without depending on ICMP. For instance, the existence of other devices can be inferred from their network activities which generate entries in ARP tables of surrounding network devices. Deep discovery of the network devices can provide access to these ARP tables and allow effective device identification even when the devices are configured to not respond to ICMP.
These same types of information can also be leveraged to identify relationships between devices in the network to allow things like pinpointing which port on a switch a particular device is attached. Access to this type of data can significantly reduce the amount of time and effort a security team needs to track down rogue or compromised devices.
Once is not enough
The second, and equally important dimension to consider with respect to discovery is the frequency at which it occurs. While it may be technically correct to say that running a single point in time network scan constitutes a “discovery”, the reality of highly dynamic modern networks is that these isolated point-in-time discoveries are out of date very quickly. Any processes built around the data provided by the discovery can be suspect as they run the risk of being associated with data that no longer represents the “as-is” state of the network.
To be truly effective for network security, discovery needs to be an ongoing process that is continually collecting data to validate current state and identify changes and their sources. Ideally, this is achieved both by linking the discovery processes to standard configuration change mechanisms to catch expected changes as well as via regularly scheduled discoveries to capture changes done out of band of the standard mechanisms.
As one of my colleagues noted, discovery executed continuously and in depth behaves as a “patrol” of the network that acts as a consistent source of inventory and a trusted initiation point for a wide variety of security activities. But discovery for the sake of discovery doesn’t help much. Rather it is the use of this information combined with other sources of data such as core network services (think DNS and DHCP) that gives a complete view of the network. Extend this through to integration with the larger ecosystem of security tooling and you really deliver the value. As the saying goes, this is just the start of the story for network security but considering how pivotal network discovery is as a first step, isn’t it worth taking the time to evaluate if you are doing it effectively?