Post by Ayal Yogev, CEO & Co-Founder, Board Member, Anjuna Security
For many years the term compliance and public cloud could not possibly go together in the same sentence. Even today, many organizations avoid the cloud due to fears of privacy exposure or compliance requirements—concerns over loss of control and lack of trust. At the same time, eschewing the public cloud has meant being at a competitive and economic disadvantage, with limitations on scalability and agility that may have significant strategic costs.
Risk and compliance professionals, along with security leaders, are beginning to reverse the long-time question of whether the public cloud is secure enough and a trustworthy environment to meet risk and compliance goals and requirements and now consider that the public cloud, with its latest technologies, may represent the best means to assure compliance and mitigate risk. In other words, it is likely that now it is no longer a question of the public cloud having sufficient protections but that it can provide the best way to attaining and maintaining compliance.
Besides evolving and exacting privacy laws from California, New York, the EU and numerous other places, new thinking around the use of public cloud to advance compliance stems from several concerns. The first represents a shift in treating data security as a collection of security tools, policies, practices and personnel (applications team, cloud team, desktop/endpoint team, etc.) to one that is unified and offers consistency, uniformity and simplicity. There is a strong desire to make data security a native capability that exists wherever data is located or used. This also means that, ideally, data is secure regardless of its state—in storage, transit or during execution.
The encryption gap that now widely exists when applications and data are executed on CPUs within servers has become a well-known issue to security and risk professionals. Data and code can be encrypted when it is at rest or being transmitted, but it has had to be in the clear when being processed. This gap opens data, application code, proprietary AI or machine learning algorithms, private encryption keys and other digital assets to competent, motivated attackers, insiders or third parties to glean from computing environments—in the cloud or on premises. The gap introduces significant risk and makes it impossible to truly comply with privacy law and data regulations.
Second, and similar to making security and compliance uniform and native to data, is the desire for data security by default. Here the goal is reduced complexity, more straightforward management and fewer points of potential failure, particularly that involving human error. Data security by default not only helps ensure that various regional privacy and regulatory requirements can be more easily met—even at a distance—but that misconfigurations and simply misinterpreting various requirements can be mitigated. Problems and mistakes can be avoided through use of consistently applied data protection that protects data and upholds compliance by default, regardless of the law or locality. Changes or modifications to the default protection are the exception rather than the rule.
Locking down data in all of its states, constantly, consistently and without a gap ensures security and compliance. In addition, the encryption mechanisms currently in use within an organization through applications, browsers, email, drive encryption and other components create a substantial challenge in knowing whether and how data is being encrypted. Questions such as, where is the point of decryption or the termination of an encrypted tunnel; what level of encryption is being applied; are certificates current and valid; and other important issues should have straightforward answers. Unfortunately, the reality is that the vast complexity and rat’s nest of encryption use throughout the enterprise is anything but straightforward and easy to manage or understand. Mistakes—sizable ones—do occur based on misunderstanding of whether and how something is encrypted. Making encryption a single mechanism that spans all uses, users, locations, applications and places of storage strengthens security and risk postures rather than subverting them.
A third consideration around using the public cloud to better compliance is around the concept of isolation. The primary reason that the public cloud can be considered at all is because of several key advances. Some time ago, the leading CPU manufacturers began incorporating a way to lock down data and code within the CPU and make it impervious to attackers, insiders or third parties of any kind. Even those who gained root access to servers are shut out of seeing or accessing data or resources. This major advance was adopted by public cloud vendors, freely and widely provided as confidential computing or a similarly-named capability. In effect, workloads in the public cloud can now be fully isolated and the environment now under the exclusive control of its owner. The public cloud can be a trusted environment.
The one drawback to using the lockdown/isolation capability has been that it required changes to application code or IT processes, making it impractical for the enterprise or wide-scale deployments. New technologies have surfaced to make the use of runtime encryption fully transparent to application code and processes and eliminate the need for modifications.
All of these factors make the public cloud viable and appealing for organizations to advance their compliance and reduce risk. A 180-degree shift has occurred, from the cloud being considered an untrusted environment to one where it actually improves a security posture and the ability to comply with regulations and requirements. With the additional considerations of native data security, security by default, uniformity, less complexity and isolation, many organizations are discovering that the public cloud can offer less risk and better compliance. Those who have not made the transition should seriously consider it.
Ayal has 20 years of experience in the enterprise security market, serving most recently as VP of Product Management at SafeBreach. Prior to that, he led the Umbrella product management team at OpenDNS, which was acquired by Cisco in 2015 for $635M. Ayal has also held senior product management positions at Lookout and Imperva, and he was part of Imperva’s IPO in 2011. Ayal holds an MBA with honors from UC Berkeley Haas School of Business and a B.Sc. Summa Cum Laude in Electrical Engineering and Computer Science from Tel-Aviv University.
Indeed….cloud providers such as AWS, Microsoft, and Google have developed very strong security practices and also are very active in maintaining their certifications with industry recognized programs to show their continued commitment to security.
However…there is one aspect that I don’t think was emphasized in the above article…which I thought was very good by the way…which speaks to compliance requirements.
As someone who has worked with these public cloud providers and others, on important aspect that they recognize is that despite their top notch security and controls, they all recognize that in some industries such as banking and healthcare, there may be compliance related reasons that these cloud providers will actually direct their customers not to use the cloud for various reasons. Even though some of these can be cured by setting up one’s cloud environment to ensure that data is maintained within the U.S., for example, when looking at the whole picture…it may make more sense to not use the public cloud.
There is little or no doubt that the adoption of the cloud and how its use is a major contributing force in an organization’s digital transformation, making sure to look at the compliance-related implications of its use should be front and center when deciding on whether or not or at what level an organization will migrate IT activities to the Cloud.
Frank
Comments are closed.