Making Compliance Cloud-native

Security. Hi there, welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, a product manager for threat detection here in Google Cloud, and Anton Chuvakin, a reformed analyst and member of the cloud security team here at Google. You can find this podcast wherever podcasts are distributed and at our website when we are just so close now when we launch it. Until and after then, you can follow us on Twitter as well, twitter.com/cloudsecpodcast. Our guest today, delighted to introduce her, her name is Zeel Samani. She is a Security Solutions Manager here at Google Cloud. Zeel, welcome to the show. And Anton, the first question is for you today, buddy.

This is a fun topic for me, and I've been dealing with compliance in the cloud in the past, mostly with PCI DSS. So one thing that always puzzles people in this area, and we're going to hit Zeel with a question about this, Cloud is fast. It's kind of for agility, for quick transformation, for rapid delivery of results, but compliance is slow. So how do we succeed if cloud is fast but compliance is slow? What are the usable recipes or the ways to think about it that actually work in the real world?

Yes, you're right. Compliance is slow by nature, and it's even more slow and complex when you're addressing compliance in cloud, mainly because of a couple of things. Number one, compliance is always referred as something which is rearward-looking and reactive. It's a check-the-box exercise for most of the people So it's always a struggle to, you know, get your compliance activities and day-to-day activities, you know, knocked off. It usually takes up time from forward-looking functions such as risk management. If you're keen about risk management, I would highly encourage to read our blog on risk management. So pivoting to your original question about, you know, how do we make this work? You know, cloud is fast, compliance is slow, how do we succeed? So some of the things that, you know, you should keep in mind, particularly to be successful in this space of compliance when you're working in the cloud, is a few things. Number 1, know what kind of frameworks impact your cloud workloads because not all frameworks mean the same thing. This is very critical. Number 2, gain visibility of your assets. You can protect only what you can see, and your audit is also only as effective as the visibility or, you know, what you can really see from an asset perspective. So make sure you have good visibility of your assets, gain visibility of the risks on your cloud assets. And finally, you want to shift left for security and compliance, particularly if you're operating your workloads in the cloud.

That makes a ton of sense. One of the interesting things in my mind about compliance is that it's often so driven by regulation. And people who know me know that I am driven away from regulation, whatever, you know, degree compliance is a thing people engage in. It's something that I, from a personality standpoint, am unable to engage in. So while I'm challenged by it, I'm curious. In what ways are regulations challenging our cloud customers? Where do public cloud customers get hung up?

You're right. You know, some regulations are a little bit more challenging versus others. And this goes back to my earlier point about, you know, learn the frameworks or, you know, get intimate with your frameworks because not all frameworks mean the same thing. So there are certain frameworks which are much more tactical and technical, such as PCI DSS or FedRAMP. And usually these frameworks will end up in a certification or an attestation. So If you're going through a PCI DSS framework, or a PCI DSS audit, or a FedRAMP audit, you will have a PCI DSS certification at the end of the audit. Usually, these type of frameworks are easy to achieve on the cloud because the controls within the frameworks are quite technical. You either pass a control or fail a control. And for such a framework, it is even easy for cloud service providers to produce a customer responsibility matrix. So, you can easily differentiate this is a customer's responsibility versus this is something I inherit from the cloud provider. And then there are frameworks that go beyond the actual technical framework that are technical controls. So certain frameworks such as NIST CSF and ISO 27001, they assess a maturity of the control, which is quite subjective, right? You know, something that is mature to you might not be mature to me. So achieving compliance or aligning your controls, your cloud controls to such a framework becomes a little bit subjective and, you know, subject to interpretation. And then there are frameworks and regulations that really do not have any certification, but they are more like laws and regulations. Those frameworks are a little bit difficult to, you know, achieve in the cloud. You might need additional language, contracting language from your cloud provider to meet the requirements of those regulations and laws.

It is possible to achieve what you need to do in the cloud.

Yes, it is possible, but then you have to put in a little bit more effort It's not as clear as, you know, you check the box, you inherit a control. Yes, you check the box, you inherit a control, you design your own control, plus have some more contractual language with the cloud provider.

So if I'm a public cloud customer and I'm sorting it all out, I get to hang out with you and make sure I've got all the boxes checked, right?

Yes, we should be friends.

Excellent.

So one thing to add to this, you kind of mentioned briefly that there's this thing called shared responsibility model or shared responsibility matrix. So obviously, everybody knows it by now that there's this diagram, and it's different for IaaS, and PaaS, and SaaS. And there are boxes that are green by client, boxes that are red by cloud provider, whatever color. But in many cases, when I see this, I realize that many clients are quite confused about how it really works in the real world. So for example, people pick easy items like, hey, Google is responsible for physical security of a data center if regulation says do X, Y, and Z in physical security, it's very clear that this is Google's job. Google does a great job there. All done. And if you pick something like managing user accounts for a client, very clear, it's very much in clients' hands. Clients own accounts. They manage them. But there are also some items that are kind of in the middle, like network security, certain types of data security encryption. So how do you see the client and provider responsibility split or responsibility matrix for compliance work in the real world? Like, what are the joint items? How do people approach this?

I talk with customers and I tell them that, you know, as you start bringing your workloads on the cloud and as you run your production workloads, as you go through the audits, have a very clear conversation with different control owners and not just your control owners, but with your cloud providers in terms of where the responsibility of the cloud provider stops and where do you pick up the responsibility. So like I mentioned earlier, right, you know, for frameworks such as PCI DSS and FedRAMP, you can have a customer responsibility matrix that is provided by a cloud service provider. Now as a customer, what you should do is take that customer responsibility matrix and then dive deeper into some of their controls and some of the requirements and fully understand, especially those areas where the responsibility is mixed, where the cloud provider says this is, you know, something that will be partially inherited by the customers. Study that responsibility matrix clearly. Now, in terms of, you know, areas such as networking and key management, you know, I used to be an auditor before.

You were?

Yes.

And you and I are friends.

Yes.

If you want to be really good friends with your auditor, you need to provide your auditor with clear diagrams. And a picture is worth a thousand words. And when you start diagramming your workload, you will start to realize that you know, certain responsibilities are of a customer, meaning, you know, myself, if I'm running the workload versus certain controls I am directly inheriting from their cloud provider. So what I recommend is if you get a customer responsibility matrix from your cloud provider, regardless who the cloud provider is, take that, study it, you know, dive deeper into specific areas where the responsibilities are shared between a customer and cloud provider. On top of my head, I clearly say that regardless of the type of deployment, regardless of what type of workload you're bringing to the cloud provider, some of the things will always be retained by you as a customer. Number 1, responsibility of the data, responsibility of securing the data will always be yours. You own the data, will be always yours. Number 2, from where are you accessing the cloud provider? Meaning the endpoints that control the access to your tenant in the cloud, Securing that is always going to be your responsibilities. Number 3, identities and access management, right? Like you have your own identity source, you have your source of truth for your identities, how you federate into the cloud provider, how do you bring your identities, how do you secure them, how do you grant access to those identities, whether they are resources or whether they are programmatic accounts or whether they are user accounts. Securing them is always going to be your responsibility. You will get tools from the cloud provider to, you know, bind them to certain resources, but making sure that, you know, you secure them, you know, will fall on you.

That makes a ton of sense. So one of the things I love about cloud is that everything is driven by these APIs and we have these identities and we can trace who did what, where, when, all the on-by-default logging from a homogenous control plane. That leads users to want to shift things left. What does shifting left look like in the compliance world?

This comes up often, you know, what is this shift left for compliance? So now when we simply talk about shifting left in the context of software development lifecycle, shifting left is about performing tests on your software earlier in the process. And the reason for this is that you want to ship faster, you know, the velocity of the software. So you do not want to be hung up on, you know, testing something Later in the stage versus, you know, you want to test earlier. So, if we apply the same notion to security and compliance, with shifting left, you test early, you defend or, you know, catch any type of bad configurations or bad actors earlier, meaning you harden whatever is on the right-hand side, and then you have your defenses, you test your defenses earlier in your software development lifecycle. It is a little bit difficult in the cloud because cloud is quite dynamic and things keep on changing, but it is practically possible to shift left and, you know, do your security tests and, you know, check for compliance earlier in the process. For example, you know, you are writing an API or you are coming up with an application where a VM instance has to connect to a database server in a cardholder data environment. I used to be a PCI QSA, so I always liked this. examples around PCI DSS. So in the PCI DSS framework, we have a term called Cardholder Data Environment. Anything that is in the scope of Cardholder Data Environment becomes part of your PCI DSS scope. So now if you are writing an application where the VM instance is connecting to the database in CDE or Cardholder Data Environment, it is subject to PCI DSS compliance. And so you want that piece of code or the infrastructure, if you're using IaC, meaning Infrastructure as Code, you want that piece of code that deploys the VM to perform certain checks such as firewall checks before it attaches itself to the CDE. These checks should be performed earlier in the lifecycle rather than the VM attaches itself to the database server and then you perform a check. No, you want those checks to happen before the VM attaches itself to the database. That way you're not violating your PCI DSS checks and, you know, your audits goes faster or, you know, you are not out of compliance.

But it doesn't mean that every compliance professional, every auditor now has to be a programmer and they have to program and then shift left through that. Because sometimes I hear this kind of misconception is when somebody says shift left and everybody hears, I don't want to program. What are you talking about?

You're wrong.

So is this a misconception in its own, right? It's not about programming. It's about doing things earlier.

Yes, it is about doing things earlier. And then, you know, if you want to be successful on this notion of shifting left, you want to take stock of controls, identify those controls which are technical in nature. You want to decouple the outcome of the control. And if the outcome is something technical, you want to, you know, code it as part of your infrastructure as code. So, yes, this is not something where, you know, an auditor will become a programmer, but this is something like, you know, you are in an orchestra, everyone has to be on the same tune, or, you know, you're We have to dance together to make this work.

So, you work at QSA, and now you're involved with the PCI Council, as I hear. Do you think it's kind of hopeless to change that industry? I remember PCI Council in the good old days of Bob Russo and the original crowd. And I remember that they tried very hard to induce the thinking that PCI DSS really does help security. And I was involved in many, many fights with people who kind of argue about security versus compliance. But to me, PCI DSS was meant to improve security. There's absolutely no debate about it. But even today, people argue about it, and it's kind of seen as controversial. So do you think PCI DSS is going to continue to be a useful force, or, you know, is it too hopeless? What's your take on this?

You know, to your point about, you know, whether it would be useful or not, so let's hope for the best. We need to understand that, you know, security is not the same as compliance, and compliance is not the same as security. You can be secure, but you are out of compliance, and you can be in compliance, but you are actually not secure. And there are so many examples where we see that, you know, someone was actually compliant but had a security breach, for example, Target. So let's be clear that the role of PCI Council is to set up this framework or frameworks and guide the industry in how to achieve compliance against those frameworks, which is different from, you know, security. Now, to your question about will they change, I've had very candid conversation with them. What they've told me is that, you know, regulatory bodies such as us, we are definitely slow to adapt to newer technologies, right? Mainly because we cater to a bigger mass. We have to look after, you know, smaller organizations such as, you know, your corner bakery or your mom-and-pop shop, which are not as uber cloud-native or, you know, modern or advanced as large organizations are who are going through a digital transformation. But that doesn't mean that, you know, they are not open to change. They are definitely very much interested in learning about newer technologies, specifically cloud, having more cloud-friendly language in their frameworks. However, this change requires patience, empathy, and humility. And this is true with any kind of change, right? Like, when you want to change something, you have to be patient. Practically speaking, I and another Googler, Anne Wallace, we have been largely involved with the OCI Council. We sat on their cloud task force this year and last year. Now we sit on their board of advisors. The main goal of all of this is to educate the council, uplevel them on some cloud-native technologies and give them options on how to evaluate or make those standards more cloud-friendly. I'll give an example. If you look at the current PCI DSS requirements, one of the requirements is to have a defined DMZ. You need to have a DMZ to pass your PCI DSS checks. Now, having a DMZ in cloud, it really doesn't make sense because how would you define DMZ in cloud? Your identity actually becomes the firewall. We are talking with the council in influencing them to change their narrative around such requirements. Yes, it makes sense to have a DMC. DMC is a great security control, but that is not the only way to be secure and to segregate your cardholder data environment. We have been participating in several task forces, as I mentioned before, and we have also recommended, you know, newer task forces specifically around task forces and special interest groups, one for tokenization and another one for container orchestration. There's a current SIG going on for container orchestration. So, you know, if you're listening and, you know, if this SIG or this topic interests you, please go ahead and, you know, sign up for it if you are a participating organization within PCI DSS. This is for the betterment and good for the entire industry.

How would people sign up for that? Where should they go to find that?

The best way to sign up for container orchestration SIG is to go to PCI Council's website. They have a link where if you are a participating organization within the PCI Council and you want to join the conversations around container orchestration, you can sign up there.

We'll add that to the resources for the app.

So here's my favorite question that always comes in the end. So what are the challenges, mistakes, blind spots that you've seen in your experience when people are trying to be compliant with whatever regulation in the cloud. So think mistakes, challenges, blind spots, maybe risks of certain approaches that people do when they try to think about compliance in the public cloud. So tell us the most hilarious ones, hopefully.

Some of the blind spots are, you know, not assessing your risks. Customers assume that, you know, if you have something running on the cloud, you are probably inheriting the controls directly from the cloud provider. That is a misnomer and a misconception. Going back to our shared responsibility, by just putting something on the cloud does not make you secure. You need to understand—

So wait, wait, wait. They disregard the shared responsibility model completely then, right? They basically think, hey, Google has a firewall. That means we have a firewall. That means firewall is a check. But that's crazy, right? That is crazy.

That's almost as crazy as the people that want to physically ship us firewalls to put into our own data centers.

Yeah. Cloud is great. You get a lot of benefits, but then it comes with shared responsibility. And, you know, like how you buy things, right? You want to test it, you want to try it, and then you want to invest in it. Do not shy away in investing time in assessing your risks for a particular workload before you move to the cloud. So assess your risk, have a thorough understanding about what kind of risks you're going to assume versus what kind of risks will be mitigated by going to the cloud provider. Number 2, I would say, is that your audit community and your regulators are not up to speed in terms of, you know, how the cloud operates. So if you have a regulated workload, be very clear from the beginning, how are you going to go through an audit? So plan early. If you have a PCI DSS workload that is going to run on GCP or any other cloud provider, you're going to go through a PCI DSS audit in fall, you should plan early. How are you going to have that conversation with your auditor? Because the auditor probably needs to come up to speed on GCP terms or whatever cloud provider you're going to use. So, keep that in mind.

Yeah, we've survived things that don't come in 3. We had one guest who had a very simple 9-step plan, although it was a comprehensive 9-step plan.

And now we are at time. Thank you very much for listening. We will post links to the resources and materials we discussed at the podcast site. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, Or wherever you get your podcasts. You can follow us on Twitter as well, twitter.com/cloudsecpodcast, and your hosts are at twitter.com/anton_chuvakin and _teampeacock. Tweet at us, email us, argue with us, and if you like or hate what you hear, we can invite you to the next episode. See you on the next Cloud Security Podcast.

Security. Security.