
like to present gramm how to train your detection dragon guys can you hear me okay yeah give me a shout from the back if you can hear me I know it's early one more time all right awesome I I cannot see anyone so that's why I'm saying shout all right well good morning everyone welcome to bsides um my talk is called how to train a detection dragon now I hope people have seen the movie right because it's a great movie movies and as a TV show I think. Um but before I begin I wanted to just thank Bides for you know having me here. It's 15 years apparently which is huge. So props to Bides you know thank
you for organizing this. Um in this talk today I I want to go through some of the things that I have learned while building out our detection response pipeline. Right. Uh you're going to expect quite a few dragons right? um some memes here and there and hopefully by the end of the day oh end of the 45 minutes you will leave with something even if it's just my face or my voice talking to you. Cool. So training the dragon is basically for everyone but I understand there's a lot of different talks out here. Um for this talk you do need a little bit of knowledge or just understanding about sec ops in general. I will go through the technical
definition but this is also something which I've been really focused on. This talk is is great for someone who wants to set up a new detection pipeline or scale their pipeline or even just you want to know what secops is all about. Right? So who am I? This dragon is actually me. Um by the way I I don't have a lab coat but I've been you know I'm a security engineer at Lime. I've been in cyber security for over seven years. Um I have some experience in sec ops prodac you know doing a little bit of everything and I do like building 0ero to1 security functions. Now what is detection response right well as this dragon is
scarily telling you it is basically identifying something detecting something that's going wrong in your environment and responding to it. According to me, I think detection response or psychops is one of the cornerstones of security because you don't know what is going wrong unless you can detect it and you don't know what you're going to do because you're going to have to respond to it. Now, detection response is easy said no one ever. Right now, this as this meme says um there's always something happening. There's always a disparity between a security team and the number of new products, new tools that are out there. There's always a little bit of friction versus security team in the
organization. Now, I don't know if any of you have solved that, but if you have, 12:00, let's meet outside, teach me everything. There's all also a really cool principle called the Goldilocks principle, uh, which we'll get to later on. And unless you're, you know, flushed with cash, which some companies are, right? You can't just throw money at the problem and solve it. Before we get into this, I do want to set some expectations, right? like what does 0 to one really mean? In this particular case, you know, we're working with a pretty functional tech stack. So, something's already built out when you're building out the detection pipeline, you're not always the first hire in the company. There's always a
tech team or something has already been built out, right? There's quite a few log sources, complex log sources. There isn't always funding for new security tools because, you know, you are the security tool essentially. You're the first one. Um there's fewer security engineers normally one which is you um or a handful and there's just quite a bit of manual processes um involved. So I want you to keep those things in mind uh before we get into this. Right? So yeah this fire breathing dragon is telling us to get to work. Now for me I think of detection as a three-headed dragon right fluffy in Harry Potter but if it was a dragon um where do I start?
How do I scale? and how do I sustain? So let's look at each of these heads and instead of slaying it, let's try to train it. So where do I start? So a couple of things which I faced right is what are the logs I need to ingest? Do I have to get all of them in? What are the alerts that I need to set up? Do I need to have 100% coverage everywhere? How do I notify me, my team, my response engineers, anyone? And do I really need to respond to everything right now? The solution to this whiteboard this is something I did not do right it's a very simple solution and a lot of you must be like what are
you talking about like this is this is not the solution it brings you to the solution right one thing which I I wish I would have done is got these four tasks and be like hey I want to whiteboard this why is whiteboarding really effective in system design there's there's lots of articles for that but in detection response it really helped me now this diagram is what I think about when I say hey what is the detection pipeline in a nutshell sources alerts or rules notification and then responding right let's take a look at detection sources now we have a lot of different ones how do you know which ones to start with what I did is a prioritization for
injection right now this is different for each company each situation but some things that I have learned are you it's not always you you need to work with the rest of your teams, right? The most important according to me are the ones which also have compliance specific impact, right? Because look, a security incident happens, something goes wrong, but you don't want it to have crossunctional impact, especially if there is some sort of compliance related to it. I've given a few examples here of socks, PCI, but there's quite a few and it just depends on what you guys are running. Right now, this will this should take most of the key systems out. So first focus on these. There's also a
small subset which would be production or business related systems which are not under the compliance scope. Now from my experience that's a very small fraction right but if there are right for example we have an internal app which does not really fall under compliance but it is very important for for production right then you work towards those. Once you're done with those fun things, then you look at, hey, the cross functional tier one systems. Then you talk to your sister teams or any other teams and be like, hey, what do you guys what are you guys worried about? We've done all of this. We have maybe 10 20 sources already ingested. What are your, you know, P1s or like
critical ones? Now, once you've done that, then you go to all other systems. And I can pretty confidently say if you've reached this point, you know, you you've you've achieved a lot already. And the fourth point is basically if you have any other systems that are not covered and you have time, bandwidth, resources, which is energy, money, and the will to survive. Um, go get those. Cool. So, now we've spoken about how to prioritize those, you know, detection sources. We we've ingested our compliance ones, our top ones. Now, you're like, "Hey, G. Okay, I have everything. I have all these logs, you know, racking up a bill. I need to get something done. Okay, let's set some
detection alerts. Now, this is where the Goldilocks principle comes in. Now, this meme, I don't know why it's a little messed up, but this is me when I was building this out every day. And I'm sweating right now as well. Do you alert on too many actions and get flooded, or do you alert on too few and be like, "Yep, we're good." And then tomorrow there's a there's an incident. The answer is not what you'd expect, right? You don't need 100% coverage to win. Now this is these are some really cool blog posts that I've read by Van Vleet. Um there's a lot of math involved. I I've tried to understand a lot of it. But essentially what I I took
this and I thought about it from my perspective. I'm like hey I don't need to have 100% visibility into everything because it's impossible to manage and handle especially if you're building out the pipeline. You probably don't have a you know huge team to respond to. So what do you do? Right? You step on eggshells, you set up anomaly detection rules, right? So you know how the standard processes for the systems that you're ingesting are. If you don't know, talk to those system owners. The easiest and the best solution that I can give you is have a conversation with the people who run those systems. Understand what they do. Right? To give you an example, we we alerted on GitHub, right?
GitHub. And some some teams were uh bypassing um branch protection rules and this was their standard process. We were like, "Hey, this is this is weird. Um is this expected?" They were like, "Yeah, no, this is what we do." Okay, cool. But this is not supposed to happen, right? So, how do you improve those processes? We will get to that at the end. I would not have been able to set up my detection pipeline if I did not work with the system owners. Now once you've understood that then you alert on the big ones right the shady malicious behavior where you can you can find those all over the internet now you'll ask me g okay the internet is big vast
and it scares me where do I find it well you're lucky for you here's a few so detection libraries by the beautiful security community out there have already been built out right these are just a few and and I do want to note it's not sponsored at all um that I have used to help me have have a base, right? A foundation to start from because it is very daunting to build out your own security just, you know, bank of alerts is insane. Um, what I did is I actually took some of these and I'm like, okay, I want to start with one of them. The one that I chose was Sigma, right? Why did I choose Sigma? I think
it's great. Like I it's so friendly for developers. You can essentially write rules, edit them, and I don't I don't know if you guys have used Sigma. Can you yell if you've used Sigma before? I can't see. You'll have to say something. Okay, cool. Awesome. Sorry, this lights in my face. Yeah. So, Sigma is amazing, right? And I can there's a whole I can I can have a whole talk about Sigma, but there's a great talk by Alex Sinnate, who was a security engineer at Wise, um, who, you know, I think contributes to Sigma as well on how to actually practically use them. I don't want to go into that right now, but if you've not
checked it out, definitely check out Sigma rules. They're really adaptable. Um, you know, you can also tune them and write your own detections, right? So, I prefer Sigma rules. And all the other ones that I said are also great to just get an understanding of what is the detection, you know, visibility or or security alerts that I need to put in. So, this is a this is a sigma rule that we have. Um, hello darkness and g is lost obviously are not the ones that we use. Um, I am lost, not gonna lie, but I did have to change it. This is a this is a sample one that we have. Um, it's really cool because you can just
add whatever details you want, even response, uh, playbook tasks, whatever it is. This is just a format of the sigma rule. Okay, cool. Now we have the sources, we have the alert bank. Now you tell me, gee, okay, now what? I don't know what to do next, right? You need to notify, you need, how do I know what is going wrong? How do I know when an alert is hit? And I just, you know, I'm lost. Fear not. The first thing I'm going to say is do not reinvent the reinvent the wheel. Use the alerting platforms that you already have. Now, in this case, we have uh email, right? I hope everyone has email here. And we have Slack. Now, why
why should you use this? If you go back to the first slide, one of the things that I said was you don't have additional tools or funding for tools, but you have email, you have Slack, you probably have some other things which are already working in your company. Why do you want to make it tougher for you and the company and and introduce a new solution to alert on, right? Use Slack if you or Teams or whatever messaging platform you have. use email and it just makes it a lot easier because in today's world we're never just on our machine, right? We're always traveling and we want to see an alert quickly just on our
phone, right? It does help. I I guarantee it now. You'll be like, "Hey, I don't want everything on email. I'll get like 10,000 emails a day." You're right. This is where you need to have some sort of notification schedule set up. What we do is we have a severity mapping. Now, this is a very very common severity table. I'm sure most of you have probably seen it. If you haven't, you know, it's it's essentially a way to sort out the alerts right now. If there's a critical security event or security alert that gets hit, we we page. So, page of duty is a great application that we use personally. You know, it's great for paging. If it's if it's an important
notification which doesn't need me to wake up in the middle of the night, it's on Slack and we we tag the person who's done it and it's a couple of really cool features. Now, medium, low, we also use Slack channels, but we're not explicitly like, hey, look at this. Look at this. We're not waking up our detection and response team. And if it's anformational, we're like, hey, we don't have the time to deal with this, unfortunately, right now. You know, we'll we'll we'll get to it. Now, now I I I can sense a lot of people will be smiling at least at this. Um, and I'm going to get to why why I'm also smiling
at this because it comes up and it's going to come up in the next time of like, okay, G, I have all these alerts set up, different priorities. I'm I'm done. I'm set. How do I respond? Now, you set up all this notification schedule. Oops, sorry. You set up all this notification schedule. You have to respond in that way. Now, response playbooks are very important. Now, I don't want to go into how to build a response playbook and and all that fun stuff in this talk because we're talking about the detection dragon. The response dragon is is very very large, right? So, we'll deal with that another time. But essentially, it's very varied, right? It's it what we use
is like, hey, if there's something really important happening which we need all hands on deck, we'll have a data dog incident. We use data dog for incidents. Otherwise, it's it's this man on the left here, which is myself, saying, "Dude, we need to fix this ASAP." Right? That does happen. And I'm and I'm and I'm and I'm not ashamed to say sometimes you do just need to DM someone and fix it. Especially if you're at this stage where you've not properly built out your pipeline, right? If you remember the previous chart about notification schedules, you also need a response schedule. Right? Now, if it's a critical alert, you need to drop everything, right? If it's an
informational, honestly, response may not be necessary, but it really depends on how you classify informational, high, medium, low, etc. What we do is, hey, if it's a high, you know, you're tagged already, but you don't have to drop everything and look at it, but you need to look at it straight away. If it's a medium, you know, every morning, spend a couple of, you know, maybe an hour, maybe two hours just taking a look at it. If it's a low, maybe at the end of the week or start of the week, right? Um I would say start of the week because the weekend will have given you quite a few alerts to look at. So maybe Monday
morning uh do that and if it's an informational as I said it really depends a response may not be necessary. Now you you you'll tell me hey okay you've told me all these things but you're not giving me anything. You know what are you going to give me now? I'll give you some gifts. There are quite a few response libraries also right now. Naming a few of these, I've used AWS one for a few of these things. Tines has an automation library, but it really helps to understand kind of how other people are doing it. Um, and honestly, you just have to Google sometimes, right? How do you respond to something? I know it's gotten a lot
easier with with you know Gen AI to help you which really helps us in this case because you don't really always need to build a response strategy. One thing I will note though here is do not just lift straight away. Lift it from these templates which are free. Um but also make sure you you actually carefully think about hey does this really apply? Right? One of the things that I did my mistake was I lifted a response template straight away. Then I realized, okay, my team does not really really look at emails coming in from a particular account. They don't need to because they get a thousand every day. So what I did, I'm like, okay, I'm going to put those
and change that response strategy and move it to Slack because we really look at Slack, right? And it really helped me. So take these strategies but contextualize them to your business to your environment and kind of what works for you and your team. Right? Now the easiest way for me is just to add those response steps to the sigma rule. Right now this is if you look at the end here uh um the the response playbook task. I don't know if I have a laser but um this is basically like hey how do I triage and respond to this right? Um it's easy. Now in the sigma rule, everything you need for each and every detection uh alert, you can
have add a custom tag and just put it right there. You can also do it in your SIM, you can do it in your documentation, whichever works for you, you can add it there, right? What I think is good if you're using Sigma rules is like, hey, you have it right there. So even if you look at the detection alert that gets hit, you can just reference what are the exact steps you need to do here. Right? So this is the detection pipeline in a nutshell. And I've given a couple of examples of like hey you know some logs which are important which kind of come under that scope detection alerts of hey maybe suspicious activity things
like that notification schedules and response. So this is basically how you build a detection pipeline. It is it is easyish but it's not like once you start getting into this when I started I did not know you know how to get my head up. I started building straight away. What helped me now is when I can go back and I'm like, "Hey, what I should have done is I should have whiteboarded this. I should have literally drawn on a piece of paper or a whiteboard if you have it or on a virtual whiteboard. What are all these four phases and how can I tackle them?" Why am I saying this? I'm saying this because one of the problems that I
had is the pipeline that I built up essentially broke during the response side. I'm like, "Okay, I've already set this up. I've set up the alerts. Everything's going this way, but my team's not able to respond." Now what I had to do is then I had to scale, right? So how do I scale it? How do I remove these false positives? Because I'm getting a thousand alerts every day and I I I want to sleep. I want to have a relatively normal functioning life. How do I prioritize these alerts that come that way? Because I'm not going to see each and every one, right? And am I expected to be awake all the time? Let's add some log enrichment. A
log enrichment essentially just means adding some details so that we can properly contextualize and prioritize what we're looking at. Cool. So, let's add some context. Now, this is a very relevant meme um that happens to me all the time, right? Except there's no breach. It's just an important alert. How do I remove these false positives? Right? You have to add a little bit of context. This is an example of what we've done when it comes to GitHub, right? We just added a little bit of context about the repository. Now, this repository, hey, we're like, hey, are these repositories really important? Now, in this case, some are, some are not. I don't want to be woken up in the middle of the night
if the repository that we're talking about or the asset that we're talking about is not business critical. The reason is I just don't have time, right? And a lot of the things that you will realize as you build this out and scale it, you don't have time to respond to every alert straight away. You'll get back to it, right? So this is a kind of rough diagram we've done about, hey, look, an alert comes in, you just check if the repository A exists. Is there a level of importance to this repository? If there is, then triage it in the way it's supposed to be or even escalate it. If it's not, maybe we deescalate for now
and go back when you have some bandwidth. Now we've contextualized it. We've add some a little bit of detail here. How do you prioritize these alerts? Like G, okay, you've added context. There's still maybe not a thousand, there's still 500. You have to add some logic here, right? What we've done is we've added exceptions. Now, in this case, hello darkness is a Google admin, right? The Google admin is supposed to assign a role, right? If you look at this event name, supposed to assign a role. This is an intentional action, right? The business decides that Hello Darkness and GE is lost are individuals who require this particular task. Now, I'm not saying this action is not weird,
right? It is weird if they don't do it. Now, I know there's a whole train of thought of like, hey, what about insider risk? What about if they're really, you know, if they're actually just being bad levers, right? My thought about that is look, this is where the probability comes into it, right? Do you want to have false positives every single day about these people doing this? If so, okay, don't put the exceptions there. Right? But this is a conversation and this is a decision that you yourself cannot make. Now, going back to the first point, you need to have this conversation with the teams who who are doing this, right? One of the things that we saw was, you know, a
team who was administering Google, they were using their accounts for a couple of administrative actions. We we saw the problem there. We were like, "Hey, um I can add an exception, but that's really not going to help us because we're going to silence that alert, right?" What we suggested were like, "Hey, can we use service accounts in this case? Can we can we try to find another way to identify or you know add some more priority in this saying, hey, if you're doing it from location XYZ where you're supposed to be, you're living there, cool. But what if someone's taken over their account, right? What if there's anything which is a little bit anomalous, right? The decision we took
was, hey, okay, until we can figure out a way to move everything to service accounts, right? Maybe we put a little bit of complexity on, okay, if if Hello Darkness is doing it from from San Francisco, there's a high possibility that this is this is this person's house. Now, again, I want to preface this by saying this is not the solution every single time. A lot of the times you do see alerts which are kind of silenced but you definitely need to take a look at them. So I'm not saying mute the alert completely right. Instead what we've done is in the in the previous uh in the previous image and the one coming up we
have decreased the severity a little bit. What we've done is we like, okay, if it's a critical, don't wake me up in the middle of the night straight away. Send me a Slack tag me, right? When you wake up, you do see it. And sometimes this has not solved every single problem, but when you're at this level and at this scale where you're probably the first or one of two people who's responding to this, you have to prioritize and you have to give your team the benefit of doubt of saying, "Okay, this is your job. You do this for a living. I'm not going to falsely alert on this because it's going to cause you
problems and it's going to cause me problems." Now, speaking about waking up in the middle of the night, we don't want that every single time, do we? I like my sleep. Um, I'm I'm sure a lot of you do, too. So, am I expected to be awake all the time? Short answer is sometimes, right? Sometimes you do need to be woken up in the middle of the night. What you need to do is set up that automation in place to remove a little bit of active employive involvement, right, during at least low-level triage. What I've done is if anything happens, I will tag the person who's done it just just because I want some context, right? Like, hey, in this
case, Teddy volunteered to be in my screenshot. Um, I'm like, "Hey, Teddy, did you mean to do this? Can you just provide some context?" Right? Now, does this eliminate the aspect of you being asleep or awake? No. But what it does do is I'm based in London. Teddy's based in SF, right? By the time I wake up, Teddy's already given me some context about, okay, this is what I've intended to do. So then I can either escalate the alert, deescalate the alert, but I don't have to wait another 8 hours for Teddy to be awake, right? Because then essentially you're just wasting a lot of time. Another thing that it really helped us do is add quite a bit of
visibility for these detection alerts. Now, whoever is on my team, if I'm awake, right, one of my team members is actually here. Um, if I'm asleep and I'm on call and he's awake and he's not on call, he can at least see, okay, this is happening. It's a Slack channel. Teddy has provided some context. So, I'm not going to wake him up. I'm not going to page him. I'm not going to just call him and say, G, I need help right now. I'll let him sleep, right? Does it happen all the time? I don't know. He doesn't let me sleep often. But, you know, it's something we found that works. Um, the reason that it works is also the most
important p point point. You have to talk to your other teams. You have to tell them, hey, this is what your business processes are. I'm going to alert on this, but this is what my process is. I'm going to tag you. I need you to add context because let's be honest, you're making them do a little bit more. you're adding maybe three, maybe five, maybe 10 seconds for them to take a look at this uh tag that they're getting on Slack and add maybe a sentence, two sentences, something. So, you're adding to their work, right? This is where Sorry. This is where you need to talk to them and be like, "All right, guys, Teddy and Teddy's team, I'm going
to do this. This is what you need to do." Right? Does it work always? Not always, but it really helps to have a transparent conversation. So going back to what I spoke about in the first few slides, you have to talk to your teams. Now this is an example of the the contextualization that I did. You know, just wait for the user to respond yes or no and add some context what I showed you. And uh if so, oops, sorry about that. If so, you can at least relax a little bit at this scale at this time because you again, you're one of a few people. Does this always work? And should you always just go to sleep? No. So, how do you
sustain, right? How are you able to sustain? How do I properly respond to cross functional security alerts if it's sister team, sister or just someone somewhere in my company doing something? How do you add process complexity? Right? How do you make sure whatever your company is doing, you convince people that, okay, I want to add something. I want to make sure you know your task that you're doing, I'm going to add 3 seconds, 5 seconds, 10 seconds. and just proactive improvement, right? We're talking about reactive stuff, responding, reacting. How do I turn reactive improvements to proactive improvements? Because in the end, you're probably one of one of one, one of two, one of five engineers, and you need to
help your team, right? You need to help your security org just get better. So, how do I properly respond versus just reacting to the alert? The first answer is crossf functional security champions. Now this is a very debated topic in security. Do they work? Do they not work? For us, it's been just identifying security forward-minded people and just telling them, hey, if you find something in your team's purview, let us know. Right? This is a problem which is not just in detection response, but it's security overall. Right? You go to any of these rooms today, you listen to anyone, this is a topic which which transcends sec ops, um, prod everything. So build out security champions, right? Have these
people talk to their teams and be like, "Okay, security is doing this. This is now what we need to do because they already have the ear of this these teams, right? You don't have to reinvent the wheel. You don't have to keep convincing someone. You convince someone on their team and you empower them to convince the others, right? This is where you have to have back and forth. And this is how you build trust within cross functional teams. Um, have a yes and approach. Don't always say no because security is thought of as the police, right? Hey, you're not supposed to do this. Okay, instead of that, just say, "Okay, you want to do something?
Okay, add guardrail 1 2 3 4." Often times, what you will see is people will will react and respond and they'll be like, "Okay, GE and security, you're not telling me to stop doing this, which is great and I'm happy, right? You're you're you're not being a police, you're being a collaborator. So, okay, I'll listen to you because the first thing you need from them is you need them to listen to you, right? Because you have to have a conversation. When you have a conversation with these teams, that is how you improve security at your company. Now, provide solutions. Don't just say, "Oh, this is wrong." Right? The example that I gave earlier about a
team was bypassing uh branch protections. What we did is we told them, okay, maybe you don't do that. Is there anything we can do? Can we have a bot account to do some of these actions for you? We'll add a bypass rule for this particular account. Something along those lines to not just provide a problem and be a blocker, but also provide a solution for that. This was the hard one that I learned, right? Security impact is not always equal to cross teamam impact, right? And we're still solving this to this day. How are we effectively able to translate the security risk of bypassing you know branch protections? How do we do that? You have to talk in the
language and if else if all else fails escalate accordingly. Now in this case another example of the response steps just being at the end of the detection alert. Now how do I add process complexity? Right? Keep it as simple as possible for everyone else. Add the complexity for security. Right? And the easiest thing to do is add whatever complexity you want to standard processes. Make sure the employees are used to what they're going to be seeing. Slack, they're used to Slack. Don't don't have them respond on a SIM. Don't have don't create another account for them. Let them respond on Slack. Now, how do I properly respond versus React? This is a tough conversation. Sometimes reaction is
okay, right? Sometimes you don't always have to close the loop, but it's really good to close the loop. If you close the loop, you improve that culture in your company for any sort of detection tuning alerts when you're actually being, you know, proactively improving it. You can do it yourself. If you have something like a sigma rule, you can add another exception. You can you can change some of these false positives. If it's a business process gap, that's where you actually have to make a case for it, right? You have to talk to the teams with the proposed solution. Now, if you missed all of that or you were asleep, fear not. As the image says
on the right, top right, this is what you need to take a photo of. So, I'm going to give everyone 10 seconds. Take a photo of this. 10 9 8 7 6 5 4 3 2 1. Sorry, I running out of time. Not convinced about what I'm saying? Try before you buy. Right? You don't believe me about Okay, this is how you build a dete detection pipeline. Here are some free solutions. Right? Again, not sponsored at all. This is just something that you can get started for free in your own spare time before actually pinging it with your company. Um, you know, Run Reveal is a great open source sim. Uh, Tracecat is an open
source sore for automation. Sigma rules repo, as I said, there's there's a bunch of rules there. And if you want to know how to like actually categorize and respond, the mitro attack framework has helped me not just in this current role, but in my in my um, you know, past role as well. the mitro attack framework has been really really good. So again, not convinced as this dragon is trying on shoes in front of you, just try it. Right now, looking ahead, right? What do I want to do? Obviously, there's new systems coming in. There's going to be new threat vectors. I want to make sure my pipeline is scalable, right? I do want to dabble a little bit
in genai solutions. I I've seen some AI socks out there and just I want to know what they do so that can help me, right? Multi-level detection alerting is something we, you know, we're we're navigating. We're figuring out how to correlate these alerts from you know multiple different sources and actually have a good response strategy there and crossing sister teams to have detection response respon responsibilities PR changes right I want someone in my infrastructure team to write a PR and change it themselves obviously I will review it that's the beauty of having kind of PRs right like you write code I will review it if I if obviously if it doesn't make sense etc I'll go back to
it but I want it to be more decentralized because they know their systems better than I know their systems. Again, this is where the conversation goes in, right? You have to talk to them, but you need to use their experience and their guidance on how to tune your alerts. And obviously, if this excites you, you know, come, let's talk, right? We we we are always going to be a very security forward shop at Lime and and myself and my team member here. Um and maybe there's a chance for us to collaborate, right? Um contribute in different groups. There's a great uh Slack channel for detection response. Definitely if you if you want to join and you're interested, let me know. We
can have a conversation. And um yeah, if you're interested in, you know, helping out, let me know. Let's have a conversation. Here's I think the slido and feedback uh QR code if you have any questions. But um yeah, that's my talk. Um, do we want to go to Q&A right now or do I have to open up a link? All right, is there Hey, thank you, Ge. Thank you so much. Thank you everyone. So, this is the point where we do do questions. If you do have questions, it's best if you do it via Slido. So, Slido is an app, slido.com. If you go into your phone right now or any device that you have, and just simply type in
the keyword besides SF205, that will get you into Slido. I don't currently have any questions registered. We'll give people time to do that. Uh while we're doing that, I'm gonna give some announcements here. Uh launch starts promptly right at 12:00 and it goes until 1:30 and that's up on the fourth floor in City View. Um please know it does take some time to get up there. It is pretty crowded. So, uh budget yourself time. You don't want to miss out. We also have a raffle running upstairs and that is thanks to our lovely sponsors. Our sponsors here at Bides are really important to us. They sponsor us without any strings attached, which is amazing. Um, so that raffle
draw starts at 2:15 on both Saturday and Sunday. So, um, to win you must be present to draw of course. Um, that's going to happen in the lock village in City View. Uh, we have head shot all day sponsored by Opal. Head shot for your profile, LinkedIn, whatever you want to use it for. Really wonderful service that providing to us. And uh, let's go check if there's any questions in Suido. If you're really shy, I don't even want to do that. Maybe walk up to me and I'll just repeat the question. Does anyone have a Anyone want to ask a question without Slido? Just I can't see so you're going to have to yell it.
Don't be shy. No question is too silly or too small to answer. Going once. So the question is when will we get the slides available? Um that's a great question. I don't know the answer to that. Unfortunately I don't know either. I'm certain they'll be available on the I I will also say um I will post a part of these slides on my LinkedIn. Um I think that's a great idea actually. Um yeah, I'll do that. And um my LinkedIn's connected to the SCAD uh profile as well. So maybe not today or not maybe after uh RSA I'll uh remove a few of those weirdly exposing screenshots and then uh and then post that on my LinkedIn. So if you
guys want to check it out, definitely do. And please if you have any questions which you don't want to you know have here and you want to talk about it I'll be outside for a while and connect with me on LinkedIn and we can we can chat and will you also be available up in city view on the fourth floor where people generally hang out. I will I will be um my schedule I don't know if you can see my schedule on uh SC but I I do want to attend a few of these uh sessions but I'll I will be hanging out upstairs as well. Yeah. All right. Well thanks again everyone. Don't forget to
go to lunch, enter into that raffle, and we appreciate you, and we'll hope to see you at the next talk. Thank you so much.