
Cloud Security Podcast · 2026-06-23 · 39 min
Key moments - from our scoring
Substance score
58 / 100
Five dimensions, 20 points each
Simon Biggs from Varonis examines how AI is fundamentally changing the incident response and forensics landscape. Rather than enabling entirely novel attack vectors, AI is accelerating existing ones: attackers now craft sophisticated SQL queries within minutes of compromising databases, execute Microsoft Graph queries seconds after stealing tokens, and automate reconnaissance and lateral movement that previously required deep technical expertise. This mirrors the impact Metasploit and Bloodhound had in lowering technical barriers to entry. Biggs emphasizes that traditional security controls remain critical - layered defense, proper permissions management, visibility, and auditing - but organizations must now account for shadow AI usage, AI-discovered vulnerabilities in niche products, and the speed at which proof-of-concept exploits emerge. For defenders, the key is thinking like attackers: running AI models against your own infrastructure to identify misconfigurations (especially in Salesforce, M365, and CRMs), ensuring comprehensive logging of database queries and AI platform activity, and building automation since manual detection is impossible at scale. Varonis' forensics lab also discovered prompt injection vulnerabilities in Copilot, highlighting that the attack surface extends to AI platforms themselves.
Attackers are using AI models like Claude to generate sophisticated SQL queries within minutes of accessing databases, targeting payment records, PII data, and credentials without manual intervention - a capability that previously required nation-state-level expertise and is now automated at scale across ransomware groups.
No; AI is not creating entirely new attack types but rather accelerating existing ones and lowering technical barriers. Attackers are achieving outcomes faster and with less requisite skill, similar to how Metasploit and Bloodhound democratized penetration testing decades ago.
Varonis' threats lab discovered prompt injection vulnerabilities in Copilot that could allow users - potentially inadvertently - to access information they shouldn't have, highlighting new attack surface areas introduced by AI platforms themselves.
Organizations should focus on comprehensive auditing of database queries and AI platform activity, enforcing proper user permissions, detecting shadow AI usage, and building automated detection and response capabilities - traditional controls remain critical but must now explicitly account for AI-augmented threats.
Since AI can now efficiently research vulnerabilities in less-popular software that skilled researchers wouldn't target, organizations need broad visibility into all data repositories and applications, and should proactively run AI models against their own infrastructure to identify misconfigurations before attackers do.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains a solid cluster of practitioner insights - the shift from encryption-first to data-first ransomware, automated Microsoft Graph queries seconds after token theft, and AI enabling bedroom researchers to get proof-of-concept exploits - but is padded with well-worn points about logging maturity, data classification importance, and AI lowering barriers that circulate widely in security circles.
We're seeing queries coming in seconds after that token's been stolen. There's more people doing attacks and achieving outcomes without the requisite skill set that they needed
Five years ago, attacks predominantly used to be encryption first. Now is data first. Practically no encryption
The framing of AI as an accelerant rather than a revolution is a measured and honest take, and the shift to data-first ransomware is a useful reframe, but most of the episode confirms conventional wisdom rather than challenging it - the Metasploit analogy is apt but well-worn, and recommendations (log everything, classify data, run tabletops) are standard IR doctrine.
I don't think it's so much a revolution in terms of it's doing things that were just impossible. I think it's accelerating that process
somebody could get that in their bedroom if they can afford the tokens that's on the table. I think that's a bit of a sea change
Simon Biggs is a genuine hands-on practitioner with 15 years in forensics and IR, a law enforcement background as a detective sergeant on an organized crime team, and time at NCC Group - he has clearly worked hundreds of real breaches. The episode is sponsored by his current employer Varonis, which introduces some vendor framing, but his operational knowledge is evident throughout.
I've been in that space for about 15 years and started off doing cyber law enforcement. I was in the police. I, uh, finished as a detective sergeant on the regional organized crime team dealing with cybercrime
dealt with hundreds of breaches all the way up from business email to nation state and government agencies
There are genuinely specific practitioner details - SQL schema queries materialising in minutes, Graph API calls arriving seconds post-token-theft, S3 access logs being off by default, 72-hour contractual notification windows - but the episode is light on named breaches, precise statistics, or published research citations beyond a vague Copilot prompt-injection mention.
we're seeing pretty much all the groups. They will go after maybe your SQL databases, they'll be taking a schema, they'll be coming back and they'll be doing a really crafted query within minutes
S3 storage access logs on, um, on by default... the amount of people that are shocked when we say that there, there is nothing that will tell you what access that data
The host asks some genuinely useful follow-ups - pressing for a concrete speed example, introducing the Metasploit analogy to sharpen the point, and synthesising a summary checklist at the end - but also asks long compound questions, lets vendor claims go unchallenged, and relies on affirmations like 'awesome' and 'wow' rather than productive pushback.
when you say they're getting faster, what's an example of something that was, I guess probably a similar attack before, but now seems a lot more different with AI?
Is there a huge volume of security? AI attacks.
Computed from the transcript - who did the talking, and the words that came up most.
AI isn't necessarily creating impossible new attacks, but it is drastically lowering the technical barrier to entry for cybercriminals. In this episode, Ashish Rajan speaks with Simon Biggs, Cyber Incident Response Specialist at Varonis, about how AI is accelerating the attack lifecycle. Simon explains how attackers are using AI kits to instantly set up ephemeral phishing portals, query SQL databases in minutes, and bypass AI guardrails to compile Remote Access Trojans (RATs). We also discuss the shift in ransomware tactics from "encryption-first" to "data-theft-first," and how AI empowers attackers to post-process terabytes of stolen data to monetize it in novel ways. For defenders, the message is clear: if your S3 access logs and SQL transaction logs aren't turned on before a breach, your forensics team won't be able to tell lawyers or regulators what data was actually lost. Discover why data classification and proactive logging are the ultimate lifelines for IR teams in the AI age.
Transcribed and scored by The B2B Podcast Index.
Speaker A: These AI kits are out there and being used on mass. That suggests there's no hands on the keyboard.
Speaker B: Is there a huge volume of security? AI attacks.
Speaker A: We're seeing queries coming in seconds after that token's been stolen. There's more people doing attacks and achieving outcomes without the requisite skill set that they needed. Five years ago, attacks predominantly used to be encryption first. Now is data first. Practically no encryption doesn't matter where the data is. They will find where that data is very quickly. This information that's taken is going to be weaponized in new and novel ways.
Speaker B: AI agents and incident response. If you have been working in the incident response forensic space for a while, you probably already understand that, uh, traditionally, and when I say traditional, I mean before AI became a thing, we knew that we could get enough information from a cloud build. As long as we had the logs, we could build the, uh, entire footpath of. We could build the entire footprint of how something impacted the organization and what was the root cause of it. Of course, we can't do that without the logs. Now that's for another episode. But to unpack what incident response and forensic looks like in an AI world, I had Simon Biggs, who is a cyber incident response specialist at Voronis. He's been in NCC group before and has done a lot of forensics in the pre AI era and doing forensics in this AI era we live in. So we spoke about some of the changes that he has noticed in the field on how incidents have changed, how forensic has changed, how much AI is actually being seen out in the wild and what kind of AI incidents are there and if there truly are, uh, a lot of zero days can tell me he thought was destroyed in this particular episode. But all that a lot more in this episode with Simon on unpacking what incident forensics look like in an AI world. As always, if you have been watching or listening an episode of the podcast for a while and have been finding it valuable, I really appreciate if you take a quick second to just drop that.
Speaker C: Follow.
Speaker B: Subscribe whichever podcast platform you're listening or watching this on. We are on Apple, Spotify, YouTube and LinkedIn and wherever you consume your podcast from. Thank you so much for doing that. We're inching towards a goal of 200k followers across the board. So I really appreciate your support, support in helping us get there. I hope you enjoy this conversation with Simon and a, uh, huge shout out to Vedonis for sponsoring this episode of the podcast. I'll talk to you soon. Enjoy. Hello and welcome to another episode. Simon, thanks for coming on the show. Maybe just a quick intro about yourself, what you've done professionally. So do a handsome idea.
Speaker A: Absolutely. Simon Biggs. So I currently work at Varonis. I'm uh, on the forensics team, which is a team that helps our clients when there's a true positive breach. Uh, we use data from Varonis but also outside. So we're all forensic and IR experts. I've been in that space for about 15 years and started off doing cyber law enforcement. I was in the police. I, uh, finished as a detective sergeant on the regional organized crime team dealing with cybercrime. Moved into the private sector where I've been doing consultants. Lee IR dealt uh, with hundreds of breaches all the way up from business email to nation state and government agencies. So dealt with a lot, dealt with many breaches. And uh, yeah, here today.
Speaker B: Awesome. And I'm glad you've done this because I think one of the top of mind conversation for people, we're at Infosec Europe and one of the conversation that has been top of mind for people is that is there a huge volume of sophisticated AI attacks?
Speaker A: Sophisticated AI attacks. I think what it's doing is it's increasing the scale, the volume and it's low the technical barrier to entry. So I think in terms of how often is AI allowing a goal that was unachievable at all, like wasn't seen anywhere from nation state down, I don't think that's happening. I think it's making them easier. I think there's more people doing attacks and achieving outcomes without the requisite skill set that they needed five years ago. Yeah, but is AI driving something that's completely unseen? No, that's not what I'm seeing on the front line theoretically with the more advanced models and if somebody does some work, possibly, but we obviously don't know about that. But there's nothing I'm seeing that's thinking that's impossible without AI. I just think that it's lowering that technical barrier to entry. They're getting quicker. Uh, they're getting, they're able to achieve better outcomes quicker during an attack. So AI augmented and they're doing things that Claude, they're using Claude to get, uh, on the fly code to access something that they probably wouldn't have bothered touching before.
Speaker B: Oh, uh, but would you. So when you say they're getting faster, what's an example of something that was, I guess probably a similar attack before, but now seems a lot more different with AI?
Speaker A: So I think when they have a domain compromise, it used to be, you know, they would maybe sink a file share out, you know, a typical ransom group. But now we're seeing pretty much all the groups. They will go after maybe your SQL databases, they'll be taking a schema, they'll be coming back and they'll be doing a really crafted query within minutes, which didn't used to happen at scale and at volume. Your nation states would do stuff like that. But now we're seeing that in normal kind of ransom breaches and other attacks. So I think that that is one area where we're seeing, you know, access to diverse data sets that weren't touched. Yeah, and just, just frequently and relentlessly. And I think the other thing that is given advantage certainly that we're seeing now is on business email compromise. The more advanced phishing kits, I think they're leveraging AI both for the prompt, both for the, you know, to set up the infrastructure and get the phishing portal and sort of spinning up on you know, cloud and containerized very ephemeral platforms. So you know, signature doesn't work because they're only there briefly and then actually post compromise as well. We're seeing sort of Microsoft graph queries coming in like minutes, seconds after that token's been stolen by Relay. That is unusual. Like that suggests there's no hands on the keyboard and these AI kits are out there and being used on mass, which is a big sea change in terms of the threat that that poses.
Speaker B: Wow. And I think when we were talking about this earlier, it's almost like what Metasploit did for script kitties. Is this something similar?
Speaker A: Yeah, and it's the same thing. So Metasploit, Kali, Linux, Bloodhound, these tool sets that were released that sort of brought everything together and gave it a bit of a user interface and a bit of a, uh, you know, prepackaged that brought the technical barrier to entry down. So Bloodhound, for example, you used to have to know Active Directory quite in depth. You'd have an expert to kind of move through that and get where you needed to be quickly would require some expertise. Bloodhound, which is an amazing tool, both the defense and offense that was co opted by attackers to obviously maraud for a Windows environment so you can get your domain admin in a couple of hops. Yeah, so that was a big sort of like lowing of that technical barrier and we saw that on the front line because all of a sudden we were finding Bloodhound outputs and compromised compromised servers and Now a better futures. We've actually had the raw output and you can actually see the path they followed and it matches the forensics. So you're like, okay, they needed two hops to get domain admin. Oh yeah. Those two machines that are in the Bloodhound output I've been is where they moved. So that I think AI is just a, uh, faster, ah, evolution of a trend that we've always seen. So I don't think it's so much a revolution in terms of it's doing things that were just impossible. I think it's accelerating that process. So if you've got a weakness or you've got something there, vulnerability, it's going to get found quicker, it's going to get exploited quicker. I think that that's the way I see it. But yeah, to your point, the tools, it's a very similar lowering of the.
Speaker B: But the recon part, the exploitation part or even the network traversal, all of that is achievable. A lot more easier today.
Speaker A: Yeah. And I think AI, uh, can pull that together. I think that's another key thing. Whereas you have disparate tools, you'd have to work the output still. You would then have to have somebody that could understand the output, say Bloodhound, and then manually going to Metasploit and maybe do what the necessary attacks, etc. Whereas now the models are there that would let you pull that together relatively easy.
Speaker B: Yeah.
Speaker A: Uh, you don't actually have to be able to code, you don't actually have to really understand Active Directory. You know, if you've trained, if the model's trained to do that sort of thing and it's set up in advance, you can kind of get there without really any major technical skill, which is quite scary because that used to be like a red team capability. You'd be like a good red team. That's what they're doing.
Speaker B: Yeah, because they already had their, like a. Whatever toolkit that they would walk in with.
Speaker A: Yeah. Then have custom toolkits and obviously Bloodhound, you know, Metasploit, all these packages, it just pulls together their tool sets, makes it easier, just automate stuff. And I think, yeah, AI can do that and can on the fly as well. So you don't need to wait for say, the Bloodhound team, the Metasploit team of Kali Lynx, to put something in. You can do it yourself. If you find something bespoke, you can probably get one of the good models if you can afford the tokens to do it for you and that you're not constrained by somebody else that is a developer. You can probably get there yourself.
Speaker B: I think, um, I would love to kind of paint this in the picture of the current AI augmented kind of services, whatever. I think there's a copilot research, uh, that you guys came up with. Could you share a bit about that as well? I think the one you spoke about that you guys use copilot in prompt.
Speaker A: Yeah. So basically our threats lab discovered a vulnerability in copilot where you could basically, uh, do a prompt injection and get it to carry out an instruction, which is of concern and I think highlights the attack surface that you've got. So it's not just AI, as you said, augmenting the attackers, it's the attack surface and the vulnerability that introduces as well. It's a whole other level of vulnerability and it's a little bit more nebulous than, you know, a traditional platform where you would do work on the code and you'd find the vulnerabilities. Obviously AI can do things that are perhaps unexpected and it's hard to lock down. So I think that exploit kind of shows that you can. Every user potentially could start being able, even inadvertently, access to things that they shouldn't be or you don't want them to get access to.
Speaker B: So, uh, from a forensic perspective, is there enough telemetry or information available for you to retrace test within with the AI use cases?
Speaker A: So yes, you can get. Or you can obviously get the prompt. Obviously there's platforms out there that will record that and centralize it. I think it's the scale that is difficult and to derive meaning from noise, which, uh, I think is just generally the landscape we find ourselves in anyway. Right. I think because attackers aren't dropping malware as often. They're acting like users. They're using compromised credentials that they're using living off the land. I think AI is just an extension of that, is deriving that meaning from noise. So M. You can audit the prompts that go in. I think what's difficult is understanding what gets returned. Oh, and having a kind of M. Traditional forensics is pretty easy. You know what an artifact is in Windows, you know what it means with AI Obviously, depending on a whole host of variables, what they can do and what they get back isn't always certainly just native, out the box, not that easy to derive. So you can see what was asked for. Deriving the meaning of why that was asked for and what that means and what was delivered. Obviously that's another challenge.
Speaker B: Also Even to understand the intent of the request is itself.
Speaker A: Yeah, absolutely. I think if you've ever played around with the models like the way you can craft queries. I uh, know there's a few online platforms that will let you test it and it gets harder as you work up and obviously tricking the AI. I know there's been research out there where the AI is over friendly.
Speaker B: Yeah.
Speaker A: And you can kind of almost plead to it and people successfully got information out that they shouldn't be able to get out. So obviously that that is a concern because it's not easy to test that. It's not a. We're going to run a vulnerability scanner against that and see what we get. I mean you can do that but you know there are people that specialize in getting prompts through and getting same with malware. Right. The models are locked down that aren't. That don't allow you to do offensive things and kind of got guardrails.
Speaker B: Yeah.
Speaker A: People that specifically get around those guardrails with really clever intuitive kind of prompts and asks of the of the AI to get them to like do what they need. I saw one example where they pretended to be a security researcher and they kind of just did the individual components and danced around the guardrails until they ended up and they tricked it into compiling oh uh, like a fully remote access tool which was blocked initially but just through the prompts they managed to get there.
Speaker B: So is the sophistication now the way people should approach AI security? I guess a lot of people are looking at that from as a data security thing that hey, as long as I have my data covered I should be good. But sometimes or at least a lot of times the reality is far from it because you may have data classification all of that in terms of preparing for this kind of you say AI augmented world of incident response and research. What do you see the good I guess some of the more mature customers do in their environment to be able to be ready for this? Because the one reality that is true today is that the volume of AI attacks is continue to go into increase is that people are not expecting it to slow down anytime soon. But what we can do is to prepare for it. How do you see some of the I guess people you may have spoken to the customers, uh, how are they approaching this overall AI security as a space?
Speaker A: So I think it's two pronged. I think that the traditional security checks and controls work and they've got to be in place and I think they're even more important to have a laid defense. Because AI lets the attackers move in the same way but quicker. So if you've got barriers to that, then obviously you're going to slow them down. In terms of AI itself, I think obviously having something that pulls together will detect shadow AI usage. I think that's important because obviously you can lock down models, you can make them less useful if you like, but more secure. But then users might try and go around that with shadow, which is, is a massive risk. So yeah, uh, inventory auditing, like advanced auditing, I think permissions is a huge one. Like what permissions should it have, what does it have? And obviously again, just like a uh, file share, it's the same thing. It's just an agent accessing the files for you. What can it see? Does the user need it to see that? And obviously then dealing with that. So uh, a platform that pulls that together, it's an extension really of what you should be doing anyway. I don't think there's any kind of new magical controls that need to be in place. I think you need to account for this new platform. But it's the same problem, right? Shadow, it's over excessive permissions. It's visibility, audibility and automated response as well. I think, you know, it can't all be done manually. There's just too much noise. The attackers are uh, acting like users. The sort of detection opportunity is slimmer than it was. So I think you need some automation in there as well. AI powered just purely from a resource perspective more than anything. So I think that together it's still the bread and butter of what you know, you should be doing. Anyway. Yeah, an extension. Um, because I think as well you're going to see vulnerabilities exploited in more niche products due to AI vulnerability sort of research as well. I think that's going to cause some issues as well. So you need a broad visibility, I think, of where your data sits and have some AI behind that to spot the noise.
Speaker B: Because to your point, there's not just the applications you already have, there's also third party, like your salesforce as a world.
Speaker A: Yeah, absolutely. I think obviously there's only a set number of vulnerability researchers in the world. I think, you know, you've got these new models. Mythos is a great example of, and some people say it's marketing, but it does a good job of finding vulnerabilities. And the thing is, if that's not constrained with skilled people anymore, then you can start to target the more niche products that don't get attention because the market share. Yeah. But actually might be of use. So I think you are going to suddenly find a wider array of vulnerabilities in many applications. And then if there's a zero day, obviously to get a proof of concept now for an exploit is really quick and use of AI is doing that. So from something getting released in the patch, people have working proof of concepts the same day. In a lot of cases we're seeing proof of concepts for things that aren't even patched yet, aren't even announced as vulnerabilities. So all of a sudden you could be as secure as you want to be, but it's something that on the perimeter might have a zero day in it that there's a proof of concept there or they can get one and suddenly they're in. So you're not necessarily buying zero days. $50,100,000 pounds.
Speaker B: Yeah.
Speaker A: Somebody could get that in their bedroom if they can afford the tokens that's on the table. I think that's a bit of a sea change. I don't think it's hyperbole.
Speaker B: I think that's so with the people who are preparing for this because obviously a lot of people are thinking about uh, uh. One of the topics I was top of mind for was how do I augment AI into my instant response team, my SOC team, my overall process in general. Do you find that obviously data being that very top of mind thing for hey, data is a fuel for AI data security, blah blah. Is there anything specific on the data space that people could be looking at? Uh, that was okay when we were looking at a non AI world, but perhaps it's not okay in the AI world especially now because we have Salesforce Copilot, we have all these other things in the ecosystem.
Speaker A: Yeah. I think again it comes down to like user permissions and uh, I think that's the case obviously Salesforce. There's been some stuff in the, in the press around Salesforce and guest permissions and things that weren't configured correctly. So I think a lot of it is going to not even be vulnerability, but configure, you know, misconfiguration. Be that in something like Salesforce or any CRM, any M3, whatever it is, M M365, unintended behavior. I think AI is going to tease that out very quickly. Um, a bit like Bloodhound would tease out vulnerabilities in your AD infrastructure that you set up. So I think it's the same thing. So I think using it defensively.
Speaker B: Yeah.
Speaker A: So I'm an advocate of saying Run Bloodhound or run Metasploit. Come from the point of view of the attacker and see what you find. I think it's the same, like run the same models, do the same thing to your environment and see what it finds. Now, maybe it's an extension of your pen test. Maybe it's something you have in house. Maybe it's something like SEC DevOps that you need to build because you've got some custom things. But again, you can use AI to do that.
Speaker B: Yeah.
Speaker A: And I think, you know, instant response from that perspective. You've got to be prepared to like spin up your own tooling. Maybe you do that with AI. Depending where you think you need the audit data from. If you've got something where you haven't got any audit data, that's a problem. If you've got data that just isn't an audit path or you think it's not important, it's not important to have a breach and somebody, a legal eagle, a lawyer says, what was in that data?
Speaker C: What was it?
Speaker A: What was taken? And you know, I don't know. Because there's no auditing. Yeah. That's just. You can't be in that position anymore because it doesn't matter where the data is, they will find where that data is. Yeah. Very quickly.
Speaker B: And to what you said, because the path is automated. You said the example of the SQL query being crafted.
Speaker C: Yeah.
Speaker B: Those are no longer a. Oh, the script read is not skilled enough anymore.
Speaker A: Yeah. No, they. If they see it and they find it and they can query it, they will query it and they will query it with a really good query that gets all the nice stuff they want out of there. If this credentials and accept, you know, payment contracts, PII data, they want the leverage.
Speaker B: Yeah.
Speaker A: If it's a ransom group, if it's nation state, but have a different, but same, same principle. So if you've got no transaction login, if you've got no way of knowing what queries are run, then you don't know what they've taken. If you don't know what they've taken, eventually you're gonna have to own up to that to somebody. And obviously a good incident response. If you. Everybody will get breached at some point to some degree. Yeah. World we live in. But if you can go and say, well, actually we did this and this, we know they did this. Initial data is impacted. We know that. Because that's a great position to be in where uh, I've dealt with breaches and it's not a great position to be in, is, yeah, they access this and this and like a customer comes back and says, was my data accessed? But we don't really know. It's not like, uh, it's just not. You're never going to recover that relationship. I think you will recover the relationship if you can say, this is what we've done and you're quite open and frank. And I've seen that actually build a stronger relationship because they're in the same boat. Yeah, but where you go back and say I don't know is difficult. And obviously SQL databases and things, there is an overhead from logging that information. So doing that without impacting business performance is the classic. It's the classic CISO conundrum. Right.
Speaker B: Do I want all the data, uh, or just only some of that?
Speaker A: Yeah. And ultimately you need to think like an attacker and think if they got access to this, what could they do? Can we see it?
Speaker B: Is it possible to use AI to kind of make that kind of. Or help us do that judgment to your point about the forensic log as well, from a forensic perspective, these logs are the reasons you're able to trace them back. And I don't even know there's a checklist for how a forensic person approaches an AI system. Is there like what's your thought process when you approach an AI system, which is probably very different. Like approaching a copilot versus a, I don't know, whatever chatbot you saw before.
Speaker A: Obviously a little bit in between the kind of its reasoning and logic. Obviously that is notoriously non exposed. Really. Yeah. So obviously we look at the prompts, we'll look at the prompts and what's being done and we'll look at the access on the other side. Again, that's in terms of the other side because it still, it should still leave an imprint. Right. So whatever your agent is just an extension of the user. So uh, it should still be audited. If that just comes back to some nebulous model that you can't attribute to any particular user at any particular time, that's useless. So it's the same. It's the concept of an audit. Like it's a bit similar to a firewall that just gives you the firewall IP and doesn't go back to an external. What use is that to anybody? It's the same principle. So uh, I think, you know, being able to verify that data and get it back to the user context it's from and attribute it to a user and if you've Got the prompt and you can see the output. You've got the full picture. The difficulty becomes if it's configured or they're using, and that's probably an element as well. Enterprise AI and the non enterprise AI, like an open source and stuff. Has it got. It might be great, it might get your output, but has it. You're giving that permission to access your data.
Speaker B: Yeah.
Speaker A: Right. So. And I think people can be a bit quick to give any AI agent access to the data compared to if somebody came in a contractor and they're really strict with the contractor but you know, oh, this open source AI model. Yeah, let's give that full read. Write. Yeah, brilliant. And I think that's what you need. You just need that audit trial. So it's no different, um, whether it's an audit trial of your SQL database, audit trial of the AI agent and what it touches. It's the same principle. So somebody needs to look at that in advance.
Speaker B: Yeah.
Speaker A: Say, yeah, if we had a breach and maybe bring lawyers involved because they will tease out the gaps, they will ask you questions and I love working with, with lawyers on jobs because they tease out those pertinent questions and they get things done. So they will say, right, we need to know, is there any third party contract notification requirements from this data? Can you tell us like what's been taken or. No, we can't, you know, so them going through, uh, a dry run is great because they would, they will find it. They will find it. They'll go, okay, can you tell us what would be accessed in that SQL database? What, what's, what does it look like? Oh no, we can only tell you the IP it came from, but not what was asked for. And they're just going to raise their eyebrows and um, it's good because they can give you support to get it done. Yeah, um, doing that in advance is great because it's, you don't be doing it after a breach really, if you can do it before. I think it works well actually this
Speaker B: is an interesting point because I find that obviously not everyone's that forward today. So a lot of forensic folks that I've spoken to may not be working directly with AI systems.
Speaker A: Yeah.
Speaker B: And uh, the approach that you mentioned is an interesting one to include legal in those questions because I guess when data is taken out nine or ten times, a lot of people may have a data classification policy, but it was never really applied. Let's just say that. And the whole discovery of that a. Is this like, um, is this a confidential data? Is this pii, that exercise never been done before at this moment. And now suddenly it's been given out to AI systems.
Speaker A: Yep. Yeah. So I think attacks predominantly used to be for ransomware groups. Encryption first, right? Encryption, no data taken. Yeah. Now is data first. Practically no encryption. And I think a lot of people don't understand, coming back to the legal angle, the questions that will be asked and what's important. And like you say, the data classification is often the most expensive kind of part of the response.
Speaker B: Oh, my God, yes.
Speaker A: Uh, it's the one that's under the most time pressure because you've got regulatory bodies, you've got customers that want to know you might have contract requirements. Right. From third parties, where you've got to let them know within 72 hours quicker than you've got to let the ICO know. Yeah. So straight away, you need to be. If you've got nothing done in advance to classify that data and label it, it's really hard to do. And something I think people overestimate the ability of forensics to do is forensics to tell you what data has been taken. Windows is great at telling you where people move to what they did on the box in terms of data access and sending it outside the system, out of the box. Windows is there's not many forensic artifacts that, oh, really will definitively tell you because the lawyers will want to definitively know. So you kind of have to match it up if all you've got to Windows forensics, you kind of rely on firewall to confirm volume and that it actually went out of the door.
Speaker B: Yeah.
Speaker A: You can probably really get to data staging from forensics on its own without anything. So I think that's when something that people overestimate, like, oh, forensics will come in, they'll tell us what was taken, no problem. But if there's no logging. Yeah, no logging on the SQL database, the system may have been encrypted after data's taken, they may have done hit forensic, uh, evasion techniques. Yeah, right there. So, yeah, there's these zip files, but we can't tell you what's in them from the forensics because that, that's, you know, that's not available anymore. And if you haven't got firewall, we don't know if it's gone out of the door. So having some platform to monitor that and to address that gap is key because I can attest the amount of times I've been there, and I'm like, there's just no forensic evidence to give you that answer. Uh, and obviously lawyers don't want to notify based upon a hunch. So I can say, yeah, I'm pretty sure this is what's gone. You can see from shell bags, they've gone into this fog, they've done this. It's a good chance that's gone. And lawyers is basically, well, no, like, has it gone? Uh, I can't.
Speaker B: You can't answer that also, because traditionally firewalls are never designed to just hold on to what data is actually going as well.
Speaker A: And a lot of times aggregated as well. So you'd be surprised how many times you can't work it back to a particular endpoint. So even just what you think is simple, or let's see how much went on the fault, is not that simple in practice. And that's one of the things you can look at. You can say, okay, if we had a breach and we were looking at the firewall logs, are they useful? Yeah. And when you look at it, you go, oh, no, it all just comes back to this one appliance and we can't work it back to an endpoint. So we don't even know which blob story. Jurassic book. We don't know. All of a sudden what should take you minutes is taking you days, if you can get there at all.
Speaker B: Yeah.
Speaker A: And that's again, a difficult position to be.
Speaker B: So what you're almost suggesting is that for forensic people, or people who are building a program for AI security, probably should also consider the fact that there should be enough information for forensic to come back and look at what data transferred.
Speaker A: Yeah.
Speaker B: And even has an ability to understand what type of data it was, what classification the data had. Otherwise, you basically, there's no point at, uh, the end when you get to that point, if you ever have to, God forbid if you have to. But if you did, you don't have anything to work with.
Speaker A: No. And I mean, even if you can say, okay, this data, you've just got file names, you've got the file server, uh, maybe that that's been taken, or the blog even, working that from a cold start to get answers in the timeframe that is expected or required is very, very difficult. This is stuff that needs to be done. You need to be classified because obviously you've got to work through that data. It's got to do ocr. It's got to. That needs to be done up front. Yeah. So actually, forensics give you a list of files, and I do this and I give the list of files and feel Great. Yeah. And I've got this, you know, it's been a couple of hours and we've told you this has happened. Um, and obviously this is when we haven't, you know, got varonis in place. But, you know, this is what's happened. And then it's like, okay, you tell us what's in that data? Well, no, this is just Windows metadata. I can give you the list.
Speaker B: Yeah.
Speaker A: Like someone's gonna have to look through that data. Uh, or run a tool. And I know data and E discovery companies charge a lot of money to go through that data and do that data classification piece. Yeah. So having it up front and just being able to go, okay, these are the files, like, how many are sensitive? How many have pii? It's a great start because straight away you can go to a customer breached at this time, like, we've done this on the data and nothing. If there's no PR of yours, there's no hits for you, you're out of scope. It's obviously the reduction of your risk. Whereas if you can't quantify, you're probably going to have to notify everybody. And there's nothing worse than doing that on a hunch. Right. The data wasn't taken, but you're having to notify them and say, look, we don't. And we don't know because it's much better to go, we've got that done. But it is, for me, it's part of the instant response lifecycle, the preparation stage. That's where the battle is won or lost. We can obviously make it a bit better when we're in there and we can get you the answers. But some stuff. Yeah, it's possible to not have those answers.
Speaker B: So do you find that the IR team should be involved as say. Let's just say an AI system is being built. There is the solution architect, security architect, all of that. They've gone through there, whatever the requirement is pre prod. Before they go into. They should have a conversation with the instant response for, hey, because the reason, uh, it's interesting, right, because at that point in time, a lot of times, and security people, and we don't know what the application is supposed to do. So it's hard for us to tell what kind of log is important and how do you kind of find the balance there. With AI systems, I think the key
Speaker A: is to speak to an IR team or speak to responder because we tend to operate in a fairly niche world and it's greatly good calling as a breach, but I Think, speak to them and say, okay, what information would you need? And give them an example of what's audited and see if they can work it back. Because we're really interested in working lateral movement back to where it started.
Speaker B: Yes.
Speaker A: So can we get it back to an endpoint? Can we get it back to a use. Can we get it back to a usable entity? It comes back to an aggregate, such as, uh, a gateway, a proxy, and we can't go any further. It's no good to us. We need what's on the other side. And I think then the other thing is, okay, what's the data look like? Has it got timestamps? Like, proper timestamps? Has it got, you know, like, what details are the API requests, for instance? Like, is it useful? Yeah, just something somebody's added in for. And I think they'll give you an honest answer. I think if you show them the output, they'll say, yeah, I can work with that and just follow the process and save. Somebody breached this. Could we work this back? Yeah, it doesn't have to be intensive, but you'll very quickly tease out, oh, no, like, we're not getting a forward header from that gateway. Like, we don't know where it's going to. And it sounds the simplest thing, but the amount of breaches I've had where I get these logs and you wait for the logs and they pull them from the appliance and you get them and then it's like, oh, it's all the same IP for everything. Like, yeah, that's the gateway. And you're like, can you. Have you got anything to decide to marry it up? It's like, no. And it's like, so I can't get any further than this. That's just a wall I can't see over. So how do we find the endpoint? And you have to go another way. And it should be simple. So, like, when I say basics, because it's the same for an AI agent, right? If it's coming from an IP on an endpoint. Yeah, you've got a clear path right to the data. You can work that back and you can say, okay, that's initial access vector. Let's close that hole and then move. If you're spending a lot of time trying to just find the initial access, which should be simple, you're making the forensics life really hard, actually.
Speaker B: Uh, I think so. Uh, if I was to summarize a new wave of instant response of forensic for AI systems is if you're able to a classification is important. We're definitely understanding on that. Second one is the fact that if you have a direct path from a user or an agent to a data, everything that's involved in the metrics or telemetry around it needs to be somewhere. You need to have that at least.
Speaker A: You need to have it. It needs to be queryable because again, just having that, uh, and saying there's six terabytes in an S3 bucket of unstructured data. So, okay, well, I'm going to have to now do something with that. You want to at least be able to get it into a platform to query it quickly. I think that's something that gets lost as well. Like speak to your security IR teams. And how quickly can you query the data? Because the amount of times m. Where It's. Yeah, there's 17 terabytes of unstructured logs here. That's like, okay, but, uh, work with me a bit. We need to be able to get that into something creative. I get it. It's expensive to keep it in warm storage, but part of your process for IR should be if we needed information from there, how quickly can we get that? And it needs to be minutes to hours, not days to weeks. Because obviously once we get a thread, forensics people are great at, uh, pulling that thread. What you don't want to be doing is a threat hunt to a breach to try and find, like casting a huge net. You don't want to be in that position. You want to be able to say, okay, there's the logs. Okay, we've got the first thread to pull. We know that last step we've got that will work back. And you want that to be quick and easy along every step. So if it's, if it's the data to an aggregator or a firewall and then to an endpoint or something in between or an agent. Every step. Because you don't want to get stuck at a step because we're trying to get you the initial access so you can close the initial access. You can figure out how long you've been breached.
Speaker B: Yeah.
Speaker A: So you can do containment because that's, that's. We want to stop the bleeding, right?
Speaker B: Yeah, yeah.
Speaker A: Uh, if we can't get that back and get you back to the initial access vector, we can't give you any definitive. So, yeah, uh, anything that's going to hold that up is really going to hurt you. And it's not that hard to just work through as a driver and exercise and say, okay, so what we worried about well, we've got a file server, we've got this, we've got that. I mean a good example like S3 storage access logs on, um, on by default.
Speaker B: Yeah.
Speaker A: The amount of people that are shocked when we say that there, there is nothing that will tell you what access that data if you've got no platform in place, if you haven't like without some pre work, if it's just out of the box, default. Yeah, yeah. Somebody we can take, you know, we can tell you somebody's took, you know, somebody's took some. Can't say what they took.
Speaker B: Yeah. I think because to your point, a lot of times engineering is focused on I don't want to pay too much on log storage but I do need the logs as well.
Speaker A: Yeah, I mean you don't. Nobody wants to pay for log storage until you have a breach. Yeah, everybody needs the logs and unfortunately especially Cloud and these other sort of, you know, SaaS platform. Everything else. If you don't have the auditing in place, there's not a lot to do. It's not like a traditional Windows forensics where maybe we can carve some data out or we can do some magic and get. Yeah, it's there or it's not. It's a binary thing. If it's not there, that's it.
Speaker B: Yeah. Wow.
Speaker C: Okay.
Speaker B: I mean I can tell point ass is really similar as well where it's either either you have the logs or you don't have the logs because by default the same to the same as the S3 example. They would not have that turned on.
Speaker A: Yeah. I mean a lot of platforms don't have. It's getting a bit better but obviously a lot of platforms don't have them turned on because obviously the storage costs money.
Speaker B: Yeah.
Speaker A: You've got to be able to query the logs as well as I said getting them in somewhere that's useful. But yeah, it costs money and I understand that it's easy for me as a consultant. Yeah, just log everything. Um, but you need to have that basic audit path and I think sometimes people overlog as well, like stuff that isn't useful.
Speaker B: Yeah. And finding the balance is the hardest part because I'm sure people have found that they've over engineered and have. Maybe the financial organizations are good like that because they just have the money to just give me everything.
Speaker A: Yeah. And, and you know sometimes we say give us everything's forensic because we want the data and it's like whoa, whoa, maybe not that much, we can be picky. But I think, yeah. I think being led by some sort of offensive team with the A blue team as well, and just running through a draw run is a great. That tends to get the best results because you can very quickly say, yeah, we can get you answers from that and that's a good baseline. You might want to do more. But if you get to a point where the forensics team saying we're stuck now, you don't like, it's good to do that in a test and get over that hump.
Speaker B: Yeah, uh, I think I got the answer because my hope was, at least from this interview to be able to give people a starting point for what they should be looking at. And I think we've already given three, so I think it's pretty cool to be able to at least have enough information for a direct path. Having the classification, which is, I'm sure it's not an easy conversation because depending on how much data and how long the data has been there, there's like, I think I was talking to someone about zero trust and they were talking about zero trust has this pillar for data security. One of the things was data, uh, classification in that data security. And someone said if you look at the organization that has been 20, 30 years old, who've never done this, just the exercise to classify that data, and I don't know about with AI systems, but this is pre AI, they said it would cost them more than the revenue the company makes to go through 20 years of data and classify them.
Speaker A: Yeah, I think it's finding that sweet spot again of over engineering and what you need to be able to do. I think obviously there's some easy wins. Your CRMs and your cloud storage, I think that is an easy win because there are tools out there. Obviously, Rhonas being one, I'm still the T shirt on, but there are tools there that will allow you to do that at scale, enterprise scale, where it doesn't cost the earth. I appreciate with legacy systems and everything else, there's always going to be that question. I guess the problem is if you can't answer that question, what's the cost of not being able to answer that question? And you look at some of the big breaches that come out and eventually this information that's taken is going to be weaponized in new and novel ways. So I think the liability will increase as well. Because what AI allows attackers to do is post process Data. So getting 10 terabytes of data is overwhelming. It's overwhelming for an attacker. It doesn't change just because it's an attacker, what do I do with this? But now with AI actually they could be post processing that data and finding new and novel ways of monetizing it because that's all they want to do and it will happen because it's what they always do and have done. So I think you will find new and uh, novel attacks coming from stolen data that will drive the need to be a bit. Because if you haven't notified a customer and all of a sudden they get aware of an attack that's using the data and you didn't notify, obviously we're going to start seeing liability lawsuits come through more often and again then the cost of the data classification might become more reasonable. But I think you can get to a point now with the tools. I don't think it has to cost the earth. I uh, think even just that first pass of being able to say, okay, what type of data is it? Are we worried about this data? If you can rule out a terabyte straight away and say, yeah, that's, we know that is not like we've done that pre work. We know that is just, we're not worried about that. And I've worked with clients who can do that. They're like, yes, no, yes, no, no, yes.
Speaker B: Yeah.
Speaker A: And straight away you've got a subset to work with and that makes it so much easier than, uh, I don't know, I don't know.
Speaker B: Just everything is important.
Speaker A: Yeah, everything's important. And I think what people don't realize is third party contracts there are, it's getting written in more and more often because the supply chain attacks and third party attacks where you have to notify them in a certain period if their data's been impacted. And actually there's quite severe penalties and the bigger players will come down heavy. Um, and I've seen it, I've seen it in the breaches. They will come down, they will demand answers and they want more information than regulators. Yeah, you're obliged to give it to them. Yeah, I've had checklists come through and it's like I've had this checklist come through from one of our third parties. This is what they want to know. And they want to know. The IOCs, they want to know, they want a forensic report basically. Um, and you know, they've got the clout to demand it. So I think knowing your liability from that perspective will drive what you need to do on the data classification piece. Yeah, the higher that is, the better you've got to be with your data classification to Meet that.
Speaker B: Awesome. Thank you for sharing that. Uh, I mean that's all the questions I had because I think I wanted at least I got my goal. Uh, where can people learn more about the research you guys are doing and uh, more about the Ronin's as well.
Speaker A: Yeah. So Varonis Threat Labs is where we publish our blogs which can be found on our website. So we have a good mixture. We have it from the security researchers. Uh, I've done some blogs, my team do blogs from what we see, you know, in attacks against our uh, clients that we've helped them with and that isn't necessarily just stuff errors, touches. We will help any of our clients out. So we've, we've been involved in some really interesting and impactful cases for them and helped them out of a bit of a jam. So it's a novel interest in that will go on there as well. Like I say we did a bit around Shah Aloud, some around Active Directory from we've spoken about. Yeah. So yeah I direct people for owners Threat Labs and, and the blog post we have on there.
Speaker B: Awesome. I'll put the links in the shorts as well. I will put your LinkedIn as well. Assuming that's where you hang out normally.
Speaker C: Yep.
Speaker B: Yeah. Unless you're an IRC channel somewhere that would be. Although I don't know if anyone else has IRC channels anywhere. Swing.
Speaker A: Yeah, I'm not, I'm not an IRC channel. LinkedIn is where I'm at.
Speaker B: LinkedIn is the modern. I think that's a good tweet. LinkedIn is the modern IRC for all the security people.
Speaker A: Yeah, pretty much. Yeah. Um, yeah, I'm uh, I'm on there maybe a couple of people that make me speak to them on Discord.
Speaker B: But yeah, yeah I will put that order. But thanks so much for coming.
Speaker A: Thank you, thanks for having me.
Speaker B: Thanks so much. Pleasure.
Speaker C: Thanks everyone.
Speaker B: Um, thank you for listening or watching
Speaker C: this episode of Cloud Security Podcast. This was brought to you by TechRiot IO. If you are enjoying episodes on Cloud security, you can find more episodes like these on Cloud Securitypodcast TV our uh, website or on social media platforms like YouTube, LinkedIn and Apple Spotify. In case you are interested in learning about AI security as well, do check out our sister podcast called AI Security Podcast which is is available on YouTube, LinkedIn, Spotify, Apple as well where we talk to other CISOs and practitioners about what's the latest in the world of AI security. Finally, if you're after a newsletter, uh, just gives you top news and insight from all the experts we talk to at, uh, Cloud Security Podcast. You can check that out on cloudsecuritynewsletter.com I'll see you next episode.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.