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

This is a cool idea and will help users that are not aware of the need to update software like Flash and Acrobat Reader. I can also see this as the beginning of a trend to centralize the updating of all the crap we run on the client side. Microsoft (and Mozilla, Apple, Google) already have a very good update system for their software. By opening it to other software vendors via a public API, it could be used as a single source of updates. Adobe, instead of deploying its own update system, could simply publish its updates through Windows update system. To avoid non-authorized updates, the user could be asked for the first time if he wants to allow that organization to update its software through the system, with the identity being verified through digital certificates. That would certainly help users to keep their software updates and to reduce the number of agents checking every time if there are updates to be installed. Please guys, let’s simplify this mess.

In, short, an organization can build its “gold image” desktop, with all necessary apps, and run the automatic rule creator to identify all the applications that will be on the whitelist of things that can run on the desktop. If you are mature enough to have a real good “gold image”, that shouldn’t be very hard to do.

The issue that I can see is with patches and updates. However, the automatic rule creation can work with the Publisher information when the binaries are signed, making it easier to accept new versions for those files. I think I’ll try that in a lab to see how effective that is.

Another interesting thing is that you can enable it in a “Audit only” mode. I have a personal view for whitelist based controls that is deploying them to generate logs only and monitor using a SIEM or similar system. On that way the risk to disrupt the environment is reduced and the exception can be managed on two levels (changing the whitelist, ignoring speficic alerts from the controls). It is one of the best ways to do security without breaking everything and also getting more value from a SIEM deployment. Be aware, however, that the SIEM system alone will not perform any miracles, this concept can only work when you have people and processes in place to deal with the generated alerts and to constantly tune the rules. That’s the price to pay for more flexible security.

I want to make the certification exams offered by (ISC)² more respected on a technical level. While I understand that the exams are not focused on technology — “Security Transcends Technology”, even! — this is not a valid reason for exams that have outdated, misleading, or incorrect material.

I want greater accountability from (ISC)² to its members. This is focused on (but not limited to) exam procedure and feedback. If there is a problem, it should be acknowledged and addressed in a reasonably transparent manner.

I want the purpose and scope of the (ISC)² certifications to be well-defined. The CISSP certification is considered the de facto standard for technical security jobs; if it is not designed to do this, there should be clear guidelines from (ISC)² on where it is appropriate and inappropriate to be gauging the skill and qualifications of a job applicant depending on whether they have the certification.

You can sign his petition at http://sethforisc2board.org/

Even if the initial SQL injection was in a SSL connection (my assumption is there was no initial reaction due to lack of detection), the rest of the attack should still be easy to detect. What are these companies doing about network security monitoring and intrusion detection? Seems to me that this is a point where current PCI-DSS requirements might not be sufficient. Requirements 10, 11.4 and 11.5 are good candidates to be improved.

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.