 |
|
|
SecureWorks, Inc., founded in 1999, is a provider of Managed Internet Security Services to protect corporate networks against attacks. The Security Operations Centre (SOC), as well as the corporate, administrative and technical operation support staff, are housed in a facility located in Atlanta, Georgia. SecureWorks delivers services to defend against, assess, correlate and control Internet threats. The managed services offered by the company eliminate the need for clients to hire and/or train security specialists, staff for around-the-clock operations, or buy capital-intensive hardware and software. The services currently available include Network-Based Intrusion Prevention, Host-Based Intrusion Prevention, Firewall Management, Mail Intrusion Prevention and Vulnerability Assessment. The iSensor 850 tested is a 1U rack mount appliance, based on standard Intel hardware, with a total of six copper Gigabit ports. One port is used on each of the dual port cards to monitor a single in-line connection (or two passively-monitored subnets), and remote management is also performed over the same port pair. The device is rated up to a maximum of 100Mbps. Although the iSensor is only a component of the Network-Based Intrusion Prevention managed service offered by SecureWorks and cannot be purchased separately, it is important to note that this evaluation is focused entirely on the iSensor hardware alone, and does not attempt to evaluate the complete managed service. The iSensor’s blocking rates were adequate out of the box, and improved to 93 per cent following an update. Resistance to all evasion techniques was excellent. Throughput and latency were excellent under all but the most extreme network loads and across all but the smaller packet sizes up to the rated 100Mbps. We would have no problem confirming SecureWorks’ 100Mbps rating for this device under all normal network conditions. We also found the iSensor 850 to be very stable and reliable under extended attack, as well as offering good DDOS mitigation with minimal impact on throughput and latency. Management and configuration of one or more iSensors is taken out of the hands of the end user thanks to the managed service model, as is alert handling, assessment, correlation and report generation. Individual alerts and daily reports are transmitted to the user from the SecureWorks SOC, and a Web-based portal provides instant access to summary reports on-line. SecureWorks is a Managed Security Service Provider (MSSP) providing a Network-Based Intrusion Prevention Service (amongst others). SecureWorks provides this service via the iSensor, a proprietary appliance installed at the customer’s premises. SecureWorks Network Intrusion Prevention Service is composed of the following three components:
The Network Intrusion Prevention Service is provided in one of two service levels, based on time of notification for high severity security incidents. Both service levels include configuration and management, continuous monitoring by the SOC, and client reports that are accessible in real-time via a standard browser interface. SecureWorks services are supported by Service Level Agreements. The Secure Operations Centre (SOC) The iSensor is monitored and managed by the SecureWorks Secure Operations Centre (SOC) on a 24x7x365 basis. All patches and countermeasure updates are applied by SecureWorks with no client interaction required. Attacks blocked by the iSensor generate alerts which are sent to the SOC and reviewed by intelligent backend systems. These systems correlate alerts into incidents that more closely represent intruder activity. Each incident is analysed within a defined service level agreement and a determination is assigned. Determinations can be either attack or informational event classifications. Attacks may be assigned a status of global attack (such as worms or viruses), malicious activity, or immediate action required. Informational incidents may be assigned a status of false positive (in which case a Security Analyst modifies the iSensor), reconnaissance, or benign. Clients have access to a command line interface on the iSensor and a secure Web portal called SecureHub. The command line interface provides configuration functions as well as iSensor management and monitoring functions. SecureHub is hosted in the SecureWorks SOC, and clients login with a username, password, and SecurID token providing two-factor authentication. SecureHub is used to generate and review reports, make basic configuration changes to the iSensor, and manage the escalation process between SecureWorks and the client. The iSensor is designed to operate as a routed gateway (including stateful firewall and NAT) or transparent bridge device, depending on the client’s network topology. The iSensor examines and responds to security threats, while remaining transparent to legitimate network traffic. The integrated Intrusion Prevention System (IPS) enables the iSensor to check traffic continually for a variety of potential intrusions, including port scans, viruses, denial of service (DoS) attacks, Trojan horses, worms, other malware, and protocol and application-based attacks. The IPS monitors for malicious activity via protocol validation, signature matching and statistical traffic analysis techniques. These techniques are continuously and automatically updated as new exploits and vulnerabilities are discovered. The iSensor is composed of four major components:
The iSensor 850 tested is a 1U rack mount appliance, based on standard Intel hardware, with a total of six copper Gigabit ports. One port is used on each of the dual port cards to monitor a single in-line connection (or two passively-monitored subnets), and remote management is also performed over the same port pair. The second port on each card remains unused, as do the built-in Broadcom Gigabit Ethernet ports - this is for performance reasons. The Secure Operations Centre has three redundant Internet connections from three different service providers that each use BGP for failover and load balancing between them. If the Atlanta SOC is not available, the iSensors are configured to send alerts to the hot disaster recovery site. Alerts received by either SOC are replicated to the other every 15 minutes. The iSensor stores alerts in compressed form on the device if it is not able to transmit them to the SOC. Within 15 minutes of a loss of connectivity, a SecureWorks SOC Analyst will contact the client to begin troubleshooting the issue. The capacity reserved for logs on the iSensor is 30GB. If the logs become full, the iSensor will begin removing the oldest alerts first. Alert data is stored on the device in an encrypted form. 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 SecureWorks iSensor 850 was tested up to 100Mbps, the rated speed of the device, and performance under all but the most extreme levels of our load tests was impeccable, with 100 per cent of all attacks being detected and blocked under almost all load conditions. We would happily confirm SecureWorks’ 100Mbps rating for this device under all normal network conditions. The basic latency figures of the SecureWorks iSensor 850 were excellent for a 100Mbps device across the board under almost all traffic loads. They ranged from 98�s with 25Mbps of 256 byte packets, to 188�s with 100Mbps of 1000 byte packets. Behaviour throughout the tests with no background traffic was consistent and predictable, with small increases as additional network load was applied from 25Mbps to 100Mbps with 550 and 100 byte packets (higher latencies were noted with 256 byte packets approaching 100Mbps). Placing the device under a half load of 50Mbps of HTTP traffic increased latency slightly, rising from 96�s to 219�s with 256 byte packets, from 136�s to 226�s with 550 byte packets, and from 188�s to 292�s with 1000 byte packets. HTTP response times were also excellent. SYN Flood protection is implemented for the iSensor, and 10Mbps of SYN flood traffic had no significant effect on the device. Latency increased by only a few microseconds across all packet sizes and HTTP response times were not affected significantly. The iSensor 850 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 99.999 per cent of legitimate traffic (an average of two legitimate sessions out of a total of 300,000 were blocked). Exposing the sensor interface to ISIC-generated traffic had no long-term adverse effect on the device, although communications between the management console and the management server/sensor were intermittent during the attack (the iSensor is managed via the detection interfaces). Please refer to the Testing Methodology section for full details of the methodology used and complete performance results. We installed one iSensor 850 with the latest signature updates, and the default policy as provided by SecureWorks (all exploit signatures are enabled, including server-to-client). Out of the box, signature recognition was acceptable at 72 per cent, and was improved to 93 per cent following the application of a signature update after 48 hours. Blocking performance was identical. Performance in our “false negative” tests was adequate out of the box, and improved slightly following the signature update. However, there were still three misses out of the 14 test cases following the signature update, indicating that there are a number of signatures written for the exploit rather than the underlying vulnerability. A major concern in deploying an IPS is the blocking of legitimate traffic. The device failed three test cases in our false positive test suite, all of which were corrected following the signature update. However, no other false positives were noted during stress testing with either Avalanche traffic or real-world traffic mixes. Following a code update, resistance to known evasion techniques was excellent, with the iSensor 850 achieving a clean sweep across the board in all of our evasion tests. Fragroute and Whisker both failed to deceive the device into ignoring valid attacks, and all of the attempts were decoded accurately. All of the miscellaneous evasion techniques (including extensive RPC record fragging) were handled perfectly too. Out of the box, SecureWorks claims that the iSensor 850 can handle up to 100,000 open connections, which we would deem adequate for a 100Mbps device. During testing, we verified the iSensor’s ability to handle up to 129,000 simultaneously open connections whilst successfully maintaining state on our half-open exploits. The action to take when state tables are full or resources are exhausted is configurable, with three options: drop least recently used (LRU) session, drop new sessions, or drop random sessions (the default). Most IPS devices will age out the oldest session (causing loss of state on half-open exploits) or reject new connections (causing blocking of legitimate traffic). Dropping random sessions may or may not result in loss of state for the half-completed exploit session, and may or may not cause the loss of a legitimate session, but we feel it is an excellent compromise. Stateless “exploits” are never alerted upon, and are always blocked by default. This offers protection against stateless replay tools such as Stick and Snot, and is our preferred configuration for an in-line device. Please refer to the Testing Methodology section for full details of the methodology used and complete 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. Once a client has signed up for the service, the iSensor is shipped via courier. An Install Coordinator serves as the primary contact during this stage, and will schedule two service calls to walk the customer through the process of iSensor installation:
Although it is technically feasible to manage the device via a dedicated management port (there are four ports free on the iSensor), this would require a second, dedicated network connection to the SOC. All of SecureWorks’ customers to date have opted to manage over the detection interface by assigning an IP address to the bridge.
We tested both options during this evaluation, and both worked fine. When using a dedicated management port, full detection capabilities are provided on that port too, meaning that all attacks against the management interface are also logged. Once the iSensor is installed and registered with the SOC, the user has access to a Web-based GUI called SecureHub. Access is via a two-factor authentication system, using user name/password combination plus SecurID token. Users are granted read-only access or admin access via SecureHub. If the user has read-only access, they may not make any changes to the device configuration. If the user has admin access, they are permitted to make changes, limited to changing the IP address for management, default gateway, and firewall settings. It is also possible to create new user accounts, and configure the escalation matrix, which specifies how users are contacted by the SOC when alerts are raised. Each user can have a specific contact type (phone, e-mail, etc.) and schedule, allowing a fine-grained policy, such that one user can be contacted during the day, and another during the night; by phone during the week and by e-mail at weekends; and so on.
Support requests - including changes to a user account or modifications to the devices manages by the SOC - can be submitted via the SecureHub GUI. After clicking “New Incident” link, the user simply specifies the product or service about which they have a request, details the request in the “problem” field, and clicks “Save.” This transmits the request to SecureWorks security analysts over an encrypted connection, automatically verifying the user’s identity and creating a ticket for the specific issue. Progress of support tickets can be tracked in SecureHub via the “Search” link, and clicking on the appropriate ticket number from the list presented. The status of the ticket, as well as a resolution once available, will be displayed on the resulting screen. All policy management is performed by the SecureWorks SOC. No policy configuration is available to the end-user. All alert handling is performed by the SecureWorks SOC. No alert handling capability is available to the end-user. The alerts are first received from the iSensor by special systems inside the SOC. These systems perform an analysis and execute a process to correlate and group alerts into attack patterns. Once the systems identify the attack pattern of which the alerts are a part, the system places the alerts into an incident. The systems then either send the incident to the SOC for further analysis or close the incident so it can be reported to the client.
Incidents are automatically closed if they fit one or more of five criteria:
Security incidents that do not fit into the above scenarios are sent to the Security Analysts’ queue to be reviewed. The Security Analyst selects the oldest incident in the queue and views the support steps, which constitute the history of the incident. The Security Analyst also has the option of viewing the alert details for analytical purposes. The system has a list of client configurations or system usages that illustrate what triggers alerts for the iSensor. The Security Analyst then makes a decision, based on gathering facts throughout the system, to determine if the event is a valid security event (i.e., an actual attack). The Security Analysts gather relevant data, if possible, including the source of the attack and the particular target of the attack. In the event that the actual packets of the attack must be reviewed, the Security Analyst has the ability to access the individual iSensor at the client location through an authorised, encrypted, and monitored session. IPS incidents are reported to the client on a daily basis, via an e-mailed report which links to detailed pages in the SecureHub Web reports. A security incident may also be classified as immediate attention required, in which case the client receives an immediate phone call and an e-mail. A range of summary reports, and lists of top attacks and top services attacked, are available via the SecureHub Web-based GUI. Summary reports are also sent to the user daily via e-mail, and are available for viewing on demand in SecureHub.
SecureWorks clients can either access SecureHub directly via their browser or by clicking on the embedded links in the daily or monthly e-mail report. SecureHub access requires a SecurID token. There are three levels of reporting available on SecureHub.
For each report, the user can enter a date range, and the output can be saved as a PDF or RTF file. Performance The SecureWorks iSensor 850 was tested up to 100Mbps, the rated speed of the device, and performance under all but the most extreme levels of our load tests was impeccable, with 100 per cent of all attacks being detected and blocked under almost all load conditions. We would happily confirm SecureWorks’ 100Mbps rating for this device under all normal network conditions. The basic latency figures of the SecureWorks iSensor 850 were excellent for a 100Mbps device across the board under almost all traffic loads. They ranged from 98�s with 25Mbps of 256 byte packets, to 188�s with 100Mbps of 1000 byte packets. Behaviour throughout the tests with no background traffic was consistent and predictable, with small increases as additional network load was applied from 25Mbps to 100Mbps (higher latencies were noted with 256 byte packets when approaching 100Mbps). Placing the device under a half load of 50Mbps of HTTP traffic increased latency slightly, and overall, HTTP response times were excellent. SYN Flood protection is implemented for the iSensor and worked well in our tests - 10Mbps of SYN flood traffic had no significant effect on the device and mitigation was effective. Latency increased by only a few microseconds across all packet sizes and HTTP response times were not affected significantly. The iSensor 850 performed consistently and completely reliably throughout our tests, blocking 100 per cent of attack traffic whilst passing 99.999 per cent of legitimate traffic, and exposing the sensor interface to ISIC-generated traffic had no long-term adverse effect on the device. Security Effectiveness Out of the box, signature recognition was acceptable at 72 per cent, and was improved to 93 per cent following the application of a signature update after 48 hours. Blocking performance was identical. Bear in mind that, although this device uses Snort-like signatures, the managed service model means that it is not feasible for the end-user to create and install his own custom signatures (though SecureWorks will obviously do this for individual clients). Performance in our “false negative” tests was adequate out of the box, and improved slightly following the signature update. However, there were still three misses out of the 14 test cases following the signature update, indicating that there are a number of signatures written for the exploit rather than the underlying vulnerability. The device failed three test cases in our false positive test suite, all of which were corrected following the signature update. However, no other false positives were noted during stress testing with either Avalanche traffic or real-world traffic mixes. Following a code update, resistance to known evasion techniques was excellent, with the iSensor 850 achieving a clean sweep across the board in all of our evasion tests. Fragroute and Whisker both failed to deceive the device into ignoring valid attacks, and all of the attempts were decoded accurately. All of the miscellaneous evasion techniques (including extensive RPC record fragging) were handled perfectly too, and we were particularly impressed with the Protocol Reconnaissance Pre-Processor which was able to detect all backdoor traffic on any port, at wire speed, without requiring configuration. This same module was also able to detect HTTP exploits on any port without having to define the non-standard HTTP ports to the system, as well as being able to detect non-HTTP exploits on port 80 based on the actual protocol used. During testing, we verified the iSensor’s ability to handle up to 129,000 simultaneously open connections whilst successfully maintaining state on our half-open exploits. This is adequate for a 100Mbps device. Stateless “exploits” are never alerted upon, and are always blocked by default. This offers protection against stateless replay tools such as Stick and Snot, and is our preferred configuration for an in-line device. Usability In terms of installation, configuration, policy definition and alert handling, the iSensor 850 is obviously going to be as straightforward as you can get, since all of those functions are handled via the managed service aspect of the SecureWorks offering. This can be considered restrictive or liberating, depending on your particular view of managed security services. For those who require total control, this approach is obviously not going to feel comfortable. For those who do not have the skills or resources (or inclination) to install and manage their own security devices, a managed security service is ideal. Whilst this report is not intended as a review of the service itself (the aim was to test the iSensor specifically), all aspects of the service to which NSS was exposed throughout the testing appeared to be professional, thorough, and adequate for the required task. Alert handling, correlation and initial investigation is handled by the SecureWorks SOC, and the end-user receives an alert via e-mail (and/or whatever other methods are specified in the alert escalation procedure for each client) which contains sufficient information to keep the client informed. The best part about a managed service like this, of course, is that by the time the alert has been received on the client premises, the danger has already been neutralised. The SecureHUB Web-based GUI is very simple in its appearance and provides a good range of summary reports of incidents and alerts, informational events, top attacks, and top attacked services. Combined with the reports which come out of the SOC on a regular basis, these should be more than adequate. One feature which we have not seen before is the ability to generate change reports and board reports for presentation to senior management and auditors to demonstrate compliance with strict security procedures. Many companies would find these very useful. Company
name: SecureWorks Click here to return to the IPS Index Section |
Send mail to webmaster
with questions or
|
