From an IT professional's perspective, cloud services are a double-edged sword. On the one side, cloud services can drastically cut the cost and implementation time of even advanced software services since these now don't require lengthy setup, configuration, and testing times nor lots of expensive server hardware. Just sign up for an account and go. On the other hand, this ease of implementation is something users have learned, too, and many of them are setting up their own service accounts, either as individuals or as teams—and they're using them to store and manipulate all kinds of corporate data with no IT governance whatever, until something goes wrong.
No doubt you've worried about your employees setting up this kind of "shadow IT" service. Another common example is the cheap Wi-Fi router. Users buy these boxes from vendors like Amazon, and then deploy them in their office for better Wi-Fi throughput but without any of the firewall settings IT would normally insist upon. A more extreme example that happened to me: there's a server under someone's desk that's hosting an entire low-code development platform.
Shadow IT, or information technology (IT) systems developed within a company by individuals other than official IT staff, can be a serious security and data protection problem. At the very least, these systems contain services that aren't protected by the rest of the security measures IT employs. And at the worst, they provide an additional and largely unprotected attack surface that often backdoors directly into your corporate network. Your first response is likely to root these employees out, punish them, and destroy their shadow IT.
You might think that rogue cloud services aren't as severe of a problem as the hardware examples I just mentioned, but actually the problems are very similar. An employee, let's say she's a developer, decides to quickly purchase a virtualized cloud server instance on Amazon Web Services (AWS) or Google Cloud Platform so she can quickly test some new code she's behind on, without having to wait for a request to go through IT. In a few minutes, she's running her own workload. She pays for the service with her credit card, figuring that once the code is approved, she can simply expense it.
You might not hunt such a user as diligently as you would someone deploying a rogue router because there are two key differences between AWS and a personal router: First, simply finding our developer's rogue server isn't easy. As reported by market research firm Statista (below), governance and multi-cloud management are two of the biggest challenges facing IT professionals in the cloud age. Without prior knowledge of this user's unoffocial account, how do you track it down quickly without also violating your own security policies regarding privacy and data protection? Second, Amazon is managed by an army of expert IT staffers who do nothing all day except keep the service running smoothly and securely. So how hard do you really need to be chasing a server they're managing?
Rogue IT Risks
Users who create their own cloud services typically don't know much about network security; if they did, they wouldn't be doing what they're doing the way they're doing it. They know they want to use some important feature that the cloud service offers and they probably know how to make it work to solve a problem. But when it comes to configuring a firewall, they have no clue, and since the service is running over the internet (which is being delivered via an IT-configured firewall anyway), they probably figure they're fully protected. All they're really worrying about is doing their job in the best way they know how—which is actually a good thing.
So, if your response to these motivated employees is to come down on them like a ton of bricks, punish them, and shut down their rogue cloud, then you might want to reconsider. Sure, maybe they're ignoring the rules you made to keep control of IT. But, chances are, they're doing it for several good reasons, at least one of them being you.
You've created the environment after all, and it seems to be one in which a rogue cloud was seen as the better way for these people to do their jobs. This means, as an internal IT service provider, you're not responding at the speed the business requires. These employees needed that cloud service today; how long would they have needed to wait before you helped them?
How to Detect Rogue IT
According to Pablo Villarreal, Chief Security Officer (CSO) of Globant, a company that helps in digital transformation, finding rogue cloud services is not necessarily obvious. If the rogue cloud is using the same provider that the rest of your company is, then it may be nearly impossible to tell the difference between the traffic to the rogue cloud and to your normal cloud traffic. In the case of our aforementioned developer's server, if the company already had a few dozen virtualized Amazon servers doing other workloads, how easy would it be to distinguish her one rogue server based solely on traffic analysis? While a properly configured next-generation firewall and appropriate software can do it, the work required to do so is significant.
Villarreal said that the most effective way is to look at the credit card statements when employees submit expenses and find them that way. Higher-end expense tracking solutions can actually be configured to flag specific expense types, so finding them can be at least somewhat automated. But he also says that your next step is critical, and that's reaching out to employees rather than coming down hard on them.
"Offer to provide the services they need," he said. "Once you embrace the rogue services, you can build relationships with the users."
He said that by embracing the rogue cloud, you can bring it inside your own security, and you can help the users ensure that they can operate their cloud instance efficiently. In addition, if you're already using cloud services, then you can probably get the same service at a significant discount.
6 Steps to Embracing Rogue IT
But remember, every rogue service you find, whether it's on AWS or it's something more self-contained such as Dropbox Business , it's a symptom of an unmet need. The employees needed a service, and either you couldn't provide it when they needed it or they didn't know that you could. Either way, the root cause lies with IT but, happily, these problems are relatively easy to fix. Here are six steps you should take at the outset:
- Get to know the person, and find out why he or she chose to create the service instead of using the IT department. Chances are that IT takes too long to respond, but it could be other reasons, including a prohibition that could result in their not meeting their business needs.
- Find out more about the rogue cloud service they're using, what they're actually doing with it, and what they've done to protect it. You need to make sure it's secure while you're in the process of bringing it inside.
- Look at your own procedures. How long does it take for a team to request access to your cloud services? How involved is the approval process? How much help are you willing to provide? How hard is it to get something simple, such as an IP address? How hard is it to get included in the corporate backup plan?
- What can your IT department do to make rogue cloud accounts unnecessary? For example, can you provide a means for creating accounts on approved providers quickly and easily? Can you provide a corporate cloud account that employees can use with minimal delay? Can you provide staff to work as consultants since nobody's IT department has extra staff?
- What can your department do to foster innovation in non-IT departments? Can you perhaps provide a menu of IT services that are available on request? Perhaps a rapid-reaction service for teams that are doing something really innovative but who need help, such as incorporating machine learning (ML) into a part of their business? Remember, if you can't or won't help, then a highly motivated team will move on without you and that's what you're trying to prevent.
- Most important, use the experience to measure and improve what your IT staff is doing to react at the speed of business.
I know at this point, you might be pooh-poohing all of this, claiming you don't have the resources. But the fact is, if your employees are doing a good job themselves, then you don't need much in the way of additional resources. And if you try to prevent this sort of activity with the proverbial iron fist, then the activity will likely continue behind the scenes—and you run the very real risk of having a security incident or a business failure that will require far more resources than you'll ever have.
Even mega-providers such as Amazon and Google get hacked. If you have reams of corporate data on these services that aren't protected the same way your official stores are, then you could easily have a nasty problem and be completely unaware of it until it's too late. Sure, you can point a finger at the user who signed up without permission, but that's not going to satisfy an angry Chief Information Security Officer (CISO) who wants to know why IT couldn't account for X percent of the company's virtual servers. And it's not going to help your customers (who are often the unwitting victims) because it's their personal data that winds up being exposed.
"Employees will be happier [if you help them]," Villarreal pointed out, while also noting that punishing employees for their motivation generally results in them no longer being motivated. No one is going to thank you for that. By embracing the rogue service, you not only make users happy and keep them motivated, you also establish a communication channel based on trust. If they trust you, there's no reason to sign up for services on the sly. They'll simply inform you as they do it, since you knowing is better for both of you.