Monday, May 17, 2010

SIEM: The good and the bad - Part I

I work in the computer security industry and one of my specialities is integrating and deploying security products. I have deployed on several occasions and in large environments; proxies, anti-virus, firewalls, SSL VPN, intrusion detection systems, anti-spam and finally Security Information and Event Management (SIEM). The company which I currently work for happens to be the biggest value added reseller in Canada dedicated in IT security and I have noticed an increase interest towards SIEM technology this year. I believe it will be a very popular product for the mid to large enterprise especially in the retailer and heath care market. I believe SIEM's will be as comme as firewalls within 5 years. The usual deal can range from 60k to 1+mil and the driving factors are mostly PCI compliancy and getting hacked - no kidding. So I have decided to write a few posts on the subject.

What is a SIEM:

A SIEM is a software that takes in any type of log over various channels. 95% of the time the channel is the Syslog protocol. Once we are able to gather logs from various sources, we are able to provide automated alerts based on correlation rules. A correlation rule could be; fire brute force attempt alert if you detect 100 failed logins within 5 minutes from the same source IP to any of my sources. Log sources can be any device that can send syslog or generate some kind of log locally which we can acquire via an agent or simply sftp/scp. For example, I have gathered the following logs from various vendors during my deployments.

  • Windows servers
  • *nix servers
  • Database servers (Oracle, DB2 MSSQL)
  • Custom applications
  • Web Server (Apache, IIS)
  • IDP/IPS (Cisco IPS/Intrushield/Snort)
  • Ciscoworks/ACS/IOS
  • Firewalls (ASA, Checkpoint, iptables)
How does it work:

  1. An event comes in the SIEM solution via a channel such as Syslog
  2. An internal parser is used to understand and extract the information from the logs such as the IP addresses, usernames etc.
  3. The event is than normalized - so instead of being a windows event signalling a failed authentication it is simply referred to as failed authentication within the system. So if we also get a failed authentication on a Unix log, it will also be normalized as failed authentication. The normalization process is what allows the system to correlate events between different products.
  4. Once the event is normalized it goes through the correlation rule engine and the correlation engine fires up an alert if it detects a pattern.

Obviously this is a very high level overview of the process but it should give you a good understanding of how correlation is made possible through normalization.

Stay tuned for part II where I will cover the usefulness of correlating flows with events.


Sunday, December 13, 2009

Bluecoat ProxySG webilter bypass vulnerability

During a Bluecoat knowledge transfer session which I was conducting, I was informed on a way to bypass Bluecoat's URL filtering technology. Apparently an employee of my client figured out a way to bypass the web filtering via Google cache by forging the parameters in the url queries.

I have advised Bluecoat and will wait until they release a patch before giving out the details of the hack and give proper credits to the person who found this loop hole. I will also test this vulnerability on other solutions such as Webwasher.

Wednesday, June 24, 2009

Must have hacking tools

I recently installed Ubuntu 9.04 in dual boot on my laptop and I am pleasantly surprised by the stability and speed so far. I've been slowly building my repository of tools and here are my top 10 tool which I installed first:

1. nmap
2. nessus
3. metasploit
4. NetCat
5. Aircrack-ng
6. Wireshark
7. John
8. hping3
9. Scapy
10. Webscarab

I will release a short how-to on each tools shortly.

RFC1918 security issue

This is a good article on the security issues surrounding the use of private IP addressing schemes.

Thursday, March 12, 2009

War Dialing

Metasploit H.D. Moore release a new war dialer tool called WarVox - Check it out at

I have not tested this tool yet but you apparently can dial 10,000 numbers per hour via VOIP.
I remember the good old days when I used my 2400 baud modem to wardial the Montreal region.... :-) good old days indeed.

Tuesday, March 3, 2009

Countering Bell's BitTorrent Shapping

I have found that setting your torrent ports to well known VPN ports such as 1723 and 500 greatly helps in bypassing Bell's Traffic shapping for Bittorent...

Sunday, February 15, 2009

Pen-testing - Usefull or not?

I have read some articles recently about the "worth" of pen-testing in the corporate environment. Some individuals claims that pen-testing is not usefull and should not be relied upon to asses the security of a corporation and that pen-testing will be a thing of the past. 

I think that if conducted properly, a pen-test offers great value to a company. I also think that the customer must also react properly to the pen-test in order for it to have great value.

A pen-test should be used to test policies and procedures to make sure they are in effect or need fine tuning. If your company policy states that all routers and swithces on the network should user SSH for management and a few routers are found to have telnet running during a test, that should indicate that there is an issue in the enforcement of your policy or procedure. If you don't have any security policy are procedures, well... you shouldn't be conducting any pen-test at this time.

Let me give a real life example.

I had a customer who thought had a pretty solid patch management process in his organization. This client made sure that none of their windows servers had exploitable vulnerabilites and patched them every week on Sundays. After 2 days of pen-testing I had gain full control over their network, not only did I hack into their AD and cracked all their passwords, but I also had access to all their routers and switches. It is true that the client had all his windows server OS properly patched, but their patch management was flawed. It was flawed because it only encapsulated the Windows OS, not the services running on them. So even if their windows servers were fully patched, I was still able to exploit a vulnerability located in veritas backup agent. I have also accomplished the same results with other services such as dameware and remote admin. 

This shows the true value of a pen-test. The customer reacted to the pen-test by modifying their patch management process to ensure that it covered all services on the OS. 

Pen-testing should not only be used to patch holes on your network but should also be used to patch policies, procedures and standards within the company.