Data Owners’ Responsibilities When Migrating to the Cloud

Understanding who owns data is not as simple as it appears at first. It is easy to say that all data belong to the organization. This is correct, but it does not identify accountability for such ownership. The IT function may process data, store data, back data up and perform other services, but it does not own the data. Outsourcing service providers do not own data any more than an internal IT function does.¹

Data management, data quality and other aspects of data governance tend to get little attention from the IT community, and best practices in these domains rely on the work of other professional bodies such as DAMA International, publishers of the Data Management Body of Knowledge (DMBOK).²

The cloud, in its many variants, has the potential to offer many advantages to clients. Senior management is attracted by the possibility of achieving cost reductions and simplifying the enterprise IT environment. Time will tell if these materialize to the expected degree, but it is right to explore the cloud option in detail.

Twenty-five years ago, the client-server architecture seemed to spell the end of the mainframe (it did not). Thin clients did not make it to the market until the emergence of smartphones and tablets that, in turn, brought the challenges of bring your own device (BYOD) and mobile information security risk.³

Outsourcing was also expected to deliver significant cost reductions and, in many cases, it did. The main lessons learned from outsourcing were that:

• The contracts are complex and biased toward the provider
• The benefits from well-managed outsourcing extend beyond financials
• It is difficult to separate from an outsourcer

Before discussing the role and responsibilities of data owners, it may be good to recall that there was a form of cloud many years ago: the time-sharing computer bureaus (1950s-70s).⁴ These bureaus provided an Infrastructure as a Service (IaaS) capability and sometimes Software as a Service (SaaS), as well.

Only then, things were simpler:

• The number of end users was relatively small (in the 1950s, anyone who could do anything with a computer was considered a mathematical genius).
• The technology was simpler—usually one mainframe, leased lines or dial-up connections (2-4 kilobit per second [Kbps]), and a dumb terminal.
• While initially the computer bureaus handled batch processing, transaction processing became a possibility (which later developed into outsourcing).
• There were no issues of data ownership and the same was true for the location of the data (at the enterprise, at the bureau or in transit).
• Security was not as significant an issue as it is now.
• Vendor lock-in was not an issue—the data were owned by the organization and it could have them processed elsewhere; contracts were simpler, too.
• The applicable jurisdiction was clear. Data rarely crossed borders
• There was little or no legislation on data processing, security or data protection.

Data Owners and Their Data

The data owner should be a business user who understands the business impact of a security incident resulting in loss of availability, confidentiality or integrity.

This understanding enables the data owner to make informed decisions on the actions to be taken to mitigate the impact of such security incidents, including:

• The definition of data management requirements and the specification and/or acquisition of systems and services (including cloud computing)
• Information classification—together with the definition of criteria and procedures
• Requirements specification of specific data life-cycle activities, such as retention and disposal

There are several ways to approach information classification. A short and well-written guide to such classifications can be found in the freely available US Federal Information Processing Standards Publication (FIPS PUB) 199.

Every information system and its associated databases are supported by a number of data professionals that may include, for example, a data modeller, a data architect, a data steward and a database administrator. One of them should be designated to be the data custodian.

Data owners and data custodians should have a shared view of the appropriateness of the various mitigating actions. These, in turn, should be reviewed with officers responsible for risk and privacy. Consultations may also be appropriate with those working on data management and related business processes.

Data can exist in various states and each state has special requirements to ensure data confidentiality and integrity are not compromised: Data can be at rest (stored) and either unencrypted or encrypted.

Other responsibilities of the data owner include defining the retention period for data (often defined by regulations or laws) and authorizing their disposal and the method through which it will be carried out. The data owner is accountable for ensuring data disposal is carried out according to good practices. The more sensitive the data, the more important this becomes.

Whatever the data being disposed of, organizations must comply with regulatory acts (e.g., US Health Insurance Portability and Accountability Act [HIPAA], US Sarbanes-Oxley Act of 2002, the European Union [EU] Data Protection Directive). Participation of the compliance officer and validation by the internal audit function are also essential.

Granting access and privileges to data, the IT function or service provider may provide and operate an identity and access management (IAM) system, which is essentially an empty box. Data owners are responsible for defining who may access various systems functionalities and datasets and what they can do with the data.

Beyond this, the end user is allowed to perform one or more of the following functions on the data: read only, update, create and delete. Role-based access controls (RBAC) can be used to maintain defined individual roles. Exceptions are managed and access and privileges are terminated when the employee moves to another job or leaves the company. Failure to do this can have serious consequences.

Next, come things such as ensuring appropriate data quality; developing, maintaining and enforcing relevant data-related policies; and liaising with other data owners. All of these activities are required regardless of whether the data are processed in-house, by an outsourcing service provider or in the cloud. Having discussed data issues and conducted audits over many years, the authors believe that reality is often different. The main issues encountered include:

• Unclear ownership—Usually, the accountabilities of ownership are divided among the many data players mentioned previously without appropriate governance.
• Unknown data meaning—This relates to a lack of semantic definitions and incomplete or nonexistent data dictionaries, and carries the risk that data captured for one specific purpose may be used for another unrelated and inappropriate processing when converting data to load into a data warehouse.
• Inflexible data structures and legacy systems—These are still around and delivering good service. Some may still use flat files in which records may have variable lengths. These are still in use, primarily for large data transfers.
• More and more data—As the cost of storage continues to decrease, it becomes easy to create and store more data. This may also lead to metadata-related risk. For example, data collected from different departments of the same company may be correlated to provide confidential information on individual work assignments, business practices or external partnerships. The risk may also be potentially damaging to corporate identity, as well as individual identities of employees, customers and partners.
• Large volumes of data—Volume brings the challenge of scale as this alone ensures that some data will be incomplete or invalid, some will have inconsistencies, and some may be untraceable to their source.
• Access controls not always being as good as they should be—People can gradually acquire additional privileges when functional management looks at access control as a chore and simply signs a change control or equivalent document. When computer systems were designed in-house to meet specific business requirements, good programmers created (but did not document) workarounds to allow for bug-fixing, bypassing change controls, or even granting full access and privileges to production data.
• Privileged users—System administrators, database administrators and network administrators all have privileged access to hardware and software, and they require this to ensure that business needs are met. Others can acquire superuser privileges and keep them when their role (e.g., project manager) comes to an end. In a medium-sized organization, such privileged users are known and trusted, but it is rare to find a documented trail of what privileges they have, when their roles or privileges have last changed, and who approved them. Scale works against enterprises and the number of privileged users may be greater than anyone would guess. In the absence of records, monitoring and reviews, any one of these persons could cause significant damage to data, systems and the business.

Migration to the Cloud for Data Owners

Nontechnical matters that must be addressed prior to transferring any data to a cloud service provider include those that have legal and regulatory implications, contractual matters, and domains of risk and uncertainty to recognize and, if appropriate, accept.

Legal and Regulatory
These issues are perhaps the best known and need not be repeated at length here. As legislation continues to develop, from the new version of the EU Data Protection Directive⁵ to the US Patriot Act,⁶ proper analysis requires the collaboration of, at a minimum, the data owner, the procurement function and legal affairs, and, ideally, someone accountable for data governance and IT governance.

The effectiveness of compliance with such legislation is defined by the fines for failure to comply. If these are small as a percentage of the cloud operators’ turnover, this creates little incentive to improve the extent of compliance.

Contractual
As stated earlier, those who have entered into an outsourcing agreement have gained insights into how service providers structure and word these contracts. The providers have signed many such contracts and have access to knowledgeable and experienced legal advice, whereas the entity outsourcing for the first time has much less knowledge of the ins and outs of its procurement and legal services, which may put it at a disadvantage. The same applies to cloud contracts. Such contracts should include the usual service level agreements (SLAs) and guarantees, appropriate penalty clauses, and several other things that may not be necessary in a traditional outsourcing situation, such as:

• Clear and unambiguous definition of data ownership and what this implies in terms of access, copy, distribution, nondisclosure, deletion and destruction, throughout the data life cycle—up to and including exit from the cloud service provider (CSP)
• Data residence details, as well as procedures for data residence changes (server and/or location); contractual measures to ensure traceability of changes
• Classification of security incidents and their associated reporting needs
• Mechanisms for reporting data breaches to the data owner and details of what such reports should contain
• Control requirements, metrics and audits
• Contractual guarantees that data are segregated from the data of other clients
• Description of the exit process, including its associated retrieval of assets and their subsequent usability
• Contractual guarantees that all copies of data made by the virtualization replication process are destroyed upon exit from the contract

From a data owner’s perspective, other topics that a well-designed contract should include are:

• Data access by CSP users, including under what circumstances, for what purpose and how this is reported to the data owner (regardless of whether the data are encrypted). A recent article in the ISACA Journal highlights new risk associated with limited understanding of the consequences of using encryption.⁷
• Monitoring the activities of CSP privileged users and being notified of personnel changes in these roles

Risk and Uncertainty Domains
It is often said that “prediction is difficult, particularly about the future.” Going forward with any initiative or activity involves risk and uncertainties.

Risk is, in principle, measurable and involves making assumptions about threats, vulnerabilities and impacts. In information security, many threats are not random; thus, assumptions become guesses.

In the absence of numbers, practitioners revert to risk matrices with impact on one axis and likelihood on the other, and different colors (e.g., green, yellow and red) indicating degrees of risk. Although subjective, it is better than nothing.

Uncertainty applies not only to the future, but particularly to individual entities. Here statistics are less useful.

At least three driving forces can create risk, uncertainty and even conflict in an organization before migrating to the cloud:

1. Organizational politics—This is unrelated to governance and reflects the real organizational distribution of power (the ability to change the status quo) and influence (getting others to embrace decisions made by an individual). Politics can make governance ineffective and lead to bad decisions. When this happens, it is usually ego driven (or driven by an expectation of promotion and/or a bonus).
2. Cost containment—This is also known as saving money regardless of cost without taking into account unintended consequences and side effects, which are unpredictable at the time of deciding to migrate to the cloud.
3. Pseudo leadership—There are many in the IT industry who are more interested in being among the first to have the latest gadget, technology, software or service; or to be listed in some chief information officer (CIO) top 100 listing; or otherwise impress management and peers. Sometimes it works. Often, it ends badly.

Among the domains that could cause pain after migrating to the cloud are:

• Disputed/disputable definitions of data ownership ending in an expensive and lengthy legal process
• Compliance with cross-border data flow legislation and regulations, which vary from country to country (the EU Data Protection Directive has been implemented into national legislation throughout the EU in different ways), i.e., data may be stored in a compliant domain and processed in a noncompliant one
• Compliance with the Wassenaar Arrangement⁸ on cryptography technologies
• Government access to data and seizures of servers
• Use of undeclared subcontractors, e.g., the CSP outsources some of its processes to another company without reporting this to its clients

Data Owner Controls

Clearly, the data owner must be satisfied that the contractual relationship with the CSP is supported by appropriate controls that provide evidence that what was supposed to happen did and that the result met the conditions of the contract. The data owner should exercise appropriate diligence in assessing the proposed CSP’s history of data breaches and related reports.

However, each control requires independent monitoring, tracking and reporting—all of which requires resources and time and is reflected in the price paid for the service. Too few controls do not provide adequate assurance, and too many controls may reduce the benefits gained from the service.

Data owners and the IT function should agree on the extent of controls to be required and this should match the criticality of the data and services to be provided. Some of these controls may require infrequent reporting, such as certification of compliance to a set of standards or accreditation by an independent body.

Other controls may include regular Statements on Standards for Attestation Engagements (SSAE) 16 (formerly Statement on Auditing Standards [SAS] 70),⁹ or the European equivalent International Standard on Assurance Engagements (ISAE) 3402,audit reports carried out on the CSP by an independent and credible third party. For critical applications and data, it may be appropriate to consider having the right to audit the CSP and/or engage ethical hackers to conduct an assessment of their security arrangements. The Cloud Security Alliance (CSA) has launched the Security, Trust & Assurance Registry (STAR), which provides information on security controls and practices of CSPs.¹⁰ This publicly available register can assist data owners in the CSP selection process.

Other suggested controls may include:

• Validation/testing of the exit process by taking selected data back and running it elsewhere
• Frequency, completeness and quality of backups
• Business continuity—demonstrable capacity including significant Internet outages (i.e., if required, involving the presence of a client representative)
• Data disposal processes
• Effectiveness of data isolation mechanisms and procedures
• Actions by CSP privileged users (with or without misuse or abuse)
• Confirmation that there are no data remaining at the CSP after exit

Cryptography and Encryption

Cryptography is a science focusing on secret communications. The security of the system should be ensured by the secret key and not by the secrecy of the algorithm. Therefore, the data owner should own the encryption key. This is important in situations when data custodians offer encryption services to data owners. The benefits of applying encryption to data in the cloud include:

• Simpler data residence issues as the data are readable by only a limited number of parties
• Reduced breach notification requirements
• No or reduced need to shred data at the time of disposal

• The complexity of key management
• Export restrictions (weapons and dual-use technologies) of some encryption methods.¹¹ These are described in the Wassenaar Arrangement.

Preparing for Divorce

The precautionary principle (“better safe than sorry”) should be considered before signing a contract to migrate any applications or data considered to be mission-critical and/or sensitive to the cloud.

Some of the potential triggers that could drive the termination of a contract with a CSP include:

• Failure to comply with legal and regulatory issues
• Failure to meet SLAs and other terms of contract
• Significant audit observations and recommendations
• Data breaches, unauthorized data destruction or modification
• Use of nonapproved privileged users or subcontractors
• Unilateral changes to contract terms and conditions

External unpredictable triggers include:

• The CSP/client relationship turns poor and/or a loss of trust in the CSP develops.
• Other clients leave the CSP and, as a result, the CSP goes out of business.
• The CSP is the target in a mergers and acquisitions initiative. The new company imposes changes to terms and conditions.

Prenuptial Preparations

The concept of “fail to plan” being equivalent to “plan to fail” applies to migrating data to the cloud. Data owners must give due care and attention to several issues, in particular:

• Prepare, maintain and test disaster recovery, business continuity and crisis management plans to be invoked in the event of a major disruption at the CSP or Internet service provider (ISP). Several major cloud operators suffered unexplained service interruptions in the last couple of years.¹²
• Prepare, maintain and test mechanisms to report data breaches to the appropriate bodies.
• Conduct regular exit simulation tests. These may involve taking a data extract from the CSP and running it in another environment to prove that the data are actually usable elsewhere.
• Develop and maintain a comprehensive exit strategy and associated plans to move the data and data processing to another CSP, an outsourcer or in house.
• Expect, and look for, side effects and unintended consequences of the migration, and be prepared to address them as they arise.

Conclusion

The cloud and its associated services represent a major step forward in information processing and promise to deliver many benefits, both operational and financial. Some cloud services, such as Gmail, have been adopted by many—mostly small and medium-sized organizations—and have operated successfully for years.

Like all new developments, the benefits of cloud services have been seen in the context of potential downsides, side effects, unintended consequences and other unknown unknowns. Organizations whose culture and requirements drive them to be early adopters should consider migrating in stages, beginning with noncritical applications or those where a standard package (SaaS) would meet their needs.

Mission-critical applications based on custom code should be carefully reviewed for suitability to migrate to a cloud environment. Migrating noncritical applications should release resources to focus on higher-value IT and data.

Laggards and those who are not convinced of the potential benefits of migrating to the cloud may be missing a valuable opportunity. Unfortunately, there is no right answer to any of these dilemmas.

Endnotes

¹ This article is intended as a complement to Wlosinski, L.; “IT Security Responsibilities Change When Moving to The Cloud,” ISACA Journal, vol. 3, 2013, bringing in the role of another major player: the data owner.
² DAMA International, The Data Management Body of Knowledge, 2009
³ Projects/OWASP Mobile Security Project, “Top Ten Mobile Risks,” https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
⁴ IEEE Computer Society, “Compatible Time Sharing System (1961-1973),” 2011, www.computer.org/portal/web/cshc
⁵ European Parliament, Council of the European Union, European Union Data Protection Directive, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:NOT
⁶ Congress, The US Patriot Act, www.justice.gov/archive/ll/highlights.htm
⁷ Ross, Steven J.; “A Tide in the Affairs,” ISACA Journal, vol. 6, 2013
⁸ Wassenaar Arrangement, www.wassenaar.org
⁹ SSAE 16, http://ssae16.com/SSAE16_overview.html
¹⁰ Cloud Security Alliance, CSA Security, Trust & Assurance Registry (STAR), https://cloudsecurityalliance.org/star/
¹¹ A useful survey of current legislation on cryptography and encryption is available at www.cryptolaw.org.
¹² Google, “Today’s Outage for Several Google Services,” 24 January 2014, http://googleblog.blogspot.ch/2014/01/todays-outage-for-several-google.html

Ed Gelbstein, Ph.D., has worked in IT for more than 40 years and is the former director of the United Nations (UN) International Computing Centre. Since leaving the UN, Gelbstein has been an advisor on IT matters to the UN Board of Auditors and the French National Audit Office (Cour des Comptes) and is a faculty member of Webster University (Geneva, Switzerland). He can be contacted at ed.gelbstein@gmail.com.

Viktor Polic, Ph.D., CISA, CRISC, CISSP, has been an information and communication technology professional with the United Nations and several specialized agencies since 1993. He is chief of the information security office at the International Labour Organization and an adjunct faculty member at Webster University. He can be contacted at polic@webster.ch.