 It provides had a great day listening to all the great talks and hopefully participating in some other workshops. Super glad to be here and thankful to be here today at Cloud Village presenting on Security Onion and using it in the cloud and making that CISO proud, right? Or if you are a CISO, learning how you can leverage Security Onion in the cloud to get better visibility over all your cloud resources and really just better visibility over your entire enterprise because we do like to kind of pitch the notion of enterprise security monitoring to include things like authentication data, cloud data, and then all the other network and host data that you might find in an enterprise. So again, my name is Wes Lambert, I'm a principal engineer at Security Onion Solutions and you can find me on Twitter at the real W Lambert and feel free to hit me up if you have any questions after this workshop, but otherwise we'll continue through and get this thing going. All right, so on the agenda, what we have today is an introduction to the cloud. This is Cloud Village, so we're going to talk a little bit about the cloud, right? We're going to give an introduction to Security Onion itself and then how it can be leveraged in the cloud to increase that visibility. And so when we talk about the cloud and kind of all of the data that it contains and where things are stored and how things happen, how data flows and communication happens between applications. Typically, these are just some examples, just kind of to get the brain flowing, but in AWS, you might have things like S3 buckets or DynamoDB. You might have Azure Blob storage or use Event Hubs for forwarding or storing data. And then in Google Cloud Platform or GCP, you might again, storage buckets, pulp buckets usually. And then there may be other mechanisms in addition to the application or a machine or an instances network traffic, the data that's going back and forth between those systems, right? So talk about all this data and all this stuff going back and forth in the cloud. And you know, a lot of times, obviously, this is why we talk about security monitoring in the cloud. This data is exploited and can be abused, right? Or the access to this data can be abused. For example, in AWS, S3 scanner is a popular one or has been in the past for looking for open S3 buckets as well as I saw another one called, I'm not sure how you pronounce it, PAKU or PAKU. It's an AWS exploitation framework, right, where maybe you're looking for those open cloud buckets or you're looking for permissions and things like that. And I'm kind of going from there and really breaking into someone's cloud infrastructure from that point. And similarly with Azure, we have microbursts. And you know, with microbursts, you can perform things like Azure services discovery, but for weak configuration and we see where some post exploitation could occur and you know, get into some other frameworks as a result of that. And GCP, GCP IAM privilege escalation, these by Rhino security labs is great for things like permissions enumeration, you know, also, you know, looking for that privest moment that GCP bucket, you know, enumerating those cloud buckets, determining what access is there and determining the best place to get a foothold and that infrastructure and pivot from there into, you know, more maybe more sensitive components or, you know, something more valuable. And we also talk about, you know, aside from getting at the data, you know, how credentials like AWS credentials, you know, these things can really pretty easily be obtained by by phishing efforts, right, by going after folks administrators, IT admins, you know, trying to get IAM account credentials or root account credentials, or trying to get those access keys, right, to basically not have to log into the environment, right, but have programmatic or have, you know, kind of a more silent method of access, right, or something a little bit easier, especially if otherwise these are accounts are locked down with MFA, you know, we can get by that. Obviously, if we have the access keys, the root access keys or things like that. Similarly, you know, creating new policy policy versions is one way in which, you know, those credentials could be used for privilege escalation. You can create new user access keys for yourself or, you know, for your friends, right, you could even add, like a malicious Lambda layer to an existing function. And if that's not well audited, you know, it would look pretty normal if you have these preexisting lambdas that you already use, and that just function normally. If you're not paying attention and tracking auditing activity, like you should be or could be, you know, those things could be pretty sneaky and get past the door. And so, you know, we have all these ways to kind of exploit or potentially exploit and abuse this data. And, you know, how do we, how do we monitor for that? Or what are some challenges with monitoring for that? You know, typically, you know, from my, you know, from my experience, kind of before the cloud was as popular, right? And still, even some folks may be not as much in the cloud. Traditionally, we use platforms that perform network security monitoring and we're able to tap that network infrastructure and get a copy of that traffic, you know, via a span port or via a tap and copy that off and be able to monitor that pretty easily. Well, there's some monitoring challenges when you come into the cloud with NSM, you know, that have to be addressed in some way, you know, shape or form. And some of those challenges are going to include things like VX line encapsulation, right? Some applications are not going to be able to decapsulate that traffic. We can record the traffic maybe in some form, but, you know, will those applications be able to handle it? Will they be able to know what is inside of this VX line tunnel that's, you know, this data that's all wrapped up in another package? Then there are things like segmentation and ephemerality, you know, services in the cloud frequently spin up and spin down. So sometimes that's difficult to monitor if certain characteristics of those instances change, you know, unique identifiers. We may lose that instance or where the instance was, what instance it was, and something happens. So that's kind of another thing that we run into when we start to monitor these things sometimes. And then in some cases, there's no native really scalable mechanism for monitoring the network. And I highlighted Azure here and I'm not trying to poke fun at Azure, but, you know, I know back in the day, they had the virtual tap preview that never really went anywhere to now. You know, hopefully that gets revived and going, you know, public soon. But, you know, for some cloud platforms, that capability is just not there. I know Azure does have some other, some partners that do this through like a set of agents and sending it through their own VX line tunnel and that sort of thing. But again, there's no native mechanism to do that. And, you know, there are many other services like that. So this is where security onion kind of comes in, right? So security onion was created by Doug Burks in 2008. Doug is my boss. He's super nice dude. Make sure to check him out on Twitter at Doug Burks. But so what Doug did, he created security onion out of a need of his own and analysts that he knew that, you know, they were trying to get a sensor platform up and running quickly. And, you know, back in the day, you were compiling all this stuff, trying to get all these dependencies right. And what Doug wanted to do was really make that into a nice little package to be able to click and deploy and go from there. And, you know, spend more time monitoring your network and less time administering it or setting up the mechanism to do so. So in doing that, security onion became this free and open platform for intrusion detection, enterprise security monitoring and log management. So we record that traffic off the network. We can also pull host telemetry and then also just perform. If you're just, you know, using it for log management, you can send different types of log data via firewall and other stuff there as well. And it can be installed from right now we have a sent us seven based ISO image and packages are also available for Ubuntu 1804 or sent us seven. So if you want to install it, install your own Ubuntu or your own sent us seven install and then install security on top of that, you can absolutely do that. And we completely support both methods. So that's a little bit about security onion itself and I'll get into some of the components of security in here. And one of those, one of those types of data that we get out security in is going to be alert data. And this is some of that, you know, that data that tells us that something is wrong here or that something could be wrong. Right. And some of the mechanisms or tools that we use to gather that alert data are going to be wazoo, which is a host based intrusion detection system, formerly known as OSEC. And so the binaries even are still called OSEC. So you may know that already, but it does things like sit, does things like sit on the host, and it can do file integrity monitoring, you know, pick up windows logs, ship those, ship application logs, other things like that. But that's going to be the host based component of that alert data that's generated and provided in security in suricata right now in security and provides that needs functionality. So those alerts that you get, you know, from IDS, that's suricata. Well, at least in this case. So if you see some network traffic or if suricata sees it and thinks it's bad based on the signatures that it has loaded, then it will generate a needs alert. And that's what you see here along with these source and destination IP addresses. And I just realized it's actually an older image that I've not updated to ship, but playbook is another way that we can alert on log data that we pull in or even network data, just events that are in Elasticsearch. We can generate Elastalert queries and then alert on that using playbook. What playbook does is take in native Sigma rules from the Sigma repo, and then we can convert those to Elastalert rules and use those for detections and alerting inside of security. Strelco is going to provide the file-based component. So if you've worked with Yara before, you know that it works with files. Strelco can also use Yara to take those files that are extracted from network streams and perform some analysis on those and also run Yara rules against those files and then generate an alert based on that. So that's super useful to be able to have that type of data out of fingertips. And speaking to some other types of data that we collect and that provide available to you in security and are going to be that of network metadata via Syracada or Zeke. Zeke, formerly known as Bro, has been a pretty popular way to policy neutral IDS way to get that network metadata and be able to stack it and really see what's going on in the network. Lots and lots of different logs there from Zeke and both Syracada. Syracada can now perform that same kind of collection. So things like DNS activity, HTTP, SMB, DC, RPC, tons and tons of protocols available for both of those. Along with the full content or a full packet capture data from Google Stenographer. We use Google Stenographer to record that data off the wire and we store that as indexed pcap. So it's a little more efficient than storing raw pcap files. So the files on disk are stored as an index or R indexed and then we go and retrieve that via our pcap application and security in it. And we can carve that pcap pretty quickly since it's indexed and we're able to refer to that. And with that pcap, we get that complete transcript or the complete goings on of whatever unencrypted traffic that we can't see. Obviously, things that are encrypted, we're not going to peer into unless you're performing some type of inspection beforehand, right? Excuse me, let me get some water. All right. So continuing from that full content data, that full packet capture, we have other supplementary data that we can feed security in it. And we recently made this a lot easier, but we can use file-based modules from Elastic and what those file-based modules allow us to do is pull in a ton of different already supported log sources or other forms of telemetry. Things like, you know, forwarded net logs, let's see, you can pull in thread data, you can pull in GCP logs, AWS, all sorts of stuff there. In addition to, I mentioned Wazoo for host data, as well as WinLog, the Elastic Windows log beat for Elastic itself, the Elastic stack. And then also OS Query. So with OS Query, you can query those hosts, like kind of like a relational database, seeing all different types of things about the host, what's going on, processes, users, all sorts of good stuff there. And we manage that with FleetDM here in security. Now, let's talk a little bit about, you know, traffic mirroring itself in the cloud and how that might occur. So with AWS, traffic mirroring kind of happens like this, right? So we have these mirror sources, which are going to be these Elastic network interfaces. And these are going to be essentially those instances, they're nitro-based instances in AWS. And what's going to happen with those is inside of a thing called a mirror session, those ENIs are going to flow through a mirror filter. And this mirror filter basically tells us, or tells AWS, what do you want to see, right? So I only want to see, you know, TNS, or I only want to see HTTP, or I want to see everything, right? And then once that filter is in place, that traffic flows through and then hits that mirror target, which is going to be our security in an instance, which is comprised of a management interface and a sniffing interface. And this right here, this mirror target is going to be that sniffing interface. So it's going to listen to all of that traffic, all that goodness, and pull that into security in it, excuse me, and make it so that we can review that data and see, you know, read out attackers and all sorts of things like that. So, you know, this is again a brief diagram of how that AWS traffic mirroring works and we'll dive into that just a little bit. So here's an example, you know, you can run security in and in the cloud. We do have a security in an Amazon machine image now that you can use so you can run it as a standalone instance or a complete distributed install in the cloud all by itself, all on Slonesome. Or you can also set up security in as a cloud node. So when I say a cloud node, I'm meaning a sensor in the cloud, right? So we essentially have, we can have a manager that's local to our, you know, maybe we have an on-prem environment or we have a manager and a search node, which is going to house most of the elastic data. And then we have a local sensor, maybe we have local traffic that we're monitoring. But we also want to have that cloud traffic brought in. We want to perform that traffic mirroring and capture that. We can absolutely do that using, you know, something like Direct Connect or OpenVPN. We can connect a tunnel up there. And then we can have that in our deployment, essentially as if it were a local node and see that data all the same. So it's super awesome to be able to do that, right? So you get the best of both worlds. You're getting, you know, the local coverage, you're getting the cloud coverage, and you're able to view that through that single pane of glass. So it's super, super useful to have that capability. Now, going into that, that VPC mirroring or that traffic mirroring and AWS a little bit more, I mentioned one of the components is that traffic mirror target, one of those components of that mirror session, right? And that traffic mirror target, again, is going to define the target interface where we want to send that traffic. Right? And in our instance, it's going to be the interface that's associated with security onion. So here's just a screenshot here of what that looks like when you go into the console. I'm going to dig into that in just a little bit here. But you can see the target settings there. You can add a tag if you want to. And then you can choose, typically it's going to be the network interface and the target of the security admin sniffing interface right there. And then another component that traffic mirror filter, which is filtering what traffic is actually going to be sent to security onion. That is here as well. So basically, you're defining those protocols and that traffic that you want to be mirrored, and then you can filter anything else out. Or you can just again, take it all and send it all to security onion. And then that traffic mirror session, again, is comprised of that source interface that, you know, that nitro instance, maybe a Linux box, maybe a Windows server, and that target interface that security and sniffing interface. And again, that mirror filter, which is filtering the traffic, whatever you're determining you want to have in there. Now, some notes on traffic mirroring with AWS. Suricada, we run these versions above these origins, but I just wanted to note that Suricada, you know, 4.1.5 and above can natively decapsulate VxLine traffic. So because it can support that, and we're recording network data off the wire, it's able to inspect that and generate alerts accordingly if it needs to. And the same with Zeke, 3.0.x and up can also natively decap VxLine. So we have that capability as well. And again, that traffic mirroring is capable only with the nitro based instances. So you cannot use just any instance or you cannot mirror traffic from just any instance. It would need to be one of those nitro based instances. So that's something you want to be aware of if, you know, you're building out your cloud infrastructure, or you're considering a reorganization, or if you have these plans to go monitor this traffic, you need to keep that in mind that it is supported only for those nitro based instances. Now let's talk a little bit about GCP, also known as Google Cloud Platform. So with GCP, we can also perform traffic mirroring, or they call it packet mirroring. And those components, it's going to be a little bit different than AWS, but the end goal is essentially the same, right? So get that traffic from one point to another. And it consists of a packet mirroring policy, which determines basically which interfaces or which instances are going to be participating in that traffic mirroring. And that traffic will be mirrored accordingly. And when that traffic gets mirrored, it has to go to a TCP UDP load balancer. And what this load balancer does is it distributes that traffic that's mirrored from those instances, and it takes it and splits it up across a collector destination. In that collector destination, it can be one instance, or it can be multiple. It can be an instance group, right, where you have these instances that spin up and each handle a certain part of the load. And that's what the purpose of this is, it's to allow you to distribute that across the nodes equally or to be able to have some priority in that if you need to. So again, it's a little bit different as far as how you do it for the packet mirroring policy. This is going to essentially take those source interfaces and that filter that I mentioned before and combine that into one. And this collector destination is going to take the place of that other mirror target that I mentioned before. And this load balancer is actually just a kind of a different concept altogether, right? You can use a load balancer in AWS. I'm just not covering that at that moment. So here is a diagram of what that might look like. Here we have a single project and a single VPC network. And this is taken straight from no documentation. So I have the link there if you want to check that out. But it is again in a single region. And you can see that this mirrored VM here is, you know, there's traffic traversing the internet and an on-frame network and some Google services. And all of this stuff right here, this subnet right here, is basically via that packet mirroring policy is going to be mirrored. And because this VM is in here, it's going to mirror that traffic. And according to the packet mirroring policy, it says it needs to go to, we're going to send it to this internal TCPDP load balancer. And then this distributes it into all of the collectors or instances we have here in the collector subnet. And this is where the security and instances sniffing interface would come into play. So something to note is that, you know, in Google Cloud or in TCP, you cannot have two interfaces in the same network on the same instance. So you would have that one interface in this network performing this function, the sniffing one. Then you would have another interface for the security and inbox in a separate network, which really would be best practice anyway, and then controlling it from there, managing it from there. So that's how that would look in coming to play there with the GCP packet mirroring. And I mentioned that here, just kind of again mentioned that in incidents in GCP, you cannot have more than one network interface that resides within the same network in VPC. So that security and management interface again should reside in its own network or VPC. Now, some ways, you know, you might spin these things out in the cloud and you might be wondering, okay, well, how can I test to make sure this is working? Make sure my packet mirroring is working, my traffic mirroring is working, as I think it is. TNNIDS is a great way to do that. It's traditionally used with, you know, you can use it on-prem or in the cloud, but it would test Siracada, it's basically for you, so you can use it. It's basically a command or a script written by Tiago Faria, super great guy. Three core second Tiago, they put out a ton of great open source tools, you should make sure to check those out on the GitHub, check them out on Twitter. But you can use TNNIDS or test my NIDS, kind of a super charged version if you've used test my IDS back in the day of that. So you can run the command and then hopefully, if all your packet mirroring is set up correctly, it will generate alerts like you see here. And we'll, we'll just do that here in just a little bit. Another tool that's really cool, really awesome to use with AWS if you're performing that traffic mirroring. And it's again another open source tool by Tiago and team is three core sec auto mirror. And what this does is it's an application, previously it was a Lambda function, but I think now it's an app, a serverless app and the app repository that you can install. And what you do is you install that and you tag your instances, you can have this come up as part of your instance creation procedure. If you want to monitor it, right? So that way, when people are rolling out your team, IT is rolling out instances, you can append this mirror true tag and what auto mirror will do, it will see that and it will create a corresponding configuration, a corresponding mirror session for that automatically. That means you don't have to go to the mirror session, go manually add all these interfaces. It knows basically, you know, based on those tags, what to add to the mirror session that you have. And if you need to, you know, configure a new mirror session, if you've hit the limit for mirror sessions. And that's another thing entirely, there are some considerations there that you want to look at, make sure to review AWS documentation on the limitations for mirror sessions, but I digress. So we'll continue from there, but be sure to check out team needs and auto mirror, because they are again very useful tools to have in your toolkit. All right. So kind of poured through that, I wanted to get to the lab, you know, in somewhat decent time. So give me just a second here, and we'll get started with that. Hopefully, you guys have the prerequisites in place and AWS accounts and don't necessarily need the access key for this workshop, since I'm not sure if we're going to be performing that just yet or not, but you will need an AWS account. And you will need to sign up for the security onion AMI. If you want to do that, you don't necessarily have to. In the documentation, if you look at the prerequisites guide there, you can absolutely set up any Ubuntu 1804 or CentOS 7 install and then secure install security onion on top of that, if you're comfortable with that. But for the simplicity of the lab and everything and getting everything going quickly, we are going to use the AMI. So yeah, just feel free. Let me know if you have any questions about that. But I will spin that up here in just a second. We get more drink. All right. So this lab, let's see. Any questions? Comments? All right, cool. Okay, so wrong way. All right. So if we're going through here, again, this is if the link should be provided already, but this is the instructions here. If we want to get set up with AWS. And then if you scroll down to follow along with the step by step, we have instructions here and then sorry, I was just making sure I was still sharing there. We have some other stuff here that will follow through it in just a little bit. But I'm going to have this opened up on my side. So let me make sure I get that. Okay, got that ready to roll. And now I am in. Anyway, that's right now. So let me go ahead and delete this. This is just an old VPC. I don't need this thing. Get out of here. All right. So if you're starting from the VPC dashboards, we're going to start and create our VPC. And we'll go through the wizard here. Actually, let me go back. Sorry. Let me go back. You don't want to start here. It's a little bit easier if you actually launch the VPC wizard. And we're going to do for simplicity sake for this demo, we're going to launch with a single public subnet. All right, and I'll give you guys a second there. And what we're going to do here is specify our our cider for the for the public subnet. And actually that's what you actually need to do this. But this, okay. All right. And then what we'll do from there is we'll just go ahead and create the VPC. Let's take a minute here. Okay. It's been successfully created there. Then we'll take a look at that. We see it in here. Our VPC, just some basic details here. So now let's just go over to security groups. And I actually have this modified if I remember correctly. Ready? Let me see. Oh, no, that's right. Billy did VPC. All right. So what we'll do here is we're going to add exceptions for SSH and HTTPS for your IP address there. I'm just going to add it for range here. I'm going to edit the default security group, edit inbound rules. And I'm just going to delete this default when it hits here and add SSH. And I'm just going to do custom. Okay. And you'll be adding yours here. You will not be adding this range. And you really can just click my IP there to use your own range here. Oops. Can't type. All right. So that's, we'll also add another rule for HTTP. Let's see. There is, I'm sorry, HTTPS, not HTTP. Am I doing? There we go. All righty. And I'll just do the same thing here. All righty. Let's save those rules. All right. So now we're just modifying again so we can have that SSH and web access from externally, from our own machine. And what I'm going to do here, I'm going to go over to the ET2 instances and spin up a security inbox. All right. So I've got zero instances running here. And I will click launch instances. And again, all of this is in this documentation. And this will be recorded. So you should be able to refer back to this if you feel going a little too fast. All right. And you'll search security and you'll see three results in the AWS marketplace. We're going to choose security and into here. All right. And you can review the pricing details if you wish. We charge it's 15 cents an hour, but it's 30 days, first 30 days are free. Please make sure to delete your VMs after this so you're not charged unnecessarily. But again, it is 30 days free for that image. And again, feel free if you want to spin up your own Ubuntu or CentOS image. You're more than welcome to do that. From my purposes, I'm going to choose the ET2 to Xlarge. You should be able to choose that one, or you can choose the Xlarge if you wish. Both of them should work. Just add a little extra horsepower there for this demo. So I'm going to go to configure instance details. And most of these defaults should be good since we only have one public subnet here. But otherwise, let's see, we'll scroll down to network interfaces. Since we have everything else here in place, and we're going to add a network interface. And we'll just leave it like that. It's going to go with that, just like that. And then from there, what we're going to do is we're going to click add storage. And I believe with this image, it does require that you specify a throughput value. You can specify as little as 200 megabytes per second, or I'm just going to specify 1,000 here. It's completely up to you. I will say that the installer prefers that you use 200 gigs, but you can certainly get by using 100 gigs with this. I'm just going to use 200 for the time being, but you should be fine just using 100 if you choose to do so. I'm just going to click add tags. I guess I can't choose that many. Okay, so we'll go there. I'm not going to add any tags here. I'll just continue without adding the tag there. I'm going to configure the security group. And then I'm going to select that existing security group for that instance. I'm going to select default because again, I want to be able to reset via SSH and HTTPS. So that's what we're going to do here. I'm going to review and launch that instance. And it's going to pull up the summary here. I don't have to click launch once again. And now it's going to prompt me for a key pair to use with this. Now, what you'll want to do is if you don't already have an existing key pair, is you'll want to create one and then download that key pair. And then from there, you can perform that SSH access that we'll get into in just a minute. But I'm going to choose an existing key pair for mine. I've got this security and demo CV right here. And this is one that I created before and I'm just going to use it again. And this is what tells the instance what key pair to use. So please make sure you use the appropriate one that you're intending to SSH with. So I'll choose that and I'll acknowledge that if I don't use the right key pair or if I don't have that, I won't be able to access the instance at least in a traditional fashion. We'll click launch instances. So it's launching that instance right now. We can view the launch log or we can go look at the instance itself. So it shows that it's running and we can scroll down to the bottom of the pane. And if we click on the instance and click on where is it? Networking, let's see, view instances, let the security instance go down to the bottom. Okay. Okay, where is the interface? There we go. All right. So the interface that we're going to look at here, the primary network interface, what we're going to do here is we're going to actually assign an elastic IP to this. And so you can see here, if you click there, if you go to actions, manage IP address for the interface. And then we must allocate an elastic IP address and associate it. Okay. So we're going to allocate an IP and actually have some here already, but so you can go there, right? In the documentation there, if you need to refer to that and then click allocate elastic IP address, we're going to use Amazon's pull of IP addresses, right? Allocate. And then I'm going to go back here and hit cancel. I'm going to click manage IP addresses again. Whoops, I did it. Okay. And allocate. Whoops. I guess I should have done that already. Okay. Whoop my bad. Okay. Wait, let me do that. Whoops. Sorry, wrong one. I'm going back and forth. Okay. So we need to actually get actions and associate elastic IP address. I'm sorry. And we'll choose this instance. Choose that and then associate that. Let's see. Okay. I think I have that already associated with something. All right. Let me go back. Just close this. Good. Two network interfaces. Okay. Okay. So you need to go to one that's not allocated. I've already had some of these available before. So you just need to use one that's not allocated. Okay. There we go. All right. So now my public IP address is going to be 3.13.20. 208. Okay. And now, so if we go down, we should be able to SSH to that box now. So if I go over here, choose that. It's not the right one. We go back and copy that IP address. Oops. Okay. We'll copy that. And now I've already copied that security Indian PEM file. So if I look here, you can see that. And one thing that you'll need to do is, you'll need to do a CH mod or 100 on that file more than likely when you first start using it because the permissions will be too open. So make sure you do that before you try to use it. But otherwise we'll do an SSH-I and we'll specify the PEM file. And the default user for that onion user will be, I mean, I'm sorry. Here we go. See if I can go back and get that. Come on now. Oh my goodness. There we go. Just making sure it's in my copy paste buffer. Okay. Now I'll take that off. I knew it could be so hard to SSH. All right. So yes. And now what will happen? It'll pop us into setup here in our security in an instance. And we're going to go ahead and run through this. So we'll say we would like to continue. Yes. We would like to continue. And we'll choose a standalone node. And all of this, it's fairly straightforward. So again, if you feel like I'm moving kind of fast, feel free. If you feel like it's moving a little too fast, it will be recorded again. Okay. It's going to call this box security onion AWS and I'm going to map a host file entry after this. Okay. We're going to assume all this other stuff like DNS, H, you know, everything else is already set up. We'll just select yes here. And because we use DHCP in here, we're just going to let Amazon handle all of that. And we're going to specify ETH0 as our management interface. And then setup is going to go through and it's going to initialize some networking components there. We're going to choose the direct option here hit enter. All right. So it's going to check a couple of things real quick and then it's going to go back to the rest of setup. Let's use our monitor interface. This is that sniffing interface here that we'll be using to sniff that network traffic. And we'll pretty much tab through most of these. And so some of these I'm going to disable for the time just because we're not going to be using these, but these are some other components that we run. So I mentioned some of these already, but the hive is another component that we run with security. And that is available for escalating cases and doing that kind of thing. A super powerful tool if you haven't heard about it or checked it out already. But I'm going to actually I'm just going to keep wazoo but I'll do the rest right here. Okay. And I'll select yes for the default Docker range. And you can specify anything here for the username. I'm just going to be user test out local. And I'm going to enter in a password. And for this, this web access portion, this is pretty important. You want to choose other here because this is how it how the web application knows to refer to itself and other components. So we'll need to be able to point it to a DNS name or something that we have mapped a name like security in the AWS. Because otherwise the external IP and the internal IP there can be some confusion there. So we'll do security in AWS for now. And we'll specify a password for the SO remote user. And this is really only used if you use a distributed deployment, but it's there in case you extend yourself your deployment to one. So that's available to you. It's going to tab through a number of these. And now we get to the SO allow component. And what SO allow does is it opens up some ports on a local host space firewall for you to be able to access components of security onion. And what we want to do here is because I'm letting Amazon handle the firewall here, I'm actually not going to go against best prices here. And for simplicity sake and demo, God's sake, I'm going to do quad zero here and hit okay. And then it's going to hit yes. And then it's going to go through setup. It's going to take a little bit. So we're going to continue on some other things as it goes through setup. And, you know, we'll continue from there and continue on with the workshop as that's going in the background. So let me get back over here into AWS and catch up on these notes here. Okay. All right. So once setup is running, we're going to go back to the instances tab that we have here. All right. We can see our one security onion instance. And we're going to add another instance. I think maybe just an Amazon Linux instance. And then we'll go with because now T3, I believe, if we go to the AWS supported Nitro, let's see if true instances. Let's see Nitro system. Okay. So again, I mentioned this here, all the instances based on the Nitro system. So we'll start with the lowest of those AT3. And we'll go over here and launch our instance with AT3 micro, the pretty much the smallest that we need here. We'll configure those instance details. All right. And it'll be pretty straightforward here. We're just going to set up some basic things here. Allow the auto assignment of a public IP address. And it's being able to auto assign now because we only have one interface here. So that's what we're going to do. We're going to click add storage and then click just make it. You don't really need to add storage here. I'm going to do 20 for fun. I'm going to click configure security group. And again, all this is inside of that documentation. And I'm going to select an existing group. I'm sorry. Now I'm going to create a new security group. And what we're going to call this is security onion sniffing group. Right. And this will be the group that the network interface belongs to. That's and we want to be able to route all internal traffic to security and be able to monitor all that traffic. So what we'll do is add an invalid rule here. And we're going to specify it for all traffic here. All right. And then the custom source here, what we're going to use is that IP range that we use for our subnet. So if I go back here and I go to the subnet here, let me check the go back to instances, check the internal IP on this. Yes. Okay. So I may have transposed it and the documentation, but it will be either in your case 100.0 or 0.100. Okay. So in my case, 10.0.100. Right. So I want to do that here. It's not 0.100. 0 at 24. Right. Or what was it? Yep. Okay. And then what we'll do there is for the outbound rules, we'll also specify a rule there. But what we're going to do is that rule, oops, actually, hold on. Let me make sure. You know what? Okay. Let me get out of this. I'm sorry. Probably confusing people. I'm just going to review and launch this instance with the default security ending group or the default security group. And then we'll go back to the instances dashboard here. So if we go back here to do it. Oh, I didn't actually want to say instance. I'm sorry. Okay. I'm going to choose the same key pair here. Under choosing existing key pair, I'm going to choose the security ending demo CV, the launch instances. Okay. And if we flip back over to our instances, we should then see that running. Okay. So now what we're going to do is under the EC2 security groups, we're going to create that security for security onion Smithing group, right? Okay. We're going to add a rule for all traffic here. And we're going to use so that 10 dot, I'll just do the 10 dot here just to be good. You would do the corresponding submit here. All right. So all traffic here. I'm sorry. That's not 24. All right. Cool. All right. So we'll do that there. And then we'll just click create security group right here. So this is allowing all traffic essentially to go across these internal traffic. You would tighten this down a little bit in your environment. Obviously, if you're going to do this in a traditional case, but in the specified description, security onion Smithing right here. We'll create that security group. All right. And now what we'll do is we're going to select the security and an instance right here. So we get back to instances and we look at the security and an instance here. We get a networking. We'll see these two network interfaces right here. And where he is. Let's see where it says like he's one. See if I can bring this up a little bit. It's a little easier to review. So right now we see the primary network interface. And then we see the secondary interface. We want to select that secondary interface. And then we'll take that interface and we will change the security group on that. So we'll change that to the security and sniffing group. Because that's what we want it to be able to do. We want it to be able to get traffic from the other the, I'm sorry, the other note, right, the Linux instance that we launched there. Okay. So we'll close out of that. And we'll just do this right here. And we'll go back. We'll be the instances trying to consolidate tabs here. All right. So now we've got both instances running. We've associated the security onion sniffing interface to the sniffing group. And we need to do the same thing with the interface for the other instance. Right. So click on that. Let's see. All right. And we'll click. Let's see. All right. So we did the one for each one. Oh, I'm sorry. Let me go back to the mirror session. Okay. So far what we've done is we've created these two instances, this Linux instance here, I'm sorry, there's a Linux instance here and this security and instance right here. And we have those two, you know, those interfaces, the one with the security and an instance in that sniffing group. And then we also have from the, the two three micro in the regular group here. So we want to be able to access that from the internet. Right. And so all those security groups and everything are good to go. Now we're going to go configure the VPC mirror. And let's check on that instance. Okay. So security and install go on the install there. And on the VPC dashboard under traffic mirroring, what we're going to do is we're going to go to create a traffic mirror filter and actually have one created here already. But what we can go do is click create traffic mirror filter. Right. And then we would specify in here for all protocols. So we would add an inbound rule and an outbound rule for all protocols here. All protocols. All right. And then for the source and destination sider. So just like that. And then you would create that there. All right. So because I already had that here, I can go and that's not what I want. I'm going to show me. I guess I can't do that. All right. Well, so I've got that anyway in there. So I'm going to use that mirror filter. And then what we're going to do here is we're going to create a mirror target. Right. And so for the mirror target, we're going to create a traffic mirror target here. And we're going to call it security. We're going to call it mirror target. And you can add a description if you want to. You don't necessarily have to. We're going to choose network interface. And then we're going to choose that primary interface. I'm sorry. The secondary interface of a security and an instance. And that's going to be the only one here that is not a primary network interface. So we'll select that there. All right. And we'll click create. All right. So security and a mirror target is the one that we're going to use here. And in your case, it would be SIDMA mirror target when it's, I already have created there. But I just wanted to get through the process here again. All right. So we created that. And now what we're going to do is create the mirror session. And we'll click create traffic mirror session here. All right. And I'm just going to call it, you can call it SIDMA demo mirror session. I'm going to call it security and mirror session. All right. And what we're going to do here is we're going to do the mirror source is going to be that network interface of that instance there. That's Linux instance. So if we go back and see if I can actually go back to the instances here, go back and look. We see this T3 micro here. I'm just going to label these to make these a little easier. Linux and security. All right. So we can see, we click on this Linux instance here. We can get the ID for the network interface by clicking networking and going down and grabbing that. Right. If we would just want to grab that and copy and paste that or just make note of that one. And I'm just going to enter that here just to make sure that I got the right interface. And then we're going to point it to that mirror target. Okay. So again, that mirror source is going to be that Linux instances primary network card. And the mirror target is going to be that security and sniffing interface. And we have to specify something here for the session number. You can just put one for priority. And then everything else, you can really just leave blank unless you wish to populate that. Oops. I'm sorry. Now you have to specify the filter. Yeah. So you actually have to specify the mirror filter that's going to be applied to this session here and create. All right. So now we've got that mirror session created. We have the mirror target, the mirror filter, the mirror source all inside of that mirror session. Okay. And so what we'll do here is just go to my notes here. All right. We created that. Now let's flip back over to security and it's verifying setup right now. But while it's doing that, what we can do is open a new tab. And I'm just going to go to my host where I am SSHing to all these boxes. And I'm going to log on there real quick. All right. So here I am. I'm just going to do this. I'm going to prep my command to log in to the Linux box. And again, we're going to specify our key file or pin file here. And this will be a little bit different if you're using Windows or something else. You may not be able to use a pin file directly. You may have to convert it with putty. And if you did look at those prerequisites, the instructions were there to do that as well. Okay. So I'm going to grab the public IP address and go back to the instances in the EC2 dashboard. All right. I'm going to grab the IP for the Linux instance. And did I not choose? I guess I did not choose auto assign because I am dumb. Okay. So I'm going to allocate an IP address for this. So let me go and do that. But if you had chosen according to the directions followed the directions like you should, like I did not, then you should not need to do this. But I'll go to the network interface for this instance and allocate the IP, the ADD, the ADD associates. All right. Are we in business or what? Okay. Now I will take this and we'll move on. So over here again at the terminal, the Amazon Linux, the default user is EC2 user for Linux. I'm sorry for Amazon Linux and we'll paste in that IP address. Our host there and just select yes. We logged in and we're in our Amazon Linux now, an instance now. And let's flip back. Prepping that up. Okay. So our standalone install finished. Hopefully yours finished. Hey, Lux. Yep. Would you be able to increase the font size on the terminal? Oh, yeah. Yeah. Sorry. I did that on the other one. I just forgot to do that on this one. Yeah. Absolutely. Perfect. Let me do that. Sorry. I know it's probably tiny. There we go. Is that better? Yep. Thanks. Cool. All right. So finish that. We're going to let that reboot for a minute. Okay. But we're going to go back over here. And so this tool that I mentioned before, CTM NIDS. So we go over here to the GitHub repo. It's github.com. And the link again is in the slides. And I guess you don't have the slides, but if you go github.com and slash zero XTF slash testmynids.org, you can get that there. And I will paste that actually into here. I'll make it easier. Okay. So that's there. And what we'll do here is copy this command and I'll actually paste this in here as well. Oh, that didn't do too well with me. There. All right. So you can copy and paste that into the terminal. All right. And so we got TN NIDS. All right. So we've got that ready to roll. I'm not going to fire it off just yet. I want to wait for that security in an instance to come up, but once that's up and running, we can fire that off and then test and make sure that Z can surcata and everything else are looking good for security. Let's see. SSH back in. Yeah. So you may get this too because it changes the host key. So you might just have to run the SSH key gen dash F to remove that from the main host file. So it's not associated with that anymore. And just go back and SSH into it after doing that. So SSH into there and just run an SO status and because it's going to take a minute here for everything to start up. So I'll give that a minute there, but I will, I guess I'll pause for just a moment and see if there are any questions. Not any questions as of 10 minutes ago, approximately, but I will give the chance now. Okay. Just for a minute or two as we wait, and I'll get a sip of water. And again, so this is all orchestrated by salt and what it's doing, it's applying different states and starting these services right now. And we'll see that status change as they come up. Again, you can see some of them changing already. Okay. Okay. And once we have the engine X and sock up, we'll try to hit that web interface. So I guess in the time being while it waits, if you don't have DNS resolution or anything like that, you will want to add the IP address of the IP address of the security and inbox exit out of here to that host file as security and AWS. And I'll give an example here. Okay. So I'm just editing my local host file. And I've got quite a few in here, as you can see, because I'm crazy and organized. So put that there in our host file so that we can resolve that. And so everything will be kosher whenever you're going to try to access the web interface. And we've already run so allow or SO dash allow the member to allow that web access from the host base firewall perspective. And we should be allowed from the Amazon firewall perspective based on the IP address that you've given and the range that I've given. So let me SSH back in, see where those services are. Again, it can take a few minutes. Looks like sock is up. So what we'll do here is actually pivot back over to the web. And yes. All right. Looks good. It's returning. So it means the firewall, fire breaks working. And we'll click advanced. And you may need to do some mumbo jumbo here with your browser, depending. I'll just log in with those creds that I specified during setup. In my case, that was user at test.local. And if you've specified the same, you can use those credentials here. Now we're logged in to the security and interface. This is called sock. And it's the main interface of security and insecurity and two, or really the next generation of security. And you can see here, we've got a lot of different things here on the side. We've got things like alerts, a place where we can hunt, a place where we can pull pcap. We see an alert on grid. This is probably, this is a known, known little bugger at the moment. But so we can just ignore that for now. But this downloads right here is where we can download any clients, things like that. But for the time being, I'm just going to just kind of go back to this overview. And then we're going to pivot back over and try to generate some traffic with TNNIDS and see if that's witnessed by security in it. So let's make sure that everything is up. We got any scragglers? No, scragglers? All right, everything looks good. We're all green, ready for a go. So we're going to run test 11. We're going to cause some chaos. I mean, not really going to cause any chaos, but this is what it's called. And what it does is essentially runs all of these tests that you see here, right? So one to 10, we'll do that. And actually before we do that, from a network perspective, let's see this. So let's perform a TCP dump on the interface. So in our case, it should be easy one for the sniffing interface. And we want to specify the IP address, the local IP address, our internal IP, so IPA here. I'm just going to grab the IP address of this instance right here. It's Linux instance. And paste that in here. All right, I'm going to type O2 to speed on that. Oh, host, sorry. Okay, yeah, you need host. I'm being silly. So you need a host there. And then if we go back here, run the TMNIDS command, let's see if we see anything. I'm going to give you a little bit there. And it may not necessarily be that we're looking for it may have been the external IP. All right, let's see if we go into NSNZ. And if we configured the traffic mirroring correctly. And I don't think I have. Let's see. Let me go back. So now if you've configured it correctly, you should be seeing that traffic. But what we're going to do here is double check our mirror config. Okay, so if we go back here, we're going to look at this interface here. The, where is it? Two. All right, and let's go to the Linux interface and make sure that it's part of that security group. Going to go to the instances, networking, network interfaces. Okay, and we're going to change security groups. Okay, so it looks like maybe we did not add this to the correct security group after all. So let me do that. Didn't I just change it? Oh, I need to remove it. Okay. That's cute. I can't read. Okay, so now if we go back, and this is, you will run into this more than likely that you did not add it to the correct security group and things of that nature. So to confirm, we will, we'll look at those interfaces again. And I'm actually going to look here because it's a little bit easier. And yes, we confirmed that that's in there. Okay, so now we go back here and we'll get a little stuff there. There we go. Sweat from the brow. Good. All right, so we now see some traffic. All right, it's coming across. It's being, it's hitting that security in an interface, that sniffing interface, being mirrored from that other Amazon Linux instance. And, you know, when you start doing this at scale, you can see how something like AutoMirror would be very helpful. So you're not going in here and manually adding stuff and then making mistakes, potentially, and that kind of thing. So I would definitely take a look at AutoMirror if you're using AWS. So make sure you check that out. And you will also see some cool stuff at the near the end of the presentation that you can leverage with that. Okay, so now let me get out of here. All right, look at that. All right, we've got some more logs. Okay, much better. We've got connection records. We've got files, one across DNS, HTTP, lots and lots of good stuff here. And if we go over, it may take a minute or two before we're able to view it in security in it. But now if we go to alerts, we can actually see alerts, you know, generated from that network traffic in the cloud, from that VX line encapsulated traffic, we're able to peer through that tunnel and see that traffic, you know, see what's going on. So it's really super powerful to be able to do that. And if we want to drill down, we can drill down into a single event and look at some other details. I'm not going to go into that a whole lot, but you know, just really trying to give you an idea of how you might be able to leverage this, right? So if I go from this alert, and I pivot on the community ID, which is basically a hash of, you know, the network source destination IP port, you know, source port, destination port and protocol, then if I actually hunt for this value, I can do this in security. And it's going to give me all of the records that were associated with this. So I can see there was a surcard alert that we just saw. I can see there was some Zeke traffic, a connection record, and then also some Zeke HTTP traffic. And, you know, if I wanted to pivot the peak app, maybe I'll look at the con record and see, you know, I can review those various details. Then if I want to go look at the peak app, I can go pull that right there. And this is in the cloud, right? That's amazing. We're looking at this traffic, we're performing that VX line encapsulation and behind the scenes, we're having to do kind of some crazy stuff tying back Zeke parents and child connection relationships in the tunnels and everything. But it's awesome that you're able to see the full transcript, you know, in the cloud with this kind of traffic in AWS. So it really shows you, you know, the power that you can have in your investigations and how you can leverage these tools, right? So again, that's just one of the ways that you can monitor that traffic and perform that traffic mirroring with that Linux host. Okay, so if we go back, let's see, move back to the slides here, and I'll break for just a minute, we're going to go over to cloud logs here. I'm going to play that from the start. Oh, no, draw on. Cloud logs. All right, let me play from the current slide. All right, and grab a sip of water. And actually, let me get back and check. Are there any questions? Any questions? Okay. Oh, well, keep doing that. Miserie is my companion. Okay, cloud logs. Okay. So let's talk about cloud logs and one of those being Azure data. I mentioned Azure briefly and, you know, kind of the difficulty without a kind of licensed partnered solution in Azure for that network recording and network metadata and things like that. But there are lots and lots of logs in Azure that you can tie in and that you can bring in through things like event hubs, and then pull in the security and it's pulled in using those faulty modules. Now there's activity logs in Azure, tracking the activity of action by management personnel along the control plane. We can bring that in, right? That's another layer to our context. Diagnostic or auditing logs for the platform. If there's some reason, you know, I've used security in the past many times for not just threat hunting or intrusion detection, but actually, you know, helping to resolve issues in the network or with applications, and that can help do that as well, or clue you into something that an attacker might be doing and cause those kind of issues. So we can bring those in as well as sign-in logs. So if they're authenticating, signing in, and then also Azure AD audit logs, things from the AD perspective that we can bring in. We can bring all of that in using that faulty module in security. And I'm not going to go through this a whole lot, but here's really a summary and some links. If you want to go off and do that on your own, you can absolutely do that. But again, it would be using that Azure faulty module. Once you have everything set up, you can pull all of that data in, have that alongside of your on-prem data or your other cloud data. If you have Azure and, you know, GCP and AWS, you can have them all in there in the same single pane of glass. So it's really awesome to be able to do that. And the same thing with GCP data, audit logs, right? Those can be published to pubs of topic. Same thing with VPC play logs. Looking at not necessarily packet capture, but, you know, just some flow data, some kind of back and forth connections, Z connection style records that you can look at from the authoritative source, right, from the VPC itself. And you can pull that in using the faulty modules. And here's some, here's some configuration here. I'm not going to go over that a little bit, but if you want to review the slides later, which I'll have posted, you can absolutely do that and set that up with faulty modules as well. Similarly, with AWS, in addition to all of the great traffic mirroring, you can pull in stuff like cloud share logs, cloud watch, VC2, VPC flow, all of it into S3 and SQS, pull that in using those faulty modules that are tied in with security and in the Elastic Sack. Let's check in time. Okay. And so here's some example cloud trail configuration. Sorry. So yeah, you can configure cloud trail to send obviously to S3 and then, you know, from there S3 would notify SQS and then you can kind of use SQS as a pointer to get that data from S3, right? And then we can sift through all of that data and hunt. And maybe if we want to alert on certain data from there, we can absolutely do that. And we have some documentation there down at the bottom for you to walk through if you want to walk through that as well. All right. So now we've got another lab here. What we're going to do is we're going to stay in AWS. We're going to configure the cloud trail logs and see if we can pull those into security and in and get some additional context. So again, this is just another way to assess the traffic mirror. If you're not able to see the traffic or you simply want more telemetry, right? You want more contextual data. We can pull in those cloud trail logs and go from there. We can see stuff, you know, if there have been keys deleted or users added, management functions, things like that, we can see that through cloud trail. All right. And so we'll pivot over to there. And what we'll do is going to paste this, let me double check the requirements doc here. Okay. So get to the cloud log ingestion. Now that will be, let me make sure that's the one I have. Yeah. Okay. So on that cloud log ingestion doc, what we're doing is we make another millions tab. We're going to create an IAM user and that user is going to be used instead of a root user to delegate access to those cloud trail logs and SQS. Okay. So we're going to create that user. We're going to go over here to IAM, search IAM over here. All right. And you can see we have users here. All right. And so what I'm going to do here is I'm just going to get a couple users here. I'm going to say cloud trail. Actually, let me just click add users first. So I'm done. All right. There we go. All right. So add users, cloud trail, demo user. All right. You can specify your name, whatever you wish to add there. I'm going to enable programmatic access. All right. This will allow us to programmatically access stuff instead of having to log in through the console. And I'm going to specify permissions here. I'm going to search for that AWS Lambda execution role. Oh, okay. I'm sorry. Create group. And then search for it. I'm going to add that, keep that selected for this group. And then I'm going to add Amazon S3 read only access. And again, these are in that doc. So be sure you refer to those. Okay. So cloud trail users is going to be the name of my group. Create group. All right. Okay. So we can see that group is now created. We can choose if he wants and selected for the user that we're creating. I'm going to click that tags if we want. I don't really care. I'm going to click create user for the cloud trail demo user. Then it's going to give me an access key and a secret access key. And I'm going to ask obviously that you guys, this will only be used for this demo presentation, but be sure to use your access key into your access key only. And we should be good from there. So we're going to keep those. I'm going to say those offer. I'm just going to keep this page pinned right here. So I'll come back to that in just a moment. And then what we're going to do, we're going to follow along with this document right here. So we have a walkthrough here on AWS cloud trail logs. And Kai and Shang and Elastic had a really great document that kind of tied in with this that you can review right there. But since we have our IM user and everything set up, we're going to go create our queue. All right. So we're going to go to Amazon SQS queues and create a queue. So let's just search for SQS. And we're going to create queue. And now we'll have a prompt. We're going to keep the standard queue. And we're going to name it ccdemo queue. And then I'm going to change this policy here because there's some things that need to happen for S3 to be able to publish to this queue. Okay. And that's where I'll go over here. If I go to file the page and I copy this right here. So I'm going to copy this and I'm going to edit it here in just a moment. So I'm copy and just paste that in there. And what I want to do, I'm going to take my account ID and I'm going to put it in there. And my region is going to be US East 2. So you would enter yours accordingly. There are my account ID here and the queue name here, which is going to be cbdemo queue. Let me just grab that kind of the yep. Okay. And again, these are all for demo purposes. Okay. So that's how I'm going to choose to do that. So basically anything from the accounts right now at this moment can send to this queue. You may choose to change this in your organization. You know, back down the hatches a bit, make it a little more, you know, tighten it. So I'm going to save that and click create queue. I'm going to go back here. All right. So after it's created, you'll be redirected to the summary screen. And we'll want to save the URL value here. We'll use that for our file beat configuration on security. But first, we're going to create a trail. So make sure you save that right here at this URL. All right. I'm just going to keep the page up and pinned. Okay. So if we go back, we are going to create that trail using the AWS CloudTrail console. So we'll go search for CloudTrail. Whoops. What am I doing? I'm not even in the console. I'm being silly. All right. We'll go to, you can search for this up above. Let me go ahead and copy this off, actually, this URL. Copy that over here to the side. Just for fun, dude. And we'll search for CloudTrail here. All right. Now let's create a trail. All right. And we can name it whatever we want. You know, for my purposes, I'm just going to save the demo trail. It's going to create an associated bucket and folder with that. And you can see what the name is going to be here. So just click create trail. Okay. And then, so if we go here and click that, we can edit the trail if we want. So I'll just click edit to see the details. And we can see that, you know, stuff right here, we're using this S3 bucket, right? Just some general details. And management events. We click on this. We'll see that we are auditing read and write API activity events and management events. So we'll just save that. So it should be good to go from that perspective, right? And then if we go back, just depending on, you know, how we created it, it may ask us certain things, right? So we just created that one and we're not using a key with that one. But we'll just take the defaults there. And so we see the status now if we go back, not here, but to here, we should see the status as logging, which we do. Okay. All right. And now what we'll need to do is we'll need to ensure our bucket is configured correctly, right? So we're going to go to S3 now. Okay. And we're going to select the bucket. All right. And we're actually, what we'll do here is we'll just click on the bucket. And then we'll select properties. And we'll drill down. We want to know if the bucket is accessed. And what we'll do here is just choose our bucket. We'll publish to our own bucket. That's accessed. You could alternatively publish to a different bucket for, you know, server access and that kind of thing. All right. And then what we'll do here is we'll add an event notification. Let's say the event notification here. Okay. And we can add additional details if you want, but you don't necessarily have to. And we'll select all object create events here. Okay. So any time, basically, something is added to that S3 bucket will be notified. Okay. And now this is important. We're going to choose our destination here. And our destination is going to be an SQSQ, the one that we set up. So we'll, we don't have to enter the ARN. We can actually choose CV demo queue here. We'll save changes and assuming the permissions were correct and everything. And it can actually send to the queue. It will actually fail at runtime here if it's, if it cannot. At least I believe it will. So we'll go from there as far as, you know, hopefully for now it should be working well or working as intended. All right. So now what we'll do since we've configured that is we'll configure the security and the configuration. All right. So we'll take that access key and that access key ID and some other details like the queue, the queue name. And we'll go over here to security ending and back up. You can opt SO salt stack. Oh, you'll actually might need to elevate. So opt SO salt stack. And inside the local directory there, there is a pillar directory. And this is where we house some salt configuration and where you would configure certain things in security ending. So I'm just going to go into the minions directory. This is where configuration for a specific node, security ending node would live. So even the manager, if you have a manager node would have this configuration. And then I'm going to go down all the way to the bottom. I'm going to paste in some configuration here. And so I'm just going to copy this right here. I'll paste that in there. And it's wrapping a little bit just because of the fonts, but rest assured. What we'll do here is we'll specify our account ID and demo queue here, and then our access key ID and then our access key here. Okay, so I'm just going to paste this in first since I have this available. At least I have the URL of it. Oh, I'm sorry. I'll have to go back and get those. That URL that you copied before, you would simply paste that into here. And then I will go and grab the key and key ID. Okay, copy. I'll paste that key ID here. All right. And I will copy. All right. Save that. All right. So let's double check. Let's go back to this dock here. Okay, so we added this. We modified that configuration. Now we need to restart file B on the node. So let's do that. So file B restart. And depending on if other commands are being run, sometimes it may take a few minutes to run this and for this to complete. So that went pretty well so far. So we're good there. Now what we'll do here is we'll just do an SO2 status. I'm sure everything looks good. Okay, everything's still running good. And I'm actually going to check from the data perspective. And so this is one command that you can run to check and see what indexes are actually in, you know, in the Elasticsearch from the command line. It's in that there into the dock. All right. So I see a whole bunch of stuff. It's kind of hard to read though. So I'm going to sort or I'm going to grab this. Okay, cool. So I see an AWS index was created. Okay. I don't see any documents just yet. But I do see that it was started to pull that data. And it may take a few minutes before we start to see anything. We may have to perform some activity. But I actually see some there now. So let me actually back off this font a little bit. So it will be a little bit easier to see. So this is actually the dock count here, the document count that you have in that index. So that shows us that there are some documents in the Elasticsearch index. So then if we go over here to something like hunt, search event dot module AWS, we should see some data. Okay, cool. And then we can also group. Similarly, kind of like Splunk, we can group by the event action there. And then we can see all of these actions that are occurring. And we can slice and dice that all day. So if we wanted to add additional fields to that, we can go up and put that in the group by up there in the search bar. Or if I want to go through and see, you know, filter on something else, I can, you know, I can filter on the key, whatever can include that. Well, that's actually a filter. I'm sorry, that's not a group by. So that would actually be an inclusive filter. But if I wanted to group by something else, like the key, you know, the cypher suite is a pretty bad example, but you would just add that to the group by, right? And then you can see that alongside it right there. And then you can also pair this right with that other traffic, right? So if you wanted to see a certain activity, you can cross correlate that with the other traffic. So again, it's really super powerful to be able to do that and, you know, be able to essentially aggregate all of that traffic and all of those logs within security. Okay, so I know that was a quick lab. I'll stop there for a minute, maybe to let folks catch up if they're still working on that, if they're following along. Or if there are any questions, let me go ahead and check the string yard here. Okay. All right, no questions. Let me get, throw this a little scratchy here. Now, let's see if I can do it this time. Play from current slide. Look at that. Learn something new. All right, so let's talk about some additional tools. I'm just going to touch on these briefly. I mentioned, you know, the auto, what is it? Auto mirror, right? Three-core second auto mirror. Definitely check that out in addition to, you know, TM nids. But other additional tools you might check out. The X-Lens of PCAP is a tool that I actually wrote a little while back when we didn't have the ability to pull PCAP like we do now with security engine. But in some cases, you know, there's still going to be many environments where you're not able to, you know, maybe tools don't know the X-Lens. Or, you know, you have to be able to kind of unwrap that tunnel. And this allows you to do that. Basically, you run the command just like this, and then it will output a PCAP that has been stripped of that the X-Lens encapsulation. So if you're on a case or you're pulling PCAP from a box in a cloud and it's AWS or another partner solution that does the X-Lens encapsulation, that can absolutely help you in that case. And it's pretty, pretty nifty tool to have. Also, not necessarily a tool, but maybe, I would say it's a tool, just maybe not software. It's the cloud matrix for MITRE ATT&CK, right, is a great way to kind of map your coverage across the cloud platforms. You can create detections. I mentioned Playbook. So I know Tiago and Dreadcorsak have some cloud trail rules out there that they use. I think they use a little bit different, maybe, with like the elastic detections, but you can still use that relevant Sigma rule and map those across, you know, or map your detection coverage using that, right? So, again, another useful tool to have. So I'm not going to cover this in the workshop, but feel free if you want to explore on your own some automated deployment or testing of security engine. One of the ways that we can do that is going to be using Terraform. And so we have a repo here, just at this link. And again, these slides will be sent out, but I will put that, okay, I'm going to actually copy that right here. I'll put that in here as well. I'm going to appendix for you if you want to check that out. That's a huge font. All right. So I'll flip back here. Okay. And so if you want to test that out, what it does is it spins up an optional Ubuntu node and a security engine node, and it automatically configures AutoMirror so that those instances come up already ready to be mirrored or already mirroring traffic. And then you're ready to do your testing or whatever, right? Do your lab. So it's pretty cool to have that capability and do that really quickly and easily this way. All right. And the same thing. You can do the exact same thing with GCP. Right now, though, I will say the Terraform config does, by default, use the AMI. So after that trial period, if you don't want to continue using that, I would make sure that anything you spin up, you change the AMI use. And that's, you can do that within the Terraform config described in the repo. And then so with GCP, you can do the same thing again. Now we don't necessarily have an official Google image or Azure image at the moment, but there are lots of cloud things that we're working on very diligently. So I would keep an ear out for that good news at some point. But be sure if you're a GCP shop, if you're AWS, try and spin it up and check it out if you can. And that is pretty much it. Unless there are questions that we can direct towards more lab time or activity, that's pretty much all I had. I know it was kind of fast paced. I just wanted to make sure that we're good on time here. And I wanted to make sure that you guys have the resources to go back and review this later. So again, you should have everything you need. If you want to replay the video or go back to the slides, all of the resources should be there for you to be able to do all of this on your own and be successful doing that. And obviously, if you still need help, feel free to reach out to the real W Lambert on Twitter. Or if you think Security Ending is cool, make sure to hit up Security Ending or Doug Burks on Twitter. If you want to download it or want to see the documentation, all that's there as well, as well as the link to the AMI and Cloud resources. Again, I just want to say thank you for allowing me to present here today and perform this brief workshop with you guys and kind of get you exposed to Security Ending in the Cloud and how you might leverage it. Again, if you guys have any questions, I'll be glad to answer those now or later if you prefer. So thank you guys again.