Running time: 10:41

Direct Link: http://eiqcast.podOmatic.com/entry/2009-10-20T13_58_46-07_00

We can thank PCI for that. At least partially. PCI specifically calls out the need for log aggregation and analysis (Requirement 10) and of course, most customers are just looking for something to check the box and make the compliance issues go away. Log management can do that to a point.

But the next tact I take with these end users is to ask whether they have confused compliance with security. Most (when questioned) don’t fall into the trap of thinking that just because they are compliant, that they are secure. But those same folks tend to accept investing just enough to be compliant, and don’t push to actually protect their data.

And that’s why we continue to see high profile data breaches from these organizations that are “compliant.” Remember, being compliant on Tuesday doesn’t matter, if an organization is compromised on Wednesday. There are lots of precedents that say the regulators will determine the organization is not “compliant,” based on the fact that a compromise occurred. Yes, that stinks, but it’s fact. Deal with it.

So given that we can all acknowledge that compliance doesn’t equal security. And most end users do want to be secure. That they need to push beyond just simple log management and move toward security management. And the vendor community has evolved their offerings along those lines as well.

This need for both security and compliance has driven for convergence of previously separate technologies (security information and event management (SIEM) and log management) coming together. And now most vendors have solutions to address both problems. Of course, we can (and do) debate about what integration really means, which we wrote about recently on eIQviews.

The market only recently figured out that SIEM and log management really need to be integrated, but we at eIQ also believe in the near future we’ll see configuration assessment (the definition and enforcement of standard configurations for computing devices) become part of this security and compliance management platform as well. But, eIQ is ahead of the market requirements on that right now, so we’ll need to keep evangelizing the logic of continuing to integrate more functions into a common platform.

To wrap up this piece, just being compliant isn’t enough, and we know most organizations are looking for a combined platform to do both SIEM and log management. Yet, all of these converged solutions continue to use mostly log data for its analysis. As you know, eIQ knows that “log data is not enough” and the next set of posts in this series will talk about 10 reasons why.

Stay tuned.

First is the concept of knowing what you don’t know, and that’s pretty much about finding the data that is protected and/or private and then tracking access and authorizations for that information. Don’t minimize the amount of work involved in this step. Whether you want to call it “data governance” or anything else, this step has killed many a compliance effort, as well as most of the stand-alone DLP market. But that’s another story for another day.

Second he dives into identity management, since that both enables the tracking of who does what, and also provides the ability to turn up or shut down access quickly and in an automated fashion. Since most organizations are pretty dynamic by nature (meaning people come and go, and customers come and go, and pretty much everything else comes and goes at different times), it’s hard to see how any organization can really substantiate compliance if they don’t have some level of automation underlying their identity infrastructure. This is another good topic, but not what caught my eye about this article.

What I want to focus on is his discussion of “state management,” which is basically configuration and vulnerability management. Though I buy into his idea of this being the third aspect of compliance automation, I think from a security operations standpoint – it’s as important (if not more important) to get this nailed PRIOR to large scale identity projects. Yes, this is part religion and part philosophy, but I still get back to the issue that anecdotally a lot more data is lost because of less than secure configurations and the inability to patch against known exploit code, than provisioning or deprovisioning issues.

I know, I know, compliance REQUIRES that you know who is accessing what and when. And that gets back to one of Richard’s points relative to doing what’s right for security vs. being forced to do what will get the auditor off your back.

Requirements like PCI pretty much require both state and identity management, but there is a lot of variability in what that really means. So, again it gets back to doing what’s right for your business, documenting the policies and being prepared and able to defend them when the auditor challenges you.

And they will. So be ready.

Events in 2009 provide further proof that PCI compliance is not enough to secure credit card information, yet PCI compliance is a major driver of technology purchases each and every day.

If the need-to-have products for PCI compliance are not enough for security, what are the nice-to-have products that can make an enterprise far more secure?

In the latest episode of the eIQcast podcast series, Ross Levanto asks eIQnetworks Product Evangelist John Linkous for his thoughts on the question. In the process, they discuss the features and functionality that IT and security teams can investigate as part of PCI compliance projects to greatly enhance the security of their systems.

Running time: 8:59

Direct Link: http://eiqcast.podomatic.com/entry/2009-06-05T07_07_13-07_00

In the latest episode of eIQcast, Host Ross Levanto and eIQnetworks Product Evangelist John Linkous analyze Hathaway’s comments and the industry’s reaction to them. The report Hathaway recently completed and sent to the President has not been made public; it’s expected that many of her recommendations will emphasize the need for ongoing monitoring of networks and security controls, as well as the need for the White House to step up its management of IT security across the entire government.

Editor’s note: This episode was recorded on Friday, May 1, and therefore references the RSA Conference that ended on April 23.

Running time: 10:57

Direct Link: http://eiqcast.podOmatic.com/entry/2009-05-04T08_49_21-07_00

Running time: 9:53

Direct Link: http://eiqcast.podOmatic.com/entry/2009-04-22T07_45_10-07_00

Is that the right goal? Let’s look a bit a history. Have we “won” against traditional crime? No. Have we beaten terrorists? No.

So what makes us think we can beat cyber-crime? Though I’m sure trying will result in a good amount of product sales and even more services. I guess I run the risk of sounding like a broken record, but it’s not about winning. We can’t invest enough and there really isn’t an economic driver to win. We are just trying to NOT be the slowest gazelle in the herd. As long as there is someone slower (meaning an organization more at risk than you), investing incrementally more money to eliminate the last vestiges of risk isn’t worth it.

The banks assign a certain amount of money to cover “shrinkage.”. So do the retailers. It’s not worth the investment for them to totally eliminate fraud. They are trying to keep it at a manageable level. We (for the most part) adopt the same approach, though I’m not sure it’s intentional.

We need to stay focused on the objective of our security efforts. To keep cyber losses to a manageable level, within a reasonable amount of investment. Once we let go of the need to win, we can get back to doing our job. Which is to protect the information of our organizations and make sure business systems remain available.

But regardless of preferred attack vectors and attacker profiles (which organizations have relatively little influence over), the most telling statistic in the entire report relates to implemented security controls (which organizations most definitely do have influence over): 87% of data breaches were considered avoidable through simple or intermediate controls.

So if these controls are so easy to implement, why aren’t organizations doing so?  Information security, to borrow a common turn of phrase, is not rocket science.  Lots of sources out there (such as the Verizon report) give us a good, empirically-based understanding of who’s trying to get at our data, and how they’re doing it.  Organizations need to start getting better at implementing security controls, and especially the kind of low-hanging fruit singled-out by Verizon: monitoring, and especially for attacks over time.  According to the Verizon report, in over 50% of data breaches, the attacker (person or code) wandered around for a period of time between days and months before data was compromised.  And, in almost 50% of data breaches the amount of time it took for organizations to discover the breach of their data was measured in months.

Monitoring is the Achilles heel of most security programs — especially those driven by compliance standards or other mandates – because people tend to view compliance as a point-in-time event, rather than an ongoing process.  That’s not the case.  PCI DSS, SOX, FISMA — they all require covered entities to continuously monitor the security profile of their systems.  Any organization that views PCI DSS (for example) as a checklist exercise is simply begging to be breached.  Moreover, you have to have tools that can correlate data over time.  Low-and-slow attack profiles are intentionally designed to avoid point solutions that look at only one type of data; you need to be able to correlate across multiple types of data, or as we like to say around here, log data is not enough!

Additionally, customers now expect their log management and SIEM capabilities to be “integrated.” Again, eIQ believes this is right on the money. The issue in taking these statements at face value is that the term “integration” is going to be twisted and turned to such a degree, you won’t even be able to recognize it. No one wants to bring a “two headed monster” into the environment.

So let’s lay out a couple of key ideas of what integration really means and then you can ask your favorite vendors to what degree they meet these ideals.

1. Does the vendor make both log management and SIEM technology? – As the SIEM market has evolved, you have vendors from both the SIEM and Log Management spaces converging into the same place. A few have decided to take short cuts and OEM technology to fill the gaps in their offering. So the first question to ask is whether the vendor actually produces both aspects of the solution. An OEM relationship doesn’t lend itself to real integration.
2. Does the SIEM and Log Management functions share a data store? – This is another area that vendors will try to deceive customers. The fact is most vendors in the space offer totally separate products for SIEM and log management. Some use their log management products to address scalability issues with their SIEM. Whatever the reason, if the products use different data stores and hardly even have interface integration, how can they say the solution is integrated?
3. Does the solution go beyond logs? - Log data is great, but it’s not enough. It’s critical to be able to analyze not just logs, but also other data types like configuration, asset, performance, vulnerability and network flow data to figure out what is happening in the IT environment. The vendors can talk about integration all they want, but if they are only looking at logs – then they are looking in the rear view mirror and will not be able to react fast enough to an emerging threat.

You probably aren’t surprised that eIQ can answer all these questions and show REAL INTEGRATION. SecureVue is a single platform, using a single data store for both SIEM and log management. We also do configuration assessment using the same platform and will continue adding functions over time.

The reason we use our own data store is because we couldn’t find one that could meet the needs of both SIEM and log management use cases. It seems other vendors are finding out the same thing and having to use separate data stores to solve the problem.

The two headed monster was kind of cool to see in a horror flick. They also say “two heads are better than one.” Sometimes that’s true, but not in this case. You don’t want to see two heads in your security environment. Clearly customers want integration, just make sure you understand what “integration” really means.