← All talks

Anti-Checklist Culture: Building Useful Security Compliance

BSides Seattle · 202050:26636 viewsPublished 2020-12Watch on YouTube ↗
Speakers
Tags
CategoryTechnical
TopicGRC
StyleTalk
About this talk
Luka Trbojevic walks through building a security compliance program from scratch, covering the journey from zero infrastructure to external audit readiness. The talk emphasizes practical approaches: defining clear control requirements, automating evidence collection, avoiding jargon-filled policies, and maintaining empathy with engineering teams. Key themes include post-audit maintenance, continuous simplification, and positioning compliance as an advisory function rather than a rigid mandate.
Show original YouTube description
ABOUT Luka Started playing with computers as early as I can remember Been doing security and compliance (regulatory and non-regulatory) for the past 5 years. Before then, I did everything from run experiments in the lab to hosting websites/gameservers and playing around with bug bounties. Made the full-time switch to a security compliance function and work with fast-growing companies to build simple, scalable, and automated programs that put security and engineering over opinionated policies nobody can read or understand.
Show transcript [en]

[Music] cool well thanks everybody uh for taking the time to uh join me today um so today we're gonna be kind of walking the road map of building a useful security compliance program uh from absolutely nothing so we're gonna start with an absolutely blank page you get hired into a company there's absolutely nothing there and we're going to kind of walk through the process of what it looks like to go from you have absolutely nothing to eventually external audit and then what you what you do from there and then before we get going i just want to give a huge thank you for everybody who's uh joining us today everyone who's participated uh in the conference uh

all the organizers sponsors um putting something like this together is not easy um and uh you know folks doing this to make the conference happen despite the circumstances uh is really awesome and everyone involved is awesome so thank you so much so a little bit about me uh i'm on the grc team at hashicorp right now um and so helping build out the the security compliance program there and then before that i was at get lab and i joined i think i was employee 450 something and in that year or something that i was there we about tripled in size and we built the program from absolutely nothing and then ended up getting uh that external audit that we wanted um

and then before that i was working mostly startups and build a few security and compliance programs usually a mix often as higher number one for for security and compliance um and then before that i i did a whole bunch of things i uh worked in a lab for a little bit did a couple of research internships i did bug bounties on the side and i uh way way back when hosted uh websites and game servers so i've i've kind of gone all over and i found myself in grc to bring kind of that technical perspective and um you know i just i enjoy putting the pieces together and working with with people so it ended up

being a good fit so it usually helps me to understand why is somebody talking about something what's the motivation um and so about a year and a half ago when i was at get lab i put out this video about soft to compliance and the the reception was really really good i had a lot of people reach out there was a lot of curiosity about this stuff and um i kind of started putting out more content and found that there was a need for it and um this i feel like there's a huge need for this but all of the content our consultancies and vendors trying to sell you things and it's really hard to

get actual information um and so i wanted to put something out there selfishly that anybody can reference keep it open source pull it up on youtube and be able to kind of walk this road map and then who's this for absolutely anyone who's interested but it's mostly focused on uh the practitioner who will actually be doing this stuff managers who need to maybe build a team or are going into grc for the first time and also leaders and startup founders who kind of want to get a sense for what's out there and what are some of the approaches for doing this stuff so i think it's important to talk a little bit about what is security

compliance and what it isn't and so kind of the the top level points here are that um people are buying your stuff and you're one of hundreds if not thousands that come through the vendor process per year and security compliance is a risk reduction function but not for you but for other companies um it's also it's also a way for you to get resources um that are devoted to doing this thing you need to do anyway but getting all of your engineering security and product friends on board that that ship so that they can build and deliver things they otherwise would but that aren't being prioritized um and it it's also a pragmatic approach to

doing external audit so it gives you a good framework it gives you this program level view of of being able to go from nothing to external audit and you might be regulated um you know you need to if you're like a healthcare startup you need to sign a baa business associate agreement um stating that you're doing these things um or maybe you're in like communications and you have the telephone consumer protection act um and so you need to align with these regulations and this kind of gives you a framework to to go about doing that so i want to talk a little bit first before we get started about some of the problems um with the current practices and and

the grc slash security compliance industry as a whole and so this was an interesting um post that came on my feed on linkedin and so the the point dallas is essentially making is that if you talk to somebody in finance or healthcare um everyone seems to have these really special rigid requirements um and at the end of the day it's kind of all just security basics but talked about and packaged in a different way and so i responded essentially making the point that yeah i completely agree with you and i think the reason is a basic requirement like segment your network and d provision users becomes really really really incredibly special um after um maybe the legal team or

auditors or um maybe your own internal grc team put together this like really rigid checklist that you have to go through and everything becomes a special requirement and that's that that's that's the essence of what this talk is about is that checklist doesn't need to be so rigid and and everything doesn't need to be here's a list of controls please deliver for me right now there's there's i think a better way to do it a more holistic people-friendly approach to doing that so the tldr of all of that is that you know security ad compliance at its core is um and i'm sure many of you uh have experienced this it's very very rigid you often get told

these are the requirements you have to deliver on exactly this um and you know from the practitioner view i see a lot that these practices and and the way we do controls is often considered immutable you've seen it once done this way and that's how you carry it for the rest of your career but it absolutely isn't it doesn't have to be rigid and it's not immutable so you get hired into a company and this is what you see there's literally nothing you have no policies no controls um and then ceo or your director whoever says build me a security compliance program so that's what this talk is about and so let's start with that absolute

blank page so the first thing i like to do um when i get hired on for a role like this building a program is you have to get to know the people you have to talk to absolutely everybody you have to figure out what are the things that you're actually doing today um why are you doing it that way you have to ask for documentation and show a genuine key in interest and like what's going on right um you have to really understand your environment like what cloud assets do you use do you just use aws or do you also use um you know azure or whatever um and you have to let them know

uh who you are why you were hired what you're doing and why you're doing it that's so important you have to tell people like why are we doing this what's the goal of all of it so from the very beginning with the blank page there are a couple of there are three main things that you have to do you have to get your policies in place i know everyone's really excited about policies um i can sense the excitement here um and and that's just in essence the fancy way of saying it's a high level description of what you're doing and what people should be doing um and i i like to include uh you know the

scoring rubrics for like risk management and whatever in slas but you can obviously move that to process docs if you want um and then you have your controls and controls is just a fancy way of saying um it's a logical framework for mapping activities you do to your regulations and policies and it just makes things easier to work with so when people say controls that's what they mean and then the third step in all that is uh the gap assessment and that's a fancy way of saying we need to figure out what you're actually doing now and whether it's what you actually need given the the controls and your requirements and stuff like that so the first part is is um uh policies

so let's kind of walk through if i come into a company and there's absolutely nothing there how do you with this useful security compliance program how do you build out the policies with absolutely nothing my preference is always start with a template and so i give two specific examples and these are completely free and open source and you can go to each of these and you can put them pull it put in a pr on github if you want to change them but there are a couple of resources like these i highlight the jupiter one uh policy templates and they also have some nice mappings to controls and stuff like that and then you have like strong dm has

their comply thing which is a fun tool um and and with policies the way i see it is the ultimate policy leaves your typical um you know employee contractor or whoever knowing what you're actually doing and why and so i'm sure all of you have had that experience you open up a policy you have absolutely no idea what's going on by the time you're done with it and so that's the benchmark and and that that's what i like to see is the benchmark for making useful policies somebody without any background going in and actually understanding what you're doing and why um and of course you know for audit time you can't forget your rubrics and slas um

because you will get asked okay where's your risk scoring rubric and you can maybe have it in a process doc but wherever you put it just don't forget um your slas and we'll talk more about that too um and and it's it really is as simple as pick a set you you actually like and so some people prefer comply some people prefer jupiter one some people prefer you know whatever else there are a bunch of free policies out there um make it pick whichever one's the simplest most convenient and kind of go from there and go do a quick review based on your conversations with everyone are they relevant if they're not make some basic changes to kind of align with

your doing and then set them aside for now and so in about a week to a month you can have a whole set of policies for absolutely free it was really easy and you can go through make them relevant for for you know in like two days or whatever it takes so the second part of them now that we put policies aside we've tabled them just for now are the controls and so again it's just a fancy way of saying you're mapping logically these different activities you're doing across your company and it's an easy way to track things so um if you've been part of the grc function or um you know you've worked with grc

team or audit team um everyone's always talking about controls give me your wrist control matrix you know show me what are your controls um and so why all the fuss um it essentially just describes what you do and it maps it back to the requirements so that you can uh do something once for it to meet a bunch of requirements um and for you to be able to collect evidence easy right so if you know that like this requirement maps to control one two and three it's just an easy way for you to logically keep track of what's going on um so these are really important they're very often done very wrong they're often very confusing

and we'll we'll actually talk more about that and how to avoid that so you you um you're finished your policies you had this template and you said all right i have uh my policies now that was easy but now controls this sounds like a lot of effort this is really elaborate i have no idea how to start how do i do it and so um my general recommendation is go to something like the adobe control framework again it's free completely open source all of you can go and download it today um and it's essentially uh an easily customizable thing that maps to everything right so maps to fedramp taylor to sock2 pci iso and so rather than spending months

building out your own thing you can download this move it to a spreadsheet and have uh your own control framework you can even give it a fancy name and say like this is this is you know my org control framework um which it's great internal marketing so what does that look like um so uh this is the pdf version and i source this down below with the link but essentially it breaks everything down into control families it tells you all of the things that you need to do for any particular framework and so it's really easy it's a single pane of glass to see what are the things that you do that you need to do to meet these

requirements and it's it's great so you can go through and they have instructions for how you can you know customize this so like you change the organizations to like whatever your organization is um and then you can filter by um the different frameworks so if you don't need iso you just want soft too you can just filter everything else out so it's really really handy easy to work with so um how do you actually work with this stuff though i get this question a lot does it need to be in like a fancy grc tool that you're paying 10 000 a month for does it like is there anything particularly have to do an answer is absolutely not you can just

move all of this into a spreadsheet i personally prefer markdown files because i prefer markdown files but you can put them wherever you want copy and paste into a spreadsheet that's totally fine um and then like i said you just go through it and and the actual mechanical things you do to get this set up is filter out any framework uh any frameworks you don't need and if there's something that clearly just doesn't apply to you don't make the case to include it just remove it so if you're a cloud native company and you're using aws or whatever clearly you don't need to have physical access controls for your data center because you don't have them

you know what you tell auditors come on a time yeah we rely on them here here's you know there's the they have their soft to report and let's inherit those controls um and that's it um and then just follow their instructions to set it up so you can do all of this probably within a week a month if you want to be really elaborate with it so now that you have sort of that logical framework set up uh it's time for the gap assessment so if you open any like security compliance job listing everyone is all about the gap assessment um and this is the really important part now that you've kind of logically figured out

um some of this stuff you actually have to um see what's in practice you need to see what you're doing and whether it's what you need to do so in general people people make a big fuss about gap assessments but i i think it's it it doesn't need to be that complicated so i like to break gap assessments into three parts and i know there's some disagreement in the industry about this but um for the very first part and it looks like my numbering is completely wrong but they're all number one because they're all equally important um is that each framework requirement you have to make sure that the controls that map back to it actually meet the

requirement and what happens is um often times these control frameworks will be really broad um and these companies that make it will have this stuff in their policy and it might if you're using the control as a basis for you know deciding what you need to do you need to make sure that they address everything in the requirement and then the second part is part two is you need to compare all those controls once you know they meet the requirement but it's so important you need to know that the controls you're working with actually meet the requirement because this will bite you later i've seen it so many times you need to do that first part but after

you've done it you kind of run through your policies and make sure that there's like one sentence per control saying we we do this thing or you know like the general theme of what's going on and then the third part is you have to go through each control now that you've established the um validity of your control framework you have to ask yourself do we actually do that thing so um let's let's walk through this first part really quick um making sure that the controls actually meet the requirement again this part is so important it's gonna if you do this this is gonna save so much effort down the road so here we have fun requirement 3.1

and it maps to exciting controls one two three and what you're going to do is you're going to read fun requirement 3.1 and this might be soft to or iso and then you're going to say all right exciting control 1 says to do this thing that meets this part of the requirement you'll do the same for exciting control two and three and and that's it right that that's the entire process you'll then go through this and you'll do this for every requirement um and and uh whenever there's a gap you'll note it maybe you'll fix it um and uh it really is that simple you can do it in a spreadsheet you can do it in a google doc totally up to you

so then the second part is um comparing your controls with the policies and and again this is really as simple as it sounds you have your exciting controls one two and three they're part of this exciting control family one and what happens is you're gonna read the policy and you're gonna make sure there's a policy answer to every one of these activities that you're eventually gonna say you do and so usually a sentence or two about controls one two three is enough but it really helps to keep it simple and then the third part of this is going through each control and asking yourself whether you actually do this and so this is a pain point

and mistake i see all the time is when you do gap assessments you kind of just use your head and then you say okay we do this and we don't do that and you don't document any of it and you don't test any of it so what happens is come audit time you find out oh we don't actually do this thing there's no documentation for that and if you've been like on an engineering team or you've gone through audit and then very last minute security compliance comes and says hey we need you to build out all this documentation and start doing this brand new process you have like three days please do it um this is why right so as you're doing

this testing the first question you always have to ask is is this even applicable and so we talked a little bit about that earlier um and then you know do you do you actually need to do it a lot of these controls won't be applicable to what you're doing um and it's a it's okay to scope some of these out you have to ask yourself is it actually documented is this written somewhere is it you know living in somebody's head are there defined slas roles responsibilities um and and who owns it somebody has to own this process document all of these things and ask all the right questions and do that for each of your controls

um the kind of the top level point there is anybody who goes through your gap assessment should know exactly what you saw and why you made your determination and so a persistent problem i see in the security compliance space is when you generate a work product like this you give it to anybody nobody has any idea what's going on and it's a huge liability for engineering teams that have to work with you because they have no idea how you came to this conclusion and it's a liability for the rest of the security and compliance team because they have no idea how you came to this conclusion so every single thing that you sample every policy that you make a

determination on you have to document that and this can be in a spreadsheet google doc markdown file whatever those are details that don't really matter um and so you will have gaps i mean if you're coming in and there's nothing you will have gaps and the where a program becomes useful or not is what you do with those gaps so i want to revisit this slide because this is so so important the second point that i've i've um bolted out um you know it's security compliance is essentially a nice way for you to get the things that you want and that you otherwise would do but that there isn't business justification for um and at this point when you have these gaps

this is literally the best time for you to go to your security teams go to your infrastructure teams go to all these people and say hey look um we now have an opportunity to build out some of these things that you want to do and and we have business support to do it but before you go to these control owners and you start talking about remediation again you need to go through those steps so what is absolutely required what needs to be done in a very specific way what doesn't is it flexible and if so how flexible is it what is the exact scope you're talking about and so a useful security compliance program uh will give people very specific bars

and and measurements and they'll know exactly how far they can go what is malleable and what isn't so you go to the control owner and you have this conversation i'm sure many of you have had if if you're on engineering or security or whatever and you've talked to um the grc folks that are getting ready for audit um and um you you know they they kind of give you this list of controls that need to be done and nobody really knows what's why it needs to be done that way or is this flexible is it or is it not um and so when you go to control owners as the practitioner again go through that list what's required

what's not how flexible exactly where's that bar and maybe there are like one or two people who have been in audit with me um on this on this um you know in this talk i'm always harping on this exactly where is the bar people need to know how much they can move how much creativity they can have um and ask the questions like is this something you know are you otherwise planning to do something that aligns with this and it you know these audit preps can be a resource magnet and then you can say okay you were planning on deploying this elaborate logging pipeline there wasn't enough business support this aligns with all of these things we need to do

let's do it let's make the business case for it um and then another question is you know is there a way to automate this um so it's so important to tell people here is what our end outcome is do you see a way instead of doing this manually to automate this or if maybe you're technical yourself you can propose your own automation solution i think probably the most important thing and and a huge mistake made in security compliance programs is that um you give them this immutable list um that uh you know is based off of things you've seen before and you say please deliver and you you you know you say just add it to your

sprint and get it done but the bottom line is you have to let the smes be smes if they don't know what you're doing and where the bar is and um and they if they don't know where the bar is and and what you're trying to do then even with that immutable list they can't get you exactly what you want and so the better solution is tell them exactly where the bar is and then let them be the smes for their own systems and their own development and so there are gaps too with with the things you do right so these are the processes that you do you have risk management vendor reviews access reviews all of

that stuff and so these are an important group of gaps that are really can be a pain for teams so the point the first point is that absolutely nobody likes security theater absolutely everybody can sense it i'm sure many of you um you know uh who are here today or watching this video later um have seen it um everybody can sense it absolutely everybody can sense it and so um you have to be very very cautious to play along with it you know it's never your mission to defend bad requirements or outdated frameworks and i see this time and time again you don't need to justify what you're doing with this is the basics of security

sometimes it's a bad requirement and it makes no sense and it's totally legitimate for you to say i totally get it this is just one of the things they're asking for um and let's make it as painless as possible so the second point with with these these process gaps that you see is um filling the void with jargon in words and so this kind of goes back to the policies and the controls and how you wrote them and the solution to that is you know everything you do every process that you help build and implement doesn't need to sound like this superhero right um is simple and to the point is is always uh more effective than not

so you know one example for risk assessments for is um you know your process for doing a risk assessment is you open a google doc you follow the mozilla rapid risk assessment um process and then you create a ticket in jira for tracking remediation um but what happens often is you copy and paste you know like the quarter of nist 830 which is the risk management framework and then you have a 20 page process doc describing how you create a google doc and then create a jira ticket and so keep everything really simple avoid filling the words with jargon it really only hurts understanding of what you're doing and why and it hurts your documentation in the

long run the third point is um you know you have to be security compliance is an advisory role at the end of the day um we some programs will try to mandate things very rigidly when it's absolutely not necessary and so the solution for that is look if you have an exceptions process just use it right um you you have this way out and when things aren't going well or maybe something doesn't make sense just just use your exceptions process um and you'll you'll have situations where um things will get in the way maybe one of your change controls doesn't work because um you know there's no reviewer for a pull request of you know a non-critical repo because the

engineer lives in a different time zone and you know you can policy your way out of these things but a lot of teams don't do it and so a useful security compliance program will give people this exit hatch and a way to get around some of these problems while still meeting the requirements and and um going through audit just fine um and you also have to let people make their own decisions um and and let people own any risks that they do take with maybe your audit report gets tainted um at one point you you have to not make it your mission to make everything perfect give people the the autonomy to make their own decisions and

you know if it doesn't apply or make sense use your exceptions process and you can always do a risk assessment saying um hey look um you know this this is very low risk for the company uh the the fourth point on this is you need to know your your uh how your org size and maturity and the solution to that is um if you're a 500 person company you don't need this massive enterprise risk management thing that nobody understands or can work with right so you're trying to solve problems and build direction for other teams that is commiserate with the current size and level of maturity of the org right and so you have to

crawl first and then you walk and then you run but also when you start running if you're running with a weighted vest on in the middle of summer it's very very hard to do and there are often times when you don't need to have that vest on and maybe you can run your marathon in the winter right so take all of that excess baggage away and make it easier for people to work with the program and and get things done and then the fifth point on this is uh you have to automate everything a useful security compliance program is one that gets out of the way and um makes reduces friction as much as possible so

that people have to think about compliance as little as possible and they have to invest as little time as possible into the the activities you have to do for compliance so access reviews can largely be automated if you know if you have your role based access controls defined and you meet with somebody and say hey what's the process you're using for you know doing these things manually you can absolutely automate it same thing with risk tracking you know you don't need to manually go through gear tickets and have people manually go through gear tickets you can just write a bot that checks to see if the slas are being met same thing with control testing and

auto and audit evidence collection and and the larger point here is you need to partner with your security teams engineers um tell them exactly what the goal is for any given control and automate it um ask you ask them to automate it for you get their suggestions on how it could possibly done or if you can do it yourself and all of this to say is that you need a lot more self-serve content you need a lot less friction in your program and everything you do should be about the convenience of your org and i think if you keep those goals in mind uh it makes it easier for people to work with you it makes the solutions that you

implement a lot better and it helps you scale over time and that should always be your goal how can i make this easier for you know person a team b etc and so you've gone through this process um you've you've got you've created your policies you've created your controls uh you've gone through this gap assessment and and you've identified all these pain points you've avoided them you've implemented the remediations you have the next part of this is uh are our audits um so let's let's kind of walk through that a little bit because this is a this is a point that that gets missed quite often i think so picking an audit firm is super

important um it's one of those things where you you really do need to meet with quite a few different auditing firms and you need to interview them and ask them really good questions you need to figure out what kind of clients are they working with and do they have experience doing the things or auditing the kinds of environments that you are and so an example i like to use is let's say you're working with an auditing firm who's only ever audited or mostly audits uh people with their own data centers and like these really elaborate on-prem deployments and they focus on those controls and they're really good at that that's totally fine but if you're cloud

native and you have like continuous deployment stuff like that it's going to be really hard to explain to them what you're doing and how this is a huge problem especially because these frameworks um regulatory and not regulatory are often outdated by 5 10 sometimes 15 years so meet with them and ask questions like what kind of controls would you anticipate to see you know if we're deploying after every change to master and if they have no idea what you're talking about things will only get harder from there so you really need to interview the auditing firm um and and find the best fit another point i'd make is that you have to pick a firm based on uh the

size of your company so what often happens is people will want one of the big four um and it can be really really challenging for small orgs because the bar that they set can be a lot higher because they're used to seeing a lot more elaborate enterprise-y type stuff um but it can also be extremely expensive so it can be hard to get advice it can be hard to meet the threshold that that particular auditor has um and and they also come in with their own experiences and biases and and have very strong preferences on how things are done and and you have to ask yourself do customers really care who it is i mean for folks

who are doing actually doing the vendor risk reviews i mean how many times do you really see that it's not one of the big fours and you say wow this is so disqualifying most of the time you know the vendor review process is you get a soft tube report and you scroll down to that table with exceptions maybe you read section three a little bit to see what the controls are and and you call it a day and so you really have to focus on finding somebody who can work well with you and who can help you through the process but also somebody who understands um what's going on with other companies who do similar things

so they can give you advice that's relevant to you and then audit periods probably the least exciting thing we're talking about today but just for the sake of completeness if anyone references this talk um later on uh everything does not need to be a one-year audit period even for sock two um which is the most popular you can have a three to six month window even for a sock two type two um and so just be aware that you don't need to take your organization through this massive like two-year ordeal to get your audit report um you can start small and build up if you have the budget for it um then you can absolutely do a shorter

window i thought that was just a finer point that uh needed to be made um and so for getting ready for the audit the audit prep and doing the audit um you need to communicate with everybody very very early on you need to let them know what you're doing what they should have to expect and tell them essentially um you know we're gonna spend like two weeks collecting evidence we're going to spend you know large amounts of time talking to the auditors there's going to be a lot of back and forth if you let them people know a week ahead of time there's this constant scramble this constant rush and it's very very unpleasant for everyone so just keep

that in mind um and then i like to meet with everyone four weeks ahead of time really think about this um you know ahead of time get ahead of it for i like to do four weeks you can do it even earlier than that um and then i like to leave at least two weeks for evidence collection so i'm sure if you've been part of audit maybe not on the grc side um and you get a request saying hey we need um you know this massive listing of things and then we're gonna you know auditors will randomly pick from them it's a complete disaster so you need to get ahead of it give people at least two weeks and even

before then they should know it's it's um it's coming and to anticipate it um and and be specific with everything you do if you copy and paste um the requests from the auditing firm nobody will have any clue what you're talking about nobody except you really understands what they're asking for because you're the one who built the relationship you're the one who's worked with your controls the most and so be as specific as you can say i need a screenshot with your time tray down of this specific dashboard get to that level of granularity and also make sure everyone knows what to expect for walkthroughs let them know hey they're going to sample evidence that we submitted during

evidence collection here's a list of other things that will probably come up be ready to talk about some of the policies and walk through dashboards and stuff like that and i i think the top-level point here is for you it's it's just another day um you've gone through this process many many times or maybe you've you're doing this for the first time but you've been very close to it for a very long time for other folks it can be very high anxiety so be very empathetic and just understand that you know the engineering product all these other teams i t are also doing their work on top of all of this so plan as far ahead as you possibly can and and

have a high level of empathy because it really will go a long way and so life after audit so let's say you go through this audit process um and you wake up the next morning and you get your cup of coffee maybe it's a really nice pour over you got really nice beans from costa rica that's my preference you walk out and you see these trees in your backyard and the light is coming through the trees and it's really beautiful you kind of stretch a little bit and you say wow this is fantastic we're absolutely done now this this feels so great all the stress and anxiety is gone what do you do after that um the work doesn't stop there

right this is a continual process and it absolutely never ends as long as you have these requirements you need to maintain them you need to keep doing audits um and so i you know doing a retro is so important after every audit i like to do um invite everyone who is involved with audit for like a wider retro and then also do like team specific things if there was maybe um some struggles with a particular team and and have frame it as an open conversation where any and all feedback direct or otherwise um is is welcome and so you want to um outline what went well what didn't go so great and what could be improved um and

and be very honest ask folks for their most honest direct feedback get what they're actually thinking and then act on it write it down create a jira ticket out of it and start implementing some of these things right away because no matter how well you try to do or how well you think you do there's always room for improvement and and that little bit of effort to try to figure out how you could make it easier for all the other teams goes a very long way the next point is after your audit keep on automating so all that evidence you collected for the audit you know how can a bot do it next time right um

all those things that you need to keep monitoring for you know making sure that your slas are met making sure that pull requests are reviewed and approved you you can write a bot to do that and and so after your audit kind of figure out where were all the pain points what are some of the things we need to maintain um and and um you know make a list and start socializing it with people so if you can't do it yourself take that list take those ideas socialize it with teams frame it as hey look we know this stuff is really painful we know you don't want to be doing it but you know do you see any way that

maybe you could write some automation that will help you stay on top of this stuff um and if you can do it yourself even better um the next point is to just keep simplifying um you know everything can always be done better um and um you know processes can be improved uh they you know words can always be taken out and if we go back to you know one of the the first slides where we talked a little bit about you know the ultimate policy if somebody reads it and they actually know what's going on uh keep working towards that goal um and you know we we talked a lot about some of the things that you practically

can do to build out this program but the reality is we're all gonna miss the mark all the time and um you know figure out where you didn't do so well keep improving on it i mean you know i'm on program number five or six that i've built various you know sizes of of company i've you know being in roles where maybe i wasn't as technical and those were being technical and i always miss the mark um on something and that's totally normal we're all human and so keep simplifying everything keep working on all of those points and just have in mind that you know everyone you work with is a partner of yours and

your ultimate goal is to make things as simple and frictionless as possible for them um and then you know the third is you know the point can always come sooner um you know when you're when you're going through some of these exercises with like testing controls and writing automation um just keep in mind that you know having just the context and goal and end state in mind always helps and so kind of with that to the point of the point can always come sooner i guess we can open it up for some questions if there are any

trying to unmute myself uh i didn't make an announcement for questions up front and that was my my bad but um i didn't see any thus far i did make a comment in the uh the discord so we can give uh people a couple more moments and i can see if there's any questions that shake loose um if not thanks for the talk ah there is there is one question from uh scan scandra anan what determines whether independent auditors can start placing reliance on your testing of controls essentially trying to reduce the impact of multiple audits you can you see that question one more time or can you maybe copy and paste it into the question box here

just like i know uh i'm getting yeah let me see i might use your house if i can send it to you via chat send chat message actually i'll try it again because it's not working very well what determines whether independent auditors can start placing reliance on your testing of controls essentially trying to reduce the impact of multiple audits i think that for so statement so so i i think your your actual testing of controls doesn't matter so much uh as much as their testing of your controls so what ends up happening is like there are a portion of some frameworks well they'll see that are you doing some continuous monitoring activities um your own testing of your controls is

more for your own visibility so you know what's going on um and and you can make corrective action if there are any issues when they when auditors come in and they start testing your controls um they'll have their preference for how they do it um and you know i think before testing starts uh they'll obviously assess the the suitability of the design and operation of your control so i think it's it's more a question of um you know how do you is your process built in a way that's going to meet the requirement so it's designed correctly and is your control operating correctly and then your testing is just for your own internal visibility of if it's working

all right and there was a one more question from iron heat do you have any suggestions for getting business support for unsupported mandates for example management says get us compliant with 800-171 but you have little support from the sysadmins help desk or business and the executive that made the mandate gives no teeth behind it oh that's that's a really great question um so this this happens all the time i i'd say your best bet is um go back and you know go through this process of telling folks hey look you know i'm being honest i have 171 they want me to meet all these controls um you know there isn't much of a an appetite real appetite or bite behind

it or wide um and you know there is some support though so like let's walk through some of these things and are there things that you've wanted to do for a while can you tell me what some of those things are and maybe you can map some of those things back to um the requirements you need to meet um i i think if you give people a reason to start working on things they want to work on because of compliance that's absolutely perfect i think you have to loosen your standards a little bit at that point and say you know you probably won't get it perfect but just document um where any of the gaps are and

um go back to the executive and say hey we've been able to make progress on these things um but everything else it doesn't seem like people feel like there's enough support for this um or um you know it doesn't seem like um there's enough business interest for people to start dropping the things they're doing so i think that the main point is everyone all the sysadmins all the developers want to do things and so there's a really good chance that some of the things that they otherwise want to do fit into some of your requirements and sometimes you have to get creative look at what they're doing and see if maybe you can't show some

goodwill by saying okay this partially meets it but can we maybe like tweak this one setting and be specific so a problem i i see often is you know will you know security compliance teams will go to folks and say hey we need to meet this requirement please meet it um but if if you can give specific suggestions um like maybe enable this or disable that or you know like you know can this be done or maybe do it yourself maybe there's a way for you to you know get looped into that process um and to start implementing some of the changes itself um if you're not technical that might be an issue or if there's like

rigid like siloing between what people can do that might be an issue um but yeah i think that's the most you can do for a situation like that and just document everything so i come from the healthcare space everything gets documented all the time if it wasn't written down it didn't happen um if you have pushback or you can't get something done for some reason write down who you talk to write down what the conversation was and then when you get asked about it you can give it to the those that documentation to the business and say hey look you know you need to make a decision on what to do all right and there's uh one more

question from looks like aldrias what are the examples of things that cis admins and engineers have wanted to do that that they leveraged compliance to get done sorry about that so i i mean you can run the gamut on on things like um i'll use vulnerability management as an example um and maybe this isn't specific to justice admins but um one of the problems in security compliance is that vulnerability management has become synonymous with like just scanning everything and getting this massive list of things that nobody really knows what to do with and most of them are false positives um but you know oftentimes um there will want to be some more automation in place

for um you know deploying um infrastructure so maybe you can use an infrastructure deployment tool and then your vulnerable vulnerability management position can be hey look if you can get this infrastructure deployment automated um our vulnerability management can be um you know periodic reviews of like your terraform conflicts um and stuff like that so um you know other things might be that um you know segmented environments right not using test data stuff like that i think most uh sys admins don't want to be playing in production um using um production and so there might be a desire to move to maybe like a staging environment for better testing and maybe that's not in place and maybe that's a conversation

you can have with some of the technical teams to say hey look you've been wanting to do this thing you've been wanting to have segmented environments um you know let's let's make that happen we have a business case for it now um but you'd really have to pick like really specific things and um you know and sometimes it's not easy to say that um you know here are the specific things that uh you know a person might have everyone's organ structure is different everyone's environment is different um and sometimes it takes um you know you talking to a sis admin and saying hey what are some of the things you're doing what are some of the things that are in

your backlog and kind of mapping that then to your to your controls that you need to get

implemented