“Much of the Internet’s infrastructure happens automatically, without human intervention. This means that any encryption keys need to reside in software on the network, making them vulnerable to attack. In many cases, the databases are queried so often that they are simply left in plaintext, because doing otherwise would cause significant performance degradation. Real security in these contexts comes from traditional computer security techniques, not from cryptography.”

Those cases show how frequently controls are implemented in a checklist-based approach, without any attempt to do a threat based assessment first. As Einstein said once, “things should be made as simple as possible, but not any simpler”. Although I am among those that think that PCI DSS is a step in the right direction, there are clear misconceptions that come from the heavy push towards encryption in that standard. Applying the wrong control for a threat is as bad as an inefficient or non-existent control, or even worse, due to the false sense of security, added complexity and cost. I’m sure that checklists can help us with the most basic stuff, but when we start touching things such as database encryption, I don’t believe we can apply a checklist-based approach.

I was reading a post from the “New School of Information Security” blog, which, by the way, is very good. However, there is something from this “new school of thought” that I really have a problem to accept, the idea of measuring the effectiveness of security controls. The post  I was referring to includes an example of new techniques to measure and predict the effectiveness of baseball players.

Take, for instance, an affirmation like ”80 percent of the league couldn’t have made that catch”. Thinking on the nice work from Nassim Taleb, people (and so outfielders) physical attributes are usually only slightly different. Checking the past features from league outfielders should not give you enough information to say something like that, specially considering the interval between the games and the constant training for the athletes. It’s too much conclusion based on past data that don’t have a direct causality relation with the event you are trying to predict.

That is also common on security. With the speed of changes and complexity of IT systems, constant changes of user behaviour due to those new systems (social networks?), it is extremely hard to produce a decent forecast of future events based on past data. Why would all the data about the exploitation of OS and web servers vulnerabilities from the past decade be useful to determine exploitation trends of browser vulnerabilities or XSS on social network websites?

We should be a little more skeptical on our ability to forecast events, specially security incidents. The great “new school” I’m waiting to see rising is how to protect our data without relying on magic numbers and formulas. That would be innovation.

It is, and I’m trying to see how these two different approaches can co-exist. One option, and can see how cool that could become, is to create that big standard as a framework that would allow different implementations of the same process, but all following specifications for inputs and outputs. That would create a big standard with “sub-standard plugins”, suggested implementations for specific processes. Each of those plugins would consider information from those threat modeling components I mentioned before, in a way that you could choose an implementation of a process that is more aligned to your organization profile, technology and characteristics.

That would avoid excessive standardization and also ensure that the basic necessary processes are in place. Now the two posts are not that incompatible anymore and I can go to sleep without that bugging me

Honestly, I remember when I first read that 2006 article from Donn Parker that I was somewhat disapointed by his suggestion of doing things based on compliance. It was the old security sin “checklist based security”. All the recent discussions about PCI DSS are great sources of opinions and insights about the subject, and I’m seeing that there’s an overall perception from the security industry that it end up being good for security. Is the checklist based security working?

If PCI DSS is working, it’s certainly not because of those approaching it with a checklist based mind. It is because it is a quite good prescriptive standard. It is clear about what the organizations need to do. But is has limitations.

PCI DSS has a very clear goal, to protect card and cardholder data. The standard allows a quick and dirty approach for those that don’t want to bother with all those requirements. Reducing scope. Think about all those requirements about wireless networks. You have two choices, doing everything required by the standard or removing that network from the scope. With PCI, as long as you can prove that the cardholder data environment is protected, the rest can be hell, it doesn’t matter, you are good to go. Is it wrong? Well, the standard has a clear goal and it makes sense to define the scope around it, but it is kind of naive on assuming that it’s possible to isolate network environments inside the same organization without considering that the payment process (that uses card data) is usually very close to other core business processes. So, PCI DSS is a good standard but it is limited for overall information security purposes.

With this in mind, one could say that creating a “generic PCI DSS” would be the solution for risk-less security. I think it is part of the solution, for sure. The problem is that the scope for that standard is considerably bigger, in a way that it would have to include some less prescriptive requirements. Is there a way of doing that without creating a new ISO27002? Don’t get me wrong, I think ISO27002 is a great standard, but it is so open to interpretation that it can almost any beast can become a certified ISMS. Also, it has on its base the risk management process, that is exactly what we are trying to avoid. The new standard would have to include requirements to solve one of the biggest challenges on information security: prioritization.

Prioritization is the achilles heel of any attempt of doing security without risk management. After all, everybody knows that we cannot protect everything and during the long implementation phases the bigger pains need to be addressed first. How can we do that without using that wizardry to “guess-timate risks”?

My take is that it should be done based on two sources of information: benchmarking and threat modeling. Threat models can be generated based on geographic aspects, organization and business profiles, technology in use. Threats for banks in the same context (same country, for example) are probably very similar. Organizations using the same basic software package on its workstations will share the same threats for that technology too. We should also consider that a lot of the current threats organizations face are pervasive and ubiquotous, they affect almost any organization out there. Except for very few cases, malware issues are a common problem. Sure, the impact from malware issues will be different for each organization, but it seems to me that those characteristics will probably be those considered for many other threats too.

How would an organization “risk-less” work to define its security strategy and the controls to implement? Most important, how it would check its own security status? Is it ok? Should it spend more? What needs to be improved?

That’s where the fun is. And no, I don’t have those answers. But building the processes and tools to do that is definitely the most cool thing to do on this field.

1. Payment processing company (Heartland) had a breach, leaking thousands of credit card information
2. Heartland’s CEO complains that they went through the regular PCI-DSS audit and the QSA had not pointed out the issues related to the breach
3. Security industry goes mad about his complaints: “compliance is not security”, “compliant at that time doesn’t mean always compliant”, “PCI-DSS is just a set of minimum requirements”, the QSA report is just information based on their own honesty, etc, etc, and finally, “he should know all that”.

I agree with my peers on almost everything that was said on #3, but I’d like to point to some issues here. First, there is a kind of “cognitive dissonance” about PCI-DSS in our industry. It is sold (not by everybody, I must say) to high level executives as the best thing since sliced bread for breach risk reduction, but when something happens we promptly start saying that it is just an initial step in a longer journey, it is composed only of minimum requirements and so on. Think for a while about all the things you heard people saying while briefing executives about PCI-DSS and trying to get a budget to implement the requirements; have they always made clear all the limitations of PCI in terms of risk reduction?

I’m trying to see this episode with my “CEO glasses”. I imagine what I would do if someone would come to me asking for money to implement requirements from a regulation that will do little to reduce my risk; wouldn’t it sound to you that the standard is worthless? Also, I need to hire a company, that was trained by the organization who created the standard, to tell me if I’m in compliance with it. Assuming that I did that with the best intentions, provided my CSO with all necessary resources to stay in compliance and not just be in compliance at the audit time, shouldn’t I assume that if a breach occurs its valid to verify if the breach occurred because of conditions that should have been identified by the auditors? And, in this case, that they share the responsibility?

I’m not necessarily saying that it is right or wrong, just that it seems very reasonable to me that CEOs would follow this line of thought. To be honest, I’m not the only one thinking like this. This post from the New School of Information Security blog goes along the same way.

“[...] I listened to yet another conference presenter complaining about security awareness training. He was talking about the difficulty of getting employees at his company to actually follow his security policies: encrypting data on memory sticks, not sharing passwords, not logging in from untrusted wireless networks. “We have to make people understand the risks,” he said.

[...]

“Fire someone who breaks security procedure, quickly and publicly,” I suggested to the presenter. “That’ll increase security awareness faster than any of your posters or lectures or newsletters.” If the risks are real, people will get it.”

He is totally right about it. Employees perceive very fast the organization posture on its own rules. Everyday decisions are usually based on personal risks, and not on organization related risks. The employee is thinking mostly about the risk to his performance and to his job, not to the company itself. If people starts to be punished for security policy violations, this “personal risk” starts to be considered on decisions like forwarding internal mail to external accounts and sharing passwords.

I had the opportunity to witness the change in people’s behaviour because of changes in management posture before. In one of these cases a group of developers used to share passwords among their group to “keep things running while they are away” and were encouraged by their manager to do so. They immediately changed this behaviour as soon as that manager was publicly reprimanded by his director due to promoting bad security practices and warned that it would be formally punished if identified again.

The other case, at the same organization, was related to prohibited content being accessed on the Internet. We didn’t have content filtering at that time, but by using some simple Perl scripts and Proxy logs I was able to trigger the process of warning managers of abuse from the biggest offenders. The actions taken by those managers (strongly encouraged by higher management) over those warnings triggered a huge change in behaviour from all users, that could be clearly noted in the next month’s logs. People just realized that there was a real risk related to that behaviour, so they changed it. An interest fact about this case was that some users went the other way and started using stuff like proxy websites to avoid the controls. The same mechanism (report of users doing that) that triggered this behaviour was also used to reduce it. Users doing that were punished, and the message that Internet access was being monitored and that attempts to abuse it would be punished was clearly received. 

So, if you want to know what’s the best investment on security awareness: real punishment of violations. Change the employee personal risk/reward equation.

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.