It’s one thing to develop and execute a strategy to manage governance and risks, but how do you deal with the things that the strategy can’t manage – the exceptions to the rule?
There is a quote that is often reproduced in the cybersecurity world that says: “Every time you make a security exception for convenience; you leave the door cracked open.” It is a statement that true, particularly as it is a common thing that even the most security-conscious organizations must contend with – the legitimate need for and workaround pressure to allow exceptions to established policies and processes.
The Role of Governance
Governance is all about identifying risks and defining and implementing controls – policies, procedures and standards – that mitigate them to the level deemed acceptable by the organization.
There is an inherent challenge with controls. If you want to cover every possible eventuality, your control documents will all be extremely long and complex, hindering their effectiveness and hampering adoption. To make them practical will usually require a degree of generality. Such an approach should see a set of controls cover roughly 80%-90% of possible situations (a rough estimate) and will err on the side of prevention rather than liberalism – which means that we need a process for applying for and granting/denying exceptions. We might call them “waivers”, “dispensations”, “variations” or anything else we can find in the thesaurus, but they all amount to the same thing: exceptions to the rules of governance – which includes cybersecurity. This is a discussion of just some of the considerations when dealing with exceptions. We encourage to research further before implementing actions appropriate for your organization.
Exception to the Rule
Exceptions are easy to create in a technical sense. For instance, we add a rule to the firewall, or enter a web address in the web filtering service, or create a bypass so a user can send encrypted email attachments (this example is legitimate as some organizations prohibit outbound email with encrypted attachments because the mail server can’t scan them for suspicious content). Nonetheless, exceptions represent a significant governance obstacle, as managing them is infinitely harder than implementing them. We therefore need to invest time, money and effort to ensure that we manage them properly.
First, identifying what is needed. Exceptions are just like IT incident tickets: the request asks what the user wants you to do, rather than expressing the need and letting a subject matter expert figure out how to make it happen. Exception requests often take the form: “I need you to set an exception so I can send email attachments bigger than the 30MB limit”, when the actual situation may be more like: “I have a one-off requirement to somehow get this 50MB file to third-party law firm X”.
Next, approval: the question “Who should be approving this exception?” can be a hard one to answer. Should it be the requester’s line manager? They are probably best placed to understand why the exception is needed, but they will almost certainly not look at things from a wider organization or cybersecurity governance point of view – their staff member is simply trying to get the job done. Should it be the CISO or risk manager? Well, they will understand why the policy is in place but may not have enough awareness of day-to-day needs to fully grasp the context of the request or the impact of denying or delaying the exception. Should it be the head of IT? They might well be the person best placed to figure out a technical solution that addresses the need without an exception being required. On balance, the usual way to go is for the risk/cybersecurity team to be the decision point – but the onus is on them to discuss the requirement with the requester, so they understand why the exception is needed. Context is key!
Third, the scope of the exception. We glanced at the idea earlier: a very niche requirement can be put across to us as a much wider-ranging request. Exceptions, if we grant them, should be very tightly defined. Just like firewall rules, there should be no concept of “permit all” in any of our exceptions: “I need outbound SFTP” needs to be tightened, for example to: “I need outbound SFTP from my PC to X, Y and Z”.
Fourth, and related to the previous item, time. How long do we need this exception for? Some needs are one-off; some happen more often, but infrequently; some are permanent. The general rule should be that every exception must be time-bound – that is, it has an end date at which point the exception ceases to exist. If we can configure this into our security systems then that’s excellent: the ability to tell the VPN server, say, to permit the CIO to connect from Malta while she’s there from October 28 to November 12 is the perfect feature. Never permit indefinite exceptions; if the requirement is an ongoing one, pick a maximum duration (six or 12 months are the usual choices) and set an end date. Make sure that you have an effective mechanism for warning when exceptions’ end dates are coming up and put the onus on the requester to ask for an extension or a review. If it’s important enough, they will ask for it.
Fifth, monitoring. Where you have permitted exceptions, log traffic comprehensively and schedule (and do) regular reviews of behavior that uses those exceptions. There is always a non-zero risk of an exception being used by a bad actor as a means of data exfiltration, for instance.
Just Say No (When Needed)
Finally, don’t be frightened to turn down a request for an exception. Policies exist for a reason: to mitigate risk. They are not there (or, at least, they should not be there) merely for show or to tick a regulatory/audit box, but are intended to define the controls within which the organization can operate at what management have agreed is an acceptable level of risk. So approving an exception should not be a rubber-stamping exercise, and it must be made absolutely clear to approvers that they share the liability for anything that happens because of an exception that they approved. This doesn’t mean, of course, that approvers have ultimate power of veto, merely that they have the right to decline to approve something they think unwise. Someone more senior with the authority to do may opt to overrule the approver. If so, ensure there’s a means of documenting such instances.
Exceptions, in any governance scenario, are a risk factory. Be wary of them, treat them with respect and caution, monitor them closely, constrain them as tightly as you can, and keep their number to a minimum.
And never be afraid to say “no”.
Related Insights