Name: Ask Me Anything #13: How to Build & Scale High-Performing Security Teams
Uploaded: 2025-04-30T19:20:41.555Z
Duration: 56 min 44 s
Description: Ask Me Anything #13: How to Build & Scale High-Performing Security Teams

Transcript for "Ask Me Anything #13: How to Build & Scale High-Performing Security Teams": Hi, everyone. Thank you for joining us today. I'm just gonna give everyone a minute, to join. Alright. Hello, and welcome to today's Ask Me Anything session, how to build and scale high performance security teams. Before I hand things over to our speakers, I'm just gonna go over a few items. If You do have any questions throughout the broadcast, please submit them through the q and a tab on the right hand side of the webinar console. We will be recording today's session, so be on the lookout for an email with a link later this week. With that, I'll hand things over to our host, Andrew Mundell, to kick things off. Fantastic. Thank you so much, Taylor, and welcome, everybody. Thanks for joining us again on one of our AMA sessions here. Really excited to get into this with all of you. And as always, we have a a fantastic speaker today. I'm gonna tee you up in just a second, Chris. I'll just a little bit. This one's really, really interesting because as you all know, what we've been trying to do is kinda really get into some of the interesting questions not just related to Sophos stuff, but stuff that's happening in the industry and trends. And and there has been one thing that's come out of all of the previous AMAs that we've done, and that is people are really interested in understanding what a security team actually does, what it needs to do, and, spoiler alert for how we'll we'll wrap this whole session up, how to get started. And I can't think of anyone better to help us answer those questions than our very special guests today. Chris, thanks so much for joining us, and, I would love if you could introduce yourself to everybody. Tell us, what it is you do for Sophos and, of course, where in the world you're joining us from. Absolutely. Thank you so much for having me. It's, it's great to be here. Hey, everyone. So yeah. So I'm Chris. I am the, VP of, security operations at Sophos. And that means I, lead and support the team who, performs all of our internal security at Sophos. So we protect the company of Sophos. We also protect our products and deployments as well and all of our kind of delivery pipelines that support them too. So really fascinating area to be protecting. It's a very interesting job and and and certainly for me, it's one of the most interesting jobs I've done in my kind of career. I'm I'm a I'm a career long blue teamer. I've always been on the kind of defensive security side of things. It's really interesting to do security for a security company as well because there's a lot of cool experts in this organization I get to work with. But, yeah, my background, and I'd say be been in security operations pretty much my whole life. Started my cyber security journey in, central government working for what was at the time referred to as GovCert UK. Went through lots of different transitions, and nowadays, we're referred to as NCSC UK. So I spent, my my final year in government was actually working in the first year of what NCSC was, which was really cool. And then after that, I spent a bit of time, in a, a tech start up, which is kind of the complete opposite end of doing government work, which was another another fascinating experience. But, again, just doing security operations there, building teams that can do threat intelligence at scale and how to implement those in in sort of security toolings and those sorts of things. And, and, yeah, and I spent a couple of years doing some big tech stuff. That was fun. And just before I joined Sophos, I was working at Google in the Google Cloud area and working on threat intelligence side of things. So, yeah, I've had a bit of a broad experience in this sort of area. It's something which I I I often find myself having to build teams around these problems and figuring out how to how to solve complex issues. I hope I bring some some valuable experience into that conversation to help out a little bit. Oh gosh. And, yes, where I am, I I'm I'm dialing in today from from Manchester in The UK. It's fantastic. One of the one of the perks of working at Sophos is we're very remote first. So I get to dial in from my, my weird I call it the workshop. I've got lots of stuff going on in here. But, yeah, it's, it's, it's from Manchester in The UK. So, yeah, great great to see you all, and, yeah, looking forward to a good discussion. Thanks so much, Chris. The workshop, very intriguing. That almost sounds like it's gonna need an entire other show and tell AMA Yeah. Just to talk about the cool stuff. It's it's a lot nerdier than you think it is and and not in a not in necessarily in a good way. It's I mean, that could that could go either way. My line of paper is just outside of my grasp, so I can't get to it right now. But, yeah, I You got a good backdrop too. Yeah. I thought there was a reason I liked you, Chris. So, let's let's get started with you mentioned kinda your your really interesting mission of protecting Sophos as an enterprise, but also protecting Sophos as a vendor. Most enterprises don't have hundreds of thousands of firewalls and tens of millions of endpoints that that also sit under that that security team umbrella. But I'd love to wind it back a little bit and ask, how did we get here? Why why are we doing this? What what are some of the reasons why we we need such big security teams, what's happened in the last few years? Yeah. It's it's a really good question. It's something which, you know, to a large extent, I'm always reflective of in in sort of cybersecurity. We have so much technology, so much amazing stuff that's that's being done and all these amazing tools that sort of, you know, help us do what we're doing. At the end of the day, you know, we still build teams of experts to help us solve these problems. And and I think that, you know, that that speaks to a couple of things. I think, first of all, it speaks to, the complexity of the problem. You know, this is this is a problem that requires smart people to come up with smart solutions to these things, and no one tool is ever gonna fix that. And I say I say that as an employee of Sophos. I mean this with the greatest respect to to the Sophos tool sets, which we use and we make, you know, a huge huge value from as well. But at the end of the day, it's a really kind of, like, land that impact and understanding into the business. There needs to be smart people making smart decisions along the way, enabled by the tech. Absolutely. But but I think that's something which, you know, bridging that gap between the technical problem and the business impacts will will will you know, is a perennial problem. It's something which we're still still actively solving. I I mean, that's the first thing. And and the second part to this as well is, as you say, like, in recent years, you know, you don't have to you throw a rock and you and you'll hit, like, a bunch of different incidents that that happened where it was kinda like, oh, the issue was something that just was, you know, completely out of scope of any tools that we were running. And I'm not talking about crazy zero days or anything. I'm talking about, like, you know, like, it was a human process. Like, I don't know. Someone clicked a link on a phishing email and something, you know, and then and then some more nefarious stuff happened. These these are hard problems, and they require smart people to solve these these problems. And every single, like, instance and implementation is slightly different and slightly worse. And and then when you add into that fact that you've also got an adversary that is constantly evolving and constantly improving its TTPs, we are literally in a a constant arms race against these folks who are who are coming up with these cool ways of doing things. So we need other people who are coming up with cool ways of fixing that, right, and coming up with cool ways of designing it. So, yes, the tech's there. Yes. We can do lots and lots with the tech nowadays, but we'll always have these major instances. We'll always have these people trying to innovate beyond us. So even if the innovation is just making better tech, we're still gonna need people who are there who understand this and can help us join the dots between the technical and the business impact. That's that's my view anyway. I think it's it's a really interesting point you raised there talking about business impact and business context. Yeah. Literally, I was having a conversation earlier with someone, in a vulnerability vulnerability management discussion, and we were talking there about how how important it is to help, organizations understand the difference between what might be a a nine CVE on an endpoint and a nine CVE on your web facing, Internet facing web server. Yeah. Totally. Totally. Yeah. I I think sorry. Sorry. Yeah. No. I just I I totally agree. I I I've got vivid memories of of being sort of told, oh, there's this, you know, CVSS9.nine, and you absolutely have to respond to this now. And I'm like, it requires physical access to the machine, my dude. Like, I'm so sorry, but no. This, this doesn't blip on my radar. And that was a different world where everything was in a bubble and and, you know, no one could physically access the device. But, you know, yeah, you're absolutely right. The context is key. And and and to a large part, you know, there's a lot of work going on to try and understand that context in a in a programmatic way and in a in a systemic way, and I applaud those efforts. We should continue to do good asset management and good you know, we have a CVSS. We should also have a CWE. You know, we should look at e EPS. Sorry. I've done that TLA thing again, haven't I? Like, you know, there's all these acronyms. You know? So when we have, like, you know, a a vulnerability, we should look at the weakness profile of that. That weakness is then mapped to our assets as well. And then we should also look at, the exploitability of those, vulnerabilities too, and we should factor that into our decision making. There's standards and there's processes for being able to capture this information. But but at the moment, at least, this is still a a a process that requires us to kind of, like, apply our own logic and and our own context around that to make it work. Even when you've got a tool, you're still gonna have to create a profile on top of that of what that looks like. And by the way, that probably changes every day. So, yeah, I I there's there's a massive role there, and and as much as technology can help us, like, you know, optimize that and and increase the efficiency, that expertise is gonna be invaluable. Chris and I are are workshopping some, some stand up comedy sketches incidentally about TLAs in the tech industry. So sorry that bled into the presentation a little bit. Maybe maybe you'll, you'll catch us on tour at, you know, next year's Edinburgh Edinburgh best tour on SEL. Yeah. I mean, I'm gonna ask. Sorry. That business context piece though because I think one thing that's that's really difficult often is we talk about ransomware actors. We talk about and, from a from a previous AMA, my go to, non offensive ransomware actor is placebo Dolphin. Long term long term AMA fans might recognize where that one came from. So when we're thinking about all those things and we're thinking about TTPs and the the CVSS scores, it can be really overwhelming for business the business people, especially in a smaller organization. Now, Chris, you're you're lucky that we've got we've got some pretty tech people senior in in Sophos, but how would you advise, tech folks, security folk to think of explaining those and and maybe using some metrics to help take the take that risk conversation upwards in their organization? Yeah. That's a great question. And although although as lucky as I am to have lots of technical colleagues around me to help me out with this, that comes with its own set of, of of, challenges sometimes too. Just throwing that out there, and then some people in your audience may relate to that too. But yeah. No. It's a great question. Like, translating that to the business is is really critical. I think I think the you know? Yeah. So so first and foremost, like, that quantification that you can do is really valuable in this process. So so so being able to provide data to back up the the the broader conversation around these sort of just take an example of a vulnerability. You know, how widely are we affected by this, being able to do those scans and understanding your arc you know, your your your asset register and your kind of architecture well enough to be able to say where that applies, you know, having the statistics of how many effective instances you might have, being able to provide an an additional level of kind of business impact over what those instances might look like. So, for example, is this a vulnerability on a domain controller, which is like, hey. This is a problem, or is this a vulnerability on, you know, some r and d device that no one really uses? You know, I that that flavor, that context will start to give a little bit of value there, and and there's lots of good ways of being able to kind of start to quantify that a little bit, putting in some, you know, even just the basic high, medium, and low impact type measures. But if you're really good, you'll have, like, a an instant response plan that will equip you with a sort of a a predefined, precanned understanding of what Sevilla looks like. So a lot of a lot of organizations, those included, use SEV levels to describe that. So Sev three two you know, three two one zero zero being the worst type thing like world ending event. And and building that instant response plan ahead of time and defining those different levels of severity, and trying to come up with some sort of quantification. It's always hard, but, like, coming up with some some sort of quantification that gives a a relative impact to the business. But, again, as you say, you can kinda, like, translate it to those senior folks who are maybe a bit less technical, so to say, like, bright. I don't know. Let's say let's say this affects our customer base and let's say it affects, you know, over 50% of our customer base, would you call that a SEV one or a SEV two? By the way, you know, SEV SEV two is sort of severe and sev one is ultra severe. Like, you know, just finding that that wording that you can use to sort of communicate with the business is really valuable. But as I've implied, like, with a instant response plan, you kinda need to do that ahead of time. Right? Like, there's there's it's it's, you know, woe betide someone that's setting those criteria up mid incident. Right? Like, this is part of the and and for the for the audience that's interested in this stuff, the instant response life cycle is is definitely a way to go for this. Right? And preparation is that first step. Get in there, build that instant response plan, socialize it amongst those leadership, make sure they're under they understand those different sub levels. And then for your team, as it comes in, just get really practiced and really drilled at quantifying those different threats, putting them against that established criteria, and then you can go back to them and say, like, hey. Remember we agreed that topic of a SEV two versus a SEV one? Well, this is a SEV one, and then they'll hopefully just be the, oh, I get it. Okay. Cool. And you can just crack on and and get on with it. But yeah. But that requires a little bit of thought. That requires that understanding of, putting it in the context of the business, putting it in the context of ideally, putting it in the context of pounds, you know, like, literally or or dollars or or whatever your currency of choice is. You know, find finding that way of communicating it to the business impact in a way that makes it very, very clear for people. And if you can, then making it, still quite honest to the security message is key because sometimes you can also, you know, make it a little bit too vague when you start talking about money and you start saying like, oh, it's got a a million pounds worth of impact. And it's kinda like, well, from a security perspective, I've kind of, you know, I've I've I've used a little bit of artistic license to say what impact looks like there, you know, and we all know what that feels like. So finding something that you can be confident is, you know, from a security perspective is genuinely technically true, but also translates to that business profile and putting it into that instant response plan nice and early so you've got got that agreed language. I think that's the best way to look at it, to be frank. And to be fair, we do that for a technical leadership as well as a a nontechnical leadership because technical doesn't always mean security impact savvy. That's something which we need to bear in mind too. Very, very talented engineers who just wanna get the products out there, and we're having to stop them in their tracks because it's a security issue. I wanna have a common language over that person before I start challenging them on that. That's that's more of a self preservation thing than anything else. I love that you talk about the the common language. I know that's one thing that that we talk about a lot on the solutions engineering side. You know, MITRE gives us this this common language when we're talking through attacks. For organizations that are just trying to get started, I know there's a lot of different standards, organizations, and frameworks out there. Could you talk a little bit about, like, what does does Sophos use one of those? If so, why? And and perhaps what would be some good ones for folks in the audience to to go take a look at to help them build out some of that framework and start getting that that common language? Yeah. Well, you know, that that's that's this is this is a huge part of the role. I I really believe that. And I every time someone talks to me about standards, I just think about the SKCD sketch with the kind of like, you know, we have 14 competing standards. Right. We need one standard to fix all this. Right. We now have 15 competing standards. And it is it is always a bit of a perennial problem. This, you know, they're there for a reason. They're there to give us, as you say, that kind of common language, and I think that if there was one that I could point to that's worked really well, you know, I don't really like to call it standard, but it's a framework. You know, the MITRE ATTACK framework is is good. You know, it is it gives us a nomenclature more than anything else. It just gives us an ontology to talk about these threats in a in a structured way, in a way that just means when I say fishing, this is what I mean. When I say whaling, this is what I mean. There's a there's a it's a lexicon more than anything else, and that's valuable just for just for establishing what those core kind of mission verbs are, like what we're gonna do. So so that really, really helps. And I and I think that, you know, don't get me wrong, it can be used very negatively. It can be used in a way that is like, you know, you know, fear, uncertainty, and doubt. Like, if you're, like, not covering the entire heat map of the MITRE attack ecosphere, then you're doing it wrong. That's not what it's there for. What it's there for really is just being able to tag certain threats in certain ways so that we all understand what that threat is and what that means. MITRE ATT and CK repository goes well beyond just, tactics and techniques, by the way. They've got a fantastic knowledge base over at MITRE. I've I've worked with them for a long time. They're a great organization. And if you go and look at their stuff, they'll even have, like, free sort of open source threat intelligence, you know, a group and campaign attribution, you know, data, which again, because of the way that they've structured it, all links to the the MITRE ATT and CK framework as well. So so actually, you know, it's it's when done properly, this stuff can be extremely useful. Extremely, like, deployable and very, very, effective for operational teams. You know, there's lots and lots of standards that don't fit that criteria that are there just basically to kind of, I don't know, tick some compliance boxes, but there's some of them that have been built very, very well, and the MITRE MITRE one is one of them. And, incidentally, all that data that that they've got saved on they've actually got it on the GitHub account. I'll try and get the link out actually as part of the follow-up for this. But, yeah, they've got it they've got it on their GitHub accounts, and it's all stored in a in a data format, which is another standard, which I really love, which is the STIX format, which is the Structured Threat Intelligence Expression Language. And when we talk about standards, you know, that's the kind of thing which is extremely interesting for me is is, like, we have a framework in terms of how we talk about things, and then we have standards that can help us build, you know, interfaces between tools. So when I talked before about quantifying the impact, being able to do that at scale often requires that standardized data format that can help us do that. And and that's hard. You know, that's building tools that build data formats and data schemers in a certain way. But, actually, MITRE ATT and CK is the easy one. This is the one where you just apply, like, tags to data. You get that organized in such a way that you can sort sort of talk about the threats in the in the same way as someone else. That's the easy one. So this is before we deal with the real, you know, complex stuff of, like, oh, you call this threat act, fancy fish, and you call it, like, sleepy llama or whatever. That's that's that's a hard problem. But even before that, just doing that tactics and techniques stuff, getting the labeling in there, that's a massive step forward. So even if people are just doing that for their detection libraries right now, that's that's a huge step in the right direction. And I think shout out to MITRE for defend as well. A really good framework for for mapping kind of that next that next I said the next level down or the next level up? The next level of, of of kind of applicable capabilities. Great example. Yeah. Really good. I love I love the stuff they do. They they come up with some great, great stuff. I'm really a massive MITRE fan. Yeah. It's fantastic. I know we're we're always excited to see what they dream up in some of the, the evaluations that they do for the industry. So, yeah, big big fans of MITRE over here as well. Now, Chris, you mentioned they're at scale, and, obviously, one of the one of the the words in the title of this session is talking about building up this capability, at scale. We had one question come in that actually is is kind of the opposite of that. It's, an organization with a really small team, but I think I think the question could apply to any team at all. And it's talking about team structure. How do you keep the team together? How do you keep the team focused on the goals? And not to steal some answers from earlier in terms of having the same capability, but I'd love to to kinda dive in into your experience a bit more at that human level. When you've got a bunch of folks, you know, working really hard all the time to to try and deliver some of these, deliver some of these programs, How do you how do you maintain some some good some good teamwork across that team? Yeah. My goodness. Yeah. If you know how to answer that question, let's write a book. I think I yeah. What a what a what a challenging question. I mean, like, you know, first and foremost, we we've gotta recognize here that security is a is a is a is a hard job, and you gotta be a a, you've got to be. It it it it helps to be a certain sort of type of person, really, who likes to help people. Right? Who wants to collaborate, who wants to get involved and get stuck into a problem and help each other out here. You know, diversity of thought is is critical to a security team. You you you want people who are going to collaborate together, come in with different mindsets, different ideas, and different backgrounds, and different perspectives. The last thing I want is, you know, clones, like, you know, people that think the same way and have always worked the same way, and I and I certainly don't want people to work in isolation. So so, yeah, I think I think this is a great question because it is a % what you've gotta be doing with these security teams is finding that diversity of thought. And then when you've got this massive mix of all these different people and personalities, finding a way for them to collaborate together, is tough. But but, you know, like, that's the first thing is, you know, making sure we pick people and and build teams of people who are just good people, who work together. It reminds me of a Simon Sinek, presentation, one of his one of his early ones about, you know, do you take competence or do you take trust? And I'll always take a a hit on competence if you know, because I can train people. Right? I can teach people stuff. I'll always take a hit on competence if it means I can get people I can trust and I can, you know, work with. And and that's really critical. But, hey, let's say you've done that and you got your team and you're trying to make them them function together. It's it's challenging, and especially in in a modern scenario where we've got, like, a lot of hybrid working and a lot of people working from home, that's been something which we've been struggling with, you know, in as a as an industry for a while, as a community, I should say, rather than industry. And I think I think that, you know, first of all, you gotta recognize that we've just got a a job to do here. So there are certain principles that you can start to build around this where, you know, are very common, and these are skill sets you'll get from lots of different places. Having a repository of work to do as a security team, is something that can, you know, is is often overlooked. You know, it's like this kind of, like, you just do security. You respond to incidents. If you're if you if you go in in that reactive mindset, it's gonna be very difficult to kind of, like, really keep track of, like, what is the work you're working on right now and how are you keeping track of it. So it sounds really obvious, but, like, the main the main job of a SIM capability or, you know, a security incident management capability, any case management capability, is to, kind of align the team to the body of work that you have to do and to get normalized on what that backlog looks like and what that kind of process looks like. I think that's an often overlooked and very important first step. You know, people say the team is dead, and I understand the motivation behind saying that. But the thing that isn't dead is the need to, align on a corpus of work that you're doing. Because only in doing that will you be able to prioritize, triage, you know, figure out what things, you know, need to be booked at first. And then very importantly, if you're a diverse team of people, assign the right work to the right people and get started on it, and, indeed, collaborate on that work. And this is where, for in my career at least, and and yeah. I'm I'm obviously gonna sort of say what's worked for me, but the thing I really enjoyed working is, I I take a lot from agile in this. You know? And, like, agile approaches to in software development are all about having, like, a backlog of work. You know, you have daily stand ups where you sort of talk about progress being made against different tasks. You have the opportunity to contribute to other people's work, you know, and and there isn't very much a kind of like a hierarchical approach to being tasked things. It's just like there's the work, and we all contribute to it, and we kind of work it down. I take a lot of inspiration from from the agile methodologies in our in our approach because it encourages that collaboration and that sort of diversity of thought. And then if you can also then instill in the team the ability to understand the concept of prioritization, that instant response plan we talked about before, then that can also help sort of, like, you know, really channel channel people in the right direction. And that whole kinda, like, mission command approach where you sort of, like, you set the objective, you set the work to do, you give them the guidelines, and then you allow them to execute within it, that's that's like chef chef's kiss moments sort of for me. Like, that's a really powerful team. That's the team that's working, you know, with with, they can they can be individual, they can be autonomous, they can drive ahead, and they do things. Because in this operational environment that we're in, it's that thing that we missed because, you know, we thought we were controlling everything top down, and we had a handle on everything, but it but it was that thing over there that we missed. I'm not gonna spot that. It's gonna be one of my, you know, awesome, amazing, diverse team who spotted that and picked it up and then and then called it out. So I wanna create an environment where I can just encourage more people to say those sorts of things and have the have the safety to do that. But, hey, that that's my way of doing things. In a lot of places, it's it's doesn't work that way because you need to be very compliance oriented. You need to, like, focus on how you like delivering against security, and and and I totally get that. That's that's a balance to strike as well. But I think that the most successful teams, especially ones that are, like, you know, that that that work at scale, that are, you know, heavily resilient are the ones that really do sort of, like, empower their people to sort of, like, figure these problems out because that's that's how we breed skill. That's how we really secure things, in my opinion. I I love that. I think just making sure that everybody understands, like, the big picture. This is this is where we're going. And I think giving everyone a chance to to actually influence that beyond just well, today, you've got you've gotta just keep hitting refresh on this ticket queue until you get to zero. Like, that just that sounds like a bad day, like a rough day. Yeah. And and you're not gonna get the scalability that you want out of that. You know, we we we've thought oh, gosh. I'm gonna have to mention AI. I'm really sorry. I know that I know that we were talking about minutes. We made twenty eight minutes before you get to AI. I'm so sorry. Hey. If you wanna, you know, if you wanna do that, if you wanna keep refreshing your queue and then work through tickets, then then that's an AI task. Right? Like and frankly, it's not even an AI task. It's it's even just a just a script. You know, so so I really do believe that if we're if that's the conversation we're having, there's only so many, like, you know, pizza parties and and, you know, casual Fridays that will that will get you through that. But notwithstanding, there are specific things that we need people to do certain times. Right? So there are compliance orders we have to do. There are things that we need to do where we are, like, you know, satisfying, like, criteria. I just feel like we can do that at the same time as supporting that open culture and that sort of, like, you know, driving towards, like, something where you can sort of spot the difference. Yeah. It's it's a it's a tough one, but it's definitely, it's a it's a balancing act for sure. But, but, yeah, I strongly believe that it's gotta be about that diverse team. We got I we're we're so close. So AI slipped in slipped in there just such as under the whole thing. We're really close to me going on my, my IOC automation rant, but I'm gonna hold it in. Gonna hold it in. It. Oh, let's do it. So I'll do I'll do the quick version of this for everybody. No. And, Chris, I'm gonna look at you and and hope that you nod when I say this. Quick reminder, everybody. No human should ever copy and paste an IOC, a hash, of a file or an IP address into a system and search for it. That's humans should not do that. I I On a triage basis, that shouldn't be the first place of triage. I I agree, and also Oh. Some people have to. Right? Like, it's just and and this is the thing. It's like like, I I I remember having a similar debate around, I was working in an organization, and we were still using spreadsheets to coordinate our IOCs. And someone came in I know, I know, it's cringe. Right? But and someone someone came in, you know, comes in from the outside, never worked a day in our office in their in their life, and they come in and they say, oh, you're using using spreadsheets and you're copying and pasting them in? And it's like, well, number one, before you got here, this was a paper system, and we were manually typing this stuff in. So this is a massive improvement. Number two, we have to use spreadsheets because we don't have any other technology that we can install on these devices because these are secure controlled devices, and we can't install the software that we want. So so this is the best we've got. Number three, here's the list of macros that I've written in the background that are automating the crap out of all of this stuff, excuse my language, and and doing a really good job. Like like, I I honestly I have a lot of time for people who have to do these things and make it work. But, yes, I absolutely agree with your principle on this one. Like, if you are if you are manually copying and pasting IOCs from, like, a report or something and then putting them into a search feature yeah. I hear you. Totally agree with you. But, like, shout shout out to the people that are struggling in difficult environments to to make it work, and that's the best that they can do. Copying and pasting is better than manual typing any day. Love it. Thank you for the, thank you for the gentle correction there. I I I look down a little bit. I I have a a a really interesting question that that they came through, and I will confess this came in from a colleague. And it's not an easy question, Chris. Prepare yourself. Okay. I love this one though. Throughout your career, what's what's one mistake you've made building a team that you think, hey, you're out there doing this, folks. If you're building a team, to to to operate for security, don't don't do this. Oh, yeah. That's a question. I think don't do it. Well, I don't wanna say don't do it because at the end of the day, what what didn't work for me, you know, could very well work for someone else. Right? And and I think that it a lot of it a lot of it is down to context. I think the don't do it part was oh, gosh. This is a tough one. So so I do remember building a team where we were very much focused on on the the kind of, like, the the the queue refreshing thing. And I think that one of the things that I did at that point was I I introduced some metrics. Now metrics are good in operations, right, because they help us tell us, like, you know, where the bottlenecks are, and they help us kinda, like, you know, make sure that we're, working at the efficiencies that we need to and all the rest of it. The thing is is I kind of introduced these metrics in a in a slightly more competition sort of way, And and I was sort of comparing it in terms of, like, well, so and so has resolved this many incidents, and you've only resolved that many incidents. Yeah. And and and I thought I was doing it, like, in a smart way because I would, like, weight them based on, like, severity. I would sort of say, like, well, you know, if they did a if they did a couple of, you know, highs, then that that, you know, outweighs, like, you know, or, you know, they did more lows, so that kinda weights up, you know, for for a high. I think I started to gamify it a little bit too much. Now, again, I wanna be really clear that, like, you know, metrics are very important in operations. They really help kind of process things, as I say, with, like, you know, you know, when you find bottlenecks or indeed when you, you know, if someone does need help in terms of kind of the process, they're all working. But I think that for me and the the thing I would warn people away from is over indexing too much, especially on volumes. Because at the end of the day, this arbitrary thing that we call an incident that we happen to assign a ticket to is is is our own internal definition and doesn't really measure impact. Focus on the impact that you're having as a security team. That's a hard question to answer because measuring security impact is difficult. You know, I've I've got this white rock and it keeps tigers away. Prove that I'm wrong, you know, is a is a problem. You know, the lack of incidents is is a good thing, but is that impact? I don't know. Like, that's a hard problem, like, figuring out what that metric really should be, but it shouldn't be just measuring the number of incidents you deal with. And and I'm and I learned that mistake at my peril where we where we ended up, you know, really suggesting that people weren't doing a good job because they weren't managing enough incidents. But then when I dug into it and I found out what instance they were managing, they were severely impactful, and they would they would thank goodness they were working on those incidents. So I learned that lesson pretty quickly. But I think that, you know, again, it's it's finding that balance between, like, doing that metric management but not over indexing on it. I think that's a fantastic answer. Thank you. You're welcome. I'm gonna go to a a live question that came in, Albert. Albert, forgive me. I'm gonna I'm gonna tweak your question just a little bit to widen the scope. So, Chris, the things we do is we obviously contract with with external organizations to help us with pen testing, to help us with assurance of various things. Albert is asking a question specific to to DevOps pipelines, but I'd love to to get your thoughts on that more widely. How do what is your perspective in working with those those organizations and when it comes to openness and and and transparency to to really make the most out of that investment? Yeah. That's a good question. So you mean, like, sort of working with a third party security provider that might be doing pen testing or something for us and how much we share in return, that sort of thing. Is that is that right? No. I think that'd be good. Yeah. Yeah. It is a tough one. So, yeah, we we work with a lot of, of external organizations, and I think that probably the area that we work with a lot of third party you know, the most, I think, third party is in the sort of security research community. So so those of you aren't aware, we actually have a bug bounty programmer. Sophos, massive fan of it. It's run by a colleague of mine, David Davidson. It's an awesome piece of work. You know, we we will regularly get external pen testers. We'll also get individual security researchers and all sorts of folks who will come in and sort of say, like, hey. You don't think you found something, and then we'll have to work with them to sort of figure out what that problem is. Fantastic sort of resource. Love that community. It really, really works wonders. And, yeah, we we realized over time that we get out what we put into those relationships. So the more the more open we can be with those those in sometimes just individuals, other times companies and organizations, the more open we can be, the more value we'll get out of them. So we've we've really taken approach here to be as as upfront as we possibly can. The the thing that we absolutely protect without fail is customer data. That that doesn't ever come into it as far as we possibly can. That is the one thing that is like, no. That's not even like, that that doesn't even blip on our radar as a security team. But I think everything up to that is always open for us as an option to be able to share. And I think one of the key parts of that is then sort of saying, like, it's it's a it's what I what what I and others in the industry refer to as a technical equity question. It is how much of my technical you know, all organizations have technical equity. Right? Whether it's about how the security policy works or how the company runs or whatever it is, you have equity that is technical. And when you give that up, you should get something in return for that. Right? Like and that's and that's a really key thing. So every time you you're organ you know, you're working with someone on a security context, you just gotta go through that process of, like, what's the technical equity I'm giving up here? You know, is it is it worth that? What's the cost benefit analysis of giving this up? What will I get in return? And you can formalize that. You can make that a process if you really need to, and you can even formalize it in terms of legal documentation. I know it's easy to say you just go and get an NDA as though that's an easy fix to this, but but but kind of it is. Like, at the end of the day, you've got this data. You're gonna provide this to this person. You expect them to handle that data in an appropriate way, and in return, you're gonna get something out of it. That's a that's a negotiation that happens a lot, and I and I feel that's something you can codify to some extent. Something I did in government quite frequently when we had some very sensitive data, and we had to make sure we knew that that was being handled correctly. Sometimes that can be done with legal processes. Sometimes that can be done with commercial arrangements. Other times, it can just be about using, like, good old fashioned traffic light protocol. Right? Like, sort of, you know, sorry. This is this is TLP amber. This is TLP red, you know, not to be shared further. The good news is is that most vendors will understand that if they've done that and you've made that effort, it's worth more than their reputation to ruin that situation. Right? So I think it's working with them to make sure that they understand the impact of that too. But, yeah, it's a tough one. It's a good question. You know, I think the more you share, the more you get back. We've seen that in experience, but you do have to be really good at handling that data and the technical accuracy, I think. I'll I'll tell a very quick story of a a time a customer asked me to help them understand the results of, one of these automatic pen tests. And, the the customer was was, was coming at it from a perspective of, I want to understand why Sophos failed this test. And long story, Chris, you'll imagine they were ex I was just gonna say exclusions were made, and that that that's why, spoiler alert, but what was really interesting was was trying to have that transparent conversation and that the point of a pen test, frankly, from my perspective is not to come and poke holes at the endpoint security. Mhmm. As you said, we work with bug crowd and and shout out Dave Gary, previous guest on an AMA, friend of the show as we're supposed to say. So we we absolutely love that program, but the point of a pen test is to test an organization. It is to test if these things happen, If if an if an alert happens in the middle of the woods, midnight and it makes no noise, does does it get responded to to to absolute butcher, butcher a claim there? Yeah. Yeah. We're we're poacher gamekeeper here. Right? We're all we're all here to sort of, like, feed each other and help each other be better. You know, we've got an internal red team as well as us partnering with external teams as well. You know, we we understand the benefit of this. And, yeah, it's a it's a it's a live conversation. It's an active conversation. But it's hard. I I get it. You know, it is it's challenging to manage that. But I think when you hit that level of trust and you look after your data well, I think I think that's that can only lead to good things. We this is about the ten minute warning, everybody. We're gonna try and wrap this up right at at ten two, get everybody teed up and ready for their next call. So quick reminder, use that q and a panel, and we're gonna start to to taking a look at wrapping up. Now, Chris O'Brien, don't worry. We're gonna get to AI. We're gonna we're gonna spend a little bit more time talking about AI. I'm balanced. Love to alright. I am gonna I'm gonna ask you kind of three questions in one, if I may, of of some thoughts on back to that thing of how to get started. One of the things that I've been talking to a lot of organizations about is if you are building a security practice, no matter what the scale or the expectation is, whether you're Chris O'Brien protecting Sophos and the 500 600,000 Sophos customers globally, folks in our MDR team protecting 30,000 specific customers, or you're just building building a team to to deal with the signals that you're getting. I like to always think of it as there's there's three areas you can think of. There's people, there's process, and there's technology. Could you give us, like, your your top hits of how to how to be the most efficient, be the most impact full in in those areas of people process and tech? Oh, goodness. Yeah. Well, I I I'm I'm a very, security as a data problem type person, And and I and I think that that that's, more more just because that's where my expertise lies really. You know, my background is in coding. I kinda came from that perspective of just, like, you know, everything is is a data problem, so we can solve these things if we if we think about it in that way. I I there there is plenty of room for all, all church all faiths in this church, and there's lots of people that come from different different walks of life that have different perspectives on it. But that's that's certainly my my kind of leaning. And because of that, you know, when it comes to the kind of people process tools, I I tend to sort of work a little less on the process side. I I pretty much sort of get the the core things in there, you know, your your, your instant response plan, your, your business continuity plan, your disaster recovery plan, all the all the plans, all the things that need to get a little bit of, like, okay. We need a bit of rigor about this. We need to know what happens if all the lights turn off and all the rest of it. But, you know, but I go reasonably light with the kind of, like, I'm not I'm not one sort of step by step step processes. That would be a little bit too much. So that that's that for me is like, yeah, put a little bit of time in that, you know, build some good relationships, you know, get some good policies made, but other than that, be a bit light touch on that. On the tech side, I like to go, I like to go open. I like to go, you know, open architectures. I like to even go open source sometimes. I like to go, you know, like, let's just get the data into a into a nice big sort of, like, organized pile and and pass through it and make some good make some good assessments on it. And and, you know, encouraging people to think about how we build tools, you know, and how we kind of develop new capabilities and build automations. And then, you know, once I've got those things, like, you know, as I say, pretty bare bones, pretty, pretty pretty basic. The thing I spend most of my time on is the people. Like, that's that is the real part of this that makes this whole thing sing. It's it's about having this kind of, like, again, not to not to bang this drum so much, but, like, this this, you know, diversity of thought, this skill set of people who want to innovate, who want to come up with cool ideas, who want to come up with, you know, interesting ways to solve these problems. And I think that's where you get the the real magic happen when it comes to security is when you just have, like, the basics of policy and process in place, a nice open architecture approach to how you store your data, and then just smart people cutting through it and finding the the signal and the noise, because this is a big problem. And this is and and if you wanna scale that problem up, you've you've gotta have that capability in there of just people who can just process this stuff at scale. And there are some great tools out there that can help you do that, but I'll I'll promise you, you probably need to figure out what you need first before you go invest in those those major tools. Again, I should probably not say that as a vendor, but there we go. Lucky to know. For me, figure out what your problem space is, figure out what works for you, and then and then get that investment made. And, yeah. I think I think if you got the right people around you, you can't go too far wrong. Love that. And I I will do the quick vendor shout out here. Actually, not to plug any Sophos products or services, to plug some free stuff that we've got. If anyone has an in a Sophos Central account, jump in there. Up in the top right, you are going to see what I have heard described as various things. Chris, I think you and I would call it a mortar board. I think some other folks call it a graduation cap. You'll see a little icon for that. That was an adjustment I had to make after moving to The US. What do you mean you don't know what a mortar board is? In there, you're gonna see some some free tools to help you plan incident response, engagements, to classify incidents, some frameworks from NIST, very popular in North America, and NIST two, very popular in Europe. And if you are starting with with nothing, those are some great places. They're completely free. If you're joining us without a Sophos Central account, central.sophos.com, you can get a free account there. All of these tools will be free for everybody forever. I definitely recommend checking, checking those out. Let's go with AI, though. And I I wanna dive into, like, two particular AI things. The first is let's let's kinda talk about AI from the the the attacker, the bad actor perspective. Yep. And I'll maybe phrase this in a little bit of a leading way of how how worried how worried about AI are are you in your position? So so I'm I'm curious. I I think it's probably how I would phrase it. I I, yes. I'm certainly you know, if there was, like, a kind of a Defcon sort of level, I like, you know, I've I've progressed from fine to curious. You know, I I don't think I'm at full blown panic yet. But, certainly, no. I've seen some really interesting applications of AI from the attacker perspective. I think one of the things that's kind of intriguing me the most is just the the the speed, with which generative AI can can sort of, do do things in the past that that that have maybe been programmatic, that now are are much more, sort of, like, you know, generative and and and organic. So for example, if I think back to the days where we were sort of, you know, dealing with, like, fast flux domaining and botnets, for example, where there were, like, you know, scripts and programs that were, generating these kind of, like, what seemed like random, sort of, you know, strings that then became domains. And then they would, like, quickly spin them up, and then they would run them for a bit, and then they bring them back down again. And that was really hard for us to deal with as a as a sort of a defender community because it it seemed random. But but then what we did was we had we had source code that eventually well, even not just source code, but the the samples of the botnet that we could then sort of, you know, reverse engineer, figure out what this pattern was. And, actually, it was a it was a program that was doing this. So it always felt like there was some predictability to it because that was the tech that we had at the time. And now I'm curious because generative AI kind of introduces this, like, a little bit of a wild card into the mix where it's kinda like, well, actually, it may not be something that's that's programmatic. It may not be something that's predictable. And and, you know, because it's kind of created on the fly, so to speak. Now, of course, like in the fast look thing example, that still won't work because we still have an Internet that's kind of, you know, designed where you still have to register a domain and there's still a process behind that. But what if that was different? What if there was a different thing there? You know, what if there was a a capability that actually, you know, was able to sort of, like, you know, grow? And we talk about polymorphic code all the time, but at the end of the day, polymorphic code, again, is sort of generally predictable. What if it isn't? That's the part that gets me a bit curious, and we've seen a little bit of that, you know, with some of the attacks that are coming in. You know, the easiest example at the moment is just being used in phishing a lot because it can reconfigure, you know, phishing emails in such a way that, makes them unique unique, you know, every time. That's challenging. But I think that, you know, it's again, there there's there's ways around that as well that that rely on the kind of core infrastructure and architecture of the Internet. So I'm curious because it could change. Like, it can develop even further. At the moment, I'm just a little bit kinda like, yeah, there's some interesting things going on. But at the moment, I'm just more in the curious phase, I think. And on the on the blue teaming side, one specific question asking how good are these models today, like, identifying vulnerabilities in code. So maybe you could talk about that and talk about what do you think we might, I'm gonna I'm gonna ask you to make predictions, Chris. What do you think we might see in the next year from that Defender perspective? Yeah. It's, I again, I'm I'm still kind of in the curious phase, but slightly more positive on this side of things. I I do see some good work going on in this space. You know, I had the pleasure of actually, you know, being at Google when they were you know, before they'd least released Gemini and working on some of the some of the internal tooling that we had around that. No. It was promising. Like, you know, this is good. And and and since then, they've actually released their specific cybersecurity sort of trained model, which is, you know, which is really cool, and that works pretty well as well. So I see I see good good upside to these things. I think the specific example of vulnerabilities in code is an interesting one because, again, we went back to the conversation we had before. A lot of it is contextual. Right? So so, actually, sometimes, like, how how do you account for that contextual, you know, contextual nature of vulnerabilities, when you're, you know, working with a machine? I I don't know. I I yes. Absolutely. It's better at spotting these things than a human is because it can do that abstraction, like, faster than we can. So I do I do agree with that when it's just the code analysis. But I think that as soon as you start adding in real world sort of, like, infrastructure to to the mix and all of those different contexts, in theory, you'd need a different, you know, trained model for every single context, and that feels unlikely. Or we'd need to have all the context exposed to one master model or something. So, yeah, it's it's, I don't know. I don't know. It's it's it's one of those ones where I'm a little bit kinda like, I I I I see good things. I see good progress, but I think there's still, like, it's almost like the world the the ecosystem around it needs to evolve to keep up with it, I think, is the is the is the state that it's in at the moment. Cool. Let's, let's wrap up with, just one more question. It's not gonna be an easy one, though. It'll always keep a hard one right for the end there. I would love to to to understand from you. We've got a ton of people asking questions ahead of time and live about this is this is all fascinating. Cyber, you know, it's this next big thing. How to how to get started as an individual. The way I'd love to kinda almost, pitch that to you is well, number one, are there really 3,000,000 empty cybersecurity jobs? Who knows? Because, we can't take them. Yeah. The gap. But more importantly, when you're looking to hire across anywhere from, you know, seasoned, seasoned peer to work alongside you on the the programmatic elements down to entry level, Kinda what are you looking for? What what matters to you, and and what should people really focus on? Yeah. It's it's a challenge, isn't it? And and I I've gotta just throw out there about the whole cybersecurity skills gap that is it's it's, you know, I that's recruitment. Right? Like, I mean, this in the nicest way possible, but there's always gonna be an ebb and flow of availability of people and and and capabilities and all that kind of good stuff. I think that oftentimes the gap is is different depending on your perspective. Right? Like, actually, like, if you're saying, like, oh, yeah. We've got a a shortage of people who are actually formally trained in cybersecurity, then my point to you would be, like, well, I don't know. I wasn't formally trained in cybersecurity. I'm doing okay. You know, I I I think I think there's a lot there to be said. I, you know, I, we talked before about, like, this idea of, like, you know, is it is it about certs? I'm not a massive advocate of certs. Although, you know, the right training and the right kind of, you know, focus on the gaps that you've got and making sure you can kind of bridge that gap is is is very valuable. Don't get me wrong. If I could have my time again, I probably wouldn't go for certs, but I'd probably go for long. These amazing apprenticeships are going around at the moment, by the way. You know, there's some fantastic sort of, you know, programs out there that get you working on the on the cybersecurity challenge from day from day dot. And I think those are the ones that are really gonna add the value where you can do that and potentially also, you know, gain a certification or or a degree along the way. For folks that are getting involved in cybersecurity now, you know, I think I think the first thing to say is, like, it's not as big and scary as you think it is. If you've got curiosity and if you're if you're excited about this stuff, if this is kind of interesting to you, you know, remotely, then, you know, there there's there's definitely gonna be work for you to do in this space. Right? There's there's tons of different jobs that are available in cyber security, which are not all about, you know, understanding the full deep dive packet inspection kind of route. If you've come from a network engineering background and you like that sort of thing, we've also got jobs for you there as well, by the way. But if you come from, like, a, you know, more of a, like, a coding background as I did, the, you know, security is a data problem. We've got tons of jobs for you as well. If you come from more of a kind of, like, a report reading background or sort of, like, an analytic background, like history or or, like, an arts major or something, you know, you've got a lot of threat intelligence opportunities as well, which still require people to understand that kind of broader context and source management and geopolitics. You know, it's it's a it's a very broad church, and and there's a lot of different disciplines that are available for people that wanna get involved. I think the best thing, as I say, is just just get stuck in. Like like, find some some evidence. And this is this is the part I think is really cool and people sometimes forget is it's all around us. And that that sounds like a really silly thing, but, like, you can get started on the computer you're on right now. Right? Like like, there there are things that you can start doing. There are tools you can start downloading to start getting plugged into this and start having a crack at this. There's a lot of cool stuff out there, and it goes back to something I think that we were talking about earlier about hobbies, for example. The people to answer your question about the people I look out for, it's the it's the curious people. It's the people that decided to dismantle their radio that day because they just wanted to sort of see how it works under the hood. That might be a bit of a dated example now because they're on this and everything through their phones. But you know what I mean? Like, it's that person that sort of, like, just thought maybe they would give it a try to try and, like, you know, Jimmy rig up this thing that caused this other automation to kick in and did this thing. Because it's that curiosity about how how technology works, that will sort of really help people survive and continue to thrive in cybersecurity. I really I really firmly believe that. The technical stuff we can teach you, that's fine. Like, you know, learning learning, you know, the difference between operating systems and how endpoints work on different operating systems. It's hard. Don't get me wrong. It's gonna take a bit of studying, but, like, it's documented. Like, that's fine. That's doable. You can go and click on the mortar board in central and learn about instant response stuff. And, you know, you you can learn that, and that's a great resource, by the way. It covers all the things that we wanna we would need you to know as an instant responder. But then it's that other stuff. It's that curiosity. It's that technical investigation. It's the kind of, I'm just gonna give you data, and I'm gonna let you go figure out problems for me. What are you gonna do in that moment? That's that's the thing that we really need. That's the thing I'm on always on the lookout for for for new talent. Love that. I I would add one thing as well. Go find that community. Go find your b your local b sides. If you don't know anything, ask questions. I still have the, you know, the the embarrassment of going to my very first Defcon and not having a clue what was going on. And, every everybody's really nice. Just ask questions. As Chris said, be curious. So, Chris, that that fifty five minutes went past really quickly. Thank you so much for, for joining us, for sharing your expertise and your experience with everybody. Thank you to everybody for watching. And, with that, I think I'm gonna hand back to producer Taylor in the in the producer booth, if we've got any last minute logistics. But thanks so much, everybody. We really appreciate you joining us. And, again, Chris, thanks so much. Absolute pleasure. Thanks for having me. Lovely. Thank you, Andrew and Chris. Now, and with that, just a reminder that we'll be sending the recording out, early next week. So keep an eye on your inbox. And if you have any questions, just feel free to respond to the email. Thanks again, Chris and Andrew, and we'll see you on the next AMA. Bye. Cheers.