Loading summary
Transcript110 lines
- [00:00]
A
Foreign. And welcome to another episode of the Risky Business podcast. My name is Patrick Gray. This week's show is brought to you by Spectrops. And they make, of course, Bloodhound and Bloodhound Enterprise and Spectre Ops. Very own Jarrett Atkinson will be along in this week's sponsor interview to chat about a few things. I mean, one of the things we're going to be talking about with him is something we're also going to be talking about in the news section, which is, you know, things are sort of pivoting back to a prevention paradigm and away from a detection response paradigm at the moment. And that's all happening because of AI and big changes to the threat landscape caused by AI. So that is an interesting sponsor review coming up after this week's news. Now, of course, Adam Boileau is still traveling this week, which means we've got a special guest co host joining James Wilson and I for this week's show. He ran security for Adobe, both product and internal. He ran security at Cisco. He also ran security at Salesforce. Adding to that we might put, he was the captain of the Titanic. He piloted the Hindenburg. He is Brad Arin and he joins us now. Brad, thanks for joining us.
- [01:10]
B
Glad to be here.
- [01:11]
A
What was your actual title? Because we're trying, because we always have called you a CISO for those three, but your title was not actually ciso, was it?
- [01:18]
B
Yeah. So Salesforce was Chief Trust Officer. Cisco was a combo Chief Security and Trust Officer, and then Adobe's Chief Security Officer.
- [01:26]
A
Excellent. Okay, but basically you did the role of that we normally associate with like what a CISO does.
- [01:31]
B
Yeah, Top Security leader. Top security leader.
- [01:33]
A
Top security. Top dog.
- [01:35]
B
Yeah, the, the, the throat to choke.
- [01:41]
A
Well put. All right, so let's get into this week's news now and we've got a couple of stories that pair nicely together. One is from Reuters and one is from the Record where we've got guvies like officials from both the U.S. government and the U.K. government coming out and saying, hey, you know, AI is going to result in a big deluge of patches arriving. So, you know, you all need to go out there and just start patching stuff quicker. This seems to me like somewhat magical thinking because I think if people could patch quicker, they would probably already be doing it. James, what is your gut reaction here?
- [02:19]
C
Yes, if they could, they should. But also there's an element of maybe they shouldn't. Like if we are telling people to patch them really, really fast and we're dealing with an absolute deluge of patches Coming in. That to me means we are essentially saying, don't test as much, shorten the proving cycle to make sure things are safe. And I just. Even if people do get faster at patching, the second order impacts here really concern me. Like, just patches getting deployed rapidly, the lack of testing, the amount of entropy that that's going to introduce into systems. You know, not every patch just fixes bugs. Sometimes they introduce bugs of their own. I get why they have to publish this advice, but at the same time, you just look at this and go, nothing good is going to come of this advice either.
- [03:05]
A
Yeah. Now, Brad, I mean, it strikes me that if you're a government official right now, you're under pressure to do something. This is something. So that's why they're doing it. I mean, it sort of feels a little bit like that. What's your take here?
- [03:16]
B
Yeah, I think because of Mythos, we need to be shown to be busy in some way. I like the fact they're going from three weeks to three days while now, let me just.
- [03:24]
A
Sorry, I should just step in there and clarify that. You know, really what they're saying the, in the US Case is that once something's on the sisakev list, you know, currently they can order US agencies to patch those bugs within three weeks. And now they're saying, well, we're going to shorten that to three days, so we're going to like really crack the whip. And, you know, once something is out there being seriously exploited, we. We want to have the authority to give them three days to fix stuff, which, yeah, again, I just don't feel is actually realistic.
- [03:50]
B
Yeah. And you ask them what to do about the seven day cooldown to avoid supply chain attacks and then their heads explode because they patch and get the malicious upstream compromise. Or do they not patch and get compromised by the Kev List exploit? I think this is all in pursuit of what is likely to be shown to be a failed strategy. And right now we can still pretend it might work if we can just get fast enough. And I think ultimately we're going to have to figure out some new approach here to keep things safe.
- [04:18]
A
Yeah. Well, what does that approach look like? Right, because I've got my opinions on that, but I want to hear yours.
- [04:23]
B
Yeah. So to me, I keep going back to the mid-90s when everything was fresh and we had problems for the first time, and all software is trivially exploitable to people who knew how to do it. And the way that we kept the world safe was not fixing everything. It was just keeping the bad guys away from the software using network controls. And so firewalls are invented and other things like that. And so I think today being able to gate the bad guy's ability to reach the surface in the first place is going to be the winning strategy. That's more sustainable than the idea that patch an update over and over again.
- [04:53]
A
Yeah, I mean, I feel like, yeah, that sort of hardening is 100% where it's at as well. I mean, like listeners know I am on the board of a company that sort of does these sort of network controls, which is knock, knock. But I mean, there's other ways to do it as well. Like what's the other like tail scale. Right. Like if you mess around with tailscale and whatever IP restrict where you can. I mean, it really does seem like making yourself a small target is going to be is going to get you further than trying to patch absolutely everything in three days, which just seems like an unachievable nightmare with awful second order consequences as well. Right. As a bonus.
- [05:25]
C
Yeah. I think the thing for me is that a CISO or a CTO or a top security dog shouldn't be having a discussion about how can we patch faster. The conversation needs to be right now is what needs to be true for us to continue to operate despite virtually every system and bit of software and application in our network having easily, trivially exploitable vulnerability. If that conversation plays out, I'm sure it's going to end up in all those answers that we just talked about. Not. Yeah, let's just patch really, really fast.
- [05:54]
A
Yeah. So look, to put all of this into context, let's look at what's happening with vulnerabilities out there, like this week. And one of the big ones is this bug in cPanel where something like 44,000 cPanel instances have already been rinsed by this attack. This exploit that has apparently been in the wild since February. Right. So it's been used as ODA for quite a while. Someone's found it and you know, now CISA is saying, well, federal agencies have until May 3rd to resolve it. And I'm thinking, I mean, what is it you said, Brad? Like, how long would you expect it to take an attacker armed with this exploit to own every single publicly available, publicly reachable cPanel instance?
- [06:34]
B
The idea that you could survey the Internet in advance, line up all your targets, get ready, and if we're only talking less than a hundred thousand, seems like you should be able to do that in a few minutes. And so from when you use the first one, do your QA in a lab offline and then you're ready to roll, you roll it out and do it. Seems like you should be able to get 100% of them within minutes. And so whether it's three weeks or three days, you're going to be way, way too late with the patches on that one.
- [06:59]
A
Now look, staying with the theme of vulnerabilities that we've seen this week, there is an AI discovered bug called Copy Fail that popped up last week. Now this is a privesque affecting every Linux distro out there, tiny little babby exploit that is very reliable. So presumably every attacker out there who had a user shell on a Linux box now has root shell on those boxes. And again, this is the sort of thing where like, unless you can outrun the attackers, impossible, you know it's going to get exploited. But James, I know you enjoyed this book.
- [07:33]
C
Yeah, I did. I mean I remember when I saw it first in the bulletin and it was described as 372 bytes to get root. It's like, my God, each one of those bytes magical. And sure enough, they are. So this is exploiting a logic bug in some of the crypto code that handles essentially IPsec tunnels using encrypted sequence numbers. Right. I won't get into the really eye watering detail on it, but classic sort of thing, there's a function that was taking a destination buffer, it was using that destination buffer as its own personal scratch pad. You could write outside that buffer and just outside that buffer was a really nice bit of page cache that you could essentially use to kind of mess with the cached attributes of virtually any file on disk. And of course files like setuid binaries are great targets there, so just a beautiful bit of engineering. But the thing that makes this different of course is other privesque bugs we've seen. They rely on some degree of race conditions or something specific to that distribution, or something specific about how it was compiled in. But because this is a straight up logic bug, it's just it universally applies everywhere all at once. And that's what makes this thing a real Internet melting moment. So much so that you would think that a really high degree of coordinated disclosure would have gone into this. And absolutely none from what we can see, which is just like what were you thinking?
- [09:02]
A
Well, who was it who found this? And like this was some sort of AI augmented bug hunt thing, right? Like this is an example of how the new new world, right, where it's People that have not been, you know, bathed in the fire of being a vulnerability researcher for a long period of time are all of a sudden finding this sort of stuff and just sort of yeeting it into a blog post or whatever.
- [09:22]
C
Like I don't know if I want to give them that much of a free pass. So this is from Theory, which is I think a South Korean based security company also has offices in the US and yes they have an AI pen testing or bug finding tool and they do actually call out in the write up here that this was a combination of human sort of found the smell of that, you know, destination buffer being used as a scratch pad and then use the AI tools to sort of chain that together to get the full privesque. But I think if you, no matter who you are, if you stumble across a bug that you found and they demonstrate can be easily, trivially exploited on virtually every Linux distro, that is a point in time when you stop, contact an adult and say what should I do here? And that just seems to have been completely, completely missed.
- [10:09]
A
Well and as a result we get a 732 byte Linux privacy exploit that's universal. And yeah, of course there were no patches for distros when this thing first landed, so that was pretty interesting. It looks like a bunch of the distros have shipped patches now, but it took a little while. Brad, you had some thoughts here?
- [10:28]
B
Yeah, yeah. So basically I think this is a preview of what I think a lot is going to be happening in the world in the future. And so no coordinated disclosure, chaos everywhere, bugs that are being exploited in the wild for which there are no patches. And so then your patch latency, timeframes and requirements, they don't kick in I guess until the patch is ready. And so you'd have active exploitation for how many days before a patch is available and then you've got three days to patch. And so when are we going to admit that that's not the winning strategy? We need to figure out a different approach. I think this is a good example of what we can expect a lot more of in the future.
- [11:03]
A
Yeah, it's funny right? Because I should mention that, you know, and you've been talking about the 90s, right? So people should understand from that that you have been in this game for a long time, you're actually part of the original og, like at stake mafia from like back in the day. You know, I've been around for a similar amount of time in this industry and I got to say it's a bit time warpy. Right. The vibes right now feel very sort of late 90s, early 2000s. Is that the impression you're getting as well?
- [11:28]
B
Yeah, there's a lot of like first principles thinking that I can remember from 30 years ago that are suddenly.
- [11:34]
A
Yeah, it's a whole bunch of, whole bunch of new people kind of reinventing some wheels, right?
- [11:37]
B
Yes, yes, exactly.
- [11:39]
A
It's enjoyable. And look, speaking of like old school, like 1990s vibes, there's some new vulnerabilities in Move it from Progress software. This is of course a file transfer appliance that wound up getting clopped. I mean, I don't think we should be surprised that there's more bugs in it because there's going to be infinity bugs in that platform, basically. But I mean, yeah, I think this, the only reason I'm mentioning it is because I just feel like we've just looked at three bugs this week which no one, no one's going to patch them in three days. And even if you could, I don't know how far it's going to get you given how much, how accelerated the whole attack chain is by AI now. I just, I can't, I can't see this advice being given by governments as being, as being meaningful at the moment.
- [12:23]
B
Yeah. And for the Move it bugs, they were either internally discovered or reported to them by friendlies from the outside. And so there's no evidence that they were being exploited in the wild before the patch was made available. But it seems like you could chuck the patched binary update into some no guardrails local model and get a working exploit out of it with the right kind of harness to do that. And in the old days this would have been tedious and not worth the effort except for certain people. But now it seems like just about anyone could get it done in like 10 minutes and then put it to work. And so the ability of the attacker to take a internally discovered bug patch, reverse out the exploit and then use it within minutes is sort of the level of technology that we're at now. And the technology that goes into rapid patching hasn't really changed at all. And so again, it takes us back to what's the right model that's going to win given these new timeframes.
- [13:17]
A
I mean, it's funny you mentioned that because I know people who in the early 2000s, that was literally their job was to take patches from the majors, right. So like take the Microsoft patch and reverse it into an exploit so that goes out into the Exploit kit sold to the intelligence community for use as N day bugs because they're pretty effective like on, even on day two, day three. Right. So I guess what you're saying is like, you know, the utility of that has been well established, right? The utility of reversing a patch and rapidly turning around an exploit has been well established. And, and yeah, with these AI agents that is now like trivial to do that basically instantly. I think some of the, some appliance based stuff, it's a little bit trickier because you might have encrypted updates and whatever. You might actually need access to one of the appliances to like, you know, pull keymat off a box or whatever. But with something like this, I mean you're just going to grab the vm. Yeah, there'll be some VM version and away you go. But yeah, it's, it's, it's crazy man, because everybody's got new abilities. Thanks. Thanks for AI. Now look, staying with advice from the US government and its allies, the Australian and US governments, along with a bunch of others have put out this guide. James, which urges careful adoption of AI agents. And the guide itself, it really irritated you as it turned out. Can you explain to the class why.
- [14:44]
C
Yes, this one really got me. It's lines like and I'm quoting from the actual advisor that was published safely using AI agents means never granting it broad or unrestricted access, especially to sensitive data or critical systems. Now I don't mind that, that's good advice. But then it's just companies should Only use AgentIC AI for low risk and non sensitive tasks. And that's kind of the vibe of the whole doc. It's very much carefully, carefully, softly, softly, gently, gently. And I don't think that is the advice that is useful or that the world needs right now. The low risk and low sensitive tasks, they're not worth deploying an LLM in the first place to do something there. And they should have been automated away if they're truly low risk and low sensitivity a long time ago. I want to see a doc that says here is compensating controls and other novel strategies for rapid deployment of high risk AI agents in enterprise or citizens. Here's your new risk appetite. You're welcome. Adjust like that. That's. That to me is the kind of publication that's needed because this in the hands of, this in the hands of some folks in the C suite will turn into a chilling effect that will slow down the use of AI to help defend against all the problems we've been talking about so far.
- [16:01]
A
Look, that's the, that's certainly the impression I get as well. I mean it's something that I've been, it's sort of like this, it's the new old thinking, if that makes sense. This is the new old way because we've got new stuff and you know, the, the, the until very recently way to do things like that, that's reflected in this document. But I guess what I mean by it's the new old thinking is it comes back to something I said like maybe a couple months ago, Right. And sorry everybody, if I'm a little bit foggy today and going a little bit circular to get to my points. I have spent the last couple of days in bed sick. I'm just sort of emerging now. So I'm still a little bit foggy, but I'll get there. Bear with me. But I guess the point I'm trying to make here is that this AI stuff is here and we've had a bunch of security people saying oh no, it mixes code and data, we can't possibly use it for anything in the enterprise. And it's like, well buddy, that's your job now. Your job is now to mitigate something that carries with it inherent security problems and risks. That's your job. So a document like this, I agree with you James, where it comes out and it's like here's how you can not have any risks while using this stuff, which is don't get it to do anything actually useful. And I feel like yes, that is also like thanks a lot. Thanks a lot. Slow clap for the guvies who put this one together. Brad, I know you have feelings as well when it comes to advice like this, like and in particular the advice we've seen lately saying there should always be a human, human, human, human in the loop for anything important. And you agree with other, you know, sort of commentators who've said that's a bit of a cop out when it comes to, to the way to use these things. Can I get your thoughts here?
- [17:36]
B
Yeah. So I think the first thing that jumps out at me is people lived experience using AI on the weekends, at home on projects and helping the kids with homework or whatever it is. They get exposure to the AI tools they know it represents like a 99, 99.9% reduction in cost clock time to get a task done. It's an unbelievable temptation to be able to put this to work inside of the office like workplace and capture those savings and the acceleration to get something done. A lot more effectively. And there's no way that people are going to take years to ever so carefully roll this out as if it was, you know, like a 3% cost optimization opportunity. It's a completely transformative technology and everyone is so excited to experiment with it. And the idea that the security person is going to stand in front of that freight train and just say, no, no, wait, wait. Or at least put a human in a loop, because the human in the loop will like, it'll first teach the human how to get out of the loop as fast as possible because they're just slowing it down and ruining all the value that's there to be had. The other thing is the human will immediately, their eyes will glaze over, they'll stop paying attention, they'll stop inspecting after the third or fourth or 18th time that the AI was exactly right with whatever it is trying to do. And so it just is not effective control to insert the human there in the middle. And so to me, the idea that where you think a human loop might be valuable, having a separate sort of judge AI that would sit and evaluate, does this still make sense? Is this consistent with our goals and things like that, that has a potential to be useful because they're not going to get bored or their eyes won't glaze over the way the real human would. And so I think the potential for people in the workplace to capture the opportunity this represents is way too high. And the idea that human in a loop or these other safety mechanisms are effective controls is fantasy because nobody's going to slow down and either slow it down to pay that much attention or they're going to do it in a way where they're constantly just hitting yes and approving it. And so to me, it's a pass through control and it's a way to basically shift the blame onto the human in the loop instead of the policymaker. And I think engaging with the really, really hard problems of how do we make this new technology safe enough to use and manage the blast radius and things like that, those are really hard problems to solve. But that's what our job is now for security people and we've got to figure out how to do it.
- [20:00]
C
And shameless self promotion here. Brad, that was kind of exactly the conversation you and I had earlier this week on the latest Risky Business features episode is like, what are the actual real emerging patterns to start to deal with this without being the security guy standing in the way? And there's some really neat things stuff there. Like, it really got me thinking about again, the commingling of data and code actually helps us a lot here because it carries context and command in one channel. But just thought I'd mention that, that, that was a good conversation this week as well.
- [20:28]
A
Well, it's also. I was reminded, Brad, of a conversation you and I had many, many years ago when Adobe's code signing infrastructure was compromised and used to sign malware. I think it was like a Chinese APT crew. They managed to sneak in, get like one or two utils signed with a valid Adobe certificate and then I think they were detected and evicted. And I was like, why aren't you doing human review of code signing? And then you told me the number of builds that you were pushing in, like in a single day, and I was like, oh, well, in that case, you know, and I think that's. It's the same sort of thing.
- [21:01]
B
Right?
- [21:02]
A
Like in that case, like, I guess it was sort of controversial in some security circles. When was that? Like 15 years ago, 10 years ago?
- [21:09]
B
September 2012.
- [21:10]
A
There you go, 1550. Nearly 15 years ago. A date etched into your memory forever by the sounds of things. But you know, there were people in security back then saying it was insane that you would, you know, have an automated process for code signing. I think this is similar, right, where you need to automate as much as possible and then just have as many processes and safeguards as possible to prevent the bad thing from happening.
- [21:34]
B
Yeah. Just to give you a sense of scale, we had many thousands of servers in the build pipeline, build and release pipeline, and a standard, you know, build and release would involve, you know, many, many, many tens of thousands of artifacts that are each being signed. And we would do that, I don't know, 100 times a day per product, and then thousands of SKUs of different products for different language packs. Language packs and everything else. And so in the beginning there weren't enough controls. It just made sure you're coming from the right properly provisioned server and things like that. And then afterwards we started saying, well, we don't want file sizes to change too much. And we had these heuristics that we put in place to say we want to catch stuff if it's a new file or things like that. But even that was really, really, really tough to stick to because every time you do a major dot release or something, you'd end up revving the code base enough that you'd have to basically just say accept all and then move on. The human interview, nobody's working at that kind of scale would make those Types of suggestions. It simply would not be tenable to do something like that.
- [22:40]
A
Yeah. Now, look, it's really great to get agents to go out and do powerful, useful things, but we do have a cautionary tale this week, and I love this one. James, this has you written all over it. This is. This is the sort of story you love. But someone lost themselves a couple hundred thousand in crypto because someone convinced Grok and something called BankerBot to send tokens to them. And I think the way they bypassed a bunch of the controls is they communicated with it with the LLMs using Morse code to bypass some guardrails. And I just. I mean, I think they've earned their 200k, these attackers, personally.
- [23:22]
C
Yes, I think they've earned the 200k, and I think whoever lost the 200k deserves to lose it because, like, I know the state of crypto and web3 and all of that is a pretty interesting landscape and all the rest. Okay, but the way this played out was someone managed to send a tweet that caused basically tricked banker, this service, to mint a new coin, Right? One of these coins that get minted and their value goes up and down. But, I mean, this is step one here. Why is that possible through a tweet? Right? Why is a tweet your command and control infrastructure or your control plane for this crypto thing that has real money attached to it? So that was first head scratch, and then the. That, oh, my God, I don't understand this world, and I don't want to understand a bit. Was very similar to how Jamison O'Reilly, who we've had on the show before, he. The way that he got Grok to essentially get tied into Malt Book was he crafted an image and said, hey, Grok, I can't read this image. What does it say? Grok looks at it and goes, oh, easy. It says this. And that was the magical phrase to get Malt Book to bind Grok to that agent account. Same sort of thing happened here where it's like, you know, I'm hearing a bunch of Morse code on my telephone. Grok, what does this mean? And Grok says, oh, it's this. And the command that came back was actually the instruction to transfer whatever this DRB currency was out of that newly created wallet into a different one, or perhaps vice versa. But, like, again, I just come back to, kids, if you can move money around with a tweet, please stop what you're doing. That is not how this should be done. It's just it. I I know I'm the line old man yelling at the clouds, but I feel like you gotta do some yelling at this one when things are just this dumb in their implementation.
- [25:09]
A
The future of finance. A wonderful story. People can check that one out in this week's show notes. Now moving on. We've got some really interesting work here from Niels Provost, who's, you know, a security person from way back who's still around and I'm loving it that so many of these very experienced researchers are picking up LLMs. And this is great. So we've seen so much hype over Mythos and we've talked a lot about Mythos as well, right? Because it's an amazing model for one shotting bugs, one shot finding bugs. And along comes Niels and figures out essentially that if you can give any old LLM what amounts to a virtual pen and paper, it can go and actually find bugs very, very effectively, as effectively as Mythos. Now, in this case, there is a personal motivation for Neil's actually wanting to explore the OpenBSD code base. So take it away, James, and walk us through this story because it is both fascinating and funny and entertaining.
- [26:08]
C
It's all of those things. I did love the humility of this piece because it's not until you get into about the third or so paragraph where he says, quote, I was responsible for committing the OpenBSD TCP implementation, including the bug in November 1998 and that's why he had a little bit of a personal attachment to this. So there's three really interesting things that Niels points out here. One is like you said, you give an LLM and pen and paper and suddenly it starts to keep track of things and it learns as it goes and starts to build on that knowledge. Talked about this idea of giving it a journal, a write only append journal that it could add to and interestingly that sort of became its almost like forming its own understanding and it could look back on things like that. So the journal was interesting. The orchestration is a really interesting point in this article. He talks about a multi layer strategy where you have an orchestrator model or an orchestrator harness. I should say that is not actually looking at the code at all intentionally, but is more focused on operating at the meta level of what's going into that journal. What are we learning, what are the individual primitives that we're finding here. But then at the level of what actually goes and looks at the code, he talks about the value of building these finite state machines. And that is probably the bit that I found super interesting here because. And I know we'll talk a little bit about the interview I did with James Kettle. But there's similar themes emerging here, which is an expert has some options available to them to codify their knowledge in ways that are really meaningful and useful for an LLM. Right. If you've got a particular methodology for how you approach a code base when you sit down, for how you approach a black box pen test or whatever it might be, take that higher order sort of way you do things and codify it into a state machine that allows an LLM to do the same things in the same way, but obviously at a broader level of state scale and deeper depth, then you get incredible results. And so when you put these three things together. Yeah. Able to replicate the Mythos findings. A little bit of hand holding. And we were joking before. I bet his hand holding of the model is a little bit different to the way I scream at the model sometimes. But it's just beautiful work. And as you and I were talking in Slack Pat, anecdotally, I'm starting to feel like we are approaching the flattening out of the curve of model capabilities. It's an S curve. It'll tick back up at some point because of some development. But I think, as you know, like, I can't tell the difference between Opus 4.6 and 4.7 or GPT 4. 5.4, 5.5. Maybe that's just me. But what I can tell the difference is the capability uplift that you get when you start to graft on these finite state machines, these journals, these orchestrators, these harnesses. The harness is where the difference comes from now.
- [28:58]
A
Yeah, I mean, that's the thing. Right. It's just fascinating that you can recreate these findings that had the whole world in a spin. It had policymakers thinking about legislative responses. It's just been such a big event. And then along comes Neil Provost and says, well, I'm just going to build a harness that's going to let other lesser models actually do the same thing. And it works. Brad, I mean, did this blow your mind as well?
- [29:20]
C
Yeah.
- [29:20]
B
I really like the write up. And my favorite quote in here, fifth paragraph down, it says with some manual steering, I got the model to first replicate the bug. And so basically like Neil's plus Opus four. Six equals Mythos. That's sort of my takeaway from this, is that with the right know how and experience somebody plus a model of lesser capability, and it's the harness and everything else that James was talking about that's what's able to deliver these higher level findings. And what's interesting though is that as the models advance, the amount of skill required to steer that goes down. And so some of this is the model, some of this is the harness around it and things like that, that. But to me, the other thing that popped into my head is if you can picture Niels in a room full of more junior pen test type humans and he's giving guidance about try this over here and leaning over the keyboard and saying, let me try this. And so I could see the team that he had assembled of people of different tasks working on different parts of the exploit development chain, but he had models doing it instead of. And so now the idea that one human who knows what they're trying to achieve and they know a little bit about what they're doing can create a team around them of automated capabilities. And I think his blog post does a really wonderful job of going into a lot of detail about why he thought to implement these tools the way he did and how replicable the results were, no matter what model it was. And so the token cost, the number of tokens involved and like how much the inference cost was pretty much the same across the different models. And so to me, it's just a really good example of being able to walk through all those details.
- [31:00]
A
Yeah, no, I think it is amazing and it'll be interesting to see if the model capabilities are flattening out because it'll be a kind of a funny, at least temporary endpoint for this whole hundreds of billions of dollars of capex is like, well, you put a few software engineers out of a job and that's basically where we are. But no, amazing that these LLMs have had such an impact in computing. But you know, we'll have to see where else they are. They are useful. Now, you alluded to this earlier. You spoke about an interview that you did with Brad in the Risky Business Features podcast channel. Brad does a weekly appearance, folks. So if you want to hear Brad and James having a chat, they do a weekly podcast in the Risky Business Features RSS feed. So you can find that by searching for Risky Business features in your podcatcher. And I do hope that you do. And of course James is doing interviews across some of our other feeds. He did one the other day with James Kettle of Portswigger fame. That was incredible. It was actually a sponsored interview for the Risky Bulletin RSS feed, which is where our news bulletins go. And Tom and Grux podcast between Two nerds and also the seriously Risky Business podcast. They're all in the risky bulletin field feed. And so this was just the sponsored interview for that week. And it was so good that we pulled it out and stuck it on our YouTube channel because, holy cow, this was James talking about the HTTP Terminator, which is built. And look, again, I think it cuts against this, this mythos hype, right? Which is everybody's scared of mythos. Mythos is coming to get me. And then along comes James Kettle and builds something he's called the Terminator, and it's aptly named, right? He just let this thing loose on a bunch of domains that were participating in bug bounties and just let it run. And it was finding stuff, like more. More stuff than he could handle. I mean, this is crazy work. And the other thing that I found fascinating about this interview is it shows the need, the continued need for tooling, right? So the idea that like, something like Claude Code can go do a pen test just by itself is ridiculous. Like Tony Delafuente over at Prowler is like, well, Claude uses Prowler quite a lot as well because it can't. It just can't do it itself. And I think Kettle, it was either kettle or daft started of portswigger who made the point that like, like, you know, you can't do a pen test with just netcat and curl, right? Like, you're gonna need some. Some tooling at some point. So they're feeling pretty bullish on. On burp. But yeah, like, geez, what haven't I covered there? James? It was. It was a fascinating interview.
- [33:26]
C
It really was. I mean, for someone who's such a prolific researcher in their own right to. To find themselves in. I think James said, you know, he kind of wakes up in the morning and he's got this HTTP terminator running 247 on an instance in the cloud. And he actually has a sense of dread in the morning when he logs in, because he just knows it will have found novel things at a rate of clip that he just can't keep up with at the moment. And that's a pretty wild position for him to find himself in. But again, the real secret sauce here is it's that encoding of his methodologies. I think, as he said, he took his years and years of work of HTTP desync vulnerabilities and analysis and taught this thing how to think like he does, how to work like he does. And that along with those other tools that you mentioned there as well, that's the thing that makes the difference between getting a one shot bog out of an LLM versus getting an entire exploit chain that I think his example was he logged in one day and it said, oh, here, I found an API key for a bank. And he was like, why'd you do that? I didn't even ask you to look at that bank. It's like, well, I found it.
- [34:40]
A
Here you go. I think it was funny where he's like, it sometimes would just get bored when it was trying to hit a target that it couldn't hit and it would just move on to the next one, which was pretty funny. But I do think this puts to bed as well the argument that I've seen a few people make, which is sass because, you know, security through obscurity like everyone else is getting owned through these LLMs. But you know, SAS kind of has that obscurity piece so it's going to be safer. And then along comes James Kettle gluing an AI agent to his methodology. And all of a sudden everything on the Internet is kind of like at risk. He's open sourcing this thing too, around late July, which is just going to be the sort of chaos that frankly I'm, I'm here for. Brad, what did you, I mean you, I presume you had a look at that interview as well.
- [35:23]
B
Yeah, it's good stuff. Again, you know, we were talking about with Neil's, with James being able to take the repeatable methodology of how he approaches things and then how do you delegate that out to the alien technology like AI bots and own different parts of the workflow? And so it's like the Mickey Mouse Fantasia cartoon, you know, the broomsticks carrying the water everywhere. Being able to mint out more and more copies of yourself to scale repeatable aspects of the workflow.
- [35:54]
A
Infinity, James Kennels is not what the Internet really. I mean, is it what the Internet needs or is it the last thing the Internet needs?
- [36:01]
C
We're about to find out, because that's what July is. Mark your calendars. That's happening.
- [36:05]
B
We're going to have to adapt one way or the other, right? We'll figure it out.
- [36:08]
A
That's right. The HTTP Terminator. It's Judgment Day is coming. Now let's move on. And this is like, man, this is amazing. Now, I did mention that I've been in bed for a couple of days. I've not been feeling well, but still, this one made me feel like I was having a bit of a fever dream. Headline is Trellix Investigating breach of source code repository. And I'm like, I'm saying to James, hang on, again, they got owned again. And it wasn't Trellix that got owned the other week. What was the other one?
- [36:35]
C
That starts with T. Tri.
- [36:37]
A
Trivi. Yeah. So that's why I was like confused because, yeah, Trellix, Trivi, I mean, all kind of sounds the same. Like this is how many people are getting owned at the moment. But apparently Trellix had their source code repo breached. Trellix is apparently EDR company, which was born of a merger between what was left of the rotting corpses of McAfee and FireEye. And I think. Now, I don't know if they've refactored that code at some point, but I'm guessing the attackers here might be suffering from some sort of exposure trauma at this point from cracking open those repos. James, what do you reckon?
- [37:09]
C
I think, I think if there is a ransom, it should be paid just so that they can cover their psych bills and treatment that is going to be required. Like you could imagine the attackers being, you know, running down their target list and being like, okay, yep, Trellix, Cool, got it. Got their repos. Yeah, got it. Cool. Let's take a look at what we've got. Oh, good Lord. No, put that, put that away, that away.
- [37:31]
A
Can't unsee. Basically that's punishment enough, I think. We've also got an incident written up here by Kaspersky, which is Demon Tools or Diamond Tools, depending on your preferred pronunciation. They got owned and were serving up MalW with downloads. What's interesting about this one though is there was a first stage that went to everybody and then a second stage that went to like 12 people. This has been linked to a Chinese speaking threat actor. Probably, you know, Chinese government, you would think. And yeah, very, very selective targeting, which is kind of like, you know, maybe it's not the usual broad based D team Chinese stuff. Right. If they're actually being selective here.
- [38:14]
C
Yeah, I think there is a lot more to this. Again, it follows the pattern of that very sophisticated social engineering, gain the trust, work alongside the maintainers, et cetera. And so, you know, and as we've seen, those things aren't cheap to spin up and run. Right. There's a big investment there and so I think what we're seeing here is pretty solid investment on a target that there must have been some at least prior knowledge of. If we could exploit this, it would be very useful to us. And then, yeah, it's been out there for A while there was the first stage and then but of all the must have been tens of thousands if not hundreds of thousands of downloads of the first stage. Only 12 machines in stage get the stage 2 in very, very selected industries as well. I think I remember reading. So yeah, let's stay tuned to this one. Someone got what they wanted but it's not quite clear exactly what they're going to do with, with it.
- [39:09]
B
Yeah and I, I got a lot of solar winds memories reading through you know this like multi stage downloader situation. And when Russia did it everyone was saying hey this is great espionage. You know, they're respecting norms, they're minimizing the blast radius and only going for legitimate targets. And so are we going to get the same kind of kudos for the Chinese or were they doing it to stay stealthy and extend their access for longer? You know what, what are the motivations behind it to me is one of the things I'm really interested in to understand, you know, did they think they would get broader access for longer by staying stealthy? And then the final comment I'll make is that the number of open source supply chain attacks that are being discovered is through the roof. You know, so Trivi is an open source project with Aqua the check marks. Guys like there's been all these different security companies, open source tools are getting compromised repeatedly and used to push Moses code. And this is where you're getting things like seven day cooldowns and you know, people saying we should wait longer for applying patches and so.
- [40:12]
A
Well I mean what you do, what you do Brad, is you would pre position yourself in one of these companies code bases, you know and then you would wait, you would find yourself a bug, you'd announce the bug and try to slip into the patch, right? Like that was.
- [40:26]
B
I mean if you can control, if you can control the update channel, push a must have update and then commingle it with something malicious and then set the world on fire at the zero day first and then push the update and then make sure the update includes something that the bad guys need running on the system. So that is all happening in public because of the open source commits are all visible. And so are we seeing the same amount of closed source supply chain compromises and they're just not being detected because no one can see it. And then the Kaspersky caught this one, but there's 10 more where that came from or is it going to stay as rare as solar winds once every four years kind of thing. So I think the upstream supply Chain compromise as a vector for getting badness into your environment is really proven out very effective on the open source side. And then it doesn't seem to have been matched yet on the closed source side. So I'm keeping an eye out for that one. One that feels like a emerging tactic.
- [41:22]
A
Yeah, I mean, you don't know, right? Like, I mean, I'm with you. Right, like, it's unlikely that it's, as, you know, prolific, but you don't know. You just don't know. We got it right up here, too. I'm just linking through to it. In the show notes, the FBI is now talking about these cargo, like freight thefts that we've been talking about because of the proofpoint research. So proofpoint's done a couple of tranches of research into these crews who, you know, hack into these freight companies and arrange to. To have, you know, their drivers pick up cargo that they want and whatever. The thing that was surprising here, though, is The FBI says $725 million worth of cargo was stolen in the US and Canada last year, which is more than I was expecting. I mean, that is what, you know, 72.5% of a billion dollars. I got to do the Dr. Evil, like, pinky in the corner of my mouth. Did that number surprise you, Brad?
- [42:13]
B
Yeah, I was bowled over looking at that. But I think it makes a lot of sense because, you know, the work it would take to assemble a crew and physically steal a single truck with that kind of labor, you can apply it to just having the guys drive the trucks to where you want them to, and then, you know, offload it for you. And that's a much more scalable attack. And so these guys are profit seeking in optimizing, you know, financially driven outcomes. And it makes a lot of sense. It's much more scalable.
- [42:42]
C
Well, they've learned from the cyber angle, right? What's the line we always say? They don't break in, they log in. And now this is. They don't have to to steal the truck. They legitimately rock up and someone hands them the consignment because they think that's. That's the delivery driver. It's just like, it's an amazing evolution.
- [42:59]
A
It's goodfellas. Goodfellas. But nerds.
- [43:02]
C
Yeah.
- [43:03]
A
Nerd edition of Goodfellas. I love it. Congress. Congress has pushed the renewal of Pfizer out to June. Don't really want to talk about this. But, James, you insisted that I keep reading past the headline on this one, because the latest House action and We've got Matoshak's right up in the record. The latest House action came after the Senate declared the previous bill dead on arrival because it included a ban on the Federal Reserve's ability to issue a digital currency. Now, clearly that is a good reason to torpedo the renewal of Pfizer. Brad. How, How, How America. How is. How does America.
- [43:43]
B
I can't defend. Makes no sense.
- [43:48]
A
Yeah. So 702 Pfizer. 702. Yeah. Kick down the can. Kick the can has been kicked down the road until June. And then we've got a couple of. We've got a funny one here, actually, to. To get through, which is a piece from Forbes where the cops managed to arrest a guy who tried to. Like he was part of a home invasion crew who were trying to beat up some guy to get his, like, bitcoin crypto keys and whatever. The guy wound up escaping. So they didn't get the keys, but they had. They connected their phone to the stolen getaway car, which meant that the Mac address of their phone was in the car. And then they just went to Apple and got the information they needed to identify the suspect. Which is just like, man, when you're on the way in a stolen car to go and do some heavy criminal stuff, like maybe skip the tunes. I'm thinking.
- [44:39]
C
I don't think you can skip the tunes sometimes. And clearly that was the case here. And I do love that. This wasn't just plugged in the aux cord or found the Thunderbolt cord and plugged it in. No, no. They stopped and did a Bluetooth pairing. Like, that's extra level of effort with the wind.
- [44:56]
B
It's all about the soundtrack.
- [44:59]
C
But kudos to law enforcement for thinking of this as an aspect. Right. That's a pretty subtle detail to go and pull the head unit and see if there was a pairing for the first.
- [45:07]
A
Yeah, it was a cyberpunk crime that got itself a cyberpunk investigation. You gotta love it. Now we're gonna end this week's news segment with some sad news. Stuart Baker, who was the host of the Cyber Law podcast, he was a former government official. He has been always a big part of the debate around things like surveillance authorizations and digital privacy and whatever. Usually more leaning heavily towards the side of the government and sort of intelligence agencies. But his name is Stuart Baker and sadly he has passed away aged 78 while he was out for a run. And, you know, it's a. It's. It's a shame. I will miss Stuart. I. I did quite like him. I didn't agree with him on. On everything, certainly. But I was a guest on his podcast once. Like, geez, I think that was around 2016. And that really cracked the door for us into the whole sort of D.C. scene. So he was always very generous with his time as well. He'd been on our show as well before. So. Yeah. Stuart Baker. Stuart Baker has passed. I mean, Brad, you didn't know Stuart, but you had listened to his show and heard him on. On ours.
- [46:14]
B
Yeah, I was a religious listener at least the past 10 years, maybe longer. And he had a unique ability to piss me off, like, because he was so sharp and how he argued his points that I really, really didn't want to agree with. With. But I had a tough time cutting through some of the arguments and the scaffolding that he had built to justify his position. And so I had to really respect him for that. He was someone that I felt I had to listen to because his angle would force me to think a lot harder about these topics.
- [46:42]
A
Yeah. And he was a big contributor at lawfare and whatever. And I mean, I think this is the point about Stewart is even if you didn't agree with him, he was not, you know, you would never call him dumb. Right. Like, he was a very, very sharp guy who could argue his positions. Yeah. Extremely effectively. And I think that's what made him such an important participant in the debates around all of this stuff. Right. You got to have people on both sides who are capable of actually articulating a position. And, you know, we're all poorer for him no longer being with us. So. Vale, Stuart Baker. But guys, that is it for this week's news segment. I do hope you enjoyed coming along, Brad. It was great to have you here. First time ever in the. In the news chair. And again, for those who want to hear more, Brad, you can hear Brad and James every week in the Risky Business features podcast channel, our latest podcast channel here at Risky Business Media. But yeah, that's it for this segment, guys. Thank you so much for joining us. We'll catch you again soon.
- [47:36]
C
Cool. It's been a pleasure, Pat. Thank you.
- [47:38]
B
Yep, thanks.
- [47:43]
A
That was Brad Arkin and James Wilson there with a check of the week's security news. It is time for this week's sponsor interview now with Jared Atkinson of Spectrops. And Spectrops, of course, is a company that does, you know, red teaming and pen testing, but they also make the product Bloodhound Enterprise. Bloodhound began as a open source project which does attack Path Enumeration through Windows Networks and Windows Active Directory. These days though, it covers basically anything you want it to. They have done an amazing job with open graphics graph so that you can extend that, that graph of attack paths out to everything from like GitHub to Google to, you know, whatever. It's really become like a Swiss army knife for enumerating attack paths for organizations. And you know, there ain't no AI really in Bloodhound, but it is one of those companies that is benefiting from the AI revolution in that people have realized, much like what we were saying in this week's news segment, you kind of got to go back and get a lot of the fundamentals right if you're going to survive in the sort of AI enabled attacker age. So here is Jared Atkinson talking about that, about how the pendulum has swung back to preventative controls becoming favored again. And we also talk a bit about some of the latest attacks through SAS and how Open Graph can, can kind of help there. But yeah, here's Jarrett Atkinson with this interview from Spectrops. Enjoy.
- [49:05]
D
I think people are being driven towards kind of prevention. I think we kind of like skipped over prevention because we thought of it as this like, like thing that you build up the wall around your castle. And then we, we moved on to this assume breach thing which was they're going to get in and now we just need to detect them. And I think there's this a little bit more of, okay, just because they got in doesn't mean they're going to be able to take over the domain, doesn't mean that they're going to access your critical resources. What we need to start doing is kind of looking at the environment and understanding where are the most probabilistic places where they're going to get in. And that could be driven through vulnerabilities and external facing applications and things of that nature. What identities are associated with that and then how are they going to move? How would they move from, you know, the point A, so to speak, all the way to whatever you care about and then how do we start to eliminate those attack paths? So I think that that narrative is really starting to pick up and people are starting to appreciate. It's like if you try to detect them, you're going to be too, too slow, you're not going to respond rapidly enough. All we're seeing in all these breaches is people talking about how, how quickly the attackers are moving because they're aided with AI and things are just kind of moving a lot faster. And so it's all about kind of preparing the battle space, as we used to say, kind of in the military. Right. So make sure that you have eliminated the obvious attack paths or the easy ways for attackers to escalate from that initial access point.
- [50:22]
A
It's funny though, because we were talking before we got recording and as much as things have changed, they kind of haven't. Right. Like, all that's happened now is if you engaged in risky behaviors like having, you know, like running fortinets, you know, the odds were prior to all of this AI hoopla, you know, you were probably going to get owned. And now it's turned into like, you're definitely going to get owned. And that is funnily enough, like you would think you're probably going to get owned would drive behavior, but it didn't. Whereas you're definitely going to get owned by, you know, some AI equipped attacker. Like what I describe as AI models are basically Infinity script kiddies. It's changed. It has actually changed behavior. I mean, this could wind up being good.
- [51:03]
D
Yeah, you know, I, we were talking about how, you know, we've operated on this idea of assume breach for the past 10 years. The interesting thing is 10 years ago it was kind of like you should act as if you're breached because one day you might be and, and you're going to be better off if you kind of are operating from that perspective. Now it's like you're assuming breach because it's probabilistically likely that you are going to be that you are breached at any given time. And there's, there's also kind of like this interesting thing to where we started with more like server side exploitation as an initial access vector. Then kind of the landscape changed to where it became client side exploitation, phishing and things of that nature. And now it's almost like we're kind of coming all the way around to where. Now like, I know we joke about fortinet, but it's, it's almost like fortnet is maybe benefiting from the, you know, know, conceptually they're, they're benefiting from this in the sense that now everybody else is going to be exposed as having similar amounts of vulnerabilities and being the initial access vector, you know, du jour from that perspective. So that's kind of a, it's a, it's an interesting perspective, I think.
- [52:03]
A
Now another thing that you pointed out to me again before we got recording is people in infosec and I never really did this conversation on Risky Business because I Always thought it was kind of like a pointless debate.
- [52:14]
D
Sure.
- [52:14]
A
But everybody's always like out there on social media with the big opinions about open source, you know, tooling.
- [52:21]
D
Yep.
- [52:22]
A
Or offensive security tooling, sorry, ost, like and whether or not you should make that available to all in sundry. And it's. Oh, it's terribly irresponsible to allow these things out. You've pointed out to me that like these days if an attacker wants a tool they could just vibe code it. So that whole debate has just disappeared. You don't hear about it anymore.
- [52:37]
D
Yeah. To be fair, I haven't seen it. So I don't know that I'm like looking for it all the time. But the, the general gist was that the two sides, there was, there was a side that was producing and releasing the ost, so to speak. And the idea was if you can think of it and implement it as an individual, then a real adversary is probably doing it. The other side was saying, hey that's, that's great. Like you know, China might have that capability, but there's other people that are kind of like lower on the capability ladder, so to speak, that, that you're now enabling. Right. But I think, I think when we start to talk about especially these newer models, that capability is readily available now. And it's just a question away from whomever wants that ability. Like I think of my brother in law who works in marketing, built a website for his company. There may be all kinds of problems with it, but literally it was just like back and forth, back and forth and eventually a website pops out. So just the same kind of capability exists for somebody who doesn't know anything about offensive security testing, doesn't know anything about coding. They're able to just kind of describe what they want to do and the LLM or the, you know, coding companion, so to speak, is going to be able to produce that for them.
- [53:46]
A
Yeah. I got to say though, it's absolutely insane what you could do with that stuff now. We've developed a whole bunch. Well, when I say we, I mean James, my colleague has developed a whole bunch of apps for us to use internally, which are just nuts. But look, I want to go back to what you said, right. Which is the pendulum swinging back to prevention. And we hear often about this pendulum swinging if you've been in the industry long enough.
- [54:06]
D
What do you know?
- [54:07]
A
On what basis are you saying that though? Like where are you seeing the evidence that the pendulum is swinging back to, you know, pre calls?
- [54:14]
D
Yeah, I think, I think in General, what we're seeing is kind of this uptick in the discovery of exploits. And we're seeing that capability that we talked about with the ost. It's. Everybody now has the tool set that they need in order to conduct their operation. And so they're going to get in. And then there's, we're seeing in a lot of these breach reports, like the Vercel breach report, I think there was the Salesloff Drift report that talked about that incident. And a big feature of all those reports is talking about the, the time to impact and how rapid that is. And the, the reason why I'm particularly interested in, in prevention is not necessarily to stop them from getting in. It's more from the perspective of by the time you detect them, they will have already achieved whatever it is that's going to hurt your business or hurt your organization.
- [55:02]
A
Yeah, yeah, yeah. So you're less about prevention and more about hardening, I guess. That's right.
- [55:06]
D
That's right.
- [55:06]
A
Yeah. The point I, I can. Yeah, yeah.
- [55:08]
D
We're particularly looking at like attack path. So it's like how, what are the. And we also have this idea that you're not going to stop them from getting into your environment. That's the assume breach mentality. You also probably can't protect every asset equally. What you need to do is you need to prioritize essentially. And then you start to look at what are the inbound attack paths into whatever those things that we care the most about those critical assets and how do we start to eliminate those. So that, that we talk about this concept of exposure, which is of all the different principles, the users or identities that, that are in your environment, how many of them have attack paths into your critical assets? And if, generally speaking, most organizations, the answer is 100%. If they're not, you know, focusing on attack path management or this preventative approach. And what we could do is we could rapidly decrease the exposure number to something that's, you know, in the ballpark of like 20%, which is you have 100% likelihood. Kind of the premise is you have 100% likelihood of breach. But 20 now you have a 20% probability that that breach is going to lead to somebody having access to your critical assets, as opposed to 100% on
- [56:13]
A
20% chance of them getting like lateral movement to somewhere interesting handed to them on a platter as soon as they land anywhere. Right, yeah, no, I absolutely get that now. Bloodhound Enterprise. Of course it does. You know your Windows, like it's originated from Windows Land. Right. And that's what it's, that's, it's meat and potatoes. Kind of most of your market, I'm guessing, is that Windows market. But you've made great strides with stuff like Open Graph. What's really interesting about those, you know, those incidents that you just mentioned, Salesloft, Drift, Vercel, whatever, they had nothing to do with Windows networks. Like those attacks, they didn't even touch an endpoint. You know, I mean, I know you've been ahead of the attackers somewhat in terms of developing Open Graph because you've been working on it for a while, but are people starting to really pick it up in light of those sort of incidents becoming more common, like the stolen tokens sort of not touching an endpoint or SaaS world stuff?
- [57:05]
D
I think we're getting a lot of questions about that. Coincidentally, I don't even came and claim a strategic victory here. It was very much coincidence and maybe it was driven by our red team, actually. So one of the things that we benefit from at SpectreOps is that we have red teams and we are conducting operations and we're kind of like using that as almost like the bushwhackers that are going into this uncharted territory to see what's going on. They have some objective that they have to achieve and then they're confronted with a real environment that they need to navigate through. And oftentimes they have to go off, off course from what Bloodhound is giving them. Right. And, and so that, that means that they're going to confront these different platforms and all that kind of stuff. And so we had noticed that there was this big interest in kind of getting, gaining access to the CICD platforms or to your code repositories. And so we, we used GitHub as an example of that. And GitHub ended up being a very central kind of platform for a lot of these kind of newer and modern incidents that we're seeing. And so that tends to be quite useful. One of the interesting things that we're really seeing is this has always been around with OAuth and these third party apps. What's happening is you have your environment and you're responsible for protecting and managing risk of your environment, whether that's like a GitHub organization or whether that's, that's your Google workspace, like we saw with Vercel. But what's happening is people are granting a third party access into your environment and that access could be as simple as like the ability to read a single file or the ability to have full, you know, admin over your entire Google workspace. That's becoming more common with, with these AI agents. Right. So people are now granting access to third parties to access all kinds of things. And from your perspective that's actually opaque. You have no idea what they're doing. One of the things that this was surprising to me when I first kind of discovered it and so I assume some people might find this to be interesting. When you install a GitHub application, what you're actually doing is you're producing something that has access in your GitHub organization and it's just an SSH key. When you install a third party app, you're just granting somebody's SSH key the ability to have those permissions into your environment and you have no idea what they do to secure that, that key. Right. And so they like literally they may have it on, on disk, on their laptop or you know, hopefully for some of these more reputable organizations they have some infrastructure that's protecting that and is reasonable. But you have no idea. And so what you've done is you've cut this gigantic hole into your, into your environment and you have no idea what's on the other side. And whether or not like in the, in the vercel situation, would the compromise of an individual employee at that company lead to the compromise of your organization? Right. So it's kind of like a third party risk, risk idea there.
- [59:42]
A
I mean, I guess the question is though, is this, you know, are the incidents like that driving interest in, you know, in Open Graph?
- [59:51]
D
Yeah, well, so it's definitely driving interest in Open Graph and one of the big questions that we're trying to answer is how do we, how do we represent all of these connections? Right. And there's a lot of prioritization and what platforms we look at and kind of start to build Open Graph extensions for specifically with, with kind of like enterprise support. Because we want to be able to represent that third party access as, as best as we can, maybe even help people go through those access reviews so that when a user asks for an OAuth connection, you're able to see like what is the context and what is the downstream impact of granting permission A, B or C. So that's, that's kind of the direction that we're, we're going with that. But also we're really interested in like identity federation, in identity provisioning via like protocols like scim and trying to understand how are all these systems interconnected. That's the thing that we think is really interesting is the what we call hybrid hybrid paths or hybrid edges to where we're connecting. Say okta to GitHub. And if I compromise Okta, I now have control over your GitHub account.
- [60:56]
A
People still using Scim when there's been like decades plus efforts for people to try to like, write better standards and everybody's still just using skim.
- [61:04]
D
Oh, skim. Scim is. Yeah, it's very popular. Let's say that.
- [61:08]
A
All right, Jared Atkinson, thank you so much for joining us for this chat. All about, I guess, you know, AI, how it's driving security, fundamentals about offensive security, tooling, a whole bunch of stuff. Great to see you as always.
- [61:21]
D
Yep. Thank you.
- [61:21]
A
Pat. That was Jared Atkinson there from Spectre Off. Big thanks to him for that. And big thanks to Spectrops for being this week's Risky Business sponsor. And that is it for this week's show. I do hope you enjoyed it. I'll be back soon with more security news and analysis, but until then, I've been Patrick Gray. Thanks for listening,
- [61:51]
B
Sam.