Security’s blind spot: The long-term state of exception
It seems every major hack is accompanied by the pointing of fingers. And there are plenty of places to point them: the servers that weren’t patched, the retailer who hadn’t finished setting up an intrusion detection system, the high-ranking official who used his personal email to store secrets, the critical application with unfixed security holes because the programmers hadn’t finished fixing them yet, the users of unapproved cloud or mobile applications for corporate data.
What all of these things have in common is that they involve IT systems in a state of exception. There were rules (or “best practices,” if you must) on how things should be secured but, for some reason, these things were an exception to those rules.
The people who were responsible for the security of those who were breached had assumed that things were happening a certain way – that is, only approved applications were in use, all critical systems were patched properly, appropriate alerts were being monitored, and internally written software had been hardened. However, these things were not always true, all the time. There were exceptions living outside of the security policy and distorting the acceptable risk tolerance.
The state of exception
A common way people are misled by these security exceptions is when these things are in the process of becoming “acceptably secure” but are not quite there yet. In project status meetings, it’s not unusual to hear, “We’re hardening those boxes, but we’re behind schedule.” And the assumption is that they’re almost done, but that isn’t always the case. Another misleading statement that a user who needs a specific solution is told is, “We don’t have the right secure application or email system yet, but we will soon.” This is often the user who will go find their own BYOD application until IT supplies a solution, which could take months or even years. In the meantime, IT assumes the user is making do with the existing solution and will get used to it.
The assumption is always that in a short run, these exceptions to the rules will be closed. However, periods of exception can grow to become long-term, exposing an organization to higher and higher levels of risk as they go unresolved.
Why exceptions linger
Why do temporary workarounds linger for years in the long-term state of exception? The most common reason is cost. An organization establishes a universal solution that covers most of the necessary cases at an efficient and economic level. The few cases that the solution doesn’t cover exist in exception, but the assumption is that they will eventually catch up. Why don’t they catch up? There are two categories of lingering exception cases: systems and people.
The systems that don’t get brought up to the rule are usually legacy systems. These systems are often expensive and critical but need to be upgraded or replaced. However, that often takes longer than expected to implement due to cost, lack of expertise, and unexpected complexity or interactions. And as new problems are found, the deadline continually gets pushed out.
It’s human nature for the minority to protect their own interests in the face of majority-mandated changes that don’t fit all. And nothing ever fits everyone, especially in larger organizations. These kinds of BYOD and shadow IT exceptions are inevitable when enterprise-scale solutions are rolled out. People will make their own exceptions and use what they want to use. I’ve seen a handful of users refuse to use corporate standard email and download their own client because it was what they were familiar with. Guess who got infected with emailed malware?
Providing custom secure solutions for that subset of the population requires significant cost and provides no direct benefit to those maintaining the overall system. In other words, if it works for most of us, everyone else needs to fall in line. But that doesn’t usually happen, and pockets of long-term exceptions begin to fester.
What to do when the exception becomes the rule
Security policy exceptions that are untracked and uncompensated becomes a source of risk, which increases depending on two factors. The first factor is the size of a possible impact of a security failure, which can be high if an exception involves critical data or systems. The second factor is the likelihood of exploitation which increases over time, making long-term exceptions especially dangerous.
The key to dealing with exceptions is to document and track them. Assumptions should also be made explicitly clear to all decision makers so that everyone is on the same page. It is easy for exceptions to be overlooked or ignored as they linger over time, becoming part of the status quo.
Security leaders must make sure that everyone is aware that problems exist and they will not solve themselves. A powerful management principle is: If you can’t measure it, you can’t manage it. Therefore, risk regarding these exceptions should be measured, tracked, and regularly reported upstream to ensure there are no surprises. It also makes it easier to create a feedback loop from executive management for resources to mitigate the risk or order the elimination of the exception.
Reducing exceptions
When rolling out a new policy or system, it is helpful to remember that new systems will generate new problems. Even small changes can act as catalysts for larger, unexpected blowback which, in-time, will create exceptions. It all depends on how well a solution matches the culture and infrastructure it’s being put into. It’s also difficult to force a large-scale solution to work if it doesn’t fit in an organization. Usually it integrates or it creates significant exceptions.
A warning sign that something isn’t going to integrate well is when people (sometimes referred to as “users”) are treated as inert, obedient components instead of dynamic individuals with their own motivations, habits, and requirements. Another problem can arise when new security processes favor the organization’s convenience over the individuals. These are the processes that might be worked around as exceptions instead of being used properly and safely. For example, a difficult process for remote access will push users to alternative, less secure systems while still maintaining the organizational illusion that a secure system has been put in place.
Exceptions that manifest over time
Even a fully functioning and well-integrated security system will need to be monitored and adjusted over time. There will be variability in demands and conditions of any normal organization that if not compensated for can create hidden exceptions in the security program. Success means spotting and tracking these exceptions as they arise and meeting them with appropriate mitigations. In this way, the state of exception can be moved from a long-term unacceptable risk to short-term and the acceptable level of risk maintained.