Recently, an article in The Wall Street Journal revealed that IT outsourcing companies in India had reduced the number of H1B (worker) visa applications made to the authorities in the United States even before President Trump voiced his concerns about the negative impact of such visas on the US labor market.1 Looked at from a high level, this should not be a surprise. On-site provision of expertise by the service providers was replaced by offshore locations. Now, much of the offshore IT service has moved to the cloud. Cheaper, better, more efficient are the drivers of computing services metrics today.
The reduction in H1B visa applications goes to the fundamental nature of shifts in computing, which rest upon physical and logical views of the system. A single physical view can support multiple logical views. Leveraging this idea, the first move was from data files to databases; next was a transition from one’s own physical assets to the shared physical resources of the service provider to support logical views of the acquirer of services. Moving to the cloud would mean not having to worry as much about the physical view and instead focusing on logical views, the real value of information processing. Of course, this decoupling of physical from logical is a key factor in the launch of cloud computing.
Cloud services have grown dramatically in the recent past and continue to increase in popularity. Between 2015 and 2020, cloud computing is predicted to achieve an annual growth rate of 19 percent.2 Cloud implies sharing, which means potential efficiency because a shared resource can be optimized across many clients. On the provider side, sharing means scaling to meet the needs of increasing numbers of customers to move more data and applications to the cloud. The unprecedented growth of this idea is vividly expressed in Amazon’s magical rise in the cloud services market—no wonder its stock price crossed the US $1,000 mark recently!
Interestingly, the idea of not having to own infrastructure and instead relying on a centralized resource (as in the cloud) or a decentralized resource (as in ride-hailing or Airbnb) has great appeal for innovation and growth while dramatically containing costs. Google’s current experiment with Waze, a community-based traffic and navigation app in the San Francisco Bay (USA) area, has to do with sharing without owning: If person A is going to the same place where person B is driving today, why not connect on Waze and plan for a ride share? In another 10 years, it may be that driverless cars combined with ride-hailing platforms result in not having to own a car or have a garage in the home.
This exciting development in cloud services comes with new or additional risk. To quote an ISACA Journal article, “The benefits of cloud computing are tempered by the extreme potential to introduce uncontrolled or unforeseen risks and threats to an organization’s information.”3 If there is one third-party risk management instance that the IT auditor should thoroughly examine, it would be the cloud services provider(s) (CSP). When an enterprise is living in the cloud, it is beholden to a third party that can make decisions about its data and platform in ways never seen before in computing.4
Blind Spots
Whereas it would be difficult, if not impossible, to identify every blind spot on the cloud platform, there are a few categories that illustrate the fact that, indeed, such blind spots exist, and one needs to look for them so they can be addressed to mitigate any hidden risk behind them.
Four main sources of blind spots are:
- Interoperability between the cloud and in-house systems
- Task allocation between the provider and the acquirer
- A new definition of users
- In some areas of the cloud, the collaborative nature of work
The ability of computer systems to exchange information, or interoperability, in cloud ecosystems is becoming more critical given that part of the organization’s system now resides elsewhere, with the CSP. And yet, the logical flows of data and user interactions have to be supported as if the system has never been split. By the very nature of the arrangement, interoperability is assumed in cloud services. However, many users may not even be aware if their work is happening in the cloud or on their (local) system. Depending on the scale and complexity of outsourcing, managing interoperability can be a major challenge, even when due care is exercised in the selection of the CSP. Often, confusion arises from lack of knowledge about the application, such as whether the version in use is cloud independent (e.g., Office 2010), cloud supported (e.g., Office 2013) or cloud integrated (e.g., Office 2016).
A related point is that, in essence, there are now two custodians of the whole (system), and an exhaustive tracking of who does what is difficult, especially if this is likely to change dynamically. The destiny of the acquirer is deeply connected with events unfolding in the provider space. For example, when the provider is hacked, the organization’s sensitive information is at risk no matter how stringent the organization’s security. The sole reliance on service level agreements (SLAs) is impractical as there are numerous minute details that need to be identified and incorporated in the task allocation. It may even be necessary for the acquirer to have the provider commit to compliance with key policies of the client and an audit of critical areas by the client. Missing or poor handling of a task on either side can have grave consequences; therefore, it is important to know who is responsible for the task.
In the past, end users were all within the company and were subject to strict protocols and requirements. Not everyone was an end user, and tasks of managing the information-processing value chain belonged to the few. No more. In some ways, the split between physical and logical views empowers the organization to do more with information to create wealth. The traditional definition of end users is now expanded to include practically everyone using the information, creating new data or running applications from their devices. This vast expansion of the user universe is different in its culture. End users have come to expect that they can begin working on a task at the office, then pick it back up from home later in the evening without any noticeable difference between the two. They want to work with systems (anywhere, anytime, from any device), while often having little awareness or understanding of relevant risk exposures. They may not know where they are saving their documents, for example, or how safe these documents are.
Finally, because the cloud facilitates sharing, collaborative work has flourished on cloud platforms. When two or more users jointly share in the duties of a project or a task, the best protective shield that exists is represented by the weakest link in the chain. This creates uncertainty about what the exposures might be. Even tech-savvy people sometimes are not fully informed about risk and may or may not consider paying attention to it as important. A collaborative group is often focused on the core outcome of the project and may not see beyond the central project requirements.
Protection/Mitigation
Interoperability implies many communication channels and frequent access to data and systems across the boundary of the cloud. Access authorization, encryption of stored data and data in transit, and role-based user privileges—these are some of the common means of securing the client-provider communication. As to the applications supported by either side—provider or acquirer—a rigorous change-control process oriented toward the cloud environment must be followed. Recently, the change control process has received increasing scrutiny from auditors. The level and quantity of information required to make even simple changes have multiplied following this scrutiny. And documenting even a simple change could take as much as 30 minutes now compared to less than a minute a few years ago.
In defining acquirer-provider accountabilities, a periodic audit of the SLA and related documents may suggest vulnerabilities arising from vague language, implicit understandings or undocumented promises. Without review of how the two partners come together on critical tasks, it is difficult to modify existing commitments and, thus, improve expectations.
In a systems environment where the cloud presence is significant, it is necessary not only to require end users to successfully complete appropriate training, but also to do so regularly for most training, including updates. While this is a soft area because of the human element involved, it potentially offers the best hope for any kind of prevention of mishaps or incidents. Even a blog of what went wrong and how it was addressed could help users understand the gravity of the task and how seemingly trivial things trip up normal conduct. The case for end-user training cannot be overstated. For example, in the Bangladesh Federal Reserve Bank case, approximately US $90 million was stolen by hackers; the reason was that while the SWIFT5 system appeared quite secure, the environment in which it was operating in Bangladesh caused vulnerabilities.6 The system stayed logged on even after hours, clearly a user oversight, making it feasible for the hackers to exploit the bank.
In instances of collaborative work, it is important to strengthen the weakest link in the chain. This can be done by requiring rigorous training and having the group discuss exposures and vulnerabilities—or, simply, what could go wrong and how to avoid it. This soft approach should be supported by appropriate software, hardware and communication controls to create defense-in-depth for the collaborative environment.
In sum, (public) clouds split the system tasks across independent organizations. The risk, therefore, nearly doubles, as if the two decision-making groups were acting in unison as a single entity. A tsunami at the provider location is also, for all practical purposes, a major disaster for the acquirer. Any outage at the Amazon cloud could mean outages for its customers, such as Netflix, which, in turn, would impact millions of Netflix customers. The weaker of the two entities will likely generate more worries about security risk. Confidentiality, integrity and availability objectives in the cloud environment are the products of joint efforts, with the requirements often specified by the acquirer of cloud services. In this joint effort, all providers matter. A February 2017 survey conducted by Intel Security reached the following recommendation: Organizations should look for specialty security solutions that provide an equivalent control layer across all providers.7 The identification and mitigation of blind spots across all cloud platforms in use is a critical step for the reliable and sustainable existence of both the provider and the acquirer of cloud services.
Endnotes
1 Meckler, L.; N. Purnell; “Use of H1B Visas Fell Before Donald Trump’s Critiques of Program,” The Wall Street Journal, 5 June 2017, www.wsj.com/articles/use-of-h1b-visas-fell-before-donald-trumps-critiques-of-program-1496682157
2 Columbus, L.: “Roundup of Cloud Computing Forcasts, 2017,” Forbes, 29 April 2017, www.forbes.com/sites/louiscolumbus/2017/04/29/roundup-of-cloud-computing-forecasts-2017/#29787c3131e8
3 Cadregari, C.; “Every Silver Cloud Has a Dark Lining,” ISACA Journal, vol. 3, 2011, www.isaca.org/resources/isaca-journal
4 Trapani, G.; “The Hidden Risks of Cloud Computing,” Lifehacker blog, 29 July 2009, http://lifehacker.com/5325169/the-hidden-risks-of-cloud-computing
5 SWIFT, https://www.swift.com/
6 Burne, K.; R. Sidel; “Hackers Ran Through Holes in SWIFT’s Network,” The Wall Street Journal, 30 April 2017, www.wsj.com/articles/hackers-ran-through-holes-in-swifts-network-1493575442
7 Greengard, S.; “Why Cloud Security Is Still a Concern,” Baseline, 3 March 2017
Vasant Raval, DBA, CISA, ACMA
Is a professor of accountancy at Creighton University (Omaha, Nebraska, USA). The coauthor of two books on information systems and security, his areas of teaching and research interest include information security and corporate governance. He can be reached at vraval@creighton.edu.
Don Lux, MSITM
Is a MTS 1, software engineer at PayPal and a doctoral student at Creighton University. He has nearly two decades of experience in IT in various roles as a programmer, automated tester, release engineer, release manager and support engineer. He can be reached at donlux@creighton.edu.