Philosophical phriday - compliance risk
According to a vendor's promotional video interview I saw recently, the 'cybersecurity compliance burden' has allegedly become so significant that [customer] organisations are eagerly buying [their] software tools and services to help them manage and fulfil their obligations. The vendor's argument goes that, instead of accumulating a ragtag bunch of policies and other controls relating to user Identification and Authentication (I&A), for instance, it makes sense to:
- Identify all the cybersecurity-related laws, regulations and standards that apply to the organisation;
- Examine them for any security control requirements relating to, say, I&A;
- Rationalise the I&A controls down to the smallest set that satisfies all the requirements - the lowest common denominator;
- Design, implement, use, manage and maintain those I&A controls;
- Have the I&A controls checked or audited to gain assurance that the compliance requirements are met.
OK so far? Sounds reasonable, right?
Starting with #1: simply identifying which cyber laws, regs and standards are or are not applicable is harder than it seems - not simple at all. Consider NIS 2 for instance, which takes several pages of legalese to define the critical infrastructure organisations to which it applies ... and then allows for EU nation states to refine the applicability criteria, including or excluding organisations according to their national contexts. Furthermore, NIS 2 requires or encourages applicable critical infrastructure organisations to impose similar [contractual] obligations on their suppliers.
NIS 2 is just one of many potentially relevant compliance drivers in the area of cybersecurity, so it is not hard to come up with a very long shopping-list, especially for a large, complex and multi-national organisation in heavily-regulated industries.
Broader still, since confidentiality, integrity and availability are important considerations for most if not all forms of information, there may be information security implications in laws and regs on seemingly unrelated topics, way outside the usual cyber/privacy areas. Laws and regs are, themselves, forms of information with stiff integrity requirements. Ultimately, since law involves submissions and judgements in court, information security is vital for forensic evidence.
In short, information security is relevant to all laws and regs in various ways. Therefore, step #1 could be seen as the converse challenge to identify applicable laws, regs and standards that do not have some material bearing on the organisation's cybersecurity. Either way, there are lots of them!
#2 is tricky too. What are 'security controls'? What is 'I&A'? What are 'requirements'? How 'related'? These seemingly esoteric questions are challenging for those who delve deep into step #2. Since privacy laws, for instance, concern personally-identifiable information, it could be argued that all their specified controls (however that term is defined) constitute I&A controls - even those that are quite distinct with little if any relation to identification and authentication per se.
Aside from I&A, a complex interlocking and overlapping mesh of controls is necessary to mitigate the wide range of unacceptable information risks ... so multiply the effort to explore, say, I&A by N where N is a large but uncertain number.
Surprise surprise, #3 is not easy either. The language of well-written compliance texts is formal and definitive, leaving little to no wiggle-room that might allow applicable organisations to escape their obligations 'on a technicality'. Details matter, so even a generic good-practice control that 'broadly' satisfies a legal/regulatory requirement may be found inadequate in practice and deemed noncompliant in court. Potentially, even controls that are stronger/better than those mandated could lead to problems if the compliance obligation is too explicit.
Conversely, some compliance texts such as NIS 2 pose a different challenge, in that they are deliberately non-specific in order to apply to a diverse range of situations, and to allow the authorities to interpret them according to the implementation contexts.
Either way, the phrase 'lowest common denominator' is a red flag to information risk and security professionals, since it strongly implies doing barely enough to satisfy the compliance obligations, as opposed to doing what's best for the organisation, its stakeholders and society at large. Some may feel scraping past low hurdles is adequate: pro's remain concerned at the residual information risks, including those that are not even addressed by current, applicable compliance texts. A forward view implies preparing now for quantum-resistant cryptography, for instance, going beyond current legal obligations. Getting ahead of the game means more options to take the most efficient path. Wise investment trumps kneejerk expense.
While the other steps are quite laborious, intense and costly, #4 is where the bulk of the control costs are incurred ... and where the main benefits are generated - hopefully more than enough to offet all the costs, otherwise why bother at all? Compliance management tools/systems/apps/services have limited value here, except perhaps that the other steps help rationalise the requirements, prioritise the implementation efforts and clarify various controls or aspects that are particularly important. That's a marginal effect on the most value-intensive step.
#5 is also a mixed-bag. On the one hand, credible, high-quality compliance evidence supporting the presence and effectiveness of a particular control may be sufficient for multiple compliance obligations specifying that control ... but maybe not, particularly where compliance checks revolve around tick-n-bash auditors using prescriptive checklists.
At a more general level, the suggested approach is patently compliance-driven, suggesting that the organisation has no agency - no choice but to comply with demands imposed upon it by the authorities. It is also minimalist, seeking the simplest and hopefully least cost way to clear the compliance hurdles by the slimmest of margins. It is static or retrospective in the sense of examining current laws and regs, whereas laws and regs gradually evolve, are variously interpreted by the courts, and are occasionally withdrawn, updated or replaced.
Last but not least, there are several uncertainties here, making the compliance approach risky as well.
I appreciate this is a negative, critical, even cynical perspective, over-emphasised to make various points. I plan to return to this topic soon with a more balanced piece offering alternatives to the compliance-led strategy. To whet your appetite, I'm hinting at value-driven businesslike approaches. Maybe.