 |
|
|
The Symantec Network Security 7100 Series is a family of integrated intrusion prevention appliances designed to detect and prevent attacks across multiple network segments at up to Gigabit speeds. A range of models are available covering various sizes of installation from small business to large enterprise, and all use the same software version. The SNS 7160 under test here is a dedicated 2U appliance designed to monitor and protect multiple network segments at Gigabit speeds. The device sports twelve copper 10/100/1000Mbps ports, of which eight are used for monitoring, three for sending TCP resets when monitoring in passive-mode, and one for management. The eight monitoring ports can be configured in various combinations of in-line pairs (in blocking or non-blocking mode), or single passive-mode ports. Overall, the performance of the SNS 7160 was very good, easily handling the rated 1Gbps of traffic under normal network conditions. Attack recognition and blocking ability were excellent out of the box, and improved to a perfect 100 per cent following an update, whilst resistance to all common evasion techniques tested was also perfect. Latency was also very good for a device of this type, allowing the SNS 7160 to be deployed anywhere in the network - either at the perimeter or in the core. We found the SNS 7160 to be very stable and reliable under extended attack, and the handling of high-levels of DOS/DDOS attacks (such as SYN floods) was excellent. Out of the box, policy management, alert management and reporting is first-rate. We found the management system to be powerful, scalable, and intuitive, with an advanced event correlation capability that simplifies the processing of large numbers of alerts and some good reporting and analysis tools. The Symantec Network Security (SNS) 7100 Series offering is available as a range of dedicated, purpose-built hardware appliances which all employ a common core architecture that provides detection, analysis, storage, and response functionality (referred to by Symantec as Intrusion Mitigation Unified Network Engine, or IMUNE). The main components of the SNS 7100 system are as follows: Symantec Network Security Console The administrative and management component of SNS is called the Symantec Network Security Console. It communicates over an encrypted and authenticated link to ensure that authorised administrators may log in from any secure or insecure network. The Network Security Console manages all operations, including policy management and application, drill-down incident analysis with full packet capture, detailed event descriptions, application of security updates and patches, and allows event annotations and incident marking for tracking. The Network Security Console provides an interface from which the administrator can monitor events and devices, edit sensor parameters, configure protection policies and response rules, apply policies, and view log data. It is possible to generate reports and view them immediately in the Network Security Console, or they can be scheduled to be generated automatically and transmitted via e-mail or Secure Copy (SCP) .
Four pre-defined roles provide granular management. Roles are sets of permissions for specific management operations, and each user's login identity determines their role and permission assignment during an administrative session. SNS installs with a SuperUser account, and the SuperUser can create additional login accounts in the following user groups:
It is not possible to restrict access to specific policies or interfaces on a per-user basis. The SNS console enables encrypted and authenticated communication using password-protected 1024-bit Diffie-Hellman key exchange and 256 bit AES encryption. The 7100 Series Appliance contains a variety of tools and techniques that work together to gather attack information, analyse the attacks, and initiate responses appropriate to specific attack circumstances. The following diagram illustrates the basic architecture:
The components of the SNS appliance architecture include: Alert Manager - The SNS Alerting Manager provides three types of alerts or notifications: a console action alert, an e-mail alert, and an SNMP trap alert. Sensor Manager - The Sensor Manager maintains a pool of sub-processes to manage sensor-related functionality. This includes sensor processes for event detection, traffic recording, and FlowChaser sub-processes that handle network device configuration, starting and stopping. Administration Service - All communication across the network passes through the QSP Proxy, an administration service with 256-bit AES encryption and pass phrase authentication. This ensures that all communication between the Network Security Console and the master node, and between appliance nodes within a cluster, are properly authenticated and encrypted. In addition, this service enforces role-base administration and thus prevents any circumvention of established access policy. Analysis Framework - Because SNS appliances have access to information collected by other SNS nodes - and even other IDS systems deployed on the network - attack analysis and response can be coordinated across a distributed network, enabling a rapid global attack response. The SNS Analysis Framework (AF) aggregates event data on possible attacks from all event sources meaning that multiple related events are correlated and presented as a single “incident” at the console. This makes it much easier for the administrator to sort high priority alerts from those which are less important. The Analysis Framework also performs statistical correlation analysis on events to identify event patterns that vary significantly from usual network activity and to identify individual events that are highly related, such as a port scan followed closely by an intrusion attempt. The grouping of several low priority alerts together in a single incident - based on event type, source or destination - thus makes it easier to spot when several exploits are being employed one after the other in a concerted attack. When an event is received from the sensors, the tuneable Analysis Framework considers its characteristics to decide if it is part of an existing incident. If it is, it is added to that incident - if not, a new incident is created. All further analysis is then based upon the current incidents and not on the individual events. If no new events are added to an incident for a predetermined period of time, the incident expires and is moved to the historical incident list. Incidents are extremely valuable in the determination of malicious activities because individual events may or may not be important by themselves, until other related events take place and build a profile of activity. For example, a port scan is not an important enough event to send a notification at 3:00 in the morning. But, rather than throwing away that information, an incident will hang on to it to see if more activities follow. An invalid login on an open port also is not necessarily a significant event. Incidents allow these activities to be associated such that the priority may be increased. After a certain number of invalid logins, the priority for the incident may be high enough to take action. This allows for a much more granular approach to attack response, so that no one is bothered when the threat severity is low, but resources can be allocated rapidly when necessary. Databases - SNS uses multiple databases to store information about attacks, the network topology, and configuration information, including:
Event Stream Provider - The Event Stream Provider (ESP) prevents flood invasions by categorising events and treating them as a single unit when it sends them to the Analysis Framework to be analysed. The ESP can also monitor bi-directional traffic. When the ESP monitors an event, it generates a message hash and a destination hash of the event. The ESP uses the values of these two hashes to select the queue into which to place the event. The ESP then pushes the queued events to the Analysis Framework at a rate configured by the administrator. The ESP checks each queue in turn and pushes one event to the Analysis Framework from each queue containing events. Given this architecture, if multiple identical events bombard the network, as in a DoS attack, SNS will assign the same message and destination hashes for all of the DoS attack events and place them in the same queue. This prevents the Analysis Framework from becoming overloaded with the DoS events, because the ESP sends only one event at a time from each queue. If there is an attack hidden beneath the DoS attack, the message and destination hashes for the events related to the hidden attack will differ from the DoS event hashes. The ESP, therefore, places these events in separate queues. The Analysis Framework can then analyse the events related to the hidden attack. Sensor - SNS 7100 Series sensors can be deployed in either in-line or passive mode, and using interface groups or single monitoring interfaces. SNS detects a variety of threats using a layered detection model that Symantec refers to as its IMUNE architecture. This architecture includes protocol anomaly detection (PAD), Vulnerability Attack Interception (VAI), Signature Detection, evasion detection, Denial-of-Service and Scan Detection, and traffic monitoring. Independent of the deployment mode of a particular sensor, SNS applies the same detection strategy and protection, tuned to maximise detection while retaining network performance and reliability. For example, using in-line mode, the sensor tunes itself to minimise latency and maximise throughput across a pair of interfaces. Using interface groups, the sensor correctly adjusts itself to compensate for the fact that a single network session may be conducted using multiple, asymmetric links that have packet-based asymmetry. Using single monitoring interfaces, the sensor batches process packets to maximise detection coverage. Smart Agents - SNS Smart Agents provide a bridge between SNS and other intrusion detection/prevention and firewall products, allowing users to centralise management of events and incidents from the Network Security Console. Smart Agents enable SNS to collect data from third-party hosts and network IPS/IDS products in real time, as well as collecting event data from external sensors such as Symantec Decoy Server. This data is then sent to be analysed, aggregated, and correlated with all other SNS events. FlowChaser - FlowChaser serves as a data source in coordination with TrackBack, a response mechanism that traces a DoS attack or network flow back to its source, or to the edges of an administrative domain. FlowChaser receives network flow data from multiple devices, such as SNS sensors and network routers. The SNS 7100 Series is available in three models :
The device submitted for testing was the SNS 7160, a purpose-built, dedicated 2U appliance designed to monitor and protect multiple network segments at Gigabit speeds. The SNS 7160 runs an optimised, hardened operating system with limited user services to further increase security and performance. The rear panel sports twelve copper 10/100/1000Mbps ports, of which eight are used for monitoring, three for sending TCP resets when monitoring in passive-mode, and one for management. The eight monitoring ports can be configured in various combinations of in-line pairs (in blocking or non-blocking mode), or single passive-mode ports. Also on the rear panel are dual power sockets (the supplies and fans are not hot-swappable), master power switch, USB ports, serial console port and Compact Flash slot. The serial console can be used for initial configuration of the appliance and for command line access to the operating system utilities and file systems. The Compact Flash can be used for initial configuration and for full backup and restore. Slave appliance nodes can also be configured initially from Compact Flash. The front panel sports a number of useful LED indicators, plus an LCD screen and push buttons. The screen can display two lines of sixteen characters each, and there are six buttons: four arrow buttons and two function buttons labelled s (start) and e (enter). The LCD panel can be used for initial configuration of the appliance if required. After initial configuration, the LCD screen displays system statistics in a rotating sequence, and provides a menu of tasks including stopping and starting SNS, rebooting or shutting down the appliance, and changing the IP address. Command and control of the device can thus be provided via a Java-based Console, SSH connection, direct serial connection, or the front panel LCD. In-line mode Protection Policies are configurable so that the administrator can choose to block and alert on designated events. It is a one-click operation to switch between blocking mode and alert-only in the Network Security Console - Symantec refers to this as “One-Click to Prevention” as it enables users to move rapidly between blocking and non-blocking modes very quickly by circumventing multiple, time-consuming editing steps found on some other products. In blocking mode, all network traffic is examined by the SNS detection software before it enters the network, and when a blocking-enabled event is detected, the offending packet is dropped. For TCP/IP traffic, a reset is also sent to both sides (client and server) of the TCP connection (this will be a configurable option from the next release). In in-line alert-only mode, the SNS detection software still analyses all packets as they enter the network, but will neither block packets nor reset connections. The advantage of in-line alerting mode over operating in passive mode (attached to a switch SPAN port or network tap) is that it is possible to enable blocking with a single mouse-click from the Network Security Console - it is not necessary to halt network traffic while changing cabling and configuration to switch between in-line alerting and blocking modes, and nor is it necessary to create and manage multiple policies for blocking and non-blocking operation. Interface grouping enables up to four monitoring interfaces to be grouped together as a single logical interface. This is especially useful in environments where packet-level asymmetry is present. By default, the 7100 Series appliances fail closed, meaning that network traffic is blocked when the appliance fails or is shut down or become temporarily unavailable during, say, software upgrades. This behaviour can be modified with the addition of an In-line Bypass unit, a custom fail-open device available from Symantec specifically for the 7100 Series appliances. Two and four segment copper bypass units are available for the SNS 7120, SNS 7160 and the copper-interfaces of the SNS 7161, and single segment fibre bypass units are available for the fibre interfaces of the SNS 7161. Within a network, multiple SNS nodes can work together across multiple network segments and network locations - this is called a SNS cluster. Attack data is correlated across all SNS nodes in the cluster. By default, the first SNS installation in a cluster is designated to be the primary master node, and all subsequent SNS installations are designated to be slave nodes. Changes made on a master node will propagate automatically to all other nodes in a cluster. All SNS nodes in the cluster can be administered from a single Network Security Console. From this same interface, the system administrator can also view all attack activity being logged by any SNS node in the cluster. One point worth bearing in mind is that, out of the box, SNS is not implemented as a “traditional” three-tier management architecture. Instead, it is designed as a peer-to-peer architecture that provides centralised management and decentralised event storage and analysis. There are several benefits to this approach:
The clustering feature takes care of replicating topology and configuration data throughout the system, whilst viewing alerts and running reports requires the central Network Security Console to retrieve data from multiple sensors each time a query is run (the main disadvantage of a peer-to-peer implementation). Symantec also has a separate three-tier architecture management system which is available at low cost (the user only pays for the CD-ROM and print documentation media - about $30). The main reasons an SNS user would deploy SESA are:
SNS provides the ability use backup SNS nodes to ensure constant coverage in the case of unforeseen failures. The backup node will process the same data, perform the same analysis, and evaluate the same response policies as the dominant SNS node, but it will not execute duplicate responses. If the Master node fails, the next node in the fail over group becomes acting Master, providing continuous event viewing for the Console. Monitoring in this state is read-only, however - to edit policies, apply updates, or make other changes in the cluster, the user must promote the acting Master (or another node in the group) to Master. When the original Master is returned to operation, it will automatically rejoin the cluster as a Slave node. To communicate with the backup nodes, SNS uses a fail over heartbeat protocol which is transported using AES-encrypted, authenticated tunnels. The aim of this section is to verify that the sensor is capable of detecting and blocking exploits when subjected to increasing loads of background traffic up to the maximum bandwidth supported as claimed by the vendor. For each type of background traffic, we also determine the maximum load the IPS can sustain before it begins to drop packets/miss alerts. It is worth noting that devices which demonstrate 100 per cent blocking but less than 100 per cent detection in these tests will be prone to blocking legitimate traffic under similar loads. The SNS 7160 was tested up to 1Gbps, the rated speed of the device when deployed in-line, and performance at almost all levels of our load tests was perfect, with 100 per cent of all attacks being detected and blocked under most load conditions. The one exception was Test 4.2.4 where we determined that there was a limit of 17,000 HTTP connection per second (equating to approximately 850Mbps) meaning the test could not be completed. Beyond this limit, legitimate connections began to fail, but all attack traffic was still blocked successfully. However, we would happily confirm Symantec’s 1Gbps rating for this device under all normal network conditions. Basic latency figures were very good for a device of this type at all traffic loads and with all packet sizes, ranging from 155�s with 250Mbps of 256 byte packets, to 259�s with 1Gbps of 1000 byte packets. Behaviour throughout the tests with no background traffic was very predictable, with minimal increases in latency as traffic levels increased from 250Mbps to 1Gbps across each packet size. Placing the device under a half load of 500Mbps of HTTP traffic, we noted slightly larger increases of 66 per cent with 256 byte packets (155�s to 258�s), 45 per cent with 550 byte packets (184�s to 267�s), and 32 per cent with 1000 byte packets (222�s to 293�s). However, all results remained below the “magic figure” of 300 microseconds, our limit for deploying in-line devices in the core of the network. HTTP response times were also very good, meaning the SNS 7160 could be situated anywhere on a Gigabit network, either internally or at the perimeter. SYN Flood mitigation is a recent addition to this product, and 100Mbps of SYN flood traffic had no significant effect on the SNS 7160. Latency increased by only a few microseconds across all packet sizes (HTTP response times were barely affected), and the SYN Flood was mitigated almost completely. The SNS 7160 performed consistently and completely reliably throughout our tests. Under eight hours of extended attack (comprising millions of exploits mixed with genuine traffic) it continued to block 100 per cent of attack traffic, whilst passing 100 per cent of legitimate traffic. Exposing the sensor interface to ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attack. Please refer to the Testing Methodology section for full details of the methodology used and performance results. We installed one sensor with the latest signature pack, and created a Protection Policy with every attack signature enabled, plus some key audit/information only signatures. Signature recognition (with blocking disabled) was excellent out of the box (95 per cent), and was increased to a perfect 100 per cent after the application of a signature pack update which was provided to us in 48 hours. Blocking performance was identical throughout the tests. We noted a minimum of “noise”, with very few test cases raising multiple alerts for a single exploit, and the accuracy of the exploit descriptions was high. Performance in our “false negative” tests was good out of the box, and there is every indication that the majority of signatures are written for the underlying vulnerability rather than specific exploits. Specific exploit signatures are also included where appropriate, however, to provide more accurate identification for the administrator. A major concern in deploying an IPS is the blocking of legitimate traffic. The SNS 7160’s resistance to false positives was perfect in our tests. The SNS 7160 arrives with a number of default policies configured for different environments and with sensible PASS and BLOCK actions set for appropriate signatures (i.e. where the confidence level of a signature is VERY HIGH then the action will generally be set to BLOCK). Resistance to known evasion techniques was excellent, with the SNS 7160 achieving a clean sweep across the board in all our evasion tests. Fragroute, Whisker, ADMmutate and even RPC record fragging all failed to trick SNS into ignoring valid attacks. Not only were the fragmented and obfuscated attacks blocked successfully, but all but one of them were decoded accurately as well. Out of the box, the SNS 7160 handled 100,000 open connections without tuning. Following a simple tuning operation (a single parameter) the device handled just over 1 million connections (the maximum allowed). Default operation of the device is to age out old connections when the state tables are full or resources are low, and this behaviour is not configurable. Stateless “exploits” are not alerted upon (this is correct behaviour in order to be resistant to Stick and Snot tools) and mid-flows are not blocked by default. It is not possible to configure the device to block mid-flows. Please refer to the Testing Methodology section for full details of the methodology used and performance results. This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis. Installation of the SNS 7160 is very straightforward, mainly thanks to the front-panel LCD screen (although compact flash configuration provides an even simpler method when deploying large numbers of appliances across an organisation). Using this, it is possible to configure the management IP address and port number, time zone, date and time, whether it is a master or slave node, and the relevant passwords. Care needs to be taken over the choice of master or slave node, however, since it is not possible to change this following installation without starting again from scratch (which involves re-applying any patches and updates). The Network Security Console software can be installed on any suitable host (Windows, Macintosh or Linux) with access to the management network, and once it is running it is a simple matter to connect to the device and apply the license. Without a three-tier management system, it is necessary to connect to each master node individually using a separate instance of the Console. However, most organisations will undoubtedly make use of the SNS Cluster capability, in which case the Console is connected to the master node, and all slave nodes are added to the topology allowing policies and alerts to be replicated cluster-wide. Each SNS node is installed without a Protection Policy and thus will not pass network traffic by default (we are assuming throughout this test that the device has been installed in in-line mode and without a bypass unit). Once the Console has access to an SNS node, it is a simple matter to define an in-line pair from the available interfaces and apply one of the default Protection Policies in order to start monitoring traffic. By default, blocking is not enabled. The documentation set for the SNS 7160 is extensive, including:
We found all of the documentation to be very well written and extremely useful. For example, in addition to step-by-step instructions, each section contains detailed information on the reason for, and use of, each of the menu options. This is high quality documentation, and Symantec is to be praised for continuing to offer both hard-copy and electronic versions of most of its manuals. The Java-based Network Security Console contains three main tabs that provide a view of the Devices, Incidents, and Policies:
SNS maintains a network topology database, and the Devices tab is the administrator’s view into that database. This tab displays the current network topology in tree form, and contains objects representing SNS nodes, monitoring interfaces, Smart Agents, routers, network segments, and other aspects of the network. In a large distributed implementation, the population of the network topology tree, if done properly, is probably the most arduous task faced by the SNS administrator. There is no auto-discovery process, and so all the information needs to be entered by hand, and maintained in the same way as new sensors, routers, hubs and subnets are created or relocated. The network can be mapped logically (such as by department) or physically (such as by building or network segment), and it is necessary to include nodes for all devices and device interfaces that SNS should monitor (including external devices and Smart Agents for event aggregation), as well as all those through which SNS should be able to track flows. However, if it is not required to take advantage of some of the more advanced features of SNS, then only the sensor details need to be configured in the topology tree.
The topology database must be populated on a master node, which subsequently synchronises the databases on all other nodes in the cluster to the master’s topology database. This means that even for the largest distributed network, the topology database needs defining in one place only. Types of objects which can be included in the topology database include:
Note that many of these are optional, and only the appliance and interface details are actually required to have the system up and running. At least one in-line pair (or single passive-mode port) needs to be configured for a node before a Protection Policy can be applied. The master node is created by default during the install process - additional nodes can be added as independent single nodes or as slave nodes in a cluster. A slave node is synchronised with a master node within a cluster or group of SNS nodes, whereas a single node behaves like a master node in a cluster of one. Selecting any SNS node in the tree brings up a status display in the right hand pane which exposes one of the most complete sets of statistics we have seen in any GUI. This display includes detailed packet, event and flow statistics on a per-node and even per-process basis, providing a wealth of information which is useful when troubleshooting or tweaking settings for maximum performance. It is also possible to define external sensor nodes - Symantec Decoy Server deception hosts or other Symantec Smart Agents for example - from which SNS can accept and correlate security events. Once the topology database has been populated, the bulk of the configuration work is done. All that is then required is to create Protection and Response Policies and apply them to the configured in-line pairs - this is covered in the following section. As far as configuration goes, there is not much else to do. There are a couple of parameter screens at a node and sensor level which enable the administrator to modify advanced settings such as maximum log size, sensor alert delays (to prevent flooding), and maximum events per incident, but most of the entries here are accompanied by dire warnings about what happens if you modify them and get it wrong. Thus, for an initial deployment these can be safely ignored. However, we do like the way such advanced tuning parameters are exposed in the GUI, and the descriptions for each one are very clear in the potential effect each parameter has on performance, memory usage, and so on. These are also very well documented in the Administration Guide.
Having configured the topology, all the changes are propagated to every slave node in the cluster automatically. Changes only need to be made in one place for them to be available from every administration console in the organisation. There is not much to do in the way of configuring clusters. All that is really required to make two nodes part of a cluster is to allocate the same management port and password to both of them (though each will have a different node ID). The administrator authenticates to the Console using a login name and password, and specifies the IP address and management port of the master node. All other nodes using the same port and password combination are automatically available to be managed from that console. If it is required to manage another cluster, it is necessary to initiate another instance of the console, and log in to a separate master node with a separate management port and set of login credentials. Four different user levels provide varying degrees of access to the Console and SNS configuration data, but it is not possible to restrict access to individual nodes, interfaces or Protection Policies on a per-user basis, something which is becoming a key requirement in an enterprise-level management system. Backup and restore capabilities are provided to allow the administrator to backup entire cluster or individual node configurations to disk or compact flash. These can be restored later to the same cluster/node, or a different one in case of failure. One of the major improvements over early versions of the management console is the support for Protection Policies. There is no way to restrict access to individual Policies or nodes on a per-user basis, however, which is something of an omission. Given sufficient rights, every administrator has access to every policy and can apply those policies to any sensor.
In addition, Response Policies can optionally be created to enhance the existing response actions and customise how the SNS system responds to individual alerts. Any number of Response Rules can be created, each one matching on source, destination, event type and priority. When a response rule matches, an alert is sent to the SNS Administration Console and one of several additional actions can be taken:
Any number of Response Rules can be created, and although each rule can only have one response, the rule base is traversed from top to bottom whenever an alert is raised. This means that multiple rules - triggering multiple responses - can be matched for a single alert. It would be nice, however - and much easier - to allow each rule to have more than one response allocated to it.
In addition to Response Rules, SNS can respond to network traffic according to Flow Alert Rules. These respond to traffic flows that violate defined security policies on monitored networks, and can be configured to notify the administrator when a sensor or router detects flows that match specific criteria. SNS collects data about network flows from various devices, optimising the data to enable response actions such as TrackBack and to notify the administrator about illegal flows. To trace an attack back to the source (or at least to the edges of the administrative domain), SNS uses a component called FlowChaser to retrieve the Netflow data provided by Cisco routers to accomplish flow detection and analysis of the flow. The Cisco Netflow technology is a proprietary source of device information that provides the metering base for a key set of applications including network traffic accounting, usage-based network billing, network planning, network monitoring and data mining capabilities for both service provider and enterprise customers. SNS’ FlowChaser uses the Netflow data to provide TrackBack with additional traffic shape information that is analysed to quickly determine the ingress point of a DDoS attack within the network infrastructure. Out of the box, Symantec provides a number of default Protection Policies which are split into “detection only” and “prevention” policies. Prevention policies have a subset of the signatures configured to block traffic, whilst detection policies perform no blocking. A number of policies are provided in each category, each tuned for a different deployment location (DMZ, for example) or for different level of threat (Web server, worm protection, all exploits, exploits and audits, and so on). Although the default Protection Policies can be applied as they stand, many administrators will be more comfortable creating their own. It is not possible to change the default policies, but any one of them can be cloned as a starting point for a custom policy, making it easy to be up and running quickly.
Policy editing is very straightforward thanks to the advanced search tab, which presents an extensive set of search criteria in the top half of the window, and the results of the search in the lower half. Search criteria include:
Any number of these can be selected together, providing the means to select a very precise subset of the available signatures. The results are available in the lower half of the screen (a summary of the number selected out of the total available is displayed above this) and it is possible to select all of the results for bulk editing operations such as setting all to block, or log, in a single operation. It is also possible to set the same annotation for a group of signatures which would make it simple to re-select the same group at a later date, since it is possible to search on just the annotation.
A right-click on any signature provides instant access to the log/block configuration screen, as well as the ability to view the detailed event description. Buttons above the search results provide one-click means to select all and access the log/block configuration screen for the group selected. It is also possible to sort the signatures using any of the columns headers (by Severity, Protocol, or Date Modified, for example) and then use the normal Windows selection keystrokes to select a subset of the signatures displayed. This provides a simple means to select all of those signatures provided in the latest LiveUpdate (via Date Modified), or all of those currently set to Block, or all FTP signatures, and so on. Individual signatures, or groups, can be edited to log all occurrences, or just those which fall within a specified range of source/destination IP addresses an ports. It is also possible to set an aggregation counter, such that for every user-specified number of non-logged events, a single event is logged (ideal for those events of which the administrator thinks he may see an excessively large number). Every signature can have a custom annotation/note applied to it, which provides a good way for the administrator to document policies (why a specific signature has been disabled, or why it is set to block but not log, for example) or to create custom groups of signatures by virtue of the fact that they all share the same annotation. Finally, it is possible to set events to block or pass traffic. Blocking traffic is the only prevention option configurable at this level, since the Response Rules mentioned earlier handle other responses at a global level. Although the rules provide an extremely flexible and powerful way of defining responses across all signatures, it would be nice to be able to override these on a per-signature basis - perhaps you might want to enable packet capture temporarily for a single signature, for example.
The Block response sends TCP resets to both client and server, in addition to dropping the offending packet and blocking all subsequent packets from the same flow. In the version of software tested, this behaviour was fixed, but as of patch 10 for the SNS 7100, it is possible for administrators to disable the automatic transmissions of resets in both directions upon a blocked event. In addition to the signature selection and search tabs, there are two more available: Notes and Auto-Update Rules. Notes provides a free-format text area to enable the administrator to create documentation at a policy level. Auto Update Rules allows the policy to be updated automatically each time a new set of signatures are acquired. SNS uses the standard Symantec LiveUpdate mechanism (which will be familiar to users of its Anti Virus products) to provide access to new and updated software and signatures automatically. These updates can be downloaded directly from the Symantec servers, or “mirrored” LiveUpdate servers can be created on an internal network to conserve bandwidth when there are multiple appliances installed. Of course, normally it would be necessary to review new signatures and add them to Protection Policies manually, but the Auto-Update Rules provide a means to streamline this process. The administrator can create multiple rules per Policy based on signature Category, Protocol, Severity and Confidence, and where new signatures match those conditions, they will be added to the Policy automatically. A further option allows the new signature to be switched into blocking mode immediately, or activated in logging mode only. Thus, even if the LiveUpdate occurs in the middle of the night, SNS can immediately start logging and/or blocking the matching events. Should the administrator need to check on and review new signatures, it is a simple matter to use the search capabilities in the Policy Editor to sort and search for signatures with a specific Date Modified, but otherwise there is nothing contained within a signature to say with which LiveUpdate it arrived. For many administrators, this mechanism could provide an almost “install and forget” means of maintaining their Protection Policies, and this capability is currently only available from a couple of products in the market. Another nice feature of SNS 7100 is the “One-Click to Prevention” feature. Where a blocking policy is applied to a sensor, it is possible to disable and enable all blocking at the touch of a button. When disabled, the sensor continues to detect events as normal, but will only log alerts and no longer block traffic. Once the administrator is confident in the accuracy of the policy, the blocking capability can be re-enabled instantly.
Any number of user-defined signatures can be created on a per-sensor basis, and there is a very simple Wizard available to help with this process. Signatures created in this manner are called “basic signatures”, and are restricted to matching simple patterns at given offsets within a packet, as well as matching on protocol, source and destination IP address, and port. For more advanced requirements, there is a complete signature writing language available, using complex structures, functions, regular expressions, and so on. These signatures are compiled and imported via the GUI. User-defined signatures are synchronised across clusters so that each node has the title, severity, and definition of the user-defined signature. The signature writing “language” has undergone radical enhancement in recent engine updates, and now provides the capability of creating some extremely advanced signatures. Once the signatures are loaded into the database, they are available for selection in all Policies. Although the SNS Policy Editor does not support the concept of signature groups, all user-defined signatures have the same SNS_GEN prefix to their name, so it is possible to use the search capabilities to search for all signatures starting with SNS_GEN and process them as a group in that way.
Once the Policy has been completed, it is necessary to click on the Apply button to save it. This not only saves the Policy itself, but also automatically applies it to all of the Nodes and Sensors which already have that Policy applied. Unfortunately, there is no way to save the edited Policy under a different name at this point. This means that if the administrator’s original intention was to clone an existing Policy and amend it rather than edit the original, or if he feels that he may have made a mistake and wishes to save under a temporary name while he investigates further, there is no option but to discard the changes (there is a Revert option to do this) and start again. It is possible to make multiple changes to several different Policies, and Apply them all on one single operation. However, when changes to several Policies are made in the same session, it is a shame that there is no on-screen indication of which nodes are awaiting application of changed policies or even which policies have been changed. One other significant shortcoming of the current system is that there is no history/audit capability to be able to track who changed what on which Policy or Node, or monitor the date of last time a policy was applied, by whom, and so on. Rollback capabilities and policy versioning (tracking all versions of a Policy through multiple edits) are also missing from the current version. However, one area which is very strong is the actual deployment of the finished Protection Policies. Selecting any Policy and clicking on the “Set to Interfaces” button brings up the ubiquitous topology tree again with a checkbox against each hierarchical level and each individual node down to the interface level. By clicking one or more of the checkboxes (clicking on one of the upper levels, such as a physical location or department name, causes all the nodes beneath it in the tree to be checked automatically) allows the administrator to apply a policy enterprise wide - or to an individual node - in a single operation.
Once the policies have been applied, the right hand pane of the Protection Policies screen shows the same hierarchical topology tree with a display showing which Protection Policy is currently applied to which interface - very useful. There are two tabs used for monitoring and alert handling in the SNS Console:
The Incidents tab provides the main view on current and previous incidents, both active and idle. Incidents are actually a collection of individual events, grouped together by the SNS correlation engine based on a sophisticated algorithm that takes into account things like event type, event name, source IP, destination IP, and so on. The result is a vastly reduced amount of information for the administrator to sift through in order to determine the most important events to be investigated. Configuration parameters provide the means to tune the weightings given to each of the above criteria in order to customise the way events are correlated to a certain extent, making the correlation feature even more usable. By intelligent use of the weightings, it is possible to have SNS group events together in completely different ways (i.e. all events of a specific name grouped as an incident regardless of source or destination, or all events targeted at a particular host grouped together) or even effectively turn off correlation altogether.
Even though individual event types can be quite different, SNS is reasonably adept at determining which of them are related, and raising the priority and response status depending on how an incident develops. The top level heading of each incident always reflects the highest priority event within that incident. For example, low priority port scans and other reconnaissance probes are usually followed by more invasive probes, and eventually by a serious exploit attempt. SNS will consider port scans as low priority, and - depending on the response policy in place - will usually not alert the administrator directly. As the intruder moves on to more invasive techniques, however, the overall priority of the incident may be raised to a level which causes an e-mail or pager alert to be raised. This correlation is performed across all nodes in a cluster, and this makes SNS one of the more useful products in terms of alert handling. Active incidents are those to which new events are still being added. Incidents to which no new events have been added for a given amount of time are considered idle, so SNS closes them. The display can be filtered to exclude closed events if required, leading to an uncluttered display of data which is of immediate interest. The closed events remain available for further analysis, however, and can be restored to the main display at the click of a mouse button.
The Incidents table allows the administrator to view incidents detected by all SNS nodes or only those detected by a particular SNS node, and it is possible to restrict individual Consoles to viewing events from certain SNS nodes only. Information displayed includes date and time, event type, source, destination, event count, device name, location, marked, node number, node name and current state (active or idle). To keep track of which incidents have been viewed or processed by the administrator, it is possible to select the Mark Incident check box in the Incident Details dialogue (or by right-clicking on an incident). The Marked column of the incident will then display an indicator. Selecting any incident from the Incident Table lists all the events that make up that incident in the bottom half of the Incidents screen. A single line is displayed for each event, consisting of date and time, event type, name, source, destination, severity, confidence, event number (within that incident), device name, interface group, VLAN ID and whether or not it was blocked. Not all of the above fields need be displayed - it is possible to select the columns to be displayed on-screen and, as with incidents, additional filters can quickly and easily be applied to further refine the data displayed. The name of an incident and its severity are determined from the highest priority event within it, and this is a function of the event’s severity and confidence. Severity is a measure of the potential damage that an attack can cause, whilst the confidence indicates the level of certainty that a particular event is actually an attack. If the incident is merely suspicious, or if there is a propensity for false positives, then its assigned reliability level is low. If SNS collects more data on the incident to substantiate its reliability, the reliability is adjusted upward automatically. Double-clicking any individual event brings up the event details dialogue. This repeats all the event details from the list on the first tab, along with a list of the source and destination IP addresses and ports that have been involved in that incident. If flow status collection is enabled on the monitored interfaces, then SNS can also display information about network flows to and from each address. The Advanced tab shows detailed packet content data, whilst the long description shows in-depth exploit info, with cross reference links such as CVE, BugTraq, etc. SNS provides an extremely intuitive means to drill down quickly from high level data to packet contents, allowing an administrator to investigate incident and events in detail and with a high degree of effectiveness.
Another extremely useful event management feature is the ability to annotate incidents and events. Administrators can add multiple comments to incidents and events by clicking the Annotation button in the Incident Details or Event Details dialogue respectively. Each annotation is time stamped and lists the author of the annotation. If there are multiple annotations for an event, they can be sorted by time stamp in ascending or descending order. The Annotation box in the Annotation dialogue displays a default template which prompts for information, such as ticket number, owner and the last action taken in response to the event. Filters can quickly and easily be applied to refine the incident and event data displayed by eliminating (or only displaying) marked events, by eliminating (or only displaying) annotated events, or by eliminating (or only displaying) events from a particular SNS node.
Note that all the event and incident data is actually stored on the individual SNS nodes and is only transferred to the console as required for alerting and reporting. This can make some operations very slow as a console attempts to gather large numbers of incidents and events from multiple SNS nodes across a network. The upside to this approach is that with no single central database there is no single point of failure or single performance bottleneck. Another advantage for those organisations that have round the clock incident monitoring on a “follow the sun” basis (i.e. in different time zones) is that any administrator logging on to a cluster from any console around the global network has instant access to the identical data that was being worked on by all the other administrators before him. All in all, the incident handling capabilities of SNS are very impressive. The ability to handle large quantities of data are vital in a high-bandwidth systems, especially when it is possible to include events from third party sensors, and SNS acquits itself with honours in this area. Summary reporting is well catered for within SNS, with a range of built in graphical and text reports, though it is not possible to customise them in any way (other than to select a date range). For more detailed reporting, data can be exported to a SQL database. Any SNS node can generate daily e-mail reports that contain detailed incident log information for all SNS nodes in the cluster. The report time period is always the last 24 hours leading up to the report generation time.
The e-mail reports include the following information:
Reports generated at the Console consist of data collected from all SNS nodes in the cluster. The data collection is performed as the report is running, and so can be quite slow when large numbers of nodes are involved. Most reports are presented in graphical format initially, with a choice of bar charts, column charts or pie charts. Right-clicking any one of the columns of data on a chart allows the administrator to drill down to the next level. If, for example, the report is Incidents Per Month, right-clicking one of the individual columns drills down to that particular day and presents incidents per hour. Right-clicking on one of the columns on that graph will drill down to the incidents that occurred within that hour, from where it is possible to generate other drill-down reports, such as a Top Event Types report to view the types of events that occurred most frequently during that hour. Eventually, it is possible to drill down to lists of the individual incidents and events (though it is not possible to directly access the individual event details from this point, which is a shame).
This approach makes it very easy to filter out unnecessary data and quickly drill down to the data which is of most interest, providing a more focussed level of detail. All console reports can be printed directly or saved as HTML, PostScript or PDF files if required. Multiple report schedules to be created to run reports - either singly or as groups - at regular intervals. Scheduled reports run directly on any SNS node in a cluster, and the finished reports can be e-mailed to an administrator or secure copied to a report server elsewhere on the network. Regardless of which node is running the reports, SNS gathers data from all nodes to generate a comprehensive cluster-wide report. Reports available include:
Although most top-level report types are also available as drill-down reports within other top-level reports, there are some reports within the Console which are only available as drill-down reports, and not available from a menu. These include:
FlowChaser serves as a data source in coordination with SNS TrackBack, a response mechanism that traces a DoS attack or network flow back to its source. The FlowChaser database can be queried for flows by port and arbitrary address. The Network Security Console displays both current flow data and exported flow data, and provides secondary query options from the results page.
Like the FlowChaser, Query Current Flows, and Query Exported Flows, the Traffic Playback Tool provides another way to search recorded data outside of the SNS reporting system. When a response rule is set to record events of a particular description, the Traffic Playback Tool can then be used to replay and scrutinise the records of those events. The recorded file is in PCAP format, which is easily accessed using commonly available tools such as Ethereal. Performance The SNS 7160 is rated at 1Gbps when deployed in-line, and performance at almost all levels of our tests was very good, with 100 per cent of all attacks being detected and blocked under all but the most extreme (20,000 connections per second) load conditions. Even when pushed beyond its limits (17,000cps), the SNS 7160 continued to block all malicious traffic successfully. We would happily confirm Symantec’s 1Gbps rating for this device under normal network conditions. Basic latency figures were within acceptable limits for a device of this type at all traffic loads and with all packet sizes. Behaviour throughout the tests with no background traffic and with a half load of 500Mbps of HTTP traffic was very predictable, and HTTP response times were also good. All latency results remained below the “magic figure” of 300 microseconds, our limit for deploying in-line devices in the core of the network. This means the SNS 7160 could be situated anywhere on a Gigabit network, either internally or at the perimeter. SYN Flood mitigation is a recent addition to this product, and 100Mbps of SYN flood traffic had no significant effect on the SNS 7160. Latency increased by only a few microseconds across all packet sizes (HTTP response times were barely affected), and the SYN Flood was mitigated almost completely. The SNS 7160 performed consistently and completely reliably throughout our tests. Under eight hours of extended attack (comprising millions of exploits mixed with genuine traffic) it continued to block 100 per cent of attack traffic, whilst passing 100 per cent of legitimate traffic. Exposing the sensor interface to ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attack. Security Effectiveness Signature recognition (with blocking disabled) was excellent out of the box (95 per cent). It was increased to a perfect 100 per cent after the application of a signature pack update which was provided to us within 48 hours. Blocking performance was identical throughout the tests. We noted a minimum of “noise”, with very few test cases raising multiple alerts for a single exploit, and the accuracy of the exploit descriptions was high. Performance in our “false negative” tests was good out of the box, and there is every indication that the majority of signatures are written for the underlying vulnerability rather than specific exploits. Specific exploit signatures are also included where appropriate, however, to provide more accurate identification for the administrator. Signature recognition capabilities have improved considerably since engine update 4 (the version tested was engine update 5) at which point the Symantec signature writing language gained numerous new features allowing the creation of much more complex signatures. It is worth noting that the power of this language is available to administrators when writing custom signatures (though it is a shame that the built-in Symantec signatures are not open to examination) There were no false positives noted during our testing, and resistance to known evasion techniques was perfect, with the SNS 7160 achieving a clean sweep across the board in all our evasion tests. Not only were the fragmented and obfuscated attacks blocked successfully, but all but one of them were decoded accurately as well. Out of the box, the SNS 7160 handled 100,000 open connections, and just over 1 million connections after tuning. Default operation of the device is to age out old connections when the state tables are full or resources are low, and this behaviour is not configurable. It would be nice to see a choice offered to the administrator of whether to age out old connections or block new ones. Usability The Java-based GUI is one of the strong points of the SNS product line, sporting an excellent correlation engine and good reporting and analysis capabilities across multiple sensors. The ability to correlate data from third-party IDS products makes it particularly attractive in larger enterprise deployments. The one area to show the biggest improvement in recent releases is the policy management. Early versions of SNS did not use policies at all, and so it is good to see that not only has the concept of Protection Policies finally been introduced, but that it has been implemented so well. The policy editor was extremely easy to use, and the searching and bulk editing capabilities were excellent. Slight improvement is still required in the areas of version tracking and rollback of policy deployment, but all in all we found policy management to be good. SNS’ greatest strength, however, lies in its incident management capabilities. The tremendous challenge of sorting through volumes of network traffic requires an organisation to more efficiently manage the flow of incident information. SNS' correlation engine combines multiple events from multiple sensors into single incidents, making it much easier to sort genuine alerts from the irrelevant. The recently introduced feature allowing fine-tuning of the correlation mechanism makes this even more useful. The ability to annotate, mark and sort incidents with SNS provides the security specialist with the means to effectively identify specific incidents that have been resolved and remove them from the current “view”. This provides a form of incident “To-Do” list, and clearly indicates incidents that require immediate attention. Annotation capabilities allow an organisation to more thoroughly track the progress of investigation into an incident, even when that investigation is spread across multiple administrators and multiple time zones. These types of features are typical of those companies with a strong IDS pedigree, and not often seen in the newer IPS products. Reporting and analysis are well catered for with a wide range of graphical reports and the ability to drill down from those reports into the more detailed event lists behind them and, eventually, right down to the individual event details. Overall, Symantec is still amongst the leaders in terms of event handling, reporting and analysis. Given the potential volumes of traffic that will be seen on high speed networks, and the resulting volume of alerts that could be generated, the ability to more effectively manage those alerts is essential. SNS has one of the better approaches to this problem, and is worthy of consideration for any large scale IPS/IDS deployment. Company
name: Symantec
Corporation Click
here
to return to the Symantec questionnaire |
Send mail to webmaster
with questions or
|