This morning, there was yet another case of phishing that was reported by the New York Times. This phishing incident, Larger Prey Are Targets of Phishing, is interesting because of the victim demographics: executives of large companies. As I just learned, this is also referred to as whaling. We have all seen phishing emails that tried to lure us into logging into our PayPal account. But an email from the United States District Court in San Diego that has a very authentic look is a different story. Would you fall for it?

The best way to address phishing is to educate users to make sure they don’t give out personal information. Have a look at the AntiPhishing Working Group’s phishing checklist that contains a lot of specific tips to prevent successful phishing attacks.

Splunk can addresses a couple of use-cases surrounding phishing attacks:

• Detecting, after the fact, whether someone in your company fell victim to the scam (phishing).
• Protecting your company from being phished. (In today’s story, the United States District Court in San Diego)

Detecting Phishing Victims

Once you know about a phishing attack, you can use Splunk to figure out whether anyone in your company has fallen victim. There are a few ways to do so, depending on the attack vector:

1. The phish infects the victim and installs a trojan that starts leaking information.
2. The phish uses a Web site to collect victims’ personal information (such as credit cards)

Both of these infections will start communicating with the outside. In the case of the phish reported today, the computers started communicating with machines in Singapore. By analyzing the traffic patterns and figuring out where in the world connections are being made to, this infection can be detected very easily. The Splunk reporting is a great way to quickly generate traffic reports and isolate traffic patterns based on geographic locations of the communicating machines. If , for example, your normal access pattern looks like the first graph and then after some time, you get the result of the second picture, where China suddenly shows up at second position, there might be something wrong.

Normal traffic patterns hitting Web site:

Suspicious traffic pattern hitting Web site. Note China on second position:

Protecting Your Company From Being Phished

If you are operating a Web site, you should try to make sure that there is nobody trying to phish it. There are a couple of ways that IT Search can help you with this:

• Monitor your Web server logs for non-complete session requests. A lot of phishers request images from your site, but not the original site itself (the HTML page).
• Monitor Web server logs for sessions that directly send a login, without ever requesting the login page itself. This happens when the victim logged into the phishing site and the credentials are passed to the real site, making everything look normal for the victim.
• Check DNS lookups and see whether you get a lot of lookups from one single machine. This is tricky and you need to know the baseline of lookups, but spikes might turn out interesting to investigate.

Here is a search in Splunk that you can use to determine whether someone posted credentials without ever requesting the login page:

sourcetype=access_comined (login_form.php OR sales.php) | stats count by clientip | search count=1

This assumes you have a page, sales.php, which you can only access once you logged in via the login_form.php. For more complicated Web site architectures, you will have to build a more sophisticated search that uses transactions, but more on that another time.

I have a lot of conversations lately about the topic of IT search versus SIEM (security information and event management), the more traditional way of doing security event management. People are asking me how Splunk’s technology is different from all the log management tools. With ArcSight (my former employer) going public, LogLogic going through some turmoil in their executive management, and Splunk that just got an amazing round of investment, people are very interested in understanding what the deal is.
The topics of SIEM and IT search are fairly similar. However, there are some very important differences that I want to start pointing out in a series of blog posts.

Let me start with the topic of data collection. In an SIEM system, you use a collector, a connector, or an agent (I don’t really care what you call it, but it’s some piece of code which reads the data and feeds it into the system) to process the data before you can use it in your SIEM for correlation, reporting, or forensic purposes. If you do not have a connector specifically written for your data source, you are out of luck. Just to be clear, I am not talking about having a connector for files, for ODBC, for SNMP traps, or for syslog over UDP/514. I am talking about a connector for each specific data source: Snort syslog, Snort database, CheckPoint OPSEC, CheckPoint syslog (do they have a syslog output?), PIX over syslog, CISCO router over syslog, etc.

What this means is that the SIEM has to either already support your data source or you need them to build you a connector; or you build it yourself. Most of the SIEM tools have some sort of an SDK that you can use for this purpose. However, do you have the man power and the skills in-house to do so? If not, does the SIEM company have the bandwidth to build your connector in acceptable time?

What happens, if the source data format changes? For example, Snort might slightly change its syslog format. Guess what has to happen. Yes! The connector needs to be updated to support the new format. This could mean a down-time of your data source of a few days, if you don’t plan accordingly and get an updated connector right away.

No connector - No data

Now, what is the deal in the IT search world? Well, you need some sort of connector as well. However, you only need one to transport the data from the data source into the search system. In other words, you need about a handful of connectors: One for ODBC, one for receiving syslog on UDP/514, one for text-files, and one for databases other than ODBC. (Okay, okay, I will add one for CheckPoint’s OPSEC). That’s it. You don’t need a specific connector for each data source. You also don’t have to update every time the data source decides to slightly change the logging format. [And if you think that never happens, have a look at SiteProtector.]

What does this mean? It means that from day one that you install your IT search technology, you are able to work with your logs. You don’t have to wait until the right connector is available.

So much for now. In my next post I will talk about structured data.