%20(3).png)
Detection Dispatch (Alex's Version)
Detection Dispatch (Alex's Version) is an independent detection engineering & threat hunting podcast. Rebuilt. Community-first. Featuring a lineup of the real and active projects pushing the limits of detection engineering, threat hunting, and everything in between.
Detection Dispatch (Alex's Version)
GRC, the Passenger Princess of the SOC? feat. Ayoub Fandi
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
GRC has been called the passenger princess of security for too long. In this episode, Alex sits down with Ayoub Fandi, GRC engineer and author of the GRC Engineer newsletter, to make the case that GRC and detection engineering are solving solving the same problems and somehow still not working together.
This episode covers:
- Why GRC plays PvE while everyone else in security plays PvP and why that actually makes them your best ally
- How auditors certify 100% coverage from less than 1% of your environment
- Detection debt meets GRC debt: what inheriting someone else's program looks like on both sides
- Vibe coding, AI agents deleting production databases, and what that means for both of our jobs
Ayoub's newsletter and podcast: GRCengineer.com
Detection Dispatch (Alex's Version) is an independent detection engineering & threat hunting podcast. Rebuilt. Community-first. Featuring a lineup of the real and active projects pushing the limits of detection engineering, threat hunting, and everything in between.
Today's episode is brought to you by Detections AI, a fast-growing repo where the DE community shares peer-rated detections and adds new content every single day. Welcome back to Detection Dispatch, the show where we talk about detection engineering, threat hunting, and everything in between, including today's topic, GRC, or as some would call the passenger princess of security. I am your host, Alex Ritato. And today it is my pleasure to host the ultimate crossover and collab that I've yet to ever see. We're bringing GRC in the Riverside Room from none other than the king of GRC from across the pond himself, Ayyub Fondi, previously just GRC engineering lead at GitLab. And from the looks of your last newsletter, it seems like that completely inspired GRC as Git today. Welcome to the show. I'm so happy to have you here. This collab, I feel like, was has been in the making for some time. Or no, it came to be on somewhere on a rooftop in the Bay Area the last time I saw you, which is also where I met you for the first time. So how are you? How have you been? It looks like you're rocking and rolling a new gig soon, perhaps.
SPEAKER_00Yes, yes. Uh so nice to be here. Uh yeah, so we met at uh this uh this infamous rooftop. Uh uh is it a month uh month or something ago? Yeah, time flies by. Uh that was that that was cool. And that's where kind of brainstorm about this amazing idea of combining detection and grc feels like a match really happened. I'm very excited. Yeah, yeah, yeah, yeah. I agree. I agree. Uh and yeah, starting a new gig soon. Uh exciting stuff, AI related, just saying. But yeah, I'm uh really looking forward to this because you know, I think it's really two teams and two, you know, two environments that should be closer together.
SPEAKER_02We also have probably uh a new second gig as well. Like you just became a dad for the second time. So congratulations.
SPEAKER_00Thank you. Thank you. It's uh yeah, it's the hardest job, but it's the most important and probably the favorite one out of all of the gigs you have.
SPEAKER_02Yeah, because you're a you're a podcast host as well. I always love to to chat. We were just chatting about her our riverside, uh, our riverside likes and dislikes, and and also you're you as well host a newsletter, which is pr which is fantastic, by the way. Well, I agree. I appreciate it. You're right, like GRC and detection engineering should technically play for the same team, right? The same field at least, different functions. GRC builds the controls posture where detection engineers detection engineering keep, you know, check to see if things are working and moving and grooving and flowing. So in theory, we should really much complete each other, but in practice, we're not really talking. Like we're we're not really yeah.
SPEAKER_00No, that's yeah, it is really uh in theory feel like we'd be a perfect comp a perfect pair in a sense. It's almost like we'd design and then you would not implement also verify that it works in practice, but then in reality, it's very rare that you see strong collaboration.
SPEAKER_02Speaking, like communication, where is she? Like, so I want today to talk about the things that we should probably be chatting more about and get into it. But perhaps a good place to start is uh to hear your origin story to get into the mindset of it all. So tell us like how you got into GRC out of all places. What does that origin story look like?
SPEAKER_00Yeah, it's a very fun story, depending on how far I want to go. But yeah, so I'm uh I'm not from technical background, so uh I did uh my undergrad in economics, and then I wanted to uh become an English teacher uh at university, uh very different path. So the origin story started where I did my master's thesis on how the YouTube algorithm polarized the 2016 election in the US, and like all about the filter bubbles and the recommendation algorithms, and I used competition linguistics to uh do some of that work. And uh then I was big into privacy, you know, I had Tor installed once or twice in my life and some of that stuff. And some of my friends were like, you know, in GRC, like uh in security, there's this field that is like less technical uh that you can get into called GRC. So then I did the French thing, which is I did another degree on top of my master's, um and I kind of did consulting, and that's where I was like, yeah, that's actually cool. Like I like this field. I think uh academia is okay, but like for now I want to try the private sector and actually work in consulting. And if I don't like, I'll go back to being like a kind of like a library rat or whatever, and and go back to academia. And then I stayed the course. And I think for me, like GRC, so I did consulting, a big four, then I moved to the UK, worked for a startup, then Salesforce, then GitLab. And for me, the constant is I worked mostly in technology companies, uh, where very engineering heavy, very product heavy, which means a lot of the more you know, weird controls and things that didn't feel too current when you kind of looked at the frameworks. I very quickly I hit friction points. You know, try to say, like, I need a list of IP addresses for this control. You know, like who cares about IP addresses, bro? Like in 15 minutes they'll change again because we destroy the infra and we rebuild it because we use Terraform. And I'm like, yeah, but that's not what they say in ISO, you know, we need to find a way. And I always felt like a translator, you know, the auditor was speaking one language, the engineer is speaking another language.
SPEAKER_02And they can't understand each other.
SPEAKER_01No.
SPEAKER_00I have a very funny way of saying it. Like uh auditors, they speak like uh the the Queen's English, and uh the engineers speak Cockney, so it's a lot closer to the the truth in a sense, like they speak more of a slang, and then you have to translate it back to the Queen's English so they actually understand it, and it has to be very formal and doing that translation with stuff, but you learn so much of the technical chops because you have to understand how it looks in like a cloud native environment and then translate it back to an auditor so you still pass the audit. So that's like really for me was a boot camp and kind of get more technical because if I wasn't like the engineer has zero BS like allowed, so I had to really make it work on both sides.
SPEAKER_02I love how it happened at face value. GRC may seem like it's not a technical role, hence the calling of the the passenger princess of the sock. But it once you get into it, you really do have to become a bit technical yourself to do the translating. So it is not it is not as easy as one seemed. There's an art and a science behind it, as what I've come to realize truly from the way that you write your newsletter, really.
SPEAKER_00Yeah, and I'm trying to push for it to be more technical. Like there's still a gap. We can still do it the old-fashioned way, uh, but working at technology companies is a forcing function. You have no choice but to be technical. Whereas if you work at a traditional Fortune 500, maybe you can be, you know, you're more at you know you can use some of the old school method and still work.
SPEAKER_02That's completely. There was one thing that I I remember the first time that I came across your newsletter and I read something that I genuinely had to put my phone down. Like I was like, wait, this is this is this is really something. And you said something about again, I could probably search it, but it was uh it was like GRC plays PVE, right? Players versus environment. When everybody else in security plays yes PvP, which is player versus player, which is a pretty sharp diagnosis. As a gamer myself, like I I but then I would argue that detection engineering it's it's a it starts as a PvP, but there's a lot of PVE that we have to come back and do to make sure that we have the right telemetry and the right data for the right rules, right? It it starts that way, but there I would argue that it is very much a PVE as well. So I have to ask, so are you a gamer? Because 2026 is a big year for gaming.
SPEAKER_00Yeah, I'm uh I'm a gamer, I'm an ex-gamer, let's say. I did a lot of League of Legends probably 10 years uh from 2008 to 2019. I did World of Warcraft, Soda 2.
SPEAKER_01That's a good one.
SPEAKER_00Yeah, yeah, but a lot of like a lot of MMOs, just because I was an extremely toxic person growing up. So I was always like the one in the chat that was saying dumb stuff, but like, okay, you don't you don't want me to play mid, then I just feed for my team and then I just get killed a hundred times. I became good, but at first, yeah, I was uh dumb.
SPEAKER_02I mean, this is a big year for gaming. I mean, we have like the GTA coming out, and uh so so many, so many big ones that people I've been waiting for years about, but but no, but you're right. Uh to not to get off track here, like DRC is a PVE game. How how are you thinking like what made you think about it that way? Like, what was really the the the big piece of it that made you say, Oh yeah, 100%. We're it's me against this environment, really.
SPEAKER_00Yeah, I think there's like literally uh one example, like one practical example. There's one time where uh like there was an insane amount of new threats, and we had like Lot Pro J, a couple of things that happened, right? And like everyone in security incident response, uh, like application security, they were all hands on deck. It was like an insane amount we have to do recon, like verify any exposure, exposure in third parties, like all the dependencies. And I remember the JRC team being very relaxed because like nothing changed for us. Like maybe there's a new risk that we have to log, but like in terms of compliance, we're still compliant with everything, like there was no audit cycle coming on. And I felt like there is like almost two parallel universes, and they all both reported to the same person, the CISO. And it felt like almost you had like threat actors that would make you always on tip of toes and like a lot of stuff that you had to always think about, and then the GRC team, who's like more based on audits instead of threats, so the cycles are longer, it's like quarterly testing, annual audits. So that when I saw that, I was like, we both work in security, but I feel like the urgency and the stress that both teams feel is like so so different. So I was like more, you know, that's where I was like PvP, like in World of Warcraft, there's like strongethorn area where often you'll be level 30, everyone would like be from the Horde and Alliance, everyone would be there, like kill each other for days. And then if you're only in like your own kind of corner when no one could come because it's a PvE zone, then you're very chill. Like, you know, you can have a video in the background, you don't have to be on your tip toes all the time. So that image came up when I saw that happen with some of the vulnerabilities and stuff.
SPEAKER_02You're almost as well as against a audit schedule, like an audit, uh, every time an audit comes around, that's what you're planning for. Versus here, it's it's it could be a couple of different things. It could be news, news, like headline chasing. It could be uh the the the CISO tells you that you need to do something, and then all everything has to be reorganized and reprioritized to meet that. Um, I mean, of course, there's some audit things that come our way, but mainly that's what you guys are for. But I I feel like we're we're mainly chasing headlines, whereas you are chasing audit schedules.
SPEAKER_00Yes, yes, like if you look at the Jossi roadmap, like audit periods, like uh audit prep would be the first items you would put on that roadmap before you put anything else. So it kind of tells you what you care about.
SPEAKER_02And the priority, which but it's chaos on both fronts, it's like chaos engineering almost.
SPEAKER_00That's what it is. Yeah, I agree. I agree with that.
SPEAKER_02So, okay, back to kind of the type of person that you have to be to be a GRC. Uh I started thinking about that as you were explaining your your origin history. On the previous episode, I Hayden, he's uh a detection engineering instructor, works for Black Hills, the D uh DNR SOC there. He he we were just we were talking about how to be a DE, you almost kind of have to be a type A person, where it's like you have you have to really control every phase of this life cycle that is the detection engineering life cycle process. And uh and and you you can't just be hyper-fixating on one thing or be too uh too detailed uh to get to get to go down rabbit holes on one thing. So you almost have to be like a type A. Is there like a certain trait or quality of a person that would make them a very good, you know, GRC practitioner?
SPEAKER_00I would say like in a sense, type A would work. I think in a sense, like we have like in GRC, we have strong attention to detail, but probably placed in the wrong areas, you know? Like we would care about like do you did you timestamp this piece of evidence or did you actually follow the guidelines to write the the risk? Yeah, like the risk narrative. And like if if you hear a lot of cycle, a lot of like circles around auditors and stuff, like they would look at a SOC2 report and like nitpick like how they were section two in the narrative. And I'm like, it's attention to detail, but maybe in areas where like the ROI is not that big. So maybe if we reposition it in a different way, maybe you could get the more benefits and more assurance from that, you know. For sure.
SPEAKER_02What could could a DE and a GRC analyst trade places? Yep, maybe not.
SPEAKER_00Yeah, just on personality type, maybe a skill set, maybe not. Uh but like it could, but I think another thing in GRC to really need is like strong uh you speak to people all the time. Just because if you think about the CISO that they they manage the whole security, but then GRC, the control domains, they span everything, which means you have to speak to both engineers and but finance and legal, and often we're very close to legal. So if you get like drained by kind of like communication with humans uh and you prefer talking to machines, you know, maybe maybe JRC won't be able to do that.
SPEAKER_02Yeah, I know that's a good way to put it because I I've I've met and detection engineers that could stay behind the computer and for and not have to do much communicating up uh up the chain that all that much. Yeah, they they they don't have to really that much. So if you're constantly in a role where you have to communicate cross-functionally, maybe that that that that definitely puts a ring into things. The other thing too, I feel like we share in common is you published a the state of GRC report. I I've been working on two years now, two two times in a row, the state of detection engineering report. What would you say is the most compelling stat from that report about the role itself or the industry?
SPEAKER_00I would say one thing that kind of came up was the big like spreadsheets are still the number one GRC tool. Like that was the big aha moment for people because they were like, oh my gosh, but now we've had the automation vendors and so many like newcomers, and spreadsheets are still the number one. And for me, I try to give the stats without doing too much analysis because then it puts my opinion on top. But like for me, why spreadsheets are first is they're free. Yeah, people already use them, and many JRC people they come from CPA firms. Often they did audits and then they got hired internally. So I I give you the playbook, okay? So you you you get uh through kind of like some information systems degree at a US university or same in Europe, then you work at a big four or like top 20 CPA firm, you do auditing for big companies, and after three, four years, one of these companies they'll hire you in-house and you work in GRC. So that's the typical playbook, which means you've been a Excel like spreadsheets power user for the city. Yeah, VLOOKUPS.
SPEAKER_02VLOOKUPS and you know now Cloud can do a lot of these things. So because you're even in Excel.
SPEAKER_00Exactly. So now what I'm thinking is like people use spreadsheets because they're free, they're used to them quite a bit, and also because like spreadsheets they're good, like it's a structured way of like presenting data, but if you have like different data feeds and everything, like it doesn't scale. So I think we almost like by design don't allow our programs to be more impactful. I see constrained by the tool. Uh and I'm like, next year, most likely, the number one GRC tool will be claude. That's what that's my guess.
SPEAKER_02You know, screw Drada, screw all these other you know, GRC tools, but I love all of them, okay?
SPEAKER_00Just saying, caveat, I love all of them. But yeah, it could be Claude Corework, could be the number one GRC platform next year. Who knows?
SPEAKER_02Claude is coming for everyone at this point. I I mean, there's been so many people that said they didn't renew their security scorecard or check marks license because they could just do it all in Claude now. Like it there's it's coming for all of us, even even people outside of our industry. Like I have some girlfriends in law and some girlfriends in accounting, and they're they're they're saying the same the same thing.
SPEAKER_00Yeah, yeah. This is this website, maybe you you you've known about it. It's sort of deaf by claude. And it's it's a hilarious website. You can put any any website to give you a score, and you can do it with people as well. And you know mine, so I put my name, they check my LinkedIn, and it was like this guy is dumb because he found a way to automate his own profession away. I was like, This is what they'll say about me. Maybe you you're more safe, but me, I was like 85 out of 100, I'll I'll be I'll be qualified.
SPEAKER_02Say that the the best that for us uh was the the vendor, the vendor provided detections. It's like how how between the detections that you have to build, how many of them come from your vendor library, how many of them come from open source, like in the community that you go out and look for? How many of them come from having to build them yourself custom? It's it's increasing every single year, the the percentage of just literally starting over and just building something yourself instead of finding something that could kind of work and trying to kind of make it work. It's just better to just start over, uh knowing what you need. So that that's uh that's interesting. And and now Claude and stuff like that, it's making it easier to build detection logic. Although there's it's like uh it's it's very divided right now. There's there's some very strong opinionated people that they're like, hell no, Claude can never write detection logic. And there's some that are like, no, it's actually pretty good at reading you know documentation and schema, so it can get you pretty far. And it, but yeah, it's right now we're in like a 50-50 divide.
SPEAKER_00Interesting. One thing I I would of course I'm not from from the detection field, but one thing I feel more uh with like the velocity of like code being shipped through AI. I'm like detection is going to be an amazing field to be in because I feel like security by design, like with the velocity now, it's more like we ship everything and then at runtime and later we actually find like we're more focused on like exactly after the fact instead of because we have to be fast. So reactive means that you know, hey, I'm here, it's my job. So it's like I knew you're a good position.
SPEAKER_02So I got a little scared during B-sides. There was a fantastic talk panel with Jackie from Anthropic AI and Kyle uh from Perplexity.
SPEAKER_00Oh, yeah, with code red partner the guy, Tom Adolf.
SPEAKER_02And they were talking about how in the future, like he foresees, I think it was Kyle. Uh he foresees that maybe we're the detection engineering function is not gonna be needed to uh to to do things in a reactive mode function where it's gonna be more mainly agents that come and sit alongside every every session that is active, every browser session. And an agent's gonna be monitoring that session and it throughout its full duration. And then once it's over, it's it it you know, the the agent will go away and it will report back what it what it saw, or it will immediately remediate if anything you know goes south or goes sideways. Uh and then I'm like, okay, well, then what our our role is gonna morph into attuning the agents and what should and shouldn't be happening rather than looking at alerts and reviewing. I mean, we're already not looking at alerts anymore, they're already being summarized.
SPEAKER_00Yeah, that's interesting because in that case, yeah, the JORCE job is just as in a bad position with that with that same uh that that that same kind of like uh hypothesis would still be, you know, who would need Josy could just have an agent that runs and automatically understands the drift between the desired state and an actual state and then fixes it and then you know I can relax uh you know somewhere. What are the people gonna do?
SPEAKER_02Like if AI is coming for all of us.
SPEAKER_00Good question.
SPEAKER_02Another thing, another interesting parallel is uh you you said something about compliance. Uh compliance is observability applied to control. Controls and observability to us means something very specific, right? Like the the visibility of you know assets reporting what people are doing on them and uh and and the difference between like a questionnaire that you have to fill out and a query for us that we look up at is the difference between a human to a test and asking a system to prove it, right? So I I mean that it it's true. Like we the exact gap that teams live in every single day, we have the telemetry, we have the data, and then the question is whether the data's there or it works, and and or in your case, whether control is actually working, like you have a process in place for something. Um what does that look like in practice? Like, what is it is it I find it also hard to, for example, explain a gap and communicate that up the chain. I've talked about this all the time. Sometimes detection engineers t have been, you know, ringing the alarm and telling leadership that this is a known gap, this is a known gap, this is a known gap, and they're kind of like, Well, the lights are on. We've been fine. How do you do that the same way on your side?
SPEAKER_00Yeah, so it's a it's a it's a great question. I think so there's there's two approaches. So there's there's two sides to your question. There's like the observability part, like for me, I feel like compliance is okay. Like there is good. One second. Oh good. Yeah, yeah. It's just because I have only work at my house. And he's he's done, he's just going.
SPEAKER_02We can edit it out.
SPEAKER_00Okay, perfect. I'm back. I'm back, all good. Sorry, I'll restart. Uh so for me, there's two sides to this question. There's like the compliance telemetry part. So for me, when I think about compliance, I'm like a core thing about compliance is I want to know if you actually there's a control narrative, okay? You need to have encryption at rest for your object storage. And then there's like how this control is actually applied in practice. Is it actually applied? Is it always applied? Is there anything out of scope? And then we need to verify, and through that, I need to get access to the source data. So it could be logs from AWS, it could be like unfortunately, sometimes a screenshot from the console. Like there's different ways of proving that you actually implement the control. And I'm like, people that really need strong true data, it's the observability stack where it actually happens, right? You get actually live production data and you make decisions on top of it. And a detection team would make like have rules and logic on top to kind of like see drifts and P99s and all this stuff, right? So for me, I'm like in compliance, we should be thinking about it the same because we work through so many abstraction layers. Like by the time we have a screenshot of the console, like if we were in non-compliance, it could have happened for minutes, hours, days, weeks, we don't know. And for me, I'm focused more on the bottoms up, where we start from the live feed of data that is already trusted by everyone in the team and or more the technical side, and then from that we apply the compliance-specific logic. But a lot of it is Boolean. It's like, is it true or false? Like, is it encrypted at rest? Like the JSON key value pair, it's like encryption, it could be just true or false. So it's easy for us to then apply logic. And then if we see like data coming from systems and we see that, you know, some data is coming and then some systems are not encrypted, and we we get that data fed back, or like we have an audit trail and we see that some access has been elevated compared to the baseline, like then we can make decisions also on the GRC side, and that's where we can help the technical teams that look at that raw data with the business context to fine-tune maybe some rules and understand like what to when to trigger an alert officially, etc., because it maps to compliance. So for me, that's that's something that we should be doing, but there's zero incentives right now because we can still pass audits without any of that. Well that's a little scary. So yeah, we we we'll talk about it as well, but like you know, there's this sampling, there's all these things in GRC that means it's very easy to certify a company when you only looked at a sample of 35 words.
SPEAKER_02Sometimes when we want to look for something, but sometimes the data's there, sometimes it's not. Anton talked about this on the CISO Tradecraft podcast last week or two weeks ago, where it was like you you look back one year, two years, and then maybe the data is no longer there anymore. So then now what?
SPEAKER_00Yeah, yeah. And and what you said about, you know, kind of like you you kind of surfacing those gaps and then there's no action taken. Like, like that's where GRC can be such a great ally because we think in risk, right? Like the gaps by themselves, like if especially if like the context around them is not like clearly labeled, they'll say, okay, it's a gap, like you know, who cares? We're still here, everyone, everything's fine. If we can tie the gap to a potential attack path, if we can tag it to one of the key risks that are reported to the board, then very quickly we create that chain that allows you to have a narrative to actually work on a fix. And I think that's where we should be in those conversations because often you report those gaps without GRC even being able to help. Because we don't know or we don't care, which is worse. So being in those conversations allows you also to have more tools in your tool belt to try to push forward with those tools. Yeah, you're right. It's true.
SPEAKER_02You're already in a you're already you're already in a better position because your that's your main sole job is to constantly be reporting on the the the known gaps. And and and you do it every every you know, the frequency of it is for something extremely important, like as an audit, which bec and the failure of that audit can really create a lot of risk to the or a lot of impact to the organization. And so you're already in a situation where you're gonna be heard. Whereas the detection engineer, every single day, it's more of a day-to-day function, and it's like we're constantly ringing the bell and everything may that's where you kind of have to pick your battles, like inside uh otherwise you're gonna be known as. Have you heard of the of that story? The boy, the boy who cried wolf. So it's like you almost have to pick your battles and know when to ring the alarm at the right times, and yeah, so it's you're in already a better situation to get heard. So I'm jealous.
SPEAKER_00Yeah, exactly. But that's where we need to give you the tools so you can also have the same thing. Exactly.
SPEAKER_02So we should be working together more because of that. But our worlds collide though in another uncomfortable way. You were talking, you talked a little bit about the sampling. Um which is uh it's a scary thing to think about because you out of a small sample size, it may not always be representative of the full population size, right? So I it it I mean, it it can work in our favor sometimes, but at the end of the day, maybe that's not that's not a good thing. You write, you write about like how auditors check only like less than one percent of the environment and can and can at the end of the day certify you for 100% coverage. Yeah, we have something similar to that called miter playing miter bingo. We say, Yeah, we have 100% of the miter attack, but uh do we really? Maybe not.
SPEAKER_00Uh interesting, interesting. Yeah, because like for us, like what's weird is you need the certificate, you need to keep like SOC2 is an attestation, ISO certification, but it's kind of the same, right? It's like if you go on a website or like you see those badges and we have all of these and we're secure, and like there's a halo effect with them, right? If you see all of this and you actually say we're secure, we're compliant, like it creates something in the buyer's mind. It's like this company is a good company to buy to buy from and and stuff like that. But when you've been under the hood, and especially even you, you work in security, like often you've been involved in audits to some capacity, they bring you on photo call, and you see how it is in practice, you're like, Yeah, you know, it's uh it's okay, but probably not probably not looking at all the stuff over there that they should. And I think there's really this thing that when you know how it works under the hood, you know that the trust that we give to it is probably a bit overblown and probably a bit like inflated. But we still have to do it. But for me, what I want to work towards is the industry kind of aligning the incentive between like a full so population. So we test everything or we care about everything, especially now with the technical means we can. And also like we provide something that is meaningful to try to sell, like the more of the sales and able aspect, okay, having all those badges helps us sell more and stuff. Trying to find a better middle ground because right now I feel like JRC is a lot of sales.
SPEAKER_02100%. That what that also got me thinking about that I a post I read probably a year ago at this point, but I still think about it every day is there's breaches that happen left and right. And this you probably feel it more being from Europe because there's like things like GDPR that really keep people accountable. In the US, it's breaches are happening and happening and happening, and it's kind of like we all move on from it after a after a couple of months. Yeah, which is like, and and so it this this person was writing about it. She's Christina Murillo. She's like, security is so unserious, like until until it is, until until it happens for real. But after a while, it's like you know, we're moving on from every single from the last three or four breaches. People are not gonna cancel their T-Mobile account, like you know.
SPEAKER_00Exactly. The incentives means that at some point, like it's it we see that in JRC in the vendor review process. So you know there's a T parm process where we have to onboard vendors, like there's really this thing where if the business wants a vendor and this vendor has known vulnerabilities or like they've done crap, like if they really want the tool, like what's what's the leverage we have? It's like you will make a decision for me. Like, I prefer, I don't know, whatever. I prefer Miro to Figma or whatever. Like, who am I to say, like they've had a breach and like, but you won't use the tool? Like, I use the tool, I prefer this one, and whatever the breach, like compensating controls, but we'll buy it. And that's where at the end of the day, like people think with like whatever they care about, like you target breach, people still go to Target to buy stuff, right? It's like so it's like it's not for pro the breach approach, probably not the best way to get coverage now because it's so common that no one cares, you know. It's true.
SPEAKER_02The other other thing too is that I that I comes to mind is the inheriting inheriting. So for example, somebody that the target gets breached, they fire everybody in security, but and okay, sure. The new p the new people that come in, they now are inherit, are inheriting this program that they have to keep up with. And and and I I also call it like the ghost detection logic or detection debt and having to continue the ghost logic moving forward and never really having known why this detection was built in the first place, but I still have to babysit it for the next two, four years, depending on how long I stay in the company. And you just wrote something very similar about that, um, about inheriting like the your previous counterparts, GRC lead. Uh I I want to hear about that.
SPEAKER_00Yeah, it's it's very similar. Yeah, it's very similar. I think there's really this thing where uh and I think after reach is a very good point, also, like there's very this thing where whoever built your program, like your detection program or your GRC program, like when you come in after that has been built, like you if you want to continue the legacy or build on it, like there is so much context that you built upon that maybe you completely disagree with, or was built for a different era or actually failed. But then in many cases, like if you want to complete reshuffle everything, it could be a ton of work and you want to keep the lights on. So you incrementally change, which means often you add layers of crap for what's already been built. And in GRC is very often the case because the first person that built the program was built for a very different scale. So then now like the team is way bigger. Uh, you have like context is like tribal knowledge is not enough. Everyone needs to have documented processes everywhere, and none of it is done. So you document the crap process that only worked with one person and you scale it to six or seven, but it's the same like underlying logic, then you end up like literally like scaling things.
SPEAKER_02Yeah, you know, but the world is different now than it was when you wrote it a few weeks a few years ago. Yeah, 100%.
SPEAKER_00100%. The company itself might have been pivoting, you know. Like they literally the new company sometimes sell something different.
SPEAKER_02But they bought three more after that. They now became, or who what was that company that now is an AI company like Elon Musk now? Is that or who was it? They sell shoes, they sell shoes.
SPEAKER_00Yeah, it was like, yeah, yeah, yeah, exactly. That that one, that one. Yeah, that was funny. That's the one.
SPEAKER_02That comp man, I was gonna say that uh the when you do, I I call that the washing machine effect. It's like, okay, can your washing machine you also want it to you want it to do more and more and more and more. So I want it to also wash my my shoes. I want it to also wash maybe my dishes, and so you kind of configure it in a way where it can do more things, but then it becomes really shitty to everything.
SPEAKER_00Yeah, yeah. You at some point you need to like, you know, buy another machine uh or change it. Like you need to like at some point you need to take a step back and rebuild it. And I think with AI, going from zero to one is faster than before. So it's also easier to make sure if the program hasn't been standing on the right legs, to actually rebuild the legs because you can redo from scratch with the context and everything, and you can get to a certain point where you have to then tweak it. Whereas before, if I had to do everything manually, like remap the controls and do all this, it could be months and months of work.
SPEAKER_02I was also thinking, too, that your I feel like your open source project, I was I was I was exploring your GitHub the other day, and the the what it's like a cryptographic GRC type of immutable way to track these changes as you're making changes in your program. Like that that could be an answer, it's part of the answer to this. Because you know, it's it's to keep track of what changes were needed, why and when, even even if you know you outgrow the team there, even if they move on, the people that come, they all see exactly what was done in the past, they'll be able to pick right up from where you came from.
SPEAKER_00Yeah, that's a big part of it. Like, um so the goal, uh the first goal of that project uh called Court Corsair, might change the name, it's a bit weird. I like pirates, but that's not probably explaining what it does very well. But the goal of that project was like how I can exchange, because right now, if I need to trust you to buy your product, I look at the certifications you have and that stuff, right? And then I say, okay, I think they're secure, I'll onboard them. Like what I want to get to is where I can ingest actual data coming from tests that have been done on your systems and infrastructure and make the decision based on that. Because, like, to give an example, like if I test for a certification, like they test every control to the same depth. Okay, could be like an IAM control offboarding of like employees, or like, you know, do you have like I don't know, merge request approvals, you know, uh before you merge code to production. If me, I care a lot more about IAM that I care about encryption at rest. Maybe I want a lot more depth on one control domain and less depth on another one. I can't do that because I have one PDF, which is the certification. And in the certification, the auditor, they use their approach, whatever I don't know. So I want to the goal was for me to find a secure cryptographic way of exchanging that information so then I can consume those control, like control, uh like controls data, and then I can make my own decision. I'm like, okay, for I am, like the way you do privileged access management is not enough. I need this, this, this. But then for here, I'm fine. You know, I just accept as is. So then I can use my own wisp posture to determine where you fit in my landscape. Whereas right now, I just look at you have those badges and I send you a questionnaire, but I lack so much context on how those things work in practice.
SPEAKER_02I I feel like that's similar to I that's similar to the way we're committing to detection logic these days. Like detection is code, people call it, but it's really just keep the simplest way to put it is throwing a YAML file into a repo and then just keeping track of it over time and just making like comments about changes that you need to make to it for whatever reason. Uh, that's probably the simplest way to do it. You could get more mature with it and have like have a validate, like a validate Python file where it's it's it's it will test the syntax of your detection so it so you kind of know that it's still working, or maybe the pipeline data that's feeding that detection. You could you could get more mature with it, but the the simplest of ways is just to keep just even a text file of why you have that detection in the first place, what is it protecting you from, what domain is it for? Like, is it web? Is it cloud? Is it an endpoint one? And then just even just the exercise alone of keeping all of like an inventory of all of your detections, it it's it it organizes you in a way, and and you have a lot of context about what what all the coverage that you have across the board.
SPEAKER_00Yeah, and I think something in in in GRC that I see more now is like with AI, people are very eager to build, like get into the mode of building stuff. And really what you said about like keeping that inventory of like all the detection and stuff, like it's very important for GRC as well to have a log of all the decisions that were made, why did we make those trade-offs, like why the risk program looks this way, why we test this control this way, specific to XYZ stuff that happened. Because if you don't have that historicity, like then when you need to make a change, you might make a breaking change without knowing. And also there's a lot of cultural aspects that are infused in that, actually. And if you don't, if you don't account for that, you'll make mistakes that might create security, uh, put security in a completely like the wrong light because people used to have this context. You came in, you didn't know, you did this, and now everyone has security and you blocked on Slack.
SPEAKER_02Because that's what that's what actually AI is not good at. Knowing, knowing the like what who's talking to who at you know a nice rooftop in the Bay Area, and and what ext what exchange we pass, or I don't know, whenever you you get together with your team, you you come up with things, and AI's not a part of these conversations, or maybe, or maybe they will be, maybe they have like those like necklaces with the Oh yes, I've seen that. But uh AI doesn't have these this tribal knowledge of of the industry, it only has what you what you add into it, but nonetheless, it is coming for both of us. So we of course we have to talk about that and how that impacts you know both the grc and and DE game. Uh attack services are obviously expanding and growing faster than your certification cycles. In my case, uh it's now expanded on to now like Claude itself, like everyone in in marketing and everyone in sales and everybody in, I don't know, even even outside of it, like they're vibe coding their their things that they need. There's uh there's obviously unique ways to automate your job and they're and they're and if you just and if they're given a Claude Enterprise license, they're like vibe coding the crap out of everything. And that's that's that proliferation of access and without the visibility of what they're doing, or maybe them, you know, installing, like doing all this pip install to make their their apps like that, that's so scary. And and it's that's moving faster than what detection engineers can build detections for. And uh, and and in your case, I mean certification cycle. So that's I I feel like the AI bubble is gonna burst at some point. It I I feel like it's going to at any minute now, but it may but maybe I'm wrong. Like there, I've been keeping up with this poll that Jose Hernandez posted. And it's like, how are you protecting AI uh AI agents right now? And like the the options were through GPO or through EDR rules or through like an app uh control like app locker. I or and then but and then the last option was nothing yet, I haven't figured it out. That one is the highest selected.
SPEAKER_00Yeah, I can imagine. Yep, yeah, yeah. It's it's scary. You've seen, is it this week or the week before? There was this company, right? They they used Cursure and uh they deleted their database in prod plus the backups in like nine seconds or something like that.
SPEAKER_02I saw that because they didn't know what they were doing when they were vibe coding. So they're just like, yep, accept, accept, allow, allow, claude, allow. And and Claude may be asking you, hey, yeah, do you allow this? And they're saying yes without knowing what prerequisites they're installing. It's like dangerously skip permissions or like YOLO.
SPEAKER_00Yeah. And it becomes, I think, like the the dangerously skip permissions. I think it becomes more of the standard now. Feels like less and less people would have those guardrails when they say, Do you actually agree to this change? And then they click yes. Which means your job technically is becoming more and more critical because this stuff will come down your pipeline at any minute when they actually click send on the prompt, and then you know, all. This stuff is built, but in nine seconds, it's a bit it's a bit tough for you to detect and respond, you know.
SPEAKER_02I think the bubble's gonna burst. I think that there's gonna, I don't know, we're gonna, it's it's it this is not sustainable for so long, you know. I it it can't be. I I don't I I have maybe I have a very negative or pessimistic opinion of it, but I it's gonna burst at some point. I don't believe that it's gonna be like Sam Altman says, where it's like AI is gonna be like a utility bill, like you that you pay for. I'm like or maybe I don't know. Oh, yeah, yeah. I I I have a little bit more faith in humanity than that, but yeah, I think I I think uh I think you'll probably course correct in a sense.
SPEAKER_00I I think what will probably change it, I I you know there's so many things are breaking with that speed. I think even people are seeing like issues with GitHub, like it's been down so much, issues around like reliability of the platform. It feels like yeah, and I think what is difficult is uh the usage, like the the infrastructure we had, so Git and all these things, they were built for a certain amount of velocity. And I think now like everyone and their cousins they're using all those tools, which means they're all having to push stuff to GitHub and they don't even know what GitHub is, which means like the infra on which we've built, like kind of developer world and all this, like it's being stress tested in in real time. And I think many things they probably won't stay. I I know that the ex-CEO of GitHub is trying to build a replacement to Git itself, which is like agent native, which are a different way of reviewing code diffs and all these things. And I don't know, there's so many things that have been the backbone of like kind of like the software industry for like 10, 20 years that might not exist in three, four years. Feels like the change is coming, and like even in GRC, I'm I'm I'm really trying to think about like okay, tomorrow agents are making those decisions. Like, how do I actually think about like accepting a risk when it's an agent that took the risk? Like, they don't go to jail if something goes down. Like right now, the CFO might accept the risk, but like if it's an agent, like okay, I can tie it to a human identity somehow, like whoever launched that agent. But like I was thinking of like how we can embed compliance metadata into like tool calls, and but it's like a very different way of thinking about GRC. But you know, just thinking to myself in a mirror sometimes, just chatting by this thing.
SPEAKER_02Well, we're gonna have to keep contemplating these parallels. Are you coming to Black Hat this this summer? Or was one one one big conference good enough for you for the rest of the year?
SPEAKER_00Yeah, I've never done Black Hat USA. I do the one in London where it's very small, uh, but I really want to do it. It was my first RSA, and then I'm like, okay, I want to do DEF CON also as well. Kind of, you know, I did so I spoke at RSA this year. I spoke at Black Hat Europe two two and a half years ago. I'm like, if I can get a jersey talk at DEF CON, that would be that would be crazy, but that would be great. We'll find some way of like doing red team in Jersey or something fun. Um I'm hacking to a car and then you get you will get a certification out of it.
SPEAKER_02That's definitely the favorite conference. Hacking, they're very hacky people, I will say. Uh, but there the crossover's gotta be there. So I do I do hope you make it. A hack hacker summer camp is is truly an unmatched experience to have.
SPEAKER_00That's what I've heard from everyone. I've been to Vegas once for uh a company offsite, so yeah, I I know my way around Vegas, but I haven't done it for Harker Summer Camp. It probably is a unique experience.
SPEAKER_02I keep getting asked from people like, what what I'm going to DEF CON for the first time? Like, what should I bring? I was like, Deodorant. Bring deodorant. Because it's so it's so bad. Like, I wouldn't mind Vegas going to Vegas for because every big major conference happens in Vegas, I feel like that's probably the best city that's well suited for having so many hotels hosting so many people at once.
SPEAKER_00That's true.
SPEAKER_02And so it's like, but why I wouldn't mind it so much to go if it's during the winter, but it's like we go in the worst of summer.
SPEAKER_00Yeah, August is a real choice. It's yeah, it's like wow, yeah.
SPEAKER_02I so I do hope you go. I'll be there for sure. We're I'm I'm I'm planning some some big things around around DEF CON uh for the pod. So we've reached the end of the episode. Thank you so much for coming on. This has been everything that I wanted this crossover to be. And for anyone listening who came in skeptical that GRC is still a passenger princess, I think we kind of shot those claims down. It's a lot more sophisticated than I thought, for sure.
SPEAKER_00I hope. I hope. And I want to say, like, passenger princess is like an amazing uh metaphor. And the first time I heard it is from you. I've been using it since then. I always like, oh, it's from Alex. This is great. I like it. I want to shut it down, but it's very active.
SPEAKER_02So that's why I like ThoughtCon, uh, which is another hacky hacker type of conference in Chicago. Uh but it's not. I learned today that it's just as much of a science and it does cross over with more like change culture, which I think is a beast in and of itself. It's so much more difficult to do than detection engineering telemetry wrangling it in a different way, I guess. But I think fundamentally we're both trying to answer the same question, right? Is this supposed to be working? Right? Is is you know, are is the protection mechanism working as it should be? And you do it through controls, DEs ask it through data. And uh just overall, there there's sometimes no hallway in between us, but I I think there definitely should be. So thank you so much for creating that space for us today. Uh for those uh for our listeners, where can they find you? Where can people read more about you and steal more of your frameworks?
SPEAKER_00Of course. So on LinkedIn, I'm fairly active, might be less active. I'm in a new job. We'll see how it changes. But so I have the podcast Jarse Engineer on the on YouTube, Spotify, many places, and then the newsletter is on jarcengineer.com. So I publish once a week. Uh, hopefully, my goal is for people that are not in GRC to actually like it more and find angles that they enjoy. And yeah, when I was uh uh RSA, I had so many CISOs are like you only JRC person I actually like because you're talking to me more. I was like, that's both sad and interesting because you have a JRC team under you, which is sad to say that. But I was like, that's also good. Like my goal is really to make it interesting again for people, uh, and for JRC folks to have more impact, you know, to work on cooler projects and be more recognized. You know, if you get a raise because of uh my stuff, I yeah, I won't need anything. Uh yeah, a coffee, a coffee, uh you know, a V60, V60 filter when we meet. That's fine.
SPEAKER_02GRC great again. You can find all of the newsletter, the podcast, the the I mean, the coursar GitHub is pretty cool too. All of it will be linked in the show notes. Uh, and if you do want some advice of where to start in terms of your newsletter, I think that the most like detection engineering adjacent piece is the your like what if compliance was just a query uh newsletter. I think that was a fantastic post. And then go find the PVE PvP essay. That was also really good.