Until the advent of peer-to-peer and cloud-based services, corporate systems were developed/acquired, deployed and managed by IT managers and sysadmins. Access to server-level resources (including large storage volumes) was tightly controlled, laptops and desktops were locked down, and even in environments where users had administrator rights to their own devices, the worst someone could do was install an application. Granted, that application might’ve been an infected version of Elf Bowling, but malware frequently caused problems that were quickly brought to the attention of IT and the system as a whole was monitored by corporate anti-virus and intrusion detection systems so the damage could be contained.
However, with the rapid growth and acceptance of cloud technologies, a new model for IT service design and deployment has evolved and users are working around corporate systems they view as inefficient or lacking in functionality by using “do-it-yourself” cloud services. This ranges from using personal email for official communications to sharing files via a service like Dropbox or an externally-hosted SharePoint instance to using a cloud-based CRM.
A post on the July 12, 2013, WSJ Japan RealTime blog provides an example of what can go wrong.
In January, senior Japanese officials attending a conference in Geneva decided to use Google Groups to communicate with one another and colleagues back home rather than use the agency’s group email system, which apparently had a reputation for being slow when used internationally.
Throughout the conference, officials exchanged a total of 66 emails regarding the treaty being negotiated and media reactions in Japan. The messages included details on meetings with the Swiss and Norwegian delegations and draft statements to be made by the head of the Japanese delegation.
Unfortunately, the team failed to realize that, like so many social networks that assume anyone using their service must want to share information with the whole world, the default privacy setting for Google Groups allows public access to all discussions. [Ob. plug for Privacy by Design]
Although this unprotected use of Google Groups was technically a violation of the agency’s policies, this is simply an example of end users taking IT into their own hands because (a) they consider the officially-approved solution to be inferior to what’s available outside of the offerings provided by IT, and/or (b) getting approval for use of a different solution involves excessive bureaucracy and red tape. Even the cloud based services that require payments are so cheap and easy that they are within the signing authority of lower levels within the organization. IT never even sees the bills.
Looking further into the matter, the [Japanese government] found the situation to be far more widespread, involving many other government and public organizations. It found there were more than 6,000 cases of personal and central-government data being available for anyone to view on Google Groups.
Seven medical institutions and nursing facilities had no restrictions on their group discussions, which included medical information on more than 300 patients and the health records of high-school students.
Other government bodies, including the tourism and transport ministry, the agriculture ministry and the earthquake reconstruction agency, also had business-related emails open to the public.
Unfortunately, as the Japanese conference delegation demonstrated, when users bypass approved systems, they also bypass IT’s ability to protect the organization’s networks and sensitive information. In addition to exposing sensitive information, the use of unapproved (and unknown) external services can open a hole for potential network security breach.
The problems created by “self-service” cloud usage go even further than confidentiality and security. When employees leave, you may lose access to those password protected accounts (even if you knew they existed), and if you end up in litigation you may have had a duty to preserve that information and/or produce it as part of a discovery request. Even if you have access to the accounts, cloud providers may not store information in easily accessible, legally compliant (i.e., “reasonably usable”) format. Facebook and other social media services are not e-discovery friendly, and if you don’t have access to the accounts, obtaining information without employee’s password/cooperation may require litigation against that cloud provider.
“Not In MY Organization!”
According to the recent “State of Cloud Security” survey of 700 IT decision makers by the Ponemon Institute, 50% of the respondents were confident they know all cloud services in use in their organization. (This number was 45% in 2010). While I leave you to draw your own conclusions, the Japanese example might suggest that some of those respondents are overconfident. Even if that number is correct, that means at least half of organizations may have “rogue” cloud services in use.
So, odds are that your organization has at least some “self-service” cloud usage. IT should work with senior management, legal (and privacy/compliance if they aren’t within legal) to establish a policy for cloud services usage. The policy should clearly explain the risks associated with unauthorized “self-service” cloud services and specify the penalties for failure to comply with the policy. (These penalties need to be enforced consistently at all levels of the organization.)
Once the policy is in place, IT departments should include education about the policy and the risks created by these services as part of regular end user training. But policies and training only go so far, because users will always try to circumvent systems or approval processes they view as inhibiting their ability to get their job done. So IT needs to develop systems and procedures to detect suspicious cloud activity.
First, and foremost, IT should be performing proactive monitoring for unauthorized cloud usage as part of SOPs. Reports/alerts should be set to identify suddenly changing patterns of network traffic, suspicious network activity traversing intrusion detection/prevention systems, or unusual shifts in demand for data storage. All of these could be signs of “self-service” cloud activities.
Going beyond automated tools, IT should already have a “feel” for the systems and/or security procedures that cause users to chafe, and which users are the most frustrated by them. By working with various departments and users on a proactive basis to address these problems and provide solutions, IT can be viewed as a facilitator rather than a hindrance. Among other things, Accounting can look for reimbursements for payments to cloud providers. While that won’t detect use of free services like Google Groups, it will detect regular usage of things like Dropbox, AWS and SalesForce.com.
Recognize also that people like to brag about their solutions to problems they’ve experienced. Walking around and talking to people about how they use they existing systems and their day-to-day activities can reveal a host of information about actual issues and needs as well as how people are circumventing systems and policies to get their work done.
Got ‘Em!
Once you detect use of unauthorized cloud services in your organization (no, that wasn’t supposed to be “If you detect…”), what should you do?
First, remember that, in general, people only create their own solutions when they feel like the existing solutions/procedures prevent them from getting their job done.
Given that, resist the impulse to shut it down immediately unless the cloud service creates an immediate security or compliance threat. Take an objective look at the solution and determine whether the person/people using it simply didn’t understand functionality offered by existing systems (i.e., a training problem), whether the functionality can be provided as efficiently by existing systems (i.e., it’s available but may not have been turned on or provided to that group) or if the cloud service can be merged into the supported environment. Also, look into monitoring tools that can detect that service by others, because when one person finds a solution to a problem they share the solution with their co-workers who have similar problems.
Nicholson on Technology 