SPEAKERS
Rob van Os, John Hubbard
John Hubbard 00:00
Support for the blueprint podcast comes from the sans Institute. Since the debut of sec 450. We've always had students interested in a matching course covering the management and leadership aspects of running a SOC. If you'd like to topics in this podcast and would like to learn more about Blue Team leadership and management, check out the new management 551 building and leading security operations centers. This new course is designed for security team leaders looking to build grow and operate a security operations center with peak efficiency and it's a hands on technical leadership course that takes you through everything from scoping threat groups to use case creation and organization, threat hunting planning, SOC maturity and detection assessment, and much much more. Check out the course syllabus labs and a free demo at sans URL comm slash 551. And I hope to see you in class.
00:46
This is the blueprint podcast, bringing you the latest in cyber defense and security operations from top blue team leaders. blueprint is brought to you by the sans Institute, and is hosted by sans certified instructor john Hubbard. And now here's your host, john Hubbard.
John Hubbard 01:06
Are you a manager looking to build or improve your SOC? Are you trying to understand how to measure your SOC maturity or your use cases or your threat hunting efforts? If so, today's podcast with Robin OS is for you. We'll cover three of Rob's awesome projects aimed at clarifying and solving these commonly confusing topics. In today's episode, we hit the SOC CMM for SOC maturity measurement, the magma use case framework for building and tracking SOC use cases, and the Tahiti threat hunting methodology for showing ROI on threat hunting. Rob has put together some amazing guides and models for each of these topics. And we walk through how each of those can help you build the best possible SOC for your org. So stick around for all of that today and more on the blueprint podcast. Hello, everyone, and welcome to the blueprint podcast today. We have Robin OS on the show. He is a long time SOC management veteran. And I knew of him because I've long been aware of his SOC CMM framework and some of the other awesome projects he's been aware of. And so today on the show, I wanted to talk through a few of those things, because we haven't really had a management centric podcast yet. So really looking forward to this conversation and some of the really useful kind of mental models and metrics and management aspects and expertise that Rob brings to the table. So welcome to the podcast. Rob.
02:27
Thank you very much, john.
John Hubbard 02:28
To start off, could you give our listeners a bit of a background on your current role and kind of various activities within the infosec industry?
Rob van Os 02:36
Right, yeah. So my current role is actually a senior Security Advisor role, which I've started fairly recently, the last two and a half, three years, I've been active as a SOC manager for a large financial company to one of the largest banks in the Netherlands. And before that, it was just, I've been involved in cyber defense, doing sorts implementations for SIEM solutions, as well as being a just one of the specialists in security operations centers and designing incident response teams, that sort of thing. So always had a sort of advisor coordinator role, which seems to fit me fine.
John Hubbard 03:12
Fantastic. So you've kind of done it all. It sounds like from incident response to management to designing Sox and everything under the sun. Right.
03:19
Right. Yeah. I've also done some SOC assessments as well, incident team isn't Response Team assessments just to see where they're at in terms of maturity and capability, which is one of the things I specialize in.
John Hubbard 03:31
Yeah. And so speaking of assessments, and all of that, that's a great segue into our first topic, which is one of the things I wanted to make sure we cover today in a decent amount of detail, which is your SOC CMM. A SOC CMM is an outstanding framework for assessing the various components of a security operations center looking at the maturity in the various domains and aspects. And I was wondering, could you explain why you created the SOC? CMM? And what's it for and how you kind of modeled it?
03:57
It all started out, I think, I think about five years ago, when I was doing a master's degree study, I had to choose a project as a final project to get the degree. And one of the things that always interested me is how do you measure something like maturity? How do you measure capability, and if you go looking for it, then you will see that there's HP, which Microsystems now had an assessment and IBM had an assessment and, and all those things were sort of vague, you know, they were, you got the the, the model, they were clear about the model, the sort of things that they were trying to measure, but not how we're actually doing it, which ultimately gives you a vendor lock in. Now you do one assessment and they know the metrics. So if you want to do a reassessment to see if you've progressed you need to get the same guys on board because you know, you don't know the exact metrics that they use. So I wanted to create something which was similar but then open source and of course, completely transparent about what metrics are we using to assess certain aspects of a song. So what happened is I got a few thoughts on board from different sectors and different sizes are different levels of maturity. And I started to do leisure research to find out, you know, what are the common things in a SOC, our common aspects of a SOC? And do we actually find we find them in literature. But do we also find them in an actual SOC. So that was the first part of it. And then all the information gathering and putting into a model and into an assessment tool, because that was one of the goals, you know, to allow someone to go online, just download the assessment tool, and start assessing their SOC without any thresholds without any registration without any accounts just be able to do that very quickly with something that was basically salvage telemetry, that was the whole initial goal. And I released the very first version or finger around August 2016. So almost five years back now. Now we're currently in version 2.1. So it has definitely progressed since then.
John Hubbard 05:54
Very cool. So this is one of the things that I think confuses people as they approach building a SOC for the first time. It's just like understanding what are the key components that you would break down a SOC into right, and the different domains, as you would call them in the SOC CMM? Could you explain a few of those domains? And just kind of how you thought about how, you know, organizing the large topic of a SOC into these different categories? And what each of those categories kind of contains in it? Right? Yeah, so
06:23
I was actually looking for a way to logically group all these aspects that I've found. And one of the things that you usually refer to easily, it's just like the people process technology, because it's so standard. So that was the first thing on my mind, just to split it up, and people cross the technology. And I kind of found that at some of these things don't really fit into those categories. So I needed something else. If you're looking at enterprise architecture, there's always a focus on business as well. And I found that lacking in in just if you're just looking at people pursue comedy. So I added another domain was business. And ultimately, I decided to put services into it as well into the model as well, because of course, technology, you know, you have the technology to do something with it. Basically, you're delivering services as a SOC. So I started outlining, you know, one of the common services of a SOC and what they look like in terms of maturity and capability. So those are the five domains from business people process technology to services, and I mapped each of the aspects that I sort of inventoried into one of those domains.
John Hubbard 07:27
And so if someone goes and downloads the CMM, like the worksheet from your website, what's the experience they're gonna have, when they go to try to look at the maturity and assess the maturity of their own SOC? What does that process can actually look like? For me,
07:40
I've seen different approaches. But I think what works best is if you have a small team of people doing an assessment together, because if it's just one person, for example, just a SOC manager going through it, and mapping their own ideas of how the SOC is running on the SOC CMM, you will get a certain view from one single viewpoint, but I think is much more valuable if you have multiple viewpoints. So you have the viewpoint from the SOC analyst, and also the SOC engineer, perhaps an incident responder or incident coordinator, but also the SOC manager. And I would even say that for certain domains, especially business, you need to have outside stakeholders as well. Don't just keep it within the SOC, but also try to, for example, ask the CFO just come on. And let me hear your view of what we're doing. And if it's properly aligned to what you think a security should do for the company, because ultimately, you should be serving the business as a SOC. And I've seen assumptions are working very, very well autonomously, but not very much connected to the rest of the organization are sort of separate entity within the organization, doing great things in terms of security, but sort of unseen and unknown from the rest of the organization. So I will say yes, but also take external stakeholders for some parts of it. And for the rest of just create that small team and go through all these questions and have that discussion, I find that if you start out with the SOC CMM, you'll get a lot of discussion on the way you need to answer these questions. But once that's sort of cleared out, you can really start going forward. And bond of having these discussions is a lot of sort of collateral things that you find, you know, collateral findings, things that you really haven't thought about yet, and might not even be in the SOC CMM, which is some great things that happen when you're having these discussions about things you'd normally not think about because you're running your operation.
John Hubbard 09:37
Yeah, I really liked the way that it's kind of broken down within those five sections into a whole bunch of detail. You've obviously put a ton of time into this Excel chart. And for those who haven't seen the SOC CMM it's an Excel sheet with a whole bunch of different sections and there's rankings and questions and kind of goals and everything gets input and broken into those five people process technology and business and services and within each of those Once you go through those, you end up with this, I guess a spider chart would be the right word for it. The assessment for each one of those things and services, for example, it gets broken down into threat hunting and vulnerability management and all of the kind of subcategories within that, which is a really cool output. And I'm guessing the goal here is to, you know, give people a visual idea of where are there gaps and kind of steer them in the right direction? right?
10:22
Correct. Yeah. And the level of detail is one of those things that I was, I'm still a bit worried about it, because there's a lot of questions to go through. And there's a lot of detail in the assessment. And it's about balancing, because I could easily add another 1000 questions to the SOC CMM. No problem there. But you're looking for the right level of detail that allows you to actually see the SOC in the right direction with the right information. So it's always a balance between too much details, or too much questions, and too little detail that really doesn't allow you to do some proper steering on it. And I'm still struggling a bit once in a while with, should I? Or should I not add these questions to the software? Just to just keep on adding new and new questions, because there's just one huge pitfall that could be the end of the story, which ultimately will result in an unusable set of sheets with like a bazillion questions, you're never gonna be able to go through.
John Hubbard 11:20
Right, right. That is always a struggle is figuring out, you know, like, people want the best answers. But the best answers means the most detail, the most detailed means the most time it takes and 1000s of questions, right? So the number of questions you have here, what do you think it would take, you know, roughly for a person to run through and fill out all of these things,
11:37
it does depend on the amount of services and the amount of technology because once you do the profiling, you select which services or which technologies, you're going to be evaluating, assessing. So if you have like, every technology, and every service selections, and go through each and every one of them, is going to be very time consuming. I think like business people and process domains, those are standards, you can't choose the so there's a standard, and you probably be able to get through them in like maybe four to six hours, you should be able to do that. And then technology and services, depending on how fast the team is working, and how committed you are to doing it within sort of time boxing it, and not having this discussion go on endlessly. And also depending on on your scope, it might take another day or two. But I think you know, this is kind of a large investment, it seems like a large investment in time, especially because you know, you have to run your operations as well. This is something strategic, this is something about looking where are we? How are we doing? What things we need to improve? And if you do this, like once a year, I don't think like spending 40 hours on it is too much time.
John Hubbard 12:46
Yeah, that's actually your answer. The question I was gonna ask next is, you know, it's, it's something that's that big picture, strategic kind of planning stuff that you have to do. And it's important to have a goal and to have like a snapshot in time of where you are and where you are, what you're missing. So you know, knowing like, maybe it's a once a year activity, if it takes a couple of days, you know, that's a good thing to know what like your mindset is, when you're going into wanting to pick up the SOC CMM is something to use for evaluation, when you get to things you said kind of earlier back that I wanted to circle around back to is the tie into the business and how you specifically call that out within this because the people process technology wasn't enough. One of the LinkedIn posts you had put up recently broke down SOC into different types of SOC and you had in there, you know, these kinds of SOC are maybe better at aligning with the business or better at threat hunting and intelligence and things like that. I thought it was an interesting way of kind of categorizing stuff. And I'm always looking for those kind of easy models for people to lock on to because I think it helps clarify the problem of what should a SOC be and what a SOC should be is potentially different depending on where you work. I was wondering if you could talk a little bit about those different types of SOC you listed and kind of how that helps you decide where people should go in terms of improvement in their SOC,
14:01
I was just thinking about these SOC types, and especially the primary drivers because SOCs are rather complex. It's not black and white, you don't just have one single driver, which decides everything. There's always going to be multiple stakeholders, there's going to be multiple things at stake as well. But I was looking at it in terms of primary drivers, what is your primary focus as a SOC and coming from the financial sector, which is pretty heavily over sighted, you will see that, you know, compliance is a very important thing within a SOC is adherence to internal policy, but also to what the oversight expects you to do. And we see a lot of regulations as well. So I think compliance can be a very important driver and I had a discussion on the LinkedIn posts as well about compliance and how compliance should never be your primary driver. Then that's compliance comes from doing security properly, but it's just if you're looking at it depends On your view, and especially on your sector, I think it's a very easy thing to say. Compliance isn't that important. If you don't have like oversight, pushing down on you to get compliant? I think that's a, it really depends on the sector that you're in, and what you're trying to achieve. I don't want to say that every SOC within a Fennec financial sector is compliance driven, which is absolutely not true, because there's also software have more focus on threat intelligence, and are more intelligence driven heavily depends entirely on what you're trying to achieve, what your goals and mission is. And I just wanted to sort of, there's one or two thoughts that I had, you know, what if you had to choose a primary driver? What would it be? I think it's an interesting, it's an interesting thing to think about. And in my experience, I've dealt a lot with compliance driven Sox. But also, the assessments that I did were with a managed security service providers and a very different focus, what they're trying to do is to get their security service across to as many customers as possible. So they're not looking for a lot of customization. They're looking for standardization, they're looking for efficient operation, so they can serve as much customers as they can efficiently. So this is just a very different focus for your SOC. And it has to do with sexual it has to do with your mission and vision as well. So I think, you know, there's those things to think about, if you're looking at the business side of the SOC and your real reason to exist.
John Hubbard 16:26
Yeah, I really like the way you broke it down. I said before you had a compliance driven SOC and intelligence driven efficiency and technology. We're not things I'm always like, seeing and hearing when I'm teaching courses is like, well, what's the best way? What should I be doing for this? And I hate giving the answer, it depends. But in a lot of cases, that is the answer, right? And this is one that are like, what do you see? Do you work for a bank? Do you work for a small organization? And so that's why I kind of liked this kind of way of breaking it down as it makes things simple to understand. It says like, what's your primary objective? You know, if that is the case, these are the things you might want to focus on steer your metrics towards optimize and things like that. So I thought that was a pretty cool way of breaking that down. Speaking of business drivers, and metrics and things like that, one of the other kind of related questions is ROI, right? How does a SOC best express the return on investment that business is getting for, you know, the money that the business is putting into that? What are some of the like metrics and ways that you have seen Sox have really any of those types? You know, like, what are the external facing metrics, you like to see what a SOC used to show that they are returning the value that the business is helping
17:42
very difficult questions as john, because basically, SOC are just cost money. And that's the general ID, and sometimes even save money. But it's very hard to show that, you know, as a SOC, you can say, okay, we've seen all these events, we've acted in all these incidents. And this is what we have saved for the organization, this is our return on investment. Because you be sure that you don't know what the impact would have been on that incident, possibly you can use like the podium cost of a data breach report, to use that sort of thing for very focused incidents, it's going to be very hard to actually make it very concrete. If you're looking at these sore vendors, usually what they say, again, this is the time saved because you bought this tool. And this is your return on investment for this specific tool. And that will probably be correct for that tool, even though that you can have a lot of discussion about whether or not those values are actually correct. But it's still, I think it's actually safe times it provides some efficiency. So you can save time, which you can calculate in terms of in terms of money, though, if it exceeds the investment, then there is no return on investment for that specific tool when there's more to assault than just the saw tool. And also, I think the SOC CMM can help you provide some return on investment. Because you're doing an assessment, you're saying, Okay, these are just trends, these are the weaknesses, this we're going to be investing in. And then your year later, you're going to do another assessment, you're going to say, okay, we've progressed, you know, we've invested in this and that, and now we've progressed to a new to a higher maturity level, which is sort of a return on investment, again, on the specific investments you put into achieving a high level of maturity or high level of capability. But it doesn't really say anything about the SOC as a whole. So it's a very difficult question. And as I was saying, you might use the cost of a data breach to calculate it. And but you'd have to estimate the number of data breaches, that you've actually managed to stop because of your security operation center. And there's also of course, a lot of preventative measures in place as well, that function autonomously without the security operation center. And so if you come up with a formula, I'd be very interested in it.
John Hubbard 19:51
Yeah, no, I did ask that question. Knowing that it's a very complex thing. And again, it's one of those you know, it kind of depends what you're looking for, and what you're looking To start up, right, based on the attackers and the type of destruction you're trying to prevent, and all of that. And so yeah, I do like the approach that the SOC CMM can help you take and saying that like, this is where we are this year, this is where we are the next year, this is where we are the year after that and demonstrating that progression. And you know, my thought about that is there will be an aggregate, you know, statistics on how many incidents you had the kind of impact and disruption they were having throughout those years. And hopefully, you know, you would see some kind of decrease on that, or maybe on a per incident basis, you know, the number or the price of each one is kind of going down to follow that, it is a really, really difficult thing to do. because like you said, you know, you can't say what didn't happen. How many attacks did you stop today? And I'm always like, I don't know, what's an attack, right? And like, that then follows into like, well, how much money did we not spend? Because we had a SOC today? I don't know, right? But I can say like, we're getting better and better at detecting things and our time is going down and attacks are progressing. They aren't getting as far every time we see an attack, and we're catching more and more spam, percentage wise and whatever, right?
21:03
It is the eternal struggle of justifying your existence as a SOC. And yeah, because you go always say I go. So we've had less incident this year. Okay. So does that mean you're functioning better? Does that mean our preventative controls are better? Or does it mean we were less targeted this year? Right? Really, really hard to answer that question? Yeah, that's
John Hubbard 21:24
one of those like, well, there's the external factor of like, you don't control what attacks are happening. And then the internal factor of like, we prevented some detected others. And how well did you do in each of those places? Plus, how accurate were the attackers? So? Yes, it's really hard math to get to. That might be a good segue into slightly more technical topic, one of your other projects, the magma use case framework, could you tell us a little bit about magma, and what was the inspiration and kind of aspects of that? bright,
21:53
so magma came into existence as a joint effort within the Dutch financial visor community, we had a session revolving around the NIST cybersecurity framework, and we split it into into four different sessions that year. So the first one was prevent and you know, that sort of thing. We we came across it to the tech part of this iPod framework. And I said, I've got an ID, why don't we exchange our use cases? Why don't we exchange what we have in terms of security monitoring at a perhaps higher level. And so we can learn or improve our own detections. And that was the kickoff, basically, so we sat together, and then we find that we don't have the same definition of a use case. So that was the first thing we needed to address. So okay, let's start out with the definition. And once we have that definition, we were looking into, okay, who's got already got some sort of relatively mature framework, and ABN AMRO, one of the Dutch banks, one of the largest Dutch banks, they had a pretty good framework in place already, which is sort of the basis for magma. magma stands for management, growth and metrics and assessment. So these three pillars, you know, managing your security monitoring use cases, that's one thing just in managing through them through the entire lifecycle, from designing them and building them and operationalizing them and testing them and improving. So that whole lifecycle and the things that also drive change, because I think there's two different things that drive changes, things change in the landscape, which I call environmental drivers for change, like, you know, the threat landscape changes, but also your internal IT landscape changes. And there might be new legislation or new compliance rules that also have an effect on your use cases, even, you know, new legislation like privacy, if you look again, at the use case that you have, and see whether they're compliant or with regards to to privacy. And there's also the operational drivers like things, the outcome from your security incidents. Also, you know, the outcome from your threat hunting investigations, and all that sort of stuff that drives the change in the management of your use cases. And then there's the growth. So we have this use case framework, and it's ever growing, and how do we do that? So how do we select the next use case to implement? Which one is more important than the other one? If you're looking at, for example, the mitre attack framework, there's so many things, there are so many technologies, there's so many things that you could potentially be monitoring for. How do you select the next best thing? You know, how do you select the right things to focus on? And that has to do with growth? In my opinion, microtech is so extensive, you need to take a risk based approach, you need to decide what's most important for me. So you have to understand what do we already have in terms of preventative controls, where the largest risk in terms of the threat landscape, which actors are part of that threat landscape, how do they operate? And that sort of gives you a view on what's most relevant to you within mitre attack and then you can prioritize and And then start the growth growing into your into your use case framework. And last is metrics and assessment, which has to do with sort of measuring whether you're doing things, right. So you can just say I've got like 500 detection rules. So that must be good, right? Because it's 500. That doesn't say anything about the quality of those rules or the efficiency of those routes. Are they detecting the right things? What's the number of false positives, what's the number of false negatives in other ones really are two because you didn't detect something that happened. So one way to to find that out is through incidents, or perhaps through more proactive threat hunting, as you also need to find out, you know, what's my false negative rate, and all that sort of stuff to measure your set of use cases to make sure that it's not just quantity, but it's also quality?
John Hubbard 25:50
It's a really nice framework for kind of thinking through the different levels of, I don't know if abstraction is the right word, but the levels of detail, you kind of have like the level one, level two, level three details. And I definitely wanted to cover this because I get a lot of questions on use cases as well. And you know, as we said, like business alignment is kind of like the top level thing we always have to ensure here, use cases are the thing that kind of says, like, why do we exist? And how do we specifically implement these things that are going to, you know, detect the things that we're trying to detect? That are the reason we exist, right. And so the way you would broken it down is into like level one, level two, and level three stuff. I was wondering if you could talk a little bit about that kind of framework of the different layers for pieces of what goes into a use case? And then the type of like, I guess, software, or like, how would you organize use cases? How does a team keep track of all of this stuff? Like what kind of management software or otherwise would you use to track all this,
26:43
so it's about the layers. So the highest layer is the old one layer, which is basically your risk layer, which should be aligned to your business. So you know, in that layer, you should be able to find things that actually are actually business risks. In magma itself, we also use the cyber Kill Chain, which I think is getting a bit old, especially because you know, mitre attack is a lot better. But it provides too much detail basically matters, actually, you need to find something in between. And so what we did is we use the cyber Kill Chain, which is relatively high level, but still not really a risk, you know, so you could you should be able to sort of create overlays for specific risks. And then there's the L tune is how that risk manifests itself. Now, how would that come into existence? So that's the sort of thing it's comparable to what mitre attack does with tactics. And then there's the L three layer, which is the implementation layer. So however, we implemented our security monitoring rule in our security monitoring tool, specifically. And this way you do your measurements for each single rule, you do your measurements in terms of how efficient is it? How effective is it? What coverage? Do I have that sort of thing?
John Hubbard 27:50
I really, really liked this way of breaking it down, because I think it makes it very clear, like we have a use case to cover this one specific thing, right? We have this section on what is the threat, you know, what is the tactic or the technique or whatever? And then it separates that from like, how would that actually be implemented in our tools? And is it there? How much does it cover, stuff like that? And so you got specific metrics on each one of those levels. And I think that's a really cool way of approaching it. And the other thing, the software piece, yeah, back to that. But to get to that answer before I forget.
28:25
Well, one thing is don't don't build in in Excel. That's, that's the basic thing. So we did an example implementation Excel, because it was really easy to create it that way. You can't manage your use cases in an Excel file, you should tie it into your security monitoring system as well. So perhaps because you know, security monitoring, it's not just your SIEM, it's also your EDR as well. So what potentially could be a good source is if you aggregate all that information into a single saw platform, that platform and its, you know, its potential for automation, and would allow you to extract all the all the required information, because you can also sort of aggregate your security incidents as well. So there's a lot of information probably from your saw platform if you're using it. And I will say, use that as a basis for getting the writer getting all the information. I think a lot of things can be automated, I've seen implementations in an actual saw. I've also seen implementations in JIRA. So that's, that's also an option to do that and to have your to manage your incidents as well. And categorize and manage your use cases. I've seen multiple options. I haven't seen anything yet. That is really, that we can really download and use right away so probably need to build some sort of web web interface or something around it, to have it work for you.
John Hubbard 29:48
Yeah, it's one of those things that I haven't seen any purpose built software for yet and like you said, you know, some of the ticketing systems out there seem to work fairly well if you as long as you customize the fields but nothing kind of tailor made for you Security use case storage yet. And when I asking courses a lot of people don't tend to have? Well not I wouldn't say a lot, maybe 5050. It seems like people have like a documented structured kind of use case database of sorts, and others are just kind of like it's an Excel or we don't really have anything, we just have analytics, and we kind of know what to do.
30:18
Yeah, it's in it's in the same system. And that's what that's where all the documentation is. That it's also a very common option.
John Hubbard 30:24
Yeah. So let's say you have all of your use cases put into, you know, magma style framework and documented in one of these systems, as a SOC manager asking the question, you know, are we covering what we need to cover? And are we detecting what we need to detect? What are the metrics and numbers and kind of things you're pulling out of such a system? To try to answer those kinds of questions,
30:47
I would definitely say, you know, to get aggregated results of all your security monitoring, security monitoring rules, and then that's where the the subculture and does help, even though a lot of it will be in actions and objectives, basically, because that's everything that happens after initial compromise, you still get a sort of views, how are we doing in terms of how am I doing in terms of reconnaissance? So what step of the way, am I detecting these incidents going on? I could look at the security monitor use case, but I could also look at the security incidents. And to see, okay, so this is where we see these incidents. And at that stage of the of the cyber Kill Chain, they were that incident was taking place. So it helps me to kind of say, Okay, this is where, where the incidents take place. And this is where our detection strength is. So what we need to do is to get sooner to get earlier earlier detection in that cyber Kill Chain. So we move we want to move up the chain, instead of moving down to actions on objectives. Because basically, that will be the arm too late part of the your use case framework, to actually, you know, really do really do prevention.
John Hubbard 31:55
In my view, right? My answer to that question is, is probably largely the same, right? You're looking for defense in depth, right? Evidence of kind of objective way of saying, Where are all my detections placed, either in the mitre attack framework, or along the kill chain, or any kind of process model of an attack that you can think of, right? If you have all this data entered in a structured way, then as a manager, you can go in and just say, like, show me all my use cases sorted by which ones are commanding control, which ones are installation phase, and all that stuff. And if you see, you know, a big peak on one and nothing early on, you can say like, oh, we're over subscribed on later, you know, Kill Chain stuff, and we need to back it up and maybe catch our delivery or, or things like that. And so
32:36
right now, and I think what helped here is also that the mitre attack framework was schools, it was updated about how view back and stuff from the pre attack framework was integrated into attack. So I think it is, you know, those tactics helped to really address the parts of the of the of the kill chain that weren't addressed. Yes, in the original mitre attack. I think it'll be replacing the cyber Kill Chain entirely in about a year or so. So we probably won't need that anymore. You can just move on on the left side of the current mitre attack framework.
John Hubbard 33:08
Yeah, it's an interesting kind of comparison that you know, people make a lot right, the kill chain, which was made many years ago now versus mitre attack. And the way I kind of look at that difference is they're both useful, but one's more oriented towards like a chronological model of an attack. And the other one's kind of just by category, what can happen here, right? And so when I'm looking at an attack, I'm trying to describe chronologically, like, how does it progress Kill Chain pretty good at that, there's a few things that I would maybe add in there just to get a little more detail. But you know, models or models, a lot of detail. And then mitre attack is, you know, just kind of thought whole, like game board of moves, right, with running burning time. And with that addition of pre attack, yeah, it would be interesting to see if they start making it maybe a kill chain esque, like, you know, pre attack stuff, I think they are actually physically putting on the left of the matrix now, and kind of turn into one of those chronological things. So I think it's a great thing for the industry to have, right. It's it's an awesome resource for blue team members who might otherwise. So ties in with this.
34:11
circling back to your use cases, I think one of the things is very important. And we we know, we're getting better as an industry is to do the red teaming, just the validation part, validate that what you've got in place is actually working the way it's supposed to be working. And so you don't have to wait for the incidents to happen, or go into it earlier. And also the attack simulation tooling, which is also very much progressing. And there's a lot of open source, great things out there. You can use to do like breach and attack simulation. And I think it's very important to to validate what you've got, you can use these metrics, and I think that it's valuable because you can do that by continuously, but every now and then you need to have challenge yourself and also your SOC. If nothing really bad happens for a long time. You know, will you still be prepared for the worst so The effing red teaming is very important to do, just to keep everyone sharp and on the edge.
John Hubbard 35:06
Yeah, it's like, I always kind of compare it to testing your smoke detectors, right? Like, you got to make sure that buttons still here, you know that that alarm will still go off? Yeah, it sits there, like the green light blinks every once in, right, like, I think it's working right. But actually try the thing you might find out in a very unfortunate way that it wasn't doing what you expect it to do.
35:27
Right. And the blinking green light will probably be your metrics, you know, saying I'm in control. But yeah. validation can't hurt.
John Hubbard 35:37
Right, right. So diving, one more layer kind of more technically deep you also have which called the Tahiti kind of threat hunting methodology. Could you explain that briefly. And what brought that about and what that contains,
35:50
we created this within the ducks, financial isec when I was the product owner at the fog bank, and I was looking at a threat hunting as well as in terms of proper process we were struggling with, how do we need to address this sort of as a standardized process. And we were looking for proper documentation couldn't really find it. So first thing we did is no just check with the other financials and see if they were you guys with threat hunting. And everyone was sort of at same moment in time is looking struggling to find the right way to do and so we came together and started working out this Tahiti methodology as Tahiti approach basically to threat hunting is also an abbreviation standing for target hunting, integrating threat intelligence. So we wanted to take a threat intelligence approach to threat hunting, just have a driven by threat intelligence, because of course you can, if you take a threat hunt, you're going to start out with some hypothesis. And that's about a million of those you can probably come up with. So what is the right thing to be focusing on it again? And this the same thing that we had we discussed with with the mitre attack? What should you be doing first? And I think intelligent threat intelligence, very important, they're part of the things currently going on in the world. What are your the threat actors that are very specific to your sector? Or maybe your geographic region? What are they doing? What types of attack methods are they using, and perhaps some of that information you can take into and create a hypothesis, which is more based on your current situation, your current level of protection, and also your your current threat landscape for specifically for your organization. So that was the whole idea to create something that was more risk driven. So that's why we created that ad for hunting methodology. So
John Hubbard 37:37
with Tahiti, you have certain kind of tie ins to threat intelligence enumerated, you have metrics broken down and all that good stuff. I think it's a it's a really nice way of kind of looking at threat hunting, you know, is a big topic. And that's that's another question to get right is like, how do we start threat hunting? How do we measure threat hunting? threat intelligence, as you said, a key piece of that, right? Part one is, are you focusing on the right thing, you can threat hunt for people coming in the ceiling of your data center, but it's probably not a good use of your time, right? Because it's not really something that happens versus like, I don't know, so it's compromised, or whatever it happens to be right. Where do you suggest people start it? You know, if this is a new SOC, right, someone's just building SOC for the first time? Where would they source the kind of threat intelligence? And how might they take the first steps and just picking the right things the threat hunt for,
38:25
I would say, start out with the mitre attack framework in use to detect the detect to the tool created by Hubbell bank. And what those guys did is sort of create an overlay for the mitre attack framework, based on the detections in a data sources that you have, don't throw something you don't have data source for, right, you can't threat hunt, if you don't have any data, you need to date it. So that's the first thing you need to data. So what you probably need to focus on is those things you do have data for, but you don't really have proper detections for and I think that's the sort of the area where would you first start out with your threat hunting, that's not even intelligence driven? There's just lack of visibility driven, which is another way to approach it. Where are my visibility gaps, and that will be probably the right thing to to focus on if you're hunting for threats.
John Hubbard 39:16
So if a team is following the Tahiti methodology, and they're going through their data, looking for everything, what do you expect the output to be of like a good threat on whether successful or not right, like what are the kind of objective metrics and pieces of a threat hunt that you would expect to be produced at the end?
39:34
Right, yeah, so we had we did have a discussion on metrics because as a threat Hunter, of course, you don't really want many management metrics interfering with your work. But on the other hand, as a manager, you don't want people doing threat hunting investigators all the time with no output. So you do want to have some output. And one of the pieces of output, you can find to know what sort of incidents that we detect. That's the ultimate error code. We've done a threat hunt, we were looking for that particular threat. And we found it and we stopped an incident which was going on in our infrastructure without us knowing it. So that's the ultimate result from a threat hunting investigation. But it's probably not going to be every single threat hunt, it's going to end like that, at least if it would, you know, you'd have a major problem, probably Hopefully not. So, there's other things are very important as well, which is basically to help identify weaknesses in prevention to help identify weaknesses in perhaps in architecture, and also in your detection capabilities. And the third hunting that you did, we will probably lead to new ideas about how to detect certain things. So you're currently also continuously improving your, your detection capabilities as well. So that's the sort of thing that you should be focusing on as threat hunters as well, not just the incident, but also the things around it, you know, helping to continuously improve your cyber defense.
John Hubbard 41:02
Yeah, like that way of breaking it down, you know, the way I kind of think about it is pretty much the same kind of maybe restated. But you want to have the metrics on like, what did you find, right? Because we're assuming a lot of time there is something to find, but not always right. And a threat hunt, where you did good threat hunting, but you didn't find anything isn't a bad thing. And there just wasn't anything to find, right? You're
41:21
not compromised.
John Hubbard 41:22
That's a good thing, right? When you do find stuff, of course, you want to take the metrics on that. So you can say like, when we did threat hunt, we found stuff. And here's what that stuff was, it was important. But when you don't find stuff, you still need some evidence of the effort. And so having metrics I like tracking, like as a result of hunting, we also created these new analytics, these new use cases, we had these better ideas on how to do stuff. And so that's kind of my approach in uncovering it. Right? It's like,
41:47
absolutely.
John Hubbard 41:49
And what was the the other output from that effort? What improvements did lead to? final question for the day SOC management, SOC monitoring, and the new state of the world, which will probably be more work from home and cloud focused services? What do you see in the future for these kind of areas? And how do you think where we are now? And 2021? How are things going to evolve maybe over the next three to five years,
42:17
I was also thinking about this, because in the SOC CMM, you have the process domain, which also covers operations and facilities, which is always a sort of the standard thing to look at in the analyst workstations, and the wall displays and all that sort of stuff. But yeah, right now, I don't think it's proven not to be that important anymore. Now, with almost the entire workforce working from home, I don't have a wall display in my home. So probably don't need one. So I think we've kind of that sort of thinking has probably changed. And I don't think that this year, Grayson center, as we knew it, will probably look the same anymore. So that's definitely a change. Also, cloud is definitely a new world, you can't map your on prem security solutions, one on one on the cloud, you know, different dynamic going on as different technologies being used, you need to go cloud native, if you're as a company, you're not fully operating in the cloud, yet, you'll probably need like an on site, on prem security team, as well, as a cloud security team. I would say, you know, that could be the same person. But it's, it's different. In terms of the normal city, you need to have, you know, the experience you need to have as well. So I would say for cloud, and if I go fully cloud native, but you probably need to have an on prem team as well. So I think there's two worlds will coexist until like, everyone goes fully cloud native, which is probably only a matter of time. So I see skewed ration centers, going more into the cloud using cloud native tooling, which is, you know, I have to say, I'm very impressed with what's what's available in terms of cloud native security, too, and also security monitoring and stuff. So that's really great. The
John Hubbard 44:03
way that we are doing kind of distributed teams now, with security operations centers, you know, we used to all sit in the same room, we used to all be able to yell to each other and have these video walls and stuff like you said, Are there any technologies or in terms of management, like communication with people and making sure those lines of communication stay open? Is there any tactics techniques, you've seen kind of implemented recently that have been a huge help in that area to kind of adjust to the everyone's kind of physically in a different place? kind of work team?
44:36
Not really probably. But you know, I think it's very important to have your informal chats as well. So it shouldn't be all about work because one of the pitfalls is because you don't know you're no longer see each other in real life. every meeting is going to be on topic focusing around a certain aspect of work, which takes us out of the social, all the social, the social part of being in a team That, ultimately will threaten the cohesiveness of the team, if you will, I think it's very important to also focus on doing that social part as well. So maybe that doesn't have to be daily, but at least weekly, you need to have a session, like 30 minutes or an hour, in which you're just talking about other stuff besides work just to keep that team feeling. And probably what we're going to be seeing in in the future is your workforce bodily working from home, and then also on site as well on site presence as well. And I think that we've seen in the last year, if you're looking at, for example, the usage of zoom and other technologies is really exploded. And I think it's really improved over the year years as well. So the technology is already there, you know, working together remotely is already it was just only I know, very uncommonly used within a SOC context, probably. And it's getting more and more common. And I think right now, because I've been to my job in, I think, yeah, probably in two weeks from now, I'll be working from home for a year. I've been onside like five times, maybe four or five times in that whole year. So it is completely different than before. And you need to have the the social aspect, you know, within the team, you need to cherish that and still build on it, even though it's remotely.
John Hubbard 46:24
Yeah, absolutely. building those personal relationships within the socket is a crucial thing. And as we bring in more team members, you know, that maybe weren't members of the team, when this whole thing started, it's going to be crucial to make sure you still forge those personal connections to make sure everyone's doing the best job possible and kind of communicating openly and freely. So
46:40
yeah, and one thing, which is, I think, very important, and might just be like an open door, but I've seen it differently. Turn on your camera, if you're doing a meeting, it makes all the difference. And there's a lot of nonverbal communication going on for everyone. And you need to take that into account as well. So just turning off your camera and having the audio only meetings is really killing the atmosphere in the team as well. So always said on the just always turn on the camera.
John Hubbard 47:09
Yep, absolutely agree with that.
47:11
Even if it's messy.
John Hubbard 47:14
We have virtual backgrounds. Right.
47:15
Right. Yeah.
John Hubbard 47:17
All right. Well, I think that wraps up our time for today. So thank you very much for joining us. Where can we find all of your awesome content and frameworks and everything we mentioned today, with websites and blogs do you have that we can send listeners to
47:30
so it's a SOC Seaman site, which is sought dashi meme.com. If you want to look at the hidi or maximize your SOC seamen.com slash magma or slash Tahiti, I usually post my new IDs and just questions or insights on my LinkedIn. So you can follow me on my LinkedIn, which is linkedin.com, slash i n slash cyber defense specialist. And you can connect with me.
John Hubbard 47:54
All right. Well, I think that does it for today. Thank you very much, Rob, for joining with us. Thank you so much for your contributions to the community with these awesome, awesome, super detailed frameworks that strike at some of the most confusing and most asked about pieces of running a SOC. So definitely, big thank you for that, and very appreciative of all the effort and thought that went into those things.
48:14
Thank you, gentlemen. Thanks for having me.
John Hubbard 48:16
Yep. Have a great one. Hey, blue teamers. I hope you enjoyed today's episode of blueprint. If you've got a second and want to help support the podcast, please subscribe and leave us a review on Apple podcasts. It would be really, really meaningful to us and if you have any ideas or suggestions, I would love to hear them. Your reviews are going to be one of the best ways to help others find this podcast. So anything you could do, I would be a big help. As always, thank you for listening. You can connect to me on social at sec hub sec HQ, BB on Twitter, on LinkedIn. So until next time, thank you for listening to the blueprint podcast.