BSidesCharm 2026 - A Standard For Investigative Playbooks

All right, good afternoon everybody. Thank you so much for sticking it out to the afternoon of day two. I know it's kind of rough. Everybody's dragging a little bit by this point in the conference, but I appreciate you uh coming out to my talk. I also appreciate the fact that nobody booed immediately upon seeing my title slide here. Uh I gave this talk in Rochester near Buffalo and just the sight of a Dolphins coach was enough to drive them into a frenzy. Um I I picked this one for a couple reasons. One because obviously I did a Google image search for playbook and a bunch of NFL coaches came up. But I always appreciated that Mike

McDaniel looked like somehow the guy who runs the team blog or like an analyst from the infosec team got promoted to coach after some some sort of wacky hijinks. So, good role model for all of us. Um let me move forward a little bit here. Uh so, my name is Matt Gracie. Uh I do a lot of different stuff. Uh for the context of this talk, uh I'm going to talk about my day job. I am a senior engineer at Security Onion Solutions. Uh how many people are familiar with Security Onion, the software platform? Okay. So, to dispel any confusion at the beginning here, Security Onion is a free and open software platform. Uh you can

go to our GitHub. You can download the install ISO for it. We don't even want your email address, okay? I work for Security Onion Solutions, which is sort of a commercial support organization behind that free and open product. Uh but this is not a sales pitch. I'm not going to try to sell you anything. Uh everything that I'm going to demonstrate is part of our free platform okay? I know it can be a little bit confusing because the name of the company and the name of the project are similar, but I am not here to sell you anything. I'm just here to tell you about some cool stuff. Uh in addition to my job at Security

Onion, I'm also the director of the graduate program in cybersecurity at Canisius University in Buffalo, New York, which is where I live. Um I organize the local B-Sides Buffalo conference and a bunch of other community stuff. Just general uh nerd highjinks and shenanigans. What I'm going to be talking about today is a new standard uh for writing investigative playbooks. Uh how many people know Chris Sanders or at least have heard of Chris Sanders? Anybody? Okay. So, Chris is kind of a old-school Mandiant guy and he's done a bunch of really interesting research in the last few years about how analysts and investigators think, right? And how people process knowledge and a lot of sort of

cognitive behavior stuff. And what he's done is he's taken that information and he drafted a new standard for writing investigative playbooks. So, basically, how do you better equip your analysts with the information that they need uh in order to effectively investigate alerts and and uh other malicious activity. So, that standard is called the Human-Centered Investigative Playbook Standard. That's what I'm going to be talking about in this presentation. Uh we've implemented part of it in Security Onion, so I'm going to demonstrate what that looks like. The standard is freely available. It is licensed under Creative Commons. Uh if anybody else is an open-source developer or working on tooling like this or you want to talk to

the vendors that you do work with, they would be able to implement this at no cost, no licensing. Uh it's just a very cool contribution that that Chris has made to the the cybersecurity community. Um a couple little housekeeping notes before I get started. Uh one, I saw some of you are familiar with Security Onion. Uh if you want Security Onion stickers for your home lab, I got a bunch of them here at the edge of the the stage, help yourself. Also, this slide deck is posted on my GitHub. Uh the link will be at the end of the presentation, so you can grab a copy of the slide deck if you want it. Don't feel like you need to write

everything down or take pictures. I mean, you're you're welcome to, but uh the slides are freely available uh for everybody after we're done. All right. So, first things first. Um I'm sure most of you already know this, but for people who are new to cybersecurity, what am I talking about when I talk about a playbook? And this is just kind of a a generic definition of a playbook, a detailed framework that outlines organization-specific procedures for handling events and incidents. Or if you're like me and you work for a health insurance company where you weren't allowed to call things events or incidents uh for handling the recent unpleasantness. Uh it includes predefined courses of action that provide guidance on

detection, analysis, et cetera, et cetera, right? So, basically, what we're talking about when we talk about a playbook is this threat or this alert or this issue comes up, here's a step-by-step list of the things that you do to deal with it. Somebody gets a phishing email, great. You know, run the URLs in it through URLScan, blacklist the the sender address, you know, figure out where it came from, who else it went to, et cetera. You're going to have a list of steps that even your most junior analysts can go through in order to investigate and mitigate the threat. All right, playbooks are not a new thing. We've all been doing this for a long time.

Um some of us tried to implement soar, right? Trying to do uh automation on top of our existing playbooks. Uh some of us tried to do soar without existing playbooks, which was an exciting adventure for everybody. The uh I Sorry to digress, but the the all-time best quote I ever heard in any conference talk over the 20 years I've been doing this was somebody who said, "Process first, then automation, because when you automate a mess, all you get is a really fast mess." Love it. So, that is sort of a classic playbook. Now, we have some principles that we work from when we're designing a playbook, and we don't always explicitly think about these, uh but Chris lays them out very well on

the home page for this project. For one thing, in any given investigation, analysts are going to ask investigative questions that they answer with data, right? I get that fishing email, I'm going to ask some questions. Did the spam filter see this? Was it scored at all? Have I gotten an email from this domain before? Have I gotten an email from this sender before? Has this recipient gotten a bunch of these, right? Is their name on some kind of list? We're going to have questions uh to build context around the event so that we can investigate it effectively. Uh analysts will encounter common scenarios across diverse investigations, right? Um again, fishing emails. No organization receives one fishing

email, and then they're like, "All right, well, that's never going to happen again. Security achieved, guys. We're good." Uh you're going to have classes of incidents that come up over and over again. Uh somebody's going to download a dropper. Somebody's going to enter a phishing email. Somebody's going to hard code their credentials into GitHub. Right? Somebody's going to do something and you're going to need to respond to it and investigate it and get the rest of the context. And in a large enough corpus of these events, these incidents, these unpleasant situations, uh you're going to have sort of playbooks for these broader classes of event right? Many, not all, but many of the initial investigative questions that you ask can

be predicted. See, this is This is an interesting observation. If you have a particular class of event or particular class of alert or particular class of malware that you need to respond to, the first few questions that you ask are going to be very predictable. But those questions will, of course, lead to more questions. And those questions get less predictable as we go on. So, this diagram, uh that Chris puts up on his page, I think illustrates it really well. You have a common investigation queue, all right? A common alert, a common malware, a common something. The first question that you ask is going to be predictable. Who sent the phishing email? What was the recipient address?

Whatever. Next couple questions will get less predictable and then less predictable from there. And then next thing you know, uh you're trying to figure out who registers domain names in .ru. But, you know, at the beginning at least the investigation is going to be um predictable. It's going to be steps that we can foresee, that we can write down, that we can hand off to our junior analysts and say, "Hey, once you get to step five, if you still don't know what's going on, come talk to a senior." Right? But most of the stuff you'll have wrapped up by step five. Finally, if you can predict the questions that analysts will ask in investigation, uh if you provide the analyst with a

list of those questions when they encounter the queue, you're going to have significant performance benefits. I don't just mean that they're going to be able to do the investigation faster, right? Although that is part of it. If they have a list of established checks, and they can work through those checks without having to dedicate a lot of processing to it, they'll get through it faster. But what I mean is they'll also be more thorough, right? There's a reason why pilots use checklists, because even if you've done the same thing a million times, even if it's your career, it's still possible to skip a step, to forget something, right? So, what playbooks allow us to do is

explicitly articulate all the steps in the early phases of an investigation, and then follow them the same way every time, right? It's a good tool for consistency. It's a good tool for training. All right, so that's basic playbook principles. That's why we write these things. That's the whole point. So, let's talk about a simple example scenario, and I have some actual security onions here as prizes for people who answer questions. You receive an alert in your sock that an endpoint belonging to a user in accounts payable, it's always someone in accounts payable, has launched a curl process. What do you need to know? So, if you're investigating this, who has a guess? Yeah. Have we seen this before? Good.

Anybody else? Yes. All right, those were all good answers, but you only get one onion. All right, anybody else? Yes. Should they be launching curl at all, right? Is this expected behavior for an accountant. Sorry, I'm I'm not left-handed. Um >> [laughter] >> All right, these are all good. So, what did I have in my little word cloud here? >> [clears throat] >> Excuse me. Uh what is the parent process, right? If they're launching it directly from PowerShell and they're an accountant, that is sketchy. If it's launching from winword.exe, more sketchy, right? So, we want to know where this is coming from. Does that user have admin rights? Right? Either locally or in the domain.

Uh if you're asking yourself, why would some random accountant in accounts payable have domain admin rights, I would like to congratulate you on never working in a large enterprise. >> [snorts] >> Have they run curl before? What was the URL they were going to? What was the file type they were retrieving, right? What's the hash of the file? Does VirusTotal have a record of that hash? Right? These are all questions that we would put in the playbook. Now, the human-centered investigative playbook standard, HCIP, combines standard analyst playbooks with machine-readable query language, right? So, the idea is we have a syntax that will generate a playbook for the analyst, will give them investigative steps, but at the same time is tuned to connect

to your your tooling and pull out the supporting evidence that you need, right? So, going back to our curl command, it won't just say, what is the parent process? Analyst, you should figure that out. It will actually go into the endpoint logs and figure out, you know, from the execution logs, what is the parent process of this event. Does the user have admin rights? Well, does the execution have the admin flag set? Does VirusTotal have a record of that hash? Well, we can reach out and check, right? What we're doing is we're integrating the playbook into our analysis platform, so that all of this evidence can be pulled out and presented to the analyst. Again, our goal is to

make the investigation more productive, more effective, more repeatable. So, some components in an ACIP playbook. Um every step has a plain language investigative question. This is aimed at the analyst. What sort of evidence are we looking at? What are we trying to prove? What do we want to do? Also, some context explaining why that question matters, right? So, if we say what is the parent process, then the context might be because if the parent process is a web browser, we're going to deal with it differently than if the parent process is a raw PowerShell session, or if it's an Office document. The question will also contain appropriate data and log sources for answering the question, right? If I'm

collecting these logs in my environment, I should be able to query them directly. Why not do that automatically, so the analyst doesn't have to figure out the query language and where to find it? We can just pull it out for them automatically. Relative time ranges for pertinent evidence. Um if we're querying something like the DNS requests that were made by an endpoint, we might want to do that 10 minutes in either direction, maybe. Any more than that, we're going to get drowned. But, if we're saying has it ever gone to this domain before, or has curl ever executed on this endpoint before, we're going to have a wider time frame, right? Maybe they Maybe they use curl to

do their end of month or [snorts] end of year end of quarter reporting. We don't know. So, we may want to go back further to see if this is normal behavior for that workstation. And then finally, again, search queries tailored to the analyst tools. Pull this data out automatically and show it to the analyst so they can make an informed decision. There are several categories of playbook that are that are outlined in the standard, right? We can have playbooks for particular artifacts. If you run across this piece of malware [snorts] or this uh um this file hash, enact this playbook for attack techniques, for particular phases in an attack, right? If you see somebody moving into

lateral movement, you may write a playbook around what evidence you can gather to see what other what other uh endpoints they've touched. Uh for particular malware families, the one that we've implemented at this point is playbooks for detection signatures. So, for those who are not familiar with Security Onion, one of the components that it ships with is Suricata. Suricata is, among other things, a signature-based IDS, an intrusion detection system. So, that means as your network traffic is going by, Security Onion and Suricata are observing it and comparing that network traffic to, I don't know, 65,000 signatures, something like that in ET open right now. So, for each one of those signatures, we have deployed a playbook. So, if one

of those signatures fires, then you are automatically um given access to a playbook with investigation steps for that particular alert to tell you what other information could be helpful in your investigation and pull it all out of the uh out of the back end for you. All right. So, let's talk a little bit about a detection engineering scenario. Uh this is actually from a detection engineering talk that I gave at another conference last year, but that's okay. If you're not familiar with the Bats conference talk cinematic universe, uh we can walk through it. Won't be a problem. A recent threat hunt identified data being exfiltrated by a workstation by a malicious process called wombat.exe. This executable had an original file

name of DNS exfiltrator.exe and was apparently sourced from GitHub. This is true. If you go to GitHub and do a search for DNS exfiltrator, there's a really cool little piece of uh malware there that I've used for a lot of training sessions. It was written to disk by another executable called AVUpdate.exe, which was downloaded from a counterfeit website that the user was sent to by a phishing email. Uh wombat.exe was exfiltrating files using encoded DNS subdomains in very long TXT queries all for the domain threescoops.online. Uh because .online domains were a dollar. All right. So, not to divert entirely into detection engineering talk, but who is familiar with the pyramid of pain? Awesome. All right.

Uh I saw a really interesting talk by Dave Bianco where he talked about how he came up with the pyramid of pain and he is um he's very proud of the fact that this is the world's most useful ever piece of word art. Um So, if we look at our pyramid of pain, for those of you who have not uh have not used this before, when we're detection engineering, when we're deciding what indicators of compromise to detect, what uh items to alert on, we want something that's near the top of the pyramid. Uh basically, the way these indicators are ordered is how difficult it is for an attacker to change the indicator between campaigns. So, how long are detections will be good

for is correlated with how high they are on the pyramid. Down at the bottom there is hash values. Hash values are very, very simple to change, right? If >> [snorts] >> a new piece of malware comes out or if you're hashing on like a an email value or something like that, they change all the time. So, if you write a detection rule that says, "Tell me if you see this hash value in my environment." It's probably never going to fire because they will have already changed it by the time you get that through QA. Uh same with IP addresses. We have the IP address of the website that data was being exfiltrated to, but you know what?

It's probably in some cloud service. It's probably turned over already. I don't want to say it's in Digital Ocean, but it's almost certainly in Digital Ocean. So, that's not going to be very helpful, either. Uh same thing with domain names. Uh threescoops.online, that has probably already been retired. Uh but as we get up toward the top there, we start seeing more interesting uh options. If we can write rules that detect particular network artifacts or tools or TTPs, right? Uh tactics, techniques, procedures, that's going to give us rules that are are longer lasting. So, going back to our scenario here, who would like to take a guess at what would be an effective rule for catching

this in the future? And I I have another onion. Yes.

Excellent. I I don't know if I can throw it that far.

Oh, it does bounce. Sorry. Right. So, if we're writing a detection rule for this, a good rule would be if you see DNS TXT queries that are above a certain length, right? Uh Anything above 100 characters, 120 characters, that's suspicious. We should investigate that. Now, let's say we find a client in our environment that is generating these long TXT requests, right? I'm sure I'm not the first person to make this observation, but in my experience, when you're threat hunting or you're looking for weird stuff, especially in a large network, like 2% of the time you find evil and like 90% of the time you find IoT stuff that's been misconfigured and like 8% of the time it's that help

desk getting turned. So, if we find a client in our environment that's generating these long requests and we want to see if it's a true positive, if this is something actually bad, if this is data being exfiltrated, or is this just something misconfigured or somebody screwing around, you know, what sort of facts do we want to look for? Yes. Has it been Has it been approved before? So, have we seen this before? Okay. Yes. >> Does it have high entropy? >> Does it have high Oh, dang, that's a good one. Does it have high entropy? You're going to have to You're going to have to come up if you want it. That's a good one. Yeah, so what is the

What is the context of the subdomain that we're seeing that TXT request? Very good. All right, and I got one more onion. Yes. >> Is it someone's server or is it someone's desktop or is it a server Is there somebody using it? Would it be a person doing it >> Okay. Okay, so what's the context around the query that's happening, right? All right.

All right. So these are all good and let's let's take a look at the list I've got here. So are there other DNS queries of type TXT from this endpoint? Um I would not be surprised to see some weird like corporate print queue software that's built on top of this. Why? Because it always seems to be. Uh what was the endpoint process that generated this DNS query traffic, right? Is it something that's running from the user's downloads directory? Is it running from user's public? If so, uh-oh. Um but if it's not, you know, maybe it's just some weird Microsoft thing. Are there other endpoints in the environment that are requesting this domain, right? If you have just one

endpoint that's generating this weird DNS traffic as opposed to seeing it across all the endpoints, right? That's that's going to tell us how widespread it is, how likely it is that this is something legitimate that we're just misinterpreting. And finally, what DNS server are these queries going to? If someone's trying to exfiltrate data, they're probably going to send it right to their own DNS server, right? They're probably not going to send it to your internal DNS server inside your firewall. So these are all good questions. This is all stuff that we can build into an investigative playbook. All right. Does anyone have any questions at this point? Okay. So let me flip over. See how this works.

All right. So I I do apologize. I pre-recorded the demo. Um I will do my best to walk through it. The uh the text is is not super huge, but uh there are seats in the front if you're ever in trouble seeing. I've I've reached the age where I've got those progressive lenses, so I know I can't see for more than like four rows back, but just wanted to mention it. All right. So, this is a Sigma rule for that DNS text record detection. If you are not familiar with Sigma, Sigma is a vendor agnostic metalanguage for writing detections. The idea is you write the detection characteristics into this sort of YAML syntax. They're then compiled for the

appropriate back end or the appropriate SIM or whatever tool you're using. And then the the detection goes into effect. It basically is compiled into the appropriate query language and run periodically against the logs you've collected. In Security Onion, in addition to Suricata, we also bundle Zeek. Zeek generates data based on the network traffic that it sees, and in this case we're looking at the DNS query logs that were generated by Zeek. >> [clears throat] >> Excuse me. So, title here, we see, you know, detecting lengthy DNS text requests. There's a UUID, description. And then the meat of it here is the log source and the detection stanza. In log source, we see we are looking at

DNS logs generated by Zeek. And then in detection, we are looking for logs with a DNS query name type of TXT and a DNS query length greater than or equal to 200 bytes, right? So, this will compile into in Security Onion an elastic query language string. That string will then be run against the collected database. All the logs in the database every 3 minutes. If there's a match, it'll raise an alert. Okay? Now, to accompany our new detection here, we've also written a playbook. And I totally forgot that this is a video. I apologize. All right. So, back down here to play. So, I'll stop trying to click on tabs. All right. So, here is the DNS TXT

playbook. And we see at the top here, you know, playbook for lengthy DNS text requests. We have an ID. This is the ID number for the playbook itself. Created, modified, that's all exactly what it sounds like. Uh and then we get into our questions. So, these are the questions in our playbook. And this is all written in this very simple, you know, YAML-style syntax. Question, are there other DNS queries of type TXT from this endpoint? And then the context, again, so that our junior analysts understand why we're asking this. Well, because exfiltration using this encoding will generate many text queries, but all for the same base domain. We are looking for DNS queries plus or

minus 12 hours from when the alert fired. And we are saying, "Okay, look at my network logs. I'm looking at the DNS logs in particular, the DNS service. I'm looking for DNS query name uh or query type name of text. And I'm looking for anything from the source IP in the alert. That's what this curly brace sort of Jinja syntax is here. It's saying, "Whatever the source IP was in the alert that fired, I want to search for the DNS queries from that source IP of type text. And then return it in a table. I want the DNS highest registered domain, that is, what is the the domain name. I want the query type. I want the

destination IP, and I want to know who owns the uh the destination IP and why it's DigitalOcean.

All right, so there's all that and then we have our next [clears throat] question. Are other endpoints in the environment requesting this domain? We see here we are searching for any logs of that DNS highest registered domain being requested. Um our selection is the event source IP and then you see here in the condition we're saying I want anything that matches that highest registered domain and does not match the source IP. So basically, give me anybody who's requesting this domain except for the one that triggered the alert. So if anyone else in my environment is asking for this top-level domain or this uh this domain name, uh I want to know about it, but filter out

the ones that I already know about that are triggering this alert.

Okay, what DNS server are these queries going to? Same thing, we're searching for the highest registered domain and then we are sorting uh into a table by source IP, highest registered domain, uh query type, and destination IP. So this will give me a table of anybody on my network who's requesting this domain, what type of DNS query they're making, and where they are going with it.

All right, and then finally, what process is generating the request? So, I'm going to search for that highest registered domain. I'm going to search for logs with image in them, right? So, when you're when you're recording Windows telemetry, it will generally record the process name as the image name, right? Or you may have original image name. So, I'm saying I only want process logs from endpoints of DNS queries being made for this particular domain, sorted into a table with the host name, the process name, the process entity ID, that's sort of a uh a GUID that the endpoint logs use to tie together a bunch of logs for a particular execution of a process, the question type, and the destination

IP.

All right. So, that's what it looks like when I'm drafting these rules. Uh this is the Security Onion console. If you haven't used Security Onion in a while, uh this might look a little bit different. We just refreshed the interface with Security Onion 3. It just came out a couple weeks ago. Um it's similar in functionality to the 2.4 branch. We just kind of sweetened it up a little. Um speaking as the guy who records all of our online training materials, it's just awesome that now I have a bunch of stuff to re-record. Uh but, this is what it looks like when you put all this stuff into action. So,

see here we've got a bunch of alerts for that detecting lengthy DNS text requests rule. We're going to open up the tuning interface for that so you can see what it looks like. Here I've got my detection source. That's my actual detection rule, the first tab that we looked at in that text editor. And then you see there's a tab there that says playbooks. And this is the the second tab that was in the text editor, right? So, this is all the information about what I want to ask the analyst, what sort of information I want to automatically pull out of my logs in order to present to them. And when I go back here, I open up one

of my alerts. The alert details tab is all the stuff that you would expect from a typical similar, right? Destination IP, source IP, process, all that stuff. Uh all the enrichment, geo IP, all that. But, the second tab here, uh guided analysis, is the one that uses this playbook functionality. So, you'll see here my first question, "Are there other DNS queries of type TXT from this endpoint?" What happens is it puts that in the context right into the interface here, so my analyst can see it. And then next to this uh >> [clears throat] >> Excuse me. Next to this uh hunt icon, this crosshairs icon, I see the EQL query for the data that

I'm pulling from the logs to support this question. Right? That was compiled from that playbook rule. Now, what it'll do is it'll pull all that data out of the logs, and it'll give it to me in this table with five results. But, if there's more than five, I can pivot over into my normal hunting interface, and it'll give me, in this case, 189 results. So, these are all of the text requests that were coming from that endpoint. The query has already been pre-written, pre-generated, made available to my analyst, right? So, as I'm stepping them through the investigation in this playbook, I'm making all of the evidence that they need very easy to access. Just one click to pivot.

"Are there other endpoints in the environment requesting this domain?" Uh and I don't know if you noticed, but yes, I added a different IP address there. What DNS server are these queries going to? And we see here I've got one IP address that's requesting this domain from 8.8.8.8 and it's making a type MX request. And then I have four requests from the same source IP all going to this 54.144 address, all doing TXT, right? So, while I do have more than one endpoint requesting this domain name, one of them looks very suspicious and one of them just looks confused.

Yeah. Then finally, what process is generating this traffic? Again, in this case, I pre-wrote that query to go in and look at my endpoint logs and pull out any DNS requests uh, for that domain for threescoops.online. And I see, okay, I've got these queries. They were coming from the host mbishop-win10. The process name is whistler.exe. And there's the process entity ID, that's what ties together all my endpoint logs. And then I see the DNS query itself off to the right there. What this DNS exfiltrator actually does is encodes everything as a subdomain in base 64, I think, so it looks kind of They're They're very long and that's why we're able to detect them.

All right. Now, if I want to dig into these process logs a little bit more, I can pivot from there into my process logs. Right? I correlate on that entity ID. And I can see here I've got network logs, library logs, file logs, and process logs all for that endpoint. Um one of the components that comes in Security Onion is the Elastic Agent. Uh it's written by our friends at Elastic, hence the name. Uh but it pulls endpoint telemetry from the endpoints in your network. So, whether it's Windows, Linux, macOS, uh you can install this and it will pull in not just regular logs, but it will also pull in low-level telemetry. Stuff like file creation events, registry changes,

network connections, DNS queries, all that sort of stuff. Um this is very fun uh to run at home, especially if your kids have laptops. Uh but all of this information gets pulled in and normalized. And again, because we put it into that playbook, we're able to pivot. I mean, think of how cool that is. We said, "If you see a DNS query that matches these characteristics, raise an alert." And then we're able to pivot straight from that into, "Okay, give me all the information about the process that made that DNS query." Right? We're we're going from the network to the endpoint uh log information with one pivot. It's pretty sweet.

So, we see there we've got the the process command line. We've got all of the other queries that were being made. Again, that's all like base 64 encoded stuff. Uh we have all of the DLLs that were being loaded by the process. So, if we have a particular DLL we're concerned about, we can go into our logs and pivot and look on that.

And we go into process all info, and this gives us all of the information that we have logged about that process running on that endpoint. All right. So, we've got stuff like the file path, file creation events, and so on. If we want to concentrate on the process events, we can do that and see just the process log. So, we see here we've got uh Mbishop-Win10 is the host name. Uh the username is Mbishop. The process parent is powershell.exe, which uh-oh. And the uh the process name is whistler.exe, right? So, we've got all of the information about the user, the host name, the process. If we pivot here, we can go to process ancestors. And this will give us a full uh

execution tree going back to when the machine was booted of where this process came from. So, we've got winlogon launching userinit. Userinit launching explorer, explorer launching powershell, powershell launching whistler, right? So, we can see the whole history of it. If we dig into the file creation side of the logs, we can see where this came from, where it was downloaded from, what web browser they pulled it down with, et cetera. And use that to pivot around and do more stuff. And again, we're able to expose all of this in a way that will not overwhelm a junior analyst, but will give them all of the information that they need to continue advancing the investigation, right?

We were trying to kind of knock down those barriers around learning the query syntax and building the ideal queries uh by providing all of that ahead of time for this particular alert.

So, last couple of points. Um playbooks are very helpful as an investigative path. They're very helpful as a store of knowledge, and they're very helpful as a training aid. Uh using a playbook during an investigation will help your junior analyst learn by doing. Codifying knowledge into playbooks will help scale that senior analyst experience across multiple teams. Uh one of the crises that is facing Infosec uh as always is there just are not enough seniors to go around, right? We need to find ways to share our knowledge with the new folks that are coming up. Uh or the bad guys need to stop. Yeah, that's how likely that is. Um but by doing stuff like this, we can

take that information that that the seniors have locked up in their heads, make it available to the juniors, and help them build those investigative skills. Uh the act of writing a new playbook forces reflection and careful evaluation of assumptions and investigative techniques, right? Even if you're just getting together you know, your senior engineers once a month or a couple times a quarter to talk about writing out these these playbooks, you know, what are the threats that we're facing? How do we want the juniors to handle them? How do we want to investigate stuff? Right? That can really help uh build up the capabilities of your security program and make these investigations more efficient, more repeatable.

Just better. Right? Like it says at the bottom, the standard isn't just a framework for guiding analysis, it's actually a tool for building better analysts, and we need more of those. All right? So, I think we have a couple minutes left. Um does anyone have questions? And I am out of onions. Yeah. >> This seems like a perfect like framework to do uh consistent queries. Have you tried like putting this in like log code as a skill to be like, "Here's here's the questions that I want answered." And to have it like it already knows the queries or to go out and what questions are being asked? Have you tried this in like a more automated

fashion with LLMs? >> [snorts] >> Uh Um so there is some AI assistant functionality that's built into our commercial offering. Um and uh I could talk to you about that afterwards if you like. Yes.

How do you I'm sorry. How do you balance

How do you balance automation with the with training analysts? Um Yeah, that's a good question. I mean, I I think of this is kind of training wheels, right? We're we're teaching the analyst what sort of data is important in particular investigation, where they can get it from, what the queries look like. Um there's no way to really anticipate the full investigation flow, but I think what we're trying to do is get through those first couple stages of the predictable questions uh while giving them the confidence and the skills to go out and investigate on their own. So I think it's a I think it's a balance, not really an either or. Yes. Uh do we have a repository for

playbooks? Yeah, all the ones that we bundle with the platform are on our GitHub. Um I think it's just securityonion-resources is the uh is the repo that it's in. Uh but that's all freely available. Uh one thing that I that I forgot to mention that I probably should have. Um there are also some broad category playbooks that are not for individual alerts. So for example, there is a malware playbook, right? So if you get a Suricata alert and it is from the ET malware rule set, but it's a new rule and we don't have a rule and we don't have a for that yet, it will instead default to sort of a generic malware playbook, right? Uh so

there's there's kind of a a net underlying it, right? There's even just a generic Suricata playbook like you got a Suricata alert, bro I don't know what this is. Um here's some stuff that might be useful, right? So you can sort of uh scaffold it by specificity. Yes. >> How do the

>> Uh the the playbook rules? The Sigma rules. Um so the Sigma rule that I that I presented on was was something that I wrote for this particular thing. The Sigma rules that are included with the platform are written by the Sigma project, so Florian Roth and those guys. Uh we ship with the s- the Sigma core rules enabled by default. And then there's like three or four other rule repositories that they have for stuff like cloud environments, right? Um and you can enable or disable those as you like. Those get automatically updated. It's at least once a day. I think it might be every 12 hours uh by Security Onion it reaches out to GitHub.

Um if you're using an air-gapped installation, so if you've installed Security Onion in an environment where it doesn't have internet access, then those Sigma rules will be updated the next time you update the core platform with the ISO. Yeah? Oh man, you're you're holding up a sign right under a light. I can't even see what that says. >> [laughter] >> Fine. Okay. Um one more? Anybody else? Yeah, in the back.

>> Um so the question if you didn't hear it was how do you come up with good questions for a playbook? And really there's that's that's just experience. Um You know. Yeah. Yeah, when you do a when you do a threat hunt and you come together with your lessons learned or when you do a purple teaming exercise and you come together at the end to say what should we have done here? Right? That's that's an excellent chance to put this stuff into playbooks. Um and again that's the whole that's the whole point of that second to last slide, right? We're we're we're trying to take the anecdotal experience of our seniors and turn it into a learning opportunity for

our juniors. Right? Okay. Um I will go out in the hallway cuz I think the next person probably wants to start getting set up. Um if you have any more questions, I'll be out there for a bit. Feel free to flag me down. Again, I got plenty of securityonion stickers that I don't want to fly home with so help yourself. Thanks. >> [applause]