8 posts from September 2008

 

Tenable Training Program Updates

If you follow the blog, you can see there is a lot going on at Tenable right now, and the training program is no exception. As Brian mentioned in a previous blog entry, our instructor-led classes on Nessus and Tenable Unified Security Monitoring solutions have recently been updated to cover the latest features included in NessusClient 3.2.1 and Security Center 3.4.2 releases.

Based on increasing demand for training during the past quarter, we have refined our course sequence to better meet the needs of enterprise customers that use Security Center, the Passive Vulnerability Scanner, and the Log Correlation Engine – and those that use Nessus to perform vulnerability scans or compliance audits of their own (or their clients’) networks.

As a result, we have split our training offerings into two tracks and moved from three courses to four.

Starting in October, two training sessions will be offered each month. The first session is three days of enterprise training that focus on Unified Security Monitoring and includes vulnerability scanning, configuration auditing, passive network monitoring and log analysis with the Security Center and other Tenable solutions. Later in the month, two days of Nessus training will be offered that cover scanning and configuration auditing using Nessus.

Which track should you choose?

If your organization only works with Nessus, you should sign up for the Nessus classes, and if you operate or make use of any Tenable enterprise products, you should take the enterprise classes.

For more information on Tenable and Nessus product training see http://www.tenablesecurity.com/training/

 

Nessus Virtual Appliance

Tenable Network Security has released a virtual appliance for the Nessus 3 vulnerability scanner. The VMWare appliance is available to ProfessionalFeed and Security Center customers.

The appliance image allows for rapid deployments and effortless management of Nessus 3 scanners in virtual environments. Users do not need to concern themselves with managing an operating system and can focus on managing their scanner configurations, operation and performance.

When installing the image for the first time, a console based user interface displays the IP addresses obtained by a DHCP lease as shown below:


Ipaddrs

A web based user interface can then be used to configure your Nessus scanner, provision users for use with the Nessus Client or Security Center, subscribe it to the ProfessionalFeed, view appliance logs, save/restore appliance configurations and much more. Below is a screen shot of the main configuration interface:


Webgui

Downloads for this appliance image, along with documentation, are available on the Tenable Support Portal to existing ProfessionalFeed and Security Center customers. An unlimited number of virtual Nessus appliances can be provisioned for use with the Security Center. Stand-alone images require a ProfessionalFeed subscription to receive the latest Nessus plugins.

 

Detecting Manually Compiled Network Daemons

Nessus plugin #33851 (Network daemons not managed by the package system) is a credentialed check that audits each of the server processes on the audited Linux system. If the running process is not part of a known system package, the plugin reports that the program is the result of a hand-compiled solution. Below is a screen shot of the plugin detecting a hand compiled httpd program:

Continue reading "Detecting Manually Compiled Network Daemons" »

 

Cyberespionage (Part III of a series)

Hello again!

In my last column, we looked at cyberterror and puzzled aloud about "if it's so horrible, why isn't it happening?" In this episode, we're going to tackle the most straightforward aspect of cyber-badness: espionage. While it's straightforward, it scares me more than any of the other cyber-badness.

This series of columns is based on a set of talks I gave as the keynote for IDC's CEMA Security Roadshow in 2008, with additional material and commentary. As always, I welcome constructive feedback at mjr@tenablesecurity.com.


CyberEspionage

Perhaps the salient point about espionage - all espionage - is that destroying or damaging the target is self-defeating. The effective spy is a parasite; they embed themselves somewhere they can see, hear and collect data unobtrusively. Espionage is a strategic activity, not a tactical one: you want to have your spies in place in deep cover for a long time, so that they can provide strategy-building information during peacetime and carefully selected tactical information during wartime. We're all probably familiar with the famous story of ULTRA during WWII - Churchill had to allow a convoy to fall prey to a U-boat wolf pack because if the convoy changed course the German Naval command might have realized their codes had been compromised. Converting strategic espionage assets into tactical assets almost always increases the chance they will be compromised or the enemy will change their procedures.

Imagine, if you will, a planning meeting between cyberwarriors and cyberspies. It would not go well. The cyberwarrior thumps his fist on the table and announces, "At 2:15am tomorrow, we launch the attack and collapse the enemy's command/control network!" The cyberspy, horrified, rejoins, "If you do that, you'll completely blind half our assets at the most critical moment in the battle. Thanks, you big idiot!"

Historically, armed forces have tactical intelligence-gathering capabilities, as well as strategic intelligence capabilities directed toward likely foes. In the US, the Pentagon has the Defense Intelligence Agency (DIA) which is separate from the former strategic intelligence agency, the Central Intelligence Agency (CIA).(1) This compartmentalization is useful for preventing exactly the kind of problems I'm describing - parallel organizations working at cross-purposes may not be as efficient but it gives security. So, how does cyberespionage fit in? Simple: it's just another form of "espionage as usual." Competent spies will adopt The Internet as a convenient replacement for dead drops and will find it's a lot easier to copy data onto a thumb-drive than to photograph it with a miniature camera - but that's nothing new.

Aldrich Ames, the KGB's mole in the CIA, carried Top Secret data home on floppy disks and CDROMs; does that make him a cyberspy? I don't think that's a worthwhile distinction.

The CyberEspionage Kerfluffle

Recently there has been a great deal of news-play about supposed Chinese cyberespionage "attacks" against US Government agencies and defense-related firms. The entire situation puzzles me greatly, because none of the players involved are acting the way I would expect them to act if they were performing competently. Both the FBI and CIA have had spokespeople make public comments about penetration attempts originating from China - but no credible evidence (other than "the IP address came from over there!") has been presented.

Since the FBI's charter, as a law-enforcement organization and part of The Department of Justice, is to build cases and collect evidence, you'd expect something better than "we could tell you, but then we'd have to kill you" smoke-blowing. Anyone who has worked the computer security field for more than a couple of years knows that claims from federal agencies that are backed by "...but we can't talk about it" are 99.9% likely to be false. If someone actually knows something they "can't talk about" they won't say anything on the topic at all; that's just introductory-level tradecraft. And if someone from law enforcement throws around public accusations without presenting evidence, they're skating on very thin ice, indeed.(2) Worse, in this case, it represents a potential incident between superpowers armed with nuclear weapons - throwing around unsubstantiated accusations amounts to posturing while lives are at stake.

Meanwhile The Chinese do not appear to be acting competently, either, if they are actually involved in what's going on. Surely, the Chinese cyberespionage agency (if one exists) is competent enough to launder their connections through someplace else. In fact, I would think that laundering connections would be the first thing you'd learn in introductory cyberspy school. Since cyberspies aimed at the US would need to read American English fluently, I'd expect their internal chatting would be carried out in the target language, as well. None of this matches the rumors we hear of "Chinese chatter in hacker chat rooms" or "connections from universities in China." Do you really expect that professional cyberspies would use hacker chat rooms or a university connection? It's plausible, but only if you're willing to assume that the Chinese are stupid. I'm not.

Whenever I make these observations publicly, I invariably get Emails from people saying, "yeah, but - if you knew what I know..." And, invariably, they're touting myths that I've heard before.

Just to give you an example: one fairly well-known security practitioner who has fallen for the whole "China cyberspy" story started quoting an anonymous government source to me about how they were uncovering "Blacknet." You've got to laugh - Blacknet(3) was a fictional concept-piece written to illustrate how anonymous remailers and e-currency could be used to build a covert information exchange economy. The Blacknet document was written in the early 1990s and I actually ran across it being taken seriously at a meeting at The White House, when it was handed to me by a highly placed member of US law enforcement that was investigating it. When I explained it was a USENET posting he asked me "What is USENET?" For all I know, the government has a Blacknet task force out there, somewhere, wasting taxpayers' dollars chasing a fiction. Jumping at shadows is what you do when you're dangerously ignorant.

Considering how utterly terrible our federal agencies are with anything to do with computer security, I wouldn't believe anything they said unless it was backed with hard evidence. Right now cyberwarfare/cybersecurity/cyberespionage remains a coveted hot potato in federal circles. A coveted hot potato is one that everybody wants but can't hold. How many federal agencies, today, are vying for the position of coordinating cybersecurity? Everyone wants the budget and the prestige but they are all just empty shells made out of PowerPoint decks and staffed by contractors.

Now, Let's Think

Imagine that we were setting up a cyberespionage capability for a rival superpower. How would we do it if we were professionals? Well, first off, we would recognize that cyberespionage was just a sub-discipline (or a footnote, really) of regular espionage, so we'd simply create a core team of technically savvy operators that existed to facilitate computer-related activity within our espionage agency. In other words, they'd be primarily just another data source that would feed into our analysts. They'd develop bits of custom code as well as useful technologies for our normal field operators. The field operators would be "plain old spies" and they'd target the outsourcing agencies that manage the US Government's IT infrastructure. Since we're talking about a strategic intelligence capability, it would be built over a long period of time, quietly and carefully. The last thing we'd ever do is an amateurish "smash and grab" attempt at some government agency's firewall. Why would we do something that silly, when the firewall administrator works for a contractor and we've got one of our people in the contractor's NOC? Why would we bother wasting the bandwidth to suck files out through the firewall, when the guy who makes the backups works for us? The last thing we'd want to do is rock the boat by having our victim think they were being penetrated by professionals!

I suppose it might be fun to watch the target waste its money and efforts trying to figure out what hijinks the hacker kids are getting up to. Simply by choosing to prosecute severely any hackers going against our government systems (in China, hackers have been sentenced to death) we would be implicitly encouraging them to target their efforts someplace else. Let an army of "useful idiots" keep the target busy and, perhaps they might turn up something useful. The ultimate form of asymmetric warfare is when you have something that costs you nothing but costs your opponents millions and millions of dollars while making them look stupid and feel outclassed.

See what I'm getting at? The public scenarios of cyberespionage are mostly laughable movie scripts. The reality could be much more sobering.

Next, we'll look at cyberwarfare. Of all the threats we're looking at, it's the only one that's just flat-out silly.
Stay tuned,
mjr.




(1) I choose my wording very carefully here. The CIA's failures as a strategic intelligence-gathering force are manifest. If the US had a real strategic intelligence capability, we would not have been conned into believing there was a "missile gap" or surprised by the introduction of Soviet missiles into Cuba. Nor would the collapse of the Soviet Union have been a surprise. Instead of a strategic intelligence capability, the CIA evolved into "the foreign department of dirty tricks" Readers with further interest in this topic should read Mark Reibling's
"Wedge" http://www.amazon.com/Wedge-Secret-War-Between-FBI/dp/0679414711
and Tim Weiner's "Legacy of Ashes"
http://www.amazon.com/Legacy-Ashes-History-Tim-Weiner

(2) The FBI has a long history of smearing its own face with egg by doing this. Wen Ho Lee, Richard Jewell, and Stephen Hatfill, could all tell you. The FBI's announcing Hatfill as a "person of interest" resulted in the taxpayers paying Hatfill $5.8 million in damages. Jewell recovered millions from The FBI and CNN, and Wen Ho Lee's lawsuits will cost the news media and taxpayers millions by the time it's all over.

(3) http://cypherpunks.venona.com/date/1998/01/msg00436.html

 

How to perform a full 65,535 UDP and TCP port scan with just 784 Packets

Nessus has the ability to perform full port scans on UNIX and Windows systems by leveraging credentials. For UNIX systems, the “netstat –an” command is invoked and the results used to mark each reported TCP or UDP port open in the Nessus knowledge base. For Windows systems, WMI is used to identify each open port in a similar manner.

  • For enterprise customers using Nessus or the Security Center to perform audits of systems with credentials, this type of audit saves time and improves accuracy over traditional port scanning methods:
  • Probing a TCP service with a SYN scan or a full TCP connection takes time. Not only does each packet need to be sent, but it also needs to be tracked in case it was filtered, times out or is rejected.
  • Performing UDP scans is very unreliable. By its very nature, a UDP port scan considers a port open if there is no response. Since UDP is unreliable in nature and is often filtered, most UDP port scans return results that are not accurate.
  • Placing large numbers of sequential or random port connections to multiple target hosts can impact the performance of firewalls, NAT devices, switches and many other types of network equipment. Network devices which handle packets often keep a table of active connections and a port scan can make your network look very busy, or take a network that is operating at capacity and make it perform very poorly. In some cases, such devices are licensed per concurrent TCP sessions, and such a port scan might even disrupt other legitimate connections.
  • The lack of port scanning traffic means that your NBAD, network IDS, firewall logs or SIM does not get hundreds or thousands of alerts that need to be filtered.

These credentialed port scans also have some other compliance and performance advantages:

  • Unless someone has placed a rootkit on the OS, this technique will accurately identify all uncommon and high-port listening services. Of course, if an attacker has placed a rootkit, it very likely placed in defenses that make their ports not show up during active scans.
  • If you have a PCI requirement to perform a full port scan of a target, this credentialed technique can also be used. PCI requires that assessments of Internet facing servers be performed without any filtering in place and for all 65,535 ports. Performing a credentialed scan is much quicker than doing a full active port scan.
  • Since these techniques accurately identify all open ports, it is much more likely that Nessus will perform accurate service identification of these ports and discover vulnerabilities on them. Scans that perform their port scan analysis with active methods may not target all available ports due to time constraints.

Launching these Scans and Understanding them

To make use of these scanners, Nessus and Security Center users should simply enable these port scanners in their scan configurations and also include the required credentials to log into the remote systems. Below is a screen shot of the list of available port scanners in the NessusClient:


Scanoptions

Notice that the “Nessus TCP” scanner and the “netstat portscanner (WMI)” were both selected. This would cause a full active TCP port scanner to execute as well as a credentialed WMI scan. There is nothing that prevents a Nessus user from combining these port scans, but there is no additional benefit. A user doing a credentialed audit of a UNIX or Windows system can save a lot of time by only performing the netstat style scans.

Having said that, you should surely consider creating a scan policy that made use of credentiales for Windows and UNIX accounts at the same time. Enabling both the "netstat portscanner (WMI)" and the "Netstat 'scanner'" for UNIX along with the required credentials can rapidly perform full network scans.

Results from these plugins are reported the same way as any other port scanner as shown below:


Rodanopenports

In this case, we used credentials to perform the WMI netstat scan of a Windows 2003 server. The above ports were identified. Running tcpdump during the scan, we gathered only 784 packets (which explains the title of this blog).

Full port scans place many more packets on the network. Even with a simple SYN scan for TCP and a UDP probe, a scanner would send 65535 * 2 = 131070 packets. Even worse, these packet counts can be much higher. For accuracy, a scanner might send the same packet more than once. When looking at full TCP connections or even a SYN scan, there could be 1000s of “reset” packets sent back from the target. With TCP resets and UDP “ICMP Unreachable” messages, it’s not uncommon for packet counts of full port scans to be more than 250,000.

For More Information

If you are concerned with minimizing network impact during active vulnerability scans, you should read our previous blog posts regarding distributed vulnerability scanning.  You should also review topics such as how to invoke the Nessus “safe checks” option,  UDP service enumeration, detecting “off port” services such as web servers not running on port 80 and generally how Nessus performs operating system fingerprinting.

If you are interested in real-time traffic analysis to identify change, new applications, new vulnerabilities and also discover which systems connect to each other and share data, the Passive Vulnerability Scanner can be used along with the Security Center. It feeds discovered data, including real-time identification of open ports, browsed ports and the applications and clients that make use them into the Security Center which combines this information with data from credentialed and un-credentialed Nessus scans.

 

What BIOS does that PCI compliant server have?

Tenable’s research group recently added a Nessus plugin that makes use of a credentialed WMI query to determine the type of BIOS that has been installed on the audited computer. Similar plugins were added to perform the same task on UNIX systems via SSH as well as over SMB. The WMI and SMB plugins reside in the Windows plugin family and the SSH plugin belongs to the General plugin family.

Continue reading "What BIOS does that PCI compliant server have? " »

 

Using Nessus to call Nikto

Earlier this year, Michel Arboi wrote a blog post explaining how to use Nessus to call Nikto and incorporate the results into Nessus output. Most newcomers to Nessus have enabled the nikto.nasl wrapper only to find it produced no output. Some Nessus users have found various ways to ensure Nikto was called correctly and the output displayed. Others chose to run Nikto separately for various reasons. The following guide will explain how to easily configure Nessus to properly call Nikto. This will allow you to save considerable time, especially on scans against a large amount of systems.

Background

Nikto is a small and fast Open Source (GPL) web scanner written by Sullo, based on RFP's LibWhisker. The scanner performs comprehensive tests against web servers for multiple items, including over 3500 potentially dangerous files/CGIs, versions on over 900 servers and version specific problems on over 250 servers.

Configuration

The nikto.nasl plugin can call Nikto directly from Nessus to help automate assessment work. Nessus 3 has been updated to support the release of Nikto 2.03, the current version as of September, 2008. A default installation of Nessus will not automatically call and execute Nikto. During the installation of Nessus, you must make a few configuration changes to the environment so that Nikto is run automatically:

* First, the Nessus daemon must be run on Unix. The nikto.nasl script will not run on Nessus for Windows.
* Download the current version of Nikto. Uncompress and untar the distribution, and move the entire directory to /opt (or another directory of your choice, but subsequent configuration options must be consistent in the use of this directory).
* Note: Nessus does not look for any command name other than "nikto.pl" (as distributed). If Nikto is installed by any distribution-tuned packages that renames this file or uses a wrapper, nikto.nasl will not find it.
* When nessusd is run (i.e. when the plugins are compiled and the daemon started), nikto.pl must be found in the $PATH of the shell that executes nessus (i.e. adding it to root's $PATH may be insufficient). This can be done by editing /etc/profile (or whatever system profile is invoked by shells) and adding /opt/nikto-2.03 to the path.
* The NASL script that calles Nikto is nikto.nasl (Plugin ID 14260, titled "Nikto (NASL wrapper)", in the "CGI Abuses" family) and can be found under /opt/nessus/lib/nessus/plugins.
* From a command shell, run "nikto.pl" from any directory other than /opt/nikto-2.03 to ensure it is in the $PATH and runs correctly.
* Rerun nessusd -R to re-process the plugins, and restart the nessusd daemon gracefully using the init script and "restart" option. (if this does not work, kill the nessusd process and run "nessusd -D")
* If you or your OS distribution create a symlink in a directory such as /usr/local/bin, ensure that /opt/nikto-2.03 is in the $PATH declaration before the directory with the symlink. If not, nessusd will see the first occurrence of nikto.pl and attempt to execute it. In doing so, Nikto will not find the configuration or data files required to properly run. If your Nessus scans attempt to execute Nikto but produce no output, this may be one cause. Either remove the symlink or adjust the $PATH setting.
* Finally, nikto.nasl is disabled by default in the scan policy. To change this under NessusClient3 for example, edit the policy and click on the 'Advanced' tab. In the drop down menu, select "Nikto (NASL wrapper)" and change "Enable Nikto" from 'no' to 'yes'.

Your next Nessus scan should successfully execute Nikto and provide the results in the report.

Common Problems

* If the Nikto wrapper is not seen in the plugin list, it is likely that nikto.pl was not found when the plugins were compiled. Make sure /opt/nikto-2.03 is in $PATH, run "nessusd -R" to recompile the plugins and restart nessusd.
* If the Nikto wrapper is seen, but Nikto does not run (i.e. no output is displayed in the report), it is possible that nessusd did not find nikto.pl when the plugin was launched. If nessusd is started automatically by an init shell script, this script should be edited to add /opt/nikto-2.03 to the $PATH.

Command Summary

To summarize the installation, your configuration sequence should look similar to the following. Lines beginning with # are comments.

# configuration start
cd /opt
# get the Nikto package
wget http://cirt.net/nikto/nikto-current.tar.gz
# uncompress and untar, creating the nikto-2.03 directory
tar xvz nikto-current.tar.gz
# make sure that /opt/nikto-2.03/nikto.pl exists and is executable by running it and verifying it displays usage information
/opt/nikto-2.03/nikto.pl
# ensure the $PATH knows where to find Nikto. to help ensure this works, also edit your system profile to add this path
PATH=/opt/nikto-2.03:$PATH
export PATH
# ensure nikto.nasl is present
ls -l /opt/nessus/lib/nessus/plugins/nikto.nasl
# re-process the plugins
/opt/nessus/sbin/nessusd -R
# restart nessusd gracefully. if this doesn't work, try "killall nessusd; nessusd -D"
/etc/init.d/nessusd restart

The Nikto NASL plugin automatically selects some options such as using SSL support or virtual host name (supported by HTTP/1.1 only). The plugin will not execute Nikto against web servers that do not return a 404 error code on non-existent pages to avoid Nikto output showing thousands of false positives.

 

Event Analysis Training - Advanced Blacklist Analysis

DNS blacklists are publicly accessible lists of IP addresses that have been identified as associated with undesirable Internet behavior, mostly involving the sending of spam e-mails.

Using lists of IP addresses on a blacklist can be an effective way to look for potential security issues in your logs. We've previously blogged about using blacklists with the Log Correlation Engine. In this post, we will examine more of the basic assumptions and principals for analyzing traffic associated with blacklisted IPs.

A Quick Blacklist Review

There are many different free and commercially available lists of "blacklisted" IP addresses. These lists attempt to identify IP addresses that have a reputation for scanning, sending spam email, hosting malware and many other types of undesirable behavior.

The lists differ in how often they are updated,  how many IP addresses are published, the source of the IP addresses and the nature of the activity from the IP. For example, Arbor's Atlas list comes directly from their deployed sensors whereas the SANS Internet Storm Center derives its lists from voluntary user submissions.

Here Today -- Blacklisted Tomorrow

Using blacklists to filter your logs for evidence of connectivity with potentially hostile servers is an effective way to identify potential security issues on your network. However, if a system interacts with an IP address on a blacklist, don't forget to analyze what the IP did before it was blacklisted.

Consider this screen shot from the Log Correlation Engine deployed at a large university:

Heretodayblacklsttommorowpng

This is a 5-day graph of any log matching an IP address that the security administrator identified  after seeing this (sanitized) alert:

Outbound_Blacklist_Communication src – X.X.32.99 dst – X.X.182.175 , following is known about 217.175.182.175 , message - ISC-BlockList , dns_lookup – xxxx.xxxxl.fr

To determine the activities associated with this IP address for all systems (not just the “blacklist” events), the security administrator  summarized all normalized event types for the past 5 days. If you view the graph from left to right you can see that there was a large spike in firewall and connection events. This particular network has Stonegate firewalls and logs not only firewall “deny” events, but also permitted connections. There is also a variety of statistical and never-before-seen events from this IP address.

It is interesting to note that about 3 days in the past (around the middle of the graph of events) is when our first normalized blacklist event occurs. Sometime between 5 days ago and 3 days ago, the IP in question was involved in activities that caused it to be placed on a blacklist. Only after this occurred did we get blacklist correlation events -  prior to that the connections were logged and correlated purely on their own merit.

The point of this type of analysis is to always consider what the blacklisted IP addresses may have been doing prior to being placed on a blacklist.

Analyzing Blacklist Connection Directionality

The most basic form of blacklist correlation is to get a list of IP addresses and then use them as a filter to see if any logs match with the addresses on the list.

If you are analyzing logs from public facing servers and devices, the blacklist correlation will likely tell you that you are being scanned by "known" IP addresses that scan the Internet. Although interesting, this type of activity is not alarming and should be expected.

What is more interesting is to consider the direction of the traffic  in the logs that include blacklisted connections. It may be expected that we would be scanned from a blacklisted IP, but what we would be really concerned about is if one of our servers connected to the blacklisted IP.

Why might one of our systems connect to a known blacklisted IP address? Possibly, it has been compromised and is connecting back for a payload or is part of a command and control botnet.

On the other hand, "connections" can mean many things and some care should be made when looking at these types of correlations. Consider some of these scenarios where the "outbound" connection is a legitimate connection, but that would generate a false alarm:

  • The attacking/scanning blacklisted IP address is actually a compromised DNS server. When this IP makes connections to your mail, web and other types of services that perform DNS lookups, they may in fact send DNS queries back to the blacklisted IP address because it is the DNS server. This might look like the host has been attacked and then compromised.
  • If the blacklisted IP address has been placed on a list because it is a communication channel for a botnet, other legitimate users of this system will look like they are communicating with a hostile IP address. This often happens when a public IP address of an IRC system is blacklisted. When an innocent IRC user connects to this address, a correlation occurs, although there has been no compromise.
  • In some SIMs I've encountered, the normalization of NIDS events and even system logs such as login failures swap the source and destination IP address. This can cause a correlation engine to conclude that an outbound connection has occurred. For example, consider a Snort rule that logged a VNC login failure event. This event has a source IP of the target host and a destination IP of the attacker's system. If a correlation engine were not smart enough to consider the direction of network traffic of this event, it could incorrectly conclude that a system had  made a new connection when in fact it had not.

Considering the network traffic direction of connections which terminate or originate with a blacklisted IP address is exactly what the Log Correlation Engine blacklist.tasl script performs. It considers any network connection event which was logged by a system, application, firewall, netflow or other type of network monitor and then alerts if the IP addresses involved correspond to a blacklisted IP address. Other correlation scripts attempt to see if “blacklist” connections were preceded by an intrusion detection event, or if a system repeatedly attempts to make connections to a blacklisted IP address.

For More Information

The topic of blacklist analysis as well as generic event analysis has been discussed on this blog several times: