The protection of data and information in cloud services demands consideration of various goals and regulations. We spoke with Mark Grosser, Managing Consultant and expert for Security & Compliance at Detecon. Read Part 2 of the interview here. (Read Part 1 here)
Question: What security issues arise in the course of cloud implementation?
First of all, an old friend, the subject of “identity and access management,” returns as a major issue when using the cloud. What questions are asked? First: Who are you? Authenticate your identity! And second: What are you allowed to do? What access rights to what information and documents are you allowed to have? Who (or what set of rules) decides and controls your rights?
The cloud does not solve any of this automatically or easily; precise management and control are still required. There are often cloud-based microservices that are used (for example) in the HR department. This raises questions such as which employees are allowed to see recruiting information and what data otherwise require protection. A separate “technological layer” in the cloud and, in addition, the “Federation Services” established as standard — features that orchestrate secure logins for own and cloud-based user administrations — in conjunction with app-based authentication procedures allow good general access controls with a high level of user friendliness.
I see more of a risk with the users themselves. Access to data for workgroups, “threads,” and all types of cloud-based data repositories are certainly collaboration-oriented (link instead of “email attachment”) and can be steered according to differentiated criteria. But who sets up this “collaboration” exactly, who is in charge of (who owns) the data actually? In practice at least, not a central administrator based on a “need-to-know authorization concept.” In classic applications, roles can be assigned (e.g., reader, editor, administrator) as well as be bundled into specialist roles and steered across several applications. Cloud services, in contrast, begin with mere logins to online portals that can no longer be differentiated by role. Licensing issues and authorization concepts must now be adapted to other technical implementations.
But — if data are stored centrally and clearly classified, cloud services certainly offer the option of managing from a central point user and access control technically (confidentiality) and, for example, of using file versioning to ensure the traceability of the integrity or non-deniability of processing steps.
But even without the cloud, the basic idea of “data lakes” and “data analytics” means “all data in one pot.” So access rights must be controlled, e.g., to protect effectively information classified as “confidential” — or to erase it specifically and verifiably at the end of the retention period. This necessity becomes even more urgent under cloud conditions.
Question: How do you properly protect data and information in cloud applications?
What information requires protection, why and how? The three traditional protection goals are confidentiality, availability, and integrity, the latter referring to correctness of the data. There are many technical advantages inherent in cloud services, but traceability and control over the protection of information must often be resolved through the use of various and more complex methods.
Even if a high level of security can be achieved through cloud native services, ISO 27001 certification is not always automatically included. Certified information security — like data protection and compliance — demands a complete management system encompassing specifications, processes, resources, skills/know-how, plus organizational and (but not only) technical measures.
The imperative first step is to assess the as-is situation. It includes the development of a cloud strategy with the right mix and ultimately a transformation without undue expenditure.
Yes, many processes and technical measures compliant with standards are included “in the complete package” offered by providers. However: who makes the rules here, who retains real control in the end? First and foremost, there must be clarification of what is important for the specific company — security, data protection, and compliance must be constantly ensured and controlled. The responsibility for this cannot be outsourced “qua cloud.”
Question: How can globally active companies determine whether their data protection systems are in compliance with local regulations?
Global activity means dealing with different legal systems that cannot be evaded. Non-compliance can be punished in different ways in different countries and can have major consequences. The various data protection levels must be evaluated relatively to one another. From a European perspective, this means application of the GDPR’s standard for “third country transfers” to the USA, India, or China (as examples). There is a two-track method for checking compliance. First, what are the legal grounds for the data processing? Second, is the processing lawful within the meaning of the GDPR? We are all familiar with the related “Schrems II” discussion. These questions should be clarified before a cloud-based global service such as remote maintenance of a machine in China, France, or the USA is offered.
Checking lawfulness (cf. Article 44 et seq. GDPR) means determining whether there is an adequacy decision by the EU Commission or EU standard contractual clauses or binding internal company data protection regulations. Unfortunately, even the newly revised EU standard contractual clauses for data exchange are not specific enough to determine clearly the residual risk (e.g., civil lawsuits). They could be dubbed a “simpler form of the GDPR” and include, among other things, a requirement to recognize jurisdiction of EU courts. The joint risk assessment of the parties involved in the data processing is mandatory and in any case will not be simpler than before. The formal risk assessment (data protection impact assessment) is a mandatory action from the perspective of the data subject. Additional market standards must be observed alongside the GDPR for the technical and organizational requirements; in Germany, for example, the requirements of the Cloud Computing c5 Criteria Catalog from the Federal Office for Information Security (BSI) remain effective. At the European level, the EU’s cybersecurity agency ENISA sets the standards. The challenge is to look at all these aspects from the perspective of your own organization, including the “technical stack,” and the cloud and data consolidated there and to merge them into a consistent model.
Question: Sounds complicated. What are the ways out?
The protection of information is relevant out of self-interest (data critical for business, trade secrets) and from a legal point of view (privacy of personal data to secrecy from a national security perspective). A risk analysis is always a good method for accurate recording of the specific information “at risk” and the need for protection in terms of these requirements, and is an essential action for an informed (and documented) decision for cloud services. In principle, technical solutions such as encryption through “intermediary” procedures and pseudonymization of data can help.
An intermediary authority between cloud providers from abroad (such as in the USA) and companies (“data controllers” within the meaning of the GDPR) in Germany can minimize legal reservations, but, unfortunately, is contrary to the creation of security by means of “native cloud solutions.” The degree of your own control determines your own responsibility. If your own emails are encrypted prior to entering the cloud and the provider does NOT have the “key,” malware, for example, can no longer be identified via cloud solutions. Ultimately, the customer is responsible for minimizing the security risks from its own data processing. The advantages: Access by foreign authorities (for example) is prevented, and state-of-technology integrity and confidentiality of the data (e.g., for business secrets such as design plans and patent-relevant data) are guaranteed. At least to some degree, however, this means that the advantages of the cloud solution are no longer technically possible. And the encryption procedures themselves are subject to technological development and should be future-proof, i.e., comply with the minimum standards on procedures and encryption depth. Current projects for the further development of cryptography are aimed at new possible methods in security, e.g., via quantum key distribution.
Question: Are there any other recommendations for a safe step into the cloud?
In principle, the challenges I have mentioned must be mastered mostly in interaction with various cloud and on-premises technologies (“across the entire stack”) rather than just in a cloud, perhaps even with different providers in the so-called multi-cloud environment. And let’s not forget: when changing providers as well, which should always be part of calculations. The fact-based, active decision for adequate data protection requires a documented risk analysis and consequence assessment. This is the starting point for taking all internal and external stakeholders along on the journey to the cloud. Risk-based can mean that non-cloud or private cloud solutions are elements of the strategy. Besides management systems, the establishment and operation of an efficient security operation center or cooperation with a service provider must be at the top of the list for state-of-technology security. This is the only way that monitoring can be used to make quick, informed, and targeted decisions and actions in the event of malfunctions or events relevant for security or privacy.
Keep control: fast, efficient cloud technologies also require fast, efficient technical means of control. And — frequently in contradiction to actual practice — the decision about the cloud technology or platform should not be the first step; it should be preceded by a requirements and needs analysis based on the business strategy, the IT strategy, and, as appropriate, other strategy elements. Ultimately, the customer always has legal responsibility — so governance should also be its purview as far as possible! All technologies (and contracts for them) currently in use cannot be migrated to the cloud completely and across the board — but the majority can. A cloud strategy with a perfect fit cannot grow without this knowledge, but then includes, for example, the modification, relocation, or new purchase of cloud-supported applications. State-of-technology security and data protection are constantly changing. Like any business decision, their design should be determined deliberately and in orientation to risk.
Thank you for the interview!
Das Interview führte Gerhard Auer.
The interview was conducted by Gerhard Auer.