 |
|
|
Formerly Neupart & Munkedal, VIGILANTe was created in 2000 to offer various security services, including SecureScan, an outsourced penetration and security scanning service. With the acquisition of Networks Vigilance (formerly part of Cyrano) earlier this year, VIGILANTe has added a Vulnerability Assessment product to its portfolio. VIGILANTe SecureScan NX is a vulnerability scanner with a difference, however. In addition to providing the usual host scanning capabilities, it also provides remote probes to test networks on both sides of a firewall, as well as testing the filtering rules of the firewall itself. SecureScan NX is the only VA product we have come across that has anything different in the way of �architecture�. Whereas most VA products are single-point devices designed to scan individual or multiple remote IP hosts, SecureScan NX provides a distributed console-agent architecture which allows not only scanning of subnets behind a firewall, but also a complete evaluation of the firewall filtering rules in place between scanning agent and console. The Console is the �command control centre� for all security testing, reporting and problem solving. From this point, the administrator can define a testing environment, configure a testing session, monitor a test, and generate reports. There are various modules that plug-in to the SecureScan NX Console: Network � provides the capability to scan for vulnerabilities on all hosts across the network, regardless of operating system. Vulnerabilities are reported in detail, with guidelines provided to fix the problems immediately. The network scanner consists of a number of modular �Test Cases� which probe all network hosts, just as a hostile attacker would, and quickly report on which hosts are vulnerable and why. Test cases act like any intruder - attempting to obtain information about the system, and then trying any open backdoor through an unsecured service or inherent weakness in a particular version. System - The System module tests the OS to make sure that it is free from security weaknesses, following which it will recommend the steps needed to remove the weakness. This may be anything from directing the administrator to the appropriate upgrade or OS patch resides on a vendor site, to a complete restructuring of the system itself. Firewall - Allows the administrator to create security policies for testing a remote network, separated from the Console host by one or more firewalls or routers. In order to do this, the Firewall module utilises an installed component on both Intranet and Internet sides of the network, giving the ability to automatically analyse the filtering rules currently defined in the Firewall or filtering equipment located between itself and its probe. The Firewall module does not simply scan the firewall�s IP address, therefore, but provides end-to-end testing of the Firewall's security readiness. Any number of SecureScan NX Network Agents can be installed on remote subnets around a corporate network, allowing a single Console to assess hosts on multiple subnets quickly and easily without having to scan across routers and firewalls. All communication between Console and Agent is conducted over an SSL-encrypted TCP session on a designated open port (9999). The Agent acts as a client to connect to the Console, and this prevents the creation of a potential security hole, since the connection is always made from inside the firewall � the Agent will not accept a connection at all, and will only participate in sessions which it initiates (this can require careful planning where Agent-to-Console communications traverse several firewalls in a large corporate network). The administrator can control which Agents are allowed to connect to the Console. Any number of Engines (depending on the license) can be controlled from a single Console, and once an Engine has connected to the Console, it can be instructed to scan the internal network and create an internal map of hosts and active services. Via the Console, the administrator will determine the scanning policy and the appropriate Test Cases are passed to the remote Engine. The Engine then runs the scans to check for operating system and server vulnerabilities, and passes the results back to the Console. The Firewall Agent is installed on the Intranet side of the firewall or on the DMZ and, like the Network Agent, acts as a client to the Console. In order to facilitate communication through firewalls, all data transmitted between Engine and Console is passed over TCP on port 9999 (this port can be changed) and encrypted using SSL3. Unlike the Network Agent, which is a remote scanning engine, the Firewall Agent is specifically designed to determine the firewall's filter rules, automatically detecting which rules have been implemented to block or reject packets. The Console and the Agent can both monitor their local network, so each of them can detect whether or not a packet sent by the other passed through the firewall. The packets that are sent by the Console or the Agent are either standard packets (which are used to determine a global rule such as �Deny all ICMP requests�) or �calculated packets�. Calculated packets are built from the Agent�s internal scanning results, and are used to find logical rules such as �Allow incoming connection to port 80/tcp of server XYZ only� (this is usually implemented as two physical rules). The Agent cannot find 100 per cent of the filtering rules - in particular, rules based on the source IP address are not detected. Thus if the firewall protects an Intranet without any server, the generated report could be very small. VIGILANTe SecureScan NX is the only commercial VA scanner we know of which provides this distributed client-server architecture in order to facilitate scanning through firewalls, as well as firewall rule verification. The ability to divide scanning tasks between multiple machines across multiple subnets also allows SecureScan NX to scale much better in large corporate environments. Installation of SecureScan NX is simple. It requires a Windows NT/2000 platform on which to run (though it can naturally scan any TCP/IP host, no matter what OS it runs), and uses the familiar InstallShield process. During set-up, two installation options are provided: Console or Agent. All necessary raw packet drivers are installed automatically if the latter is selected. Once the remote Agent has been installed, all that is required is to start it running, and enter the IP address of the Console and the port on which to communicate (defaults to 9999). One problem we did note � which is a known problem � is that on a multi-homed host, both the Console and remote scanning Agents will bind to the first available network adapter. This can cause problems with the Agent since there is no way to specify to remote components which network addresses they should operate one. You may therefore find that when asking a Probe to perform a network scan for available hosts, it actually looks at the wrong subnet. It can also cause problems with licensing, since the MAC address of the host is used to generate the license information. If you should remove an adapter from a multi-homed machine � or even change an adapter in a single NIC machine � SecureScan NX will no longer run. This is a ridiculous restriction to put on licensing � a NIC could fail, or a complete host could fail, and it should not be necessary to obtain a new license key before the software can be installed on another machine. In other respects, SecureScan NX is licensed by IP address range per class C type subnet. For one license, you thus have the ability to scan all the available hosts on that subnet. All configuration and management is performed via the SecureScan NX Console, which has an extremely useful and intuitive interface, if a little busy when all the windows are on view. Toolbar buttons for �instant toggle� of individual windows allow you to tidy things up when you need to focus on one particular area, and we really like the full-screen-view toggle button � every application should have one. When first starting the Console, the administrator is presented with the Session dialogue box, allowing him to choose between the predefined or user-defined Sessions. There are only three predefined sessions: two generic Safe Scans - either Network or Firewall - or �New Session�, which enables the definition of customised jobs. The �Existing Sessions� tab enables the loading of previous scan Sessions � including individual job results � for further analysis. When creating a new Session, the administrator is guided through a Wizard. After naming the Session, and selecting whether to use the Firewall Agent or perform a straight Network scan (either on the local subnet, or via a remote Agent), the next screen allows selection of the scan �Perimeter�. This is simply a range of network addresses, and a new Perimeter can be defined at this point if required, or the default �Local Network� Perimeter can be selected. Any number of Perimeters can be defined within the license range, thus allowing logical groupings of machines for scanning purposes (for example, an entire subnet could form one Perimeter, whilst another might consist of just those machines in the Finance department). Note that the Perimeter only specifies the range of addresses which are available for scanning - the actual selection of machines to scan occurs later.
The Policies screen provides a small selection of pre-defined Policies from which to choose: Safe (all Test Cases except the Crash and DoS), Quick and Safe (all high vulnerability Test Cases excluding Crash and DoS), and Full (all Test Cases). Each Policy contains a set of Test Cases (vulnerabilities) sorted according to various categories, and it is possible for the administrator to define his own custom Policies. SecureScan NX allows scanning for vulnerabilities by:
That final option is incredibly useful, and is one we would like to see added to more VA tools. Basically, each time an automatic update is effected from the VIGILANTe Web site, the administrator can perform an immediate scan using only the new Test Cases. Within each category are a large number of Test Cases which represent the individual vulnerabilities to check for, and new Policies can be defined right down to individual Test Case level, or by selecting an entire category at once, by simply clicking on the appropriate check boxes. Double clicking on individual Test Cases brings up a very detailed description of the vulnerability, and provides the option to enter various parameters (such as first port, last port, packet count and inter-packet delay for the Land attack) to �tune� the operation of the scanner. Sensible defaults are provided for all test cases, so this level of detail is likely only to be used by the more advanced security analyst. This approach makes SecureScan very easy to use � just point and click � for the novice, whilst providing fine-grained tuning possibilities for those who know what they are doing.
Another nice touch is that wherever possible the Test Case description provides detailed notes on exactly how the Test Case is performed. This is a unique � and valuable � educational feature (see Figure 2), as well as providing information that may be of use in fine-tuning Intrusion Detection systems that are operating on the network being scanned. New Test Cases can be downloaded from the VIGILANTe Web site and incorporated into SecureScan NX automatically � this can be on demand, each time the program is started, or at regular scheduled intervals. As each upgrade is downloaded, new Test Cases should be automatically transmitted to all remote Network and Firewall Agents when each Agent next connects to the Console. However, we found that there were problems with this process in the release we reviewed (version 2.4.16.0), and VIGILANTe technical support is working on the problem at the time of writing. Once the wizard has finished, the administrator is presented with the main SecureScan NX screen, which contains a number of panes:
As we have mentioned before, the screen can get rather cluttered making some of the windows difficult to read, but it is possible to toggle all of the windows on or off via toolbar buttons, as well as toggle a full-screen view.
The Policy pane lists all the test cases that are available, sorted into the categories mentioned previously, and allows the administrator to override the default Policy selection by checking and un-checking boxes to select or deselect individual Test Cases or entire categories (such as Denial of Service, for example). It is also possible to view the global properties of the current Policy, where the administrator can set ping timeout values and hih/low ports for port scans, amongst other things. Changes to the default Policy can be saved back to that Policy or saved as a new one. The address range(s) available for scanning are listed in the Perimeter pane, and it is possible to add individual hosts or multiple hosts manually within the Perimeter, or SecureScan NX can perform a network scan to determine which hosts are available. Once the Perimeter pane has been populated with the available hosts, one or more can be selected by using the check boxes alongside each one, following which the scan can be triggered. When using either the Firewall or Network Agents, the Probe tab is used instead of the Perimeter tab, and it is necessary to select at least one host located on the opposite side of the firewall to the Console. This time it is the remote Agent that will be performing the scanning process, allowing hosts on the inside of the firewall to be scanned, as well as the inside of the firewall device itself. In addition, the Firewall Agent will also attempt to pass packets backwards and forwards between itself and the Console in order to determine which packets (if any) are allowed through the firewall. The two types of remote Agent operate completely independently, and the Console will only accept connections from the type of Agent that is appropriate to the Policy being run. Once the Policy and Perimeter details have been finalised, all the settings needed to recreate the job in the future are saved as a Session. This allows the same type of job to be run again and again providing the basis for trend analysis. The Session Management screen allows the administrator to schedule Sessions for regular unattended runs (the reports can be e-mailed automatically to the administrator at the end of each run) as well as to delete individual Sessions that are no longer required. It can also check for dependencies, identifying �orphan� Perimeters and Policies that can be deleted quickly and easily if no longer applicable. The Policy and Session Management capabilities in Version 2.4 are a huge improvement over previous releases. The scan itself is split into two phases. The first phase involves ping sweeps and port scans to determine which hosts are alive and which services they are running. From this, SecureScan NX determines the likely operating system and the potential vulnerabilities, and thus can decide which Test Cases are to be run against which hosts. One of the global Policy settings allows the administrator to force a �Heavy Scan� if required. This means that where SecureScan has had difficulty in determining the likely OS running on a particular host, or where the administrator believes that it has been identified incorrectly, it can be forced to run every Test Case against that host to ensure that it is thoroughly tested. We found OS detection to be very accurate. Once a port scan has been run for a particular Session, the details of all the services found running on each host are stored in the database. When the same session is run in the future, the port scan process (which can be quite slow) is omitted, the Test Cases being based on the service information from the database. Service details can be cleared manually, forcing a re-scan when required, or a parameter can be set which will force them to be cleared � and thus a new port scan executed � for every run. During the scanning process, SecureScan NX keeps you well informed with an extremely useful real-time display consisting of several windows. The Control tab in the Output pane contains detailed text messages highlighting the port scan status, which ports were found, which test cases are being run against which hosts, and what results are returned. This can be saved as a plain text log to provide further analysis at a later date if required. The Scan Results tab shows a real-time graph of the port scanning status � number of TCP/UDP ports scanned and number of active services found � along with a list of the scan results broken down by host. The Test Case Results tab shows another real-time graph of the number of Test Cases that have found vulnerabilities, along with a list of vulnerabilities found broken down by host. Right clicking on any host entry brings up detailed information about that particular host, including host name, IP address, operating system and full list of available services amongst other things.
The Hosts Results tab is probably the most important. This displays a list of hosts, along with their current status and details of how many vulnerabilities were found. Selecting any one of them will bring up a list of Test Cases that produced a vulnerability, encountered a system or network error or have an undetermined status. It reports the Test Case ID, the result of the test, the risk that the Test Case presents, the type of impact it has (attack, info gathering only, etc.), whether there is further information available (such as banner text, or a directory listing following a successful exploit) and the port on which access was obtained. Selecting any individual Test Case brings up the properties of that Case with full details of the vulnerability tested for, how it was tested, and what results were returned. A drop down menu provides filtering on this window allowing only �found� vulnerabilities to be displayed, and eliminating the clutter of �errors� and �undetermined� when required. Note that no automatic fix capability is available within SecureScan NX. The final tab only comes into play when a Firewall Probe has been run. The Filters tab is similar in look and operation to the Host Results tab, except this time we are looking at missing filter rules in the firewall configuration between the Probe and the Console. With a Firewall Probe, the Test Cases work by trying to send a packet through the firewall. If the Result column shows �Found�, then the packet in question was able to get through, which may indicate a security failure. Not every successful Test Case indicates a security failure, of course, but the results presented by SecureScan NX should be consistent with your own security policy. By clicking on the Generate Filer Rules button once the test has completed, SecureScan NX will display the filter rules it has been able to identify based on the test cases it has run. These rules can be saved in Linux/ipchains, Linux/ipfwadm or Cisco IOS 11 format. The firewall testing capability of SecureScan NX is unique amongst VA scanners as far as we are aware, and is an incredibly useful feature.
Once a scan has been completed, the results are saved automatically in the underlying SQL database for reporting purposes. Each set of saved scan results is know as a Job, and each time a previously-saved session is recalled and a scan run then a new Job is created. Any Job can be loaded into SecureScan NX for historical reporting purposes, and SecureScan NX will compare multiple Jobs to provide trend and comparison reports. The reporting section of SecureScan NX Console (which has been extended significantly in the latest release) allows the administrator to generate several types of reports from the latest Job that has been run (or loaded into the Console from previous sessions). The following reports are available:
All reports are generated in HTML format, and are displayed in the default Web browser, as well as being saved automatically to disk. The only way to print them out, however, is via the browser�s own print facility. Each vulnerability carries detailed information against it (the same information that is available when viewing from the console) and also provides hyperlinks back to the VIGILANTe Web site to provide more up-to-date information and detailed instructions on how to eliminate the vulnerability wherever possible. The SecureScan NX reporting is clear, comprehensive and easy to read. Some might object to the fact that it is not possible to create new reports or customise the existing ones, but there is enough information presented within the numerous standard reports to suit most purposes. SecureScan NX is a well-crafted piece of software with a simple-to-use, intuitive user interface, and a wide range of vulnerability signatures backed up by regular Web-based updates (probably the most frequent updates of all the products we have seen in the last year). These signatures do seem to focus on real �hacking attacks� as opposed to OS vulnerabilities (such as mis-configured guest accounts, inadequately secured administrator accounts, or poor password policy), so some sites might like to consider running SecureScan NX alongside an OS auditing tool of some sort for complete coverage if this is an issue. The only part of the product that causes concern in the current release is the operation of the remote Agents on a Windows 2000 platform � new Test Cases do not appear to be transmitted automatically from Console to Agent in certain circumstances. VIGILANTe technical support is working on this problem at the time of writing and we expect this to be corrected in the 2.5 release. It would also be nice to see a Unix or Linux Agent included in the product to make it easier to deploy in existing distributed networks, and we would like to see the licensing process divorced from the host MAC address. However, these minor niggles aside, SecureScan NX offers the most comprehensive real-time analysis tools we have seen on any product of its kind, together with an extensive suite of reports that are well presented and easy to read. Since we last evaluated it the product has been improved significantly in terms of performance (scans are almost twice as fast) and Session and Policy management capabilities. The number of Test Cases has also been increased considerably. It provides a basic set of default policies which can be run with little or no �hacking� knowledge, yet also makes available detailed descriptions of the vulnerability checks and the means to tweak the operational parameters for those who know what they are doing. SecureScan NX seems to strike a rare balance between ease of use for the novice, and power and flexibility for the security expert. Where SecureScan NX really scores, however, is with its distributed architecture that allows remote scanning of large networks from a single, central console via multiple remote Agents. In addition, the Firewall Agent provides similar remote scanning capabilities which allows it to not only scan hosts on the inside of a firewall, but also use a number of special Test Cases to attempt to pass packets from Agent to Console � and vice versa - through the firewall, thus determining the effectiveness of the filter rules in place. To our knowledge, the distributed scanning and firewall probing capabilities are unique amongst commercial firewall tools at the time of writing, and these make it an ideal tool for scanning large, distributed corporate networks from a single location, right down to scanning the local subnet for half a dozen hosts. This should be considered an essential part of any security administrator�s tool kit - if you want to perform VA scans, you should be looking at SecureScan NX. Company name:
VIGILANTe Denmark
(European Headquarters) France United
Kingdom Germany Netherlands
Click here
to return to the Vigilante SecureScan Results |
Security Testing |
Send mail to webmaster
with questions or
|