Try as we might, there’s never been a policy written that effectively accounted for all possible future scenarios. That’s why teaching company rules alone doesn’t provide adequate security training.
We Security Awareness practitioners tend to take for granted that we can reduce the number of preventable cyber vulnerabilities in our organisations through education alone; if we tell our users what our security rules are, then those users will unquestionably strive to comply with said rules as-written for the great food. Everything will work out fine. That’s why scads of our awareness content is built around introducing or clarifying security rules rather than on understanding or changing unsafe behaviours. That approach is … idealistic at best. Many preventable breaches occur because of users that fully understood the rules they were breaking and broke them anyway.
If your reaction to reading that was to exclaim “Ha! Those rule-breakers you mentioned must be miscreants! Punish them severely for their wilful noncompliance,” consider this: what if the reason these users deliberately violated their organisation’s security rules wasn’t out of malice or even disagreement with the rules, but because they felt that they had no choice but to break those rules in order to do their jobs? Worse, yet, what if those notional users were right?
This happens more often than you might expect. First, no policy – no matter how brilliantly written – had ever been comprehensive enough to foresee all possible use-cases. Policies inevitably run up against unique situations where their rules simply can’t apply. Technology, environments, laws, and societies all evolve, often faster than policy writers can keep up. Second, rapidly-evolving situations will always outpace mandatory organisational processes. A process that was designed and optimised to take X number of days from start to finish can’t support a situation that must be resolved in an hour. Finally, there is always going to be a risk of contradiction between overlapping policies, especially when two or more domains aren’t reconciled for perspective, objectives, or integrated process steps before their policies are published.
As an example of all three of these complications in action, consider the strange case of PetroCosm. Back at the turn of the millennium, PetroCosm was a start-up online auction house intended to reduce costs for the the oil and gas services market. It was the last entrant into an already-crowded field that could barely support one such company. In its early days, us consultants that were hired to create the new company from scratch were under a tight deadline to create a product, hire employees, build structures and processes, purchase a building, and turn over a fully-operational business to its owners in a … let’s say “ambitious” … number of months.
I was on the PetroCosm job from its inception. After a brief stint in Program Management office, I was responsible for setting up all of the internal business support IT functions while one of my peers built out all of the production IT kit and a third peer sorted all the networking. The new company would need dozens of people to actually sustain and manage these functions after we stood them up. We were tasked to get a working business running for its first “real” employees. This meant that we were frequently outpacing the “policies” and “operations manuals” that our peers were crafting over in the Business Operations team for how the new outfit should be run.
In one such instance, I had to assemble the first batch of servers so that they’d be ready for the new sysadmins to configure when they started work at the end of the week. We were working out of borrowed space at the time and didn’t have access to any of our own firm’s IT resources. I needed network switches, patch cables, keyboards, mice, and monitors, and I needed them in 48 hours if everything was to be ready on time. I sent my purchase request up through channels … and was told that there might be a six to twelve week wait before anything could be purchased.
Obviously, that wouldn’t do. We were on a tight deadline, under tremendous pressure, and couldn’t be perceived by our client as jeopardising their project. I jumped the chain of command and started asking the finance consultants directly what exactly was preventing us from dropping by the local electronics retailer, loading up a cart, and spending some of the company’s cash.
After much wheedling, the acting head of finance finally spilled the beans. We had money, he explained, and lots of it. Thirty million in the bank, in fact. Trouble was, PetroCosm was so new – as in, only weeks old according to the state – that no other business would cash one of their cheques. The new company had no credit history, no reputation … and the bank they were using wouldn’t let them withdraw cash from their accounts or get official credit cards yet. That would all come with time, the bean counter promised, once all of the paperwork got sorted.
That wasn’t going to work for us, as we had hours – not weeks – to get off of high-centre. I escalated the problem to my owning partner and got his permission to put the necessary supplies on my business travel card for later reimbursement. He grudgingly agreed, even though doing so would violate our firm’s policy regarding allowable use of the travel card.
I then dashed off to the nearest big-box electronics chain, loaded up a cart … and immediately hit another wall. When I tried to pay for my van-load of new stuff, the sales clerk told me that their chain wouldn’t accept payment via a Diner’s Club card … which, for some peculiar reason, is what our firm used to pay for all official travel.
That put me in an awful bind. I had to get the servers prepared for the arrival of the new sysadmins or we were going to miss our deadline for testing outbound e-mail connectivity with the networking team. I couldn’t get the servers built and tested without the equipment in my cart. The client couldn’t pay directly for what they needed and the only authorised method I’d been given to accomplish my task was declined by the vendor. I had two choices that didn’t involve armed robbery: try to find another retailer in the city that would accept the credit card I’d been authorised to pay with, or else complete the purchase with my personal credit card and ask for reimbursement directly from PetroCosm rather than through our firm, as per policy. Sick with dread over the potential consequences, and running out of time, I chose option #2. I maxed on my personal card, packed all the kit into my hire car, and sped back to the office.
My owning partner was cross with me for violating policy, but he empathised with my no-win position. The client’s VP of Finance made out the new company’s very first paper cheque to me … which violated almost all of their brand-new procurement policies, since they were required to wire expense money to the firm to satisfy the project accountants. Shrug. I managed to pay off my personal credit card a day before the bank charged me 19.9% interest on a $2,000 purchase. The new servers got prepped with a few hours to spare and life went on.
So, was I wrong to violate a thick stack of both my firm’s and my client’s policies to get a critical task sorted? Yes and no. What I did absolutely violated the letter of the law (so to speak) for both organisations. Those rules were set up to prevent fraud, simplify accounting, and ensure that everything involving money was done in a regulated fashion. Fair enough. Unfortunately, those rules had been written based on some critical assumptions, not the least of which was that vendors would do business with this brand-new, unheard of, untrusted entity. The policy writers never factored in the possibility that exigent circumstances might require a different approach. Like, say, during its chaotic start-up phase.
Did this deliberate circumvention represent a security risk? Absolutely. I could have snuck a non-work item into my cart and run off with it. Or sold it for cash. Or used it on another client’s project. Or any number of dastardly things that our rules were written to prevent. Should those rules have been more comprehensive and accounted for the peculiar circumstances that undermined their implementation in the early days? Maybe … I argue that all of those rigid rules sets should have included an “emergency clause.” That is, a paragraph that authorises certain limited deviations from the rules during periods when the rules cannot be applied as-written.
I advocate this for most policies and regulations: an authorised deviation that gives leaders the flexibility to respond to a crisis, on pain of their job should a review board find that they misused their emergency authority. Never publish a rule set so rigid that it “traps” honest workers in a lose-lose situation during a crisis. All that does is undermine the organisation’s authority by encouraging workers to ignore the rules you invested so much time in ordering them to follow.
It’s more pragmatic to teach the reasoning why the rules are written the way they are so that users can exercise sound judgement during emergency circumstances. Equip them to come as close as they can to meeting the organisation’s intent with the resources and options available to them at the time. Give them legal and approved options for deviating from “normal” business operations when needed, subject to stringent oversight and retroactive approval. This will go a long way towards convincing your people to take your policies seriously.