The Security Kitchen

Pete Herzog (the main man behind ISECOM) was so nice to reply to my blogpost related to OSSTMM.
Here’s is his complete answer :

Since you mentioned it….

The development behind the OSSTMM v.3 has been pretty amazing. We got a huge push from the OpenTC project which is funded by the EU and a lot of support from various governments around the world. But all this attention was for a reason- the OSSTMM v.3 needed to fix all the problems from the previous versions and that meant fixing a lot of the problems in the security industry. The worst being “best practices”. This meant that OSSTMM v.3 had to be a new methodology, completely rewritten, with each and every part of the method verified to be true and not just a common or “best” practice. Needless to say it’s a lot of work. But it did bring about some really cool findings about security (remember the OSSTMM just focuses 1/5th of itself on network and data security). Basically, the OSSTMM v.3 has become a collection of security facts in the form of a methodology for security testing and analysis. Some of the improvements and differences are:

- Gone are best practices
- Focus on the proper method for doing a security test and analysis from start to finish
- New modules with a cohesiveness to operational security metrics which measure accurately the attack surface of anything and trust metrics which can help you decide if you have a reason to trust someone or something.
- Self-auditing features with new test types, error types, and a means to qualitatively assure you, as the tester, are able to review problems you encountered while testing and improve yourself.
- Flexibility to apply it to any new technologies or processes.

We’re going strong but we need a better way to communicate this effectively. We’re working on a new website which will have RSS capabilities so hopefully you will see the changes as we upload them.

Thanks Pete ! I’m looking forward to the new release.

A lot has been written on PCI in the light of the recent Heartland breach.  Unfortunately I was still setting up this blog when Heartland happened.

In my (more than) humble opinion the fact that Heartland was breached has nothing at all to do with the company being PCI compliant, but with the perception by its management of the need to secure critical information.  It is clear that this particular company took the following equation as a basis for their risk management :

Information Security Cost <= PCI compliance cost.

By doing that, the company made a critical error.  They needed to be compliant in order to be able to process cardholder data and they made compliance their end goal.

At the same time, I came to realize that a lot of people see a ‘PCI Compliant’ sticker as a statement that their infrastructure is secure.  It isn’t.  It’s basically the same as with any other certification.  Back in the day when ISO 900x was hot, every company made a procedural handbook.  Were procedures used all of the time ? The hell they were.  Every time the yearly review came around, hours were spend on re-learning the basics and special persons were selected and their answers prepared.  Sometimes everybody had to go and review the handbook again.  That is what compliance is about, retaining a quality label.

Basically, PCI in particular is a great effort in risk transferal by the CC industry. You have to commend them for that.

I like PCI, because to me it’s most basic role is raising and enforcing awareness.
Is it the only thing you should do ? No. Security, as we all know, is not a matter of checking boxes on a list. It’s also not a matter of implementing the next best firewall, IPS, SIEM or DLP technology. Security is a process and as such can never be certified, continuous improvement is paramount. Because it matters !

image under standard restrictions from http://www.sxc.hu

Michelle Dickman over at TriGeo has an interesting story .

Apparently her company was in a bid that was eventually won by a competitor ‘High Tower Software’ because they lowballed. The customer took the risk to buy from High Tower and eventually High Tower went out of business in November 08. Good times. There you are with a great (?) product.

There is something you can do against this type of risk and it’s called source code escrow. Basically it is an agreement to have the source code stored at a third party escrow agent which will release the source code when and if the licensor goes out of business. More info here .

Escrow Europe is one of the companies that provides these services in Europe (and in the US too ?). If you know any other companies that do the same, let me know, I’ll add them to the list.

When buying in economically tough times like these or when buying from great startups, it’s an option you have to consider. It’s a risk you can now easily mitigate !