by Wim Remes
This blogpost was triggered by something I experienced on the job, and a follow-up discussion I had with a few people. It even became more relevant as I discussed it with more people.
As Security professionals we tend not to believe in compliance. The reason is simple : compliance usually ends up with asking users to tick boxes periodically to stay compliant. Preferably at as low a cost as possible with the least of impact on the business.
Today, I think differently.
First off, you must realize that I don’t live in the United States. I’m European, Belgian if you want to narrow it down even further. The companies I deal with occasionally touch on PCI, and in rare cases SOX. For the majority of companies however, compliance is a choice (ISO, COBIT, SAS-70 and the like). In general there are two things we have to keep in mind and those are our national privacy law – protecting Personal Identifiable Information (PII) – and a collective labor agreement (which is largely based on the aforementioned law) protecting employee privacy. For banking and insurance companies there are additional regulations (largely based on BASEL II). Healthcare largely relies on the privacy law. To many that may sound like a good thing, until you come across a situation where you realize that regulatory requirements would help you to gain a higher level of security. Read on …
As we were reviewing an application that is used to handle PII, we saw some amazing stuff. A user needs to fill in a username and password and then has to select a few parameters for his connection before actually logging in. The parameters indicate where he is working (the site), for which department he will be working, and in what role. Much to our astonishment, the choice of parameters is limited solely based on the username entered (authentication happens at a later stage). Additionally, this application keeps a user cache and a workstation cache (in a database) that ensures that a user doesn’t have to fill in everything the next time he opens the application. Without getting too technical, it was possible to log in with a user using roles and responsibilities that wouldn’t be available under normal circumstances. As we were talking this through, it became clear that the vendor of the application didn’t care about this problem. The reason was obvious – there was no way that we could make him own the problem. It wasn’t his problem.
I’m clearly staying vague about the details of the situation, but in my humble opinion this is a situation where regulatory compliance requirements clearly would have helped a great deal. It would have forced this vendor to take security into consideration in his development lifecycle, and it would probably have even prevented this application from being released as it was. In such cases, compliance actually becomes an enabler for security. Because there are no regulations, the only thing a vendor has to worry about is keeping his cost as low as possible. Any investment in security lowers his margin. At that level, the choices the vendor made are understandable.
As an organisation, I believe you do your utmost to protect the information that is invaluable for you and your customers. As a consultant I do my best to provide top quality services to secure that information. I am convinced that most hardware and software vendors sincerely want to help us with quality products to achieve our goals. When it comes to rules and regulations, I now believe they can keep the “cowboys” in check. And that alone is a major achievement.
0 comments