Chapter 14. Incident Detection: Finding the Other 68%
Midnight on Saturday, January 25, 2003—and something devastating was about to happen across the Internet. Hundreds of thousands of computer systems across the globe in data centers, corporations, and even homes were exposed to the massive attack that would soon be launched. The worm would exploit a known vulnerability in Microsoft SQL Server first reported a full six months earlier on July 24, 2002.
From our point of view at Symantec on that quiet night, analysts at our Security Operations Centers went through their normal routines, analyzing security incidents from hundreds of customers worldwide and looking for signs of cyber attacks. But the quiet shift erupted into a sudden storm, with our analysts’ queues filling with tens of thousands of alerts within minutes. From the analysts’ view, the monitored intrusion detection systems were all concurrently alerting us of an “SQL buffer overflow” as the monitored firewalls were detecting a flood of traffic on port1434/udp.
For organizations allowing port 1434/udp through their firewalls, the worm wreaked havoc within their internal infrastructure within hours, causing denials of service as the worm attempted to propagate. For companies who were blocking port 1434/udp, when Monday morning arrived, many users with MS SQL on their laptops unknowingly carried the worm past the perimeter as they plugged in their computers, allowing the exploit to occur from within.
This was our view of SQL Slammer—a wide-scale exploitation of the Internet through a known vulnerability in Microsoft SQL that almost took down the Internet temporarily.
With 10 years of experience in Managed Security Services at Symantec, we’ve had the opportunity to witness a significant number of security incidents. Slammer, although lethal to IT infrastructures, was fairly straightforward to detect. The vulnerability was known, the exploit was identified, and the worm’s aggressive propagation methodology ensured that every security tripwire would be triggered.
While Slammer was easy to detect, the profiles of many cyber attacks today are much more cunning. Attacks have transformed from compromising systems for notoriety to seeking financial gain through cyber crime, where stealth and anonymity are paramount. As the sophistication and serious intent of attackers increases, they use more subtle attacks that are increasingly difficult to detect—attacks that leave, at most, modest footprints in logfiles and that masquerade as normal traffic.
Without a doubt, the stakes have never been higher for security practitioners to protect their information assets from cyber attacks. It is our contention that many security practitioners are unknowingly operating an incident detection program that can at best identify only 32%[101] of the incidents occurring on their network. This chapter explores some of the limitations of traditional incident detection that inhibit the effectiveness of security monitoring programs, and reviews the use of several technologies and techniques to create a resilient incident detection model—to find the other 68%.
A Common Starting Point
Chapter 13, Beautiful Log Handling, by Anton Chuvakin, describes the challenges associated with managing logs and the importance of using them for investigative, regulatory, and governance purposes. In our chapter, we’ll concentrate on getting the most out of your logs for incident detection. Most practitioners perform incident detection by analyzing logs from technology designed specifically to detect—and in some cases block—cyber attacks. These technologies are known as Intrusion Detection Systems or Intrusion Prevention Systems, which we’ll refer to heretofore as Intrusion Detection and Prevention (IDP) Systems. These technologies compare network activity against patterns that are indicative of exploit attempts or other unauthorized activity. In doing so, IDPs help practitioners by reducing terabytes of potential problems to a small number of real security events that are occurring. This appears to be straightforward, even simple. So what’s the challenge? Let’s examine a few examples that demonstrate some of the inherent limitations of IDPs.
During the SQL Slammer incident, signatures specific to the worm were available within hours of its debut.[102] These signatures were very effective at triggering alerts on packets with a specific pattern of bytes unique to the worm’s propagation, resulting in the detection of infected hosts with high confidence. While this sounds encouraging, during the height of Slammer, most companies were detecting millions of infection attempts from the Internet that offered little value, as most were noise that didn’t actually cause harm to customers.
There are a myriad of incidents occurring on the Internet at any time, but very few require immediate response to mitigate risk to your business. Identifying those few incidents that require specific and timely action is the primary goal of any effective security monitoring program. In the case of the Slammer worm, it was certainly interesting to be aware of the rapid rate of the worm’s infection across the Internet, but this data was not useful in accomplishing the goal of protecting information assets. In this case, the actionable incidents were the ones that alerted system administrators to compromised hosts within their environment that were attempting to propagate to other systems.
An effective technique used for Slammer and countless worms like it to detect actionable incidents is to refocus your detection based on directionality. Here’s the premise: although any network will be attacked frequently, most attempts will be unsuccessful. By looking for hosts within your environment that are initiating outbound attacks and thus require immediate action to resolve, you can very quickly find the compromised systems. This may initially seem counterintuitive. Wouldn’t a better approach be to identify inbound attacks and prevent the compromise proactively? In theory, yes—but considering that the timing from attack to compromise in many cases is seconds, anything less than an automated, inline blocking response would leave you in the same situation. Therefore, focusing on outbound incidents enables you to be much more efficient by only having to handle real incidents. While this technique certainly works for worms, it also works against a variety of types of malware and other attacks. To enable monitoring based upon directionality, you could either filter the alerts or reconfigure the signatures to report only on incidents propagating from your network. With a little tuning, a practitioner could turn a chatty signature that triggers on every attempt into one that could detect actionable security incidents with confidence.
There are many other techniques employed by practitioners to tune results from IDP technologies that will enable you to maximize their effectiveness. However, based on our experience, even with the most effective techniques IDPs will at best afford you the ability to spot 32% of the security incidents occurring on your network. While many practitioners believe they are effectively monitoring their environment from threats using IDP technologies, there are other technologies and techniques required to find the other 68% of security incidents.
Improving Detection with Context
An effective technique to improve detection capabilities is to add contextual information that can help validate attacks that otherwise would be disregarded. Let’s look at another incident example from an IDP. If you have a public web server, you can be sure it will be scanned for vulnerabilities daily, if not hourly. Most IDPs have literally thousands of signatures that can detect different attacks. The following are a few Snort signatures that are commonly triggered during a web server attack:
WEB-IIS ISAPI .ida attempt WEB-IIS cmd.exe access WEB-IIS msadcs.dll access
Are these signatures actionable incidents? Maybe. These signatures could be indicative of a failed exploit attempt, but they may also represent a successful compromise of the web server. The problem is that based on these example signatures, a failed attempt and successful compromise may look exactly the same. You need more information to corroborate whether or not the attack was successful. By leveraging directionality, if your web server started to initiate attacks to other hosts on the Internet, the compromise is confirmed. However, if the attacker’s footprints are more subtle, you may need to look for other indications of a successful exploit.
One readily available source of additional context can be found in your firewall or router logs. These technologies commonly record when and how a host connects to another host. For example, a connection from host A to host B on TCP port 80 probably represents host A accessing a web server on host B. In addition, depending on the source of the traffic logs, you may also see bytes transferred in the session, whether the session was accepted or dropped, NAT translations, and other pieces of information.
Knowing exactly what else occurred between the hosts in question is critical to ascertain the nature of the attack and provide evidence of a successful compromise. For example, imagine an attack that is recorded by an IDP and a firewall with the following logs:
The IDP records Host A attacking Host B on TCP port 80 with multiple signatures triggered.
The firewall records this traffic as Host A connecting to Host B on TCP port 80.
The firewall subsequently records Host B connecting back to Host A on TCP port 21 (FTP) to download a toolkit or botnet malcode.
It is unlikely that the IDP device would alert on the third connection, as this traffic would otherwise appear to be commonplace. Yet when it follows the attack, this connection provides high confidence that the attack was in fact successful due to the post-compromise FTP session connecting back to the attacker. Considering that public web servers are attacked constantly, analysts are frequently left guessing whether the attack was successful if presented with just the IDP alerts. The follow-on traffic is a critical part of the attack footprint and can easily turn a perceived false positive or low-priority incident into a confirmed compromise. Simply by adding additional context to the IDP logs, detection rates can improve to approximately 40%.
Improving Coverage with Traffic Analysis
Another significant limitation of IDPs is that they only find what they are programmed to detect. New threats and vulnerabilities are introduced with staggering frequency, often requiring updated signatures to ensure detection. According to Symantec’s Internet Security Threat Report,[103] in the second half of 2007, there were 499,811 new samples of malicious code reported to Symantec, a 567% increase over the second half of 2006. Each of these threats represents a potential gap for some period between release of the threat on the Internet and the availability of a signature to detect its existence. Even with the best of the IDP technologies, the window of exposure can last from hours to weeks in length. Using the W32.Gaobot worm as an example, dozens of variants of the worm were written and released in 2004. What would happen if the exploit used was a variant that the IDP’s signature didn’t match? If you relied solely on your IDPs for detection, you might be blind to the attack.
Instead of looking at individual packets for signatures, what if you analyzed how hosts interact with each other over a period of time? If you could organize the logs in a sufficiently real-time manner, some common attack patterns become apparent. For example, every system infected by Slammer stood out clearly because it attempted to connect to thousands of other hosts on port 1434/udp in a very short period of time. This is aberrant behavior for two reasons: (1) hosts typically don’t attempt to connect to a myriad of other hosts on port 1434/udp, and (2) the port 1434/udp connection attempts were occurring at a staggering pace. By analyzing unique connections to and from hosts that you are protecting over time, it is very possible to identify suspicious traffic independent of known signatures. For example, consider the following situations:
- Not very suspicious
Host A connects to Host B on TCP port 25 (SMTP)
- More suspicious
Host A connects to 1,000 different hosts on TCP port 25 (SMTP)
The first example is rather benign and probably represents a host attempting to connect to a mail server to send mail. The second example, however, could represent two very different events. If Host A is a mail server, then this is probably also benign activity, as it should be expected that a mail server connects to other hosts across the Internet to send email on a regular basis. If Host A is not a mail server, however, then this activity becomes much more suspicious and likely represents malcode using SMTP as an infection vector to self-propagate to other hosts. Let’s look at one more example:
- Additional information
Host A connects to 10 million different hosts on TCP port 25 (SMTP)
Let’s first revisit the scenario where Host A is a mail server. This could represent Host A sending an inordinate volume of legitimate mail. On the other hand, what if, in addition to sending mail for your enterprise, your mail server has been taken over by spammers and begins to send out spam to millions of people around the world? In order to alert on this incident, you would also need to consider the volume of traffic as part of your detection criteria. As each server and every enterprise would have a different level of activity, applying a fixed threshold for expected connections would not be effective.
However, a technique that could work would be to establish a baseline of normal mail activity for Host A over time and also determine its variability. Let’s say that we determine over 30 days that Host A on average establishes 500,000 connections with a standard deviation of 100,000 within a 24-hour window. If during a subsequent 24-hour window we detect that Host A has established one million connections, the statistics would suggest that this volume of connections is far enough from the mean to require further inspection. While this technique is subject to false positives because of the opportunities for atypical volumes of traffic, it should identify incidents that otherwise may be missed. We have found this technique to be effective at detecting misconfigured mail servers that are used by spammers and a variety of DOS attacks.
While IDPs can be very precise with detailed signatures, this very feature may also blind them to other equally valid means of incident detection. In contrast, by examining network traffic for unusual traffic patterns as described above, it is possible to effectively detect attackers based solely on how they interact with other hosts on the network, regardless of any visibility to the actual exploit. How useful is this? Considering that one of the most common actions a malicious payload attempts in the wake of a compromise is to search for other vulnerable hosts, this technique alone can increase the detection rate of attacks within an enterprise to approximately 66%.
Correlating with Watch Lists
Over the past several years, the motives for cyber attacks have shifted from attempts to gain notoriety to an intent to steal confidential information for financial gain. With the goals of preserving their anonymity and infecting a large number of systems to do their bidding, the hackers have created networks of systems infected with malware called bot networks, or botnets. A single botnet consists of hundreds, thousands, or even tens of thousands of computers across the Internet belonging to unsuspecting home users and corporations that have been clandestinely taken over, typically through exploiting client-side vulnerabilities when visiting infected websites. Each computer taken over is called a bot, or “zombie,” and they are each programmed to contact one or several IP addresses of “mothership” systems, known as the bot command and control servers, for follow-on commands over a unique communications channel. The instructions could be as simple as searching the infected host for credit card information or as complicated as concurrently launching a distributed denial of service attack against a target web server.
Bot networks are a significant threat on the Internet today: in the last half of 2007, Symantec identified over five million bot-infected hosts connecting to over four thousand bot command and control servers. To emphasize the magnitude of the problem, at Symantec’s Managed Security Services operation, over 50% of actionable incidents that we detect have some evidence of bot infection.
One of the challenges of detecting botnets is that other than the frequent callback communication to the bot command and control server, many infected hosts may not exhibit any other suspicious activity until issued a command days or even months later. While some of the more common, widespread networks of bot-infected hosts are well documented with published signatures available for detection, most are unknown with no detection capabilities in the IDP. Without signatures available, what techniques can be used to detect the infection? Knowledge of the bot command and control server could unmask the actionable incident. Regardless of any other footprint or signature, the mere fact that a host on your network is connecting to a bot command and control server on the Internet should classify it as a system that has probably been compromised.
The same principle holds true for systems on the Internet known to be associated with spam, phishing, port scanning, or any other malicious activity. What if you knew the reputation of the known bad offenders on the Internet? As a managed security services provider, our operation benefits from the visibility into a wide range of malicious attacks. With the ability to flag IP addresses as malicious based upon a single incident, what one of our customers experiences benefits all others. This “neighborhood watch program” for Internet security enables quick identification of offenders. The concept is straightforward, but the implementation is powerful. Simply by alerting on router or firewall traffic denoting connections going to or coming from known bad IP addresses, you should be able to find some of the most dangerous and stealthy pathogens on your network.
Creating and maintaining such a list is neither an easy nor exact activity. Bot command and control servers can be assigned to one system one day and a completely different system the next. A high-risk IP address may in fact also be a victim computer of an unknowing corporate or home user, simply relaying attacks on to the next host. While most practitioners will not have an organic capability to build a comprehensive watch list, such lists are available commercially and in the public domain.[104] Depending on the reliability and timeliness of your intelligence feeds and the source of your traffic logs,[105] you can easily improve your detection rates to approximately 80%.
Improving Perspective with Host Logging
Monitoring an enterprise from network devices—namely routers, firewalls, and IDPs—benefits from a broad vantage point. With good network device coverage, an analyst should be able to monitor most if not all of the hosts in the enterprise. However, in addition to the limitations of network-based analysis described previously, there is one further limitation: the network alerts can’t provide insight into how the systems are affected by an attack. Were accounts created or successfully accessed? Were files changed or downloaded? Did key services fail?
The host can contribute perspective to security incidents by logging from three key technologies: operating systems, server applications, and security technologies. In theory, the concept of leveraging operating system logs sounds important, but unfortunately, these logs by themselves have somewhat limited value. Logging is typically limited and most logs on a system are designed to record a limited set of activities and expected conditions and errors. Considering that most vulnerabilities are explicitly bypassing some control within the operating system, you can reasonably expect it to be logged only partially, or not at all.
In contrast, some server applications, specifically network-based applications such as databases and web servers, tend to log all requests obtained from the network and host alike. They can capture in detail arguments passed and commands executed, and provide a wealth of contextual information that can contribute to an incident’s discovery. The challenge with server applications’ logs tends to be associated with efficiently gathering these logs together from all hosts within an enterprise. Centrally collecting application logs from a large enterprise comprised of different operating systems is challenging and in many cases unfortunately is not a priority.
As in the network, there are also purpose-made security technologies that are specifically designed to protect hosts from malcode and intrusions, and to detect any attempts. The more comprehensive technologies combine anti-virus, personal firewall, anti-spyware, anti-spam, and host IPS capabilities together. Generally, these technologies focus first on prevention and second on detection, so while there is certainly more value in the logs, there are still some limitations on what they will and won’t record during an attack, and there is a wide variance of capabilities between vendors. As most enterprises have anti-virus deployed and many are actively upgrading to a more unified endpoint security solution, there is certainly value in gathering and including these logs in your analysis. Not only do they offer more precision, but they also fill in detection gaps that may exist within your IDP infrastructure due to network placement.
So with this additional host logging, are you going to get to 100%? Probably not, but you are certainly a lot closer than the 32% you were at when we started.
Building a Resilient Detection Model
Even the best security practitioners are prone to the pitfall of relying too heavily on one technology or log source for detecting security incidents. In our experience managing the security for hundreds of the world’s largest companies, we have had countless conversations with security officers. We found many are frustrated that their security monitoring efforts aren’t achieving the desired results, yet their monitoring program is limited to deploying IDP sensors throughout their enterprise. We find that many security teams are missing compromises of their systems due to an incomplete security architecture and are inundated with false positive alerts without the means to highlight the real attacks. As described previously, an approach of monitoring only IDP technologies is certain to yield positive results, but will probably catch only 32% of the incidents. For some companies, finding one third of the security incidents is a risk they are willing to accept based on budgetary limitations or the non-mission-critical nature of their information assets. However, for most organizations, having an incident detection capability to find a very limited number of attacks is not acceptable, especially in segments of their network that contain employee or customer sensitive data.
If the goal of an organization is to truly mitigate the risk associated with cyber attacks, it must broaden its visibility of incidents across the network, and leveraging some or all of the techniques described earlier will provide a solid foundation for incident detection. Each of these techniques will be effective at highlighting some key attack characteristics, such as unexplained traffic volumes, connections to known bad offenders, or obvious signatures denoting a compromise. However, the goal cannot be achieved by utilizing each technique in isolation. By examining a combination of logs from a variety of sources to provide different perspectives on an event, your ability to detect the real incidents increases dramatically. As an example, let’s review the attack indicators associated with the compromise of a host (Figure 14-1).
The indicators shown in the figure are:
The IDP detects exploit attempts from the Internet from known signatures. Since IDP alerts didn’t contain sufficient details to indicate that the attack was successful, this indicator only notes that the attack was attempted.
The firewall recorded reply traffic of an FTP session back to the attacking host. This additional context confirms with high confidence that the first attack was successful.
Logs from the host reveal that the string values to the following registry key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun were added at approximately the same time. This results in the malcode being executed on system startup. As registry key changes are made with great frequency, the timing of the change is critical. A registry change that occurs concurrently with indicators 1 and 2 could suggest that the attack is successful.
The compromised host connects to other systems’ file shares, in an effort to propagate malcode or search for credit card information. These connection attempts are logged by the firewall only. A quick check of the host’s history reveals that this is atypical for the host in question, so this is another high-confidence indicator that the system has been compromised.
Outbound exploit attempts are certainly not expected or typical. This is a third high-confidence indicator that the system has been compromised.
The high port UDP connection to a known bot command and control server is a moderate- to high-confidence indicator that the system has been compromised.
The excessive traffic to an e-commerce site by itself could be benign, depending on the volume of traffic, but when associated with the previous indicators, this likely reveals that the system is participating in a distributed denial of service attack.
Based on the corroboration of these discrete pieces of evidence, there is little doubt that the host is compromised. In this example, we have the benefit of an incident that exhibits suspicious activity when analyzed from a variety of different perspectives, but we don’t always have that advantage. Whereas some attacks will trigger every tripwire placed, some are designed to be stealthy and may only alert us from a single detection technique. What if the exploit leveraged in Figure 14-1 was not detected by the IDP due to unavailable signatures? Indicators 1 and 5 would not have been available. In addition, indicator 2 adds context to the first exploit attempt, so it also would not be present. Even with close to half of the attack footprint missing due to gaps in signatures, there would still be sufficient information to identify and confirm this attack.
By utilizing a broad set of detection techniques, we have created an incident detection model that is highly resilient. In this context, we use resiliency to describe an incident detection model capable of finding the majority of attacks that could be launched against your environment. If one technique fails to detect an attack, there is a high probability that one or several others will. While the concept of resiliency is simple, surprisingly it is a trait often overlooked by many security practitioners as they design their detection capabilities. The danger of not having a resilient incident detection model is that you frequently aren’t aware that you are missing incidents, and you may only discover the gaps in coverage when real damage has been done to your information assets. Here are some real examples of events that have tested the resiliency of the practitioner’s incident detection model:
An attacker targets a host with a new attack or variant that does not match a signature.
A signature is frequently triggering false positives.
Due to a recent network change, the IDP that previously monitored inbound and outbound traffic is now monitoring only outbound traffic.
A network administrator accidentally turns off port spanning, making your IDP blind to all network traffic.
The server used for logging firewall traffic becomes unavailable to the network.
Outbound firewall rules are configured not to log due to performance limitations of the firewall.
Your watch list of known malicious IP addresses is out of date.
All of these potential gaps work against your ability to see the complete picture of the incident. In fact, you should assume that most of the time, you will see only a partial footprint of an attack. The more comprehensive your capability to see different parts of attacker’s footprint, the more likely you are to confirm the incident, even in less optimal circumstances.
In addition to correlating varied detection capabilities together into a single holistic incident, many enterprises also find it useful to enrich the incident with asset information for the affected host. Let’s review an example with a less obvious attack footprint than the previous scenario (see Figure 14-2).
In Figure 14-2, the attack footprint is less clear, as all three indicators could lead us to two very different conclusions: either a host is attempting to propagate malcode or a mail server is operating as expected. Let’s look at each attack indicator in more detail:
The IDP alerted on multiple signatures. Depending on which IDP alerts triggered, it is not uncommon at all for a mail server to trigger a variety of lower-confidence signatures as false positives. For the purpose of this example, let’s assume these signatures were suspicious, but not sufficient to classify as an incident.
This indicator highlights attempted connections by the host to multiple other hosts on port 25/tcp (SMTP). The actual sequencing of destination hosts could be revealing. If the host connects to incrementing IP addresses in order, this is likely malcode searching for other mail servers, as they would not typically connect to other servers in this manner. A mail server attempting to connect to seemingly random IP addresses is nondeterministic, as it could be the result of normal mail operations or malcode that was programmed to connect to hosts randomly rather than sequentially. Hence this indicator could either be very valuable or not at all. Let’s assume it’s attempting to connect randomly, and hence a low-confidence indicator.
The final indicator is the increased traffic on port 25/tcp (SMTP). Also suspicious, but a mail server’s load can vary quite dramatically. Unless the observed traffic is significantly above a normal baseline, it is unlikely that an analyst would classify this as an actionable incident based on this indicator.
In this case, the tipping point is not what the system is doing, but what the system is—namely a database server and not a mail server. What were otherwise low-confidence indicators become a high-confidence compromise when corroborating with asset attributes.
There are a variety of asset attributes that are similarly useful to detect security incidents. Some examples of useful asset attributes are:
- Operating system of the host
Either obtained from a current Configuration Management Database or a recent vulnerability scan. For example, if the server is Unix-based and it is being targeted with Microsoft exploits, there is no chance of successful compromise.
- Vulnerabilities present on the host
For an attack to be successful, the system has to be unpatched for that exploit, and hence vulnerable. Vulnerability information provides good context, but is valuable only if the vulnerability scan has been recently performed, as stale information can lead to spurious conclusions. Additionally, vulnerability scans carry their own false positives and false negatives, which complicate or even mislead your analysis.
- The business or network functions of the host
A network management server will send and receive a great deal of SNMP traffic, and a mail server will communicate on SMTP. This information is critical to understand expected network traffic to reduce false positive rates, but also helps business managers understand systems associated with critical business functions.
- Type of data stored on the host
Depending on whether the host contains credit card information, Social Security numbers, patient health information, intellectual property, or just day-to-day operational files and emails is an important consideration in developing a security architecture and protection strategy. While not critical for incident determination, less critical systems may lower your threshold for further investigation. On the other hand, a compromise of a system that is part of your PCI DSS audit may have enormous implications for regulatory compliance and risk to your clients.
- DHCP lease logs
Most of your attack footprint is going to revolve around an IP address. Most enterprises assign dynamic IP addresses for all but their servers, so responding to an incident affecting 192.168.5.4 may be useless, as the physical host may have renewed a different IP address. Available access to DHCP logs allows you to look up the MAC address, which is unique for every physical network interface.
Each of these attributes adds a new dimension to the incident assessment that can ultimately increase confidence that the incident is in fact actionable. They also provide contextual information about the business functions of the host to allow for a rapid business impact assessment so that an appropriate response can ensue.
Summary
Although IDPs provide the foundation for performing incident detection, they have some inherent limitations that require the use of other technologies and techniques to enable more complete coverage. In this chapter, we learned how important a variety of data sources and perspectives are to improve detection rates. Most importantly, a resilient model for incident detection allows for a broad set of technologies and techniques, so that incidents invisible to one or several detection methodologies will be caught by others. A resilient incident detection model will also ensure that the inevitable failures in one part of your monitoring infrastructure—whether due to human error, application failures, or networking mistakes—will be buffered by other detection capabilities. With the right data sources and detection techniques, you should be able to build a resilient and robust security monitoring program capable of finding the majority of security incidents occurring in your network.
[101] Based on our monitoring of hundreds of enterprises around the world, we examined validated incidents to determine which methods contributed to their detection. Based on our analysis, 32% of the identified incidents resulted from IDP alerts alone.
[102] While Slammer-specific signatures were available from most vendors shortly after the worm’s debut, many IDPs had generic SQL buffer overflow signatures available prior to Slammer’s appearance, enabling early detection.
[103] Symantec’s Internet Security Threat Report, Volume XIII (April 2008).
[104] Examples of public watch lists can be found at http://www.spamhaus.org and http://cbl.abuseat.org/.
[105] Some enterprises opt to disable logging for select outbound traffic, such as HTTP. Obviously, if your enterprise does this, you will be blind to any connections leveraging these ports.