Network Discovery
Questions about information networks typically involve performance or configuration inquiries but may also include protection. The fundamental question — “What’s actually connected to the network?” — might never get asked. It’s often assumed, and usually mistakenly, that someone or some team — the desktop, server or network group — has the answers. To a degree, responses from these groups should provide enough information to estimate an answer. But is an estimate enough?
The Why
Asset management, incident response, capacity planning, standards implementation and compliance are all topics or processes that can benefit from a network discovery — the process of finding out what is actually connected. This process should go beyond a simple count of nodes and attempt to identify what the nodes are.
The topics above look impressive, but the “why” might be just a simple question asked by upper management out of curiosity. But answering “why” can also address the burning question: “Is there any rogue equipment connected to the network?”
The What
A network discovery is the obvious process of finding out what’s connected to the network. This process could use existing tools or facilities such as Domain Name Services or the current information kept in the Dynamic Host Configuration Protocol database. Information provided by these services would typically be in the form of text and provide a list of nodes that can be used as a baseline. Asset information such as records of PCs, servers or other types of devices might also be available, perhaps kept by the appropriate support groups. Some agencies might have implemented network access controls, restricting access to known or registered devices. Information could be pulled from all these facilities and combined into something as simple as a spreadsheet or as complex as a database.
What would make this spreadsheet or database more colorful would be to include current operating system versions, device types and service information provided by each device, such as identifying hosted mail, Web or FTP services. If this information was available, it would offer an at-a-glance yet explicit picture of true network usage.
The How
To understand how the scanning tools work, consider the example of Nmap, a freeware tool from insecure.org. Running on a Windows or Unix platform, it can identify the OS and service version information with configurable output export options. In some cases, proprietary applications and security service vendors even use Nmap, so it would be interesting to query potential vendors about that when evaluating solutions.
An OS scan can take three times as long as a service scan of 10 ports.
Any tool selected will discover or identify only devices that wish to be discovered. It is possible with the use of a firewall to block probing attempts. Honeypot software can be used to mask the identity of a device, make it appear as a different device or even create mirage-type devices. Network configuration and the use of secure areas or demilitarized zones could block access to network segments containing servers.
The time of day at which the discovery scan executes also matters. It might miss devices if launched at night or over the weekend. Knowledge of IP address ranges used is important because discovery against unused addresses could take much longer. Lack of these ranges could even lead to an accidental leak of the scan onto the Internet. The more intrusive the scan, the more likely it will set off serious intrusion detection system alerts.
The most interesting consideration might be the use of a single port or service review as opposed to an OS identification. An OS identification is the most direct way of answering the primary question and can usually provide limited service information, but it takes more time. The single port scan is a specific look at a specific service. The result would include the version of the software supporting the service.
In some cases, the version of the service could be used to identify the OS. For example, a single service scan of the Windows file sharing NetBIOS service could be used to differentiate a device as either Windows or Unix. Another example would be a scan of the interactive login service Telnet. In this instance, Nmap would use the results to supply an OS version.
The Reveal
Discovery is a process that all agencies need to and should do periodically. After just one scan, return on investment can’t easily be measured, yet a discovery process can be implemented at a low cost and the benefits will indirectly strengthen other IT processes and security. And perhaps more important, it will let IT avoid that painful “We don’t know” response when the CIO (or the secretary, or an inspector general or a senator) asks, “What’s out there?” or “How did that get there?”
