Automated Security Scanning

John Tiso

When I began my career in systems administration and operations, knowing the security vulnerabilities of our systems was relatively straightforward. Our users were wired with RS-232 cables direct from the host to terminals and later by terminal servers. Points of egress to the network were limited to the occasional dial modem, and the infrequent point-to-point connection. We knew which users wrote their passwords underneath their terminals. The growing evolution of e-business, the Internet, and the ubiquity of remote access solutions turns the simple task of identifying security vulnerabilities into a task beyond the capabilities of the general purpose systems administrator.

Cisco Systems has developed a graphical-based tool, Cisco Security Scanner (formerly called NetSonar) to automate the discovery and reporting of security vulnerabilities in systems and networks. It provides automated vulnerability detection to the masses (at list price at $495 USD). It has two major functions: network mapping/device discovery, and vulnerability assessment. In this article, I will discuss the base installation and operation of Cisco Security Scanner and present two real-world case studies.

Installation

The base system requirements for Cisco Security Scanner for both Solaris x86 and NT are a Pentium 266 with 64 MB of RAM, a 2-GB hard disk, and a Java-based browser. The SPARC version will run on a minimum of a SPARC 5 and has the same memory and disk requirements of the latter. The installation is menu driven off the CD or downloaded file. A demonstration copy of the software can be downloaded from CCO (Cisco Connection On-line), Cisco's Web site at:

http://www.cisco.com/public/sw-center/  \
   internet/netsonar.shtml

http://www.cisco.com/kobayashi/sw-center/  \
   internet/scanner-updates.shtml

Scanning the Network

Once the product is installed, it's time to start. The workstation running Cisco Security Scanner should be placed on the network that you want to scan and should have full network connectivity. If DNS resolution is configured on the Cisco Security Scanner, it can utilize this information in reports and maps.

The first step in scanning the network is to define a “session”. The session consists of the parameters used to initiate a scan. The parameters include IP address range(s) and whether or not to use DNS resolution. The session also can be configured to force a scan. In normal operation, Cisco Security Scanner does a ping sweep to determine hosts. If you are filtering ICMP (Internet Control Messaging Protocol) packets, you can opt to force a scan. This will port scan each address in the range, even if it does not answer a ping. This is a useful option, but it considerably slows operation.

Cisco Security Scanner sessions can be run on demand or can be scheduled daily, weekly, monthly, or randomly. It makes the most sense to schedule your scans for your system and network during off-peak times. (See the sidebar “So Where Do I Scan?”.)

Reporting

After scanning the network, Cisco Security Scanner can generate a variety of different reports. The user can informally browse a grid of results or create charts (nine different types of charts that highlight and group vulnerabilities) or generate formal reports. There are three different types of reports: executive briefing, brief technical and full technical. The executive report is intended to provide a high level listing of the security issues collected during a scan. The brief technical provides a summary of the security issues collected during a scan in tabular format. The full technical report encompasses all of the information of the previous reports, and adds in-depth focus on all security issues. All of the report types and graphs can be combined and/or edited, as they are in HTML format. As a consultant, I find delivering the executive briefing report coupled with the full technical report to be an excellent resource to add to a deliverable document to the customer. Figure One shows a sample summary table from the first page of an actual scan I performed on a small subnet (all IP addresses have been changed to protect the innocent!). This type of summary would be present in a brief technical report. It provides time, date, and hosts scanned. It also provides a listing of vulnerabilities by severity. Figure Two shows a single vulnerability detected on a group of hosts. This level of detail would be provided in a full technical report.

Case Study 1

A small research company delivers information to its customers. Its traditional delivery method was hard copy, but now uses the Internet to deliver to the customer. Its IT staff was grown internally, and there has been some turnover. Consultants have been used for point projects in IT, but no one ever looked at security as an issue.

The first step was to attach the Cisco Security Scanner to the internal LAN to assess the inside of the network (see Figure 1). A wide variety of security issues at various levels were discovered. The most interesting issues that were discovered were wide use of a commercial remote control product on non-UNIX systems and non-authorized remote access services added by end users.

The next step was to attach the Scanner to the Internet to conduct a scan. The thing to be aware of here is that the site had redundant routes to the Internet via BGP routing. So, the interface where traffic entered the network would depend on the service provider used. Theoretically, a scan should be performed from both directions. However, a scan from one direction and a manual inspection of the perimeter router to make sure the interfaces were identical was used.

In this instance, we were able to determine what vulnerabilities were present on both the interior and exterior of the network. The reports produced were suitable justification for additional hardware and security practices.

Case Study 2

A “Dot Com” company built its network during its incubation period. They have since moved to a co-location facility and are interested in looking at network security as part of their overall strategy. In this case, the first scan was performed from outside the firewall to assess the network. We then scanned different parts of the internal network. Lastly, we scanned and investigated the termination point of the VPN (see Figure 2).

There are a few issues to be aware of here. Depending on the configuration and type of network load balancer utilized, we may need to scan on all sides of this device. Network load balancers work at varied network layers and its function may keep us from getting an accurate scan, since its job is to redirect packets. Also, the VPN creates an “open door” from its termination point. This network needs to be given the same consideration, because its VPN tunnel is an open pipeline.

In this instance, the initial evaluation of the network allowed the customer to develop a plan to improve their overall network security architecture. They also used the results as a baseline to set up security monitoring procedures and integrate periodic scans, using Cisco Security Scanner, into the network.

Conclusion

Securing a computing environment is a “moving target” and requires constant monitoring, assessment, and improvement. Cisco Security Scanner provides a cost effective, automated tool for assessing security vulnerabilities.

Reference

Cisco CCO Documentation for Cisco Security Scanner: http://www.cisco.com/univercd/cc/td/doc/product/ \
iaabu/netsonar/ns20/index.htm

About the Author

John Tiso is one of the founding employees of Networked Information Systems, a Woburn, MA based integrator of Cisco Systems and Sun Microsystems. He has a BS Degree from Adelphi University, Garden City, NY and is a Cisco Certified Internetwork Expert (CCIE #5162). He also holds Sun, Microsoft, and Novell certifications. John can be reached at: johnt@netinfosystems.net.