When Security Friction Becomes the Backdoor

David Moulton: [Background music] I'm David Moulton, and this is Threat Vector.

Birat Niraula: I think of security as a tradeoff, right? You're trying to improve security-you have to give up on something. What you trade could be views and experience, it could be resources, it could be the velocity that you're giving off. So there's always a trade off, you know, if you're trying to improve security in every aspect. And obviously we asked people 20 or 30 years back, right, would you want the password on your laptop? People may say no. They probably wouldn't want a password, right? Let alone having like complex passwords that you have to change constantly and then, on top of that, MFA, hardware, software, you know, whatever, right? So if you ask the users, or any IT, you know, they'd want to put the minimum controls so that the user experience does not get impacted, right? But you've got to be able to balance it. [ Music ]

David Moulton: Today, I'm speaking with Birat Niraula, Head of Security for Google Enterprise Networks. Birat is a friend of the show, and is sharing his views today. At Google, he leads security across on prem, network infrastructure, enterprise, and cloud environments. But this conversation isn't about Google at scale for scale sake. It's about something more. Something fundamental. How do you build security that people actually want to use? How do you make security so good that it enables business velocity instead of blocking it? Today we're talking about UX as a security control, practical zero trust implementation, and what it takes to lead enterprise network security, when security that slows people down is security that gets bypassed. Birat, welcome to Threat Vector. Really great to have you here today.

Birat Niraula: Yeah, thank you for the opportunity.

David Moulton: You've had a really interesting journey. When I went through your LinkedIn, and we talked before the show, you've gone from building SOCC operations to leading cloud infrastructure at financial services firms, and now you're heading security at Google. Walk me through how you got into security and what drew you into this field?

Birat Niraula: Yeah, so when I was doing my undergrad, I took a few security course. My undergrad was in Information Technology, and we had options to take security courses. It was quite fascinating to see you need to build a lot of understanding of the technologies before you could secure them. So that's when I started getting interested in security and luckily my first job at a startup and even prior, I guess in terms of internship, I got to work in the SOCC, and my first job was at a startup where you could pretty much do everything, since it was a small company. So I made building a lot of security practices from scratch, including building the SOCC team, I think it's a very good opportunity for me to learn from all of that, and setting up Enterprise Security, Data Center Security, Cloud Security, and build all the foundations as an engineer from scratch, so that sort of helped me in my future roles, as I grew, and started leading other functions in security.

David Moulton: So, let's go back in time to when you were at alarm.com, when you were there, you established their perimeter, their enterprise, their infrastructure, and IoT security programs. I'm curious-building security from the ground up, early on, what did that teach you that still shapes your approach, and your view of security today?

Birat Niraula: Yeah, so I mean, first of all, when I first started it was quite overwhelming because my first project that I owned was building IDS Intrusion Detection System across multiple data centers, and there's no instructions. This is 2010 I'm talking about. I pretty much got a book and said hey, we need to implement IDS in our data centers, because we manage IoTs, and we get tons of signals from everywhere, and we can't tell what is attack and what is not. So after doing that, which probably took more than two months, then I started realizing there was a lot of research involved in it, right? Because you actually had to understand the protocols, how every application worked, what's an attack, what's not. Build the rules, tune the rules for the intrusion detection system, so that taught me a lot. And also gave the confidence that, you know, I could pretty much manage anything, right?

David Moulton: When you were working on some of these ground up systems, or even today at Google, are there lessons learned and/or lessons reinforced where security UX is not just a design issue, but you realize it's a risk issue?

Birat Niraula: Yes, I mean you learn that over time, I believe, right? And it took me quite a few years to actually understand all of it. I think by the time I got to Century Link is when I really started understanding it more deeply, because I was building products for customers. And that is when you start getting a lot of what are customers seeing? What do they actually care about? They probably don't care about every single vulnerability. They probably don't know about every single risk that the organization is facing, right? They just care about the important things. And there is a lot of bypass that can happen if you make security too strict. But then I definitely feel I was a security engineer that wanted to do the right thing and wanted to secure the infrastructure no matter what, not putting a lot of thought into what could be the overall impact to the company, to the velocity of the products, and everything about that, right, it strictly focused on doing the right thing in securing the organization and over time, we obviously evolved. We put a lot of thought into thinking about the end-to-end impact of something if we're starting something new.

David Moulton: You know, when we were talking about the show, you were explaining how a security design for-or the security UX-could add a few seconds, or a, you know, half a minute to a process, but at the scale that you're looking at today that could be days and days worth of productivity time, where you're waiting on an NFA code to come through, or you know, those sorts of examples. And I wonder, when we talk about security UX, you know, what does it mean for infrastructure and cloud teams? How do you think about balancing risk mitigation, you know, those control layers, with that user experience that you're rolling out to internal users, some with elevated privileges, to guests, or to vendors and partners, all of which you face today with your role at Google?

Birat Niraula: I'll provide a generic answer at first, right. I think of security as a tradeoff, right? You are trying to improve security, you have to give up on something. What you trade could be user experience. It could be resources, it could be the velocity that you're giving up. So there's always a tradeoff, you know, if you're trying to improve security in every aspect. And obviously we ask people 20 or 30 years back, right, would you want a password on your laptop, people say no. They probably wouldn't want the password, right? Let alone having like complex passwords that you have to change constantly, and then on top of that, MFA, hardware, software, you know, whatever, right? So if you ask the users what the admins did, where they would say-or any IT-they would say you know, they'd want to put the minimum controls so that the user experience does not get impacted, right? But you've got to be able to balance it, like you can't just not have a password on the laptop, and we've come over, we've come through that portal, past that portal, already many years back. Everyone, all of us, now if you think about 10 years back, 10 or 15 years back, we didn't have passwords on our phones. Now, we've got like, you know various types of passwords, right? So users have actually adopted all of-a lot of this, and they understand why it's important. And they don't disable it. Like, everyone is using it now. So it is a journey for all of us. But as we look at how do we scale security, how do we make sure people actually understand the tradeoff, why some things are required, there is a lot of user education that has to go behind the scenes. Right? And also gathering early feedback from a lot of people on how is this going to change the user impact, because a lot of times, security folks do not understand what the end users go through. Because you have a different perspective, right? You're like yes, I understand, this is a little bit of extra work, but as you pointed out earlier, it's extra work for a company of over like 400,000 users for example.

David Moulton: I want to switch gears for a second. Every time I talk to anyone who is working in dev-ops environments, and the cloud, the number one thing that they're concerned with is speed. You know? Anything that slows things down tends to be seen as a problem, and I'm wondering where your security teams most often have to slow down your dev-ops or cloud teams, and where you think it's really unnecessary and you can just let those teams run unbridled?

Birat Niraula: So generally, most companies, especially now, right, are looking at how to improve velocity across the board. How to use AI to scale, how to do better using technology to solve the ongoing problems. And on the flipside, you know, if I put on the hat of this, you know, like someone who leads security, then you see like the risks that we are creating for the future.

David Moulton: Okay.

Birat Niraula: Because, you know, I've been through this journey in the past, right? We-like, every company started adopting cloud without understanding how cloud works. Every company was on board with dev-ops model, instead of the systems engineering, and different teams doing different things, right? Dev-ops, you build it, you own it model, bunch of companies actually adopted that. And the team that built it and owned it probably did not have a good understanding of security or operations stability, and then they ended up owning it, right? So there was a lot of learning we went through as an industry in that, you know, shifting from that, like older way of operating to the new one. And what you see over time is you need to really understand what is the risk appetite for the organization? Like what is getting exposed? Right? And really understand what do they care about? I'm, like, I'll give you an example, right? I cannot go to a brand-new startup and then try applying all the security controls that we apply at Google and say everything is need required.

David Moulton: Right, absolutely not.

Birat Niraula: Google's doing, right, so Google's doing it for a reason. It is necessary, because at the scale Google operates, as type of attacks that Google gets, you know, across its product areas and everything, right-it's enormous. Right? And the, like the amount of state-sponsored, you know just think about it, any type of attackers across the globe, right? Google is a primary target, and I can't go to a startup that no one knows about, for example, or very few people know about, and say you've got to apply all these controls because it's going to make your business secure. It just doesn't work.

David Moulton: Absolutely! Where the risk model's completely different, yeah, what Google's facing as a target, and the impacts of those attacks are different. I'm curious, can you talk about the difference between friction that protects, and friction that creates risk?

Birat Niraula: Sure. I think it's a very interesting question. So let's start off by friction that creates risk, right, when it creates risks in this-or when it creates additional protections and add hurdles where a system user or any user, they would try bypassing it, because it impacts velocity for example, product teams essentially just want to launch their product, and then debug, fix the issues ASAP, so that they can launch the product fast. And if you have them go through multiple ops of pushing the code to dev, and then to validate and test, and then in production, just to validate whether the same change they made earlier is going to to cause problems or not, that is, right, it takes time to do all of that. So then, you know, we've seen examples of multiple teams trying to inject a backdoor so they can directly access the production servers, or infrastructure, so that they can directly troubleshoot, for example. Right? Especially you see that in case of ML workloads where they want to change the model, tweak the model really fast in production, so then how do you do that, right? That actually, that friction actually creates the risk of them bypassing and also provide an avenue for attackers to just utilize the same backdoors to attack the infrastructure. But on the flipside, the friction that protects against the risks are the ones such as, you know, like examples we shared earlier, right? We have a password, we use MFA, it makes it harder, and the refresh tokens, like the refresh, like the access tokens expire after a certain time and you've got to be able to refresh it. So it narrows the window for an attacker same way going through a production server through a hop-it's a, or a jump host. It's an extra step, but it makes it really difficult for someone to not be able to go to the production servers directly or use the credentials that they've added. So that sort of adds a lot of, you know, protects against a lot of risk that is necessary. If you don't have that, you're just making too easy for the attackers to just bypass. [ Music ]

David Moulton: So, as I'm listening with my designer hat on, some of the things that you were talking about where you've created friction that legitimate users try to get around, and therefore attackers can, might be where you've not been thoughtful about what the impact is, and then on the flipside, where the protections really do help out, it's where there has been enough at-bats and enough study of how people are interacting with that control or their exposure to it, so they're used to it, yeah, but it comes down to refinement and tuning, and not just blanket-here's a policy, here's a control, this is exactly how it's going to work. And I suspect that if you were to, you know, think about this, you know, or you know, challenge me on this idea, as you roll out security it has to change over time, but so does the user experience of that security. It's not a fire and forget, and you never come back to it. It sounds to me like you're going to come back and look at it over time and make sure that it's the right amount of control and the right amount of friction to match the risk that your facing as things change, right?

Birat Niraula: Right. So, I think we take-you know, personally I've done a few things to be able to manage this, right? And sometimes, I think you talked about this earlier, right, how do you improve velocity? How do you allow like folks to move faster, and we've done that, we've done that several times. But we go back and ensure that there are exceptions that are being looked at on a regular basis, so then someone wants to move forward, and dev infrastructure we'd probably give them full access in there, because it doesn't expose any sensitive data or any production data, for three months let's say. That access expires in three months. That exception has to be revisited again, as in, is that required? Do they need the same access in production? Have they sorted out everything? So then that is still helping velocity, like improving velocity and letting the teams build what they do best, and not focus-not be slowed down by security, but then when you revisit it, one of your responsibilities is also work with the team to figure out that sometimes we come up with very creative, you know, you'd be surprised what type of creative solutions we'd come up with at times to help the end user, rather than just using a sledgehammer approach, as in, this is the only way we could secure it.

David Moulton: Absolutely.

Birat Niraula: You know, we try being creative around applying compensating controls, so that infrastructure, when going to production, still remains secure, right? So it is something we have to look at constantly. And the other thing we look at is, across the board, and basically, you know, my team spent some time at this as well, right? Across the board, we look at what's being used right now? Like actively, in terms of access, and whether that's network access, user access, and so forth. What's required? What's not required at this point? What's the usage like, right? And sometimes, we just remove usage that hasn't been there for a long time, for example, right? So that's how we look at things at scale, to figure out what's absolutely needed, to ensure that it's secure. And the second part, we don't need backdoors, I suppose, right?

David Moulton: Right.

Birat Niraula: And third, if the application has morphed or is doing something weird, then we are also able to flag it, as in, this is new. Like this never existed. And like, what, well sometimes it's like you're requesting this, but we never saw this in the architecture or the design. What has changed, like, why do you want to connect to an external vendor that's not even approved for example, right? So we look at it from multiple lenses.

David Moulton: Birat, I want to go back to something you said a moment ago. We're building the future without understanding the risks. I'm curious, you know, you were talking about going into a world where everyone moved to cloud, right? Are you seeing that happening today? And if so, where do you see that specific problem happening now?

Birat Niraula: So there are a few areas. Most companies are in the cloud journey now, right? So most are actually using cloud to a certain extent. I don't think most companies actually understand what type of use cases they have. So then, they're being able to balance that, right? So the first part, and this is a classic problem you see, right? End users don't know what security clearance you have. You don't know what the end users actually are-or the application teams are actually building. So, there's no understanding. Like there's a lack of understanding between what the end user is doing versus what are the policies, right? then it's both ways. And that's, you know, and the same thing is that currently the trend I'm seeing is on AI. You don't know what type of models are being brought in, what type of data is being used, what type of protections we have against the data, what type of infrastructure is being used to secure that data. And we are just building models, and like we are using bio code, for example, in some cases, right? And you don't know what the-and most people, if the code works, why would they actually go and look at is, are every software library is that the code produced, or every part of the code important for you or not? Is the model sanitized, the model you're importing, to do something like phishing recognition, recognition for example, right? Did you pull the-what's the support like for that particular model? Like who is supporting? You know, it's like open source problems that we have, right? We are going to see more of this, and that's why I was saying earlier that we've been through this journey of people starting, or companies starting to use cloud without understanding what they actually wanted of cloud, and also what, like how to secure a cloud, and toward end users, what are they using within the cloud itself?

David Moulton: Right.

Birat Niraula: Right, and the same probably is being replicated now, in the case of AI, and in some cases, also in case of new products that the cloud services are providing as well.

David Moulton: Well, and I felt like I was leading the witness a little bit, but I wanted to hear it from you because we keep seeing folks rushing into AI, rushing into deploying or pulling in a model that they don't fully understand, or exposing parts of their data to, you know, different interfaces, and they're not entirely clear where that's going, what's being trained and I felt like I saw the movie before, and it sounds like I have, you know, it was just called the, you know, the cloud, you know, transformation the cloud. Let's-let's go back to something you were talking about just a moment ago of, I'm building something new and I desperately just want to see if I can get it built, and I'm not thinking about security. How do security leaders partner with engineering and product teams to move security left, right, like how do you help those teams build secure experiences by default? What are some successful tactics or stories that you think are models for our listening audience to try out for themselves?

Birat Niraula: So, I think first of all, best security is security that is seamless, that the users don't need to know about, right? For example, if you look at Google Chrome has a browser. Most people don't think about updating it regularly or patching it and rebooting their machines and so forth, right? It's done by default, and they just press update, and it happens, right? And everything works as is. So users don't have to think about so many types of attacks and everything that is going behind the scenes. So I think that's the best type of security, like seamless, embedded. People don't know. Frictionless, pretty much, right? But that's tough to achieve. And we see that all the time. It's-it's, like I will say it's next to impossible, but it is quite difficult to achieve that. And what has worked for me throughout the different organizations that I've worked for is being able to embed some of the security teams, like some folks that actually, you know, work-have worked in my team in the past companies, or now they generally are embedded as part of the design process. But to do that, you need to figure out and have that regular touchpoints, so that you understand what's coming ahead in six months for example. What's coming ahead in a few months in some cases, right? And what's urgent sometimes, and you've got to be able to like embed your security teams within those organizations and product teams so that they start building secure by design solutions. Right? So then, if the teams actually understand how to implement something, then you know, they could potentially support it. On the flipside, what also happens is, and this is a classic for every company is dealing with this, right, you can't have enough security engineers power everything. Right, to be able to scale and support every single thing that is being built out. That's just not going to be possible right? So the hybrid approach we are trying to take at this point is building some sort of AI agent that is probably going to help you out in a lot of questions like you build a design, would the design be auto accessed and provide the guidance and requirements and everything like that, right? And as we build this, if we become successful in this, I think that becomes an amazing model that is going to be able to scale and support very, very large use cases across the board and you spend less times of your engineers and like less resourcing from your side in order to support that, right? And you actually end up, whatever you learn, you just go back and try updating the model itself, rather than trying to tackle one use case at a time.

David Moulton: I've talked to a number of engineers about having an AI assistant look at your PRD, or your, you know product requirements doc, and then also look at your policy, and look at your code, and how you've built things, and make sure those three things come together, and then flag when they don't, or flag when there's a little extra work that needs to be done, and I look at that and I think, you know, that would be amazing. You've got to then protect the policies, and the PRD, and make sure that those aren't compromised. You know, maybe a different problem for a future state. But it does seem appealing to be able to have at your side a security sidekick for every engineer that is running through and checking those things, flagging them early on before you go into a test or a production or you know, you're out there, and you're on the backside of a breach, trying to figure out where did that problem come from when you could have known about it, you know, in some cases, you know months, maybe years before. Okay, when we're looking across the hybrid and multi-cloud environments, which is an area you spend a bit of your time, where do you see the biggest UX-driven security gaps today?

Birat Niraula: In a hybrid, or a multi-cloud infrastructure, I can specifically talk about UX experience problems where the security engineers themselves, right, you have a control that you need to apply, or think of compliance, or security, anyone, right? You know what you need to do. You know your company's policy. You probably know your compliance frameworks that you need to adhere to. How do you apply that across multiple clouds? How do you apply that across unplanned versus cloud? I've run into this problem in the past, right? And you need to be able to understand multi-clouds really well in order to implement those controls. Because all clouds don't work exactly the same way. The way you implement, let's say high-end controls in a particular cloud infrastructure is different than the other cloud. The way you do that where you have more control is different than you know how much control you give up on the cloud. So you know, like it's a problem for security engineers, and at the same time, how do you make sure those controls are applied by other teams? Because any hybrid-let's just take an example of a Kuberneti's cluster that runs on prem and then skims to the cloud, how do you manage that? Right? Because the networking stack is different in the cloud. So then you've got to build, you've got to be able to work with those teams to design it well, so that they can build it right, so that it works across the board, same consistent practices are built across the board on both the sides, right? and that's how you solve some of that. I think the other important thing is to also look at, you know, I think what I shared earlier, right? You know the exact use case. Right? Cloud makes it super easy for anyone to do anything, right? And unless you know exactly what-how do you secure a cloud? How do your requirements actually map to a particular cloud provider, or to 200-plus services that they offer? You can't just be able to help the other teams secure it, right? Because all they care about is, you know, launch the product and move on, pretty much. So you've got to be able to help through that, and it's-for security engineers, it's a lot of learning and understanding. But again, you know, the point I was making earlier, right, you've got to be able to start, not think about how do I solve this, the entire problem, but think about which is the most important problem to be solved at this point? What is the baseline requirement for me, right? And then build upon that baseline, rather than trying to think about every way I can secure an infrastructure. Think about what's the baseline, so you make it easier for the other teams to understand what the baseline is, maintain that, and gradually over months and quarters and years be able to improve security rather than try and do everything all at once and impact the velocity and experiences for the other teams.

David Moulton: Thanks so much for an awesome conversation today. You've got this former-designer fired up talking about the intersection between you know, security, UX, and risk, and then you get to apply that in the real world environments that you've been in at Google and some of the big financials that you mentioned earlier, all the way back to the alarm.com days, so I really appreciate what you're working on. I'm sure that you've got hundreds of thousands of Googlers out there that appreciate what you're doing, they just don't know it, because you're running in the background making an awesome user experience for all of those customers of your product, if you will.

Birat Niraula: Yes, I really appreciate the opportunity and thank you for your time. [ Music ]

David Moulton: If you like what you've heard, please subscribe wherever you listen, and leave us a review on Apple Podcasts, or Spotify, those reviews and your feedback really do help me understand what you want to hear about. And if you want to contact me directly about the show, just send me an email at Threat Vector, at PaloAltoNetworks.com. I want to thank our Executive Producer, Michael Heller, our Content and Production Teams, which include Kenny Miller, Joe Benecourt, and Virginia Tran. Original music and mix by Elliot Pelsman. We'll be back next week. Until then, stay secure, stay vigilant, goodbye for now. [ Music ]