Philosophical phriday - a noncompliance ramble

In a previous philosophical phriday post, I moaned about vendors of security compliance support/management tools and services over-promising and under-delivering - an admittedly biased, even cynical opinion piece about the compliance imperative.

A recent article in Corporate Compliance Insights notes that "CISOs are not just defenders against cyber threats but also champions of compliance and operational resilience". Hmmm, are CISOs 'compliance champs', really?

Today, I'm discussing alternatives to being compliance-driven. How else can organisations drive their information risk, security and related concerns in a positive direction?

First, a straw man: no leadership. Some organisations evidently have little to no interest in information security, cybersecurity, privacy, compliance, risk management, resilience And All That. For some reason, this general area is simply not a priority, perhaps because management's radar is lit up by other glaring concerns at the moment. It may be a corporate blind-spot, or more likely so far down the agenda that attention and resources are invariably consumed by even more pressing needs. 'This general area' may not even be perceived as such, with various elements or aspects being addressed independently without management joining.the.dots. Dysfunctional, stovepiped organisations are comprised of teams, functions, departments or business units focused so intently on their own interests that they are ignorant of, perhaps even hostile towards, colleagues in related areas. Political in-fighting/turf-wars and inefficiencies may well deflect senior management's attention from gaping holes in the coverage (a governance issue). Needless to say, I consider this abysmal situation sub-optimal ... and yet understandable, in some [hopefully temporary] contexts. Information security does not have an inalienable right to be led or lead.

Next comes the idea of implementing good practices, begging questions about what those are, who determines their value and how. Almost everything that anyone does is 'good' in the sense that it happens to suit their particular circumstances at some point, or is perceived that way. Turning that on its head, it can be tricky to recognise and acknowledge bad practices, then plan, resource and make changes, particularly if the value parameters or criteria are unclear or unknown. We humans tend to follow fads and fashions, adopting security controls such as multifactor authentication simply because they are being generally recommended as opposed to being evaluated and deemed suitable, valuable or necessary for us, right now, given our particular circumstances.

A classic good practice example is the policy of enforcing periodic password changes: the arbitrary nature of the password lifetime and doubts about its value as a control led some of us to challenge the rationale of an approach that was widely used a decade or more ago. More broadly, good practices are usually quite vague, leaving organisations to determine the particular parameters and implementation details for themselves. Should 'strong passwords', for instance, be determined by their length, complexity, mixture of character types, lack of keyboard sequences and easily guessed bases, some combination of all those (and more?), left to users' discretion, or superceded by (one of the many variants of) multi-factor authentication? In practice, there are usually substantial differences of interpretation and adoption of good practices.

Whereas good practices are supposed to be good (worthwhile) for the adopters (i.e. their organisations, for internal business reasons), the compliance-led approach primarily or exclusively seeks to satisfy various externally-imposed requirements, obligations, guidelines etc. It's all about the organisation yielding to pressure from outside in order to avoid or at least reduce the risk of penalties arising from noncompliance.

A related idea is to adopt guidance in the form of published frameworks, standards, methods and toolkits. The term 'framework' hints at scaffolding, linking related concepts together, while 'standard' implies commonality, 'method' suggests a structured process and 'toolkit' suggests, well, a crafstman's favourite well-used hand tools lugged around in a canvas bag. Despite subtle differences between them, in practice they are loosely defined and generally synonymous. A key point is that the guidance is contributed and compiled by specialists.A difficulty arises with frameworks that are, or are perceived to be, rigid (prescriptive) and hence difficult to apply to the organisation's situation - initially and/or as the situation changes.

Continuous, continual, incremental or evolutionary improvement is an alternative approach, the idea being to improve things systematically, bit-by-bit. Again, this begs questions such as what are the things being improved, what is 'improve' anyway, how quickly are improvements to be made, and how should they be resourced or driven. Systematic improvement is an integral part of management systems such as ISO/IEC 27001, with some direction from the standards on the associated processes such as assurance (reviews and audits) plus how to manage corrective actions.

Incremental improvements typically deliver diminishing returns until eventually more dramatic step-changes are needed to reinvigorate progress - such as adopting new tools or technologies (e.g. moving to/from/within the cloud), different suppliers, partners or workers, novel architectures or of course new security controls. '27001 has nothing to say on that.

Talking of '27001, the standard promotes a risk-based approach to information security: identify risks to the confidentiality, integrity or availability of information, evaluate them, decide what to do about them, and do it. Lather, rinse, repeat. Since information [security] risks are context-dependent, the standard doesn't prescribe specific information security controls. Compliance with the standard does not (NOT!) necessarily mean implementing all of the Annex A controls, or indeed any of the Annex A controls, but requires an Information Security Management System - an intriguing departure from the approach taken by most technical standards. The organisation's ISMS, or more specifically management using the risk management process, is what determines the security control requirements - not the standard.

That brings to mind the idea of, rather than being compliance-driven, being business-led, putting the organisation's business objectives squarely in the scope-sights. This may simply involve the security function supporting and enabling other parts of the organisation (following their lead), or genuinely pushing ahead in their specialist domain to help deliver broad goals such as 'being trusted' or 'providing a safe pair of hands'.

There's more, much more to say about being business-led but that's enough for today. I'll come back to this later.