Exceptions Should Not Become The Rule

It is a sentence I hear a lot; “We treat Microsoft 365 as an exception in our cloud security because it is a managed app.” You might think that’s a reasonable approach to take, after all Microsoft’s security credentials are impressive, all OneDrive app traffic is encrypted, and there are plenty of other unmanaged cloud applications in use as shadow IT all over your organisation that pull your attention. 

But what if I told you that the most recent Netskope Cloud and Threat Report discovered that nearly a third (28%) of all malware downloads over the past 12 months came from Microsoft OneDrive, and the next highest source was SharePoint (11%)?  Both are almost always entirely managed and authorised, and yet these services are the biggest source of malware from the cloud by a long way. Just to put those cloud-originating malware numbers into perspective as well… cloud apps are the source of 47% of malware downloads—almost as many as come from traditional websites.

Now can you see why I wince when I hear that OneDrive and other trusted vendor apps are treated as exceptions to standard stringent cloud security policies?

My rule of thumb is that an exception is not an exception if it accounts for more than 2% of traffic.  

There is always going to be room for exceptions, but they should be granted on the basis of privacy impact (for instance) rather than vendor trust. For example, If you allow access to personal banking applications from work-managed devices, then privacy practices should determine that it is inappropriate to decrypt data to allow it to fully pass through security policies. In that instance I would recommend simply blocking the use of such sensitive personal applications, and communicating to employees that personal privacy concerns mean the organisation recommends using a personal device to protect their data from corporate decryption and scrutiny.  

Another reason people tend to create exceptions is technical challenges in driving traffic through the decryption/encryption process. These issues actually tend to present themselves more often in tier 3 cloud apps—from lesser known vendors or when vendors have created a plug-in or add-on without due thought to the enterprise use case.  These issues are – to me – more reason to apply stringent security, not a justification for circumnavigating controls. 

When we start working with new customers, the question they often ask around exceptions is; “How do I migrate my exceptions?” You can probably guess by now that my answer is: don’t! Keeping a Register of Exceptions is a good idea, requiring the documentation of the reasons and necessitating approval from a senior security officer. That senior team member can also require an assessment of the percentage of data traffic that the exception will impact, to help them make their decision. I tend to find that, when organisations review their historic exceptions, no one can remember why a particular app was allowed to be bypassed in the first place. 

Ultimately, exceptions take time and resource to manage, and leave gaps in the organisation’s security posture. Attackers know they are likely to find doors left open as a result of misattributed and unnecessary trust decisions in big name, trusted apps. Don’t make it easy for them; don’t let exceptions become the rule in your organisation.