The "RISKY BUSINESS" Blog

In the "old days" (pre-2009)  there was a fundamental decision to make when implementing log management technology.  Do I go log consolidation (LogLogic, LogRythm, Splunk) or do I go Security Information Event Management (Arcsight, NetForensics, Sentinel)?  It really boiled down to whether or not you needed the increased capabilities of SIEM such as  real-time correlation, dynamic real time data normalization, and advanced integration with other core systems including Identity Management, Network Monitoring, Ticketing, CMDB, & Vulnerability/Configuration Management.

The world has changed. We are of the strong opinion that for most F500 class log management implementations it’s no longer SIEM OR Log Consolidator -- its now SIEM AND Log Consolidator.

The reason is simple a growingly insane number of events that need to be captured. As compliance requirements relating to PCI, PII, PHI, et al drive the need for a greater and greater number of events to be captured, one of SIEM’s advantages (having a RDBMS as its back-end) can quickly become a disadvantage.  When data rates start to approach 5,000 events per second (which is definitely reachable in many environments) the challenges/limitations associated with getting data into and out of an RDBMS can become problematic: 

• Few DBAs have experience optimizing databases with these characteristics.
• Database storage requirements (often on a very expensive SAN) can approach a Terabyte per day.
• Recovering from a database issue (e.g., rebuilding a corrupted index) becomes very challenging and time consuming.

Leading vendors such as Arcsight and Novell (Sentinel) recognized this issue and have recently developed Log Consolidators that are intended to work seamlessly with their SIEMs so that you can enjoy a best of breed approach to log management/forensics/compliance.

Leveraging Log Consolidators at the “edge” (e.g., at various business units) simplifies the process of deploying a solution, provides a local searchable event repository, and reduces storage requirements by a factor of 10 (or more).  Only those events that require SIEM capabilities (say 20%) are forwarded to the SIEM in real-time to ensure that full SIEM functionality is retained while eliminating the pain associated with a 5,000 EPS RDBMS).

This approach really allows an organization to end up with the “best of both worlds”.

Had a very interesting conversation with the CISO of a Global 100 the other day. He was very concerned that there were risks that they were not fully cognizant of and was understandably concerned that one of them was going to rear its head and put them in the headlines. So the initial portion of the conversation revolved around the idea of conducting a broader Risk Assessment to ensure that all key risks had been identified.

To ensure the approach was optimum, we delved into "all things security" and I was impressed at the overall level of maturity of the control environment. A Systems Development Lifecycle (SDLC) Methodology was in place and operational and included the integration of key security elements (e.g., Risk Assessment / Security Requirements /S ecurity certification) at the appropriate project phases. As the conversation evolved, we jointly realized that many of the "suspected" and most concerning risks (e.g., privileged user access to databases, source code control, ability to comply with eDiscovery requirements) were symptomatic of a failure of the security requirements definition phase to fully document the requirements relating to monitoring / logging / compliance measurement.

The result is rather than conducting a Risk Assessment, we are going to address the "suspected" risks in a more direct/focused manner while at the same time making the necessary changes at multiple points in the SDLC to ensure that the aforementioned issues are addressed. 

Risk Management is by its nature circular ... so the "real" issue may require that you look at it through the back of the mirror

One of the hotter areas today is the integration of IAM and SIEM. When Identity & Access management (IAM) and Security Information Event Management (SIEM) are optimally integrated, user access compliance monitoring capabilities are increased significantly beyond what either SIEM or IAM can provide alone.

This is because IAM provides a context to user activity event data (e.g., role, entitlements, cross-referencing of multiple user IDs, account status) that can be directly leveraged by the SIEM to identify exceptions in real-time and initiate a workflow to remediate the issue. For example: triggering a suspension of all of a user's IDs and the initiation of a security incident after detecting that an individual attempted to access critical data using multiple user IDs, after access to said data had been terminated.

To this point the challenge has been getting IAM & SIEM to integrate (dynamically share information and allow processes to be remotely initiated). Fortunately, this has become much easier as those vendors that have both an IAM and SIEM offering (Novell, CA, IBM) have included the required integration into both IAM and SIEM on our behalf. I have had the opportunity to see the Novell Sentinel IAM/SIEM integration in action at a client site. It absolutely changes the way you think about security and compliance.

Click here for an excellent Gartner technical brief on the subject.

A network vulnerability scan is essentially a "best effort".  The three predominant challenges to Vulnerability Assessments are;

• The scanner assumes that the host it is interrogating is "trustworthy" (the level of trust is usually adjustable) and bases its assumptions as to the services, versions, and vulnerabilities on the answers it receives. The false positives we are all familiar with are assumptions gone awry.
• The scanner cannot directly assess many important system settings, for example the password policies' complexity setting or the system audit policies event logging settings.
• Packet filtering "devices" in the network path between the scanner and the device (e.g., firewalls, load balancers, routers, network IPs, Host-based IPs) may respond on behalf of the device, providing incorrect data and a false sense of security.

The key benefit to running the vulnerability scan with administrative level credentials is that it allows the scanner to directly assess the system's configuration rather than guess it based on the answers it received.  This not only provides a greater quantity of, and more accurate, information, but it opens up the possibility of using the vulnerability assessment as a compliance check against relevant standards (e.g., PCI, Center for Internet Security, or organization specific).  The last benefit is that a vulnerability  scan with credentials avoids most of the problems encountered with packet filtering devices in the path as the scan is essentially local and authorized.

In a future blog we will look at one of the other unique benefits of running a credentialed scan - running a content scan on the hosts at the same time to determine whether sensitive data (e.g., credit card, medical, identity theft, intellectual property) exists on the systems in violation of policy.

Don’t miss our video, from the Master Assurance Series on Network Vulnerability Assessment: Key Decision Points, to help guide you through this valuable tool in the information security arsenal! Find it and more on our Penetration Testing 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.