Compliant with security standards but still not secure?

30. November 2017

Being responsible for something you can’t see and that is hardly to measure but could impact the whole business, CISO’s have probably the most challenging job among the executive officers. And most of all, and that is what keeps them awake during the nights, they know that despite all the security controls they have put in place eventually a new threat will manifest that will bypass all these controls and bring down the business. Like one needle is enough to bring down a zeppelin, in this asymmetric war the smallest loophole is enough for one hacker to defeat a whole army of security specialist and their security systems.

To gain assurance on the adequacy of their current security control framework often organisations spend a considerable amount of their budget and time on audits and security remediation programs to comply with their corporate security policy or security standards that are relevant to their business. This might even lead to a formal security assurance statement, according to ISAE3402 for example, or even a security certificate, according to ISO27001 for example or PCI DSS. This should give the troubled CISO peace of mind then……….…. Right?

Not completely. Compliance will namely increase security assurance by ensuring that an organisation meets the security objectives of a security standard or policy, but that does not necessarily imply that all security risks are mitigated. In order to understand why, we need to deep dive into the concept of a standard. After all, this raises the question why do we have security standards and policies that we have to comply with if they don’t ensure security?

Standards provide a framework of security control objectives and requirements based on best practices, like ISO27001, or consensus between different stakeholders, like PCI, or a governmental workgroup, like NIST 800-53 or NZISM. A security standard is as such an agreement on a limited set of generic security requirements at a certain point in time. Lets take a closer look at each of those characteristics.

A standard is limited, since its intent is to provide practical guidance to the industry, similar to a Warrant of Fitness check of a car which is limited to a few parts. That doesn’t mean that other parts can’t break. Capturing all requirements would mean redesigning the system at each check and that would be disproportionate to the objective of a standard. Therefore, a well-balanced decision had been made between completeness of the checklist and pragmatism to perform the check. The same goes for security standards and policies. Being compliant with these standards and policies therefore still leaves an inherent security risk because of the pragmatic limitation.

A standard is generic, since the requirements in the standard are technology and/or business independent to serve a wide range type of users. The trade-off however is that standards leave room for different interpretation for the implementing companies as well as for auditors. For example, a standard stating to use strong encryption for data in transit there are different ways to achieve this. It does not state which algorithms, key lengths, at which protocol layers, where the termination points are (at application, at server, at load balancers, etc). While all of them are compliant, each of those implementation decisions have different implications and as such provide different levels of security assurance. This discretionary implementation leaves therefore another margin of inherent security risk.

A standard is an agreement at a certain point in time. Due to the growing complexity of the current Internet (of Things) and advancements we make in the individual technologies new threats and vulnerabilities emerge. Whereas in the past the periodic revision of the standards was frequent enough to cope with these developments, nowadays it is infeasible to keep up these standards with the increasingly changing environment. What is considered today as the security standard to ensure a control framework against most, if not all, threats, might be tomorrow already a legacy standard that is lagging behind on providing guidance on the newest threats and vulnerabilities.

Last but not least, the aim of most standards is nowadays not to ensure that all security controls are implemented, but rather that the processes that will ensure that the adequate security controls are implemented, are in place. This move from control based to process based standards might be instigated by the fact that we realize that we cant capture all required controls in a standard due to mentioned reasons in the previous sections. A good example is ISO27001 that requires an Information Security Management System. Therefore, an ISO27001 certification ensure compliance to the standard but not that all security controls of their appendix are in place. Hence, another illusion that security compliance ensures security.

Now that we have explained why in most cases security compliance doesn’t ensure security, it is not meant to instigate a laissez-faire-laissez-passer attitude of CISO’s. Eventually, a security compliance certificate or statement does still provide to a high extent security assurance, but it would be an illusion to assume that security is fully covered off by it. Complementary to the security compliance efforts, for the remaining residual risk IISRI recommends that organisations perform information security risk assessments and to mitigate the remaining security risks. This should not be a one time off exercise, but a periodic task, possibly in conjunction with the periodic audits.

2 views0 comments

Recent Posts

See All