Steve Vandenburg, AI Security Architect at Cotiviti
Steve Vandenburg, AI Security Architect at Cotiviti, discusses the evolving role of AI security in enterprise environments and how frameworks like NIST AI RMF, HITRUST, and the new SAIL framework translate from policy into real technical implementation.
Listen on
Transcript
DownloadRead the full transcript
Allie Howe Hey everyone, welcome to episode 9 of the Insecure Agents podcast. I'm your host, Allie Howe, and today we have Steve Vandenburg, AI Security Architect at Cotiviti with us to talk about AI governance and security. Specifically. How do you go from framework to policy to implementation? Steve, would you like to introduce yourself?
Steve Vandenburg Yeah, sure thing. Allie. Thanks for having me. First off, excited to be here. My current role is as an AI security architect, and I like to describe it a little different than the classic security architect role that's focused purely on the technical aspects, but it's also about designing and assessing the processes, people, and to your point, governance around AI. Been in this role for a little less than a year. I was leading a team of security infrastructure engineers and enterprise IT folks at a smaller health tech company and was like so many of us, enamored at the progress of generative AI and kind of following it side of desk nights and, and, and what have you, and got this great opportunity to focus solely on AI at my current company Cotiviti.
Allie Howe Yeah, I feel like that AI architect role is kind of a newer 1, so super exciting that you're one of the people taking on that challenge.
Steve Vandenburg It's a Wild West of sorts as new architectures, new patterns emerge and and trying to, you know, stay up to date on what needs to be happening there.
Allie Howe So do you have like an engineering background and transition into security or always been security focused?
Steve Vandenburg So my background, I would describe it as interesting. I, I started off actually a little more on like the audit compliance side. Originally I was running teams that were doing SOC 2 assessments for companies, which I know you're familiar with and slowly transition from there to more a technical security role. I participate in Lambda school at the time. It's, it's gone through a couple different iterations since then. Did an 18 month program to help complement some of my more like compliance and security skills both to, you know, help build myself but then also empathize and be able to better communicate with engineers and builders.
Allie Howe Very cool. And yeah, familiar with the SOC 2 compliance stuff as well. And it's interesting that a lot of security sometimes starts with compliance because that's what the market needs you to have. You have to have SOC 2 compliance, You have to be able to prove your security posture when you go to market. And so security usually is a secondary market where you have to have a product 1st and then because of this product, now we're going to go and try to secure it. And so a lot of especially for small startups, their very first sort of taste of security is a forcing function from these go to market efforts where they're going to go out and they're going to try to sell.
But if they can't articulate their AI security posture or their security posture in general, they're not going to be able to close any deals. Sales cycles are going to take longer and they're ultimately going to lose deals and revenue. So tying the knot and connecting the different puzzle pieces from go to market compliance, the engineering team, the security team, tying that all together to create a holistic security program that serves the company in general. It's a super valuable exercise, something that like obviously brings a lot of value to the company. And you can like, you know, tell your boss like, hey, here's what we did.
I can really, I can point to these revenue numbers. That's what the security team did this week or this year. And that's why we're worth, you know, keeping on or whatever. That's a valuable conversation for sure. Can you tell us what it's like designing an AI security program for a company in the healthcare space?
Steve Vandenburg It starts with, whether it's AI or other items, it always starts at the patient level and the patient data perspective. And so designing a, a program that has that at the heart, that is the, the crown jewel is kind of what, what's centered any of my, my work in healthcare, like you said, pros and cons. It's, it's very compliance heavy, which is helpful from a focus and a funding perspective. And there are several kind of healthcare specific organizations, HITRUST being one of them, that has gone ahead and put out different frameworks around AI, both risk management and security. And so they were helpful in starting to kind of look and develop a program because it already has a cache among the healthcare industry for being kind of a top standard similar to to SOC 2, like you were saying at the the startup side where it becomes quickly table stakes once you start selling into larger organizations.
You know, I find in healthcare very similar that you once you start moving past a mom and pop situation, HITRUST becomes close to table stakes for anyone who wants to be selling into large organizations.
Allie Howe Yeah. And I was looking into HITRUST and it seems like it incorporates different parts of like SOC 2 and ISO and all these different frameworks to create this sort of like source of truth or like primary table stakes framework like you're saying for healthcare companies or ones that are serving that industry. Super interesting that HITRUST was able to adopt part of the NIST AI RMF, their risk management framework into HITRUST to have an AI security specific part of that framework, which is really, really interesting because I feel like most frameworks today, or maybe I'm just like recency bias from like SOC 2 like they're not taking AI security specific controls and implementing them into their frameworks, at least not yet.
What I see mostly is all these new frameworks spinning up. So like NIST AI RMF, ISO 42001, also Pillar SAIL framework, which we both collaborated on and we can get into that later. That was really exciting. I think it's really interesting that like HITRUST was able to incorporate that into their framework. I'm just wondering for the future of compliance in general, and I'm wondering how you see this? Like do you think that frameworks that will be more likely to be adopted and will be more successful are the ones that incorporate AI security into what they already have? Or do you think these AI security stand alone frameworks are best and that's where we're headed.
Steve Vandenburg Yeah, I think we'll see a mix of both for a little while. We'll see kind of the, the incumbents like a HITRUST, like ISO put out AI specific frameworks that add on to some of their existing certifications and then some that kind of come out of nowhere that are probably a little closer to the ground or closer to ground truth in terms of what's happening, what the challenges are with the risks are. And so I think right now it's important to kind of have an eye at both. I think where it lands, it's going to be that bundle. It's going to be, you know, whether SoC 2 and the AICPA start to integrate AI into that.
HITRUST has already done it. I think it'll start to bundle together at some point. Where I'm somewhat optimistic is what AI can enable in this space. So SoC 2 and any, you know, similar report is for a period of time and it's backwards looking. And so I'm hopeful that with AI and especially agentic AI, there's ability to get more real time sense for security posture. And I see companies like Vanta touch on this right now prompt armor. So there are some players in this space that are trying to address this concern of you know we've worked a while with SOC 2 and HITRUST and such being kind of the go to.
They've always been backward looking and you go to something like financial services and kind of the classic disclaimer there of past performance is not indicative of future results. And I think we've accepted it from a security perspective because it's the best we can do for now. I'm hoping that starts to change and I am seeing some of that with like I mentioned, like a Vanta.
Allie Howe Yeah, I agree. I'm a Vanta partner, so I see a lot of that as well. I'm really excited about their new AI technologies they've come out with for their platform specifically, but also really excited about Vanta and others like them having the opportunity to be the single source of truth and sort of this like single pane of glass for AI security. And in general as well, because you can add specific controls even after the framework that you're doing, like say it's SOC 2 doesn't cover AI security controls per se. You can add custom controls into a tool like Vanta and then advertise those controls in your trust center.
So when you do go to market and you say, hey, yes, I do have continuous testing on AI security specific controls, which can be really helpful especially for an AI startup in their go to market process. I'm wondering in your go to market conversations at Cotiviti, did your AI security specific control set that you did as part of HITRUST, was that helpful?
Steve Vandenburg It's been helpful and and I haven't seen the extent of clients asking prospects asking for AI specific certifications to this point, but I see the precursor of that being increasing volume of questions, increasing scrutiny in that area. So kind of going back to your earlier point of where I see some of the different third party reports going, I think having that certifiable or third party review of your program is going to be key. It's going to, you know, creep into that table stakes conversation. You look at NIST and it's not right now on its current setup with a certifiable framework versus you go with, you know, ISO 42,001 or HITRUST and you have third party certification that you can get as part of the process.
Allie Howe I'd love to focus more or dive deeper into the AI specific part of HITRUST. When I looked into that, obviously it's based off of NIST AI RMF but focuses on 4 core functions of govern, map, measure, and manage for AI. What was it like to implement any of these? Like how are you measuring AI or managing it? Does that mean like deploying LLM guardrails like model scanning? I'm very familiar with the AI security like life cycle. How to secure that from just like an engineering perspective? Does any of that overlap with how you were able to satisfy these 4 core functions?
Steve Vandenburg Yeah, there's certainly some overlap. And just to set it up so HITRUST does have two separate add-ons that they offer. One is the risk management framework and one is the AI security, I think factor framework that they have. So the piece on say guardrails, for example, is covered explicitly and required explicitly within the AI security framework. And that's something that we're we're building to. But those same guardrails are relevant for a risk management perspective because they inform the residual risk of a a certain AI system. So as an example, the AI risk management framework will look at discovery and processes to assess risk of different AI technology and use cases of AI.
And as part of that, you want to look at, you know, the inherent risks within that use case based on the data and the technology. But then from there, you want to factor in, you know, what can mitigate some of those risk. And so, you know, if you have, say, an input that is accessible to employee population or external population and you have that unmitigated, that would start bumping the risk up very, very high. But if you're able to, you know, use some type of guard railing, be it some of the native capabilities that the the CSPs give or a third party guard railing solution, you're able to, to mitigate that risk some and have that residual risk fall to a different level.
And how we've adopted that is that residual risk level then triggers approval authorities. So, you know, based on where that residual risk lands, there's different parties that need to get involved to potentially approve a certain use case.
Allie Howe That's really a great point about like where to get the guardrails from because I feel like there's lots of different options nowadays from like even like eval platforms as well as CSPs. I mean, everyone's kind of doing it, how customizable they are is sort of like like what puts them apart, so to say, which is interesting there's.
Steve Vandenburg Never been a better time to take some of like the compliance and like policy and standards language and quickly develop at least a V1 of technical specs. So using generative AI for those V1s. But taking, you know, a requirement of you need to have some inline auditing, logging, monitoring, protection against prompt injection, etcetera. And taking that and really looking at where your builders are building and giving them options, you know, it might be, hey, you're building an allowed service provider and they provide these. It may be as an organization that you have, you've procured third party tools and you can also and, and this that has been one of my strategies is look what's out there from an open source perspective and reference that to our builders as a potential option as well.
So there's never been a better time to take what I'd say is policy and compliance language and really make it actionable for the builders within an organization.
Allie Howe That's amazing work that you're doing for sure. I totally agree with that. I know we also recently contributed to Pillar Security's new sale framework. Those that don't know, Pillar Security is an AI security life cycle platform, so they'll help you secure your AI throughout the entire life cycle. And they just came out with a new framework called Sale that they collaborated on with many members of the security community, including Steve and myself. I thought that was interesting because Pillar brought tons of people from the community together to be able to create this framework and document about how do you actually like very actionably be able to take a framework and be able to apply it to your organization.
But I feel like it's kind of missing in some of the other frameworks. Or like, you know, maybe not everybody has somebody like you on your team, Steve, right? Where they like there's this AI security architect that's going to translate our compliance framework that we're using into actual implementation and technical specs that our engineering team is going to be able to look and OK, like I need to go implement this and This is why. So are you using sale at all as part of your work?
Steve Vandenburg Yeah, I, I think you had the nail on the head of it's been most useful at that helping with that translation layer. And, and one way that I've been using it is one, the general formatting. So the fact that it is more, I'd say builder focus, you look at NIST, you look at ISO, it's very much like the audience is a compliance person. The audience is part of some vendor review process. You try to hand items like that off to someone who's neck deep in setting up infrastructure for AI or experimenting with different AI tools and it doesn't line up with their mental model the way that they're working day in and day out.
That's where I think Sale succeed beyond belief. And it's been helpful to frame from the policy side, which I've kept aligned to like more that compliance focus to more the standard or technical spec side, which aligns with how Sale has formatted it from like plan all the way to the red team and along the way to monitoring. Want something out in production. It makes a lot more sense for builders to follow that format. And then even within that, I've used it to kind of gap assess some of what I've covered in standard. So red teaming being one of those, you know, I had standards around performing red teaming and here are some sample like open source libraries to assist with this.
Here are vendors that have tooling for this, but I think sale helps that speaking to think it's like Unicode and foreign language testing is part of red teaming, which I think we've all seen whether it's Pliny the Liberator, other red teamers on X that I've gotten crazy results with different red teaming techniques. So it's helped to kind of gap assess and really better frame requirements for the builders within my company.
Allie Howe This is a great place to go for help with a gap assessment. And I thought one of the most interesting things to that they did was they broke down like threats by AI security, like life cycle stage. So like there's threats for the plan stage, that's for the code stage, the build, the test stage, which is like the red teaming part and the deploy time, and then also like monitoring it later on. So it's a great place for folks to go and sort of breakdown what their AI security life cycle even looks like in the 1st place and like what to look out for at each of those stages.
Steve Vandenburg Yeah, 100%.
Allie Howe Do you have any advice for like other teams in terms of how to decide where to look and which frameworks to use for their compliance and AI security program?
Steve Vandenburg Sales are great starting point. My biggest piece of advice here would be there is a lot of noise, there's a lot of development in this space and try not to let that distract you. So my advice would be time box, you know, whether it's, you know, a couple hours, a couple days, do your research, use deep research capabilities. It's a great starting point in any of the the Frontier lab models and put your foot in the ground and choose something quickly because I think the biggest value is on getting started with the implementation starting, you know, it sets a culture. You start your dialogue with builders so you can actually get that standard and framework closer to ground truth, identify gaps.
So you know, again, sales, sales a great point. If you're in the healthcare space, HITRUST, I think has been good, but my biggest piece of advice would be time box it. Don't let the noise distract you. Pick one and move on. And it doesn't stop you from, you know, like I've done with sale as others releases, others come out taking the best parts of them and incorporating them into the framework that you've chosen. I think you mentioned earlier when we were discussing Vanta, Hey, this this particular thing might be outside of the scope of SOC 2, but we could throw it in our trust center.
And so just because something's out of maybe the core piece you're being assessed against or audited against doesn't mean you can't incorporate it into your program.
Allie Howe And that's also something you can do like beyond your audit windows. So like, say, if you're like really rushing to get through an audit for, you know, something you have to like a SOC 2 or HITRUST and you can always add on those customer controls later. So I love this idea of like constant evolution, looking at new frameworks that come out, new adoptions, new updates, but also just as requirements change within your organization. If you feel like there's some sort of risk there that you're not covering or adequately mitigating, go look at the community, see what's coming out new that other people have done. But again, like, don't get lost the noise, like you said, I 100% agree.
That's such a good point because there is so much noise and amazing organizations putting out new frameworks of their own and guidance, which is super helpful. But again, so easy to get lost in the noise. So I agree with the time boxing. I think that's such a great take away.
Steve Vandenburg Yeah, and I think I, I, I mentioned that as someone who probably circled the drain too, too long. So it, it comes from a place of, of past experience and, and pain of if I had to reflect back on on 1st focusing on this role was probably, you know, spent a little too long in that initial stage before getting stuff out there.
Allie Howe Yeah, me as well. I've definitely fallen into that trap too. And I think anybody that's dealing with AI in any capacity could probably attest to that as well. Just like there's all these new AI coding agents on there. Maybe you haven't tried every single one and you've got FOMO about that. I'm sure, you know, engineers are feeling it just as much as we are on the security side and vice versa. And everybody so well, amazing. Thank you so much for taking the time today. I look forward to continuing to follow your work. If there's people that want to connect with you beyond this conversation, where can they find you?
Steve Vandenburg Yeah, best place where I'm most active is Twitter X at Steve Vandenburg. Nothing fancy. So please reach out and look forward to continuing the conversation there. Thanks so much, Allie. It's been a great time.
Allie Howe Thank you so much, Steve. That's it for episode 9 of the Insecure Agents podcast with Steve Vandenburg, AI Security Architect at Cotiviti. See you all next time.
Auto-generated and lightly edited for clarity. Plain-text version