Steven Woodward on Cloud Security Issues
Steven Woodward, CCSK, CSQA, CFPS is CEO, of Cloud Perspectives. As NIST Cloud Audit and Cloud Carrier Co-Lead, Cloud Security Alliance (CSA) Canada Director, IFPUG ISO/ IEC 20926 Chair, ISO/ IEC JTC1 SC7 & SC38, he wears many hats. He’s currently consulting for the Canadian Government.
You've been working on geo-jurisdictions, cloud federation, edge computing, pricing and service level agreements, and security and privacy, which covers it all, right?
Yeah. That's the problem.
Let’s talk about geo-jurisdictions to start. What advice do you have for IT leaders when it comes to issues of data residency?
They need to perform comprehensive analysis and understand where the data will reside, and that includes evaluating where it's stored, computed, and moved. So, it's just a matter of getting those things clarified up front. You may discover you have multi-national or multi-jurisdictional policies and regulations such as the Trans-Pacific Partnership, or GDPR, or other regulations where it's multi-jurisdiction as well as your enterprise policies and regulations you must adhere.
In some cases, you run into problems when you can't even use the proposed software solution within your jurisdiction because it's just not offered.
Interesting. When you talk about where it's stored, you're talking about the location of the physical server.
And where it's transmitted to would be all the jurisdictions it moves through or to?
Correct. In some cases, you might even have data hopping across multiple jurisdictions, potentially.
So, everything has to be legal through all of that transit.
Correct. Legal and also just a level of being comfortable. For example, you might be willing to accept the risk of having the data moving through a country, recognizing it provides an additional level of redundancy or resiliency to your solution. So, the example I use in Canada is that by default, any phone communications typically run through the U.S. if there are any latency issues at all with the Canadian route.
Now, if you have regulation or policy in place saying no data will flow through the U.S., you need to recognize that if there is a significant outage in Canada because someone with a backhoe took out one of the main fiber lines, that the level of resiliency is not going to be there. This means that geo-residency policies can impact the resiliency and reliability of the solutions.
A great example of why you need to be aware of those considerations and try to make an informed decision. What warning do you give organizations that don't believe data residency is a concern for them?
Well, it's kind of interesting, because in the E.U., when you talk to people, they say, "Well, of course, the data's crossing our country boundaries, so why would you even be concerned with it?" Right? In Canada, it's more of a concern, I believe with us being so close to the U.S., where we have the U.S. Cloud Act in place. You have U.S. disclosure orders in place with it. So we're a little bit closer to being aware of some of those issues, and it becomes political, quite often.
I don't see it as being as big of a deal as what I know a lot of people see it as, because you should be encrypting your data anyway. So, if you take appropriate precautions and you are encrypting your data or tokenizing your data, so what?
That said, then it becomes increasingly more political. So yes, you're holding onto your encryption key, those encryption keys are staying within Canada or the token translation tables, are waiting within Canada. But, the actual data is residing in the U.S., then the only real concern is what if someone says, "No, I'm not going to give you back your data." Right?
Another unlikely scenario is where you're dealing with data hosted in a country that you're on unfriendly terms with and they go, "I'm not giving you your data back, and I know it's going to have major economic disruption for you." Then, of course, that has to be a consideration. But, for countries like those under the Five Eyes International that have agreements in place and have similar cultures and business procedures, I don't think it should be that big of a deal.
For those unaware, the Five Eyes, (FVEY) is an intelligence alliance made up of Australia, Canada, New Zealand, the United Kingdom, and the United States. They are parties to the multilateral UKUSA Agreement, which is a treaty for cooperation in signals intelligence. Okay. Give me a high-level description of the U.S. Cloud Act. Why is it important?
The Cloud Act has two major elements. One element is that they provided clarification that the U.S. has the right to issue disclosure orders on any data centers outside of the U.S. as long as they follow the U.S.'s judicial processes. This clarifies the fact that if you do have any U.S. data centers running in any country, then the U.S. can issue disclosure orders. This resulted from the Microsoft disclosure order years ago that happened in Ireland. There was a lot of confusion in terms of, could they ask for it? Could they not ask for it? What this act can clarify is, yes, they can ask for it.
The second interesting aspect, which I don't know if it has been thoroughly thought through, is that to my understanding is that any non-U.S. company or country can issue a disclosure order to a U.S. data center, as long as they have followed their appropriate judicial processes and procedures for such catered requests.
Okay. So, a company in the E.U. could issue a disclosure order to a U.S. company as long as the E.U. country followed their legal requirements?
Exactly. And I can see that working reasonably, for again Five Eye countries. Where the cultures are similar and where the business practices are similar. But last time I read the text, and maybe it's been updated or has been clarified too, it didn't say that. So what if you're dealing with an adversary? Pick one. This adversary says, "Well, we followed our processes." Which is stating, "I don't like this guy; give us his data." And they say, "Well, that's our process." And I think in some of those cases, the U.S. is probably going to say, “Whoa, I don't think so. Nice try.”
Yeah, it sounds like it's pretty much indiscriminate reciprocity. What advice would you give IT leaders as to how to go about doing a geo-jurisdiction analysis? How would you advise that they get started if they all of a sudden go, "Whoa, we've got data all over the place and we're operating in multiple countries with data centers in multiple countries." How would you advise that they begin the process of lining out and charting where all their data resides?
My recommendation would be to use the standards in place that help to categorize and classify the data. Because a lot of the decision-making and the options are going to be based on those categorizations and classifications. Categorizations such as, are you dealing with healthcare information or with air control traffic information? Or are you dealing with we're out on vacation information? And classification is more along the lines of types of security classifications and risk classifications.
Is there a single point of reference where leaders can go to find all of this information and these standards?
Yes. One of the best ones is under ISO 19944, the data classification for cloud computing guidelines. They're updating it, and I had to review it in the last couple of days.
How have security requirements changed in this new environment?
Security has gotten more challenging in the cloud, because of the fact you have more risk exposure points. If you think back in the traditional world, you could see where those were connected; they were physically connected, physically cabled. Or they were located within your firewall or your protective networks.
In the cloud world, now we're talking about more public IP interconnectivity. That brings additional risks and concerns around multiple exposure points that were not there previously. And there's a pendulum swing that's just starting to happen. You and I are old enough to recognize the pendulum continually swinging between centralization and decentralization.
So, the cloud plane was centralization. Well, now the pendulum swing's coming back to decentralization, and what's happening now is that organizations are recognizing some of the limitations of cloud, because of the connectivity constraints, sometimes the security constraints, sometimes the process constraints, where now they're trying to use decentralized capabilities such as edge computing and fog computing, where they compute in the storage and the different cloud services that are actually being hosted physically closer to the consumer. Or they're being architected in such a way that there's more of a distributed processing taking place rather than centralized processing taking place.
As far as security requirements go, when I talked to you in 2017 about CSAs and SLAs, I also spoke to the CIO of an American company called DryBar. And what he said was that they had drawn up their security requirements and required that all their providers comply with their security requirements. Is that something that you would suggest for other IT leaders?
This is where it gets tricky. So, for the U.S. government, they will mandate that if you're selling any cloud services to the U.S. Federal Government it has to be FedRAMP accredited and certified. That's how they have that assurance evaluated. Specific security requirements can vary so much where all of a sudden you're not going to get the value from the cloud services. If you say, "Hey, you have to meet our unique 300 security controls." What cloud providers have done is try to architect things at a high level of security, recognizing that then they can offer it at a reasonably low-cost point, because there's a standardized level of protection across the board. Most won’t customize because it's going to have significant ramifications on their entire architecture.
Are there sections of a Cloud Service Agreement (CSA) that you suggest people focus on more than others?
Sounds needless to say but my recommendation is to read them. Quite often there might be a significant gotcha within the actual agreement itself. It can be just in the section under Terms and Conditions, such as, "We will own your data." And you read that, and you think, "Well, no." Walk away from that vendor. Quite often, there are significant gotchas in those agreements that aren't hard to find, just read them through, carefully.
Sure, can you give me another example of a significant gotcha?
Yep, another one would be, let's go in a slightly interesting direction. We're going to guarantee as part of our service level agreement (SLA) that you're going to have availability 100%. That rings an alarm bell in my mind. Because how can you guarantee that? At 100%? Then you read further into the definitions, and you realize how they calculate their availability. So, how organizations calculate the SLA metrics varies from provider to provider. Some providers might say, "The way we calculate it is as follows: If you are unavailable for ten minutes, we don't count that." You can have an average of 9 minutes and 50 seconds, and then they're up for 30 seconds and then they're down for another 9 minutes and 30 seconds. We classify that as 100% availability. So, you need to understand the number that they're providing and exactly how they are calculating it.
The other example that I use is, quite often in their SLAs and terms and conditions, it might have statements such as, "We reserve the right to stop any particular service or function at any time. Or, make changes to any service or function at any time." Those become challenging because you might have bought Product X because of specific services. You need to understand and have an excellent trust relationship with the provider. Because, if they have those types of clauses, then you need to be comfortable that they're not going to pull the rug out from under you and all of a sudden stop some of the services or API's that they had provided to you that have great value. You might be seriously leveraging them and all of a sudden they're gone in two weeks.
Now, what are the odds that a provider is going to intentionally upset their customer base by doing some of this? You would hope they're performing appropriate analysis where they're not going to bother their customer. But, there's a level of trust.