We all know that security isn't something as tangible as a product, but rather should be regarded as a process. And when it comes to making the case for improvements to security, it's tangibility diminishes even further.
Ususally when you buy something, you expect to see immediate benefits, for example, your new car may do twice as many miles to the gallon than your old one.
Most investments are made to enable things to happen, but investments in security are about preventing things from happening. In some ways, investing in security is a bit like buying insurance for your new car: there are no immediate benefits.
As with insurance, the decisions to invest in security are based on an understanding of risk. And those with an appreciation of risk are able to justify the cost.
However, you still have to determine if your security system is really working by testing or auditing them, whether you do it yourself or through a third party.
The problem is that you need to test against something to be able to tell people how good their security actually is, and that requires an objective measure. The best way to achieve this is to have a set of benchmarks so you can tell people whether they have met a particular standard.
Of course, there are plenty of standards around. Some cover discrete activitities such as developing secure applications, for example OWASP, and it's possible to derive coding standards for your project from this.
Then there are the standards that attempt to cover all aspects of information security management. The most prominent is ISO 27001, an internationally recognised standard for information security management systems. ISO 27001 is very similar to the way quality standards work: it says that you have a security management system, but not what level of security you actually need.
In order to find standards that impose specific levels of security, you have to turn to military standards, which might specify particular levels of, say, encryption. However, a military approach is often over the top for a commercial organisation, or is perceived as such.
But there is a glimmer of hope. I've been spending a fair amount of time on the Payment Card Industry's Data Security Standard (PCI DSS), in particular, aspects around auditing and testing for compliance to DSS. Although somewhat similar to the ISO 27001 standard in the scope of the management processes, it has specific requirements for levels of technology and system configuration.
The PCI DSS does this through 12 top-level requirements, such as "maintain an information security policy" and "encrypt key data going across public networks". Each of these drills down into more detail, for example "two-factor authentication must be used for remote access to the VPN". It even lists specific technologies that meet these requirements.
While the PCI DSS is focused on the protection of credit card numbers and the systems that handle and store those numbers, it isn't too hard to generalise it for any data or information asset you wish to protect.
For each sub-requirement, the DSS provides a checklist - you either meet the demands or you don't. It is quite easy to run through the checklist and see how you compare.
PCI DSS has the potential to be useful in applications wider than it's intended target. It's a standard aimed at commercial organisations that carries an element of compulsion: if you want to store credit card details, and have a reasonable number of transactions, you have to meet the standard.
And it provides a checklist which covers both operational and technical details. Finally, it represents a minimum standard for handling sensitive data, so should not be seen as unachievable or unrealistic.
As the PCI DSS is rolled out, and familiarity increases, we can expect these requirements to trickle out to other systems or down to smaller companies, providing a benchmark against which comparisons or justifications for security systems can be made.
- Ian Castle, CISSP, is a senior consultant at ECSC and heads the internet defence division.
A lesson from the PCI
By Patrick Love, Head of Fiduciary Support, Global Wealth Sol on Aug 30, 2007 1:57PM