EP161 Cloud Compliance: A Lawyer - Turned Technologist! - Perspective on Navigating the Cloud
26 Feb 2024 · 28 min
In this episode of the Google Cloud Security Podcast, hosts Timothy Peacock and Anton Chuvakin interview Victoria Geronimo, a former attorney turned Cloud Security Architect at Google. Victoria shares her unconventional career path—from a J.D. at Fordham Law and work at the Center on Law and Information Policy, through a stint as a penetration tester, to her current role shaping cloud security and compliance. The conversation explores how cloud environments reshape compliance questions, the tension between legal and technical perspectives, and the practical challenges of translating regulatory requirements into cloud controls. Victoria recounts a real‑world audit conflict over encrypting email attachments versus virus scanning, discusses the misconception that cloud is merely “someone else’s data center,” and explains how Google’s scale, engineering talent, and standards‑development work address these misconceptions. The dialogue also touches on diversity in tech, the importance of audience‑aware communication across lawyers, engineers, and business stakeholders, and offers resources for further learning. Throughout, the hosts maintain a conversational, light‑hearted tone while probing the nuanced interplay of law, policy, and technology in modern cloud compliance.
Chapters
Security.
Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the Senior PM for Cloud Detection, Investigation, Response in Chronicle, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button in your podcasting app of choice. You can follow the show, argue with your hosts and the rest of the Cloud Security Podcast listeners on our community page. Our community page is very exciting, very new, and you can find the link to it in our show notes. Today is an extra special episode because it also features video content, which is available on both our website and our YouTube. And today is a special episode in our Voices series, and we are delighted by that. Anton, I thought this was a super fun episode because our guest also has a background like mine, interdisciplinary one, a weirdly educated one for the role that they ended up in. I really liked it. I found myself like, It felt like a kindred spirit.
Yes, and I think that the episode is way more exciting for what people would expect if they hear that the guest is a former lawyer.
Yeah, don't hold that against her.
Yes, exactly. This is, like, very important in this case.
Also, don't hold it against this episode that it's largely about compliance. This turns out to be a really— maybe if it's like, uh, you know how, like, 2 negative signs cancel each other out, you get, like, minus sign, minus sign, positive. Do you think that's what it is?
I think it's that. Yes, exactly that. It's this episode, which I guess is also in the made compliance made fun kind of bucket as well, because ultimately it's not just about let's explain compliance and invite a lawyer for it, but it's also about how compliance is interesting in the cloud specifically and how people can make it more challenging for themselves sometimes.
Yes. And about how compliance and security don't always line up one-to-one for people. And I think our guest does a great job of Making sure people think about both aspects, not strictly one, not strictly the other. So maybe with that, listeners, let's turn things over to today's guest. All right. And with that, listeners, we are delighted to kick off another episode in our Security Voices series. We're joined today by Victoria Geronimo, Cloud Security Architect here at Google Cloud. Victoria, thank you so much for joining us today. There are so many interesting aspects of this episode. One of the ones that I want to start out with is the combination of your background And the intersectional space in which you work. And maybe I don't need to tell you your background. Maybe tell our listeners your background and how that informs your work at the intersection of, like, compliance and security and cloud.
Yeah, sure. So, I have a J.D., which means I graduated from law school, a failed attorney. I went to law school because it's intellectually stimulating. There's a lot to love about the law. It's kind of setting the policy for a lot of what happens to us as citizens of the U.S. And I quickly found out after one of my summer internships that I did not want to be a practicing lawyer. There's a lot of paperwork that happens and a lot less like of that fun intellectual thought processes that happen. But one of the classes I really did take a shine to was internet law and policy.
Where did you go to law school that you were lucky enough to have a class like that?
Fordham Law in New York City, which is where I'm based and where I stayed ever since. They have a really great program. It was started by by somebody who has since passed, Joel Reidenberg. He has something called, or started something called the Center on Law and Information Policy.
Oh, cool.
Which is where I spent my time after I graduated law school. And it's basically a policy think tank and it's part of the law school, but they also do their own separate things. And it's really meant to get lawyers and technologists together to think about either future issues that may be coming down the pipeline or current issues at the intersection of technology, internet, and law. When I was there, it like the Snowden case came up and the leaks were there. So that was like a really big deal that got me kind of involved in the first place into the space. And then after that, although I really enjoyed the policy part after I graduated law school, there's a lot of conferences you go to and it's a lot of lawyers in the room and the lawyers and the judges, you'll be reading the case and they don't necessarily understand how the technology works. Like they're using these analogies, like. Email is like the postal service, and it just like, it doesn't— they're trying to make sense of it in their head, and I understand it, but it's not quite what the reality is. So I found that, and this is another lesson from Joel Reidenberg, the most effective policymakers are ones that have some hand in the technology pot as well and actually have a deep understanding of the things they're making laws about.
That makes a lot of sense to me. And if you're listening to this, listeners, as just the audio podcast, you will miss out on the horrible faces that I just made during I'm loving hearing that analogy. So check out the YouTube stream of this as well. Now, at Google, what are you working on here? Because I didn't introduce you as part of our policy team. I introduced you as a cloud security architect. So how did you end up doing this?
Yeah, so to be completely honest and not to kind of whitewash everything, graduating law school and choosing not to be a lawyer is a really, really difficult choice.
Is that a shorthand for financially ruinous?
Yes, financially ruinous.
That is so different from physics. If you graduate with physics and you're not Yeah.
And people really want you because you're probably very smart. With lawyers, it's a toss-up whether people are gonna like you or not. And so, I knew I wanted to do, like, this— I had a long-term plan of wanting to go back into policy and internet law and policy. And I also knew that I needed to have more of a foothold in the technical world, but I didn't really know where to start. And so, I was, Like, as much as I would like to say I worked according to a grand plan beyond that, and I had everything figured out, it was a lot of me sending out applications, like, everywhere and seeing, like, what landed. And what landed was a penetration tester. So—
No kidding.
Yeah, he was starting up his own security practice within a larger managed services organization, and he needed somebody to help him with the actual, like, how do I— I got into their system, I figured out how to kind of where their weaknesses were, but they want me to map this to a compliance framework that they have to adhere to. Like, can you help me do that? I'll teach you the security stuff if you help me with, like, this reporting stuff. So, that's how I got started. So—
That's amazing.
Yeah, he set me up with, like, a little Raspberry Pi, and I, like, got to, you know, like, hook it up and try to figure out, got to do some fun social engineering stuff. And from there, I kind of hopped around to various InfoSec jobs, and I really enjoyed it.
And now you're here.
And now I'm here. I got the call from Google.
But as a convert from that area, would you be more, like, naturally aligned to deal with, like, less techie parts? It's almost like I almost feel like I want to put you in a box against your will, and I feel bad about doing this, but, like, would you be more natural with, like, compliance and stuff like that? So is it me being judgmental, or do you really deal with this stuff?
And Victoria, you got to be really careful with Anton putting you in a box. He was a quantum mechanic, and so if it's like a Schrödinger box, be very careful.
But she's not a cat, so it's like kind of important, right?
Ah, that's fair.
Well, it's all about probabilities. Have you measured me yet? Um, so Anton's looking at me now and he's like, now that I've measured you, um, you are this, you are in this quantum state, you're in the lawyer quantum state. So, I'll be honest with you, like, the tech part is not as natural for me as the policy part, but it's still not rocket science, right? There's, like, a lot of— what it takes is getting your hands dirty and, like, wanting to actually get in the weeds and just deploy stuff and just kind of, like, put your hands on the command line and, like, see where it goes. And, like, having a use case is very, very helpful.
Mm-hmm.
So working for Google and working for my prior companies where I had use cases and it was just kind of like, go figure it out. I'm very good at that. And I think that's what a lot of people in the technology space are very good at. It's kind of an open secret that a lot of us just, we don't know the answer until we're presented with it and then we figure it out. So I think that's something that, as long as you are okay with like that constant sense of like, I don't know the answer to this, I have to go get my hands dirty and figure it out. Then like you'll probably be fine.
You know, I love that answer. I used to work for this guy and he would always say, if we knew how to do it, we wouldn't hire software engineers to do it. And I think that really captures it.
Yeah.
I want to just start asking compliance questions, obviously, because I want to like, so not because it's just ginormously exciting, but ultimately it is a little bit exciting because in the cloud.
We'll allow it.
So does cloud make compliance easier? Like in your mind, would you, if somebody used to use my favorite 3:00 AM test, if somebody wakes you up at 3:00 AM, and says, Victoria, does cloud make compliance easier? Would your answer be more no, more yes, or more let me be?
Or go back to sleep.
I would say, then what? First, I would ask for the comparison. But I would say no. I would actually say no. And I know that's not a popular answer, but—
That's okay.
I think we are better off on the cloud overall. I think that with cloud, it has, it has been in the news a lot more than a data center ever really was. And what happens is, as I've noticed, people are asking more and more questions. And that's part of it as a result of it being in the cloud, and they can kind of see what's happening. They have some— they don't have to manage the infrastructure part as much, and that's awesome. They don't have to kind of hire out a data center.
Mm-hmm. Mm-hmm.
But they are asking a lot of questions of each cloud provider and being like, how are you doing this? How are you doing that? They're getting really in the weeds on a lot of use cases and a lot of compliance use cases. So, while perhaps overall it makes things— I think it makes things more secure. I think, though, it also forces people to kind of confront a lot of things that they never confronted before. So, in essence, because of that, it's harder because now they're actually asking those questions, if that makes sense.
And are those maybe better questions to be asking that lead to better outcomes, or are they just different? Not to lead the witness.
It's a pot. Like, there's— I think it's really great that people are thinking a lot about, like, hey, what do you mean about encryption at rest and in transit? Like, what do you mean? Is it really all of the time or is it not? Like, I think it's good for people to be thinking of that. However, I have been oftentimes on the receiving end of kind of rabbit holes that aren't worth going down because maybe it checks a compliance box and you have that black and white thinking, but the security story is actually much more complex and there's a lot going on. And if you try to be completely truthful with the whole answers, it ends up opening up a can of worms where— People, like, the point is, is my system secure? Is like really what it comes down to at the end of the day. And what those kind of elaborations can get into sometimes, like, one, I'll give an example, is like, a common one is like, can my cloud provider ever access the content that I upload into Google Cloud or into Amazon or something like that? And it's like, well, yes and no. Like, no, we don't do that because that violates contractual terms, but like, yes, it is theoretically possible, like, we're not going to lie to you. And then, that distinction can kind of really put people's heads into, like, a weird headspace where, like, okay, well, like, then when are you going to, when are you not? And it's, at that point, it becomes kind of counterproductive to just getting the work done.
So, does it mean that it's more different than easier? So, then, it's also kind of an easy cop-out from this complicated frame-up. Compliance in the cloud is just different?
Perhaps then, like, what I really mean is, For customers, I would say that things are more secure than ever because, like, I think security gets better and better. I think the way that Google Cloud and what we're familiar with about our infrastructure is amazing. It's absolutely amazing. But we are getting smarter as well with it. And that makes things harder overall for, like, just actually my job to answer those questions and to figure out kind of more from a customer interface perspective. Like, I guess my job's harder, but maybe we are more secure. Is where I land on that.
Does that mean that users are asking the wrong questions more frequently? Have they gotten better at asking the wrong questions instead of getting better at asking the right questions?
Ooh.
That's a tough one and it's a mixed bag. I've found that it really depends on customer by customer. We have some customers who should be asking more questions and they're not. They're just kind of like, oh, this sounds great. Like, see you later. We'll take it. Then, we have other customers who understand there's something called risk management, and that, like, there's no such thing as, like, every, you know, you can have a completely air-gapped box and then also perfect usability and perfect latency and everything like that. And they kind of have that sense of risk and reward and sort of, like, where the balance lies. And they just want to be aware of what the risks are so they can make their own best decision. Those are probably the customers who I think have the best head on their shoulders with, like, asking the right questions. And then, And we have just some other folks who will, and these tend to not be our customers, like they kind of come in. I've had people accuse me and Google of like stealing their information because of like something they read in the news or something like that. So that can be a little bit different. And it's like, no, we don't do that. But—
There's a lot of misunderstanding out there, isn't there?
Yeah. Some quite crazy.
It's a lot. It's complex. When you are also a large company, people have their perceptions based on things that their governments have said about you or things that, you know, they've— they're reading in the news about another section and maybe they don't fully understand it, but like they kind of come at it with a moral agenda sometimes and things like that. Which isn't to say this is all like they're wrong, but it is an insight into how compliance as a conversation can get very, very complex. And it goes beyond just like the technical black and white what's in front of you. It's a lot of like the heart and mind of the customer as well.
But I have one particular obsession with regards to wrong questions. And I think we've been asking this to plenty of people. Like, what's your advice to people who insist on asking the questions that imply that they don't get cloud? They think that cloud is just somebody else's computer. It's a rented colo. They want to approach cloud as old-style data center, just in somebody else's possession. How do you deal with them? And I want to try not to lead you too much. Like, what do you tell them and how do you deal with them?
Other than, you know, stress balls and voodoo dolls and all of that.
Yeah, yeah, yeah. Other than stress ball. Yeah, exactly. Where's mine?
So just to repeat, so customers who are kind of anti-cloud in general?
No, no. Customers who are in the cloud, but they insist on using cloud as a rented data center, who think that there's not Nothing different about cloud. It's just regular computers.
Oh.
The people who believe cloud is just someone else's computer.
Yes, that crowd. And Tim is cringing. If you're on audio, Tim has a slight cringe.
Well, I would say, I mean, I would start out by kind of, yeah, agreeing with them. Like, I think that's the first way, because they do have a point. It is, cloud is a bunch of data centers. Like, we just built a bunch of them in different locations and made them, like, super highly available. So yes, in a sense they are correct. However, it's because of that key difference that we made a bunch of them in a bunch of different locations and we have this amassed compute power as well as cloud companies typically are not just data center companies. They typically have a whole army of engineers who are geared towards making machine learning programs and data programs and like security programs. And like you get that plus a lot more. So I think the best way to deal with it is really by first acknowledging that they, they have a point. It is. Yes, that is true, but it adds on to that through just like the sheer number of data centers that we have, as well as the employees that back it and the programs that we are focusing on and the thing, the products that we serve as well.
I feel like that's a very lawyerly answer of, yes, opposing side, you're correct, and you're also very wrong, and let me tell you why. I love that.
It's also very compassionate.
It's very compassionate.
In my mind, it's more compassionate than an average lawyerly answer I imagine in my head.
Anton and I might have different concepts of lawyers in our heads.
Are you married to a lawyer?
I want to ask kind of a fun question, which is, you know, of all the compliance things you've run into with users, what's been most surprising? What's been the most surprising thing somebody has been like hyper-concerned or hyper-confused about that you had to get them across the line about?
Oh, yeah, this was actually back when I was InfoSec manager for a financial services startup, and our customers are banks. And so, in order to have a customer as a bank, you must go through their audits. And their audits, the bank audits are not fun. Like, they're really, they're very thorough. And the banks are so big, and the people using the, like, they have all these internal tools that, like, I love the internal tools at Google, the internal tools because somebody screen shared with them at an unnamed bank that I won't say, but like, they're terrible. Like, He just was like, can you tell me what to click? I was like, it was bad. Anyways, so the bank audits are, are not the best. However, we were going through one of the bank audits and we got a finding that we didn't encrypt our attachments to our emails.
Mm-hmm.
Like we used Gmail, like enterprise version at the time before it was Workspace, and emails were encrypted, but the attachments weren't encrypted themselves. And I said, okay, like we can kind of look at products to try to encrypt the email. That's fair. Like VirusScan, blah, blah, blah. And then they go, well, no, you can't do that because the one auditor, because if you download another encrypted email, like how will you VirusScan for it? Like you can't VirusScan for an encrypted attachment.
Oh.
And I was like, okay, so we have like 2 competing things right here. So, what do you want us to do? Because, like, we can do either. Like, we're in a startup position. We just want to make the customer happy at this point. And he's like, well, you just have to do both of them.
Right. That makes sense. It's almost like we asked somebody if I want to encrypt traffic, but also sniff traffic. The answer may well be yes.
Yeah. And then, it took me 5 months of negotiating with the bank before They finally just bumped it up to, like, somebody's manager's manager, who was like, why are you still talking about this issue? This isn't a real issue. Like, make it go away. Like, just say they're fine. But it was 5 months of them, like, an auditor who didn't really understand the technology behind it. So, he didn't really understand that you could have 2 competing controls in place. And he didn't really understand, like, he was kind of, like, the worst of compliance sometimes, of, like, when it's just, hey, the line says that you You have to do this, so you have to do this, even though it doesn't actually make sense.
So, I want to switch gears a little bit and ask real quick, because of time constraints, tell us about your work on standards development. That stood out to me as something really interesting, and I would love to know how you got into that.
Yeah, that's actually the— I got into it through the beauty of Google.
I love Google.
But my— one of my coworkers, who I also consider a friend, uh, just looped me in. They were like, hey, like, we need people to develop standards, do you wanna help with this one? It looks like you might be good. I'm actually in one of my tabs right now. I have another standard open.
Nice.
But it just is a matter of finding the team at Google and kind of saying, hey, like I heard about you, can I help next time you have something? And that's all it really took to get started. And what it really is, is they send you a very long rough draft document of standards and you take a piece of it and you just kind of go through it. And you try to put yourself in the shoes of a critical observer. Like, if I had no idea, like, I try to first do it of, like, if I had no idea what any of this meant, would I understand it kind of generally, like, what they're trying to get at? And then I also come back with it as a subject matter expert, like, are they missing anything here?
I love that.
I do, actually. That actually makes sense. And I think that it's probably the only way to handle these extra tricky conflicting requirements, conflicting demand situations with standards that are not uncommon, right? And there are always one or two players who are downright— what's the polite term?
Naughty.
Yeah, naughty. Thank you. Christmas spirit and all that. Yeah, naughty, who want this whole standard for themselves, basically. So, how do you deal with them while using the expertise yet building something good together? I can see how being a lawyer is super helpful for that.
Oh, I bet.
Good reading comprehension.
Yeah, that too. Yeah. Before we start leading to our closing questions, I wanted to ask on the topic, I kind of briefly touched the topic of diversity in the context of diverse perspective. How has your background shaped your work here?
I think that this is me again, being very, very honest, trying not to do a nice warm fuzzy answer, but I joined a team that's like, frankly amazing. Like everyone on my team, is really stellar at what they do. And when I joined, we had good diversity. A few people left the team just because, you know, being a CE is kind of one note after a while. Like, you want to kind of move on. And we had a dip in diversity, but we've been like trying to acquire it back. So I think if anything, like, I have felt that I both am valued As a female, but also I don't feel that different. The only times I actually feel different are times when I actually feel a little bit guilty because I feel like I'm getting an advantage because somebody is like, oh, well, she's a female, like we need females here. And that's a good thing. But it is actually like you have a little bit of— I personally have a little bit of guilt associated with that because I feel I don't know, just that way. But I did actually talk to another person who belongs to a minority background in tech, and he kind of gave me the advice of just like, you got to take what they give you. Just like, go for it. If you want to go up, like, just do it and move on. I'm like, all right, sounds good. I'll do that. But if anything, yeah, I would say, I guess my most diverse aspect as a white woman in America is being a woman. And I have I've felt so far, I know this isn't everyone's experience, but very, very much like a part of the team while also being treated kind of special sometimes because I'm a female.
Victoria, I hate to do this, but it's time to ask our traditional closing questions. Do you have one tip to help people communicate across, you know, cloud compliance boundaries? And do you have recommended reading? For people to learn more about, you know, either like these really interesting tech law policy debates that are happening out in the world or about compliance or anything really?
Yeah. So let's see, for communication across boundaries, I would remember it's a tough thing, but it's a know your audience and think about your audience. And I know that's standard advice, but it, it's particularly important in compliance because you are often in a room with a technologist, a lawyer, And like a compliance person or a business person, and they're all speaking 3 different languages and they all have like slightly different goals. So it's really important that like, if you're talking to an attorney, they're thinking about like the actual regulation. If you're talking to a cloud engineer, they're thinking about, you know, is this gonna cause friction for me as well as how do I get this job done and make my life easier and make everything efficient? And if you're talking to a business person, they're thinking about things like cost or something like that. And everyone's kind of thinking of how do I make myself look good? How do I make my manager look good? So it's kind of all 3 of those and you want to try to address either one of them or all of them depending on who's in the room.
That makes a ton of sense.
Yeah. And for recommended reading materials, I actually, I won't say a book, but I will say the Fordham Law on Information and Policy Center where I used to work, like They try to come up with a lot of different projects. They're very easy. They're meant for more of like attorneys, but they do have like a lot of stuff on, hey, like here's a law conference, or like it can do anything from technology, from like free speech on the internet and like Section 230 type of stuff to like AI and things like that. And as well as IAPP, they have a good kind of resource center for like, hey, this is the thing that's going on in the world today.
Who was that last one?
IAPP? International Association of Privacy Professionals, IAPP.
Ah, yes.
Like, I just like those for kind of like quick hits on, hey, like, these are the things that are happening. These are the things to like keep in mind.
Awesome. Well, Victoria, I can't thank you enough for joining us today.
Yeah. Thank you so much, Anton and Timothy.
And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, Or wherever else you get your podcasts. Also, you can find us at our website cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvaikian and TimPico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google