EP134 How to Prioritize UX and Security in the Cloud: UX as a Security Capability

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at Google Cloud, 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 your hosts and the rest of the Cloud Security Podcast listeners on LinkedIn. Anton, I am delighted about today's episode because it's one of those ones where we had high expectations and then I think it really just kicked into a special gear throughout the course of the recording. It felt great.

It did feel great. And I can tell you that my impression is that we'll have a solid episode, but we actually have a magically good episode as a result. So, the result is just, like, that much better. And it's also a topic that kind of maybe doesn't trigger people, but it's a topic that confuses and befuddles people in the industry, right? Cloud security, security.

Yeah.

And we have somebody who really knows how to make it come to life.

And I think for maybe the more cynical listeners we have, you might look at the episode title and go, "Psh, that doesn't exist in my industry." And this episode is maybe designed as balm for those people to talk about. No, it it really should, and we're really trying, and this is how we're thinking about that problem. So perhaps with that intro, listeners, let's turn things over to today's guest. I am delighted to introduce today's guest. Today we are joined by Steph. Hey, Director of UX for Google Cloud Security. Steph, first off, thank you so much for joining us today. I'm delighted to have you here because I work with your team all the time, and I think of the PMs in cloud security, I may be one of the more UX-oriented ones. It's important to me, and I think it's important, but for a lot of people, UX and security kind of go together like peanut butter and pickles, and they just don't get it. So maybe could you, could you tell us about the importance of UX in security?

You bet. Pickles and peanut butter? Is that what you said?

Not a good combination. It's the opposite of peanut butter and chocolate.

That's his metaphor of the day.

No. Anyway, I mean, it was a big reason why I got into security in the first place, having been on the receiving end of working for a company that was doing its very best and experienced a data breach. And just sort of in, you know, a split second realizing that a usability challenge where like 1,000 notifications went off at the same time and no human could parse through those 1,000 notifications. notifications, and by then, the perpetrator had already been in and out. Well, that seemed like a usability challenge for sure. And so, that was sort of one moment for me, but there are just countless moments of, you know, somebody really trying their best and having a hard time understanding something. Both presents a really good obstacle for a bad guy, but also, there are a lot of good guys who are trying to make security, make more secure outcomes for their organizations. They're having a hard time doing it without the right tooling designed for them. So, That's where I think UX and security are more like peanut butter and jelly, Tim. They should be, where you can make security understandable and usable and still also have the right hurdles for the bad actors who are trying to exploit it. And that's the security challenge that I think we all face.

So, to sort of pick on that theme, I think that the whole uneasy relationship— I'm not going to go to the peanut butter and pickles, frankly. I don't know. This, to me, sounds a little, as my 4-year-old would say, yucky. But the idea is that there's an uneasy relationship, and sometimes it feels like bad or inferior or bad UX is almost like a security problem because in your scenario, when there are many alerts, they're produced and shown in such a way that a human cannot comprehend them. Ultimately, the UX designer is almost like a guilty party in the breach, almost.

Almost.

Like, I'm pushing it a little far. Oh, I'm pushing it a little far. But like, what's your take on this? How can we— like, if bad UX is problematic from a security point of view, why aren't we in security don't pay more attention to it?

Well, I think we are. I mean, there's a reason why I'm here for sure. But generally speaking, I think it's actually bigger than security. Generally, enterprise tooling has not gotten the same TLC from a user experience perspective as consumer-facing products. And I think that's, you know, having seen this in multiple different contexts, one of the opportunities for user experience as an industry is to come into what are, the operational tooling that practitioners need to do their jobs every single day. Security is one of them.

Mm-hmm.

But you can imagine, like, you know, workflow management for anything that is highly complex. When you think about doing something like that, where I might not actually be the end user every single day versus something like another music sharing service or, you know, whatever that I might actually use every single day, my job as a designer is actually much harder. So, it's harder, I think, to attract and retain UX practitioners in spaces where they're not the everyday end user and they're not actually practicing, in this case, security. So, the opportunity, I think, which we're obviously exploring here in Google, is to bring the right UX thinking in, do the right research with end users. In our case, what are the SOC admins doing? What are the stack engineers doing to try to get their jobs done and to focus on their jobs to be done and to enable them through better tooling is in the enterprise space, I think it's newer to sort of elevate user experience as a primary part of the development process. And certainly for UX practitioners to be working in that space, it's a little bit newer, at least in a critical mass where you've got UX design and research and writing and prototyping and like the same kind of full-stack design team that you would have for a consumer-facing app that's been doing it for 30 years.

There's something in there—

Consumer, consumer, I'm gonna talk over Tim this time. I'm sorry, Tim, I insist because you said something that I've been trying to have us use more. And us, in this case, means Google. Because you pointed out that in some consumer-facing apps, we do an amazing amount of that, and it really pays off. But in enterprise/security areas, we haven't until recently. So, it's kind of a reason why our consumer— Google's consumer kind of focus originally is a strength, not a weakness.

Mm-hmm.

Because our UX is, in fact, superior and should withstand the tested by billions if it's a consumer-facing app.

Well, and that's where I also think, like, we see startups in the security space in particular who have been investing in their user experience right from the jump because they can actually differentiate by taking a more consumer-centric approach. Whereas maybe for, you know, others, us included in several areas, we focus more on the developer who might not actually even be using a UI. We might be looking for the person who's going to be integrating at the API level. Not thinking about what the end user experience is going to be for the practitioner who's new, you know, 2 years down the road. And that got us up and running, but it's not good enough anymore to compete with those startups.

I'm really interested in something else you said there, and I'll, I'll accept Anton talking over me. It's allowed to happen sometimes. You talked about motivating UX people and the motivation here, but you also talked about your motivation of getting into this around being present when a data breach happened and the challenges there. How important is like mission orientation in the people that you're hiring and retaining and making successful in these roles. How do you get UX people who could work on an app that's used by billions versus work on apps that are used by thousands?

Yeah, it's a great question, a daily challenge, and everybody's different.

Yeah.

Okay, so our mission is to make security understandable so we can deliver peace of mind to customers worldwide. And generally speaking, for like I shared my example, right, but for the way the world is moving to the cloud, everyone at the end of the day is gonna benefit. And especially the UXers on our team who are at the sort of forefront of designing these experiences, everyone is gonna benefit from having more secure organizations in the cloud. Everyone. And that's not a hard sell when you are flying every day, your healthcare companies, your governments, like all of these organizations that have your data, want to protect your data. And our team, our collective cross-functional team, are at the forefront of designing the tooling to fortify that data and yet make it accessible to the right people so that they could do a better job of fortifying it as the sort of cybersecurity landscape continues to face new challenges every day. So what is your story? Like, why did you come here? Everybody's is different, right? But at the end of the day, If you are not actually motivated to secure the world's data, and by saying that, like, your own, it's probably not a long-term gig for you.

That actually makes sense. And I think, to me, this is probably a good test, right, for people coming in. Do they have that part of the story? But let me try to go into the devil's advocate mode a little bit. And of course, sometimes here at Google Cloud, we have people who express the view that security should be invisible. Sometimes when that's naively heard, that means there's no UX because there's no X. You don't interact. You don't have an experience.

Yeah.

It's invisible, so you're magically secure. And of course, we can do this for like hard drive encryption or some other areas where things are magically secure, and that's all there is to it. There's no UX. But how do you kind of harmonize the desire for invisible security with the desire for superior UX? So say mistakes don't happen. So what are the intersections here?

Yeah, it's such a great question, Anton.

It's—

Thank you. I wrote that question. I wrote that.

Yeah, Tim wrote this question, so that's very good.

Well done. Well done.

Thank you for catching.

There's a sort of basic trust and need for control that's at the heart of that reaction, I think, right? I don't trust that anybody except me as a security engineer who's been doing this, let's say, for 20 years, knows this environment as well as I do. I have to sort of, verify everything. I don't want a system doing it on its own. No way.

Right.

So like the controls and the trust have to be— the affordance has to be obvious in the user experience. And so I do think we should be taking away some of the toil that keeps that person from focusing on the more specialized, complex tasks that they're really trained to do. And so when I think about invisible security, I think how far can we move The toil, how much toil can we remove from the manual experience that the security practitioners are used to doing, but still enable them to retain their control? And so, we might say, hey, we think that you should, like, let's take some of our GenAI capabilities, right? We think that you should do this and this based on this. We're making it really transparent why we're making that recommendation. That's also to boost trust. Do you want this to happen? Yes or no?

Mm-hmm.

That little bit of a UX construct there, which we're all used to in life, is gonna do 2 things. One, it's gonna enable that end user to retain control. And 2, it's gonna teach us whether or not our recommendation was right and whether that person actually took that action, which would help us make better recommendations, by the way.

Mm-hmm.

So, I think we have to get that lifecycle, that feedback loop really crisp so that we can actually bake more security into controls, into the, the applications that folks are using every single day.

So from my side, I'm happy that you're not just building chatbots. I think that people who overindulged on the chatbots a little bit, and I've met some of them, and I think that— yeah, okay, you're smiling, so that's good.

By the way, that was a past life though, like early conversational AI work in a regulated company. That was another thing that taught me about the importance of data privacy and how to go about ensuring that somebody's sessions are retained. But maybe, you know, in a case of a voice-based experience that you're not saying things out loud without getting particular sort of permissions from the end user, because in fact, that might be a data privacy issue if a voice-based object is saying things like, I don't know, your cash balance or something like that, right? In a banking app, sort of in this scenario. But anyway, so I am a big fan of chatbots though, Anton. Like, I mean, I'm just saying that not all security should be done in there, probably. That's for sure.

I I love that because, well, who hasn't made fun of Google for building yet another chat app? And what PM and UX pair at Google has not aspired to do it themselves? I want to shift gears a little bit and talk, if we could, about your time at Google and maybe what you've seen happen here. You've been here 2 and a half years now, and I bet you've seen a lot of design reviews. Can you think of one, like the best single UX change you've seen that would improve security outcomes? I think it's easy for us in security to think about, oh, what'll sell, what'll do this. But like actually changing security outcomes is hard. Have you seen a UX change that really moves that needle for you?

Oh yeah, yeah. And this is a big hat tip to a former guest that you had, I think Vandy, original UX researcher, switched to PM.

On my team now.

Switched from a pickle to a peanut butter, I guess. I don't know. Anyway.

That's right.

Yeah, our IAM recommender is one example where like in context, like people don't wanna be over-permissioned, but you know, at the end of the day, if they're trying to unblock somebody, they have this really bad habit of sort of giving somebody more permissions than they really deserve or need. And something like IAM Recommender, which sort of, you know, analyzes the last 30 days of your activity and suggests which things might be over-permissioned, actually drove about 43% fewer overgrants. The average is 69% of folks.

Whoa.

So this is for folks in context of their experience going to IAM. There's lots of opportunities to integrate those IAM recommendations throughout the experience where folks might not be having to go to IAM to see that. And that's been a big change in the way that that team has been integrating that service throughout GCP so that we can actually get to more of a least privileged state by default. That's one example. Another one, though, I'm just going to throw on there too, is reCAPTCHA Enterprise.

Hmm.

The onboarding experience itself was a little onerous at first, and they just made some changes to that because people didn't even know that they hadn't fully installed reCAPTCHA and weren't getting the full benefits of that sort of fraud capability on their site. So, some changes to the onboarding experience combined with like some simple email updates. You know, this wasn't the grand change of an entire experience either. Those are small micro-moments using some of the user data at our disposal and introducing great user experience in the context of what they're trying to get done, which improves their security outcomes. So, we've seen a big jump in the number of people who've actually like finished the full install and are now actually getting protected by reCAPTCHA Enterprise. How's that, 2?

Those are great examples. I only asked for one, so extra credit and double extra credit for calling out Vandy, who's among my favorite colleagues on the SEC team.

Yeah, okay, good. Yeah.

Nice.

And I think that I love the Recaiam Recommender example because it also felt like it does this kind of AI magic in a very kind of non-annoying, helpful manner. And that means that, I mean, obviously I'm very far from a UX designer, but I felt like a UX designer captured the essence of what they're trying to solve because it's helpful but not annoying. Not like— yeah, I'm not going to give any examples from our product, but like we've done elsewhere.

No, it's such a good example because I was talking to a very secure user just last week, and they were describing this kind of like security paradise. They've got this control, they've got this system, they've got this operating model. And then they described some particular challenge, and I'm like, Well, why is that hard? Why can't you just not give them the permission to do that? And after describing this beautiful universe, they said, oh, well, every engineer in our org has project owner.

Wow.

And I was like, whoa, how does that fit with the rest of your model? And they explained why it did, because velocity is very important to them. But it was so funny to see a user go from like A+, A+, A+ to wait a minute, hang on.

Yeah, not exactly zero trust, or maybe a culture of full trust. I don't know. But I mean, this is really the crux back to this, you know, question about invisible security too. But like, this is the crux of user experience design, which is to understand the intent of what somebody is trying to achieve, their job to be done, and to infuse in context of that particular workflow, the right thing at the right time. The thing that is contextually relevant to them, that tells them before they make the choice what's about to happen. So they understand the implication of that choice and they can make that choice more confidently. And quite frankly, I think In the enterprise design space, there has been more of a focus on UI than user experience. As long as I have a dashboard, as long as I have a dropdown, as long as I have a button, I'm good. And that's not what we experience from the consumer applications, which are designed around workflows. And that's why I think our opportunity and what we've been doing more and more is designing for workflows for these jobs to be done end to end instead of sort of point UIs.

I hate to jump in and ask this question, Steph, what's the difference between UI and UX for the people following along at home? Because I think I know, but you just said they're different and I would love to know how you see them as different. You, I know, I know we don't have 30 minutes to cover that. Just real quick.

Don't worry about it. This is some of the nuance probably in the UX community, but user experience, you wanna think about something like the services, the blueprint of the workflow that you go through when you're trying to get a job done. The UIs are the mechanisms, the user interface are the mechanisms by which you might actually go through that workflow. And so, user experience should think about, and user experience research as well, what are all of the touchpoints that may or may not actually require me to be in, let's say, a dashboard? Maybe it's in my email, maybe it's my alert, maybe there's actually no UI here, but that's part of the user experience.

Oh, so basically, wait, wait, wait, let's see. If I don't have UI because I access system over API, I still have UX.

You do.

Haha. So in that sense, that's the answer, right? Like, oh yeah, I'm gonna use CLI, which means not UI, right?

That's right, that's right. So the user experience, and it's not to say a UI engineer wouldn't do this too, but like the roles can be interchangeable. And as Tim, as you said too, like PMs can do this too, right? Like, but generally what are the front and back of house expectations of the touchpoints We might call them a journey. We might call them a job to be done that somebody should traverse through, which may include, for example, an API or CLI, not just a GUI. As you know, when we, when we say UI, I think we generally think of GUI though.

Graphical user interface. Yeah. So I want to latch on to, this actually makes sense and I think it was helpful. So I guess the, especially for the security audience, right? Because who may not know, you may assume it's the same, right?

I want to clarify something for Steph and our listeners. I guess this was helpful. Is Anton for this was actually quite helpful? Thank you for sharing.

Was it a compliment? Excellent.

Okay. This is like actually really helpful.

That was a compliment. It's it's a translation thing.

Yeah, the actually word always throws me off a little bit.

Yeah, no, I've worked with Anton a long time now. I'm happy to be the Anton whisperer.

Got it. Thank you.

That was a compliment.

So we are doing a little bit of Anton psychotherapy on the air, and I think that's not exactly like the best use case for the for the podcast, but. To latch onto something that Steph said, and it was the jobs to be done. So, I guess I do work for Office of the CISO, so I'm not involved with product as much. But once I was dragged into some product discussion, and there was a lot of JTBD things there, and I had to kind of learn, teach myself what that is. And when I was learning this new approach for jobs to be done, I kind of kept thinking, well, that's kind of mostly about use cases.

Mm-hmm.

Can you explain jobs to be done as an approach and maybe explain how it helps? And Tim, who wrote this question as well, has a really good side question for this, which I will ask kind of on his behalf. It's like, if you use this approach, what gets better?

Yeah.

Like, if we adopt JTBD, what gets better?

Yeah. So, I've had a lot of success using jobs to be done approach after Anthony Ulwick and a whole host of people published this in the first place as a framework. So I would just encourage everybody to check out. It's an industry framework with lots of smart people having contributed to it. But what I found is that generally speaking, well, 2 things. One is, and I even said this earlier and kick myself a little bit for doing it, but like when we think about user experience, I have found in my career that people say, what's the end-to-end experience? Which sort of suggests that there's a start and a stop. And I think, first of all, in user experience, that's a bit of a false construct. User experiences are largely endless, at least when we're talking about sort of somebody moving throughout their day. So, how do you design a system that can sort of pick up and drop off and pick up again and drop off, sort of versus sort of this idea of start and stop finite? And that's where something like jobs to be done is very helpful, is because it considers that there's this ultimate motivation that somebody has. To do, and that certain technologies come out to support that motivation over time, and that those technologies get better and better, and that people will not adopt you if you are actually not providing the service for them as they're going throughout their day that supports them best. So, as an example, you know, to take it way back, originally, the only way to get from point A to point B was with your feet. And then there were like horses. And then somebody invented the wheel. And this is sort of the advancement of technology, right? And then it got to be like cars and bikes and cars and airplanes. And generally speaking, all of these advancements help somebody get from point A to point B. And we have the same sort of construct where photography is another example. You used to need to, you know, put a drape over my head and have a tripod on like a giant thing and like hold a thing up and it would like create smoke and That was how I took pictures, and you had to sit still for 20 minutes or something like that. And now, we just walk around with, you know, phones in our pocket, and those have cameras on them. These are the kinds of things that are— the jobs to be done have not changed at all. I need to get from point A to point B, or I want to capture this memory. But the technology has, and it can shift—

It's all about the use cases.

Yeah, and it can shift user expectations. I think we have the same thing with security. And back to this, like, idea of invisible security, right? Like, The job to be done for an on-prem environment to secure that versus a cloud environment that I still want to— hasn't changed. I want to secure my organization, but the technology has changed and it has shifted the context by which I'm now going to execute that job. And that's going to continue to advance. So, jobs to be done. That was a very long explanation that I hope you'll edit out a bunch of. The jobs to be done— Not at all. Is a framework that keeps that sort of intent That life just continues to move on and on and it's a start and stop and new technology will come out, but my job doesn't really change. And that's a little different than something when I think about like how we might normally do software development where we have, I think sometimes an overfocus on the UI. Well, somebody needs to be able to filter that thing. It's like, great.

Yeah.

You don't need an entire user research team to do that, but why are they trying to filter that thing anyway? And like, are they only trying to filter that thing because we put that thing in front of them in the first place? What are they actually trying to get done?

Yeah.

Jobs to be done keeps bringing us back to that ultimate motivation that enables us to design better user experiences for real humans.

Okay. Actually, that did answer my narrow sub-question of that, namely the difference between that and the use case. So, to me, it became very clear that it's not like the filter would have a use case.

Yeah.

Filter in the UI would have a use case, but the fact that filter is there and people use it in furtherance of some goal, Is part of job to be done, and the job may be whatever that is.

And that that goal is somewhat invariant with respect to technology or change over time.

You got it. You got it. It's completely agnostic. My goal is completely agnostic of the technology, and I'm going to hire whatever technology is best to help me achieve that goal. So we better be good at creating technology if we want to win over and over again.

I really like that answer. Steph, I hate to do this, but we're at the point in the show where I have to ask our traditional closing questions. First, do you Do you have one tip for our audience to help them improve their maybe security UX journey, other than check out all those awesome Jobs to Be Done resources we're going to put in the show notes? And 2, again, accepting that, do you have recommended reading?

Yeah, I do think that Jobs to Be Done— I have kind of the same answer to both of those questions, but I do think Jobs to Be Done is a foundational way to improve any experience, but the security experience especially. And of course, hire GCP. Why wouldn't you hire GCP? For your security journey.

I love that. I think we've gotten about 140 episodes in, listeners, without anybody saying that so directly, but we'll take it.

Okay, cool. I'm glad I could break the ice.

Steph, thank you so much for joining us today.

Thank you for having me. Appreciate it.

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_Chuvaikin 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.

Security. Security.