[00:00.580 --> 00:08.840]  So today, I really wanted to focus on kind of an introductory level explanation of, you know,
[00:08.840 --> 00:13.700]  some of the stuff that we see in the cloud and, you know, of course, how a lot of things are moving
[00:13.700 --> 00:19.180]  to the cloud these days, just security onion in general, and how we might be able to leverage
[00:19.180 --> 00:25.260]  security in the cloud to monitor our cloud infrastructure. And then also, maybe a couple
[00:25.260 --> 00:34.420]  ways that, you know, through a stance of academia or standing up a POC proof of concept or whatnot,
[00:34.420 --> 00:39.740]  how we can automate that and automate our testing and maybe automate the deployment
[00:39.740 --> 00:46.380]  of security in the cloud. So most of this will be focused on AWS, since it is one of the largest
[00:46.380 --> 00:51.340]  cloud providers. Although we will have some resources to share for other cloud providers,
[00:51.340 --> 00:56.840]  and we'll be going through some of that stuff there. So without further ado, I will go ahead
[00:56.840 --> 01:04.880]  and get started. A little bit about me. I have four kids, married, of course, and definitely love
[01:05.500 --> 01:11.360]  every minute of it. I, as I mentioned, work for Security Onion Solutions, where we develop and
[01:11.360 --> 01:16.580]  maintain Security Onion. And we also provide professional services and training for Security
[01:16.580 --> 01:23.620]  Onion. And it's really all about that open source platform and getting folks better visibility into
[01:23.620 --> 01:30.180]  their network. So let me go ahead and get started. Talking about the agenda today, we're going to go
[01:30.180 --> 01:35.700]  through the cloud in general, some of the stuff that we find all over the place in different
[01:35.700 --> 01:44.980]  clouds, whether it be AWS, Azure, GCP, Google Cloud Platform. And then also, again, introducing
[01:44.980 --> 01:51.740]  Security Onion, what it is, how it can help us, and then introducing, again, Security Onion in the cloud,
[01:51.740 --> 02:00.190]  and then automating that deployment. So when we talk about the cloud, and we talk about all the
[02:00.190 --> 02:07.670]  assets and all the data that we really house there, and that potentials or other folks could
[02:07.670 --> 02:14.450]  potentially access, some of those are as follows. For AWS, it's going to be things like S3 buckets,
[02:14.450 --> 02:20.710]  which we might have seen in the news recently. A lot of leaky buckets, a lot of unsecured S3
[02:20.710 --> 02:27.050]  buckets having public read or maybe even write access to them. So there's definitely some
[02:27.050 --> 02:33.010]  attack surface there with that kind of stuff, as well as DynamoDB and some other production data
[02:33.010 --> 02:41.210]  storage in AWS. Again, with Azure, it's blob storage, or maybe even event hubs, where our data might be
[02:41.210 --> 02:48.470]  stored, or logs, or whatnot. So that's another thing to keep a look for in Azure. And then in Google
[02:48.470 --> 02:54.490]  Cloud Platform, obviously, like S3, we have storage buckets, cloud data stores and file stores that we
[02:54.490 --> 03:00.450]  want to keep an eye on, and lots of juicy stuff for attackers that they may be trying to find this
[03:00.450 --> 03:08.690]  stuff, publicly accessible from the internet, or they're able to get past, slip past our initial
[03:08.690 --> 03:13.770]  defenses and easily get to the stuff, or maybe even not easily get this stuff, we definitely want to
[03:13.770 --> 03:20.550]  know. And then of course, we have the application or the network traffic itself, right? So we have
[03:20.550 --> 03:25.010]  all this this traffic and this data flowing across from these different instances, from these
[03:25.010 --> 03:30.310]  different segments in the cloud. And we definitely would love to know what's going on. And it
[03:30.310 --> 03:34.990]  definitely can help others to know what's going on, such as an attacker. So we just want to be mindful
[03:34.990 --> 03:39.950]  of these things whenever we're doing business in the cloud, running all these critical operations
[03:39.950 --> 03:48.650]  and whatnot, just being aware of that. Now, an example of that stuff being abused in the case of
[03:48.650 --> 03:55.270]  AWS, there are various tools that, you know, attackers or just security researchers use in
[03:55.270 --> 04:02.050]  general to try to find these items. It might be S3 scanner to scan for open S3 buckets, or maybe AWS
[04:02.050 --> 04:07.010]  bucket dump to try to get the stuff where we could enumerate buckets, look for interesting, juicy
[04:07.010 --> 04:13.330]  tidbits of data. So there are lots, there are no shortage. And, you know, every day, again, there
[04:13.330 --> 04:19.410]  are more leaks and more tools being released to try to find this type of stuff. So it's becoming
[04:19.410 --> 04:24.950]  easier and easier for the attacker to get in and get this data if we're not careful about our
[04:24.950 --> 04:34.880]  environments. Similarly with Azure, there's microburst, right? So we could look for different
[04:34.880 --> 04:41.160]  services in Azure that might be enabled, weak configuration, or maybe even try to identify
[04:41.160 --> 04:47.380]  post-exploitation actions, right? So, again, these tools, there's no shortage. Definitely have to
[04:47.380 --> 04:56.400]  keep an eye on this stuff. And then, again, with GCP. So GCP, there's a mechanism, GCP bucket
[04:56.400 --> 05:01.120]  brute, similar to the others, where we can enumerate Google Cloud storage buckets. We can
[05:01.120 --> 05:07.000]  determine access levels, privileges, see if we can get privask, privilege escalation there.
[05:07.120 --> 05:15.720]  Lots of ways that we can do that there. And then also the cloud credentials. It's really
[05:15.720 --> 05:21.180]  going to be another thing where it's not even the data itself, but something that brokers access to
[05:21.180 --> 05:26.320]  the data, right? If account passwords, IM, or root account credentials are able to be phished
[05:26.320 --> 05:31.620]  from people, of course, that's no good. And, again, it's the weakest link, which is,
[05:31.620 --> 05:37.400]  you know, very commonly the human in this case. And, you know, with these access keys or these
[05:37.400 --> 05:42.520]  credentials, that means that attackers could control access to AWS servers without a username
[05:42.520 --> 05:47.760]  and password, right? So access keys, if they have those, they can just go straight in.
[05:48.020 --> 05:52.760]  And then, again, those are obtained usually by a phish or some similar method, right?
[05:56.070 --> 06:01.250]  And then, again, with the privilege escalation with regard to cloud credentials,
[06:01.250 --> 06:07.710]  folks can create new policy versions, right? They can create new keys off of those keys. So even if
[06:07.710 --> 06:11.490]  you delete the old keys that were compromised, if you're not deleting new keys that were created by
[06:11.490 --> 06:17.390]  them, or you're not monitoring that, it's very difficult to get, you know, those attackers out
[06:17.390 --> 06:23.190]  of your network, or it just poses yet another concern and another question, right? Even adding
[06:23.190 --> 06:29.230]  malicious Lambda layers to existing Lambda functions, it's one thing that attackers can do,
[06:29.630 --> 06:35.050]  and Rhino Security Labs actually demonstrated it's pretty cool, actually, basically modifying
[06:35.050 --> 06:41.150]  existing Lambda functions to act as you would not expect, and it's a great way to hide stuff like
[06:41.150 --> 06:49.260]  that without being super obvious. So we've talked about that stuff, and I've gone through that
[06:49.260 --> 06:54.620]  rather quickly, but I think as far as a cloud village, I think some of us are aware of these
[06:54.620 --> 07:02.020]  threats, of course. So now I want to talk a little bit about monitoring challenges, right? So monitoring
[07:02.020 --> 07:08.560]  in the cloud. Now with NSM, or network security monitoring, which is really a core component of
[07:08.560 --> 07:13.580]  security engine, where we're monitoring that network data, we're monitoring that traffic that goes from
[07:13.580 --> 07:18.400]  endpoint to endpoint, there can be some challenges in the cloud, and there are ways to get around
[07:18.400 --> 07:25.440]  them, but to talk about a couple, VXLAN encapsulation. So even if we are able to capture the traffic
[07:25.440 --> 07:32.160]  in the cloud, typically if we don't have the right applications, if we can't decapsulate that,
[07:32.160 --> 07:38.180]  or understand what it means, or alert on it, then it's not as much value to us. So it makes it more
[07:38.180 --> 07:44.680]  difficult, you know, to interpret that data, or to use that data in analytics, or reporting,
[07:44.680 --> 07:50.920]  or alerting, and that can be difficult. That can be a challenge. Another one would be segmentation.
[07:51.160 --> 07:58.400]  Maybe you have certain segmentation in your clouds where you're not able to easily tie together a
[07:58.400 --> 08:04.280]  monitoring solution. I'm not saying security engine is it, and they'll be all for that, or
[08:04.280 --> 08:09.560]  anything else, but that's just a general challenge overall that sometimes it's just difficult to
[08:09.560 --> 08:18.320]  overcome. Then again, ephemerality. So we talk about instances spinning up and down a lot of times in
[08:18.320 --> 08:23.780]  cloud environments. You may have a variable number of instances. They may be there one minute, they
[08:23.780 --> 08:29.060]  may be gone another minute, and one of the challenges with monitoring that is how do you
[08:29.060 --> 08:36.160]  tell something, right, to monitor this host, or to monitor the activity of this host when it spins up,
[08:36.160 --> 08:40.300]  and then it just goes away? How do we tell, you know, to monitor the next host and the next host?
[08:40.540 --> 08:47.240]  How can we group these together and create an effective solution? And in some cases, there really
[08:47.240 --> 08:53.000]  is no native or no great mechanism for monitoring in the cloud, and it just, again, makes it even
[08:53.000 --> 08:59.920]  more difficult. But there are ways around it. Sometimes they don't scale that well. Well, a lot
[08:59.920 --> 09:04.700]  of times they don't scale that well. So it's always best if there is a native solution. And again,
[09:04.700 --> 09:09.200]  there are commercial solutions available for monitoring. A lot of times these are highly
[09:09.200 --> 09:16.400]  specialized, highly integrated with specific feature sets and specific products, so they can
[09:16.400 --> 09:22.720]  be very expensive. And a lot of folks may not be able to afford something like that, especially
[09:22.720 --> 09:31.050]  small to medium-sized businesses that are trying to run their workloads in the cloud. So
[09:32.770 --> 09:38.010]  enter the onion. Just making sure that wasn't from you guys. Enter the onion, right? Security
[09:38.010 --> 09:44.170]  onion. We're going to talk a little bit about here. So what is security in general? A little
[09:44.170 --> 09:51.050]  introduction. It was created by Doug Burks in 2008. Doug was really scratching the need or the
[09:51.050 --> 10:00.450]  itch to create an all-in-one solution, a click, click, or a click, click, finish solution as far
[10:00.450 --> 10:08.690]  as rolling your own IDS and doing all this alerting and this analyst activity. Back during
[10:09.470 --> 10:15.250]  2007, 2008, there really weren't a lot of great solutions tied together to enable somebody to
[10:15.250 --> 10:21.230]  have this effective monitoring platform and not have to know all these ins and outs, not having
[10:21.230 --> 10:29.310]  to compile ZEKE, not having to compile Cercata, PFRing, NetSniffNG and all this stuff. You had to
[10:29.310 --> 10:36.190]  know a lot of stuff, a lot of that core technology to be able to even get in the game. And it takes
[10:36.290 --> 10:41.610]  a lot of time to spin up. So a lot of the reasoning behind this is that we want this platform that's
[10:41.610 --> 10:49.250]  easy to install, easy to set up, and we're getting folks monitoring in minutes. And it's free. It's
[10:49.250 --> 10:55.330]  open source. Again, those small businesses, those medium-sized businesses can easily adopt this and
[10:55.330 --> 11:00.950]  be able to tip the scale in favor of the blue team maybe, just a little bit more to that side
[11:00.950 --> 11:07.770]  and be able to identify what's going on in the network. So security in itself can be installed
[11:07.770 --> 11:13.630]  from an ISO image. We provide one on our site. And then also it can be installed from packages
[11:13.630 --> 11:20.410]  on top of Ubuntu 16.04. And again, all this takes a very little amount of time. Obviously,
[11:20.410 --> 11:26.670]  the ISO image is going to be faster, but you can install it on your Ubuntu flavor of choice.
[11:27.790 --> 11:33.110]  So like many IDSs and network security monitoring platforms, Security Engine is traditionally fed
[11:33.110 --> 11:41.530]  data from a TAP or a SPAN port. We have had folks use ERSPAN, GRE tunnels, that sort of thing.
[11:41.530 --> 11:45.350]  It's not recommended, and it's not really supported, but there are other methods of
[11:45.350 --> 11:51.210]  getting that traffic to it. And now we do integrate with the Elastic Stack for the
[11:51.210 --> 11:56.930]  data enrichment, indexing, and visualization components. So it gives you all that rich,
[11:56.930 --> 12:01.370]  being able to create data tables and be able to create visualizations and really get an
[12:01.370 --> 12:04.670]  idea of what's going on in your network. It makes it really, really easy.
[12:07.600 --> 12:12.540]  And here's just a quick screenshot. It's not the most exciting screenshot, but it does give you an
[12:12.540 --> 12:18.520]  overview into the overview dashboard itself in Security Engine. And this is inside of Kibana.
[12:18.520 --> 12:24.020]  So we can see the overall number of logs here and some different log types that we've recorded.
[12:24.100 --> 12:28.980]  Some sensors that we've got connected right now, in this case just one. And then the number of
[12:28.980 --> 12:38.780]  devices connected, which would be the management node and the sensor itself. Let me just click here.
[12:40.900 --> 12:45.660]  And again, just some more, you know, just kind of scrolling down that overview dashboard. And
[12:45.660 --> 12:49.420]  I'm going to go through this more in just a little bit, but we can see some other data types.
[12:49.420 --> 12:54.820]  And again, just grouping on those sensors and those protocols. And then you also see some NIDS
[12:54.820 --> 13:04.330]  alerts down here. So talking about some of that data that we get, a lot of folks traditionally,
[13:04.330 --> 13:08.810]  when they've been exposed to an IDS or a network-based intrusion detection system,
[13:08.810 --> 13:12.070]  they're going to be aware of this type of alert data that we see here on the screen.
[13:12.630 --> 13:16.110]  So this right here is an alert, right?
[13:16.910 --> 13:21.590]  Let me see if I can do it without clicking. Oh, let me go back. Sorry about that. So the
[13:21.590 --> 13:26.930]  panmunix right here, this is just a Wazoo alert for the user W. Lambert that occurred locally
[13:26.930 --> 13:32.990]  on a system. So Wazoo is a host-based intrusion detection system that we include in Security
[13:32.990 --> 13:37.870]  Engine that can generate that alert data. And not even just alerts, but other types of activity
[13:37.870 --> 13:45.530]  generated on the host itself. And then we have down below alert data, similar to what you would
[13:45.530 --> 13:52.350]  find from Suricata, going to be generated down here. So we've got both of those types of alert
[13:52.350 --> 13:56.810]  data there, the host and the network-based intrusion detection system alerts. And it gives
[13:56.810 --> 14:03.570]  us the ability to kind of correlate back and forth and tie things together better, right?
[14:05.960 --> 14:11.780]  The other types of data that Security Engine provides is going to be that of network metadata.
[14:11.780 --> 14:17.160]  And this data is going to be recorded by Zeek, formerly known as Bro. You might have some Bro
[14:17.160 --> 14:25.100]  fans in here. And this metadata is going to give us a lot of detail around specific protocols and
[14:25.100 --> 14:32.500]  transport mechanisms that we see in our environment. For example, DNS, HTTP, SSL,
[14:32.500 --> 14:37.860]  there's tons of different protocol parsers for Zeek. And it gives us just a lot of great detail
[14:37.860 --> 14:47.440]  about those, right? Like URIs, user agents, queries, the query codes, whatnot. Just tons and
[14:47.440 --> 14:51.840]  tons of different stuff that you might have associated with each different type of transaction.
[14:53.740 --> 14:59.080]  And then the full content data is another thing that Security Engine provides. And this is going
[14:59.080 --> 15:05.860]  to be commonly known as PCAP. So we can render an ASCII transcript of that PCAP based on whatever
[15:06.440 --> 15:13.080]  items that you're looking at in Security Engine. So if you want to go from an event in Kibana to
[15:13.080 --> 15:19.100]  the PCAP and see the actual raw communication, typically if it's not encrypted or whatnot,
[15:19.100 --> 15:23.980]  or if it's not some unsupported protocol, then you should be able to see that activity.
[15:23.980 --> 15:30.400]  And it helps to really verify what you think is going on and the other things that you're
[15:30.400 --> 15:37.700]  seeing in the environment. So again, it offers that complete picture or that complete transcript
[15:37.700 --> 15:49.640]  of what is going on. Now, you can feed supplementary data to Security Engine. So we have
[15:50.380 --> 15:55.780]  the HIDS data, the NIDS data, we have all of this network metadata and stuff generated by Zeek,
[15:55.780 --> 16:02.680]  we have PCAP, and then we have other stuff like Beats, right? So using FileBeat, we could pick up
[16:03.220 --> 16:07.720]  DNS debug logs, we could pick up specific application logs and send those off to
[16:07.720 --> 16:12.760]  Security Engine. We could pick up Windows event logs and send those off with Sysmon and whatnot.
[16:12.860 --> 16:17.560]  We could even use PacketBeat and send that stuff. So if we have a segment where we're monitoring
[16:17.560 --> 16:23.840]  hosts, and some people do this in the cloud, but whenever you can avoid it, I would probably
[16:23.840 --> 16:30.700]  recommend it, you can use PacketBeat to have it on those isolated hosts. If you have a host that's
[16:30.700 --> 16:34.920]  on its own dedicated network and you're not allowed to monitor that segment traditionally,
[16:35.380 --> 16:41.640]  maybe if you have that pinhole in the firewall or whatnot, to install PacketBeat and send that
[16:41.640 --> 16:46.660]  data back, you at least have some better visibility into what's going on in the box,
[16:46.660 --> 16:54.780]  as well as a host-based agent and whatnot. And then there's stuff like S3 and Azure event hubs
[16:54.780 --> 17:00.200]  that Logstash affords us, and even FileBeat these days, that we can send data from those
[17:01.060 --> 17:09.880]  storage facilities and even Syslog. And that's great and all, right? It's great that Security
[17:09.880 --> 17:13.520]  Engine offers that stuff, and I haven't really gone into a lot of detail so far,
[17:13.520 --> 17:18.220]  but how can it help us when we're in a cloud environment, and how might we set that up?
[17:18.220 --> 17:22.260]  Or what might that look like? What does the infrastructure look like?
[17:22.660 --> 17:31.560]  You know, maybe with AWS or something similar. So that brings me to traffic mirroring. When we
[17:31.560 --> 17:38.800]  talk about traffic mirroring, I'm talking mainly here with regard to AWS, because that is the
[17:38.800 --> 17:46.660]  actual naming of their mirroring facility in AWS. And we can take advantage of that with Security
[17:46.660 --> 17:55.240]  Engine. We can basically use this architecture to collect this traffic from these hosts and then
[17:55.240 --> 18:02.540]  forward it off to our Security Engine instance. So we can set up a mirror target, which is going
[18:02.540 --> 18:07.920]  to be our Security Engine instance or a sniffing interface, and we can set up our mirror filter,
[18:07.920 --> 18:13.000]  which is going to filter any traffic that we want to go to that target. For example,
[18:13.000 --> 18:19.720]  if we don't want certain traffic, if we don't want DHCP or some other type of traffic to be sent
[18:19.720 --> 18:26.900]  to our Security Engine instance, we can filter that out with our mirror filter. And then we'll
[18:26.900 --> 18:31.640]  set up our sources, which will feed through that mirror filter into that mirror target.
[18:32.020 --> 18:38.140]  And all of this encompasses a mirror session, really. So that's what a mirror session is
[18:38.140 --> 18:45.760]  comprised of. And that is really the pretty basic concepts of the AWS Traffic Mirroring.
[18:49.290 --> 18:54.430]  Again, that traffic mirror target is going to be where we define the target interface,
[18:54.430 --> 18:58.630]  our Security Engine instance in this case, where we want to send our mirrored traffic
[18:58.630 --> 19:04.710]  that we're collecting from our hosts. And then we have that filter, which is going to filter out
[19:04.710 --> 19:09.750]  any unwanted stuff that we don't want or allow us just to specify what we do want.
[19:12.030 --> 19:15.670]  And then we have that overarching mirror session comprised of each of those.
[19:17.110 --> 19:26.350]  Let's check this real quick. Okay, no questions. All right. So let me get back to this. All right.
[19:26.350 --> 19:30.730]  So the mirror session, then. You can see here we've got a screenshot right here. The name is
[19:30.730 --> 19:36.550]  just Security Engine demo session. And then, again, the source and the target, which is our
[19:36.550 --> 19:44.610]  Security Engine instance. And there's another way we could approach this. So maybe instead of
[19:44.610 --> 19:49.830]  just setting up a standalone instance of Security Engine, if we just want to have our Security
[19:49.830 --> 19:55.890]  Engine forward node, which is going to be our sensor only and our distributed deployment,
[19:55.890 --> 20:00.930]  we can have just that in AWS. So typically, I don't think I went through this, but our
[20:00.930 --> 20:05.990]  architecture would suggest in a distributed fashion that you have a master or manager node,
[20:05.990 --> 20:11.770]  and then you have this forward node. And then you have a storage node, which is going to store most
[20:11.770 --> 20:17.290]  of your elastic data. So what's going to happen in this case is you're going to send your forward
[20:17.290 --> 20:20.910]  node, or you're going to have it in AWS. It's going to be collecting that traffic from the
[20:20.910 --> 20:24.990]  mirror session. And then your master server is going to be connected up to that. So you could
[20:24.990 --> 20:29.650]  have an on-premise master server. You don't necessarily have to deploy all of Security
[20:29.650 --> 20:35.450]  Engine in the cloud. You could have another on-premises forward node, right? You can have
[20:35.450 --> 20:40.650]  all of these different types of devices on your local network and have maybe open VPN or direct
[20:40.650 --> 20:45.630]  VPN access to the cloud and having that one security in an instance if you need it.
[20:45.730 --> 20:50.410]  So it's very flexible how we can architect these deployments. And I think it makes it
[20:50.410 --> 20:56.450]  very powerful overall for us to be able to have that comprehensive view for both our local and
[20:56.450 --> 21:07.540]  our cloud networks. And this right here is just an example of some of the VXLAN traffic that would
[21:07.540 --> 21:13.740]  come across during a typical mirror session. So all of this mirror traffic is going to be
[21:13.740 --> 21:20.700]  encapsulated, as I mentioned, in that VXLAN tunnel. So this basically, for applications
[21:20.700 --> 21:25.420]  that can't read it, of course, as I mentioned, creates a little bit of a challenge. But in our
[21:25.420 --> 21:31.240]  case, Zeek and Suricata can both decapsulate this data. So this is what this looks like
[21:31.240 --> 21:36.180]  just coming across the wire on a box right here in AWS.
[21:39.990 --> 21:45.910]  Again, just a shot of some cloud node stuff. If we were going to set up security as a cloud node
[21:45.910 --> 21:57.600]  and have the rest of it on premise. And as I mentioned before, Suricata 4.1.5 and up, which
[21:57.600 --> 22:02.100]  of course now we distribute a version higher. I can't remember the exact version off the top of my
[22:02.100 --> 22:10.880]  head, but we can decapsulate VXLAN now. And VPC mirroring is capable with only these Nitro-based
[22:10.880 --> 22:17.360]  instances. And I've got some documentation down there at the bottom with regard to those EC2
[22:17.360 --> 22:23.440]  Nitro instances. So you'll want to make sure if you're monitoring stuff or if you've not even
[22:23.440 --> 22:27.600]  deployed yet, and if it's feasible cost-wise, that you're deploying on these supported instances so
[22:27.600 --> 22:37.860]  that we can take advantage of that. And then again, there are other considerations as far as
[22:37.860 --> 22:43.120]  mirror sources and destinations. There are overall limits to the number of sources, so
[22:43.120 --> 22:47.860]  please do check out that link down there if you do plan on standing this up in production.
[22:48.380 --> 22:53.400]  Just testing in a lab environment, you're never going to really exceed the limits here. But
[22:53.960 --> 23:00.280]  architecturally, there are some considerations that you'll want to have, maybe using a
[23:00.280 --> 23:06.380]  NLB or a network load balancer versus individual hosts and whatnot. So that's just something to
[23:06.380 --> 23:14.940]  think about there when you're going through and planning your deployment.
[23:14.940 --> 23:21.020]  All right, and before we get started here, I also want to talk about TMNIDS real quick. So
[23:21.020 --> 23:29.020]  TMNIDS is an open source project written by Tiago Faria and ThreeCorsec. So they've been
[23:29.020 --> 23:35.620]  doing a bunch of great work with NSM lately, specifically NSM in the cloud.
[23:36.940 --> 23:45.220]  And what this is, TMNIDS is an open source script that will allow you to, if you're familiar with
[23:45.220 --> 23:54.600]  NIDS, testing your IDS using TestMyIDS. So it's a very... folks like me that have been doing it
[23:54.600 --> 23:59.380]  for a little while, there's a site called TestMyIDS, and you would curl that and you would
[23:59.380 --> 24:06.080]  get the UID root, and that would send you a little IDS alert as long as that rule was enabled and
[24:06.080 --> 24:11.340]  make sure that your IDS is A-OK and that it's working as intended. And this serves a similar
[24:11.340 --> 24:17.700]  purpose. This is a little bit more modern day, I think, and of course you could extend it if you
[24:17.700 --> 24:23.020]  wanted to, but you can see here the different choices of alerts that you would like to trigger.
[24:23.020 --> 24:28.600]  So you have a few different options here to try and see, generate some data, generate some alerts,
[24:28.600 --> 24:35.120]  to see if that IDS is working, and to really just generate some interesting lab data. Now,
[24:35.120 --> 24:42.120]  all of this traffic right here is not actually malicious, just simulating the maliciousness,
[24:42.120 --> 24:50.540]  so please don't be afraid to run it. I know Tiago very well, and he would not... I don't think he
[24:50.540 --> 25:00.300]  would do anything like that, so... All right. So now, I know we've been talking a lot. I've been
[25:00.300 --> 25:07.900]  speaking to the joy of security and how it might help us. And now, I want to go through just
[25:07.900 --> 25:13.340]  setting it up from scratch in AWS, and hopefully you guys can follow along if you have an AWS
[25:13.340 --> 25:19.380]  account and you've seen the resources that we have here. Let me just get out of here,
[25:19.380 --> 25:32.440]  out of presentation mode. So we do have these resources here that should have been in the talk
[25:32.440 --> 25:39.320]  description or the workshop description. And if you scroll down here to follow along, I not long
[25:39.320 --> 25:45.700]  ago posted a document. And this will really be just a text-based version of the instruction here.
[25:45.700 --> 25:52.940]  And if you can, if you would like to, please do follow along. It is not the most verbose,
[25:52.940 --> 25:58.820]  but hopefully it captures everything that we need to do here, and I myself will likely be referring
[25:58.820 --> 26:03.800]  to it as we go through, just to make sure I don't miss anything. So please do let me know if you
[26:03.800 --> 26:10.060]  have any questions or something seems amiss, and we can definitely get that taken care of.
[26:10.960 --> 26:18.980]  So without further ado, I will begin to go into AWS here. Let me just go ahead and refresh.
[26:19.640 --> 26:25.580]  And what we're going to do here is we're going to stand up a security and an instance from our
[26:25.580 --> 26:32.060]  community AMI here. And we're also going to stand up another instance that we're going to be
[26:32.060 --> 26:38.040]  monitoring with the VPC, sorry, or the traffic mirroring. So we're going to get through from
[26:38.040 --> 26:42.080]  scratch, set this all up, and then I'm going to show you a way to make this a little bit easier.
[26:42.160 --> 26:47.400]  But I do want to get started from scratch, just getting you guys used to all of these mechanisms,
[26:47.400 --> 26:52.680]  all these different concepts, and maybe nailing them down a little bit more easily.
[26:53.760 --> 26:59.740]  Okay, so I'm in AWS here. I want to launch the security and an instance from the AMI.
[27:00.200 --> 27:06.700]  So a quick note, real quick too, if you guys do have trouble, I know this might be a deal
[27:06.700 --> 27:13.020]  breaker for some of you guys, there are images. So if you're looking and you don't see the image,
[27:13.020 --> 27:23.020]  there are images in EU Central 1, EU West 2, US East 2, and US West 1. I won't be able to
[27:23.020 --> 27:27.260]  update that on the fly right now, but if you do still want to try it and you're in another region,
[27:27.260 --> 27:31.780]  please feel free to reach out after the workshop and I can definitely help you out there.
[27:32.340 --> 27:38.400]  So we've got these four in these four regions. Right now I'm going to be using US East 2.
[27:39.240 --> 27:43.340]  So if I go, obviously you can see I have zero running instances right now.
[27:43.340 --> 27:45.340]  I'm going to launch an instance here.
[27:46.540 --> 27:52.200]  And come on, click launch instance. And I'm going to search for security onion.
[27:55.180 --> 27:59.660]  Right now, don't be fooled, you may see one in the marketplace here. We don't actually charge
[27:59.660 --> 28:06.040]  for our image here, and I don't believe we plan on doing that in the future. You'll see one here,
[28:06.040 --> 28:13.740]  it's by BL King Consulting. Do not use this one. Do not. This one, first of all, is based on 1404,
[28:14.580 --> 28:22.120]  which is several iterations behind what we're on now, and it is not supported nor endorsed by us,
[28:22.120 --> 28:28.800]  so please do not use that one. The one we will be using is this security onion 1604 right here.
[28:28.800 --> 28:33.640]  The official AMI provided by Security Onion Solutions. So we're going to select this,
[28:34.160 --> 28:40.040]  and the smallest you probably want to go on this is going to be a T3 medium.
[28:40.040 --> 28:44.400]  Now, this is going to be a little bit of a charge. I mentioned this in the documentation.
[28:44.660 --> 28:51.000]  It's not really much at all. It's a few cents an hour to run this box itself, so it's not much,
[28:51.000 --> 28:56.240]  but just a heads up there that it's not completely free.
[28:57.600 --> 29:01.860]  And again, this is not really for Security Onion itself. This is just really the infrastructure
[29:01.860 --> 29:07.520]  that's running Security Onion. So we're going to choose T3 medium for Security Onion,
[29:07.960 --> 29:12.960]  and we're going to configure instance details. Oh, you know what? I skipped a step.
[29:13.340 --> 29:19.940]  All right, so let's go back. See, I should have been reading my own documentation. All right,
[29:19.940 --> 29:26.500]  we'll get a VPC because first of all, we need a VPC to put all this together, right? So we're
[29:26.500 --> 29:32.760]  going to launch the VPC wizard, and for the sake of ease for this workshop, we're going to choose
[29:33.080 --> 29:37.840]  a VPC with a single public subnet. Now, if you're doing this in production, you probably don't want
[29:37.840 --> 29:44.300]  to do this. You'll probably want something behind a VPN using OpenVPN or Direct Connect or something
[29:44.300 --> 29:49.580]  like that. But for purposes of our testing and whatnot, and because we're whitelisting by IP,
[29:50.240 --> 29:55.860]  it'll be just fine using this. So what we're going to do here, we're going to specify the
[29:55.860 --> 30:04.860]  CIDR block for the VPC and then for the public subnet. Now, if we go to the docs here,
[30:04.860 --> 30:12.200]  we're going to choose the default 10 WACC for the entire VPC. But in case you wanted to add
[30:12.200 --> 30:19.880]  something later, we're just going to specify the 10 110 for the public subnet. So that's what I'm
[30:19.880 --> 30:28.180]  going to do here. 10 110. So if you want to go play with it, you could add other subnets later.
[30:28.180 --> 30:32.000]  We just want to narrow the scope on this one a bit. All right, so we're just keeping the name
[30:32.000 --> 30:46.570]  public subnet. Sorry. There we go. So we'll keep it like this. And then we'll go with the default
[30:46.570 --> 30:58.330]  public subnet name right here. And then we'll click create VPC. And I forget to name it.
[30:58.330 --> 31:03.630]  Okay. So let's go to my VPCs. And I'm just going to give it a name here because I failed
[31:03.630 --> 31:11.950]  to do that. Because once again, not following my own directions. So I'm going to call this VPC
[31:11.950 --> 31:21.430]  security onion demo. And right here we can see that one VPC is available. Now if we go into EC2,
[31:21.430 --> 31:25.610]  we can go to running instances. We'll go back and we'll launch an instance.
[31:25.610 --> 31:31.330]  We'll launch that security onion instance I mentioned before. That AMI.
[31:32.530 --> 31:41.800]  Like that. And we'll grab the T3 medium here and we'll go to configure instance details.
[31:42.360 --> 31:46.380]  And we'll make sure it's in our VPC that we defined and of course in our public subnet,
[31:46.380 --> 31:49.460]  which it should be since those are the only ones that we have available right now.
[31:50.520 --> 31:54.600]  Now what we're going to do here is we're going to go ahead and add the secondary device
[31:54.600 --> 31:59.400]  for the sniffing interface by clicking add device right here. And what this is going to do,
[31:59.400 --> 32:06.340]  it's going to make it so that AWS will not be able to publicly assign an IP address if you have,
[32:06.900 --> 32:11.580]  you can see it here, if you have more than one interface. So we're going to go back and
[32:11.580 --> 32:16.380]  fix that in just a minute. But we're going to go ahead and click next, add storage here.
[32:17.420 --> 32:20.720]  And everything looks good here. We don't need to modify anything here.
[32:21.280 --> 32:25.420]  Let's click next, add tags. And unless you really wanted to, we don't necessarily need
[32:25.420 --> 32:30.500]  to add any tags here. I just really want to get to this configure security group right here.
[32:31.780 --> 32:38.500]  And so what this one is called, it's called right now launch wizard one. We just want to call this
[32:38.500 --> 32:46.760]  maybe, actually we'll select a default security group here. All right. And we'll click review
[32:46.760 --> 32:51.480]  and launch. So this will have our default security group attached to it once we launch it.
[32:54.060 --> 33:00.200]  All right. Now, what we can do here is it's going to ask you for a key pair to authenticate to your
[33:00.200 --> 33:05.920]  host. Now, if you don't already have a key pair uploaded to AWS, you can create a new one and
[33:05.920 --> 33:11.040]  then use that key pair to connect with this instance. You could proceed without a key pair,
[33:11.040 --> 33:16.060]  which I don't recommend because you won't be able to get into it. So we're going to do
[33:17.480 --> 33:26.040]  create a new key pair. And go to onion demo. All right.
[33:28.460 --> 33:34.800]  And download this key pair. Okay. So I've got it saved locally now. And if I want to launch it
[33:34.800 --> 33:38.860]  from my terminal, I can do that. I'm going to go ahead and launch this instance now that I've got
[33:38.860 --> 33:44.020]  the key pair downloaded. And we get this nice little screen and we can go view our instances
[33:44.020 --> 33:51.380]  here. And we can see that it's starting up here. All right. So it's going to flip back over here.
[33:51.420 --> 33:58.360]  So once we launch that instance, what we're going to want to do is we're going to want to go to that
[33:58.360 --> 34:04.060]  network interface and we're going to want to allocate an Elastic IP. So this makes it available
[34:04.060 --> 34:10.300]  publicly so that we can access it from our box across the internet. All right. So let me go
[34:10.300 --> 34:17.600]  ahead. Go to actions. Well, I'm sorry. Go to the network interface, eth0, which is the one we want
[34:17.600 --> 34:21.900]  to connect to. It's going to bring up this hyperlinked interface ID. I'm going to click on that.
[34:22.540 --> 34:27.240]  All right. So we brought up the interface and it's selected. And then we want to manage the
[34:27.240 --> 34:33.620]  IP addresses for this interface. Once we get there, we can allocate an Elastic IP for it,
[34:33.620 --> 34:38.860]  the one I mentioned previously. It's going to give us a new tab here. And it's going to ask if we want
[34:38.860 --> 34:43.720]  to, you know, how we want to allocate it, what kind of settings. Just leave the defaults here and
[34:43.720 --> 34:48.980]  click allocate. And then you can actually see that I've got some various ones that I didn't clean up
[34:48.980 --> 34:54.940]  before allocated. But here you would have one here. So let me just go ahead and delete these
[34:54.940 --> 35:03.680]  just so I'm not confusing you guys. Okay. I'm just going to release those real quick
[35:03.680 --> 35:09.120]  so I'm not confusing anybody. All right. So we've got our Elastic interface. And now that
[35:09.120 --> 35:16.880]  that's allocated, we can go back. Go ahead and hit cancel. Go back to actions and go to associate
[35:16.880 --> 35:23.620]  address, which will allow us to associate that IP address. And we want to click allow reassociation
[35:24.060 --> 35:28.280]  just in case that we want to change it later. We probably won't be doing that here, but
[35:28.280 --> 35:31.760]  might be a good habit to get into if you want to be able to reassign them.
[35:31.760 --> 35:34.400]  And then we're going to click associate address.
[35:36.000 --> 35:43.000]  Okay. So now that we see that the... if we go back to the instances, see the instances running,
[35:43.000 --> 35:50.820]  then we see our public IP right here. So if we want to go ahead and verify that that is up,
[35:50.820 --> 35:57.700]  we can do that from here. So I downloaded that PIM file right there. You see right here,
[35:57.700 --> 36:04.540]  securityunion1.pim. And you can do this with sudo or you can change the permissions on the file.
[36:04.540 --> 36:09.060]  I'll just use sudo in this case to elevate my privileges to be able to execute this.
[36:09.340 --> 36:14.040]  But I'll just do... I'm not in the downloads. Let me change to that.
[36:15.580 --> 36:25.180]  And real quick before I continue. So when you're SSHing here, if you're on Mac or you're on Linux
[36:25.180 --> 36:29.860]  and you already have a native SSH client, you should be able to do this natively. But if you're
[36:29.860 --> 36:35.880]  using PuTTY, you will need to do something like the following in this link to convert the PIM file
[36:35.880 --> 36:40.720]  for use with PuTTY. And it's going to be using PuTTYgen so that you can basically have PuTTY
[36:40.720 --> 36:47.000]  source that that's a public key and then be able to go off and authenticate to that host.
[36:47.660 --> 36:51.000]  So do look at those links there if you need to do that.
[36:51.000 --> 36:55.780]  But then down here, we also have the command that you'll run. And then again,
[36:55.780 --> 37:00.320]  if you don't change the permissions on the file, you will probably have to add sudo to that
[37:00.320 --> 37:05.260]  to execute it with higher or elevated privileges.
[37:07.720 --> 37:16.720]  So I'm going to do an SSHI PIM and then the default user for the security in an image
[37:16.720 --> 37:26.100]  that's going to be onion. So we'll use onion at and then the public IP right here of the host.
[37:26.500 --> 37:35.680]  Okay, so we'll paste that in here. And we'll just hit enter. And this is my local password
[37:36.320 --> 37:54.190]  so that I can sudo. Remember it. Let's see if I fat fingered it again.
[37:56.420 --> 38:02.600]  Oh, you know what? Okay, so what we're going to do here. One more thing. I'm sorry.
[38:03.180 --> 38:07.520]  We'll need to change the security groups assigned for this interface.
[38:07.580 --> 38:13.900]  Okay, so we'll go into security groups, go back to our default security group.
[38:14.600 --> 38:20.780]  Okay, and we'll edit the inbound rules because we really only want to allow SSH
[38:22.100 --> 38:28.640]  for our IP. And so I'm just going to allow it for my external IP here.
[38:29.460 --> 38:38.380]  And then also for HTTPS when we want to access the web interface of a security ending. So
[38:40.220 --> 38:46.820]  just modify the inbound rules here for the default security group. And we'll just save that.
[38:47.640 --> 38:53.140]  Okay, so now anything that's part of that default security group will respect those
[38:53.140 --> 38:58.380]  firewall rules. So now we only have SSH and HTTPS from that external IP.
[38:59.260 --> 39:03.520]  And you'll want to do the same when you're standing ears up. So we'll do that real quick.
[39:05.220 --> 39:07.960]  And let me just do this real quick.
[39:10.040 --> 39:18.440]  And right now that we've modified that, we can just hit yes to accept here. And now we are into
[39:18.440 --> 39:24.360]  our security box. Now we we do have the security in an image and most of the stuff is installed
[39:24.360 --> 39:30.760]  already, but we still have to run setup on here. So what that means is the actual process of
[39:30.760 --> 39:36.660]  configuring all the stuff and you know, and all the packages installed on the OS. So what we'll
[39:36.660 --> 39:42.820]  do here, just some kind of administration stuff. We'll just change the host name real quick to
[39:42.820 --> 39:53.050]  something like security and in demo. And I'm just going to reflect that in Etsy host real quick.
[39:55.830 --> 40:07.060]  So we'll change Etsy host name and Etsy host. I'm going to just give the box a quick reboot.
[40:14.070 --> 40:25.280]  Let's check for any questions or anything. Okay. All right, so it's probably rebooted by now.
[40:25.860 --> 40:34.900]  Because these AWS instances are pretty fast. So SSH back in to security and in demo.
[40:35.240 --> 40:42.700]  And now what we'll do is we'll run the first phase of setup for security. And what I'm doing here
[40:42.700 --> 40:49.400]  is I'm running SS setup minimal. Now, because we're running on a box with four gigs of RAM,
[40:49.880 --> 40:55.440]  yeah, four gigs of RAM and two cores, we run the minimal setup of security in it so that we can
[40:55.440 --> 41:01.900]  still operate efficiently. You could run the full fledged version, you would have to size up probably
[41:01.900 --> 41:09.980]  to a T3 large, or maybe even a little more comfortably a T3 extra large. But SS setup
[41:09.980 --> 41:15.560]  minimal will be more than enough for our lab. And usually is more than enough for many folks as well.
[41:15.560 --> 41:21.740]  So we'll run that. It's going to ask us if we would like to proceed. We'll hit yes.
[41:23.020 --> 41:29.300]  Yes. And we're going to configure the network interfaces. And we'll just select ENS5 for our
[41:29.300 --> 41:36.260]  management interface. And we'll hit okay. And we'll want to make sure to select DHCP and let AWS
[41:36.260 --> 41:42.480]  handle all of the IP addressing and that sort of stuff. And then we'll like to configure our
[41:42.480 --> 41:48.740]  sniffing interfaces. So we'll just hit yes whenever it asks us to do so. And then we'll
[41:48.740 --> 41:53.180]  select ENS6, which is really the only other interface available at this moment. So we'll hit
[41:53.180 --> 42:00.360]  okay. And so it's just going to ask us if we're really ready. And yes, we're ready. So we'll click
[42:00.360 --> 42:05.760]  yes. But we are not ready to reboot. So hopefully you haven't gone through and hit reboot just yet.
[42:05.760 --> 42:11.880]  But if you did, then it shouldn't be too far until you're rebooted. So we'll go and edit.
[42:11.880 --> 42:15.820]  Since the network interfaces have been configured for the most part,
[42:16.420 --> 42:23.600]  an important distinction for cloud monitoring and monitoring in AWS is going to be the VXLAN
[42:24.400 --> 42:30.940]  encapsulation. And what that does is going to add 54 bytes to the MTU or to the size of the packet
[42:30.940 --> 42:37.060]  in general. So we want to accommodate for that. We want to plan for that. So we'll want to manually
[42:37.060 --> 42:44.080]  adjust our MTU of our sniffing interface. And we can do that simply by adding this MTU 1575 line
[42:44.080 --> 42:51.100]  right here. And then we'll just hit control Z to save. And then so now that we've got our MTU set
[42:51.100 --> 42:59.640]  right there, I'm just going to reboot real quick. It's on. And then once it comes back up, we should
[42:59.640 --> 43:05.220]  be able to configure our run through the next phase of setup. And I'm just going to refer to
[43:05.220 --> 43:13.080]  these instructions here to make sure that I didn't miss anything. Okay. All right. So we've SSH'd
[43:13.080 --> 43:19.300]  back into the security in an instance. And now we're ready to run the next phase of setup.
[43:19.420 --> 43:27.280]  And we'll run ss setup minimal again. And just hit yes. And yes. And it's going to ask if we
[43:27.280 --> 43:31.500]  would like to skip the network configuration. And we're going to click yes because we've already
[43:31.500 --> 43:36.540]  configured it as we want to. And we're going to go through the main configuration, selecting the
[43:36.540 --> 43:42.340]  production mode option. And then we're going to click the option for a new deployment. And hit
[43:42.340 --> 43:49.820]  okay. I'm just going to specify a username here. And what this will be is my application level user
[43:49.820 --> 43:58.320]  account for logging into things like Squirt or Kibana. And basically it's not going to be the
[43:58.320 --> 44:02.180]  same as the OS level account but a separate account that you would use for those purposes.
[44:08.100 --> 44:13.100]  Now we're going to roll with best practices here because they are the best practices. So we use
[44:13.100 --> 44:20.520]  them. I'm going to hit okay. And we're going to use the default ET open rule set here. We're going to
[44:20.520 --> 44:28.000]  click okay. And because Suricata does offer that VXLAN DCAP, we're going to select Suricata
[44:28.000 --> 44:34.760]  versus Snort right now. And we're going to hit okay. And we're going to enable the network
[44:34.760 --> 44:40.240]  sensor services because that's what we're looking for. And we're just going to go with the defaults
[44:40.240 --> 44:48.660]  here from there. Logs. Okay. And continue. And so what's going to happen, that's going to roll
[44:48.660 --> 44:54.380]  through setup. And while that's rolling through setup, we can go ahead and start prepping our
[44:54.380 --> 45:04.080]  other node that we want to monitor. So I'm just going to minimize that. And go to instances. And
[45:04.080 --> 45:09.940]  let me flip back real quick. All right. So we're going to create an instance, a Linux 2 AMI
[45:09.940 --> 45:16.020]  instance. We're going to launch right here. And another thing to remember, and what I mentioned
[45:16.020 --> 45:22.520]  earlier, is you'll want to make sure that for the traffic mirroring that you're using supported
[45:22.520 --> 45:29.300]  instances for those Nitro instances. I'm sorry, Nitro-based instances. And the T3 line of images
[45:29.300 --> 45:35.040]  is one of those, as well as I believe the T3A. So what we're going to do here, we don't have to
[45:35.040 --> 45:42.860]  select a giant image. We can still use a very, very small image. So I'm going to use a T3 micro
[45:43.400 --> 45:50.860]  right here. And then I'm going to select configure instance details. And sure, all of this good
[45:50.860 --> 45:56.700]  stuff, the network and the subnet looks okay. Everything else looks okay. And what we can do
[45:56.700 --> 46:04.000]  is we can actually just auto-assign a public IP. So if we select that, then it'll automatically
[46:04.000 --> 46:09.420]  assign an IP, since we only have a single interface. And then we'll click next add storage.
[46:09.420 --> 46:14.760]  Don't need anything else here. Add tags. And then we'll make sure that we're using the security
[46:14.760 --> 46:21.560]  group that we want to use. In this case, we can again use that default security group because
[46:21.560 --> 46:28.720]  we'll want that SSH access. While we really don't need HTTP access, in this case,
[46:28.720 --> 46:33.300]  as far as a demo, there's really no need to create another security group because there's
[46:33.300 --> 46:38.800]  not really anything running on this host as far as HTTPS. So we're just going to click review and launch.
[46:40.920 --> 46:50.000]  Okay, all right, and launch. And it's going to give us the same question about the key pair.
[46:50.360 --> 46:56.280]  So what I'm going to do here and what we can do is select the the key pair that we created
[46:56.280 --> 47:02.300]  previously. So the one that we just created was security in demo one. We're going to select that
[47:02.300 --> 47:09.200]  and click I acknowledge. And then we're going to launch instances here and go to view instances.
[47:10.200 --> 47:13.800]  Okay, so now we see it's creating it automatically assigned that public IP
[47:14.400 --> 47:19.120]  that we can then access here in just a minute. So we'll flip back over here.
[47:19.120 --> 47:22.880]  Security is still downloading a few things, still configuring a few things.
[47:24.840 --> 47:28.360]  And then you go ahead and double check here.
[47:29.140 --> 47:35.540]  Yep, okay. So while that's still going, what we can do is create our security group that's going
[47:35.540 --> 47:44.100]  to be used for the sniffing interface of security. So what we want to do is be able to allow access
[47:44.100 --> 47:49.440]  or allow traffic to be forwarded to that interface, but we don't want that interface to be able really
[47:49.440 --> 47:57.400]  to or anybody else to that interface. So we'll create a security group right here.
[47:57.400 --> 48:06.600]  Just click create security group and we'll call it security and sniffing group.
[48:07.220 --> 48:16.900]  And this is the group that dictates who can talk to security and sniffing interface.
[48:19.060 --> 48:25.320]  All right, and what we're going to do here, instead of all traffic, well I guess we can do all traffic, but
[48:26.760 --> 48:35.440]  in fact you'll want to. So you'll want to limit it to the subnet that we defined earlier, right?
[48:35.640 --> 48:39.600]  So we will only really want to accept traffic from those hosts that are forwarding that traffic.
[48:41.260 --> 48:50.780]  Only accept from internal, so that's outbound. I'm sorry, I'm not... well that'll be the same case.
[48:50.780 --> 49:01.890]  So we really only want outbound connectivity to those as well, if there's any at all. So we'll do that.
[49:11.020 --> 49:18.020]  All right, so we've created that group now and what we can do is we can associate that
[49:18.020 --> 49:25.880]  with that sniffing interface. So if we go over here to our instances again, we will... let me go ahead
[49:25.880 --> 49:35.640]  and label these so they're a little bit easier to see. Okay, all right, so this one's the security anyone?
[49:35.760 --> 49:46.460]  All right, so we'll go to eth1 and we'll go to interface id and we'll go ahead and we'll change the security groups.
[49:48.020 --> 49:54.960]  I'm going to change it to this security and sniffing security group. All right, so it no longer has
[49:54.960 --> 50:00.940]  anything that can access it from external. It needs to. It's only doing its deed as a sniffing interface.
[50:03.080 --> 50:11.340]  All right, so what we do next... let's go ahead and check. Okay, so run through the first set
[50:11.340 --> 50:15.440]  and there's just a little bit of post-configuration that it automatically runs through here for the
[50:15.440 --> 50:29.900]  security inbox. All right, so we'll let that go and then what we'll do here is open up a new terminal
[50:29.900 --> 50:41.520]  and we're going to go ahead and ssh to our Amazon Linux host while the security inbox is finishing up.
[50:41.520 --> 50:47.400]  Okay, I'm going to do the sudo ssh i
[50:49.480 --> 50:57.660]  1 and the default user for the AZ Linux box or the Amazon Linux box is going to be ec2-user
[50:58.580 --> 51:05.450]  and we'll just paste this in here and again
[51:07.010 --> 51:25.160]  prompt it locally because my sudo and if i could type oh my goodness okay all right there we go
[51:25.160 --> 51:29.000]  all right so we're in the Amazon Linux node right now over here on this screen
[51:30.060 --> 51:32.700]  okay so we got that ssh session going there
[51:34.380 --> 51:36.620]  all right so it's not quite finished here
[51:39.220 --> 51:46.280]  Okay, so we've got those two SSH connections up now. Now what we'll do is really, I guess
[51:46.280 --> 51:52.060]  what you guys have been waiting for, not the boring AWS setup, but the actual mirror traffic
[51:52.060 --> 51:58.980]  configuration. Okay, so what we'll do now is go ahead and create our mirror filter,
[51:58.980 --> 52:09.380]  our mirror target, and our mirror session. So, go over here to VPC, and traffic mirror
[52:09.380 --> 52:13.640]  filters. We'll just go ahead and create the filter first, and we're just going to name
[52:13.640 --> 52:26.420]  it security.demo, and let's call it security.demo. Alright, now we want everything in this filter,
[52:26.420 --> 52:36.720]  we want all the traffic, all the things. So we'll do a quad zero here, here, the inbound
[52:36.720 --> 52:42.260]  and the outbound, we'll do a quad zero for the source and destination, because it will
[52:42.260 --> 52:47.520]  actually filter out the inbound and outbound from the traffic it's mirroring if you're
[52:47.520 --> 52:54.620]  not careful, so that's why we're doing that here. Okay, and we'll hit close. So we've
[52:54.620 --> 52:59.340]  created our traffic mirror filter, what defines what will be forwarded to the mirror target.
[52:59.420 --> 53:06.120]  Now we'll go ahead and create that mirror target. Alright, and this is going to be the
[53:06.120 --> 53:19.540]  security.onion.sniffing demo. And what we'll do here is we'll choose the target ENI, or
[53:19.540 --> 53:23.600]  network interface. And right here, as you can see, these primary network interfaces
[53:23.600 --> 53:27.520]  aren't going to be it, those are going to be management interfaces. So we know that
[53:27.520 --> 53:36.040]  it's this one right here, otherwise we might have to go check. Alright, so we'll hit create.
[53:37.340 --> 53:43.320]  So we've created our traffic mirror filter and our traffic mirror target, so now we just
[53:43.320 --> 53:49.880]  need to associate all this with a source inside of a mirror session. And that's what we'll
[53:49.880 --> 54:04.400]  do here is our security.onion.demo.mirror.session. And our mirror source, again, is going to
[54:04.400 --> 54:09.580]  be one of these primary network interfaces. However, we don't know just yet, so we'll
[54:09.580 --> 54:14.780]  need to go over here to instances, and we'll need to go to the instance where we want to
[54:14.780 --> 54:20.540]  mirror and find that source network interface. And here it is, eth0. So we're going to click
[54:20.540 --> 54:25.920]  that, we're going to grab this interface ID and copy it so that we know for certain which
[54:25.920 --> 54:32.280]  one we want to monitor. And it's this primary network interface. And we know here our target,
[54:32.280 --> 54:37.780]  so we'll select that. And one thing that always gets me is that you'll have to enter in here,
[54:37.780 --> 54:41.860]  even though it's prepended, or pre-populated with a 1, it's not really filled out, you
[54:41.860 --> 54:48.800]  have to enter a 1 there for the session number. And then we'll hit create... I didn't add
[54:48.800 --> 54:54.120]  my filter. So we'll need to add filter here, and that's going to apply that filter, right?
[54:54.120 --> 55:01.440]  So let's create that. So we've now got our security.onion.demo.mirror.session, our traffic
[55:01.440 --> 55:07.420]  mirror session, created. So from a networking standpoint, security.onion, or at least the
[55:07.420 --> 55:14.320]  box, should be able to see all this traffic on the network interface. So let's go back
[55:14.320 --> 55:20.580]  to our SSH session. Okay. So setup is now complete. I'm just going to check the status
[55:20.580 --> 55:28.740]  and make sure everything looks good. Okay. And real quick, before we dive into any of
[55:28.740 --> 55:33.220]  the other stuff, I'm just going to check real quick with the tcpdump command to check and
[55:33.220 --> 55:39.940]  see if that traffic is coming by. I don't see anything just yet. But if we type here...
[55:41.140 --> 55:48.480]  and let's see if I can break this out into a different one. We can see now that our traffic
[55:48.480 --> 55:54.280]  is being mirrored. Right? So that's it. It's that simple to create the mirror sessions,
[55:54.280 --> 56:03.160]  right? It's a little bit of work to get the infrastructure set up. And to... I guess
[56:03.160 --> 56:06.100]  once you go through it a couple of times, it's a little bit easier to grasp, I guess.
[56:06.640 --> 56:11.780]  But it's fairly straightforward to get that set up. And now once we have that, since we're
[56:11.780 --> 56:16.980]  using security engine, and we want to see that traffic, we can actually use something
[56:17.980 --> 56:24.680]  like... where is it? Test my nids, which I was referring to earlier. And so what this
[56:24.680 --> 56:32.340]  does is it's going to execute a series of tests, callouts to this actual website, testmynids.org.
[56:32.340 --> 56:40.120]  It's going to simulate that bad activity. So if we just do this here, and there's several
[56:40.120 --> 56:46.680]  options right here, we're going to enable pure chaos and run them all, as always. And
[56:46.680 --> 56:52.500]  it looks like maybe on Amazon Linux, Netcat is not installed by default, which is fine.
[56:53.560 --> 56:59.600]  So maybe that one didn't go through, but that's fine. We can just do yum.install.netcat if
[56:59.600 --> 57:18.610]  we want. Install-y netcat. I'll just run it one more time. And just let it run through
[57:18.610 --> 57:22.430]  there. So it's just going to simulate some nice traffic for us to be able to see in security
[57:22.430 --> 57:38.050]  engine. All right, still going there. All right, I think that's probably more than enough
[57:38.050 --> 57:43.990]  for us to take a look at. So I'm going to get off of this TCB dump here, and I'm going
[57:43.990 --> 57:50.670]  to allow access locally, because even though we've run or allowed the port in the firewall
[57:50.670 --> 57:55.830]  for AWS, we have not allowed it for the local firewall. So we'll want to allow that for
[57:55.830 --> 58:04.290]  the analyst, the port 443. It's going to give us 22443 and 7734 in case you wanted to run
[58:04.290 --> 58:09.090]  the SQL client, which is... I honestly didn't mention it previously. I didn't mention all
[58:09.090 --> 58:14.610]  of the tools in security engine. But if some of you have used SQL before, you can use that
[58:14.610 --> 58:23.210]  SQL client to connect up there and view that alert data. So I'm just going to do... before
[58:23.210 --> 58:30.550]  I do this, I'm going to do who real quick. Grab this business. Okay. And you can do the
[58:30.550 --> 58:38.510]  same thing. Run who to get that IP. Just paste that in there. All right. And we'll just hit
[58:38.510 --> 58:43.230]  enter, and it's going to refresh and throw that rule in there. And then we're going to
[58:43.230 --> 58:50.710]  access the web interface of that external IP. So let's go back and get our... where
[58:51.250 --> 59:00.480]  am I going? Okay. EC2 instances. And we're going to grab the public IP of the security
[59:00.480 --> 59:13.060]  in an instance. And we're going to go over here. That's not it. If I can copy... copy
[59:13.060 --> 59:25.710]  pasta. Come on, people. All right. Copy and paste is not being happy with me today. I'll
[59:25.710 --> 59:36.990]  just copy it from over here. Copy. There we go. Okay. Okay.
[59:37.610 --> 59:41.550]  So we get here, of course, it's a self-signed certificate. Obviously, you would want to
[59:41.550 --> 59:46.350]  change this if you deploy it in your environment. But for us, it's just fine. For Catalina,
[59:46.350 --> 59:55.450]  it's annoying. So we type this is unsafe. And then here we are on the just kind of splash
[59:55.450 --> 01:00:00.190]  page for security. And there's some links here for Cyber Chef, which we include for
[01:00:00.190 --> 01:00:06.230]  data transformation. And, you know, if you've got things like encoded bits of text, compressed
[01:00:06.230 --> 01:00:12.050]  stuff, performing other types of data analysis and whatnot, it's really good for that. And
[01:00:12.050 --> 01:00:15.950]  then also Squirt, which is going to be the web equivalent of Squeal, where you view that
[01:00:15.950 --> 01:00:21.970]  IDS alert data. So I can pop in there real quick if I want to. And I'll specify that
[01:00:21.970 --> 01:00:32.200]  username and password that I created earlier. And let's see. So okay. So we don't get much
[01:00:32.200 --> 01:00:49.690]  here. But let me pivot back over to Kibana. Okay. And let's see what kind of NIDS alerts
[01:00:49.690 --> 01:00:57.150]  we got here. Hmm. Okay. So we got the return to root one. But we didn't get many others.
[01:00:57.870 --> 01:01:05.030]  I think I know why. I think it's because we didn't enable EVX and decapsulation for Cercata.
[01:01:05.030 --> 01:01:10.590]  So this is something important to note, that we do not enable this by default, just because of the
[01:01:10.590 --> 01:01:15.830]  potential overhead of having to run it and not the percentage of folks who actually don't run
[01:01:15.830 --> 01:01:22.610]  VXLAN traffic compared to on prem. So we'll want to enable that real quick in Cercata.yaml. And I
[01:01:22.610 --> 01:01:28.830]  feel like it's good for folks to be comfortable with that and know where that exists. So right
[01:01:28.830 --> 01:01:34.410]  here we see VXLAN. I'm just searching for it in here. And then we see a VXLAN enabled.
[01:01:34.910 --> 01:01:38.350]  Stanza right here. I'm just going to change this to true.
[01:01:40.960 --> 01:01:45.560]  And yes, I really want to edit it. And just to make sure that it's still there.
[01:01:46.760 --> 01:01:51.000]  Okay. So we've got VXLAN decap enabled for Cercata.
[01:01:53.280 --> 01:01:59.960]  Let's do an asonids restart, which will restart Cercata and pull in that change.
[01:02:00.160 --> 01:02:03.580]  And we're going to replay that traffic one more time and then see what we get.
[01:02:04.160 --> 01:02:09.620]  And this is kind of what I alluded to previously, is no matter if you're watching the traffic or
[01:02:09.620 --> 01:02:14.920]  recording the traffic with seeing that VXLAN traffic, it's very important to be able to have
[01:02:14.920 --> 01:02:20.520]  an IDS or a mechanism to be able to decapsulate that or unwrap that so you can actually see and
[01:02:20.520 --> 01:02:28.020]  alert on what's going on underneath. So if we run this command again,
[01:02:28.020 --> 01:02:31.240]  let it run through. And I'm going to give it a minute before we refresh.
[01:02:31.240 --> 01:02:38.160]  But we should see some more data in there. Hopefully, you know, several more NIDS alerts
[01:02:38.760 --> 01:02:42.880]  and then, you know, something that we can have a little meat towards.
[01:02:47.230 --> 01:02:51.070]  All right. So I'll give that a minute there. Okay. So it looks like it's done.
[01:02:52.110 --> 01:02:57.170]  And if we go back, it will take... it does take about 30 seconds for Elasticsearch to
[01:02:57.610 --> 01:03:04.830]  refresh its indexes. So we'll just do this. And by refresh, I mean basically making it
[01:03:04.830 --> 01:03:11.790]  available for search, even though the data is in there. And so now that we've enabled that
[01:03:11.790 --> 01:03:16.890]  VXLAN decapsulation, we're seeing a lot more. As I mentioned, it's very important that that's
[01:03:16.890 --> 01:03:22.290]  enabled when you're doing this in the cloud. So we can see all sorts of types of alerts here.
[01:03:22.290 --> 01:03:28.810]  And then if we go down here, we can see that stuff here as well. Let me see if I can put
[01:03:28.810 --> 01:03:34.490]  it down just a little bit. Right. We get an ET policy PDF with an embedded file. That's
[01:03:34.490 --> 01:03:40.470]  interesting, right? We could go investigate that. We could see what other activity was
[01:03:40.470 --> 01:03:46.650]  associated with this. So if I wanted to search for this particular IP, this destination IP,
[01:03:46.650 --> 01:03:51.250]  or how about the source IP here? This is strange, right? So maybe where it came from.
[01:03:56.190 --> 01:04:01.250]  I can click that, and what it's going to do is take me to an indicator dashboard.
[01:04:01.430 --> 01:04:07.610]  And this indicator dashboard is basically doing a search for any time this IP address was seen.
[01:04:07.610 --> 01:04:13.790]  So it's going to give me other snort alerts. So these are the Suricata alerts. To clarify,
[01:04:13.790 --> 01:04:19.530]  we just called the data type snort, just for our parsing purposes. It's just what we've done so far
[01:04:20.070 --> 01:04:25.050]  that will change in the future. And then we can see the Ebro connection records,
[01:04:25.050 --> 01:04:30.630]  or ZEKE connection records, and then the ZEKE files records. Again, we've kept the
[01:04:30.630 --> 01:04:36.590]  older naming convention for now. And then the HTTP records, right? So we also see different
[01:04:36.590 --> 01:04:44.920]  stuff that this destination IP address was associated with. And then we can see some
[01:04:44.920 --> 01:04:52.640]  other, if there were any other source destination IPs that communicated, right? And then, let's see,
[01:04:52.640 --> 01:04:57.780]  get some different MIME types here. And you can really, at least from here,
[01:04:57.780 --> 01:05:04.300]  go off in each type of these, right? If you want to filter down for, say, HTTP,
[01:05:04.300 --> 01:05:09.680]  you can scroll down here, look at these HTTP logs that we've indicated via the indicator dashboard,
[01:05:09.680 --> 01:05:16.690]  drill into those. And then, now this is important as well. In fact, I don't know many,
[01:05:16.690 --> 01:05:24.230]  even commercial solutions that can do this off the shelf is VXLAN decapsulated PCAP.
[01:05:24.970 --> 01:05:31.790]  So I will say that typically in the on-premise version, you can pivot to PCAP from here and
[01:05:31.790 --> 01:05:37.050]  see the full conversation, as I mentioned. One limitation currently with the current platform
[01:05:37.050 --> 01:05:43.390]  is that you can't necessarily pivot to PCAP, but you can enable stuff like Suricata,
[01:05:43.390 --> 01:05:49.450]  EJSON logging, and still log that packet. Or you can do other stuff with that PCAP,
[01:05:49.450 --> 01:05:54.690]  which I'll talk about in just a little bit. But again, you can see the breadth of data
[01:05:54.690 --> 01:06:01.010]  that we have here. As far as HTTP, we have MIME types, the file IDs that were basically
[01:06:01.010 --> 01:06:07.170]  Zykl pull-out identifiers for the files that it rips out of the network stream. So we can
[01:06:07.170 --> 01:06:12.070]  pivot based off of those into different types of data, and it can be very powerful.
[01:06:12.890 --> 01:06:18.790]  All right, so if we go back here again, if we just want to even get a summary of the
[01:06:18.790 --> 01:06:25.070]  connection data, so we can see all of the stuff that was even VXLAN. So if you want
[01:06:25.070 --> 01:06:31.230]  to separate out nodes that are maybe cloud nodes and maybe on-prem nodes, then you can
[01:06:31.230 --> 01:06:39.250]  kind of filter out maybe based on the VXLAN, because all of these are VXLAN encapsulated.
[01:06:39.250 --> 01:06:43.230]  So if I filter on those, well, let me actually do this.
[01:06:45.870 --> 01:06:53.250]  Let's take those out then. It's really going to be the categorized con logs and whatnot.
[01:06:53.390 --> 01:06:58.570]  So again, I mean, you can group by service. You can then, if you want to drill into,
[01:06:58.570 --> 01:07:02.550]  maybe you've got some weird SSL stuff, you know, you've got a high count here,
[01:07:02.550 --> 01:07:05.790]  then you can drill into the SSL data over here.
[01:07:05.790 --> 01:07:12.070]  All right, and then we can see the different server names that we have here, common names
[01:07:12.070 --> 01:07:17.470]  associated with the SSL, the validation status, if you want to track validation of certs,
[01:07:17.470 --> 01:07:23.770]  and maybe, you know, you see some certs that aren't valid or track expiration, stuff like that.
[01:07:23.770 --> 01:07:28.590]  There's a lot more here than, you know, just detection-oriented stuff. And, you know,
[01:07:28.690 --> 01:07:32.290]  a lot of that, even that stuff can lend its way to being detection-oriented.
[01:07:34.110 --> 01:07:38.710]  So, as you can see here on this Zeek hunting panel, there's tons and tons of data that we
[01:07:38.710 --> 01:07:45.010]  could pore over if we wanted to. We could see these query types and these response codes for DNS,
[01:07:45.970 --> 01:07:51.330]  obviously what server we reached out to, the actual queries, right? So, you know,
[01:07:51.330 --> 01:07:57.510]  hey, that's a weird query, right? So, it's pretty easy to stack this data and to see
[01:07:57.510 --> 01:08:06.440]  it and represent it in an easy-to-digest fashion. And then, again, with the HIDS alerts,
[01:08:06.440 --> 01:08:12.040]  if we had any host-based agents deployed, we would see those logs here, and we could,
[01:08:12.980 --> 01:08:18.100]  you know, drill into different details there. You can see the TCP dump that we ran locally
[01:08:18.100 --> 01:08:23.180]  earlier, and you can also see where we modified suricata.yaml. So, Suricata, I'm sorry,
[01:08:23.180 --> 01:08:30.920]  security in itself will run a local Wazoo or OSEC agent here on the box and watch everything
[01:08:30.920 --> 01:08:37.940]  that's going on its own box as well as any other agents or any other endpoints to which we deploy
[01:08:37.940 --> 01:08:46.180]  it. So, again, you know, being able to tie in, and we don't have any just at the moment,
[01:08:46.180 --> 01:08:52.560]  you can tie in autoruns data, beats data, and all that other good stuff to help augment this data.
[01:08:52.560 --> 01:08:57.300]  And, again, you know, there are things like CloudWatch, and there are these host-based
[01:08:57.300 --> 01:09:02.340]  events, but being able to have the network security monitoring component and being able
[01:09:02.340 --> 01:09:07.460]  to bridge the gap from the host to host and being able to see what's going on is super powerful,
[01:09:07.460 --> 01:09:14.400]  and in many cases can be very cost-effective compared to other solutions. So, let me just
[01:09:14.400 --> 01:09:22.900]  go back here to... let me make sure, see if I missed anything here. Okay. All right. So,
[01:09:22.900 --> 01:09:31.720]  we walked through that. Let me see. So, again, that's how you, you know, from scratch go and set
[01:09:31.720 --> 01:09:40.980]  up security in that environment in AWS, promote that traffic mirroring and whatnot. And I know
[01:09:40.980 --> 01:09:45.320]  I didn't go into a whole lot of the investigation, but I really just want to try to leave you guys
[01:09:45.320 --> 01:09:51.080]  wanting for more and exploratory there and being able to delve into a lot of that on your own
[01:09:51.080 --> 01:09:58.100]  and in your testing. But I will continue here, and what we're going to do is I'm just going to
[01:09:58.100 --> 01:10:06.340]  go ahead and terminate these real quick. Yes, terminate. I'm going to clean up the VPC here
[01:10:06.340 --> 01:10:11.700]  and then show you guys something else, which if you do have that Ubuntu host and you're able to
[01:10:11.700 --> 01:10:18.380]  have internet access, you should be able to follow along with. Let's see. Okay. So, it's
[01:10:18.380 --> 01:10:25.700]  going to take a second for those to get the story there. So, I'll go back here with the PowerPoint
[01:10:26.460 --> 01:10:34.250]  and I'll follow up on some more stuff while that's happening. So, we'll move on. I mentioned
[01:10:34.250 --> 01:10:40.510]  that supplementary data. So, if we want to bring in Azure logs, stuff from Azure Event Hubs,
[01:10:40.870 --> 01:10:47.790]  we can absolutely do that. Logstash has an Event Hubs plugin that we can use. So, we can pull all
[01:10:47.790 --> 01:10:52.370]  that telemetry, all of that data into Security Engine. If you've got multiple clouds, that can
[01:10:52.370 --> 01:10:59.170]  be a very effective solution. And what that looks like in summary is, you know, the instructions
[01:10:59.170 --> 01:11:06.250]  are here. I'm not going to go over these too much right now. I'll leave this as an exercise
[01:11:06.250 --> 01:11:12.650]  to the reader if they want to go and do that. But there is plenty of guidance on being able to do
[01:11:12.650 --> 01:11:19.250]  that and just ingest that data into Security Engine. This is kind of what it looks like,
[01:11:19.250 --> 01:11:28.790]  the configuration there. Again, once you configure that, you can pull those logs from
[01:11:28.790 --> 01:11:33.470]  Azure Event Hubs into Security Engine and then correlate that data across all of your other data
[01:11:34.010 --> 01:11:38.770]  and have, again, your cloud data and your on-prem data and whatnot all in one place
[01:11:38.770 --> 01:11:47.300]  through that single pane of glass. And this is kind of what it might look like here. So,
[01:11:47.300 --> 01:11:52.380]  we've got some stuff from Event Hub. We're just tracking administrative actions here.
[01:11:54.740 --> 01:12:00.160]  Different... looks like somebody listed some keys here in Azure. So, that might be an interesting
[01:12:00.160 --> 01:12:03.680]  event to go after. And there's tons and tons of stuff that you can glean there
[01:12:04.440 --> 01:12:12.920]  and throw in there to make that context even greater. And the same case with Google Cloud,
[01:12:12.920 --> 01:12:17.900]  which I'm not going to go over with too much right here. But you could also have things like
[01:12:17.900 --> 01:12:24.240]  VPC flow logs or audit logs sent to the cloud logging functionality, the export sync in Google
[01:12:24.240 --> 01:12:29.760]  Cloud. You could pick that up with something like PubSubBeat and have that transmitted to
[01:12:29.760 --> 01:12:37.050]  Logstash if you like. That is one option. And, again, I'm not going to go through that too much
[01:12:37.050 --> 01:12:41.210]  just right this second. It's kind of what the configuration looks like there. Fairly
[01:12:41.210 --> 01:12:47.430]  straightforward as far as PubSubBeat itself. And then once that data is in there, again,
[01:12:47.430 --> 01:12:52.550]  if you've got VPC flow logs from Google Cloud and you're not performing any other type of monitoring,
[01:12:52.550 --> 01:13:00.610]  then we can pull that stuff in. And the same thing with AWS, right? So,
[01:13:00.610 --> 01:13:05.610]  aside from traffic mirroring, we can still pull in CloudTrail, we can still pull in CloudWatch
[01:13:06.090 --> 01:13:11.170]  and throw them into S3 and have Logstash read from S3 and have those in security
[01:13:11.170 --> 01:13:17.330]  and in for that greater context. And I'm just going to skip through this.
[01:13:18.410 --> 01:13:24.630]  And so, before continuing any further, again, just again kind of harping on the idea that
[01:13:25.130 --> 01:13:30.190]  you can pretty much take any of this cloud data that you want to augment your current
[01:13:30.190 --> 01:13:34.890]  monitoring strategy with and send it to security, whether it be in the cloud or on-prem,
[01:13:34.890 --> 01:13:41.930]  and really have a powerful solution without having to buy into a bunch of commercial stuff,
[01:13:41.930 --> 01:13:48.350]  basically. So, to move along from that, I want to talk about 3CoreSec AutoMirror real quick.
[01:13:48.350 --> 01:13:56.250]  And what it is, is it's another open source tool by 3CoreSec, Tiago Faria and his folks,
[01:13:56.250 --> 01:14:02.170]  and it really allows for that quick and easy facilitation of NSM. Now, we talked about the
[01:14:02.170 --> 01:14:09.830]  mirror config, and obviously going and adding stuff to a mirror session can, if you have a ton
[01:14:09.830 --> 01:14:15.270]  of hosts and they spin up and spin down, it can be a chore and it can be difficult to manage.
[01:14:15.610 --> 01:14:23.450]  So, one of the solutions here is to use 3CoreSec AutoMirror in AWS. And what this means is that
[01:14:23.450 --> 01:14:30.850]  if we have instances tagged with mirror equals true, a mirror tag that equals true, then we can
[01:14:30.850 --> 01:14:35.970]  do that upon creation. That can be a default and a template, and then these will be added to a VPC
[01:14:35.970 --> 01:14:40.210]  mirror session for a mirror target. And what that means is that we can spin up one host, we can
[01:14:40.210 --> 01:14:44.210]  spin up another host, we can spin up another host, and these will all be added to the mirror session,
[01:14:44.210 --> 01:14:49.030]  and security on end can be watching these without having to do any additional configuration.
[01:14:49.130 --> 01:14:52.430]  It's pretty powerful and pretty awesome to be able to do something like this.
[01:14:52.710 --> 01:14:58.530]  Now, it sits as a Lambda function. Tiago has released a serverless app. The way I use it,
[01:14:58.530 --> 01:15:04.390]  I upload a Lambda function with everything required, which is the way that he used to do it.
[01:15:04.390 --> 01:15:10.130]  If you're not using security on end, you can still use that, obviously, to facilitate that.
[01:15:15.810 --> 01:15:20.150]  Another thing I want to talk about, automating the deployment is one of the things that I
[01:15:20.150 --> 01:15:23.610]  mentioned at the beginning, and something that really doesn't take too much time.
[01:15:23.810 --> 01:15:29.170]  This is where we can automate the deployment of security on end and 3CS AutoMirror so that
[01:15:29.170 --> 01:15:33.990]  we're deploying a security on end node, we're deploying maybe a Ubuntu instance
[01:15:34.710 --> 01:15:42.470]  for a lab environment or for POC. Ultimately, you could do this with a production environment.
[01:15:42.470 --> 01:15:47.430]  Although the templates here aren't necessarily suited for a production environment, you could
[01:15:47.430 --> 01:15:55.890]  tweak them to do so. Again, that's kind of what I want to walk through here and get into the
[01:15:55.890 --> 01:16:03.670]  next demo here. I will hop out of this and check on our instances. Let's go ahead and do this.
[01:16:03.990 --> 01:16:12.190]  Ta-da! Refresh. Okay, so those are gone. Now I'm just going to clean up this VPC. I really don't
[01:16:12.190 --> 01:16:18.270]  want this thing anymore. You know, it's just we want to try to automate this thing, so let's just
[01:16:18.270 --> 01:16:24.870]  delete this whole VPC. I don't need this stinking thing. All right. All right, we blew it with
[01:16:24.870 --> 01:16:33.590]  smithereens. Okay, so now we've got a fresh account, right? No VPC, nothing. Now we want
[01:16:33.590 --> 01:16:40.210]  to automate this. How do we do that? So we're going to pop over. I've got any Ubuntu 18.04
[01:16:40.210 --> 01:16:49.690]  box right here. Let me get out of this. This thing is in my way. Sorry, let me
[01:16:51.330 --> 01:16:57.470]  clear that up. Okay, so now what we're going to be utilizing here is going to be, let me go back
[01:16:57.470 --> 01:17:06.090]  real quick, this security onion cloud right here. So this page, it's in the link here in the
[01:17:06.090 --> 01:17:11.990]  document for this automated deployment. Let me go ahead and paste that in there just in case.
[01:17:14.330 --> 01:17:16.790]  And we're going to be doing it for AWS.
[01:17:18.490 --> 01:17:25.650]  So I didn't put it in there. All right, so you can go there to take a look at that,
[01:17:25.650 --> 01:17:30.430]  and you can follow along. The steps I use are going to be a little bit different. It's not
[01:17:30.430 --> 01:17:37.310]  going to be as manual. So I'll just go from there. But let me go back to my host here,
[01:17:37.310 --> 01:17:41.760]  and what I've done is I've already get cloned security onion cloud. So I would just do...
[01:17:45.070 --> 01:17:48.470]  probably should have done this from fresh. All right, so we're going to do a get clone
[01:17:48.970 --> 01:17:55.470]  security and solutions security onion cloud right here. And then once that's cloned,
[01:17:55.470 --> 01:17:59.890]  we're going to cd into it. I'm going to cd into the Terraform AWS directory.
[01:18:00.250 --> 01:18:07.210]  So we can see all this good stuff in here. And what we're going to want to do is there are a few
[01:18:07.210 --> 01:18:13.210]  variables that we need to populate. First of all, when you're first installing it, you need to run
[01:18:14.230 --> 01:18:19.390]  obviously the prep. It's going to be the prep so script. So if you just clone that,
[01:18:19.390 --> 01:18:30.970]  it's going to be prep so right here. Just do a sudo prep so and super secret password. All right,
[01:18:30.970 --> 01:18:35.350]  it's going to run through. It's going to install Terraform. It's going to install AWS CLI. It's
[01:18:35.350 --> 01:18:42.910]  going to install jq. Just because we like things pretty. It's going to install...
[01:18:45.530 --> 01:18:52.310]  know what? What else is it going to install? It's going to basically get everything prepped for the
[01:18:54.290 --> 01:18:58.970]  Terraform thing that we're going to do here. And then it's going to prompt you to configure AWS CLI.
[01:18:59.130 --> 01:19:03.830]  Now, when you configure it for the first time, you're going to get this. It's configuring AWS CLI
[01:19:03.830 --> 01:19:09.010]  and then the access key ID right here. So it's not going to show secret right here. It's going to
[01:19:09.010 --> 01:19:12.890]  just be blank and you're going to have to enter in. Let me see if I can get it right here real
[01:19:12.890 --> 01:19:21.710]  quick. You're going to have to go here to my security credentials and access keys. Expand
[01:19:21.710 --> 01:19:25.910]  that and if you don't already have an access key, you're going to create one. And there's going to
[01:19:25.910 --> 01:19:32.730]  be an access key ID, right? So once you have that access key ID, you'll paste that into the first
[01:19:32.730 --> 01:19:37.550]  prompt. Then there'll be a secret key that's included with that. You'll paste that into the
[01:19:37.550 --> 01:19:49.450]  second prompt. So this access key ID isn't necessarily like your secret key. You may still
[01:19:49.450 --> 01:19:54.870]  want to protect it, but obviously you're not going to be able to do anything without the secret key
[01:19:54.870 --> 01:20:01.410]  as well. So we'll just press enter here to keep the secret access key. And then in the region,
[01:20:01.410 --> 01:20:05.770]  you're going to want to specify one of those regions that has access to that AMI. So in our
[01:20:05.770 --> 01:20:12.290]  case, that's going to be that US-East-2. It's going to be the US-West-2, the EU-Central-1,
[01:20:12.290 --> 01:20:23.430]  and EU-West-2, I think. Sorry, I've got terrible memory. EU-West-2, yep. Let me go back. Alright,
[01:20:23.430 --> 01:20:27.730]  so I've already got this configured, so it's just going to keep the defaults. And default output
[01:20:27.730 --> 01:20:33.490]  format is none, that's fine. Okay, and I've already... it's already generated a public-private
[01:20:33.490 --> 01:20:38.610]  key pair. It's going to prompt you on your first install, and you can just hit enter for the time
[01:20:38.610 --> 01:20:43.030]  being unless you want to protect it with a password, which obviously in a production case,
[01:20:43.030 --> 01:20:48.050]  you would want to take more secure measures, but for the purposes of testing, you should be fine.
[01:20:49.250 --> 01:20:58.310]  So we're not going to overwrite this. Alright, we're just going to... it's going to prompt us
[01:20:58.310 --> 01:21:04.070]  from this stance if we would like to have any Ubuntu host also stood up that we want to monitor.
[01:21:04.190 --> 01:21:11.270]  Now, there's an option in the actual terraform.tfvars file that you can modify if you want
[01:21:11.270 --> 01:21:16.050]  this enabled or not, but this just helps you do it. So this is just less manual going in and doing
[01:21:16.050 --> 01:21:22.310]  stuff. So I'm just going to select yes, and then what it's going to do is it's going to populate
[01:21:22.310 --> 01:21:33.590]  this... terraform.tfvars. It's going to populate it with the path of the credential files, which
[01:21:33.590 --> 01:21:38.950]  should be the default that you're going to be using. It's going to already have the default
[01:21:38.950 --> 01:21:46.070]  path of the security and then key pair, and then it's going to have... where is it? The Ubuntu
[01:21:46.070 --> 01:21:51.230]  host right here. Now, this instance type and... I'm sorry, the AMI will get configured here in
[01:21:51.310 --> 01:21:57.230]  a minute. Don't worry about that just yet because that may be an old AMI that you're looking at.
[01:21:58.810 --> 01:22:04.690]  But thankfully, what we have here is a launch SO script, and what this is going to do,
[01:22:04.690 --> 01:22:10.290]  this is actually going to grab the latest AMI. It's going to substitute that in for that AMI
[01:22:10.290 --> 01:22:17.010]  in that file, and then it's also going to try to determine your public IP address,
[01:22:17.010 --> 01:22:20.870]  and if it can determine your public IP address, it's going to populate that in there as well.
[01:22:20.870 --> 01:22:26.010]  So you don't really have to touch it a whole lot. Otherwise, you can go inside of that file,
[01:22:26.010 --> 01:22:32.470]  that TFR's file, and modify it yourself. So we're going to go ahead and click sudo launch so,
[01:22:33.670 --> 01:22:37.730]  and what it's going to do, it's going to run behind the scenes a Terraform init
[01:22:37.730 --> 01:22:44.530]  to initialize Terraform in this directory. It's going to also do the things I mentioned a second
[01:22:44.530 --> 01:22:50.850]  ago, and then also a Terraform apply auto approve so that it goes ahead and runs that action.
[01:22:50.870 --> 01:22:58.290]  And now what it's doing is creating that entire VPC, it's creating the subnets, it's creating the
[01:22:58.290 --> 01:23:03.870]  security groups, it's creating the instances, the mirror config, and auto mirror lambda function,
[01:23:03.870 --> 01:23:09.430]  and it's doing all of that behind the scenes. It may take a few minutes, so you know, if you
[01:23:09.430 --> 01:23:16.750]  see it sit there for just a couple minutes, that's normal. Wes, we do have a question that came up.
[01:23:20.030 --> 01:23:26.010]  It's one dumb question. Is it possible to make it work like a host intrusion prevention system?
[01:23:26.010 --> 01:23:33.530]  If not, are there any open source projects that can do that? Yeah, yeah, so I mean you can also
[01:23:33.530 --> 01:23:40.710]  not use the nids, the sensor components at all, right? You can send up security engine and only
[01:23:40.710 --> 01:23:47.370]  enable Wazoo, or you know, if you want to point just stuff to Elastic Stack, you can do that.
[01:23:48.690 --> 01:23:54.510]  Yeah, I mean, you can absolutely do that and only use the host-based monitoring components.
[01:23:55.030 --> 01:24:08.090]  Absolutely. Okay, so let me go ahead and copy that. So now you see that we now already,
[01:24:08.090 --> 01:24:13.830]  instead of spending the time, you know, going and configuring this manually, we now already have
[01:24:13.830 --> 01:24:38.430]  these ready to go, right? And what did I do? Exit it? Hmm, what did I... I did something wrong. Let's see.
[01:24:40.540 --> 01:24:41.460]  Hmm.
[01:24:43.740 --> 01:24:46.700]  Dee dee dee dee. What am I doing?
[01:24:47.440 --> 01:24:59.810]  Let's just get that out of there. Typos. Typos galore.
[01:25:00.970 --> 01:25:10.650]  WLAM root. Hmm, okay, well that's strange. I tested this. No, all right, so let me go back here.
[01:25:10.650 --> 01:25:12.330]  Just do a...
[01:25:22.740 --> 01:25:25.180]  SSHI security. Do I have a typo?
[01:25:33.050 --> 01:25:35.950]  Okay, that's why. Okay.
[01:25:38.550 --> 01:25:45.350]  Okay, so I've actually... I must have the same public IP in here and then host. Let's see.
[01:25:47.350 --> 01:25:52.350]  Listen and host. Okay, let me take a step back real quick.
[01:25:54.590 --> 01:26:06.970]  And do a SSHI.
[01:26:11.850 --> 01:26:15.090]  Okay, so let's try this one. See if this one works.
[01:26:28.630 --> 01:26:31.750]  Okay, so something with the permission of the key. Let me...
[01:26:32.550 --> 01:26:44.210]  All right, so I think what might have happened is the script modified the permissions on the key.
[01:26:44.210 --> 01:26:45.310]  Let me see.
[01:26:55.070 --> 01:26:56.120]  Members.
[01:27:14.230 --> 01:27:16.370]  Apologies for that.
[01:27:17.850 --> 01:27:27.550]  There we go. All right, so basically, that's how it works there. And let me go ahead and get back into that Onion instance.
[01:27:31.430 --> 01:27:37.050]  Okay, so you want to make sure, apparently, that's something that wasn't as well tested with that script.
[01:27:37.050 --> 01:27:43.070]  But just ensure the permissions are correct on that key and you should be able to SSH accordingly.
[01:27:43.070 --> 01:27:45.070]  That is my bad.
[01:27:46.310 --> 01:27:50.950]  Yeah, I was trying to help folks and automate it just a little bit, but apparently it bit me just a little bit.
[01:27:52.070 --> 01:27:58.470]  All right, so onion at security, onion zero. That's going to be the security and then host, right?
[01:27:58.470 --> 01:28:04.510]  So we could go ahead, if we wanted to, just get the interface up. We really don't have to do anything else here.
[01:28:05.890 --> 01:28:08.190]  Let's do an ifconfig.
[01:28:08.970 --> 01:28:11.950]  See, all right, so ens6 is not up yet.
[01:28:11.950 --> 01:28:18.990]  So what we can do, if we just want to run setup minimal real quick, or if we just want to do, really, an ifup ens6.
[01:28:22.350 --> 01:28:22.730]  ifconfig
[01:28:27.510 --> 01:28:35.790]  validate. Okay, all right, so we'll just run through the setup minimal real quick, if I can type.
[01:28:37.270 --> 01:28:41.590]  And what we're going to do here is we're not going to go all the way through the configuration.
[01:28:41.590 --> 01:28:49.390]  We're just going to, really, just illustrating you how the auto mirror and everything else works, since we've already gone through the actual security and install.
[01:28:49.830 --> 01:28:51.230]  So I'm just going to do that here.
[01:28:52.090 --> 01:28:54.410]  Yep, we're just going to reboot real quick.
[01:28:55.870 --> 01:29:01.290]  And again, this is really just about illustrating how quickly and easily that you can stand this stuff up, right?
[01:29:01.290 --> 01:29:04.650]  So it's much quicker than the prior route that we took.
[01:29:04.950 --> 01:29:08.850]  Again, I wanted you to get the feel and get the understanding of how to build that manually,
[01:29:08.850 --> 01:29:12.630]  but it's definitely easier when we're using something like this.
[01:29:13.630 --> 01:29:18.170]  And we can see that security and zero and that Ubuntu zero instance are running.
[01:29:18.290 --> 01:29:22.150]  And then if we want to go over real quick, just to view it while we wait for the reboot,
[01:29:23.970 --> 01:29:29.530]  we can go and see that mirror session that's already created right here.
[01:29:29.570 --> 01:29:32.810]  So it's pretty neat to be able to have that kind of stuff automated.
[01:29:32.810 --> 01:29:37.570]  And you can, again, add another host and it would pop back onto that.
[01:29:37.570 --> 01:29:39.730]  It would also be mirrored as well.
[01:29:40.290 --> 01:29:43.410]  So let's modify that real quick.
[01:29:43.630 --> 01:29:45.010]  And wrong one.
[01:29:45.810 --> 01:29:48.270]  We'll SSH back in.
[01:29:49.790 --> 01:29:51.350]  And it's fine.
[01:29:54.430 --> 01:30:00.890]  Okay, so now if we do a ccpdump, you know, six.
[01:30:01.550 --> 01:30:02.970]  That will also do...
[01:30:03.490 --> 01:30:05.250]  Oops, new terminal here.
[01:30:08.890 --> 01:30:09.990]  Let's see.
[01:30:11.130 --> 01:30:17.910]  Let's do a history grep ssh.org.
[01:30:17.910 --> 01:30:21.370]  Nope, it's not the right one.
[01:30:21.590 --> 01:30:31.130]  All right, let me go back and grab that IP of the Ubuntu instance.
[01:30:31.990 --> 01:30:33.810]  All right, got that right here.
[01:30:33.810 --> 01:30:34.830]  It's this one.
[01:30:36.070 --> 01:30:39.950]  Pop back over here and do an ssh i.
[01:30:45.850 --> 01:30:48.790]  And Ubuntu is the default user for Ubuntu.
[01:30:52.590 --> 01:30:54.670]  All right, and we see that traffic's...
[01:30:55.910 --> 01:31:01.650]  And once again, you know, obviously, if we run something like testmyniz and generate a bunch of
[01:31:01.650 --> 01:31:09.700]  traffic, then we can see all that flowing as well.
[01:31:09.700 --> 01:31:17.660]  So again, I'm not going to go through really the whole investigationary component or illustration.
[01:31:17.660 --> 01:31:23.100]  But again, you can kind of see how easy it is to sand this stuff up and have it automatically
[01:31:23.100 --> 01:31:23.640]  mirrored.
[01:31:23.640 --> 01:31:31.700]  So I would definitely recommend that you check out the Terraform stuff and AutoMirror in general,
[01:31:31.700 --> 01:31:34.620]  you know, aside from even if you're not using the security engine.
[01:31:35.700 --> 01:31:38.500]  So let me go back here.
[01:31:39.820 --> 01:31:44.320]  All right, and so we're not going to do it right this second.
[01:31:44.320 --> 01:31:49.760]  But feel free, if you have some time and you want to experiment, and please do offer any
[01:31:49.760 --> 01:31:51.940]  feedback if you do try it.
[01:31:51.940 --> 01:31:55.180]  But we can also do this with Google Cloud.
[01:31:55.300 --> 01:32:02.840]  So we have on the GitHub as well, we have some usage information for Google GCP over here.
[01:32:02.840 --> 01:32:05.380]  So you can do pretty much the same thing.
[01:32:05.380 --> 01:32:10.740]  And because they use mirroring groups, you can just add a host to the group to be mirrored.
[01:32:10.740 --> 01:32:13.320]  And it's very much so like AutoMirror.
[01:32:13.320 --> 01:32:16.400]  Very nice being able to do something like that.
[01:32:17.300 --> 01:32:22.860]  So it's yet another way to quickly and easily spin up security in Google Cloud and do a very
[01:32:22.860 --> 01:32:24.200]  similar thing.
[01:32:27.410 --> 01:32:31.530]  And then last but not least, there is a tool that we have.
[01:32:31.550 --> 01:32:36.010]  I mentioned that the PCAP is not, you know, we're not able to...
[01:32:36.010 --> 01:32:41.810]  we write the PCAPs to disk, they are VXLAN encapsulated, but we just don't have the
[01:32:41.810 --> 01:32:46.450]  technology in the current platform to actually render that ASCII transcript.
[01:32:46.710 --> 01:32:51.510]  But if you would like to take the PCAP and be able to import it into other tools that
[01:32:51.510 --> 01:32:56.430]  also don't understand VXLAN encapsulation, you can use VXLAN to PCAP.
[01:32:56.890 --> 01:32:59.970]  And I'm sorry, I should play from the current slide and make that a little bit bigger for
[01:32:59.970 --> 01:33:00.670]  you guys.
[01:33:01.130 --> 01:33:05.050]  And what you can do is just run the PCAP through there and it will decapsulate it.
[01:33:05.050 --> 01:33:09.510]  It will take off that VXLAN wrapper, and then you're left with the PCAP that you would
[01:33:09.510 --> 01:33:12.970]  normally see on the wire if it was not transported by VXLAN.
[01:33:13.550 --> 01:33:19.210]  So that's another pretty cool tool to be able to use if you've got VXLAN encapsulated PCAP
[01:33:19.210 --> 01:33:22.570]  and you have tools that need to be able to parse that and pull that in.
[01:33:26.260 --> 01:33:32.260]  And then, of course, all of this stuff you can miter, miter, miter, right?
[01:33:32.400 --> 01:33:37.320]  You can absolutely use a miter attack cloud matrix with some of this stuff when you're
[01:33:37.320 --> 01:33:39.000]  pulling this stuff in, right?
[01:33:39.000 --> 01:33:46.680]  And when you're pulling in cloud trail data, when you're pulling in NSM data, you can create
[01:33:46.680 --> 01:33:49.020]  detections with Elastic Alert rules.
[01:33:49.020 --> 01:33:55.320]  You can use Sigmac from the Sigma authors to convert this to Elastic Alert rules and
[01:33:55.320 --> 01:33:59.340]  base those on those techniques and tactics, right?
[01:33:59.600 --> 01:34:03.700]  And then you can test those detections using something like Atomic Red Team, right, if
[01:34:03.700 --> 01:34:04.840]  you want to do that.
[01:34:04.840 --> 01:34:10.000]  And we've got some really exciting stuff coming up in the next release of Security
[01:34:10.000 --> 01:34:16.520]  Onion 2.0, which is in plans to be released hopefully soon.
[01:34:16.640 --> 01:34:22.840]  Right now we have an RC1 release, Candidate 1 release, of Security Onion 2.0 that you
[01:34:22.840 --> 01:34:26.500]  can go check out by following that link at the bottom.
[01:34:26.580 --> 01:34:30.300]  And it does include that Sigma stuff and Playbook.
[01:34:30.860 --> 01:34:37.220]  Playbook is going to be basically taking the Sigma rules and converting them to Elastic
[01:34:37.220 --> 01:34:38.200]  Alert rules.
[01:34:38.200 --> 01:34:39.740]  It includes OS Query.
[01:34:39.740 --> 01:34:41.690]  I know you mentioned host-based monitoring.
[01:34:42.040 --> 01:34:45.840]  That's going to be another addition to the host-based monitoring that we have.
[01:34:45.840 --> 01:34:48.760]  And also the Hive and Cortex, right?
[01:34:48.820 --> 01:34:56.880]  Being able to go in there and have those events fire from the Sigma rules and then have them
[01:34:56.880 --> 01:34:59.000]  in an investigationary stance.
[01:34:59.000 --> 01:35:04.980]  Have them ready to go in the Hive and creating cases and working those observables and whatnot.
[01:35:04.980 --> 01:35:07.060]  It's just going to be really good stuff.
[01:35:07.060 --> 01:35:09.120]  So please do check that out.
[01:35:09.120 --> 01:35:12.540]  I would have loved to have demoed that for you today.
[01:35:12.660 --> 01:35:18.100]  Unfortunately, we don't have a public 2.0 AMI out just yet.
[01:35:18.440 --> 01:35:26.240]  But definitely do keep in touch and keep looking and we will have something ready for you soon.
[01:35:26.240 --> 01:35:29.800]  And then if you want to download, obviously, the current platform on Security On-End,
[01:35:30.600 --> 01:35:33.420]  you can download it from securityonend.net.
[01:35:33.720 --> 01:35:36.520]  And, you know, absolutely free, open source.
[01:35:36.640 --> 01:35:39.920]  We have a great community, great mailing list on there.
[01:35:40.800 --> 01:35:44.200]  And, you know, hopefully some decent documentation.
[01:35:44.480 --> 01:35:50.260]  And then if you're already using Security On-End or you really want more help figuring out how
[01:35:50.260 --> 01:35:55.440]  to set it up in the cloud or you want training or support, then we have professional services
[01:35:55.440 --> 01:35:57.460]  available for that as well if you need that.
[01:35:57.460 --> 01:36:04.320]  But anything else, if you have any other questions or feedback, anything else,
[01:36:04.320 --> 01:36:11.200]  just feel free to reach out to me at the real W. Lambert on Twitter.
[01:36:11.220 --> 01:36:15.460]  Or feel free to hit securityonend on there and just let us know what you're thinking.
[01:36:15.720 --> 01:36:17.300]  And we'd be glad to help out.
[01:36:17.300 --> 01:36:19.980]  And hopefully you got something useful today.