SIEM value

There's a lot of interesting discussions about the value of SIEM solutions. There's also some discussions about the possibility of doing that with open source, like OSSIM (I personally think it is possible for some organizations - specially those that have the open source culture already).I like to say that SIEMs are for security what ERP systems are for enterprise management. There is a huge value on deploying those systems, but you need to be aware that the implementation process is not easy, it takes time and requires a lot of commitment from the organization. It's not just "pay software, pay hardware, a bunch of consultants, done". Most of the times you need to create or adapt a lot of process to start working with the new tool. You need to understand the data that you will be working with. Just like for ERPs, when you need to have total control over how your books work in order to automate and improve them, you also need to understand how your network and systems work in order to get any value from SIEMs.IDSes suffered a lot when they were deployed without the necessary services and (right) people to manage and operate them. SIEMs are not different on this aspect, and they may be even more sensitive about it, because they rely on receiving data from lots of different sources. If those who are responsible for those sources are not in the same boat as you and are not aware of the value of the tool, they have the power to make that SIEM a nightmare to manage. In order to get some value from SIEMs, you need to be able to get the data from the systems you identify as necessary and keep that data flowing! How many places you know where the biggest SIEM related activity is troubleshooting why the logs are not coming? If you cannot feed the beast, it won't fly.

Looking at things through "cloud glasses"

I was happy to see the last posts from Alan Shimel about the incident on LxLabs and what that means to "cloud security". Not only because I think he is right about using it as an example of why we should think about cloud security but also because I like his "anti-hype" posture. Ok, that specific incident may be related only to one of the several aspects that define "the cloud" (according to Hoff, "multi-tenancy" - and the implications are mostly to "public Cloud providers"), but that doesn't mean that it there is no implications on cloud security discussions. And I'll try to go even further on this analysis.

If you look at the incident characteristics it's easy to relate that only to multy-tenancy environments, but this can also be seen as a sign of higher impacts (and rewards to attackers) when leveraging components to multiple users, users being not only multiple organizations but also multiple applications, guest OSes, networks or anything else that can share a common resource base. Sharing an (elastic, on demand, whatever) common resource base is probably one of they concepts of cloud computing, so yes, we should connect that incident to cloud security. It's not a "one to one" relationship, but it makes sense to look into the causes and effects of that fact under "cloud glasses" (WOW, I've just created a cloud-hype-term!). And that's also why I think that Schneier is not completely wrong when he says that we have been there before. We have been sharing computing resources from some time, let's look into the old stuff without prejudice and see what lessons learned at that time can be applied to the new context. I'm sure we can use a few.

Some interesting aspects that can be highlighted from this incident is how the security dependencies can sharply increase when you start to leverage cloud based services. Suddenly, the security of your data starts to depend not only on the security of the software and hardware that you own, but also on the security of software and hardware of the several service providers that are part of that offering. So, you are using Saas from X? Ok, and they are running their application over PaaS from Y, who operates over IaaS from Z. You are seeing X, but your security now depends on X, Y and Z. How can we do risk assessment for that?  I'm not saying that it's god or bad, just that it has interesting implications about risk management and trust.

Yes Alan, cloud security matters and LxLabs is a very good example to use.

Sueing the auditor? Sure!

The PCI-DSS world has just gone mad this week after Merrick Bank decided to sue Savvis, who gave a clean bill to the well known service provider CardSystems, responsible for a huge breach that lead to thousands of card numbers being stolen.It is an interesting outcome and raises a series of questions about whether it's valid/reasonable to sue an auditor after a breach. Some PCI specialists promptly said it should not happen, as the auditor report is related only to a specific point in time and cannot be taken as a guarantee that nothing will happen on that environment. However, I believe that there are situations that could lead to a lawsuit like that.If the breach happened through something that goes against a PCI requirement and it was there at the time of the audit, it was probably something that should have been identified by the auditors, so they screwed up.- "please show me where I'm screwing up"- "don't worry you are ok, go for it!"...something happens...you've just opened a can of worms!Can you show that it was something that the auditors should have found? Was it there at that time? Have you answered properly all questions?There are other interesting situations - things tested by sampling, incorrect scope definitions, among others.PCI is suffering from the same pain that SOX suffers...but it will be easier to deal with as it is more prescriptive. Auditors now need to be even more careful about their methodologies - are they doing sampling properly? Are they being careful about the definition of the audit scope? Are they properly registering the answers provided by the auditedorganization? That's how they need to work to protect theirselves from being sued by compromised clients. That and raising their prices to build a reserve for eventual legal expenses. One can expect PCI audits to become more expensiveif the trend is confirmed.An interesting outcome is that for companies being audited, this is an additional reason to be completely transparent during a PCI audit. If you have the option to sue the auditor later, you should do everything to ensure that they won't miss anything because of your actions and answers, as this would release them from the liability.Also, another player will become extremely important, the forensics guy. He'll be the one that will have to go through all the evidence from the breach investigation and from the audit process to check whether it's case for a lawsuit.Auditors trying to protect theirselves by being more efficient, audited companies protecting theirselves by being more transparent. Bad auditors paying for their incompetence. Aren't these good reasons to allow those lawsuits to happen?