One SOC, The Whole SOC, and Nothing But The SOC, So Help Me

How's it going? I'm gonna move the mic. All right. How we doing on audio levels in the back? Outstanding. Yeah, thanks for coming. Um, I'm really excited to talk to you. Um, I'm a giant sock nerd. Um, I've been doing sock stuff one way or another for a really long time. Um, I've inhabited almost every persona in the sock. I'll tell you a little about it in a minute. Um, I come from Microsoft, uh, from the Seattle area actually. Any uh anybody from the P&W here today by any chance? Yeah, West Coast, best coast. That's what's up. We can all agree on that, right? Yeah, that's right. I'm an East Coast native. West Coast, best coast.

Um, uh, at Microsoft, I run the solutions architecture team in the cyber defense organization. That's a Microsoft way of saying I am the architect of Microsoft's sock. I mean, you're you're probably going to then ask yourselves, oh, did you design it? I, no, no, I've been enrolled for six weeks. Give me a year or two. Um, but I'm not speaking on on behalf of my employer today. Um, I did write a book on some of this stuff. Miter.org. Whack 111 Strategies is where you can get it. For the love of God, don't pay for it. It's free. You can go on Amazon and and download it. There's like the Kindle version is like 99 cents. I don't see a dime of that. Why?

It's free by design. Um, I'll be using some of that information today. It's been licensed back to me by MITER for free. Thank you, MITER, for funding the work. Every sock is a snowflake. They're all shaped in in different different ways. They all have different functions and services. They their org charts, how they're structured. Every single one is is different. Um some insource completely, some outsource partially, some companies totally outsource. I've seen them come uh in sizes ranging from one person or a couple people working half-time uh to organizations of over 500 people. Um, and among all of these, I've never met a sock that felt like they were not in the middle of major struggle. Didn't

matter how new or old they were. It didn't matter how well resourced they were, they always felt like they had major struggle. And over this period of time doing it myself, again, I've worked in these areas so long, the trends reveal themselves. And in this talk today, I'm going to reveal to you some of the trends that I've seen. And to get right to it, it is based around the concept that in my experience, in my opinion, and of literally almost everyone I've ever talked to about this subject that the sock is atomic, and I'll explain what that means. They're about six here in the front here for those of you who are super adventurous

and want to see me up close. And about four right here. Um, I'm going to explain to you from my perspective what needs to go in the sock, what doesn't, and what might. Um, but then I'm going to really blow up the problem of um, where do people blow it? Where do they blow it? What do they get wrong? And and how to fix it. But you're probably asking why? What is our motivation here? Um, for those of you who have never seen this, this is the UDA loop. We probably all seen the udal loop before. observe, orient decide act. Our job in the sock is to turn this loop as fast as we can and to do it as

well as we can. Understanding we are in competition with the adversary. I could use a lot of cliches right now. I'm not going to. We need in the sock to practice continual improvement. Again, cliches. It goes across that mission, not just detection and response or analytic tradecraftraft. And you think about how do we bring all these people together so they're acting as one because when they don't act as one, we get into trouble. And so many socks I run into don't do that. So they're probably you're probably thinking, "Oh, this sounds obvious, Carson." Trust me, most people blow it. I'll show you how in just a few minutes. We need to achieve economy of force. Everyone is screaming at us.

We're not going to hire more people to turn more alerts. We need to do it faster and better. Yeah, I got it. And at the same time, nobody wants to be stuck in the same role in these organizations for a long period of time. Particularly those of us, myself included, who have at some point in our career done alert triage. We don't call it tier one anymore. By the way, I might use the term tier one at some point. Really don't want to say that. I'll explain why in a little bit. So, let's talk about it. What goes in the sock again? And here's a cartoon. Your sock doesn't look like this. That's okay. This is a cartoon. What goes in the

sock? First set of stuff is under the the theme of triage, analysis, and response. The people who are looking at the alerts, the people who are investigating, the people doing the the coordinating the incidents, the people who are doing containment and eviction. Now, you're probably saying, "We don't have triage. We've outsourced that." like, "Okay, cool. Peace, dude. But like, work with me here for a moment." Eventually, someone in your sock is going to look at signal that someone else is sending you and then do something with it. And I'm going to call that triage for the moment. Somebody's got to do it. The next set of stuff um I'm going to call out hunt detection

creation and and kind of anything around the intel cycle that's focused on cyber uh consuming it fusing it creating it reporting it etc. And next, and I'm going to go do a whole expose on this, so just bear with me. Are tools, admin, and architecture. Those tools that support the sock, its data platform, its detection capabilities, its EDRs, it's XDRs, it swords, whatever. And then finally, some of these pieces over here about portraying the sock situation awareness about what's going on in the enterprise, about the adversary, about its threats, etc. communicating that out and of course training the sock itself. The thesis of my argument is that these pieces are atomic and every single time without a single exception

ever when I've seen people don't do this they blow it every single time. Not a single exception ever. Now there's a bunch of asterisks around um outsourcing. I get it. I'm not going to talk about outsourcing a lot. It's imperfect. But generally the further you stray from this the more trouble you're going to have. Now at this point when I talk about socks and I do a much longer presentation that goes along with the book and a bunch of other stuff. Somebody always asks okay what about firewalls? Cool. Let's talk about that. And in the olden days it's less important today because like now in enterprises like you're in you're in cloud you've got virtual firewalls

whatever. Could firewall management go in the sock? Yeah it could. Um I'm not hard on or against it. Um, vulnerability scanning. I've seen it work either way. Vulnerability scanning is one of the ways for the stock to tell the truth. PERT. Um, I often see the PERT capability and think about being able to understand security, being able to look through the incident life cycle, mobilize communications, mobilize partners. There's a lot of parallels to what the sock does. Sometimes I've seen it done in sock, sometimes I haven't. It's okay either way. Asset inventory. This is like the sexiest part of security, right? Asset inventory. Who thinks asset inventory is really sexy? There's always like three people in the

audience. Okay. I think it's sexy, too. I'm with you. Let's talk. When I say um asset inventory, I mean there's no one thing in the enterprise that says what all of your stuff is. It's not just Entra. It's not just your phone scanners. It's not just your EDR. There's no one source of truth um by itself. You have to bring that data together in a way that matches your bespoke environment. That's composite asset inventory. Some socks have it and they generally prosper really well when they do. Anti-fraud and anti-abuse. Any of you have capabilities out in the cloud and anything you're offering the public capability, a lot of the ways you detect that, you think about that. The

data sources, the analysis, the looking for evil, it's very socklike in a lot of ways. I've done this. There's like 90% overlap in a lot of ways. It could pull you in another direction. You have to be very thoughtful about that. You can smear all your entire sock. If it's a if it's a boring day like a Friday at 4:00, all incidents happen at 4:00 on a Friday, right? Yeah, that's right. We all know it. All right. Let's say it's it's a quiet day in a sock. As soon as I say quiet, by the way, it's not going to be quiet. I just used the Q word, we're all screwed. Sorry. Um, they're going to

go off and they're going to be like, "Oh, fraud and abuse. It's going to be this shiny object syndrome." and they go, they're gone cuz they're like, "Look at all this pwnage over here. Look at all this misuse that's happening in our services. Who look at all these people who are breaking terms of service cuz they're really good at it." So, just be thoughtful of that. Be thoughtful of that. Pentesting, bone assessment, red teaming. Yeah, I know they're not all the same thing. Some of you are like, "No, Kirstson, pentesting is not the same thing as red teaming." Cool. Whatever. I'm just going to put it all together for a moment. Bear with me. This is a way for the sock to tell the

truth. I've seen a lot of red teams attach like right next to a a sock. One of the best ways I hear people in red teaming talking about what they do is we make the sock better. Cool. And then owning and driving the P program. What do I say when I say P? I mean those things after the in that you accumulate over the course of the incident. everything that went wrong, everything that sucked, all the vulnerabilities, all the things that were broken that led to the incident um happening and all the things that during the incident were suboptimal. The sock during its incident life cycle should be accumulating these like a pile of slop

and then at the end of that experience, they should be curating that slop into something someone goes and does something about. In theory, the high priority stuff on a good day when it's sun is shining, right? a lot of socks they should have that capability internally or or side saddled to them. So all worth the chat. Um now I also want to warn you. Um so I I enjoy giving this talk in the United States. I'm going to talk about Cheesecake Factory for a second. Um I will warn you if you go and read 11 strategies um section.2 you're going to see a Cheesecake Factory menu of all the things a sock could do. Now what happens when you go to

Cheesecake Factory and you eat everything on the menu? How you going to feel? like crap, right? Um, so don't do that, right? There's going to be things on the menu you should not be doing. Let's talk more about what you shouldn't be doing. The rest of this stuff, this is a nice visual, by the way. I really like using this when I do a class on cyber, all the different branches of cyber. Um I've seen a lot of executives come in and say oh um you know we have uh something that is security and then it's operations so we're going to put in the security operations center wrong answer. Um so things I've seen people try and cram

into the sock that generally don't work. Patch management of stuff that is not the sock systems. IT management of things that are not the sock systems. General like GRC policy etc. um security engineering apps and then finally identity management. Generally speaking, these are things that are not associated with finding and running after bad people in cyerspace. So don't put it here because it distracts a sock from doing what they need to do. Again, you're probably like, I know this Carson, but everybody screws this up at some point. So here it is on a slide because so many times so many needs to say it, so I'm saying it. So how do we screw this up? I'm

going to show you four ways people screw this up big time. Number one, let's talk about engineering. So, I'm going to show you a chart. On the left hand side of this chart is the anti-atterns and on the right hand side it's going to be the patterns. I'm going to build this out. You'll see when it's done. So, let's start with this. When engineering is not in the sock, what happens? It's us versus them. Put another way, I heard someone once say, "All socks have engineering in them. The only difference is whether you acknowledge it and fund it or not." Think about that for a moment. All socks have engineering in them. And the only

question is whether you acknowledge it and you support it or the way you screw them. And that's the way it works out. Um, when you don't, generally speaking, you have requirements and solutions being thrown over a brick wall. The further the engineering organization is from the sock, the more severe this pattern is. The taller the wall and the wider the moat. You get to tools force on operations. What will happen is is that the engineers often this far-flung organization will will grow their own brain so to speak and they'll be like, "Yeah, the soccer league needs this thing over here." And that may or may not be true, but oftentimes it isn't. And I'm not saying they're not smart

people. I'm not saying they don't mean well. I'm saying that's generally how it works out. And then as a result, as I stated before, the operators become cowboys and they big borrow and steal for what they need rather than having a budget. And then finally, we need to think about balancing risk. The slide is done if you want to take a picture. So my first message to you is is bring your engineers close to the sock. Now, I'm also going to break down the rationale people often use for not doing that. Um, and I'm going to do my best to to support this argument, but I confess some of it's a straw man argument. The

first is the engineers focus. I strongly agree with the sentiment. One of the major problems that happens the closer your engineers get to the sock is they run from incident to incident like the rest of the sock is like, oh, we need a detection right now. Oh, we need a new telemetry like right now. I got it. It happens. You need to be able to support some of that resourcing, but you also need to cordon off some of that and you need to be very deliberate about your resource planning. Um, the next one is is they should be in an engineering or and the problem with is that generally they fall out of touch. You don't have people

talking to people. If there are not engineers talking to analysts every day, you have a problem every day. And I know this. I literally wrote the book on this twice. And I'm not joking. And when I was in an engineering role previously, I talked to one of my investigations leads at least once a week cuz I couldn't get in his mind. And there was stuff he knew about the mission that I didn't. And I literally wrote the book on this So if I can't do it, I guarantee you that engineers who haven't done this for 20 years of their lives can. The engineer should have strategic sense of the socks need. I strongly agree with this. Proximity is important,

but again being thoughtful about how we allocate the resourcing. Conflict of interest. I've never gotten that one. I'm not even going to bother trying to explain it. Um, detection is an engineering function. Who has detection in their engineering shop? One person. I'm sorry. Now, are there detections today that we're going to need some No kidding. devs to work on like some no kidding ML nerds to work on. Absolutely. Abs freakingutely. However, there's also going to be detections that we need to write in response to an incident that we need to turn around in an hour or so. So the question is what is the approach you're going to take to have both dev nerds who are really smart about stuff

that might not be security who are brought together with the people who are and sometimes they're the same person that's happening more and more but those can be unicorns there's different constructs I've talked about them in other presentations the concept is detection V team or actually form a V team and a rhythm of business around bringing these different people together and then finally ops is just does ops. Um, my god, what a wonderful way of thinking about things. I would argue, as I've said in so many presentations, and I'll again I'll do again in just a little minute, everyone should have the chance to improve. Now, mistake number two, excluding hunt and threat intel. This

can be absolutely toxic. So, let's break down the anti-atterns and the patterns. The first one is, oh, I've gone to the hunting team. I'm better than you are. I don't have to do shift work anymore. Anybody heard that before? Yeah, a couple people, right? Everyone should be in an observation of some sort or another. it it's applicable to almost any role in the sock. Not just the people who are in triage, not just the people who are in investigations or incident coordination or the engineering team um or threat intel or hunting. They all have an obsertation approach one way or another and roles to fill. So, let's not exempt them and let people feel like they're a

higher form of life. The next one is we only do advanced work. Come on, man. Everybody needs to take out the trash. they're just tier one and stop calling them tiers. That's a very quick way of being non-inclusive. One of the major reasons why you need to have this capability inside the sock is to give people career path. A lot of people in the sock are motivated by finding the next midnight this or typhoon that. So let's support that and build that into our career progression. often times when the hunting or threat intel capability is not in the sock. I hear someone say this, what the heck are they doing on both sides of the

equation, no good. And then finally, um the sense that tools and processes get static. They should be constantly improving. So my message to you in the second item is is that everyone needs to feel like they are in the fight and everyone should have the opportunity to do cool stuff. And what's cool for different people is different things. One of the major differences I see is that hunting people are like hunting's a different skill set. It's not. For the most part, what we do in hunting and we do in thread intel, we're using a lot of data to make smart decisions about how to orient the sock, find bad guys, and go faster. The degree to which we are

awesome at doing that is another story. So instead of focusing on our differences, let's focus on rallying around the deliverables and what we need to put together. No one should fail above each other and then there should not be any kind of single point of failure. I'm going to keep going. So what's cool? I've talked a lot of different pieces and socks and actually one of the things I really liked from the keynote and I strongly affirm is you don't necessarily have to have a CS or engineering degree to be awesome at this stuff 100%. As a matter of fact, some of the people I work with who are the the most awesome don't have degrees have their degrees in

stuff that is related, right? Psychology, for example, or art. I've seen it. Communications. My god, we need communicators. Right. So, some people are there are indeed looking for the nation states. Some people are there are really interested and energized about being nerds about bit twiddling. Some people are here to do a lot of ML. I have to say AI at least once in a presentation or the year isn't 2025 so I just did. Some people are there to learn cyber. I love it when I see people switch it between red and blue. It's super cool seeing people switch it. What a fresh mindset. Some people are to be awesome managers. Yes, I'm a manager, too. I'm sorry. I

had my manager labbotomy again about a month ago. I guess I can't write queries anymore. That's a lie. I did one this week. Number three, excluding truthtelling. This is an interesting one. What do I mean by truthtelling? So, one of the things I've noticed is that in fact, one of the things that's the coolest thing I think about working in the sock is the sock is so good about finding bad stuff. It's literally falling off the back of the truck of everything we do every day. Every good hunt when we prove or disprove the presence of an adversary in a network using data will fall off the back of the truck. 10 bad things we found along the

way that is potentially unrelated to a hypothesis. So my point in number three here is that you need to embrace that truthtelling role into the sock organizationally and in the rhythm of business. There's lots of different ways to do it. Here are the ways that I have seen vulnerability scanning. This one is an obvious one. Acid inventory. We've talked about this. Post incident response. TR speak truth about what wrong in that incident. How did we as the sock fail? How was our enterprise screwed up? How did we not get the coordination and cooperation we did? Red and purple team. I love purple teaming. Lots of great presentations on it. hunting talked about that threat intel.

These are all the different mechanisms the sock uses to collect, organize and share back out the truth of what it sees in the enterprise. Embrace it. And then the fourth, and this is a big one, and I talked about this in my in my talk, you can find it on YouTube. How to save your sock from stagnation that I delivered in 2023. creating capacity for only incidents. This is a big problem I see is is that like everyone says, "Oh, we should get better. We should get better." But they're not building rhythm of business and capacity and accountability around it. So, what does that look like? That can look like anything you're doing that you're measuring and building structure

around that is not the incident funnel. and I would actually argue is in so many ways as important because if you're not doing it, you're stagnating. If you're stagnating, you're failing and people are leaving. So my message to you today in this fourth mistake is build at least 20% ideally 50% or more of capacity in your sock to be available for for non um incident work improving your SOPs and processes doing tool and automation work hunt and exploration etc. This enables your sock to have surge capacity for when the incident does happen. So rather than having that in a separate organization, build it in and those people are already ready to go rather than having to scramble and pull in

other heroes from elsewhere. So this is important to both your improvement and retention and progression for those people. So I'm going to build this one out. So in that talk I I featured two of the the seven flowcharts there. I talked about detection V team and I talked about investigation improvements. I'll talk about the second one here. when investigations are done from a major incident. One of the best ways I like to do to support continual growth and training in the sock because we all know we don't have $50,000 to spend on every person in the sock to send them to 10 sans courses every year. The quick and easy and lightweight to way to do that

is after the incident is over, have the people who were doing the investigation show how they did it. If you are complex enough, and I guarantee you you are, there's something one analyst knows that another one doesn't around a data source or a TTP or a query. Like you could literally spend two hours talking about joins, left joins, right joins, inner joins, outer joins, semi- joins, left ini joins, blah blah blah. Like literally two hours talking just about how you use different joins to fuse different data together in an incident. And this is helpful because I can't keep all the joins straight in my head. And God knows they don't um always correlate back to any SQL. I

digress. So the point is is that in this post incident situation you have people doesn't have to be PowerPoint. It doesn't have to be a bunch of stuff like literally just show me all the things you just ran. Talk me through it. It's an it's an enormous opportunity to have team building inside the sock and learn. And it's basically free. It's basically free. So let's wrap up. If my message today is you need to enable growth and every function team and role in the sock and I know this sounds cliched and I know this sounds obvious but so often we don't do it. So we're talking about capacity and number two we need to conduct every

function in the sock on a closed loop. And that means for example in detection land the people who write the detections need to experience the consequences of the decisions they've made and the detections they've written. Did that detection they wrote yesterday just create 10,000 alerts today or not? And am I able to cope with that? Most people aren't. By the way, that's an example of a closed loop. So, we want to keep engineering threat intel and hunt either in the sock or immediately adjacent to it. And if it's just adjacent to it, guess what? It's the sock anyways. My opinion, everyone should be in an ops rotation. Everyone needs to feel like they're in the fight.

Nurture a culture of speaking truth to power and you need to build capacity for continual improvement. Treat that role in the sock as a first class citizen. So in conclusion, I would tell you we need one sock, the whole sock, nothing but the sock. So help me. Thank you. It's question time. Everyone, we do take uh a lot of questions over Slido for this. Uh we are in theater 7. Feel free to put your questions through there. Uh if you're having trouble with Slido or just want to ask a question direct uh directly, uh just raise your hand and I'll bring the mic over. Do we have any online? Not yet. Do we have any hands in the

room? Uh there you mentioned atomicity earlier and you said you had those pillars listed in the one of the first slides. Yep. I'll pull I'll pull it up. Do you mean atomic within each pillar or across each pillar? So uh we are streaming this. I'm going to try and repeat that question. Please correct me if I get it wrong. You're asking about uh autom uh automicity between these pillars on this slide being displayed now. Yeah, I'm using the term atomic as a shorthand to basically say look the stuff in the blue boxes needs to be in the sock. And in that regard, I consider these pieces together atomic. Like yeah, you can blow up atoms. I get it. But the

point is is that whenever I see people have these functions existent in an enterprise and they're not in the sock, trouble ensues. That's my point right here. Thank you. Um if uh one is in a context where um say you're the security expert and everyone around you are kind of like core engineers and they do not see kind of like the big picture of having a sock or investing in detection engineering or threat hunting and stuff like that and you're caught in between kind of like focusing on the other things or convincing them that this is something um kind of like that needs to be investing invested in or wait for something bad to happen, right? like

what would you say to someone in such a scenario? Um and how to approach it? Is it like you know are there some strategic ways to demonstrate the need or you know just wait for some you know what I mean? Yes. Um so I've actually inhabited this role before. Um in one of the jobs I've had in the past I would literally go into rooms full of devs and and service engineers etc. And I I would say the first thing I would say is, "Hi, I'm from security and I'm here to help." And that that usually got a full laugh, a couple laughs. And if that didn't work, I'd usually say, "We're not happy until

you're unhappy." There you go. So, um, the general vehicle um that I use and that I see most people use is that when you're talking about security, you're actually you're not talking about security anymore. you're talking about their mission, their business, and what's matter what matters to them. And so what matters to them is they need to um they need to drive down their risk. And I know actually Adam Showstack last week did a lovely keynote on on don't use the word risk anymore at besides Seattle. Um catch it if you can. So maybe you don't use the risk, but the point I'm driving at is you're talking about implications to the business in terms that matter to them. So talking

about it in terms of brand value and customer trust and uptime and revenue and that kind of stuff because that's what matters. So I'll give you I'll give you another example of a way that that um that uh really helps. Um red teams um the purpose of a red team is not to get domain admin. You're probably thinking like Carson, he's lost his goddamn mind. Just hear me out for a second. The purpose of the red team um particularly in any company that faces the public and has public facing like cloud services is to validate that we are upholding we the company are upholding the promises we've made to the customer about the confidential and integrity and

availability of the services and their data. So the red team there is not to get domain admin. They're there to to stress test our ability to keep those promises to the customer. And when you reframe the argument around that, instantly the executives pay attention, the business owners pay attention. Great question. There's no magic here. Thank you. Other questions? Uh, fantastic answer. Uh, we got a couple questions lined up. I need to make a quick announcement. Uh, lunch is starting upstairs right now. Uh, it will be going on till 1:30. Um, feel free to depart. Uh, we will continue taking Q&A uh, for a while. We got the room for a bit longer. Um, and on to the next question.

Great insights. Enjoyed your talk. Um and your last tagline was so help me. Um so if you fast forward yourself 5 years from now, what's your advice to some of the upcoming vendors or players where you think there is there is that help me u opportunity for some of these. Yeah. So um and when you say when you the organizations you're referring to in this context, are you thinking of like upand cominging security product companies? Yes. Okay. So like like like imagine the next XDR kind of thing. Correct. Okay. Correct. Um spot on. Um I have a a couple pieces of advice. Um I am never going to stand on a podium or in a meeting or otherwise say that an

entire security company security product company needs to be full of security nerds. However, user empathy is critical. User empathy is critical. And what I have observed is that the being asked to or being forced to sit in the roll in a sock and deal with alert triage for weeks on end or deal with incident coordination um with lots of angry people who just want you to go away. Um etc are transformative experiences. And until you've sat in that chair and had the snot beaten out of you to be frank, it's I can't I can explain it to you and intellectually you can understand me, but there's a change in how you think and how you approach

problems when you are forced to operate in those in those roles. So my point is is in any security company that's making products for organizations like socks or otherwise empathy is critical and you must have people who have that experience and h are able to translate that empathy to how you approach design implementation customer feedback product improvements etc. Great question. Uh right down in the front I think. Thank you. Uh while I get over there, there's a quick question from Slido. Um anonymous asks, "In one slide, you said nope with regard to security engineering in the sock, but later you listed it as necessary. Can you clarify?" Uh re restate the question. I want to make

sure I do a good job of answering it. Um in one slide you said nope in regard to security engineering and sock. I know what the problem is. Yep, that was my fault. Sorry about that. Hang on a second. Okay. When I said security engineering here, I was referring to the function uh whereby uh people do things like appsseack and threat modeling and working with you as an or a random service owner to correctly architecture architect and implement your service in a secure and resilient manner. that is different than the people who are doing things like running the XDR platform, building detection analytics, etc. I apologize for the confusion. Do you have any thoughts around taxonomy

for documentation? Taxonomy for documentation. the for so the people that don't totally understand if you have good people doing good things you can't just expect that you can apply some MCP or some searchy thing to all of your documentation and be able to to surface all of the important things in a very quick and orderly way especially trying to bring on new people and also allow people to uh transition ition and grow and all these things is providing documentation in a way that's meaningful. And so then you always get back to taxonomy and so then do you have any thoughts on how texonomy could should be applied to documentation for socks? Great question. Um I've never seen a good solution to

this only variations of not so great. And that's why I was laughing and why I think a lot of other people were laughing. documentation. Sorry, I'm having feelings right now. This is a good question. Um, there are a couple things I think about. The first is in some socks people are like, "Oh, we have one tech writer and the tech writer's job is is to write all the SOPs." I'm going to call BS on that one because ultimately it's everyone in the sock who's experiencing the processes is in a position to do a job of improving those processes. And so it's an expectation I would set on everybody. As a matter of fact, um you can go so far as to say you

have a set of new employee orientation documentation and the new analyst must go through all the NEO documentation and anything that's broken like broken links or anything that's out of date, guess their job is to is to update the NEO page. So the first component is is making sure this is democratized. So this makes your the answer to your problem even worse, right? Because everyone's updating it. Um, there's a couple ways. My default answer is I hope your search bar works really well. I'm sorry. Um, what I've seen people do is use uh either any kind of kind of structured semantic wiki or specific uh keyword callouts and dating and versioning. Um, and then with all this, um, uh, LLM

stuff now afforded to us, um, you know, potentially being able to dump all that stuff into a rag, um, and have and have the LLM start spitting answers out to you. They may not be perfect, but they may help someone get faster and get the link faster. That's a tough one. U, I got one question here. We'll get yours. We're going to need to cut it off after these next questions. Uh, I sadly need to let the rest of the volunteers get their lunch breaks in. Uh, but for questions past that, you can find our speakers upstairs and in some of the social events around the conference. Thank you so much, Keran. Um, how would

you articulate the difference between SAK, the security operations center, and secops, just security operations in general? Like what's the difference of responsibilities? M so and when you were referring to secop ops in that context I think you were probably referring to like dev sec ops. No I mean secops like even just here you say security operation but then you have security operations center and I've seen organizations who have like the sock but then they also have like sack ops who like and in inside the sack ops they have the sock. Yeah. Just like in this picture. Yeah. it. I hate parsing words out really hard. First of all, uh I am never going to say in the modern day and age, the

year's 2025, that you have to have a physical place like we all went through COVID, you don't have to actually be there, lots of hybrid work at home, blah blah blah. All right, so that's the first part. The line I'm generally drawing is um the people who are principally involved in participating in the incident funnel are the functions that directly support it. So detect, investigate, respond, recover inclusive of coordination and tooling and hunting. So those are like the nearby pieces. That's that's what I'm putting inside this bubble I call the sock and the rest is other stuff. And as and I went and in the slide where I talked about [Music] So like incident response,

investigations, detection engineers, all of this is outside of the sock. I I understand what you're saying. Um there's different ways to structure it, right? So your your your ops hub or your op center might be like the inner ring and then maybe like your engineering and your detection and your hunt and some other pieces like there's your outer ring. That's one way to do it, right? That's why I said every sock is a snowflake. So it's an interesting philosophical question. I think we have time for one more. Are we done? All right, one more then. I can just ask I guess. First of all, thank you for being here and thank you for the book. It's really good book. I

highly recommend it for everybody. Um I have a problem. Um the problem that the problem that I'm facing is like there's like so much good information in this book, right? But it for me it's like overwhelming. Where should I start? So if you have like one advice how to not get um burned out or where to start from where it would be. Well, you're in luck because I actually am going to be giving a talk on how to avoid burnout at first in Copenhagen in June. So watch that talk on how to avoid burnout, but that's not the question you asked. Um uh there's a couple ways to approach it. The first one is at the beginning. If

you're new to socks, do the first do chapter zero and then skip to the part that's important to you. We did um build uh 11 strategies to be consumed linearly because we're like how do you linearize this bizarro topic? So um you can do it covered um to cover the other way to approach it is um Katherine Iningren and I those are my co-authors we did a uh uh webcast podcast dio through sans's blueprint where we did like one chapter in 45 to 60 minutes or so. If you want to just zoom in on that, we get you some juicy stuff, some fun commentary. Um, that actually is kind of like the book plus plus in each part of that. Those

that's another way you can consume it. Yep. So, just 012 34. Yeah, sure. All right, folks. Thanks for coming. Thank you for staying so late. Thank you.