“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.

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.

It’s common to see on the security standards, frameworks and best practices a lot of “standard” ways of doing things like access control and patch management. The problem is the organizations are extremely different from each other, not only on the technology but also on processes and culture. It’s pretty hard to suggest a standard process that will interact with so many different components and expect it to work (and perform) in the same way for all implementations.

We should try to avoid standardizing diversity and start selling the basic concepts for each of those processes. Usually, the expected outcome. For Access Control, we should state that the process should provide least privilege, segregation of duties and accountability. For Patch Management, reducing the vulnerability window and “exploitability” of systems.

I’m tired of seeing people struggling to fit “best practice processes”  to their organizations (and the other way around) instead of trying to achieve the desirable outcomes. That’s a waste of resources and usually puts security directly against productivity.

When implementing a security process, think about the desired outcome first. You’ll probably find some different ways to get the results, then just get the one that is more aligned to your organization. Remember to document how the new process achieves that, as you probably will not find auditors with this open mind out there. Let they call your process a “compensatory control”, as long as it works and does not make everybody nuts

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.

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 audited
organization? 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 expensive
if 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?

Q: What about the organization that says “but we use authorize.net, PayPal, Google Checkout (or whoever) to process our card payments for items we sell on the web. We don’t ever handle the card data ourselves, so we don’t need to worry about PCI…do we?”

A: Indeed, outsourcing credit card data processing is a very good way of reducing the scope of your PCI compliant environment. However , it is not the same as “outsourcing PCI DSS” since it does not completely shield you from PCI DSS requirements. “Scope reduction” is NOT “PCI elimination.” There are still areas where you must make an effort to comply. However, PCI Qualified Security Assessor (QSA) is the authorized source of this information.

Q: Is a QSA the only authorized entity to run a scan or can I as the owner of our business run the scan myself?

A: This is a pure misconception; 100% false. As per PCI DSS requirement 11.2, an approved scanning vendor (PCI ASV vendor) must be used for external (=Internet-visible) scanning. Internal scanning can be performed by yourself or anybody else skilled in using a vulnerability scanner.

Q: Do we need to ensure that our third party fulfillment company is PCI DSS compliant as well (especially if they are taking credit card numbers for our customers)?

A: It is hard to say how the contracts are written in such case, but often the answer is indeed “yes.” Moreover, if they take credit cards they need to be compliant and protect the data regardless of their relationship with you. PCI QSA is the authorized source of this information.

Q: Is a fax with credit card information that arrives to organization’s fax server considered to be a digital copy of this data?

A: A digital fax containing a credit card number is likely in scope for PCI DSS. There is some debate about the “pre-authorization data”, but protecting credit card information applies to all types of information: print, files, databases, fax, email, logs, etc.

Q: For a small merchant that only processes a handful of transactions a month, are there alternatives to some of the expensive technology requirements (e.g. application firewalls, independent web/db servers, etc)?

A: Outsourcing credit card transactions is likely the right answer in such circumstances.

That was based on CAG. Today I also found about the “Building Security in Maturity Model”, from Garry McGraw, Brian Chess and Sammy Migues.  That’s another very nice set of controls (ok, “activities”, but we can still see them as controls, i.e., something that needs to be deployed in order to mitigate a risk), produced through a very nice approach (putting together the practices from organizations that are doing well). When I was reading the model description the post from Bejtlich immediately came to my mind. There was another nice set of controls, lacking a good set of measurements to ensure it is actually producing the expected result.

Whenever a set of controls  is written, be it “guidelines”, “standards”, or a “model”, it should point to which problem it tries to solve and how one should check if it’s actually happening. That would helps us to have a clear understanding of what works and what does not work on information security. Besides the fact that most of those frameworks/control sets are developed according to a different scope, there’s really no way to measure which ones are more effective.

Honestly, except for compliance requirements, how would you answer an auditor if he asks “why did you choose this specific control framework to develop your security program?”?

SOX brought a lot of money to Information Security, but it also brought some directed focus on some controls that are not always the most required for all organizations. It would be nice to see a review of the law, verifying its results and actual costs.