The Security Policy Rollout Survival Guide

Hello, this is the security policy rollout survival guide. Uh, and I am Maya Gatski. I'm the founder and co-founder and CEO of Oblique. Uh, oblique is a access and group management solution. It's making your access self-s serve and explainable. And before that, I worked in at tail scale where I led product and where I led product and engineering. before that at uh GitHub on software supply chain security where product and at Google cloud on container security and encryption and I've been in security for a long time. I suspect many of you have been in security for a long time. And one thing you realize and you start to learn is that the technology doesn't really matter all that much

because a lot of what makes security hard to implement is getting people to actually do what you want them to do. Getting people to follow the security best practices that you want them to follow. And some of that is controls but a lot of that is organization or process. um defining a control that's actually possible to implement and implementing it are different things uh entirely. And so that's what we'll be talking about today. We'll be talking about security policies and the controls and you how you roll them out in your organization. And when I say security policy, what I mean is something like um we want to have MFA on all of our SAS apps. We want to use UB keys for product

access. Um we want to require a peer review for any code that gets merged into our environment. So the policy is the the thing that you're trying to achieve and then the control is how you're actually going to achieve it. So something like the UB key or something like uh branch protection rules are how you're going to enforce some of those things. This talk is about everything that happens between when you define that policy and those controls and when it's actually like live in your environment. So all the steps you have to take in between A and B. Um, one thing I'll note is that not every environment is the same, but specifically your prod and your

corporate environments tend to be quite different and how you roll out policies to those will will be quite different. So your prod environment tends to be more homogeneous. Um, it tends to be the same kinds of VMs or the same kinds of even like hardware on the same cloud whereas your corp network is probably going to have a mix of different kinds of devices. you might have uh if you're running Linux, you're not necessarily getting all the same OSS that you would be getting in your prod environment. Um your prod environment also has the security team has more say I would say where uh the security team gets to say here's what we're going to do because

we're keeping user data secure or business secure whatever it happens to be in your corporate environment. If sales wants to do something they tend to win uh because that is how you make more money in in in your in your in your corporate environment. And lastly, I'd say the the users that you have in the two environments are very different. In your prod environment, um you're often dealing with more technical users. They tend to be engineers who can understand more complex controls and work with more complex controls. Whereas in your corporate environment, you need to make something that works for all the users in your environment. For all of your employees, your interns, it has to work

for someone in finance. It has to work for your designer. It has to work for absolutely everyone in your organization. So let's jump into what that looks like. So, the first thing you're going to do is everyone's favorite topic, stakeholder management. Can you tell I miss being in a large organization? I don't. Um, the you have to identify who you're going to work with and get their input and make sure they're on board. And again, going back to those two different kinds of environments for your prod environment, that's usually going to be um engineering. And engineering wants to know uh well, first of all, like, do I have to do this? And if I have to do this, how long is it going to

take? And some of how you gain the the trust and the the buyin of your engineering teams is making sure it's easy for them to implement. Is there a library that they can use? Are there some code samples or examples? Has another team already done it? Are all good ways to get to get folks to understand if it's possible and and what they're getting themselves into. Some of the other teams you have to talk to here are um product as a former product person, current product person myself, I can tell you I will ask you, do I need this? Do I need to do this to ship? And that's also why you end up with

situations where for example um companies will say here's the requirements for beta and here's the requirements for GA and your security requirements often end up under GA because you don't want necessarily want them to block what gets to the customer and gets early feedback. Um and a product person is also probably going to weigh this against other tech debt. They don't necessarily see a security control as being different than all the other tech debt they hear about hear about from their engineering team. So you're going to have to explain why that's different and why it's more important than some of that. The SR team also tends to get very involved. They really just want to know

who's going to get paged uh if it's going to have any impact on reliability and introduce any new dependencies. And then in your corp environment, um your primary stakeholder is IT. Um it and security have a sometimes fraught relationship in corp environments, right? If security is writing policies and it is the one implementing them and rolling them out, um it really wants to know are we responsible for this? And then unlike say engineers in your prod environment who might be able to go fix something themselves or have the the technology to change something themselves, it needs to know like who can we talk to when this is broken because we can't fix it. So there better

be someone we can talk to to fix it. Um HR is going to ask you how it affects employees, finance, how much it costs. And then it's not so much that legal is going to ask you questions as much as you should really talk to legal about um any controls that you just can't roll out. So what I mean by that is there are certain things you really shouldn't do to employee devices. Um and you should talk to your lawyer about that. I'm not your lawyer. So how you get buyins from these stakeholders is not different than any other kind of change management. I'm not telling you anything new. Get their inputs on requirements. Agree with them

on what the actual controls you're deploying are with the definition of success looks like. Um answer any questions they have and and make sure that you're you're addressing any concerns they have and then keep them updated. And how you keep them and other folks updated is obviously through communication. When you're rolling out a security policy, you should be communicating way more often than you think you need to, way more often and in multiple different ways. Um, communicate constantly. So for your for your for your users and your stakeholders, get their input while you're developing that policy. And then as part of your policy roll out um get input from from your user or sorry communicate to your users

what's changing when and why. So you know we're going to start enforcing uh branch protection rules next Monday for sock 2, right? And the why is really important kind of like I'm telling you the why right now behind why you're doing these things in your policy changes. You need to tell that to your users for them to trust you and understand why what you're doing is important. You should also tell them how they can get an exception. Sorry, I don't know if this is just me or it keeps cutting out. >> Yeah, >> I'll switch mics. >> Amazing. All right. And uh and how to get an exception. So, if you have um users who already know that they're not

going to fit into the scope of what you're dealing with. Um making sure they can kind of signal that to you early. And for those stakeholders how they can escalate any issues that they hear about from their teams as well as give you feedback on things that aren't working while you're doing the actual policy roll out. Um again overcommunicate tell users again how to get exceptions. People who didn't realize they might need them before now need to now need to get exceptions. Um how to get feedback as well as any changes. So if you were originally going to enforce something for a larger group and you're now only enforcing it for a smaller group, don't

get a bunch of people to do work if you've changed your requirements. Like don't do that. um share progress with your stakeholders and then once you've rolled out that policy, thank everyone who did all the work. That sounds really basic to say, but they will they will be happy about that. And share success with with your stakeholders and leadership. So you need to run a pilot. Um you really should test things before rolling them out. Um there will be edge cases. your controls will fail in unexpected ways. Just like you hopefully would not roll out a change uh in your code without testing it, you should not really roll out a change to your users

and your devices and your environment without testing it. I know that's not always easy. That's why we have pilots. Um you also really need user feedback. Um your users again will hate you if you don't listen to them and you would like them to not hate you. Um a good pilot has four elements in my mind. The first is a representative set of participants that you're that you're working with. So what I mean by that is if you're testing out a control that changes something in your corporate environment, don't just ask the info team that sits next to you to test it. They're all engineers. You know, get someone who works across the company. Get people who are again

designers finance marketing whatever it happens to be to test out your controls. You need a diverse pool of real participants. Um, and you also want them to have enough time to engage with you on this. So if there's a team that has to urgently ship something next quarter, they're not the right people to talk to about running running this pilot. You need enough time to run your pilot. So what I mean by that is there are some controls that only um get triggered every once in a while. Maybe you have a policy, a bad policy of people making people change their passwords every 90 days. Don't run your pilot for less than 90 days. Sounds really obvious, but but

don't. Um, you also want to make sure you build in time for enough feedback and to iterate on that feedback. Um, and this is just a like a cultural thing. Like you'll know how long this is in your organization. Your pilot's probably not 5 days and your pilot's probably not probably not um a year, but you know, weeks or months is enough to run a pilot depending on what kind of change you're making. You'll need a support channel. So, a way for people to escalate issues and give you feedback. We'll talk about that more in a second. And you'll also need clear success criteria. So, an understanding with the folks that you're running a pilot with about what good looks like.

Um, success for a pilot is actually, you know, really easy to define. So, you should define success for your overall policy real, but also for your pilot. Success for your pilot is that you decide whether or not to move forward. That is success. You're trying to get to a decision. um you can usually go when you know that you're going to if you implement that rollout, you're going to get the desired outcome in terms of the security improvements you're aiming for. And this is also like addressing any blocking bugs. Um making sure that your users aren't overwhelming you with support tickets or or requests. Basically, the burden is manageable. Um the other thing I'd say here is you you

should know where you're starting from. So if your goal is to get a certain percent of people to opt into something, you need to have measured uh the beginning point of that of that uh journey and you'll be constantly iterating based on and throughout that pilot. Um so you have to gather feedback in that pilot to do a couple different things. The first is to to find and fix kind of any issues you might find. It might just be bugs, but they might also just be things that users are really frustrated by. So, if you have a requirement for people to reoff before they access prod, like are you sure they're re-offing once and not

having to hit like four different reoff sessions, which is very frustrating for your users. Um, another reason to gather feedback and iterate is that you need to identify edge cases. So, there's legitimate scenarios that you might not have considered when you were developing your policy or your controls that you just never thought about. And so, making sure that your controls work in those in those situations as well. And the last thing here, it's quite important, which is testing your controls actually work. If you're putting all this time into rolling out a policy and rolling out these controls and users find a way to circumvent them, they don't work. And so, don't waste everyone's time and keep

going. Figure out what does work or what would actually give you the same the same desired outcome. You can gather feedback in multiple ways. Again, I'm not saying anything that's not obvious. You know, Slack, email, um, some teams run office hours. Um, surveys are an option. I tend to find people don't really respond to them that much. um direct conversations tend to work best, one-on- ones, you know, water cooler chats, whatever it happens to be. And then also consider having any kind of anonymous feedback mechanisms for especially again depending culturally on your organization, people may not feel comfortable uh criticizing you publicly. And so giving them a way to give you private feedback, whether in

a one-on-one or an anonymous feedback form. Once you've run that pilot and got got a bunch of feedback, your goal is really to do triage of of all that feedback and figure out what you have to address. um in terms of prioritizing that that that feedback. It could be things like is this affecting only some percent of my users or my fleet. Um is this a bug? So is an actual issue versus is this an improvement or something that's that's causing friction and frustration? And really the question here is is this blocking? Right? If we go back to the goal of getting to a go or no go, is this blocking the wider rollout? The

other thing to consider is can we handle this case differently? Right? If we don't have the right controls in place, is there a different way for us to handle this situation that meets the same desired desired goal of what we're trying to implement here? >> All right. So, you've you've run a pilot, you're ready to go. It's a go. It's a go decision. Now, enforcement and and rolling out your policy is when you actually flip that flag. You've decided the pilot is successful and you're ready to turn it on for everyone. There's three main points I want to share about enforcement. The first one is that you should make enforcement visible. The any individual should be

able to see if they are in compliance, if their device is in compliance, if their system is in compliance, if you're a manager, if your team is in compliance. That is super important to get people on board and actually implementing what you need. This also like puts you a little bit in the puts you gets into the the observer effect, right? If you measure something, people will actually change the outcome. And so if they see that it's being measured, people will act differently as a result. Um, you can also be more explicit and make like, you know, real carrots like people swag or virtual thanks or whatever it happens to be. Again, what you do here depends on your

organization, but to me, making it visible is like the minimum bar of what you should be doing. My second point around enforcement is that there is a correct way to do enforcement. Um the there's a good there's a correct way to think about how good your your the enforcement of your policy is. So you could start with just saying hey you have to do this. Hey you guys have to use a password manager. Okay you could make it a social norm. You really should be doing this thing. You can make the the policy uh visible. This goes to what we were just talking about. You know 80% of your peers are doing this. Therefore you should really

be doing it. And to me that's like if you get there you've gotten more than most people have gotten. And so like that's the that's in my mind the middle level where you should get to. Um you can make it easy and this is the you know the idea of security um pave paths or secure by default. I think people get tricked by the word easy. Making it easy is not easy. It takes a lot of work to get to that state. You want to do a lot of user testing and feedback to make sure it's actually easy. Um, and I will, if I have to mention AI once in this talk, I will say I think you have to get

it to easy for AI agents if you want AI agents to do it that way. Um, and the last thing I'll say here is the last level is making it automatic. So people don't even realize they were actually in line with your policy. Um, and that's in my mind the best outcome. This is like the idea of invisible security. Your goal should be to get your policies the furthest to the right on this slide as possible. That doesn't have to mean you have to do it all at once. Like you could roll out something that's visible and then come back six months later and make it easy. Sure, only the newest people will benefit from it, but that's

still worth doing. That work is still worth doing. Um, one example I'll give here is when I used to work at Google on encryption, um, when they when they wanted to implement encryption at rest in all the systems, rather than telling people, hey, you have to do it, rather than saying, hey, here's an encryption library, which they also did, they went to all the storage teams and built it into the storage systems. So anyone who built on top of the storage systems had encryption at rest by default without having to do anything without even realizing it. I remember I would talk to people and be like, "Oh, are your systems encrypted?" They'd be like, "Oh,

I don't know." And I'd be like, "They are. You're like, you don't have to worry about it." And the last thing I'll say about enforcing policy is um the person who sets the policy should be the one who enforces it. So the too often security will write a policy that someone else has to implement and own on a day-to-day basis. I see this a lot with corporate security teams and it uh but you also see it with people saying like oh the manager is going to take care of it. I think the managers do a lot guys. Okay. Um and that means that you don't have ownership from the security team over that policy. Um that also often means

the policy is not properly implemented. The person who's implementing it and managing it on a day-to-day basis doesn't have the same incentive you do. And so you spend all this time rolling something out and then it doesn't work. Um, so the person who enforces the policy needs to feel the pain. They also need to be the one to deal with exceptions. Um, which we'll talk about. So there will there will always be exceptions to your policy. Always. There will always always always be exceptions to your policy. Um, what matters about that is knowing that there's going to be exceptions and making sure your system takes that into account. Just assume there will be and and take that into

account from the beginning. Um the other thing that's important here is is how you actually manage those exceptions. So we'll talk about that. So there's lots of reasons somebody might need an exception. Uh some of the most common ones are around uh specific departments or employee types. So maybe sales does have an exception to record to record certain meeting calls or run certain software. Uh maybe contractors do have an exception around um where they can log in from um specific platforms. So certain devices are allowed to have BYOD or whatever it happens to be. Those are the ones that you think about. There's lots that you don't think about. So if you ever talked about folks about um building security,

you know, for everyone and making sure you include different sets of users in your research and that type of thing, there is going to be users with disabilities that have a very legitimate exception around having um different keyboard tools on your devices. And you cannot block those users from doing those things or else they won't be able to do their jobs. um you're going to have demo or test environments uh or devices. You know, the sales team really does not that does need that to be publicly accessible. Um that device really does need to be not up to date. And so there's lots of reasons that that has to happen. And last one here to mention is around

automated workflows. Maybe your your process around an automated CI push should not be the same set of controls around if a human is pushing um pushing something to production. There's also going to be situations where it's not so much an exception as much as the control that you want to implement just does not exist. Um, for me, the the most typical one is SAS apps. Um, there are so many SAS apps that don't support SKIM, that don't support TOFFA, that don't support uh requiring a specific domain, and there's nothing you can do about that. Um, and so there's just situations where you can't handle the same, you can't have the same control that you'd like to

have. Um, often the objections that you're going to hear to your policy are going to be about the gray areas. So, let's take pure code review as an example. Okay, so we want every we want all of our changes to production to have a pure code review. Okay, but our docs are in the same monor repo, but they're docs. They don't need pure code review. Well, I don't know, do they? They're in the same monor repo. Um, can they run arbitrary code? Like, there's an interesting question like what's the right answer here? your device unlock. Well, my I'm using my my iPhone for work, but I don't want to change my password to more than four four

character PIN. Okay. Well, then do you need to access your work email on that device? Do you need to access customer data on that device? Like, what's the right answer? Or security training. Does the barista who's a contractor really need to do fishing training? I don't know, maybe not. But does the contractor who um does vendor security review need to do fishing training? Does the contractor who does you know marketing automation need to do security training? So there's not a right answer in these situations. And I think you can either change the scope of your policy or you can grant exceptions. It you have to think about what's right for you and like what the actual

controls that you're solving for are here and what the right scope is and and how you want to maintain that going forward. Uh the last thing I'll say about exceptions is that you have two kinds of exceptions. Long lived exceptions and shortlived exceptions. Um long lived exceptions are the situations where the user or device that you're putting in scope will never be able to meet the policy. They need a permanent exception. Um you should track the reason. You should track the set of it's usually the same kinds of reasons. You track those as a group and you should make sure to regularly review that exception, but it's not going to expire. You don't want those those users those devices to get

blocked out. You just want to make sure you remember that they're there. Shortlived exceptions are usually a situation where a user or device can't meet your policy right now for some reason. It's often based on a a lacking control like we talked about, but it might be a project that they're currently working on or something that's going to end soon. Um, and so in that case, you want to again track the reason, track them as individuals or as a group, and automatically expire the exception, right? Make sure that it's going to go away over time, not get worse over time. So, you've done a bunch of work, you've rolled it out, you've managed the exceptions, uh, we're done, I hope. Um,

I think that your policy roll out, in my opinion, should have only really two success criteria. You can define lots of other ones if you want to. One is, did you meet the security goal you were trying to meet? and two, like do your users hate you? And the if your users are frustrated, like good luck rolling out another security policy. And so I think the the second criteria there is actually way more way more important than you realize. Uh and then there's everything else, right? Like you can have lots of other very precise criteria, but at the high level, that's really what you need. Um does it work? And did I get did I not

lose enough social capital to do it again next time? So what we've talked about today is, you know, the map of what happens between when you define that policy and those controls and when it's actually live in your environment. You got input from stakeholders. You communicated out what the change was going to be. You ran a pilot. You got feedback from that pilot and iterated on what you were actually going to put in scope, how you were going to um uh handle any controls that you didn't have covered. And then you rolled out the policy. And then managing exceptions is not a one-time step on that journey. It just keeps going. you have to constantly manage exceptions.

You are never done with that work. Um, so hopefully hopefully that wasn't uh too much work for you to do. Um, that's all I got for today. Thank you so much. Uh, my slides are online. And that's the feedback code. Thank you. And I I'm happy to take questions. >> Yeah, the the question is um, sometimes the team is too small to handle the policy roll out. What do you do in those situations? I and in in my opinion, you either roll it out more slowly in a way that the team can actually handle it or you kind of escalate and say to leadership, hey, are we really doing this? If so, we need more help. Uh I know that that doesn't

always happen in practice and sometimes things are on fire. But if it's if it's truly just a size constraint, like that team still needs to be the one that feels the pain and understands it and works on it. Um rather than say like passing it on to managers. >> Yeah. Um, which comes first, policy or control? >> The question is which come first, policy or control? Uh, I would say policy and because I think people tend to get a hammer and then or what the whatever the expression is get hammer and only snails. Um, the the control is one way to meet your requirements. It is not the only way to meet your requirements. And

I think that we tend to overfocus on what's right in front of us rather than kind of going back to first principles and thinking about what we need to do. So the question is if you have a very large volume of policies that you are dealing with, how can you actually kind of make sure you go through all of those and implement them um and not have fatigue? I mean it sounds like you're handling too much. This is like when I talk to people who are trying to get like four compliance frameworks at the same time. It's like that's probably not a good idea. Yeah. Yeah. Yep. Yep. Um, so I think you're making a comment that

if we have uh something like gleaner perplexity and it finds it can read through all of our policies and tell us all the gaps that we have in our environment, >> all the firewall rule sets and everything that is not conformant or why they are. >> Yeah, I think what you're describing is I also what I've heard um in the in compliance land called like GRC engineering. I don't know if you you all have seen some of this, but people codifying um whatever requirements that you have in your in your compliance frameworks as code or as Terraform more frequently and then seeing that that actually is true in your environment. If you have a bumpy roll out, what are some

things you do to build social capital? Probably like cake. I think that's a good choice. Um any other kind of like, you know, incentives or carrots like that that people get on board with. Um, I think people tend to be very forgiving if they understand why something happened and and and what went wrong. Um, so I think there's also an element of like owning up that that happened. How do you handle a scenario where you're about to roll out a policy that you're you know will be unfavorable? Um, is the policy going to be unfavorable or is the control going to be in favorable? And I think there's an important distinction there because usually a

policy is set by like compliance, legal, etc. And there's like a very strict reason to have it. And as a company, you understand that there's a strict reason to have it. Whereas often what I've seen is people hate a control, right? I don't want to have to have somebody else review my code. It's too slow. I don't want to have to wait to get approval of this thing. It's too slow. I don't want to have to, you know, do it on a different laptop because I like this laptop. And so it's about figuring out, it's it's in my opinion, it's not usually about the policy. It's usually about how it's been implemented that people get frustrated.

>> Yeah. The example is if what if users have to um reauthenticate every 10 hours and you know people are not going to like it. Um I would make that reauthentication step as smooth as possible like so even if you decide that you that's what you have to do is the reauthentication step like typing in your entire password is it you know going on a particular device and all that kind of stuff or is it a UB key or a pass key or something else that can be relatively low friction. Um and again about explaining the why to the user. Oh, we're doing this because we're worried about persistent product access. >> All right, I'll be here if you want to

talk about anything else. Thank you.