In traditional IT organizations of yesteryear, systems were developed, acquired and deployed for use by all employees (e.g., electronic mail), specific individuals (e.g., a graphic design tool) or departments (e.g., payroll processing systems or human resource management tools) in an organized, structured way.
The most realistic strategy is to assume rogue cloud installations already exist.
More importantly, access to those systems was generally under the watchful eyes of IT managers and system administrators. Those who attempted to install their own privately or company-acquired systems had to pass through the IT "screen" before being permitted to deploy these systems. Since the early days of IT, this model has mostly worked successfully.
However, the emergence of cloud computing has challenged this paradigm. The rapid growth and acceptance of cloud technologies has brought about a new model for IT service design and deployment: do-it-yourself cloud service planning and management is now a reality.
For IT security leadership, this new "rogue" cloud usage model creates plenty of headaches, to say the least. When non-IT employees use cloud services to build and run their own IT systems without the knowledge or input of IT professionals, it sets the stage for a variety of potentially disastrous information security scenarios. In this article, we'll examine rogue cloud deployments, including why they should never be tolerated, how to find them and tips on how to effectively manage them.
Defining the rogue cloud usage problem
Rogue cloud usage, in short, is the unauthorized use of cloud-based resources to facilitate the business of an organization. An important reason for this trend growing in popularity is that it bypasses the IT organization, which is often seen as a roadblock or hindrance to the enablement of emerging business processes. It's now so cheap and simple to spin up a server in the cloud that launching a Web server or a SharePoint instance outside the corporate IT structure for users means bypassing the internal red tape that exists in many enterprises.
Yet when rogue cloud installations appear, they can negatively impact IT's ability to provide and manage a secure portfolio of products and services. For example, an improperly configured rogue cloud installation may not adequately protect important or sensitive business data, exposing it to savvy attackers. Or worse, it may enable a potential network security breach should adversaries use it to penetrate the company's network perimeter -- using an opening that the network security staff can't identify and control because they never knew about the cloud instance.
Rogue cloud systems were among the issues addressed in Symantec Corp.'s 2013 Avoiding the Hidden Costs of Cloud survey (pdf). The survey garnered more than 3,200 responses from IT organizations worldwide, with nearly a third of respondents reporting an increase in rogue cloud deployments in their organizations. Another key finding involving rogue cloud usage was problems with data backup. According to Symantec, more than 40% of the respondents lost data in the cloud. Of that group, two-thirds experienced recovery failures.
Finding rogue cloud deployments
The most realistic strategy is to assume rogue cloud installations already exist. So develop a variety of procedures -- for example, leveraging existing performance monitoring tools with monitoring support from cloud service providers -- that can identify and determine the origin of suspicious cloud activity.
Word of mouth is always the easiest way to discover ad hoc cloud usage. Savvy IT security organizations are typically well-connected with all departments and key individuals throughout the organization. Ideally, this connectedness provides a window into what departments and individual users are doing and how security can support their efforts as a facilitator instead of an inhibitor.
Network monitoring is important as well. Proactive monitoring for unauthorized cloud usage, identifying suddenly changing patterns of network traffic, observing suspicious network activity traversing intrusion detection/prevention systems, or spotting unusual shifts in demand for data storage may identify potential rogue cloud activities. If there is reason to believe users are creating unauthorized instances with an IT-authorized provider, the provider may be able to spot usage anomalies (e.g., those that are outside service-level agreement parameters) that could be rogue activity.
Managing rogue cloud deployments
Assuming you identify rogue cloud activity, resist the temptation to immediately shut it down. Instead, determine what effect it has on IT operations -- specifically, if it could somehow compromise the organization's ability to protect sensitive data and keep important IT assets secure. Some unauthorized cloud instances are fairly benign and merely require documentation. Once the discovery and due-diligence efforts have been completed and it's clear there are some security risks to consider, senior management must be notified and the rogue installation should be either terminated, secured properly or merged into existing IT operations.
Separately, get senior management support to establish a policy for cloud services usage and include a provision addressing non-IT and other unauthorized deployments, explaining why they may be detrimental to the company and detailing the penalties for failure to comply with the policy. This will help reduce the likelihood of future ad hoc cloud usage.
About the author
Paul Kirvan is an independent consultant and IT auditor, as well as a technical writer, editor and educator. He has more than 25 years' experience in business continuity, disaster recovery, security, enterprise risk management and telecom/IT auditing, and more than 30 years' experience in technical writing/editing, technical training and public speaking. Mr. Kirvan has been directly involved with dozens of business continuity, security, IT audit, risk and telecom consulting engagements, ranging from operational audits and strategy definition projects to plan design and implementation, program exercising, execution and maintenance, and RFP preparation and response. Mr. Kirvan is currently a member of the board and secretary of the U.S. chapter of the Business Continuity Institute (BCI). He is also a Certified Information Systems Auditor and a Fellow of the BCI.
This was first published in June 2013