Lloyd Evans, Head of Cybersecurity at Rise8, frames AI and compliance as two sphinxes guarding the path forward, then asks Charles Nwatu, former head of GRC engineering at Netflix, and Mario Lunato, field CISO at Knox, what has changed on the ground. They cover AI-driven vulnerability discovery and the capacity it demands of engineering teams, mapping engineering work to controls and writing findings as product requirements, and an automated continuous ATO effort Lloyd and Mario worked on at a large civilian agency. They describe GRC engineering as a multidisciplinary role that pairs automation with systems thinking, and treat compliance as an enabling outcome for the mission. They close on regulation, with FedRAMP 20x condensing NIST 800-53 into roughly 90 key security indicators.

Lloyd Evans:

Hello. Can you hear me? All right. At a 5:00 PM, I'm very, very excited to talk about compliance. With the speed and development and pace that you've probably heard up until this point, all of the things like harness engineering, pace of AI development, you'll very quickly find yourselves into the field of compliance and authorizations and ATOs and all the compliance goodness that exists on both the federal side and the commercial side. I'm very, very excited to have Charles and Mario here to talk about kind of both ends of the spectrum and specifically to avoid the grave of the 87% of failed projects that was mentioned earlier today. So the challenge with following up so many heavy hitters is finding a fact about natural history that hasn't already been covered. So to set the table real quick, I want to kind of go over. So you may know that there are some buildings here in Nashville that have Egyptian architecture, but what you may not know is that one of those lesser known buildings is actually the grave of one of the founding engineers and entrepreneurs of Nashville, a major Eugene C. Lewis, a major is actually honorary. I'm not quite sure what the history is there. And in front of that grave, there are two sphinxes. And if you know your sphinx lore, the sphinx asks a riddle or a question and if you answer correctly, you're able to pass. And if you don't, you meet your end at the front of the sphinx there. And I think it's a very apt description where we have kind of two sphinxes coalescing at this moment. One is AI in terms of our uncharted unknown. We're figuring this out. There's a lot of unknowns, a lot of collective learning, but the second sphinx is a very old one, which is compliance. And I would like to tee that up to our first question here, which is talking about the last seven months roughly since Opus 4.7 released and we've really started harnessing these frontier models capabilities, how are you seeing on the ground of how we're able to approach compliance differently, specifically some wins that you're seeing in the field and strides that we're able to make?

Mario Lunato:

So for me personally, the biggest takeaway in the field and the place I sit in is a lot of the vulnerability and continuous monitoring aspects have begun to change. As Chris mentioned previously before us, AI is attacking our systems at unprecedented rates and finding vulnerabilities that we haven't found before. Example being there was a bug that sat unnoticed for 27 years in open BSD until Mythos attacked it and found it. So what has happened with that change is CISA and now FedRAMP as well has moved to a more realistic and deterministic process for vulnerability management and patching that has really brought on by the attack vectors. Another example being when OpenAI attacked hugging face and things like that. So it strung together a couple medium findings or moderate findings to then attack hugging face. So really put into perspective of critical and high isn't really what you're supposed to be looking at. You need to enrich those things with EPSS scoring. Is it on the KEV list? Is it automatable? Is the asset actually publicly exposed? And so what CISA and FedRAMP has moved to is categorizing findings in four different categories of is the asset publicly exposed? Is the finding on the KEV list? Is it automatable to be attacked? And how much control does somebody get from that attack vector? And it's really starting to reshape how we're looking at continuous monitoring, which then rolls into the compliance aspect of now your compliance team has to monitor these things and do their GRC internal practices around the changes that are happening with continuous monitoring that's all vectoring and stemming from the attacks that AI is able to do.

Charles Nwatu:

I would say one thing that I think has been interesting about the whole move with the methods and everything else with regards to vulnerability management is the ability to actually prioritize the findings, giving engineering teams and your IT shops a more detailed list as to what to focus on. And I think there's an opportunity to also blend some of that work with some of the cyber risk quantifications. So how do you actually analyze what's important for the business to focus on with regards to the speed of vulnerability findings and your actual capacity to fix those findings? So while I'm excited about the way AI is being used with regards to finding vulnerabilities, one of the areas I think there's a possibility for growth is how resilient are businesses to actually remediate the findings? Even changing the high, medium, low from 14 days to three days and the other things.

My initial concern as a security leader was like, well, do I even have the team bandwidth and capacity to move at the speed for which AI is finding in terms of our development process, our QA process, our testing process for all these vulnerabilities? Right now my gut check is like no. So what does that look like to design and build engineering teams that can support the speed at which these vulnerabilities are being found and tagged and then prioritized, whether it be through SSVC, things of that nature. So that's also, I think the counterbalance to this is, well, are we actually designed and funded to actually move at the speed for which these vulnerabilities are being addressed and found?

Lloyd Evans:

Thank you both. And I want to pull on a thread there, which is the data quantification piece. So in the federal space here, there are very specific controls that were created pre-AI and in some many cases precloud. And these are the controls by which it dropping down and whether you're talking about FedRAMP or just 153 or even some of the commercial frameworks, these are the benchmarks that we are held against. How do you pair that from meeting these controls while also taking that data driven Approach, security engineering principles. What are some ways that you can kind of unify both of those and be able to achieve the both and spectrum there?

Charles Nwatu:

So I think part of this is the systems thinking approach. Well, how are we designing our systems to be resilient? And when it comes to, are the findings actually appropriate to the systems themselves? And so one of the approaches we've looked at is how do we inventory our systems so that when these findings do come in, we have high confidence that are they internet facing or not? We're tagging them appropriately so we can actually do the traceability of those things. So I think one way to continue to balance the control findings and the actual certification and regulatory frameworks is, well, how do we bring those two worlds together in our design of our infrastructure in a more machine to machine approach where we're recognizing the human judgment of our engineers to build an appropriate CI/CD and patching infrastructure to do that. So that's one of the ways we've been thinking about it.

Mario Lunato:

Yeah, I totally agree. We all had the big movement of shifting security left in your development processes and you ended up with DevSecOps and things like that. But I think it still left GRC out of the scope. And as Charles was mentioning, some of those folks in the GRC world are what your compliance frameworks and all of the actual things you're doing in your organization to meet compliance standards, whether you're just rubber stamping your SOC 2 or actually trying to figure out what your compliance and risk appetite as a company is. Moving those people into the conversation now and helping generate the career field that's buzzing around of GRC engineering, where you take those folks who are building your system and they now actually get the security telemetry and the things that your system may be processing or building by virtue of what they do or how they're designed, but then mapping that back to the GRC aspect of your AC controls, your AU controls, all of those different families that we all love and know from this of how does my system make this telemetry and how do I then use that to do my compliance perspectives and bridging those gaps from a GRC person who lives in SSP, documentation, screenshot world, to an engineer who's designing IAC and systems at the seat of their pants and just building because that's what they love to do of getting those two folks into the room to bridge the gap and meet those things where

Charles Nwatu:

They exist. One of the things that was successful and one of the environments that worked there was the idea of just monitoring what the engineering individuals were doing in terms of how they map to controls so that we can then take those findings and write them as requirements into their product roadmap design conversations or their sprint planning conversations. One of the challenges when trying to move the GRC concept to the shift left or the DevOps experience is that, well, how do you get GRC practitioners to actually inject themselves into those workflows? Where in some cases they've actually been excluded from those workflows. So one of the ways as well, you can run in parallel and not actually disturb their deploy process, but have it audited with regards to what would fail, what would fall and things of that nature. So that's something in terms of what you can actually go back and do, is basically run in parallel with your CI/CD team and your engineering team with regards to the controls that you're trying to do and see exactly what would happen if you were to enforce them.

Lloyd Evans:

I love that example. And earlier Paul Rayner had showed a time lapse of one of the event storms that we did here at Rise8 prior. And that was actually one of the things that they came up was the platform team had their whole kind of event storm for their process to deploy to production. And then all of a sudden now all these compliance requirements are in the mix and it's like, hold on. We can't deploy a problem until these things happen. And the mix and mash of those was a very interesting thing for our team to kind of wrestle with and grapple with. Now two things, some threads that I wanted to pull on from both your answers is I heard Mario say builder and I think I've heard both of you say GRC engineering. I think when maybe some of the folks here hear compliance or GRC, you think like very legacy, like writing SSPs or you have someone that's asking, they're in front of the sphinx being like, well, what are our compliance requirements?

How do you see the field and the individuals growing and stretching into this new kind of thing that we've somewhat called GRC engineering? What does that journey look like? How can someone in the audience maybe recognize that maybe in some of their teams or in some of themselves and maybe that's part of implementing as a part of workflows, but what does that growth journey look like for a GRC practitioner today?

Mario Lunato:

Yeah, I think it's bridging the gap in yourself or in the people you have in your organization doing those roles. To Lloyd's mention of the platform team going to deploy and then compliance steps in the room and say, hang on, wait a minute. You're actually that because all of these things that you have to meet. So having that engineer now flip that switch in their mind of like, okay, how do I build these things compliantly so I don't have to go answer to the GRC folks later on of like, are you doing this? Are you doing that before you can deploy? Yeah, I already did it. It's here. I've automated it. It's exactly what you're looking for. So finding somebody that's willing to accept the world that is NIST in all of the different frameworks while also being somebody who's willing to engineer systems and loves to build things because natively most of those things exist outside of each other.

An example that me and Lloyd shared together is trying to build a cATO program at a large civilian agency. And we tried engineering automated things like AWS config rules, security hub rules, JSON files. Here's the thing, here's the actual evidence you're looking for and it's from my actual engineered system. Here you go, here's the thing. And then the compliance folks at that organization were, I don't know what this means. I don't know what this JSON file means to me. Can you explain it? This doesn't make sense to me. So finding folks who are interested in like, oh, this is what this actually means from a compliance standpoint and then I understand how to actually go build and do the thing are probably the best minded folks for the aspect of what the career field of GRC engineering is.

Charles Nwatu:

Yeah. When I think about GRC engineering, there's I think a couple of verticals that I look at it from. And I'll also say not everything has to be automated. I think there is a rush to say just because I can automate my job, that just means I've done it better. I think one of the talks talked about you just shift the pain point to another part of the process. And I think it's really understanding the processes for which you have and then from there recognizing where is the value in terms of doing some of that automation. So there's work with regards to I think improving the user experience for when you don't own the actual data or you're reliant on another team to produce that data for you. How do you make that engagement easier so that the solicitation of that information becomes simpler? So I think that's one aspect there.

And then the second aspect is this idea of the systems thinker. Well, how do I look at all the components that are being built and the investments that the security organization with your engineering organization, your infrastructure organization, your product security, how does that all come together to really help understand the risk that the business is managing? But also how do we help from a compliance and control standpoint understand how do we make decisions faster? Because at the end of the day, we are met with limited resources and time. So where are we making the investments and how do we make that trade off if we have a better understanding of our control posture and how that helps us manage our risk at large?

Lloyd Evans:

Thank you.

One of the outcomes here is, one of the quotes that Bryon had mentioned is splitting enabling outcomes versus mission outcomes. And I think for the field of compliance in the field of GRC, we find this in a very interesting space of almost entirely being an enabling outcome. The outcome or the mission outcome isn't to achieve compliance, isn't to achieve this hardened system. It's this hardened system is what enables the mission outcome in the context that the mission outcome exists. What are some of the challenges you're talking about pulling on the thread of integrating with the business that you think maybe whether it's folks from the business side interacting with people from the GRC community or GRC professionals that are now finding themselves very quickly facing real business constraints and business requirements given the pace of deploying new things with AI. How do you find yourselves in that kind of enabling outcome space and how do you think and wrestle with that and grow and stretch to be able to engage on the business side?

Charles Nwatu:

That's a good question. I think part of it is balancing the understanding of what you know, what is your inventory? Because when you're hit with those roadblocks with regards to enabling from the business side, but then also from the engineering side, sometimes you're getting in my way. How am I able to move with a certain type of velocity and how can I make those decisions while maintaining that velocity? And I think from the compliance side, it's basically saying, how do we capture the things that are happening so that you can continue to move with that same velocity and we can achieve the outcomes of whatever regulatory framework we're doing? And I think there's this conversation that can happen with regards to how are we building our systems and our security program that actually an outcome is that we just are compliant. We just meet the federal regulations or attestations that we have to design versus the goal is we're going to do these tasks to meet this particular thing.

And I think finding that balance within your organization with regards to, are we designing our infrastructure to meet the outcome of this or do we operate in such a way that we yield this type of outcome? It's very nuanced, but I think it changes how the deployment of resources, the type of infrastructure you design, even the type of individuals you may hire to support that type of thinking where it comes to we have designed a way and architected ourselves in a way that the byproduct of our work is that we are regulatory compliant or we're FedRAMP state compliant for whatever the case may be versus we're building a compliance team to meet obligations. I personally don't think that work may be fulfilling in the long term because I think there's very creative and unique ways that this problem can be solved, especially with AI and how do you create an environment where you can lean on both?

Mario Lunato:

Yeah, I think you covered that piece really well and I wanted to mainly hit on the enabling of AI. As I mentioned earlier, attackers are using AI to hit us. So we need to be able to enable, whether it's the GRC folks, compliance folks in the same realm, security engineers, everybody to then use AI on our side internally to gather all this information and make actual valid decisions on what we should be doing with using AI to help speed up processes and do a little bit of the decision making with also putting some change on it in the sense of you don't want to just build a slop factory. You don't want AI building your entire SSP package and writing all of your control narratives with nobody ever reviewing it and tying it back to your actual business system, your mission and what's actually running in your production state to where it's just basically a hallucinated SSP and control statements that doesn't actually make sense. So using AI to enable security engineers and building their code, but doing so in a secure manner, enabling GRC folks to review all of the telemetry and all of the things that are being output by your system to make risk and actual true business decisions and then having them be at the human in the loop to review everything that is being presented to them by AI to make an actual risk decision or business factor decision on all of that information. So basically using AI as the proponent to do the research, but then having somebody there to validate that it's not hallucinating or just making a bunch of slop for the sense of using AI.

Charles Nwatu:

I think on top of that, we were talking backstage about the idea that GRC is a very multidisciplinary function and that it connects to different parts of the business, whether it be your security side, your engineering side, your business, your legal. It's a very interesting central hub where you get a lot of signal from different parts of the business. And I think the open challenge for our field is to essentially, how do we take all these signals in and synthesize them in a way that allows the business to essentially reduce the friction of making a decision? And I think that's with the involvement of AI and some of the interesting platforms and solutions that are out there, how do we enable the business to do that at scale? So I think there's some really unique opportunities for the creativity and curiosity of GRC practitioners to say, "What can I do beyond how I've done it before?" Because there are ways that it can be done. I'm aware that there's friction sometimes on the receiving end of that, but I do think that's where our domain and our industry needs to go to really explore what else is out there.

Lloyd Evans:

Thank you. Kind of pulling on the thread of the second sphinx a little bit and looking forward to the future in the spirit of uncharted, compliance is a very old discipline. And when we talk about future innovation, pulling on Eugene C. Lewis as an entrepreneur and pulling on some of the entrepreneurial spirit that I think is ingrained within some of the GRC engineering efforts, where do you think things are going in maybe the next seven months that people can pay attention to from a signal perspective?

Mario Lunato:

I think it's a matter of, as I was mentioning, enabling the business to use AI and make decisions around those aspects and being somebody who's willing to allow the business to start adopting AI features, but again, harnessing it into not making a bunch of slop and just messing up everything that already exists and creating nonsense. So I think it's on the organization to allow their engineers, their GRC folks to start enabling these features, these cool Cloud, OpenAI, Vertex, all of the fancy AI products that exist outside of that GRC tools, RegScale, Paramify, all of these tools that have some sort of AI component within them and enabling that to use to gather information, to build systems more securely and do risk for your business in a contextual conversation and enabling folks to use cool technology to do it without also limiting their capabilities of you can use this AI feature, but you can't use all of these things over here and then now the AI feature is basically useless to you.

So reigning in the control of how your business is allowing engineers to use those things.

Charles Nwatu:

I think there's probably maybe two or three things I'm thinking about. One would be just vulnerability management. With the acceleration of the adversary having the access to these things, within the next three months, what are we going to do from a Defender blue team perspective with regards to our control understanding, our control state, our control efficacy from a compliance and risk management and decision management standpoint? I think that's one area that I think will be interesting in the next three to seven months to see. And then lastly, secondly, I think it's just where do we as practitioners start to go? Are we going to becoming more embedded in native security teams? We've talked backstage even the idea that, well, with GRC being so expansive, how much can it influence other parts of the business with the data it starts to collect? And do we start seeing this role morph into some decision architecture enablement for the business?

I'm very bullish on what compliance provides, more so with regards to enabling the business to make better decisions and the ability to do that risk management and quantifying the output of that work as a way to do trade offs and analysis. So I think there's a really interesting time for just compliance in general. I never thought I'd be so excited to start saying I'm excited for compliance and regulation. It's not a natural thing to say, I think, but I think we're in a space where with AI and the things that are happening with data protection, it's really up to the curiosity of the folks that you're with and whether or not they're actually willing to step outside of the norms and of the guardrails as some, I think kept us gated in.

Lloyd Evans:

For a final question, you touched on regulation and one of the things that we talked about quite extensively backstage was the, as we transition from manual to more automated processes, we start to find that the existing regulatory compliance frameworks that we all know and love were again created pre-AI, created for a pace that is far, far slower than the one that exists today. What is the potential changes in regulation or how do we find ourselves in that balance between these compliance requirements that existed and maybe didn't quite capture, like if we're pulling on RA5 for vulnerability management, the vagueness of that control doesn't quite capture the specificity of what we're talking to today. Where do you see things going and do you see a need for tighter policy? And then there's things like FedRAMP 20X, which are strides towards this. Do you see more of that coming in the future and how does that start to take shape?

Mario Lunato:

Yeah, I think so. FedRAMP 20X is a good example of it, of where automation and trying to condense down what we see as NIST 800-53 into 90 or so KSIs, the key security indicators that 20X is hitting on of maybe we don't need to do individual control assessments and we can say like, "Hey, our IDP is doing X things here and we're monitoring this, so this is covering us from all of these controls." And we don't have to go literally timestamp and check every single control. But at the same time to what you mentioned is the control frameworks are built from a time of, as you mentioned earlier, pre-cloud. To hit back on the cATO program that me and Lloyd were building, we were building all of these NIST frameworks or it was based on the NIST framework and we were trying to build automations into these controls. And even in their environments where they're using containers, GitOps, Flux CD, Argo, those type of deployments, the controls didn't even read. You had to basically interpret like, "Well, does this mean that and does this apply to here on this container or does that right here?" So you're basically kind of guessing. So frameworks definitely need to catch up with the space that we're moving in terms of AI and the compliance and all of the automation. And FedRAMP 20X is a really good step in that direction.

Charles Nwatu:

Yeah. I would say the control inventory and control libraries and how we apply them into our systems and workflows is probably the biggest thing. Even independent of any regulation that comes out, I think there's an ownership within each of the respected environments that you represent that you understand the risk, you understand the systems that you've designed, you understand the controls should be in place or not in place. How do we get better at testing the efficacy of those controls? And then from those controls, how are we mapping them to the actual true risk? At the end of the day, if we're supposed to be monitoring and managing the risk, I defer to the people that are within those environments that have the context that are working with the developers and engineers to sort of build, we talked about this, the actuarial tables of loss for your business and what does that look like and how do we bring in those controls to then marry that to these statements that you can say, "Hey, we can demonstrate this because we operate in this way and this is the evidence, machine to machine evidence or people evidence." I won't go so far to say screenshots, but how do we get to that point where we can just deliver a package that machines to machines can validate, there is trust through the whole process, there's integrity through the whole process that we can deliver this package to you in a way that you can accept it and have trust in the processing of your data in our environment and vice versa.

Lloyd Evans:

Charles, Mario, this is a dream come true for me. I look up to you both. Thank you guys so much. I appreciate you both for joining us.

Charles Nwatu:

Thanks for having us.