 Hello, welcome to the incident response station. This is news in place for investigations. Basically, if you don't record it, if you don't document it, it doesn't actually happen. This is going to be a real world approach to IR communications in all forms. Right now, in terms of where we are in the instant response lifecycle. This is primarily focused on preparation with a end goal of having what you need at the post incident activities. And then a little bit of everything else. All right, now, news in place, what does it even mean. This is a culinary phrase, which basically summarizes getting all of the ingredients getting all of your tools getting everything that you need. In order to make the dish done and right there so that you can just put it all together without having to go and pull out extra salt or more seasoning vegetable. It's getting everything in place ahead of time. So that way the actual cooking portion goes as smoothly and as quickly as possible. This is separate from what I would consider general project management in general restaurant management. So this is going to be focused on for the analyst for you, what does it mean to get everything situated get everything laid out ahead of time. So that way an investigation goes as smoothly and as efficiently as possible. All right, preparation hindsight, but before you can get everything set up, you actually have to know what you need to get set up. What I recommend doing is go through what you normally use on a day to day basis, start adding a list, compiling it over time, and then kind of go review it. I incident type group it by the different tools you kind of need and hey, I do a phishing email I'm going to use these four tools so I'm going to make sure they're all grouped together. I need to make sure that I have access to active directory I need to make sure I have access to the email servers, getting those checklists together will help you know what you actually need at the start of an incident. You can just get going. Okay, envisioning the end at the beginning. Now the goal is to get everything that you need to get that final dish complete and perfect. But you have to know what what is required at the beginning. So you need to know what your requirements are. So what are the information you need for reporting what is the information you need for lessons learned. The auditor is going to be going through and, and checking off that you included in each individual ticket, or incident case. Do you already have templates, you have playbooks, go through all of the documentation go through all the requirements that you already have access to, and then compile yourself what you need, what you need to focus on during an incident. Now, if none of this exists. Well, looks like an opportunity. At least write them for yourself. I recommend sharing is carry. You know, make the documentation share it with your team, but at the very minimum, make it for yourself is absolutely worth the time investment. Now, this the goal. What do you need as the incident is being worked. How do you need to prepare it, how do you need to format it all of that kind of stuff is what you need to be thinking about before an incident is actually happening for the fire is, you know, on fire. So helpful tips and tricks, clean as you go we've all heard this, taking the extra 20 seconds a minute to write something down or clarify in your own notes, during the incident is worth the time. It's difficult when everything's on fire to take that deep breath and go hey, maybe I should added a little tidbit here next to this idea, maybe I should write out what I think about this particular piece of log, as I'm looking at it. That saves you so much time, like, as it's fresh in your mind, write it down, then personal pet peeve. If you have a abbreviation non standard or honestly any abbreviations acronyms, explain them go through and write them out at least the beginning. If you don't want to put them at each individual ticket, make sure you have a little mini dictionary. So that way, when audit time comes around to a time comes around, just give them a little cheat sheet to how you explain things and then be done. The auditor prefers it that way and I'm sure you prefer it that way. All right, now, biggest and most important thing. Write your notes like you're going to hit by a bus, your notes like you're going to get amnesia, and you're not going to remember a single thing, because I know I'm not alone in this sleep is like a little reset button. You know, once you go to sleep and he's like hey I don't have this pressure my head anymore. It's not all laid out in my head and it's nice cool visual thing in the back of my mind. I've slept, I moved on going on to the next hair on fire incident. Don't memorize what you can document. This is one of my favorite things because it's, you know, let the computers do the work. If you are someone who memorizes everything you get your hands on power to you keep doing it. This is for, you know, the rest of us. All right, looks like you're trying to do things the hard way. Can I help you out there. Short keys, speaking of abbreviations and acronyms. Make hotkeys go through hey I type in, you know, I are it's going to fill it out and write in incident response. All of those things where you can keep as efficient as you want to keep. But the end result is still the nicer fuller human readable version. For short keys, there's tons of different options. I like auto hotkeys. That's the first one that I came into and just kind of stayed with me. However, there are so many options out there. There are so many. BEM your own personal code, and people who have their own personal Python code hotkeys. It's crazy. Now, that gets into clipboard management. We do a ton of copy pasting. It's kind of like when you see someone right click and hit copy, and then go to the next page and it right click paste again, nothing wrong with it. Control C control V is just faster over time, especially for doing things 100 times. It's faster. Now clipboard management is the next step in that. If you're not already doing that. I highly highly recommend it. Because it's typically searchable on top of everything else. And then you can also store screenshots into it as well. The only thing here is you have to make sure you're setting up securely. You don't want to be the reason there's an incident. You don't have to work with the incident. So make sure it's secure. Make sure you get approval. Make sure it's handling all of your passwords and everything correctly. I do an auto clear. That's what I prefer to do. I like using something like a password manager like keep pass. It actually goes into my clipboard manager and deletes out the passwords and user names. I like to do it fast. Other types of pans and password managers might not necessarily do that, but get in there, figure it out. See what works best for you. Because again, there's no sure way to do anything here. The goal is to think about what you need during each incident, and the tools that make you faster and better. Getting into actual answer response work, building a timeline framework. I specifically say framework here because no two timelines are the same. No two tools handled the same way. Unfortunately, there's no two time zones or timestamps out there. If you're one of those lucky people who already have a centralized logging tool and everything's already standardized, patch it up in the back. You'll get a couple of copies. This is not for you. Time zones if you can't already insist as much as you can to stay with UTC. We've all run into problems. Been there a few years with local time zone conflicts, things like ingest versus actual, all those types of things, knowing that your time is a actual source of truth and making sure it is one standard and know what it is. That consistency saves you so much time and headache. Now, formatting. All right. It doesn't really matter if your org has a format that's preferred music. Don't reinvent the wheel, but other than that, pick something that works for you. Pick an IP, geolocation, user names, host names, goes on and on and on and on and on. Pick a way that you want to format something and then stick with it. At least stick with it through same incident. You can, you know, experiment and mess with stuff and see what works and what doesn't work, but don't change during an actual incident. Pick something you want to keep it through that one case and then, all right, that didn't work or that felt awkward. Let's try something else. Because going through and cleaning this up at the end is such a headache. We're not admins. If we wanted to do paperwork, we would have probably picked a different field. Doing this as you go cleaning as you go will make that final report as final ticket summaries. Almost can't promise completely painless but as as close as as close as it can be. Now, your timeline, specifically your timeline on a serial ticket, but your timeline has two main audiences so typically you're going to have two types of timelines. One is kind of yourself, because the audiences appear. It's your security manager, it's your senior analyst. This is your log data, your detailed information, CSB files, case attachments, they're going to, they want, they want the meat. Everyone else, your managers, or non technical managers, I should say, stakeholders, executives, they want the layman's terms. They want to know what happened when, but in a very general sense. So this is more of a timestamp, single line of data, what happened here, then this happened, so on and so forth, that way they can kind of get an idea of what happened, without having to figure out Microsoft, because that's never fun. All right, I've said this before, but I'm going to say it again, let the computers do the work, that's why we created them, that's why we love them. You can think of any, there's going to be an IR, an actual DFIR tool, but does the work. I'm not going to get into the whole giant list of different tools that do timeline work based on events, based on different types of logs, CSBs, all kinds of cool stuff. There's a ton out there, bug our friends if teams about them, and they'll be more than happy to give you some pointers and some recommended ones. For the incident, handling the side of things. We're going to be talking more around that previous slide layman's term timeline so you're trying to get a general sense of what's going on, as you're doing it so this is kind of for you. So you can kind of keep that timeline in your head, as you're going through and scoping, as you're going through and doing that analytics work. Hey, did this happen before this, or after this do I have the right timestamps, make sure which one happened when. Now, there's nothing wrong with plain text markdown. It works. Can't really sort filter, but it works. If that's something you want to do, it's going to be a little bit slower. But again, it just works. Excel has its place, but we all know Excel and time are, you know, friends, not really close, you know, they misinterpret each other entirely too often. But if you can get it to work, it will work for you. There's some more fancy things like Jupyter notebooks and something like me to which is kind of like an embedded Excel spreadsheet into Jupyter notebooks, super cool if you're into that kind of templating, then living off the land is what you got. If you have a central logging tool or security software that does this type of work, figure out what's there and utilize it. So things like this timeline in Microsoft Defender. I've got this cool new feature you can flag individual events, super neat, super hyped. I've been wanting for a while. Having a local instance of slug that you can just dump the relevant files in and logs as you go, and it'll just build it for you. The same thing with local version of Kibana. Arkany has really cool filtering. There's some ways to do custom tables and all kinds of fun stuff. Once you get into it, but figure out what you got and use it. All right, now it's time to take a look at what it actually looks like when we put a timeline in place based on our kill chain. All right, and here we go. Now the incident premise for kill chain one is a kickoff from a potential phishing issue. Now, we've already had our forensic team go in and pull all the information and then provide that to us. So we're actually working from a already existing technical timeline and forensic analysis already been completed. Our forensic team in party sitting has done an absolutely amazing job. And so this makes this a whole lot simpler. And that's what we're focusing on. Simplicity. Now, in my incident case template here, I'm going to the timeline outline section. And I'm actually just going to include the markdown from our forensic team of the technical timeline that's already been done. You can see here, this is what they've completed already. We see our lovely UTC. We see very clear language in terms of what I would expect to see between two teams being shared. And then we're going to keep going. We see, you know, initial access all the way through persistence, lateral movements, and even, you know, coming in and getting some password files. All right, now on the executive timeline, we're going to frame this a little bit differently. We're going to make sure we tell them upfront what time zone we're in. And Magnum Temp is financial. They are based in San Diego, so they selected Pacific time here. And we're also going to want to lay out the scope up front. It didn't happen over multiple days. It's happened over a fairly narrow time frame. I went and I converted those UTC time stamps to a readable format in terms of the use of knowing what it is in terms of context. I broke out the activity section into two, one being a little bit more of a summary of the activity, and the other one being the more details based off of that activity. Also notice that I took off, I took off most of the seconds. And that is because we didn't actually have anything fall within the exact same minute. So in ease of reading, there's no need to include the seconds. I took off most of this information because every single line of activity in terms of this timeline did happen in a different minute. If I had any duplications, I would have actually kept all of the seconds, because then you have that consistency through the timeline. But since each one happened in a different minute, we can go ahead and cut those out, make things a little bit clearer. And make sure that the format all looks pretty consistent. So all of the file paths are in quotes with a little bit of extra information at the end. And use the same summary type wording in each section. I see that there was an unknown timestamp, and I put a caveat here. I can, based on my experience, I can look at this data analysis and know when this occurred. Not 100% granted, but pretty dang close. This is where, in the timeline, I would presume this activity occurred. Right there. I make a little caveat, and I put my little notes saying, hey, I didn't have an exact timeframe, but based on my experience, this is where this was, and this is why I think so. And that is about it. Let's get back to the presentation. Right now, gone through timeline and kind of get some tips and tricks. So what good notes look like. All right. You know what your seats, it's CYA, it's making sure that you know what you know. All right. Good notes. Everybody sleeps better at night. You sleep better at night, your legal team sleeps better at night, your manager, your CISO, your C-suite. Everybody just is calmer and more chill when they know that they can open up an incident and actually understand what's going on. I'm not asking myself these questions. If I'm being grilled by me, can I answer my questions? And sometimes the answer is no, and I need to be like, okay, I'm going to take a step back. I'm going to make sure that I'm writing these notes out because I want to know the answers to these questions. Two months from now when I'm going back and looking through these, for whatever reason. And then on top of that, why are you even asking, why are you even being asked these questions? Why would this come up? And if you can figure out that root cause why, then you can incorporate that as you go, as you're building at your notes, as you're working your investigation, and it really, really helps. Now, during that investigation, typically you need to pinpoint the root cause. Sometimes that's an estimation. Sometimes that's just, hey, this is as far back as we got. This is as much information as the data allows. Then what data points are you going to actually need to do something about it? Like, are you going to talk tune? Are you going to re-scope? Hey, you know what? I searched the sender for a phishing email, and they just send this one spearfish. They sent all these spearfishes, all different kinds of URLs, all different source key addresses. All right, we're going to have to do some phishing ourselves. Cast a big net, pull out all those data points, and that's information that we will then use to re-scope the investigation as it's being worked. That's the information you're going to take and, you know, bundle up in a nice, here's some opportunity for tuning. Hey, why did this happen? What could we do to prevent it? But we can't even do that if we don't have that data. And then, finally, lessons learned. It's kind of nice as you're going through the investigation to be like, hey, you know what? I really wish we had a way that someone could just press a button and it just reports the email as phishing. Because then that first person who just deleted it would have been able to just hit that button. And then no one else would have gotten phished. It would have been amazing. Adding that out as you're going through your lesson, as you're going through the investigation, it doesn't have to be a lot. It can just be, hey, I see a user touch this email before anyone else. We could have stopped it further upstream by putting some tools in the hands of our users. That's a way to lessons learned. You don't have to go in crazy detail. It could just be a simple note to self so that when you are going back through your investigation notes, you can have that little ding of light bulb and go, yeah, let's see what that entails and actually flesh out the lessons learned and the potential solutions to help you not have to do all of this work again. Now, basic core for good notes. If they can't explain why you did a thing, you need to include it. You need your reasoning and your proof. If you purge an email, why did you do it? Hey, it's a fish. Okay, well, I closed the ticket. All right, well, why did you close the show spam not fishing. Can you tell me why tell me why you think that this is what it is. It doesn't have to be a lot to be going deep deep deep into the weeds, but it does have to have enough to that way. Again, you can answer these questions. All right, because notes are for your protection. I mentioned that this is CYA before. If something is missed or you make a mistake or your train of thought just completely misses a loop, which happens, it is perfectly normal and sock land. Someone else should be able to read through your notes and read through your tickets and go, oh, yeah, they just didn't know they weren't aware of this. So this is something lessons learned for the investigation. We'll give them that training. We'll, hey, make sure you check this next time and it won't happen again, but you're not going to get. No one's going to be upset with you. No one's going to be crankier at all. They're just going to go. Oh, hey, yeah, I see exactly what you did just next time when you get to this stage. You know, make sure you include this. That's it. So learn something. You know that I'm not going to do this again. Everybody's happy. And then bring it up audits again. If you're having to pull from memory to answer questions or go through your lovely, lovely rough saved text notes. You're not going to have them. You know, it's a shame. You're not going to have a good time. It's going to take a long time. The auditor is going to be mad fat and fat, shmad and miserable. You're going to be fat and miserable. It's just not a good time. Make sure your notes are there and thorough, so that way you're not having to stop doing instant work to go and talk to an auditor about an incident that happened six months ago. Your notes are your save button, because as you're going through the notes, especially those of us who work, you know, very weird hours or multiple shifts or people who have weird off days or that lovely 24 7365 got fun split shifts. Your notes are your save button. If you were compiling all of this locally, and you're not adding in comments to your ticket into the actual incident case. And something happens and, you know, an emergency pops up and you're going to have to go to your kid talk or anything that could possibly happen. Someone else is going to have to go and reinvent the wheel and go through from the last thing that happened that you actually notated and power through it themselves. If you are saving as you go. Sometimes they even set a timer on it. It's like, hey, every 10 minutes I need to go and write a quick blip on what's going on. Different time frames for different severity. You can get pretty fun with it. But the biggest thing is noted as it happens, because if you are, like this example says six hours and two instant response. And you are trying to remember why did I add this IP address. And it's fifth and you've been going through hundreds of them. It's not going to keep that time. You're going to have to go back and try and retrace your own steps to figure it out. And it's going to take a lot more time that you could be doing spending, not doing this. All right, now it is time for our next demo. So what we're going to see here is demo number two. This is the same kill chain. Same premise. We are just going to go through the analysis reports and cover a little bit of the details on why the decisions are made that they made and why the information is formatted the way it is. Here we are. Now we have a full workstation analysis here. Now this is what is hey I see a, I have a known indicator. I'm now going to go through this particular device with a fine tooth comb and bind anything related to that or anything that stands out as suspicious or suspect. We have a one piece of many forensic analysis. So this is one of six, I believe forensic analysis. And these all get pieced together. To be one greater analysis on the whole kill chain, including all of the persistence and multiple segues to different hosts and different user accounts. And then we have a quote, I just a blank template. This is where I put case notes. This isn't the actual analysis, but this is where I would be putting information as I'm actively running the investigation. As I'm getting asked questions, as I'm completing status updates as I'm running queries, I'm going to be putting it in some place that I know where each point is, and where it's organized and easy to access. I like to notebook because of the modularity of it, I would say, but there's tons and tons of different options out there. I think the most that you see from project obsidian is going to be a lot of Markdown. Markdown too, just in Jupyter notebook, alongside code as well. Let's go back to the analysis and here we are. So for this, where you're just going through, and this is basically a single workstation analysis, going to have the timeline events based on that one host, and then the conclusion on that host and any findings that got discovered through it. And so we see all of that in here. Oh, that's a lot. That's a whole lot. But includes things like this, like the Shiberchef recipe he used in order to code that. That's something that I grab as well. Any query, anything that you do to transform data, you want to make sure you put a record of that. Because, again, it'll be six months later, and then be like, Hey, yeah, I saw you did this. It's just like, oh, I have slept since then I do not remember. That is why we write things down. We write things down so that way, if our memories fail us, we have evidence and proof and records of what we did at that particular time. And this last analysis. This is a really good format. I like this one a whole lot. This one establishes the scope of the analysis first. So the baseline of what you're trying to do the scope of the host and user, then pulls all the other users associated with it. Timeline that we're looking at the artifact that triggered this analysis in the first place. And then, hey, yeah, what did I actually search on this I pulled the locks, I looked and the windows event logs. I went and looked at the windows system services as well. And I pulled memory forensics. So in terms of what happened here, I know all places that I checked. I know anything that I found that was related to this, as well as my initial assessment or my final assessment of what I believe that to be in relation to the creator incident. So in this particular case, this workstation six. Yeah, he got an email before that it will long to have someone else do some analysis on the email. He didn't actually open it or download it or trigger anything suspicious on his actual device. However, you did find something interesting through this process is discovered. This user has a plain text passwords dot text file. So things that pop out of you while you're going through, you know, created or recently updated files which is believe what this triggered and got this into. I have a forensic forensic analyst here, which is this this password file this is not something you want to see on somebody's buddy's desktop, especially being recently updated especially being in upper level titles this particular user is in leadership, and also isn't it leadership. And actually, there's something being, you know, very sensitive in this file is high. So this is something you want to kind of either make a note of and then come back to later, or, you know, if you have the time during the incident, you've already put out all the other fires by fires. So in take a look, just like this pull the source pull the extra information that way, when you're doing the report, this can be added on as a part of the lessons learned, or part of the points of interest or solutions recommendations provided to the client, or to the leadership. All right, and that is about that. Let's get back. Color commentary and play that play out. Are you sick of my analogies yet. I love them it's the way to translate what's happening my brain to other people. I try to use them. I love this analogy. This is one of my favorite ones. I feel like this is one of the things that sports does really well. I love lovely sports bay sports ball, go team, hit the ball score goal, things. There's usually two announcers you're watching a game on TV or you're listening to it on the radio, you're going to typically hear two voices, every game there is. There's always at least two. One of them is considered the play by play announcer. They are describing it as it happens if you are not watching the TV if you're just listening to it. You can actually follow along with them and know what's happening at any one point in time. You're just describing it as it happens, literally what what's happening. Now, your other person is our color commentary, color commentary, I can speak. All right, they're going to provide additional information around the players and actions. They're going to be doing things like hey, what is that coaching decision, what, what's the context around the actions that are actually happening. This person missed a goal, but he had an injury. All those types of things of where you're adding additional depth to the actual literal things that are happening as it happens. Now, reason why they do to because it works. It's a really effective combination where you have your facts laid out right alongside someone giving you more detail and more personal opinion, or most of the time, expert opinion color fat. And then you kind of get what you need out of it. You can be both, you know, a newcomer to the game as well as, you know, super super intense fan and understand what's happening and get as much or as little from this type of commentary as it's actually happening. It's pretty effective. And there's a reason why it's super super common. Now. Now we apply that to notes. You're going to have your color commentary and you're going to have you play by play the color commentary. Typically, you're going to want to restrict this to just your team. You're not going to want to have this visible outside of your security team or your stock team or talk department depends on what it is. You know your group best. Make sure it is a internal discussion, but it is important to have it because that color commentary is how we can talk to these different ideas and understand the depth of oh okay this is, this is the why behind this but it's kind of we're only like 80% sure so we're not going to like bring this out to the whole public, we're going to keep this internally, but it's important for especially newer members, or people who aren't doing incidents as frequently to have that extra information, because that way they can learn from everyone else's work. It's really really important. Be professional isn't color doesn't mean color in terms of, you know, colorful language, but you include your honest professional opinion. Some tools out there include gifts, all kinds of fun stuff. But the idea is that you're adding depth to the facts background interesting pieces of information. And that's on that. Then we get into play by play. I want the facts and just the facts. You're going to need a neutral tone. We do not want any extra drama. We don't want someone panicking about, you know, some intel tidbit that you included in it. This is literally, this is the order of events is the order of operations of what happened. So here we are now different types of this typically our status updates, shift reports. Pause summaries and client updates now. So you're not always going to be doing this depending on your role. These are the three most common types of external facing communication. Now, very, very, very careful that you know who sees what. Make sure we you test it. You sure you know that there's two different types of ticket quotes, one is internal one is external. Always double check before you post stuff in, because you want to make sure lines are clean, and the people who get the information are getting the exact information that they need and nothing more. Speaking of our Vulcans here. All right, out we're facing notes, no opinions on the facts. We know that something's a breach, we know that something's a compromise, we can tell that someone from Russia logged into this user account. But we have to say that in a correct or proper wording, otherwise, a good old legal team, I kind of be too pleased with you. And unless it is literally your job to make that decision and use the actual words. Just don't do it. Some prefixes got some lovely piece down below possible potential pops. These are all fun things that some of you might have seen and understand quite why someone is using this why someone's qualifying the term compromise or breach. And that's because this type of software and describes what's happening. So you understand what, what the thing is, but you're not using a word that actually has a regulatory or legal meaning, the term breach the term incident, those actually have meanings that can start SLA timers and compliance timers. And we don't want to be the one accidentally starting that timer, and having everyone else rush to go complete. In order to get it done in time so that way, the org is not facing funds or more audits, or whatever the case may be. So things like security event, authorized access. You don't use the term incident, you don't use the term breach, you don't use the term compromise not without saying possible or potential things like that. Yes, it's kind of silly. Yes, it seems silly. But if you go through it, and you get used to it, it makes everyone happy. You add an extra word in legal savvy because they can have a greater degree of control over when those timers start, and when they have to deal with regulatory agencies and legal contractual obligations. All right, now, time for our last demo. All right, last but not least, here's demo number three. We're just going to continue our look through those same analysis files. We're going to talk about it differently. We're going to explain why they frame things the way they did, and the word choices, things like that. Now, let's get back to where we were. Workstation six analysis. Now, the framing of this, like I mentioned, this is really nice, but the reason why is to be like, hey, what, what, this is what I'm trying to do. I am trying to review it and identify indicators, specifically for the compromise. And then we're going to, at first, this is a baseline, I really love this. Like, I think this is really good because you're setting your expectations up front, like, hey, when you're reading through this, this is what I am attempting to do through this document. It's very, very important. It's a reason why I got the TLDRs at the tops of things, why you have summaries, because it really helps set the tone for the rest of the document or the rest of everything that you're trying to do. Clearly, again, states the scope. And then this is a little bit of color here. See, I guess, here's this. It's important to review the users. Yes, we know that this is the user, and this is the workstation that we care about, but we are going to pull the users associated with this timeframe that we're aware of, and this particular host, and make sure that we're, you know, covering all our bases. We have a good timeline. I like the wording on this because this is very, I have to say, I have to say warm. It's a way of summarizing the event without making it a little bit too clinical, instead of being like, log on. Okay, this is what we did. Here we are. The making things into sentences really helps people picture things in their heads. And that's what we're trying to do here. For a timeline, especially a kind of a summary timeline like this one is, you want to be able to read through it and kind of have a picture of your inner head of the planet, point B to point C, and be able to have that visualization, which is really important. So like emails, hey, what not to do. These are summaries and all of this information, we have those email comms, we have those logs, and those are available to us. But this is that nice summary. Then we go through each artifact and the properties of those, usually nothing much to do in terms of color. This is facts like this is the thing. But only get into the log of you. This is when we are doing some interpretation. So hey, we walked up the windows of that long security. We see something odd. But it's not that odd and not can't link it to the rest of the kill chain. So here's the fact, and the assessment of that fact is yet it's not good. But it's not necessarily malicious and this nothing substantial makes that makes it exactly right. Yes, this is unusual enough to where I'm going to include this in my analysis, but I make sure that s. I don't see that this is related to the greater kill chain events because that's the goal right because that's what we're trying to focus on. It continues the same same thing on the systems. Hey, yeah, I'm seeing defender is running. The assessment is unlike the malware is on there. Marie forensics I went through all the memory. I didn't see anything suspicious. This miscellaneous concern. Great wording by the way. This is not necessarily a security incident itself. But this is definitely something we'd want to include in our notes, probably maybe like ask your manager like hey you know, I was going through this. I saw that Brad has a plain text passwords file on his desktop just was right there couldn't could not see it. Is this something or starting that conversation so that way, things that could be a potential risk to organization like a plain text file, or an IT manager, the director I believe, you're going to want to get that addressed, because while we enjoy investigations. We also like sleep. So, got it got a balance those got to balance those two things out. And it's all at once this is the TLBR of everything when I just went over preparations and lessons learned are not just for the organization as a whole. An individual analyst can get just as much out of those, if not more, and it will help your work quality and honestly just making less stress, and making more confident. It'll feel better overall handling tickets and handling incidents when they have it, because you'll be prepared. You'll feel like you actually somewhat know what you're doing when everything's on fire. These knees in place kind of self checklists can help you identify all the stuff you need ahead of time. So that way, you can address those gaps before they become blockers during an actual incident. UTC is best time always. Let's go UTC the best right what you do and as you think as you do it and think you want to stream a consciousness your notes and then tidy them up a little bit, put them in your ticket and smash that save button. And that's going to keep everything on nice and tight. And then if you need to actually hand off an incident, not spending an hour trying to summarize your notes or go through everything and handed off to the next person. It's already there. He was like, Oh yeah, no need just finish this last little segment and hop that in. Now, of course, be nice to your legal team and they will be nice back. I promise, they're not scary super chill people. It's an entirely different set of what's the term obligations there are obligations than what we are focused on. And if we can make them happy, they will then have our backs are back when the time comes, and it's very handy I assure you. Okay. references. I had the one for me some place in Wikipedia. And I want to thank you for listening to my recording on note taking. I'm impressed that you made it this far. Kind of a boring topic. Kind of everywhere though and I feel like it's super, super important. So I want to thank you again and if you want to join conversation or you have feedback or strong opinions. Go ahead. Let us know. Thank you again.