Transcript for "The Access Path Logs Won't Show: Making Inherited Access Visible & Enforceable": Hi, everyone. Welcome. Thank you for joining us. We're just gonna give ourselves, twenty more seconds. Okay. Given we have, a fairly short amount of time, I wanna get straight into it. Thank you all so much for joining us. I'm Farrah Aya from Obsidian Security from the product marketing team. And today, talking about the access parts your logs won't show, how to make inherited access visible, innumerable, and enforceable. Now a quick bit of housekeeping. We'll send the recording out within twenty four hours of this session and you can drop questions into the q and a at any point. We'll also leave time for those at the end if there are any, you know, questions and there'll be a short survey before we wrap up. Now I'm really excited to be joined by Carl Schimmel, our new head of threat intelligence at Obsidian. Carl has more than fifteen years of experience across threat intelligence and incident response, including threat intelligence at BNY and earlier roles at Citi and the NCFTA. Now, Karl, give everyone a quick introduction and tell us a little bit more about the work you've been focused on since joining Obsidian. Thanks, Farah. I, I think that's a good intro in its own right, but, you know, I've been working on multiple streams. Some of what I'm doing is working with our our team. Also been working on intelligence publications. But a lot of what I did in the financial services sector was related to external engagement. You know, that's building out intelligence sharing relationships. And I'm really working to bring those capabilities and kind of those successful models from the financial services sector to Obsidian and ultimately our partners. Additionally, I'm doing things like this, you know, in person or online engagements and briefings, you know, ultimately being a presence for Obsidian. Awesome. Well, Carl, I want to start with the research behind this session. Now we've seen so many cases where models thought they were operating in a test environment but ended up reaching real third party systems and production data. You know, at a high level, what happened in those cases? Sure. So I think, you know, people have some familiarity with the news around here, but I think there's something that I think is important to dispel, as a lot of the reporting, or at least kind of spin in the media, I feel, is a bit of a miscategorization. You know, some people have described the events as AI agents going rogue. Ultimately, that's inaccurate. You know, these agents were following their instructions, leveraging in the capabilities that they were granted, you know, acting within their governance and what they had access to. This is a reminder that, you know, the proper inventory and controls around your AI are crucial, you know, whether that's in a testing environment or ultimately in your own environment. But in terms of, like, the the, events in themselves, right, the end of last month, Anthropic announced that they, were reviewing, like, all their previous testing. And within those reviews, they discovered three incidents where cloud models escaped from their contained environments and breached third party organizations during capture the flag challenges. Capture the flag challenges are essentially just, an AI is in a what is supposed to be a controlled environment. It's set with a task, ultimately a flag to capture, and the, analysis around those look at kind of what what path the AI took. What did it do? What skills did it use? You know, and after this reporting, this this reporting followed OpenAI. They had a similar announcement on July 21 that, its models have breached Hugging Face following an escape from an isolated testing environment. Since then, AI has also, OpenAI has also reported, a couple other escapes. And then AC, which is the AI Security Institute in The UK, they also, reported on a Kim and k three model having a similar escape during a benchmark evaluation, and Meta has also made a similar claim. I think of note here, anthropics claims, that the escape, that they that their escapes, those were totally related to a misconfiguration where the Internet was made available where it shouldn't have been. Meta made a very similar claim in their case. The instance of OpenAI was a little bit different. Their models escaped the sandbox environment that had access to JFrog Artifactory, which is essentially, a tool that needs Internet access as it pulls, software libraries from public repositories. The anthropic models I'm sorry. The OpenAI models, leverage the zero day in, JFrog, and they escalated privileges through that, and they were able to eventually reach the open Internet. OpenAI said that once their model, reached the open Internet, it reasoned that Hugging Face might have been storing the answers needed for that test it was trying to pass. So that's why the attacks ultimately occurred. I think interestingly here, when looking at all these incidents together, outside of that zero day in JFrog, the reporting suggests that once the models had access to the open Internet, their compromises largely relied on nothing novel. Right? These were, this is kinda what we've seen too in in many recent, AI enabled attacks. Ultimately, it's going after known attack paths, and nothing too novel. Carl, I have a question for you on that. So if these attacks weren't necessarily novel, I guess what's the lesson here? What's like your, you know, your early insight that you can share with the group in terms of what this means? Yeah. I think maybe it's, like, a good framework for this is to think about, like, what's the good news and what's the bad news. Right? The bad news here, I think, is that, you know, frontier models have clearly shown themselves to be useful tools in kind of obtaining initial access, lateral movement against targets in, you know, this recent reporting as well as previous range studies. I think probably other bad news is that these capabilities kinda given historic precedent are likely to spread down to sort of the open weight models over time. Recently, a black hat I attended a chat where, the security researcher said that they estimate in general this is around six months to one year's time where you see capabilities from frontier models go into, you know, a lot of open weight models. So I think defenders can't assume that these capabilities won't be widely available, you know, to a variety of threat actors in the medium term. Ultimately, that's kind of democratizing the threat. That's a new, kind of broad risk in the threat landscape that you have to deal with. But I think there is good news here, and that's when, you know, if you look at what occurred in these attacks that were reported in the media, outside of those zero day vulnerabilities, you know, which is something, you know, we are actually seeing kind of more broadly in, kind of the landscape already. Right? The last three past Tuesdays from Microsoft, have been record in size. I think July was the biggest in in, in history, because of, AI enabled research, right, in in terms of vulnerabilities. But outside of that, right, most of the observed activity we see still follows known attack paths, and often that are a little bit less sophisticated in terms of the exploitation channels. So, I mean, in in the cases of OpenAI and Claude, you saw things like, exploiting weak passwords, unauthenticated endpoints, package poisoning, SQL injection. You know, those are things that we can, you know, we can address. We know how to deal with these things. So, ultimately, that means best practices remain an effective and crucial defense. I think the timelines have maybe gone down. The margin of error in terms of strict implementation, if we're thinking about an AI augmented threat environment, is a little bit more, risky. We have to be a little bit closer to perfect if we can. But, ultimately, I think what's important here is that, you know you know, hardening, is still a really effective defense. And it's not just me saying that, you know, AC who's done a lot of this range testing, that's one of their recommendations as well. So I probably think about three things as a defender, you know, following that traditional best practices, type of activity. Things like layer defense, zero trust architecture, you know, active patch management, identity and access management, things like root vocation and rotation of credentials, multi factor authentication, encryption sensitive data, role based access, network segmentation. I mean, these are all the things that we would use against traditional attackers. They're also probably more important against AI enabled attacks. Defenders should also consider employing AI for defense. You know, you can use that for things like automated testing, scanning, patching. You can work with the frontier model providers for trusted access programs. I think the most well known of those is, Glasswing. You know, you you're able to access, you know, the frontier models for your own defense. You know, you can also think about using open weight models for this as well. You know, it's worth testing those in your environment and potentially related to your incident response programs as well. You know, the same capabilities that create risk can be part of a mitigation strategy. You know, you've seen organizations like the Cloud Security, Alliance also recommend this. I think ultimately, though, this isn't really a new idea for security. Right? In the past and really still, you see threat actors use cracked versions of red team tools like Cobalt Strike and Metasploit. It's a great idea to use these tools, in your own environment to find the weak points and address them before the bad guys do. Right? It's a similar idea here. I think finally, defenders need to develop, instant response plans for AI supported attacks and and really test them before they're needed. That includes validating that your tooling can detect, log, and respond to patterns that we've observed in these attacks. You know, it's always a good idea to be ready for the bad day as much as you can before it comes. Thanks, Carl. And I'm curious, like, what are those initial steps that teams should be taking, defenders should be taking, especially when partnering with other, you know, business teams, whether that's app owners? Like, what are some of the things that they should start doing, especially if we're talking about maybe a lean team? Like, what what are the what advice do you have there? Sure. I think, doing an app inventory, you know, reviewing changes around visibility, mapping what your tools can reach, you know, think about in the event of an issue, what you do to stop it, you know, what your decision framework about making those decisions is. That's really, that's really where I would start. I think about kind of, you know, this in kind of two areas. Right? Create your living access map. It's gonna be constantly updated in terms of, you know, you know, specifics around your apps and their access, and then also have a containment plan. So at minimum in doing this, what I would look at is, you know, what what exists? You know, what are your agents? What are their integrations? Do they have OAuth grants? You know, are they connected to other applications? Think about who who is responsible? Is there a human owner? Is there a business owner? You know, what happens if that owner leaves? You know, that's where you really need to have these conversations with your line of business in terms of determining exactly, you know, what what this app is used for and who's responsible for it. How does it authenticate? You know, what's the token type it might use? That type of thing. What can it reach in your network? Are there particular tenants? Are there records? Is there sensitive data? Is there PII? I mean, that's are there administrative functions? That ultimately makes, you know, its access much more of a concern. Think about what can it do. Can it write? Can it export? Can it delete? You know, we've seen incidents in the past where delete is allowed, related to certain agent integrations, and that's caused issues when they were misconfigured. When you look at what the connection is normally doing, right, can this be just can you distinguish malicious activity from, you know, legitimate automation? Knowing exactly what business depends on it and how. Is it related to a critical workflow? Is there a business impact if we have any type of downtime related to it? You know, is there an acceptable pause window if we need to shut this down to maybe investigate more? What's gonna be the impact of the lines of business? Do we have a validated backup or recovery path? And then finally, you know, what do you cut if you need to shut this off? Is there an exact token, an integration, a permission, maybe an account or connector that you need to revoke first? And and who actually approves or executes that action? Carl, I'm curious. Like, you know, how how have you in the past approached, you know, building those relationships with cross functional partners, be it, you know, business business owners? Like, do you have, like, one piece of advice for teams in terms of how they approach that? Yeah. I think that's really important, and I don't think it's necessarily just related to AI or third party apps. You know, I think it's across the board. You need to have a strong relationship, with your lines of business and your, you know, information security folks. So I think what what is helpful, is to get buy in and communication from the top to start. You know, if if there's an edict that comes down that, you know, there's a process that has to be, you know, jointly addressed, these teams have to work together. Well, that doesn't give you much of a choice to to not work together. It's a bit of a trope, I think, that, you know, information security teams and business teams have, you know, misaligned priorities. They don't get along. I don't think it has to be that way. I've had some really positive relationships with app owners and, you know, lines of business people in the past. You know, if you have regular touch points, if you establish relationships, if you establish joint goals within those communications, I think that can really help with buy in. The other thing is if you have things that are kind of more of a regular process and not, you know, a last minute, you know, you need to do this now, it's something that's regular. It's timed. It's expected. Like, you know, we're gonna go over, you know, what these particular agents are connecting into, have any permissions change, that type of thing. If it's a regular type of process, cyber can be viewed as helpful and not necessarily, you know, adversarial or anything like that. I think it's really important, you know, as a, from the information security side to communicate why you're doing these things and communicate that, ultimately, you're trying to avoid business impacts. Right? You know, you're looking for the smallest authority path to cut something safely in the in in the case that there's an incident. Right? By having that by having that background information that allows you to do that, ultimately, you're avoiding having to make disruptions to the lines of business as much as you possibly can. If you have information in terms of the background about what these apps are doing and things like that, in the process of investigations, hopefully, you can avoid shutting down something that you don't necessarily have to shut down. The other thing I'd say is if you take this a little bit further, you know, having this buy in between the teams, you know, is helpful across the board. It's really good if you can develop kind of an eyes and ears relationship between the lines of business and your information security team. I think it's kind of like a, I don't know, almost like a Smokey the Bear, like, only you can prevent forest fires types of thing. I know that's corny, but really, if you have, you know, everyone within the company being eyes and ears for the information security team, that's ultimately good for everyone. That increases your security across the board. I think the other thing that I've kinda related to that that I've ran into in my past way more than I would like is often, if you have a third party app or an AI provider or even enterprise software provider that has some sort of issue, maybe that's a a misconfiguration, something they're changing, maybe a CVE that needs to be addressed and they provide that communication, more often than I'd like, that's going to the line of business and not necessarily the security team that's going to action that. So if you have those open paths of communication, people are comfortable communicating and they they regularly are sharing information with security teams. You know, that solves that issue off the bat. Right? That makes things easier for everyone. Thanks, Carl. That's very, very helpful. And, you know, of course, I'm mindful of time here. I'd love to leave, you know, time for folks here to ask questions. So if there are any questions, I'm gonna, you know, check check the chat and see. Okay. I have one question here, which is three of, you know, we all know AI lets an attacker work at scale, but in terms of I think we had, a question similar to this earlier, but I guess, you know, if you had to call distill, like, what are the, you know, couple takeaways that you would give folks listening to this call in terms of how to approach this new frontier of attacks, like, what would that be? Sure, I think I'd, I think I'd maybe go down two lanes with this one, right? Oh, actually, you know, one thing I'd do if you're gonna do one thing kind of, related to some of the guidance I gave earlier, is think about reducing permissions. Right? If you can reduce permissions across the board, you know, remove, access that isn't needed, you know, things like read, write, export, admin. If it's not needed there, you're ultimately accepting a risk in your environment that you don't need. Right? If you remove that, you're lowering your blast radius. It's it's a good option across the board. Right? I think about that, but kind of more holistically, if we're gonna tie this all together, I kinda think about, taking steps, you know, in terms of your inventory today, in terms of your defense today, and having, like, those types of conversations between you and your line of business today. So I think about enforce the fundamentals, you know, those those best practices, you know, inventory every agent and model in your environment, You know, look at the reach, of those agents and things like that in your environment. You know, look at if the function the function is what they're doing. You know, if you do have things like OAuth tokens that are just, you know, waiting around, you don't know what they're integrated to, you know, think about revoking them. You know, I think really look at your instant response plans, for agent driven incidents. You know, work with your line of business to come up with procedures around, you know, what can be revoked, you know, how you're gonna go about investigations, that type of thing. And then finally, you know, consider the AI for defense. You know, things like automated scanning and testing in your environment as well. Really just I think focus on those fundamentals, and that's a great place to start. Awesome. Well, we have one minute, and we did have one more question, which. is three of these labs, you know, ran a review and phoned the victims. Kimmy k three is, you know, open wide and already downloadable. So what changes when there's no lab behind the model, essentially, is the question? Yeah. So I think there's, there's two things here. I mean, Kimmy's actually a little bit interesting here because it actually does have some guardrails built in to prevent, uses for, offensive cyber attacks. But, you know, if there's no lab behind it, ultimately, that might mean no guardrails. And if there's no guardrails, you know, that changes the threat landscape and that really anyone can use this model to, engage in kinda similar attacks that we saw from the Frontier models themselves. But I also don't think it's completely negative. Right? If you look at some of these incidents, you know, particularly the one around Hugging Face, you know, Hugging Face actually employed an open weight model to do their forensic analysis in their incident. Right? Because it didn't have the guardrails in there, they were actually able to use it in a way that, the Frontier model that they actually had employed previously, was blocking them within their network. If if you look at sometimes like, IR type data, it looks like you might be planning for a cyber attack. Right? The open weight model might have not have the guardrails. It might be best fit to actually do things like incident response. So, you know, there's a there's a positive and there's a negative there. There's probably a use case for many people to evaluate these, you know, open weight models for their own defense in in a similar way that you might intend to use a, you know, trusted access program from a Frontier model. Awesome. Well, thank you so much, Carl, and everyone for joining us in this session. We will have many more to come, so don't forget to, you know, follow our LinkedIn, follow Carl, and keep keep an eye out on all the incredible research he's doing. So thank you. Yes, everybody.