EP152 Trust, Security and Google's Annual Transparency Report

Security.

This is the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Threat Detection, 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. You can follow the show, argue with us and the rest of the Cloud Security Podcast listeners on LinkedIn. Anton, what have we got today? Is this the episode where I make fun of myself for writing a stupid question?

Yes, in fact. And I think that's where I try to— this is like an attempt to rewrite the question on the fly, but not just to make it better, but to make I mean, admittedly, a fairly unimpressive question. Can I say unimpressive? Yeah. Into something that actually worked brilliantly.

Yes, which is actually kind of this whole episode is full of brilliance from our guest and very little brilliance from us. So maybe without any more from us, let's welcome today's guest. Now, listeners, I'm delighted to introduce today's guest. Of all the Googlers I've had the privilege and the pleasure of working with, Maché is at or near the top of the list. Maché Smith, Director of Product Management for Global Affairs Works at Google. Mishe, I am so glad we found the time to get you on the show. You've worked on so many cool things. One of the coolest things is the annual Transparency Report.

Yeah.

Could you tell us about what that is, how it got started, what we do there? Tell us all about it.

Yeah, yeah. So the Transparency Report started as a whiteboarding project with a couple of privacy engineers together. They got together because Google was being asked to provide information about its users to law enforcement. And from a privacy perspective, it's like giving and sharing data without users' consent is like, that's kind of like a biggest no-no, right? Notice and consent is the foundation of privacy. But when the law allows for something like that to happen, it's like, you know, what do you do to ensure that you can protect users in these types of situations? And so As a company, we must comply with the rule of law in the places in which we operate.

The alternative is like cyberpunk dystopia very quickly. So yeah, we gotta.

Right. And so it's like, well, what can we do? Like, what kind of accountability can be placed in this area? And so that's when the transparency report was born. It was like, well, we can publish the amount of requests that we get, right? We may not be able to respond, but we can publish the amount of requests that we get. And we can start to say things to lawmakers like, Like, you know, when you send us the request, it's going to go in our transparency report, and everybody's going to know that you're asking for data. And if you're asking for a lot of data, then you may look bad, and advocacy organizations are going to want to understand what's going on here. And then other countries are going to want to understand what's going on here, and it's going to become, you know, something that you may want to make sure you do in a responsible way.

Mm-hmm.

And so that was like the birth of transparency reporting. And so it has expanded to many topics since then. And the kind of key and central theme is how do we let numbers and data, which is something that Google does best, you know, right, address topics that intersect with online tech security and privacy and public policy?

That's very like Brandeis sunlight is the best disinfectant kind of thing here. I love this.

Yep. Yeah.

But it's a report about things that sometimes we can't be transparent about. So, it's almost like it starts to explode my brain a little bit. Like, I read the report and it's clear that we are talking about some things where we cannot talk about them, but we can talk about the count. So, I mean, I'm not even sure I want to ask you what are some of the things we cannot talk about, but how do we balance being transparent about things that people are typically, I guess, more quiet and hush-hush about? Like, I don't know.

How do you even do this?

Yeah. How do you even do that?

Explain your magic. So like some of the things, first of all, it has to be something that is enough of a public discourse that it's worth it to publish information about it, right? For example, for a while we didn't publish information about YouTube takedowns.

Mm-hmm.

But once YouTube became such a, you know, prominent product and so many regulators were concerned and the public was concerned about whether Google's censoring the public and taking down too much stuff, or we're allowing the governments to censor and take down too much. Once the discourse gets to that level, the goal is like just provide some data so that people are not solely talking from emotions and feelings, and there's no data to put some rationale and reason to the conversation. So that's the first thing. It needs to be enough of public discourse. that it makes sense to bring some data into the conversation. The second thing is, does publishing this data help or harm users?

Hmm.

Sometimes publishing this data can cause governments to enact more stricter laws or to do, kind of have the opposite effect of what we want, right? Which is to kind of protect the free flow of information online, right? And so if we think it's actually gonna harm users, or hurt the free flow of information online, then that's another thing that will make us, you know, decide whether we want to do it. Another thing is, are we credible? Like, do we even have enough data in this space for us to report on this? So one of the talks that I give at Google is called Security by Numbers, and it's about HTTPS and how we publish the HTTPS report. And I'll argue that if we would have published the HTTPS report a year earlier, Like, people would be like, who is Google to talk about HTTPS? Only like 2 or 3 of your products are even using HTTPS. You haven't gone through the cost that is associated with going from HTTP to HTTPS. So don't— you can't set a security standard when you're not actually even going to be willing to put your money to the paper yourself. And so we actually didn't do the report externally for a while. We started internally and showing it to people saying like, we're about to do this external report. Security org thinks that HTTPS is the way to go, and we're going to show that you're not doing it right.

Ooh.

And so that helped get a lot of people together. And then it also gave us the credibility to go out to the world and say, hey, we did it. HTTPS, we know it's hard, but it's so worth it to protect the content, to protect the privacy of the people on your systems, right? And so it made sense then at that point where we could speak from it with a credible perspective, and we had enough traffic flowing through our systems to speak to it as well. So those are some of the things that we, we think about before we decide whether we should release a transparency report on something.

So this is giving me flashbacks to when we first started working together, when you were working on access transparency logs.

Yeah.

Are these things related more than just in name and you having worked on both of them, or am I confused here?

They are related in terms of the strategy is very similar.

So what are access transparency logs?

Yeah, so access transparency logs are logs that we provide to companies on Google Cloud Platform about when a Googler touches your product or your app that's running on top of Google Cloud Platform. And the reason why we provide that was because a lot of companies are concerned about going to the cloud because when you're, as people used to be, and you're in your own area and you own all the servers, in your data center and you're on-prem, then it's like, I kind of own all the risk. I know who's coming into my data center. I know who's touching my software. I know all these things. I can implement the processes to keep my stuff secure. When you move that to a cloud provider and you don't run that cloud company, then you're like, well, how do I know you do all the things that I do to secure my data? How do I know that you, you know, you're not going to look at it and then leverage it for something else? And Google, because we have our advertising business and that's one of our primary sources of revenue, they were really concerned, like, how do I know you won't use our data to improve your ads business and to make money off of us, right? And so the Google Transparency Logs and Access Transparency was a way for us to give that visibility and oversight to the companies to say, like, hey, you get to see when we touch your system and we're going to tell you the reason why we touch your system, right? And if you don't feel good about that, Then you can say something to us or you can move to another cloud provider, right? And that's a very similar kind of theme that was with Transparency Report. Like if, if you're in the public or you're an advocacy organization and you see these numbers and you don't like 'em, you can speak to your government, you can speak and you can do something about it. And it's a way to empower these companies to do something about it.

Uh, that's, that's good. That makes me feel like I'm not, not crazy, at least not in this regard. This is great. I appreciate that.

I don't know.

To me, that's one of such of the cool, like, engineered-in capabilities we have here at Google Cloud. And like the Gintegration, I've gone through all that. It's cool to see the actual, like, engineering muscle meet the road there. That's a powerful capability.

Absolutely.

It's also something we woefully undermarket, frankly, because I had to explain it to people and people were super surprised and impressed and thought that it's an amazing thing. And it's backed up by a lot of tech and a lot of things, legal frameworks, and other stuff. So, it was kind of like an incredibly well-thought-through effort on our behalf. And we just don't seem to shout loudly enough and clearly enough to people. But okay, aside from that, you also work on something really fun.

We under-marketed something at Google?

No way.

I don't believe you for a minute. That never happens.

Yeah, that just never happens.

Never was never one of our strong suits.

So, you also work on something also really cool. What's the Central Risk Data Platform? And as somebody who dealt with companies complaining about risk, because I was a Gartner analyst, every business seemed to have a problem managing risk data, like data-driven decisions about risk. So I would assume naively that Google has some kind of powerful magic in this area. So do we? And can others benefit somehow? Like, I'm pretty sure we have something amazing here. That's my intuition.

Yeah. So I think we have something that is in the early starts of amazing. I would say I don't want to go I don't go overboard, but like measuring cybersecurity risk has not been done well in the past. For the most part, what people do to measure cybersecurity risk is they come up with some kind of control framework and they say, these are the technical controls that you should be doing to make security right. And then they look at the coverage of those controls and they say, okay, well, if you're doing all of these controls in the control framework and the coverage is there, then your risk is low. Right. And a lot of companies sell security risk scores that are really based on just that, right? It's like, I have some kind of thing and I have these checkmarks of things you should have turned on. And if those things are not on, then your risk score goes up and down, right? But the problem with that is that it doesn't tell you if the controls are actually effective. It just tells you that they're on.

Or that they are bolted into the rack in the data center and there's a big firewall appliance that says, firewall in red letters, right?

Right.

And auditors would be like, wow, you have a firewall.

Exactly. Yeah. And so like, at one point, we thought 128 encryption was the best thing ever. Then we went to 256, and we just kept going up, right? And so if you say, okay, is it encrypted, but it's encrypted in some old encryption algorithm, right? Your checkbox is just encryption, right? But you don't really know, like, is this algorithm effective for the thing that I'm trying to protect? How do you know if you really dealt with the risk, right? And so now what we're starting to do is gather all kinds of data, not just the control and the coverage, which is important. We're not going to get away from that. But we're looking at like when a control is in place, did an incident still happen? And we're looking at things like what are the issues that are associated with these controls? The controls are typically technology. Technology can have vulnerabilities as well. So are there vulnerabilities associated with the controls that are supposed to protect us? And then what does that mean for the different assets that they're supposed to cover? And we're taking all of that information and turning that into a score, which I think is something that is like unique at Google. We for sure haven't done that here. I'm looking forward to us getting to a place where we have this as a repeatable model that we're looking across the board. We're applying this first in the area of insider risk. And for people who've looked at like Verizon breach reports and stuff like that, you know that privileged access abuse is like one of the worst risks in that it takes usually months for you to find it. With other types of events, you figure it out in hours or days. Privileged access abuse is typically there for months before you figured out it's been happening, right? And so we're starting with one of the hardest risks to discover and then trying to measure that and understand that and model that because also these are like infrequent. Events and incidents when it happens. So how do you do a risk model when you're trying to model a risk that doesn't happen all the time versus like threat detection when you're constantly getting things all the time, right?

We solved this problem, but wait, wait, that's not magic. This is equivalent to curing cancer by flying to Mars or something like that.

That's beyond magic.

It's way more than that.

I don't know, Michèle, did you say you solved it or you're working on solving it?

No, no, I was asking—

I said this is what we're working on. And we're in the early stages, but we're making, as I would say, like significant progress here. And we're going to start to roll that out across Google and see how it works and see like how effective was it in predicting risk and getting people to choose the right controls to apply to adopt it. And then, you know, I'm hoping in a year or two that I'll be able to publish a nice white paper about how we solved it and be in all the magazines.

Yeah, I would think so.

So I don't usually look at the questions I wrote for an episode partway through the episode and go, damn, I wrote a stupid question. question. But my next question is literally a stupid question. It literally says, listeners, this is what it says, quote, Tim wrote this, you're a PM, what are the interesting product questions here? I don't personally associate risk management with exciting product opportunities, but this is really exciting. Like, what an idiot I was. So let me ask you this. I'm going to ask a different question than my stupid question. How did you know this would be interesting? Because I would've naively assumed it wouldn't be. So how did you, coming into this role from all the other stuff you've done, decide this was a good next move?

Yeah, so I in general am in love with the mission of privacy and security, but one of the things that's been really hard specifically for my security engineers is to understand why everybody's not in love with this. And so they go and they talk to the product areas and they're like, security is the most important thing. And if it's search, they're like, no, relevant searches is the most important thing. ads, ads is the most important thing, not security, right? And so how do you convince somebody that they need to do these security and these privacy things when they're looking at metrics all the time? Well, you got to come to them with some metrics, right?

Hmm.

And in the past, we've always come to people with use cases. And this is why it's important. And these are the anecdotal things that we've seen that if this becomes Google, this would be horrible. And And it almost felt like the program that kind of yelled the loudest was the one that the product areas decided to go with. But they were always craving for like, what's— can you give me some data? Because a lot of times you find people and they're like, I want to do this. But if you get— I need the data to prove that it's more important than innovating on this new thing, this new feature for a customer, because this will come at a cost to my business, right?

Mm-hmm.

And so it was— I saw it as an opportunity to help Google mature in that area and to be able to have more beneficial conversations with the product areas and increase the chances of seeing more security and more privacy things happen. Anybody who's a security and privacy professional in any company faces this issue. It's like, how do I get the business unit to care more about security and privacy and do more things, right? Totally.

Shit, I have that problem in security, to get security to care about security.

Yeah, but this gets very close to home. So I think this is like the topic I would avoid.

I think—

No, that's such an interesting answer. I love that answer, Moshe. That's great.

So there is a non-boring side to the original question, and that namely that you are a PM here and you recently made director at Google. If those who don't know, it's kind of a huge deal. I mean, I'm not a director. Tim's not a director. We are both kind of— I think we both have director envy. I do for sure. So any advice for the ambitious PMs? Oh, Tim, you wrote this question.

You said PMs.

How about ambitious non-PMs who, well, want to grow at Google?

Yeah.

Or in general?

Yeah. I don't want to grow.

I'm 6'3.

I don't want to grow. So I will say, Getting to director was, in my case, and I don't know, like some people are always looking for like, what's the trick to get to director? In my case, it was that I focused on the things that I cared about, and I played to my strengths, and I didn't kind of back away from my strengths. One example is when I recently got to senior product manager, which is we call L6 internally at Google, I was asked, I had the opportunity to go and work in the privacy org. And I also had the opportunity to go and work on Google Assistant in the early days. Or I could stay in cloud and keep working on privacy and security. And a lot of my friends was like, go on AI, you have to go to Assistant. What are you doing? Are you crazy? The new hottest thing, blah, blah, blah. And I sat back and I was like, my passion is to make privacy and security native to the way people work. And I was like, I felt like privacy and security was way too hard and that we put too much on users up front to actually make things secure. And I was like, we need to transfer more of that burden into the infrastructure. And I was like, in my mission while I'm at Google, if I can and people will allow me, is to transfer more of that burden into the infrastructure, right? And so I had to— I could go there and work on Assistant, or I could stay in cloud and build access transparency and put more of that stuff into the infrastructure. Or another thing that I did built in the early days was the Privacy Center that we have in Google Cloud so that we can see data that we're using in our Trusted Advisor programs so that people could be aware of how we use information about their systems. And then they could say, no, don't use this information about my system. And so like, those are like things that I like to build and make sure that they exist for our users so that we can honor and make things easier for them and give admins the options to say like, yes, you can use my data or you can't use my data. And so I stayed true to those things. And even when I was in cloud security and I had the opportunity to go to PSS and work on these things, I was like, well, I can stay in cloud security and start a joint venture with Europe so that we can get through these sovereignty laws, which would have been an amazing opportunity. I was like, but I really care about security for being pervasive across all of Google. And so I went over there and I worked on identity, internal identity access management systems, and I worked on this risk data platform. And I think sticking true to that has allowed me to keep going up, not being scared of the tough problems. Because there was a time, I think people may not know, but I did GDPR for all of Google as well.

Oh, that's exciting.

And I'm the product manager that created our first data governance knowledge base as part of that. So I never got scared of these big challenges, even though there were times when my manager was like, you sure you want to work on this? There's a lot of crazy and politics things going on. And I was like, if there's one thing I do good, it's step into situations where people are not getting along and help them come together to a solution. And I was like, I may not be the most technical, even though I am very technical, so don't get me wrong. I was like, may not be the most technical, or I may not do this, but what I do well is see a problem that has a lot of different people in it and get them to come together and align on the path forward. and create the right risk mitigation so that we can figure out if we're going off track and get back on track. And that's something that I've always been able to do really well. And I just take on tougher and tougher problems and keep doing it. And it turns out being a problem solver is like really important.

I think you're interesting because risk is the toughest. So like, I think that you pretty much arrived at the Everest, the tippy top of the Everest, and you're like, Now you're gonna crack risk, and then you're done pretty much, because like, this is really— yeah, you can go home. This is the hardest one.

Yeah, well, one thing I will say, if you want to go to director, just be ready. Like, the higher up you go, the less you get to touch the actual interesting stuff. You got to let the other people do it, and you focus a lot more on the organizational structures to make it successful. So, um, that's one thing to be aware of.

So if I were to summarize your answer, it's one, focus on things you love working on, which you've done.

Yes.

Stay true to yourself, play to your strengths.

Yes. And by the way, be a tremendous badass who can take on all these hard problems. Be capable. Like, that's one thing that you have to be. Whatever your skill set is, be capable. Because at a certain level, everybody assumes capability, right? And then after that, it's like, who do they trust? Who can solve the problem? Who has the track record? But if you're an engineer, be the most capable engineer, right? If you're a product manager, you better be able to write a CUJ, a roadmap, and a PRD, like, drop of a hat, right? You have to be capable in your craft.

Well, I wish we could keep doing this all day, but unfortunately, we're at the point in the show where I have to ask our traditional closing questions. One, do you have advice for people to improve their enterprise risk management? And 2, do you have recommended reading?

Wow.

So if you're really— I'll start with the second question.

Yeah, please.

If you're really into, like, cybersecurity risk, there is someone who worked at Google who wrote a book. Her name is Keyun, K-E-Y-U-N, Ruan, R-U-A-N. And she wrote a book on cybersecurity risk measurement.

Cool.

And she created a new measurement type called HEKLA, H-E-K-L-A, and it is Like, for me, it's one of the most fun academic readings that I've done recently, just to think through cybersecurity risk and how it works. I'm gonna have to Google the name of the book because it's not coming to the top of my head right now, but you know the author. There's not a lot of books about cybersecurity risk measurement, but that is one that I recommend as ways to do that. The other thing is—

And she does work at Google still, by the way. She is, she still works here.

Yes, she does. And she has a video too. It's about digital asset valuations. But, uh, yeah, digital asset valuation and cyber risk measurement.

Okay. And then the tip to improve enterprise risk management.

So the tip to improve enterprise risk management is asset inventories. You can't measure what you don't know exists. So this is period security 101. It's not just for risk management, but it's Especially it's important for risk management. Get your asset inventories together. And then I would say the other— that's like the number one thing you can do, to be honest.

I love that.

And then the second thing that I would say do is just choose a control framework. So many times people waste their time on like, should I do this? Should I do this?

Should I do that?

Just choose one. Don't kill yourself. It's always going to evolve. Your control framework is always going to Just choose someone, start somewhere, and then start evolving from that. Those are 2 things, like a control framework and an asset inventory, are so key to start measuring risk. So, just don't kill yourself on, like, is it the best control framework? Choose one.

Choose one.

Choose one and evolve.

There's a blog that says exactly that, that I'm going to link, because we have— we've written a blog that says exactly that. Don't obsess about choosing the right one, just pick one.

Yeah.

Well, Mushay, I can't thank you enough for joining us today. This has been tremendously fun.

Oh, fun for me too. And I'm so honored to have been a guest and to be invited to talk. So thank you so much.

Thank you. 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 underscore Chuvakin and underscore Tim Pico. 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.

Security.