Some call it "shadow IT," but I am among those who call it "rogue IT." Both terms refer to information technology that has made its way into an organization without proper approval.
Rogue IT can crop up very easily these days. Just about anyone with a valid credit card can spin up applications and infrastructure under the radar. If there's no need to integrate with existing infrastructure, no contract review and no requirement for a purchase order generated by accounting, users can arrange to receive software as a service or even infrastructure as a service with no one in IT being the wiser.
Some companies have actually embraced the concept of shadow IT, but as my preference for the more pejorative term "rogue IT" might suggest, I'm among those who see it as a risk.
What my company has embraced is the SaaS model. In fact, SaaS has become our preference, followed by buying software, then building it. But our reliance on SaaS doesn't mean that anything goes. Before any SaaS application is authorized, it must meet a rigorous set of requirements in areas such as security, availability and company viability.
But those requirements don't eliminate the possibility of unauthorized arrangements being made. At a recent business meeting, the CIO asked if we have a rogue IT problem. Much as I hated to, I had to say, "Yes, probably." Having admitted as much, I felt the need to find out the extent of that problem.
Rogue client applications on PCs aren't the problem. We can easily discover them with our configuration management tool. But cloud-based apps typically require no client-side application, except for a Web browser. How do you find those, without spending money on yet another security tool? I turned to our network gear.
Our Palo Alto firewall and the network sniffers installed at egress points gave us a comprehensive list of all fully qualified domain names of the sites to which employees make connections. We filtered out all the tolerated sites, which left us with a shorter list. Some of these were for known and sanctioned business apps, such as Chrome River, which we use for expense reporting. After some more filtering, we were left with a short list of apps that are being used but never went through the review process.
One of those was for storing presentations by the board of directors. Only a limited number of people would be interested in such an application, and after a few calls, the CEO's administrative assistant told me, "Sure, we've been using that app for almost a year now." She had used her own credit card to sign up for one year of service for $3,000 and then filed an expense report. What's the harm, right? Well, after looking into this app a bit, I found that it uses no encryption, has a poor authentication model and offers no process to remove users once they no longer need access. I don't think we want our board presentations uploaded to such a rickety infrastructure.
We also found that a business group had contracted for the use of a SaaS knowledge base for our customers. Some very sensitive, proprietary information was being stored on that site, which offered no encryption in transit (SSL) or at rest, no proper account management and no redundancy if the site went down. Sadly, our intellectual property was potentially being put at risk of exposure in this way when we already have a very robust knowledge base. Unfortunately, this particular group knew nothing about it and set off on its own to fill its needs.
We found several other rogue IT projects that will have to be dealt with either by sanctioning them or forcing them into an early retirement in favor of more robust corporate solutions.
All in all, not a great week, but I guess it's better to know about all of this stuff than it is to remain blissfully ignorant.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Join in the discussions about security! computerworld.com/blogs/security