The "RISKY BUSINESS" Blog

• STORAGE: SIEM's require a lot of storage when you are reaching 500,000,000 events/day.  The raw data, indexes to speed searching, summary data to facilitate reporting and related meta data can easily drive a requirement for 50 Terra Bytes of storage or more if you need to keep the data around for a year to meet compliance standards (e.g. PCI Data Security Standard).  You also need fast, easily manageable storage, which often means SAN - which definitely means expensive.
• LICENSES: SIEM's also require a number of servers running potentially expensive OS's, databases, and BI/Reporting Tools.   

During a recent engagement the cost to implement the SIEM per the original design got a bit too pricey so we looked for ways to reduce the cost.

1. We limited the online (SAN based) storage from one year to 90 days.  The other 275 days of data will sit on a highly compressed text indexed server that will provide them the ability to run searches on older data the handful of times that it may be necessary.
2. We moved from a Solaris to Linux (which also allowed us to move from Sun to x86 servers).
3. We moved from Oracle to MySQL (with 4  CPU's the cost and maintenance savings were notable).
4. We moved from Crystal Reports to Jasper Reports.

The net was the cost was reduced by several hundred thousand dollars with minimal impact to functionality .... Not too bad for an afternoon's work !

Visit our SIEM page to download additional resources!

SIEM tools, video and more on our SIEM resource page.

This posting is intended for my fellow auditors working in the Fortune 1000 world.

The Yankees are no longer winning the World Series every year, Bill Clinton lives in NY not Washington DC, and Y2K is a laughable memory, not a potential Armageddon. Its 2009, not 1999, so please, please, stop requesting SAS-70 reports from entities that process information on your behalf.

I will begrudgingly give the AICPA some credit for realizing in 1993 that the world needed a standard way to say "How do I know what you are doing due diligence to keep our data secure"? 

However, they encumbered it with 2 basic flaws. 

1. It was a mechanism to document a control environment and its operation, not a standard for the operation of a secure environment.  Sadly, too many of my fellow auditors took it as the latter, not the former, and just checked the box on their paperwork instead of "opining" on whether the documented environment was aligned with their information security requirements.
2. The AICPA, in a very self serving manner, mandated that only a CPA (to be clear -- an accountant) could issue a SAS-70. Apologies to those whom I may offend, but with rare exception, the CPA's turned Information Systems auditors I have met are marginal information systems auditors (at best). 

I believe ISO27001 (though not without a few flaws) is probably the best general purpose form of Information Security attestation available right now.  NIST has some great stuff, especially if you work in the government space.  If the data being processed on your behalf is "mono-compliant" you may be able to get away with the associated standard (e.g., HIPAA, PCI, PII).

Yes, that was "Guns and Roses" you just heard on the radio. However, it was a Classic Rock station, not a Top 40 station (which now plays Pink adnauseam), so please change your "due diligence" paperwork to reflect the year.

It wouldn't be a stretch to say that Windows 2000 and all the Windows Iterations before it were insecure by default and that Windows 2003 and forward are secure by default.  So why is it that Windows 2003 may make your environment more secure while at the same time it makes your environment less trustworthy?

I believe there are two predominant reasons:

1. As we become more confident in Windows security we become less vigilant in our due diligence to validate that Windows is actually operating as intended.
2. Even when we are vigilant, a network penetration test, the defacto "gold standard" for substantiative testing that an environment as a whole is operating is intended is no longer sufficient.

Windows 2003 is significantly more secure by default than Windows 2000, however, it is not immune to less than optimal configuration and vulnerability patch management issues.  Further, there are often other "less important" (and likely less secure) older platforms, network devices, or older applications that may denigrate the security (and trustworthiness) of the environment as a whole.  So Trust the environment, but remain diligent and verify by appropriate activities.

That segues directly to point two, the "appropriate" activities have changed. As an environment becomes more technically secure there is an implicit and incorrect assumption that the probability that it will be "hacked" definitely goes down.  In fact, I would argue that if the attacker is intentioned, that it does not go down at all.  An intentioned attacker will just alter his attack vector to seek the "new" weakest link (e.g., Social Engineering).   There is an old adage that professionals don't hack systems they hack people (think Kevin Mitnick).

So as your environment grows more secure the tests that you use to measure its security/trustworthiness need to change as well. Many of our more risk averse clients are adding social engineering and/or physical penetration testing into their "verify" activities.  Should you?

Our “slidepaper” on Network Vulnerability Assessment: Key Decision Points, will help broaden your knowledge on VAPT. Find this and more on our Penetration Testing resource page.

I'm an unabashed fan of Security Information Event Management (SIEM).  As an Information Security Auditor, any solution that can simplify the process of compliance is alright in my book.  One of the strengths of most modern SIEM solutions is the ability to leverage correlation rules to detect security incidents in near-real time.

The challenge with correlation rules is that in a sense they are "signature based" in that you largely have to know the situation you are trying to detect.  For example, "monitor my five external firewalls and tell me if you see port scans from the same public net block on more than 3 of my firewalls in the same 30 minute period."  

An approach we find far more promising is Anomaly Detection. Its advantage is that it doesn't watch for anything specific, rather it attempts to identify any patterns of security events which are unusual based on previously base lined performance. Interestingly, anomaly detection is based on the meta-data from events -- not the events themselves - although the events themselves can be retereived based on the meta data.

A call last week with a client best illustrates the value of Anomaly Detection.  A client called to tell me that our Anomaly Detection was "wonky, because its telling him about unusual FTP traffic on a server that isn't running FTP anymore".  A quick FTP connection attempt confirmed that FTP was indeed responding on the server and a few more minutes of sleuthing determined that a Windows reboot had restarted the FTP service a few hours prior.  Within an hour a hacker had initiated a brute force admin password attack on the server.  Anomaly Detection noted the unusual FTP pattern (as compared to the previous months baseline) and thwarted the security incident before any impact.

Find a video link and everything SIEM on our resource page!