When your IT department goes rogue

In my last post, we discussed the latest habit of non-IT departments in organizations large and small: hatching rogue IT operations on the cloud, taking your company’s data for a spin in the Wild, Wild Web — unpatched, unprotected, and nearly undetectable.

To recap, this trend involves departments buying IT services online through vendors like Amazon Web Services, Google Services, Microsoft Azure and others, setting up off-the-books IT operations outside of your organization’s boundaries.

These departments have come to rely on these services to conduct business. Shutting them off is not an option. We now have to deal with the situation. 

What are we up against?

First, why did your users feel compelled to set up shop out of band? Are they simply lazy diehards who refuse to comply with your oh-so-onerous security and compliance requirements? Or, did they feel your department isn’t responsive enough to their needs, and going rogue was the only way to get those needs met? Or perhaps they simply felt they were actually saving everyone time and effort?

Ignore your annoyance for a sec, and do a little soul searching: Is it possible something you did (or didn’t do) opened the door to this practice? Go on and ask them (gently). You’ll likely learn something valuable that will help you prevent other rogue cloud operations later.

[ ALSO ON CSO: Going rogue: Hidden cell towers found ]

Next, the new cloud-based application has to have been populated with your company’s data in order to be useful, right? How did that much business data exfiltration transpire without your knowledge? Did it exit your boundaries through your firewall? Did someone walk out with an unencrypted thumb drive in their pocket?

It’s a common assumption among end users (and sometimes even IT departments) that moving applications and services to the cloud will somehow magically decrease compliance and auditing requirements. In reality, the auditing workload has increased in scope and difficulty, and cloud providers don’t always feel compelled to cooperate with auditors.

Finally, if your end-users did make an effort to meet your organization’s security requirements, were they qualified to do so? For instance, if your data residing on the cloud was encrypted, are the encryption keys being managed properly? Did someone read the contract fine print before exfiltrating your company’s data? Did the data change legal ownership when it was moved to someone else’s computers?

By carefully examining these questions, you’ll be able to identify blind spots and black holes you can plug now to prevent more rogue cloud shenanigans later.

(Missed the first part of this post? Catch up here.)