BSidesSF 2026 - Rehearsal is Over: Moving GRC Engineering from Theory into... (Branden Rosenlieb)

I'd like to introduce Brandon Rosen Lee. He is going to be telling us about the rehearsal is over. And what's the great thing about Brandon we have to uh tease him about is that one uh which I very much as a founder really respect is that you're the founder of Enclave Cyber Advisors, but he's also director of IT at the University of North Carolina. I'm really sorry about if anyone's watching that merch menus. Okay, that joke didn't turn out very well. But anyway, he has over 11 years of experience in security and what he is known for is actually bringing together um business goals and I'm sorry I didn't do that right. He's doing he what he's known for is bringing

maturity as in cyber maturity into organizations but also helping them meet their business goals. So everybody give a round hand give a round. Thank you. Okay, thank you. Um, yep. As uh as she mentioned, this is about uh moving GRC from theory into practice. Um, I will be moving pretty quickly through here just because of the time limit. Uh, there may be time for one or two questions at the end, but um, for sure I will be upstairs uh, out on the terrace after this immediately. Um, just so we're not logging up the halls or anything like that, but I would love to hear any questions or have any conversations with you guys after this. Um, and I do just

want to sort of manage expectations that this is not the advanced seminar. Um, so if you've been doing GRC engineering for a while now already, uh, you may think that some of this is a little bit repetitive, but just wanted to throw that out there for everyone. Uh, quick who am I? Um, as she mentioned, I'm security and technology director uh, with the University of North Carolina. Um, and I like to do advisory work with startups, especially those that are in the early stages of their GRC journeys or maybe in the midpoint. Um, sort of in those sort of higher impact uh parts of of moving along through GRC. Um, I have over a decade within infrastructure

security and GRC. Um, and I've worked across quite a few industries, especially those that experience more regulation, financial services, healthcare, government, those sorts of things. And so today, um, we're going to be doing a little bit of an overview, uh, just to put us all on the same page, even though I'm sure most of you here, uh, do have at least a basic familiarity with GRC engineering. We're going to do three very small, very quick, very basic examples. Um, and then a process loop after that, just to pull them all together. Um, mostly just to give everyone something a little more tangible and concrete to think about. Um, as we're talking about the concepts as well as, uh, that may inspire some

ideas for your organization. uh then we're going to talk yep again more about those concepts and then we'll do some takeaways and such and if there's time for questions of course we'll have that as well. So going straight into kind of what is the current state of uh governance risk and compliance organizations today of course are moving faster than they ever are. It's really difficult for manual processes to keep pace with those or to sufficiently scale. If you're an organization of course that has 25,000 50,000 employees across the globe you can kind of afford to throw people with the problem and that will work for a while not forever. Uh but most um small businesses, most startups uh can't

really can't really afford that approach or or it's just not convenient for them. Um and traditional GRC often favors static products um or tools or processes, things that kind of reach a certain stage or get established and they don't really change too much. And so we we kind of want to move past that a little bit. We're still kind of in the um era of various cyclical audits. uh kind of looking at what does our environment look like you know once per year and kind of that's what you end up with a audit report sometimes is what does my environment uh look like um you know every March or something like that or every April as opposed to sort of a

continuous thing and so that creates a lot of chaos during your audit periods um lots of stress for organization it can eat up a lot of engineering team bandwidth as well especially when it comes to explaining how things work gathering evidence trying to capture data flows those sorts of things um and again like I was just describing it's oftentimes very very point in times kind of a singular um snapshot as opposed to a more continuous picture. Um and then lastly, uh you know, we're currently in spreadsheet hell still with a lot of traditional GRC. Um kind of known around the office for making jokes about, you know, one more column will save us. We just add one more column, uh one more

sheet, um one more tab, we'll be great. Uh but they're tedious. They're manual. If you have a lot of people working on them, you have version control issues. So that's just not a lot of fun. So then let's talk about shifting away from that. Um so our goal is to move away from that process based or that audit uh cycle thinking into something that's more akin to a product organization or something that engineers would try to think about what does that mean? Uh means that we want to look more at like an iterative system design. Um so as opposed to making those processes or auditing a product and then kind of hoping it stays the same for a very long

time. Um going into it with more of that iterative thinking that things will change and that we're going to continuously improve. Uh related to that, dynamically updating requirements. The audit cycle every now and then kind of worked because a lot of times, especially if you're only with one framework or or one set of audit requirements, they're probably only updating once a year, once every few years. Um but those are becoming more frequent and we're also seeing more organizations that are doing a sort of cross framework. Um they're needing to comply with multiple things at the same time and so obviously those obviously uh excuse me, they don't normally come in, they don't update themselves at the same

time. So being able to do that dynamically um removes a lot of the TDM. Uh and then also it refers to kind of continuously refreshing our artifact repos. Um again we have a lot of stress right now in the audit cycle where when the audit is coming due uh we're kind of in a mad rush to uh collect a bunch of evidence all at once. Again that's very point in time and that's also eating up a lot of your engineer developer time etc. Um and so we want to try to get away from that. And then we want to look at some feedback loops which means a couple things. one you make a change in

one place and it applies to multiple places or if you update your requirements in one place it it spreads in different places. Um and it also means that things kind of feed into one another so you don't have processes so isolated but each process helps out the next one. A few more things about just kind of doing that shift to GRC engineering. Uh thinking about who are your customers. Traditionally in GRC we think about auditors as our main customers. Uh but there's a little more to it than that with when we're thinking about GRC engineering. We'll cover that a little bit more in some later slides. Um, we also want to think more about automating

early and often. That again goes back to that kind of systems design thinking, being more iterative. And then connecting GRC wins to organizational metrics. Um, and this deals a lot with removing the idea that GRC is more of a blocker and trying to turn it more into an enabler. Just some quick examples of that would be with our typical KRIS, like how many controls you're passing and failing, meantime to remediate controls that are failing. uh hopefully you're not at the point where you're getting fined, but turning those fines down or lessening them if you are. Um and then some other productivity metrics that can play in um include sales enablement and go to market timings. Those two especially I want to

call out because nowadays um GRC is imperative to uh getting sales and to getting clients. Um clients are always asking for of course uh from thirdparty risk perspectives, they're asking for your sock two reports, they're asking for your certifications um and they will walk away if you don't have it or if you're not even publishing that you have those things. uh they may be they're not even picking up the phone to call you to begin with. So um definitely important for for pulling in customers and retaining them. So we're going to dive into a couple of those many examples. Now uh again they're quite simple. Um they're going to be very quick. Um this first one uh is probably a pretty basic

one that maybe a lot of you have already seen. Um but I just want to clarify that all three of the examples, you know, multiple ways to skin a cat. All three of them have other open source alternatives. All three of them have commercial alternatives. Um, so there's a lot of different ways to approach this. Um, but anyway, so this first one, um, again is is a little bit more on the basic side, but I felt it was still worth including because it's a great entry point, um, for people that are newer to GRC engineering, um, and and indeed people who are maybe less technical in general. And this one's called the AWS uh, audit playbook that

someone I've worked with a little bit named AJ Den uh, put out. Um, and it is a Python uh, project um, that works with gathering evidence from AWS environments. Um it uses the boto3 library which some of you may have heard of again. Um and there are similar libraries that exist for GCP and Azure and you can use that to collect a lot of evidence in an automated fashion and save it to JSON uh from AWS and that includes a lot of the common things like um AWS services configurations like S3 um RDS etc. AM of course which we're always interested in and GRC cloud trail and so forth. And so just a few um

snippets from that um is what that might look like from a more coding perspective. Um at the top there, we're just instantiating that boto3 client. Uh we're listing out all the buckets and we're saving that off to JSON. A little bit lower down there. Um we're gathering the uh encryption setting encryption configuration for each of those buckets and saving that out as well. And see one picture getting taken. That's okay. And then uh one more little snippet um is also gathering the uh uh public flag setting for those buckets. So whether those public buckets are exposed to the public or not and then hopefully that's somewhat visible. Um but these are just some sample JSON outputs. Um the one on

the left there you see is is the listing out of the buckets that happened at the top of the last slide. Uh the middle one is the kind of encryption that's being used on the bucket. Um and then the last one is showing true or false for whether or not those uh public uh flags are enabled or disabled um on the buckets. So that's the first one. Again, that's really just an automation of an existing process. It's not really anything novel on its own, but it will feed into our um larger loop that I'm going to show at the end of the examples there. Um and so then we'll move on to uh the second open

source example um which is open policy agent. Uh open policy agent is a much larger project. Uh some of the key or the core components are probably the open policy agent itself as well as uh the one there called gatekeeper. It's especially great if you're trying to do a lot of auditing with Kubernetes and things like that. But as the name implies, it is an open source policy engine whereby you write policies in kind of their own form of I think it's really close to YAML if I'm recalling correctly called Rogo. Um, and you can, if you work hard enough, you can integrate it almost your entire tech stack. It works across tons of applications, APIs. Um, our example is

going to use Terraform in just a second. Uh, but it fits in just about anywhere. and it uh excuse me uh creates really comprehensive audit trails of course puts everything into JSON that's going to be your recurring theme if you haven't picked up on already uh already um the use of JSON uh and what input was given as logged what policy uh it was checked against and what was the agent's decision pass or fail um for that policy excuse me so um now we're just kind of a really quick really simple example with Terraform uh let's say that you ran generate where you uh automatically generated some Terraform code based on your AWS environment. Um and it went

ahead and included your uh password policy uh in the Terraform HCL that exists in your AM organization and someone thought for some reason whether they knew you had it somewhere else, they just didn't think it was important, they're doing something malicious, whatever, they just thought that they were going to toss that out and so then they remove it and they go ahead and do their uh build out and push. And of course, as you go along the typical buildout process for the deployment with Terraform, you do your initialization, you do your plan, and then there's one little extra step here that's added that you may not normally be doing, which is essentially converting your uh TF plan

into JSON as well. Um, for open source, excuse me, for open policy agent, for OPA, uh, it does need to be in JSON for it to ingest it. And then the bottom section there is a snippet of code that's actually doing a lot of the analysis. So uh one of the things that OPA is doing um if you code the policy to do so of course uh is that it is assigning weights and scores to each of the changes with the thinking being that of course um more routine or more minor changes with smaller impact would have a lower risk score and things that are deleting things or just making lots of changes a TF plan that makes a

lots of change will have a higher risk score and then it compares that to a risk tolerance that you define as well and so it can pass or fail based on that. But right below that, what we're also doing in this particular one is saying that regardless of the risk score or regardless of the risk tolerance, anything that touches AM, we're automatically going to fail because we're going to consider that to be particularly sensitive. And so that's what we have here with the removal of that uh password policy in that HCL. So then the next step from there now that we understand that is to actually run the open policy agent execution u uh command. Um, and we're running it

against the LC that we just saw, uh, as well as the TFplan.json that we exported earlier. And after it goes through that, it notices, of course, that we did change something related to AM. And we see the JSON output that shows that it's false, meaning that it failed that policy. Excuse me. And um just just for you know reference again these were simple examples for uh for the sake of time but I also like to point out that OPA in particular you can get extremely granular extremely fine-tuned with uh you could take this further and say which user did the the the code change in Terraform uh even how old is their account. Maybe if you're of

the mind that a newer account is more dangerous or more likely to be an insider threat than someone who's been there for three or four years. um it can check all sorts of things and that's just one example within Terraform of course but it can get super super fine-tuned. And then the last um open source example uh before we get to the the larger process flow um is going to be an a AI coding GRC plugin. Um and this is made by a guy named Mario Lenado. Um and then he just published it you know out to GitHub for his his own valition. Um but it is an open source coding agent plugin and it supports both cloud code and open

code. Um and I do want to clarify here as well that um you don't have to be a programmer or a coder to use it. Um, if you have clawed code or open code set up uh such that uh you have access to the codebase, of course, it will use that contextually um as you're working with it, but it's not necessary. You can just put it in a completely blank open code um uh environment and still ask it questions and and still get some really great outputs. Um it has over 72 files that it references that cover 15 frameworks. Of course, all the big ones um NIST, SOCK 2, GDPR, etc. And in addition to just looking at code or just

answering simple questions, um it does do some of these other things that I found really well when I was testing it out. Um document reviews. If you're in the Fed ramp world and you have to do system security plans, uh it's great at that. Um generates even tabletop exercises and and quite a few other things. And so kind of the the thinking I think that um um the person had when they were writing this was that it would kind of create this virtual GRC analyst. Um and so this is one example. um kind of continuing on from if we imagined that uh we we saw that failure for that policy for that Terraform code in the

last example um and we wanted to to take further action on that um there's a couple different ways you can act uh interact with this um virtual GRC analyst uh and one of those is with slash commands so there's a handful of slash commands built into it um and that's what this one uses here first which is a /grc control lookup we give it the framework in our hypothetical here we're using 2701 um and then the last part there you can either put in the control number directly if you remember it or if you know it all stop your head. Uh but in this case we actually did just a keyword search for password policy and uh you

can see that it returned that policy and some some highle information about it. It also then continued on to give us some implementation requirements as well um as well as related controls and evidence artifacts. Um and this is all just generated off of that one command. And we can see uh for our specific use case here that the password complexity documentation may be an issue because that's what we're going to end up removing. Um and so this is like a if you get that you know alert that something failed. This is a great way to get a refresher on that control before you take further action. And then we're going to keep working with this agent. We're going to do a

more conversational question next. Uh we're going to get kind of more specific with what happened in our case and we're going to say a new Terraform pool request removed that policy or excuse me that resource uh which holds the password policy. Does this create any issues? We get a pretty straightforward answer which is great that yes removing that would create a gap a gap with that same control that it just told us about and it also goes on to give us uh two options that we can do moving forward. Uh it tells us we can either block it or accept the risk. It does make a note though that if we accept that risk that

that would then uh cause an issue with our 27,01 certification and then it makes a recommendation that we update the PR before moving on. And then lastly, kind of in our hypothetical like I mentioned before a lot of organizations are trying to work with multiple frameworks now. Um so we're going to pretend that our organization is also working towards fed rampant moderate and we ask it if it has any uh thoughts on that as well. Um that is another observation that I made with this particular open source tool. Um that it did seem to do sort of crosswalking really really well. And uh it tells us that yes this would also create an issue with federant moderate

with IE5 and IIE51. Um and then it uh gives us some more specific information about why it would cause an issue. Uh and it reminds us that it would violate both the ISO control and the relevant Fed RAM moderate control. So then if we all put this together, reminder this is a security conference, not a diagramm conference. Um so this might not be the most aesthetically pleasing but conceptually speaking if we try to throw all this together. Uh we've uh we opened our new PR that removed our new pull request that removed that password policy. Uh we saw open uh policy agent fail that because of the interaction with the IM. Um, from there we could then trigger our AWS script to

run automatically to go ahead and see what our current configuration is so that we can get a better idea of what it's trying to change. And then we can feed that directly into our open code GRC quote unquote virtual analyst. Uh, that would then review the failure against the org's preferred framework. So we can instruct that, you know, to always check that against 27,0001. And now that we've already got all of this information compiled and all these steps have kind of fed into each other, um, we can package that up. we can throw it in linear or a jer ticket or something of that case. And then that's the point where a human would get

involved and start reviewing it. From there, the human would look at the uh open code GRC plugin and uh look at its recommendation to remove the AM change. Okay, we're going to go ahead and do that. Rest of the PR looks good. it gets approved and then we're going to kind of loop back on oursel partially and we're going to run our AWS script again so that we can have a confirmation that nothing changed with our password policy after that deployment finished with that new PR. And so what we've done with this whole cycle here um for one thing we've had uh previously disparit processes that are now feeding into each other. Most of it's automatic. Um

there's only a couple places where a human needs to get involved here. We've also generated some more um of our continuous evidence. I mentioned the continuous part earlier and I'll probably mention it again towards the end. Um, but we're not waiting till just one point in the year or one point in our audit cycle to grab evidence. We've got a couple more instances of it here now. And we've just generally created some really good accountability um and a nice paper trail um that our processes are working and that they're executing the way that we want them to be. Okay. So now with some of those examples and such in mind um if we go back into our

our concepts and thinking about those tools. So talking again about systems design thinking. Remember, as you're as you're planning and as things are getting built out in your organization, keep in mind those uh automation opportunities, um the future scaling, the future iterations that you can do, try to get away a little bit from that traditional GRC thinking of just putting something into place once and then we're not going to touch it for a really long time. Um and so, of course, a great place to start is is with the easy stuff, and that always makes sense, you know, when we're learning reading comprehension. Um in grade school, you know, we're talking about right there answers, things that you can put your

finger on. Um and so of course those are great places to get started with your GRC engineering journey as well. Um and those can be some basic things like is encryption at rest used is logging implemented so on. And then we also just want to keep in mind that our GRC engineering approach requires more of a DevOps uh type uh mentality as opposed to a waterfall one. Um and so things like evidence collections or policy engines may not work perfectly the first time. Um I had an instance with that first example I gave you with uh collecting information from AWS that uh an environment that we wanted to run against um had federated identity enabled. Um and we had not

encountered that before. And so um that was something that simply did not present itself until we actually tried it and we saw it fail and then we knew how to fix it. Um, and so planning things perfectly the first time, which we might try to be doing with our traditional GRC, um, is is not always going to reveal all the problems and it may not may not just result in as quick process, um, and as quick improvements as you could otherwise. So, I mentioned aligning with your customers earlier in the presentation. So, let's go back to that for just a moment. um instead of just looking at auditors um and only kind of focusing on

auditors is a lot of times what leads to GRC being viewed as more of a drag or more of a blocker um we can also consider developers, engineers, infrastructure, project managers and all those folks uh as our as our customers as well. Um and that's again what really helps uh turn GRC engineering into more of an enabler. Um, and just a quick little tip I wanted to add in here, too, is um, there's no need to repeat a lot of those steps for each of those different customers. Um, some of your more general agents or your desktop AI agents are great at at kind of doing little tweaks for your reporting and things like that uh, to to meet those

different customers uh, particular requirements as well as maybe to present things to your leadership uh, teams and those sorts of things. But uh, overall the goal with this uh, and with aligning with these different teams is to reduce friction. Um, you want to reduce interruptions particularly for things like evidence gathering or trying to understand data flows or do again doing all of those things that we normally see during the very chaotic, you know, couple months around our our audit period. Um, while also being careful to not simply throw tools at the problem. Of course, I believe that some version of the three things that I showed today are probably helpful to most folks. Uh, but make sure that of course you see a

problem that that tool can actually address before you try to try to put it into place. And then just a few um examples of some quick wins that you can use while you're trying to build up some support for your GRC engineering at your organization um include things like uh automated user access reviews, those configuration checks that we talked about, and then also feeding data into trust centers. A lot of organizations now of course have a commercial compliance platform that includes something like a trust center and that does a really good job of supporting some of that sales enablement and and creating trust with your clients uh that we talked about earlier. Um, and what's

great about that too is again since a lot of these tools run off of JSON, they're very interoperable. A lot of the trust centers coincidentally also uh do a pretty good job of reading in JSON and those sorts of things. So you can build up your build up your um compliance uh posture uh within that using using some of these tools. Um I'd also say not to not abandoning your auditors, but not don't necessarily weigh on them. Um, so start now. Even if your auditors aren't ready, even if they aren't automatically accepting JSON at this point, of course, some of them still want things done in their own workpapers and their own reports and that sort of thing. Um, and that's okay.

You can still set a lot of the stuff into place now and use it as an investment for the future. Um, and it can still use it can still make things simpler for you today while adding in a stop gap for those auditors that say still want something in a spreadsheet or in a PDF report. Um, a lot of the AI agents now of course are really good at turning some of that JSON into some other formats as well for you. Um, and so you can do that as well so that when they are ready to finally start accepting JSON and those sorts of things, it's just it's actually removing steps from the process as opposed to

needing to build things out in the future. Um, and one example as well um, on a bigger scale is uh, within the NIST Federramp 20x process. If any of you are involved in that, of course, um you're probably have at least heard some rumors about that, but essentially the goal for for that initiative is to automate about 80% of Fed Ramp. Um and of course, it's not quite ready yet, but you can be ready uh when they are. You don't need to you don't need to get the okay from them first. So, some of our takeaways here. Um so, we talked about the shift between the traditional GRC and and GRC engineering. Um it is necessary to keep pace with

speed and scale um and to achieve continuous readiness. Um those uh continuous pieces are really important. That's why I bolded that because the continuous evidence collection, the continuous analysis, continuously um comparing things and analyzing it against your policies is what uh kind of differentiates yourself between checkbox uh compliance and more of a actual impact on like your real world security within your organization. Um strong adoption of course is uh important to to get ourselves towards 100% automation. It probably won't happen. Um but um certainly certainly a goal that we can work towards. Uh the tools that we went over today uh was our AWS audit playbook. So Python and Boto 3. Uh we talked about the open policy agent and

the coding agent analyst as well. Um and largely the goals of each of those were to improve automation to try to reframe our GRC approach and to augment uh perhaps commercial tooling that we already have in place. And keeping in mind our our impact that we're aiming for is uh to make sure that GRC is viewed more as a value ad and a business enabler even a sales enabler uh to some extent um that contributes directly to your organization's bottom line which in turn will help you build out your teams better get more support within the organization and those sorts of things. Okay. And we actually do have time for a couple of questions. So that's great.

There's my contact information as well and uh and some information about the u any questions and then if you will let me get the mic to you that would be awesome. Here we go.

>> Hey Brandon thank you for the presentation. Um what I was missing a little bit on the part where you showed the the life cycle basically in there. Um I think if you have a if you have an organization that also has something like an already existing risk management framework >> where you have definitions of risk appetite and what you would allow and what you would not allow. This could also be completely then automated by an agent that is basically calculating how high would that risk of stripping away the password policy be >> and then basically by itself applying to rule that out in the PR. Absolutely. Yeah. And that is um that is definitely something that you can build

out and the example I gave with open policy agent. Again, there's probably other tools that can do that. Um but that is certainly something that you can do where you're defining um those weights based off of an existing risk management framework. Um and then defining your uh tolerance, maybe you could even make that a little bit dynamic as part of your framework changes. Um and it would also be doing that as well regardless of if you're touching IM or not. But yeah, that that's exactly the goal of that function within OPA is to say that smaller, less impactful changes or more routine changes um will be very unlikely to require human intervention and can auto

kind of approve themselves. Um but absolutely great point. >> Any other questions? Oh, got one over here.

>> Thank you. So what would you say that are your key um steps to now to implement AI agent audits? Um what will be a best way or the pipeline that you will suggest now that we I mean we're changing from doing it the old way, you know, with regular people now with AI agents. >> Yeah, it's a great question. Um, of course you can start out sooner on with with some of the more like I was um alluding to kind of the right there stuff and the evidence collection and those sorts of pieces that can go ahead and bring a lot of that stuff together. um with for example the uh the virtual GRC analyst that I mentioned of course

it has really good understanding of the uh frameworks and it does a really good job with structures of questions and requests and so of course it can probably do a better job than previous automations of actually going through those pieces of evidence that you've collected as well as policies guidelines standards written documents and extracting a lot of that information out to go ahead and answer some of those questions or to try to point to resources that will satisfy your controls. Um, and so it can go ahead and do a lot of that mapping for you. Is it at the place where it can 100% take care of your audit? No, I don't think so. Um,

and and definitely things are worth checking over if if for no other reason than to to catch hallucinations and that sort of thing. Um, but I think a lot of the manual reading through documentation, copying information over where it's relevant, seeing where it actually links to your framework or multiple frameworks if your organization follows multiple ones. Um, that's where a lot of the TDM I think can already be automated away in a lot of the sort of busy work. >> Thank you so much. >> Yeah. >> Can we squeeze in one more? >> See if I can get down here. Sorry about that. Thank you. >> Under quick wins to free up tech teams. I saw automated user access reviews. Do

you have a specific example of how you've applied GRC engineering to automate these access reviews? >> Yes. So a lot of that would relate um to uh how especially during onboarding processes, offboarding processes. Um I will also say provisioning access just in general when someone uh maybe moves teams or starts a new project. Um and they are added to new groups and stuff. It kind of relies a little bit on having you know role-based access control and those things in place as well. Um but does it make sense for you know someone um in the HR team to be added to a new project uh a new group that's been created for an engineering project?

maybe not right. So, some of those things that can catch out that are really obvious. Um, again with the onboarding and the offboarding, knowing what role they're in or what position they're in and going ahead and conducting that. And then also, um, if your framework requires, let's say, quarterly or by annual access reviews or something like that. If nothing else, it can do a really good job of programmatically pointing out to you what has changed. So that then you can much more quickly take a look as opposed to manually trying to look for this is the list from last year, this is list from this year and going through it one by one. All right, folks. Let's give Brandon a

big hand.