WEBVTT

00:00.580 --> 00:22.740
So today, I really wanted to focus on kind of an introductory level explanation of, you know, some of the stuff that we see in the cloud and, you know, of course, how a lot of things are moving to the cloud these days, just security onion in general, and how we might be able to leverage security in the cloud to monitor our cloud infrastructure.

00:23.120 --> 00:42.000
And then also, maybe a couple ways that, you know, through a stance of academia or standing up a POC proof of concept or whatnot, how we can automate that and automate our testing and maybe automate the deployment of security in the cloud.

00:42.220 --> 00:47.460
So most of this will be focused on AWS, since it is one of the largest cloud providers.

00:47.500 --> 00:53.840
Although we will have some resources to share for other cloud providers, and we'll be going through some of that stuff there.

00:53.840 --> 00:57.860
So without further ado, I will go ahead and get started.

00:57.900 --> 00:59.740
A little bit about me.

00:59.740 --> 01:06.840
I have four kids, married, of course, and definitely love every minute of it.

01:07.360 --> 01:12.920
I, as I mentioned, work for Security Onion Solutions, where we develop and maintain Security Onion.

01:13.060 --> 01:17.340
And we also provide professional services and training for Security Onion.

01:17.500 --> 01:24.700
And it's really all about that open source platform and getting folks better visibility into their network.

01:24.900 --> 01:26.720
So let me go ahead and get started.

01:27.140 --> 01:42.840
Talking about the agenda today, we're going to go through the cloud in general, some of the stuff that we find all over the place in different clouds, whether it be AWS, Azure, GCP, Google Cloud Platform.

01:42.880 --> 01:53.600
And then also, again, introducing Security Onion, what it is, how it can help us, and then introducing, again, Security Onion in the cloud, and then automating that deployment.

01:56.850 --> 02:11.470
So when we talk about the cloud, and we talk about all the assets and all the data that we really house there, and that potentials or other folks could potentially access, some of those are as follows.

02:11.470 --> 02:17.070
For AWS, it's going to be things like S3 buckets, which we might have seen in the news recently.

02:17.070 --> 02:25.210
A lot of leaky buckets, a lot of unsecured S3 buckets having public read or maybe even write access to them.

02:25.670 --> 02:35.090
So there's definitely some attack surface there with that kind of stuff, as well as DynamoDB and some other production data storage in AWS.

02:35.290 --> 02:42.770
Again, with Azure, it's blob storage, or maybe even event hubs, where our data might be stored, or logs, or whatnot.

02:43.070 --> 02:47.450
So that's another thing to keep a look for in Azure.

02:47.770 --> 03:04.670
And then in Google Cloud Platform, obviously, like S3, we have storage buckets, cloud data stores and file stores that we want to keep an eye on, and lots of juicy stuff for attackers that they may be trying to find this stuff, publicly accessible from the internet,

03:04.670 --> 03:14.470
or they're able to get past, slip past our initial defenses and easily get to the stuff, or maybe even not easily get this stuff, we definitely want to know.

03:15.050 --> 03:19.690
And then of course, we have the application or the network traffic itself, right?

03:19.690 --> 03:26.250
So we have all this this traffic and this data flowing across from these different instances, from these different segments in the cloud.

03:26.570 --> 03:30.030
And we definitely would love to know what's going on.

03:30.030 --> 03:33.270
And it definitely can help others to know what's going on, such as an attacker.

03:33.270 --> 03:43.310
So we just want to be mindful of these things whenever we're doing business in the cloud, running all these critical operations and whatnot, just being aware of that.

03:44.130 --> 03:57.210
Now, an example of that stuff being abused in the case of AWS, there are various tools that, you know, attackers or just security researchers use in general to try to find these items.

03:57.210 --> 04:08.170
It might be S3 scanner to scan for open S3 buckets, or maybe AWS bucket dump to try to get the stuff where we could enumerate buckets, look for interesting, juicy tidbits of data.

04:09.330 --> 04:11.430
So there are lots, there are no shortage.

04:11.650 --> 04:17.950
And, you know, every day, again, there are more leaks and more tools being released to try to find this type of stuff.

04:17.950 --> 04:25.990
So it's becoming easier and easier for the attacker to get in and get this data if we're not careful about our environments.

04:29.980 --> 04:33.540
Similarly with Azure, there's microburst, right?

04:33.540 --> 04:43.400
So we could look for different services in Azure that might be enabled, weak configuration, or maybe even try to identify post-exploitation actions, right?

04:44.160 --> 04:46.720
So, again, these tools, there's no shortage.

04:46.720 --> 04:49.060
Definitely have to keep an eye on this stuff.

04:50.520 --> 04:52.680
And then, again, with GCP.

04:52.940 --> 05:00.960
So GCP, there's a mechanism, GCP bucket brute, similar to the others, where we can enumerate Google Cloud storage buckets.

05:00.960 --> 05:07.000
We can determine access levels, privileges, see if we can get privask, privilege escalation there.

05:07.120 --> 05:09.140
Lots of ways that we can do that there.

05:12.140 --> 05:15.020
And then also the cloud credentials.

05:15.140 --> 05:22.380
It's really going to be another thing where it's not even the data itself, but something that brokers access to the data, right?

05:22.380 --> 05:28.960
If account passwords, IM, or root account credentials are able to be phished from people, of course, that's no good.

05:28.960 --> 05:35.560
And, again, it's the weakest link, which is, you know, very commonly the human in this case.

05:35.560 --> 05:44.020
And, you know, with these access keys or these credentials, that means that attackers could control access to AWS servers without a username and password, right?

05:44.020 --> 05:47.760
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:04.410
And then, again, with the privilege escalation with regard to cloud credentials, folks can create new policy versions, right?

06:04.410 --> 06:07.270
They can create new keys off of those keys.

06:07.270 --> 06:21.430
So even if you delete the old keys that were compromised, if you're not deleting new keys that were created by them, or you're not monitoring that, it's very difficult to get, you know, those attackers out of your network, or it just poses yet another concern and another question,

06:21.430 --> 06:22.110
right?

06:22.370 --> 06:39.490
Even adding malicious Lambda layers to existing Lambda functions, it's one thing that attackers can do, and Rhino Security Labs actually demonstrated it's pretty cool, actually, basically modifying existing Lambda functions to act as you would not expect,

06:39.490 --> 06:43.250
and it's a great way to hide stuff like that without being super obvious.

06:46.000 --> 06:55.860
So we've talked about that stuff, and I've gone through that rather quickly, but I think as far as a cloud village, I think some of us are aware of these threats, of course.

06:56.100 --> 07:01.380
So now I want to talk a little bit about monitoring challenges, right?

07:01.380 --> 07:03.260
So monitoring in the cloud.

07:03.620 --> 07:18.780
Now with NSM, or network security monitoring, which is really a core component of security engine, where we're monitoring that network data, we're monitoring that traffic that goes from endpoint to endpoint, there can be some challenges in the cloud, and there are ways to get around them,

07:18.780 --> 07:22.400
but to talk about a couple, VXLAN encapsulation.

07:22.520 --> 07:37.360
So even if we are able to capture the traffic in the cloud, typically if we don't have the right applications, if we can't decapsulate that, or understand what it means, or alert on it, then it's not as much value to us.

07:37.360 --> 07:47.140
So it makes it more difficult, you know, to interpret that data, or to use that data in analytics, or reporting, or alerting, and that can be difficult.

07:47.140 --> 07:48.200
That can be a challenge.

07:48.800 --> 07:50.920
Another one would be segmentation.

07:51.160 --> 07:59.440
Maybe you have certain segmentation in your clouds where you're not able to easily tie together a monitoring solution.

07:59.820 --> 08:10.480
I'm not saying security engine is it, and they'll be all for that, or anything else, but that's just a general challenge overall that sometimes it's just difficult to overcome.

08:11.260 --> 08:13.460
Then again, ephemerality.

08:13.640 --> 08:19.180
So we talk about instances spinning up and down a lot of times in cloud environments.

08:19.180 --> 08:21.480
You may have a variable number of instances.

08:21.960 --> 08:37.340
They may be there one minute, they may be gone another minute, and one of the challenges with monitoring that is how do you tell something, right, to monitor this host, or to monitor the activity of this host when it spins up, and then it just goes away?

08:37.340 --> 08:40.300
How do we tell, you know, to monitor the next host and the next host?

08:40.540 --> 08:44.480
How can we group these together and create an effective solution?

08:45.360 --> 08:53.980
And in some cases, there really is no native or no great mechanism for monitoring in the cloud, and it just, again, makes it even more difficult.

08:55.220 --> 08:57.240
But there are ways around it.

08:57.240 --> 08:58.920
Sometimes they don't scale that well.

08:59.300 --> 09:01.160
Well, a lot of times they don't scale that well.

09:01.220 --> 09:03.780
So it's always best if there is a native solution.

09:04.060 --> 09:07.820
And again, there are commercial solutions available for monitoring.

09:07.820 --> 09:17.800
A lot of times these are highly specialized, highly integrated with specific feature sets and specific products, so they can be very expensive.

09:18.660 --> 09:26.560
And a lot of folks may not be able to afford something like that, especially small to medium-sized businesses that are trying to run their workloads in the cloud.

09:30.790 --> 09:34.190
So enter the onion.

09:34.190 --> 09:36.390
Just making sure that wasn't from you guys.

09:36.530 --> 09:37.590
Enter the onion, right?

09:37.590 --> 09:38.590
Security onion.

09:38.590 --> 09:40.390
We're going to talk a little bit about here.

09:40.830 --> 09:43.210
So what is security in general?

09:43.690 --> 09:44.890
A little introduction.

09:44.890 --> 09:47.610
It was created by Doug Burks in 2008.

09:47.790 --> 10:07.150
Doug was really scratching the need or the itch to create an all-in-one solution, a click, click, or a click, click, finish solution as far as rolling your own IDS and doing all this alerting and this analyst activity.

10:07.650 --> 10:27.570
Back during 2007, 2008, there really weren't a lot of great solutions tied together to enable somebody to have this effective monitoring platform and not have to know all these ins and outs, not having to compile ZEKE, not having to compile Cercata, PFRing,

10:27.570 --> 10:28.930
NetSniffNG and all this stuff.

10:28.930 --> 10:35.210
You had to know a lot of stuff, a lot of that core technology to be able to even get in the game.

10:35.530 --> 10:37.570
And it takes a lot of time to spin up.

10:37.950 --> 10:47.430
So a lot of the reasoning behind this is that we want this platform that's easy to install, easy to set up, and we're getting folks monitoring in minutes.

10:47.570 --> 10:49.150
And it's free.

10:49.150 --> 10:50.170
It's open source.

10:50.510 --> 11:03.570
Again, those small businesses, those medium-sized businesses can easily adopt this and be able to tip the scale in favor of the blue team maybe, just a little bit more to that side and be able to identify what's going on in the network.

11:04.330 --> 11:08.890
So security in itself can be installed from an ISO image.

11:08.890 --> 11:11.410
We provide one on our site.

11:11.470 --> 11:15.670
And then also it can be installed from packages on top of Ubuntu 16.04.

11:16.190 --> 11:19.850
And again, all this takes a very little amount of time.

11:19.990 --> 11:26.670
Obviously, the ISO image is going to be faster, but you can install it on your Ubuntu flavor of choice.

11:27.790 --> 11:35.350
So like many IDSs and network security monitoring platforms, Security Engine is traditionally fed data from a TAP or a SPAN port.

11:35.410 --> 11:41.530
We have had folks use ERSPAN, GRE tunnels, that sort of thing.

11:41.530 --> 11:46.790
It's not recommended, and it's not really supported, but there are other methods of getting that traffic to it.

11:47.790 --> 11:54.390
And now we do integrate with the Elastic Stack for the data enrichment, indexing, and visualization components.

11:54.390 --> 12:02.850
So it gives you all that rich, being able to create data tables and be able to create visualizations and really get an idea of what's going on in your network.

12:02.850 --> 12:04.670
It makes it really, really easy.

12:07.600 --> 12:09.520
And here's just a quick screenshot.

12:09.520 --> 12:16.800
It's not the most exciting screenshot, but it does give you an overview into the overview dashboard itself in Security Engine.

12:16.800 --> 12:18.520
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:27.580
Some sensors that we've got connected right now, in this case just one.

12:28.040 --> 12:33.180
And then the number of devices connected, which would be the management node and the sensor itself.

12:37.080 --> 12:38.780
Let me just click here.

12:40.900 --> 12:45.600
And again, just some more, you know, just kind of scrolling down that overview dashboard.

12:45.600 --> 12:49.420
And 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:53.500
And again, just grouping on those sensors and those protocols.

12:53.520 --> 12:56.000
And then you also see some NIDS alerts down here.

12:59.390 --> 13:12.070
So talking about some of that data that we get, a lot of folks traditionally, when they've been exposed to an IDS or a network-based intrusion detection system, 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:18.690
Let me see if I can do it without clicking.

13:18.690 --> 13:20.350
Oh, let me go back.

13:20.430 --> 13:21.290
Sorry about that.

13:21.290 --> 13:25.750
So the panmunix right here, this is just a Wazoo alert for the user W.

13:25.750 --> 13:28.370
Lambert that occurred locally on a system.

13:28.470 --> 13:35.290
So Wazoo is a host-based intrusion detection system that we include in Security Engine that can generate that alert data.

13:35.310 --> 13:40.170
And not even just alerts, but other types of activity generated on the host itself.

13:40.850 --> 13:49.790
And then we have down below alert data, similar to what you would find from Suricata, going to be generated down here.

13:49.790 --> 13:56.050
So we've got both of those types of alert data there, the host and the network-based intrusion detection system alerts.

13:56.170 --> 14:03.570
And it gives 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:16.160
And this data is going to be recorded by Zeek, formerly known as Bro.

14:16.160 --> 14:18.360
You might have some Bro fans in here.

14:18.460 --> 14:28.500
And this metadata is going to give us a lot of detail around specific protocols and transport mechanisms that we see in our environment.

14:28.640 --> 14:35.160
For example, DNS, HTTP, SSL, there's tons of different protocol parsers for Zeek.

14:35.460 --> 14:38.820
And it gives us just a lot of great detail about those, right?

14:38.820 --> 14:46.740
Like URIs, user agents, queries, the query codes, whatnot.

14:46.740 --> 14:51.840
Just tons and tons of different stuff that you might have associated with each different type of transaction.

14:53.740 --> 14:58.680
And then the full content data is another thing that Security Engine provides.

14:58.680 --> 15:00.840
And this is going to be commonly known as PCAP.

15:01.100 --> 15:09.240
So we can render an ASCII transcript of that PCAP based on whatever items that you're looking at in Security Engine.

15:09.260 --> 15:23.980
So if you want to go from an event in Kibana to the PCAP and see the actual raw communication, typically if it's not encrypted or whatnot, or if it's not some unsupported protocol, then you should be able to see that activity.

15:23.980 --> 15:32.140
And it helps to really verify what you think is going on and the other things that you're seeing in the environment.

15:32.920 --> 15:39.340
So again, it offers that complete picture or that complete transcript of what is going on.

15:44.420 --> 15:48.360
Now, you can feed supplementary data to Security Engine.

15:48.360 --> 16:00.660
So we have the HIDS data, the NIDS data, we have all of this network metadata and stuff generated by Zeek, we have PCAP, and then we have other stuff like Beats, right?

16:00.660 --> 16:08.640
So using FileBeat, we could pick up DNS debug logs, we could pick up specific application logs and send those off to Security Engine.

16:08.660 --> 16:12.760
We could pick up Windows event logs and send those off with Sysmon and whatnot.

16:12.860 --> 16:15.020
We could even use PacketBeat and send that stuff.

16:15.020 --> 16:29.680
So if we have a segment where we're monitoring hosts, and some people do this in the cloud, but whenever you can avoid it, I would probably recommend it, you can use PacketBeat to have it on those isolated hosts.

16:29.680 --> 16:46.660
If you have a host that's on its own dedicated network and you're not allowed to monitor that segment traditionally, maybe if you have that pinhole in the firewall or whatnot, to install PacketBeat and send that data back, you at least have some better visibility into what's going on in the box,

16:46.660 --> 16:51.720
as well as a host-based agent and whatnot.

16:52.400 --> 17:03.520
And then there's stuff like S3 and Azure event hubs that Logstash affords us, and even FileBeat these days, that we can send data from those storage facilities and even Syslog.

17:06.840 --> 17:08.760
And that's great and all, right?

17:08.800 --> 17:18.220
It's great that Security Engine offers that stuff, and I haven't really gone into a lot of detail so far, but how can it help us when we're in a cloud environment, and how might we set that up?

17:18.220 --> 17:20.040
Or what might that look like?

17:20.040 --> 17:22.260
What does the infrastructure look like?

17:22.660 --> 17:25.180
You know, maybe with AWS or something similar.

17:27.680 --> 17:30.820
So that brings me to traffic mirroring.

17:30.840 --> 17:44.380
When we talk about traffic mirroring, I'm talking mainly here with regard to AWS, because that is the actual naming of their mirroring facility in AWS.

17:44.600 --> 17:47.380
And we can take advantage of that with Security Engine.

17:47.900 --> 17:57.700
We can basically use this architecture to collect this traffic from these hosts and then forward it off to our Security Engine instance.

17:58.020 --> 18:12.240
So we can set up a mirror target, which is going to be our Security Engine instance or a sniffing interface, and we can set up our mirror filter, which is going to filter any traffic that we want to go to that target.

18:12.340 --> 18:25.720
For example, if we don't want certain traffic, if we don't want DHCP or some other type of traffic to be sent to our Security Engine instance, we can filter that out with our mirror filter.

18:26.140 --> 18:31.640
And then we'll set up our sources, which will feed through that mirror filter into that mirror target.

18:32.020 --> 18:36.180
And all of this encompasses a mirror session, really.

18:36.180 --> 18:39.300
So that's what a mirror session is comprised of.

18:39.800 --> 18:45.760
And that is really the pretty basic concepts of the AWS Traffic Mirroring.

18:49.290 --> 19:00.650
Again, that traffic mirror target is going to be where we define the target interface, our Security Engine instance in this case, where we want to send our mirrored traffic that we're collecting from our hosts.

19:02.170 --> 19:09.750
And then we have that filter, which is going to filter out 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:19.010
Let's check this real quick.

19:19.270 --> 19:20.450
Okay, no questions.

19:21.710 --> 19:22.590
All right.

19:23.030 --> 19:26.050
So let me get back to this.

19:26.050 --> 19:26.350
All right.

19:26.350 --> 19:27.770
So the mirror session, then.

19:27.850 --> 19:30.050
You can see here we've got a screenshot right here.

19:30.050 --> 19:32.790
The name is just Security Engine demo session.

19:32.990 --> 19:37.870
And then, again, the source and the target, which is our Security Engine instance.

19:39.810 --> 19:42.490
And there's another way we could approach this.

19:42.650 --> 19:58.370
So maybe instead of just setting up a standalone instance of Security Engine, if we just want to have our Security Engine forward node, which is going to be our sensor only and our distributed deployment, we can have just that in AWS.

19:58.610 --> 20:08.130
So typically, I don't think I went through this, but our architecture would suggest in a distributed fashion that you have a master or manager node, and then you have this forward node.

20:09.050 --> 20:13.210
And then you have a storage node, which is going to store most of your elastic data.

20:13.670 --> 20:18.950
So what's going to happen in this case is you're going to send your forward node, or you're going to have it in AWS.

20:18.950 --> 20:21.830
It's going to be collecting that traffic from the mirror session.

20:21.990 --> 20:24.610
And then your master server is going to be connected up to that.

20:24.610 --> 20:27.130
So you could have an on-premise master server.

20:27.130 --> 20:30.770
You don't necessarily have to deploy all of Security Engine in the cloud.

20:31.210 --> 20:35.150
You could have another on-premises forward node, right?

20:35.150 --> 20:45.630
You can have all of these different types of devices on your local network and have maybe open VPN or direct VPN access to the cloud and having that one security in an instance if you need it.

20:45.730 --> 20:49.370
So it's very flexible how we can architect these deployments.

20:49.430 --> 20:57.850
And I think it makes it very powerful overall for us to be able to have that comprehensive view for both our local and our cloud networks.

21:01.320 --> 21:10.520
And this right here is just an example of some of the VXLAN traffic that would come across during a typical mirror session.

21:10.660 --> 21:17.340
So all of this mirror traffic is going to be encapsulated, as I mentioned, in that VXLAN tunnel.

21:18.060 --> 21:24.920
So this basically, for applications that can't read it, of course, as I mentioned, creates a little bit of a challenge.

21:24.920 --> 21:28.960
But in our case, Zeek and Suricata can both decapsulate this data.

21:29.420 --> 21:36.180
So this is what this looks like just coming across the wire on a box right here in AWS.

21:39.990 --> 21:43.590
Again, just a shot of some cloud node stuff.

21:43.590 --> 21:48.310
If we were going to set up security as a cloud node and have the rest of it on premise.

21:52.580 --> 22:00.040
And as I mentioned before, Suricata 4.1.5 and up, which of course now we distribute a version higher.

22:00.040 --> 22:05.520
I can't remember the exact version off the top of my head, but we can decapsulate VXLAN now.

22:06.000 --> 22:11.680
And VPC mirroring is capable with only these Nitro-based instances.

22:11.680 --> 22:18.680
And I've got some documentation down there at the bottom with regard to those EC2 Nitro instances.

22:18.760 --> 22:30.240
So you'll want to make sure if you're monitoring stuff or if you've not even deployed yet, and if it's feasible cost-wise, that you're deploying on these supported instances so that we can take advantage of that.

22:33.160 --> 22:40.160
And then again, there are other considerations as far as mirror sources and destinations.

22:40.160 --> 22:47.860
There are overall limits to the number of sources, so please do check out that link down there if you do plan on standing this up in production.

22:48.380 --> 22:53.160
Just testing in a lab environment, you're never going to really exceed the limits here.

22:53.160 --> 23:04.180
But architecturally, there are some considerations that you'll want to have, maybe using a NLB or a network load balancer versus individual hosts and whatnot.

23:04.180 --> 23:09.260
So that's just something to think about there when you're going through and planning your deployment.

23:14.460 --> 23:20.800
All right, and before we get started here, I also want to talk about TMNIDS real quick.

23:20.800 --> 23:27.380
So TMNIDS is an open source project written by Tiago Faria and ThreeCorsec.

23:27.380 --> 23:35.620
So they've been doing a bunch of great work with NSM lately, specifically NSM in the cloud.

23:36.940 --> 23:50.640
And what this is, TMNIDS is an open source script that will allow you to, if you're familiar with NIDS, testing your IDS using TestMyIDS.

23:51.180 --> 24:09.900
So it's a very... folks like me that have been doing it for a little while, there's a site called TestMyIDS, and you would curl that and you would get the UID root, and that would send you a little IDS alert as long as that rule was enabled and make sure that your IDS is A-OK and that it's working as intended.

24:10.100 --> 24:12.160
And this serves a similar purpose.

24:12.480 --> 24:23.020
This is a little bit more modern day, I think, and of course you could extend it if you wanted to, but you can see here the different choices of alerts that you would like to trigger.

24:23.020 --> 24:34.360
So you have a few different options here to try and see, generate some data, generate some alerts, to see if that IDS is working, and to really just generate some interesting lab data.

24:34.660 --> 24:46.060
Now, all of this traffic right here is not actually malicious, just simulating the maliciousness, so please don't be afraid to run it.

24:46.380 --> 24:56.300
I know Tiago very well, and he would not... I don't think he would do anything like that, so... All right.

24:56.300 --> 24:59.380
So now, I know we've been talking a lot.

24:59.380 --> 25:05.120
I've been speaking to the joy of security and how it might help us.

25:06.040 --> 25:17.440
And now, I want to go through just setting it up from scratch in AWS, and hopefully you guys can follow along if you have an AWS account and you've seen the resources that we have here.

25:17.620 --> 25:20.940
Let me just get out of here, out of presentation mode.

25:25.500 --> 25:34.440
So we do have these resources here that should have been in the talk description or the workshop description.

25:35.280 --> 25:41.060
And if you scroll down here to follow along, I not long ago posted a document.

25:41.380 --> 25:45.700
And this will really be just a text-based version of the instruction here.

25:45.700 --> 25:50.360
And if you can, if you would like to, please do follow along.

25:50.700 --> 26:01.800
It is not the most verbose, but hopefully it captures everything that we need to do here, and I myself will likely be referring to it as we go through, just to make sure I don't miss anything.

26:02.400 --> 26:10.060
So please do let me know if you have any questions or something seems amiss, and we can definitely get that taken care of.

26:10.960 --> 26:16.920
So without further ado, I will begin to go into AWS here.

26:16.920 --> 26:18.980
Let me just go ahead and refresh.

26:19.640 --> 26:27.560
And what we're going to do here is we're going to stand up a security and an instance from our community AMI here.

26:27.580 --> 26:36.680
And we're also going to stand up another instance that we're going to be monitoring with the VPC, sorry, or the traffic mirroring.

26:36.820 --> 26:42.080
So we're going to get through from 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:52.680
But I do want to get started from scratch, just getting you guys used to all of these mechanisms, all these different concepts, and maybe nailing them down a little bit more easily.

26:53.760 --> 26:55.880
Okay, so I'm in AWS here.

26:55.900 --> 26:59.740
I want to launch the security and an instance from the AMI.

27:00.200 --> 27:10.620
So a quick note, real quick too, if you guys do have trouble, I know this might be a deal breaker for some of you guys, there are images.

27:10.660 --> 27:20.720
So if you're looking and you don't see the image, there are images in EU Central 1, EU West 2, US East 2, and US West 1.

27:21.660 --> 27:31.780
I won't be able to update that on the fly right now, but if you do still want to try it and you're in another region, please feel free to reach out after the workshop and I can definitely help you out there.

27:32.340 --> 27:34.480
So we've got these four in these four regions.

27:34.480 --> 27:38.400
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:49.480
And come on, click launch instance.

27:49.700 --> 27:52.200
And I'm going to search for security onion.

27:55.180 --> 27:58.360
Right now, don't be fooled, you may see one in the marketplace here.

27:58.360 --> 28:04.400
We don't actually charge for our image here, and I don't believe we plan on doing that in the future.

28:04.940 --> 28:08.540
You'll see one here, it's by BL King Consulting.

28:08.540 --> 28:10.060
Do not use this one.

28:10.180 --> 28:11.040
Do not.

28:11.280 --> 28:23.800
This one, first of all, is based on 1404, which is several iterations behind what we're on now, and it is not supported nor endorsed by us, so please do not use that one.

28:24.580 --> 28:28.800
The one we will be using is this security onion 1604 right here.

28:28.800 --> 28:31.700
The official AMI provided by Security Onion Solutions.

28:31.760 --> 28:40.040
So we're going to select this, and the smallest you probably want to go on this is going to be a T3 medium.

28:40.040 --> 28:42.680
Now, this is going to be a little bit of a charge.

28:42.680 --> 28:44.400
I mentioned this in the documentation.

28:44.660 --> 28:46.220
It's not really much at all.

28:46.220 --> 28:56.240
It's a few cents an hour to run this box itself, so it's not much, but just a heads up there that it's not completely free.

28:57.600 --> 29:00.520
And again, this is not really for Security Onion itself.

29:00.520 --> 29:03.580
This is just really the infrastructure that's running Security Onion.

29:04.580 --> 29:10.440
So we're going to choose T3 medium for Security Onion, and we're going to configure instance details.

29:10.820 --> 29:11.680
Oh, you know what?

29:11.680 --> 29:12.960
I skipped a step.

29:13.340 --> 29:15.200
All right, so let's go back.

29:16.340 --> 29:19.160
See, I should have been reading my own documentation.

29:19.520 --> 29:25.780
All right, we'll get a VPC because first of all, we need a VPC to put all this together, right?

29:25.780 --> 29:35.240
So we're going to launch the VPC wizard, and for the sake of ease for this workshop, we're going to choose a VPC with a single public subnet.

29:35.360 --> 29:38.440
Now, if you're doing this in production, you probably don't want to do this.

29:38.440 --> 29:45.380
You'll probably want something behind a VPN using OpenVPN or Direct Connect or something like that.

29:45.460 --> 29:52.320
But for purposes of our testing and whatnot, and because we're whitelisting by IP, it'll be just fine using this.

29:53.200 --> 30:01.120
So what we're going to do here, we're going to specify the CIDR block for the VPC and then for the public subnet.

30:01.400 --> 30:10.900
Now, if we go to the docs here, we're going to choose the default 10 WACC for the entire VPC.

30:11.020 --> 30:17.680
But in case you wanted to add something later, we're just going to specify the 10 110 for the public subnet.

30:18.540 --> 30:20.880
So that's what I'm going to do here.

30:21.880 --> 30:23.920
10 110.

30:25.000 --> 30:28.180
So if you want to go play with it, you could add other subnets later.

30:28.180 --> 30:30.380
We just want to narrow the scope on this one a bit.

30:30.780 --> 30:32.920
All right, so we're just keeping the name public subnet.

30:34.460 --> 30:35.420
Sorry.

30:38.610 --> 30:39.610
There we go.

30:39.610 --> 30:40.970
So we'll keep it like this.

30:41.250 --> 30:47.970
And then we'll go with the default public subnet name right here.

30:48.130 --> 30:50.410
And then we'll click create VPC.

30:51.810 --> 30:53.810
And I forget to name it.

30:57.850 --> 30:58.770
Okay .

30:58.770 --> 31:00.510
So let's go to my VPCs.

31:01.410 --> 31:04.310
And I'm just going to give it a name here because I failed to do that.

31:04.310 --> 31:09.630
Because once again, not following my own directions.

31:10.050 --> 31:13.410
So I'm going to call this VPC security onion demo.

31:13.870 --> 31:16.930
And right here we can see that one VPC is available.

31:18.670 --> 31:23.310
Now if we go into EC2, we can go to running instances.

31:23.310 --> 31:25.610
We'll go back and we'll launch an instance.

31:25.610 --> 31:29.490
We'll launch that security onion instance I mentioned before.

31:29.830 --> 31:31.330
That AMI.

31:32.530 --> 31:33.690
Like that.

31:36.840 --> 31:41.800
And we'll grab the T3 medium here and we'll go to configure instance details.

31:42.360 --> 31:49.460
And we'll make sure it's in our VPC that we defined and of course in our public subnet, which it should be since those are the only ones that we have available right now.

31:50.520 --> 31:58.160
Now what we're going to do here is we're going to go ahead and add the secondary device for the sniffing interface by clicking add device right here.

31:58.340 --> 32:09.500
And what this is going to do, it's going to make it so that AWS will not be able to publicly assign an IP address if you have, you can see it here, if you have more than one interface.

32:09.960 --> 32:12.740
So we're going to go back and fix that in just a minute.

32:12.740 --> 32:16.380
But we're going to go ahead and click next, add storage here.

32:17.420 --> 32:18.780
And everything looks good here.

32:18.780 --> 32:20.720
We don't need to modify anything here.

32:21.280 --> 32:23.280
Let's click next, add tags.

32:23.280 --> 32:26.680
And unless you really wanted to, we don't necessarily need to add any tags here.

32:26.680 --> 32:30.500
I just really want to get to this configure security group right here.

32:31.780 --> 32:36.740
And so what this one is called, it's called right now launch wizard one.

32:37.280 --> 32:44.280
We just want to call this maybe, actually we'll select a default security group here.

32:44.500 --> 32:45.720
All right.

32:45.800 --> 32:47.320
And we'll click review and launch.

32:47.320 --> 32:51.480
So this will have our default security group attached to it once we launch it.

32:54.060 --> 32:54.660
All right.

32:54.660 --> 33:00.900
Now, what we can do here is it's going to ask you for a key pair to authenticate to your host.

33:01.240 --> 33:09.100
Now, if you don't already have a key pair uploaded to AWS, you can create a new one and then use that key pair to connect with this instance.

33:09.500 --> 33:13.860
You could proceed without a key pair, which I don't recommend because you won't be able to get into it.

33:14.980 --> 33:19.280
So we're going to do create a new key pair.

33:20.280 --> 33:24.720
And go to onion demo.

33:25.040 --> 33:26.040
All right.

33:28.460 --> 33:30.360
And download this key pair.

33:32.040 --> 33:32.540
Okay.

33:32.540 --> 33:33.840
So I've got it saved locally now.

33:33.840 --> 33:36.580
And if I want to launch it from my terminal, I can do that.

33:36.920 --> 33:40.060
I'm going to go ahead and launch this instance now that I've got the key pair downloaded.

33:41.120 --> 33:44.900
And we get this nice little screen and we can go view our instances here.

33:45.060 --> 33:47.820
And we can see that it's starting up here.

33:48.240 --> 33:48.520
All right.

33:48.520 --> 33:51.380
So it's going to flip back over here.

33:51.420 --> 34:02.460
So once we launch that instance, what we're going to want to do is we're going to want to go to that network interface and we're going to want to allocate an Elastic IP.

34:02.720 --> 34:08.100
So this makes it available publicly so that we can access it from our box across the internet.

34:08.160 --> 34:08.760
All right.

34:09.040 --> 34:11.140
So let me go ahead.

34:12.200 --> 34:13.500
Go to actions.

34:13.520 --> 34:14.380
Well, I'm sorry.

34:14.380 --> 34:18.580
Go to the network interface, eth0, which is the one we want to connect to.

34:18.640 --> 34:20.740
It's going to bring up this hyperlinked interface ID.

34:20.740 --> 34:21.900
I'm going to click on that.

34:22.540 --> 34:23.040
All right.

34:23.040 --> 34:25.340
So we brought up the interface and it's selected.

34:25.700 --> 34:29.100
And then we want to manage the IP addresses for this interface.

34:29.500 --> 34:35.020
Once we get there, we can allocate an Elastic IP for it, the one I mentioned previously.

34:35.240 --> 34:37.480
It's going to give us a new tab here.

34:37.520 --> 34:42.500
And it's going to ask if we want to, you know, how we want to allocate it, what kind of settings.

34:42.500 --> 34:44.680
Just leave the defaults here and click allocate.

34:45.740 --> 34:50.700
And then you can actually see that I've got some various ones that I didn't clean up before allocated.

34:50.700 --> 34:53.200
But here you would have one here.

34:53.200 --> 34:57.960
So let me just go ahead and delete these just so I'm not confusing you guys.

35:01.120 --> 35:01.920
Okay.

35:02.480 --> 35:05.540
I'm just going to release those real quick so I'm not confusing anybody.

35:06.580 --> 35:07.220
All right.

35:07.220 --> 35:08.720
So we've got our Elastic interface.

35:08.740 --> 35:11.400
And now that that's allocated, we can go back.

35:11.920 --> 35:13.600
Go ahead and hit cancel.

35:13.960 --> 35:20.480
Go back to actions and go to associate address, which will allow us to associate that IP address.

35:21.460 --> 35:26.340
And we want to click allow reassociation just in case that we want to change it later.

35:26.340 --> 35:31.760
We probably won't be doing that here, but 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:36.800
Okay.

35:36.800 --> 35:45.360
So now that we see that the... if we go back to the instances, see the instances running, then we see our public IP right here.

35:46.080 --> 35:53.920
So if we want to go ahead and verify that that is up, we can do that from here.

35:53.920 --> 35:56.900
So I downloaded that PIM file right there.

35:56.900 --> 35:59.440
You see right here, securityunion1.pim.

36:00.760 --> 36:04.540
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:12.940
But I'll just do... I'm not in the downloads.

36:12.940 --> 36:14.040
Let me change to that.

36:15.580 --> 36:18.580
And real quick before I continue.

36:20.840 --> 36:29.300
So when you're SSHing here, if you're on Mac or you're on Linux and you already have a native SSH client, you should be able to do this natively.

36:29.300 --> 36:37.180
But if you're using PuTTY, you will need to do something like the following in this link to convert the PIM file for use with PuTTY.

36:37.320 --> 36:47.000
And it's going to be using PuTTYgen so that you can basically have PuTTY 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.120
But then down here, we also have the command that you'll run.

36:55.160 --> 37:05.260
And then again, if you don't change the permissions on the file, you will probably have to add sudo to that to execute it with higher or elevated privileges.

37:07.720 --> 37:18.360
So I'm going to do an SSHI PIM and then the default user for the security in an image that's going to be onion.

37:18.360 --> 37:26.100
So we'll use onion at and then the public IP right here of the host.

37:26.500 --> 37:30.840
Okay, so we'll paste that in here.

37:32.380 --> 37:34.120
And we'll just hit enter.

37:34.120 --> 37:38.120
And this is my local password so that I can sudo.

37:39.100 --> 37:40.600
Remember it.

37:51.490 --> 37:54.190
Let's see if I fat fingered it again.

37:56.420 --> 37:57.580
Oh, you know what?

37:57.580 --> 37:59.820
Okay, so what we're going to do here.

37:59.860 --> 38:01.480
One more thing.

38:01.560 --> 38:02.600
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:23.700
Okay, and we'll edit the inbound rules because we really only want to allow SSH for our IP.

38:23.700 --> 38:28.640
And so I'm just going to allow it for my external IP here.

38:29.460 --> 38:37.660
And then also for HTTPS when we want to access the web interface of a security ending.

38:37.980 --> 38:45.060
So just modify the inbound rules here for the default security group.

38:45.060 --> 38:46.820
And we'll just save that.

38:47.640 --> 38:54.300
Okay, so now anything that's part of that default security group will respect those firewall rules.

38:54.300 --> 38:58.380
So now we only have SSH and HTTPS from that external IP.

38:59.260 --> 39:01.680
And you'll want to do the same when you're standing ears up.

39:01.680 --> 39:03.520
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:17.320
And right now that we've modified that, we can just hit yes to accept here.

39:17.320 --> 39:19.900
And now we are into our security box.

39:20.280 --> 39:27.340
Now we we do have the security in an image and most of the stuff is installed already, but we still have to run setup on here.

39:27.800 --> 39:35.500
So what that means is the actual process of configuring all the stuff and you know, and all the packages installed on the OS.

39:35.680 --> 39:40.360
So what we'll do here, just some kind of administration stuff.

39:40.360 --> 39:45.840
We'll just change the host name real quick to something like security and in demo.

39:50.090 --> 39:53.050
And I'm just going to reflect that in Etsy host real quick.

39:55.830 --> 40:00.350
So we'll change Etsy host name and Etsy host.

40:04.560 --> 40:07.060
I'm going to just give the box a quick reboot.

40:14.070 --> 40:16.770
Let's check for any questions or anything.

40:16.910 --> 40:17.730
Okay.

40:22.600 --> 40:25.280
All right, so it's probably rebooted by now.

40:25.860 --> 40:30.500
Because these AWS instances are pretty fast.

40:31.000 --> 40:34.900
So SSH back in to security and in demo.

40:35.240 --> 40:40.400
And now what we'll do is we'll run the first phase of setup for security.

40:40.400 --> 40:44.860
And what I'm doing here is I'm running SS setup minimal.

40:45.100 --> 40:57.020
Now, because we're running on a box with four gigs of RAM, yeah, four gigs of RAM and two cores, we run the minimal setup of security in it so that we can still operate efficiently.

40:57.460 --> 41:08.120
You could run the full fledged version, you would have to size up probably to a T3 large, or maybe even a little more comfortably a T3 extra large.

41:08.440 --> 41:12.100
But SS setup minimal will be more than enough for our lab.

41:12.300 --> 41:15.560
And usually is more than enough for many folks as well.

41:15.560 --> 41:17.200
So we'll run that.

41:17.680 --> 41:19.980
It's going to ask us if we would like to proceed.

41:20.480 --> 41:21.740
We'll hit yes.

41:23.020 --> 41:23.900
Yes.

41:24.260 --> 41:26.820
And we're going to configure the network interfaces.

41:27.260 --> 41:30.560
And we'll just select ENS5 for our management interface.

41:30.620 --> 41:31.820
And we'll hit okay.

41:32.320 --> 41:39.220
And we'll want to make sure to select DHCP and let AWS handle all of the IP addressing and that sort of stuff.

41:40.840 --> 41:43.840
And then we'll like to configure our sniffing interfaces.

41:43.920 --> 41:47.460
So we'll just hit yes whenever it asks us to do so.

41:48.300 --> 41:52.500
And then we'll select ENS6, which is really the only other interface available at this moment.

41:52.500 --> 41:54.060
So we'll hit okay.

41:55.580 --> 41:58.380
And so it's just going to ask us if we're really ready.

41:58.380 --> 41:59.860
And yes, we're ready.

41:59.860 --> 42:01.120
So we'll click yes.

42:01.220 --> 42:03.020
But we are not ready to reboot.

42:03.060 --> 42:05.760
So hopefully you haven't gone through and hit reboot just yet.

42:05.760 --> 42:08.900
But if you did, then it shouldn't be too far until you're rebooted.

42:09.580 --> 42:11.880
So we'll go and edit.

42:11.880 --> 42:25.100
Since the network interfaces have been configured for the most part, an important distinction for cloud monitoring and monitoring in AWS is going to be the VXLAN encapsulation.

42:25.100 --> 42:31.540
And what that does is going to add 54 bytes to the MTU or to the size of the packet in general.

42:31.540 --> 42:33.780
So we want to accommodate for that.

42:33.780 --> 42:35.140
We want to plan for that.

42:35.140 --> 42:40.340
So we'll want to manually adjust our MTU of our sniffing interface.

42:40.720 --> 42:44.840
And we can do that simply by adding this MTU 1575 line right here.

42:45.560 --> 42:48.720
And then we'll just hit control Z to save.

42:48.980 --> 42:54.740
And then so now that we've got our MTU set right there, I'm just going to reboot real quick.

42:55.640 --> 42:56.800
It's on.

42:57.680 --> 43:03.320
And then once it comes back up, we should be able to configure our run through the next phase of setup.

43:03.840 --> 43:09.580
And I'm just going to refer to these instructions here to make sure that I didn't miss anything.

43:10.040 --> 43:11.100
Okay.

43:11.100 --> 43:11.620
All right.

43:11.620 --> 43:15.680
So we've SSH'd back into the security in an instance.

43:15.680 --> 43:19.300
And now we're ready to run the next phase of setup.

43:19.420 --> 43:22.160
And we'll run ss setup minimal again.

43:22.520 --> 43:24.300
And just hit yes.

43:24.580 --> 43:25.700
And yes.

43:26.100 --> 43:29.140
And it's going to ask if we would like to skip the network configuration.

43:29.140 --> 43:33.460
And we're going to click yes because we've already configured it as we want to.

43:33.480 --> 43:38.140
And we're going to go through the main configuration, selecting the production mode option.

43:38.780 --> 43:42.100
And then we're going to click the option for a new deployment.

43:42.120 --> 43:43.200
And hit okay.

43:44.160 --> 43:46.980
I'm just going to specify a username here.

43:46.980 --> 43:54.000
And what this will be is my application level user account for logging into things like Squirt or Kibana.

43:54.900 --> 44:02.180
And basically it's not going to be the same as the OS level account but a separate account that you would use for those purposes.

44:08.100 --> 44:12.600
Now we're going to roll with best practices here because they are the best practices.

44:12.600 --> 44:13.980
So we use them.

44:14.160 --> 44:15.480
I'm going to hit okay.

44:15.740 --> 44:19.780
And we're going to use the default ET open rule set here.

44:19.960 --> 44:21.680
We're going to click okay.

44:22.520 --> 44:29.720
And because Suricata does offer that VXLAN DCAP, we're going to select Suricata versus Snort right now.

44:30.680 --> 44:32.340
And we're going to hit okay.

44:33.260 --> 44:38.220
And we're going to enable the network sensor services because that's what we're looking for.

44:38.220 --> 44:41.820
And we're just going to go with the defaults here from there.

44:43.060 --> 44:44.060
Logs.

44:44.060 --> 44:44.800
Okay.

44:44.900 --> 44:46.400
And continue.

44:46.740 --> 44:49.720
And so what's going to happen, that's going to roll through setup.

44:49.880 --> 44:57.140
And while that's rolling through setup, we can go ahead and start prepping our other node that we want to monitor.

44:58.640 --> 45:00.800
So I'm just going to minimize that.

45:02.380 --> 45:03.860
And go to instances.

45:03.860 --> 45:05.720
And let me flip back real quick.

45:06.200 --> 45:06.880
All right.

45:06.880 --> 45:10.800
So we're going to create an instance, a Linux 2 AMI instance.

45:11.320 --> 45:13.120
We're going to launch right here.

45:13.120 --> 45:25.640
And another thing to remember, and what I mentioned earlier, is you'll want to make sure that for the traffic mirroring that you're using supported instances for those Nitro instances.

45:25.640 --> 45:27.480
I'm sorry, Nitro-based instances.

45:27.700 --> 45:32.780
And the T3 line of images is one of those, as well as I believe the T3A.

45:32.960 --> 45:36.560
So what we're going to do here, we don't have to select a giant image.

45:36.700 --> 45:41.580
We can still use a very, very small image.

45:41.580 --> 45:44.520
So I'm going to use a T3 micro right here.

45:45.440 --> 45:49.380
And then I'm going to select configure instance details.

45:49.620 --> 45:52.980
And sure, all of this good stuff, the network and the subnet looks okay.

45:53.260 --> 45:55.100
Everything else looks okay.

45:55.520 --> 46:01.760
And what we can do is we can actually just auto-assign a public IP.

46:01.940 --> 46:06.740
So if we select that, then it'll automatically assign an IP, since we only have a single interface.

46:07.460 --> 46:09.420
And then we'll click next add storage.

46:09.420 --> 46:11.100
Don't need anything else here.

46:11.140 --> 46:12.340
Add tags.

46:12.660 --> 46:16.260
And then we'll make sure that we're using the security group that we want to use.

46:17.020 --> 46:23.600
In this case, we can again use that default security group because we'll want that SSH access.

46:23.820 --> 46:36.420
While we really don't need HTTP access, in this case, as far as a demo, there's really no need to create another security group because there's not really anything running on this host as far as HTTPS.

46:36.500 --> 46:38.800
So we're just going to click review and launch.

46:40.920 --> 46:45.920
Okay, all right, and launch.

46:46.600 --> 46:50.000
And it's going to give us the same question about the key pair.

46:50.360 --> 46:57.280
So what I'm going to do here and what we can do is select the the key pair that we created previously.

46:57.580 --> 47:00.840
So the one that we just created was security in demo one.

47:00.840 --> 47:03.940
We're going to select that and click I acknowledge.

47:04.020 --> 47:09.200
And then we're going to launch instances here and go to view instances.

47:10.200 --> 47:16.940
Okay, so now we see it's creating it automatically assigned that public IP that we can then access here in just a minute.

47:17.100 --> 47:19.120
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:30.300
Yep, okay.

47:30.300 --> 47:38.240
So while that's still going, what we can do is create our security group that's going to be used for the sniffing interface of security.

47:38.600 --> 47:53.740
So what we want to do is be able to allow access or allow traffic to be forwarded to that interface, but we don't want that interface to be able really to or anybody else to that interface.

47:53.760 --> 47:57.400
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:28.240
All right, and what we're going to do here, instead of all traffic, well I guess we can do all traffic, but in fact you'll want to.

48:28.280 --> 48:35.440
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:47.760
Only accept from internal, so that's outbound.

48:47.760 --> 48:50.780
I'm sorry, I'm not... well that'll be the same case.

48:50.780 --> 48:56.060
So we really only want outbound connectivity to those as well, if there's any at all.

49:00.570 --> 49:01.890
So we'll do that.

49:11.020 --> 49:19.660
All right, so we've created that group now and what we can do is we can associate that with that sniffing interface.

49:20.480 --> 49:30.580
So if we go over here to our instances again, we will... let me go ahead and label these so they're a little bit easier to see.

49:30.840 --> 49:35.640
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:53.260
I'm going to change it to this security and sniffing security group.

49:53.260 --> 49:56.720
All right, so it no longer has anything that can access it from external.

49:56.720 --> 49:57.720
It needs to.

49:57.720 --> 50:00.940
It's only doing its deed as a sniffing interface.

50:03.080 --> 50:08.300
All right, so what we do next... let's go ahead and check.

50:08.300 --> 50:16.900
Okay, so run through the first set and there's just a little bit of post-configuration that it automatically runs through here for the security inbox.

50:20.980 --> 50:41.520
All right, so we'll let that go and then what we'll do here is open up a new terminal and we're going to go ahead and ssh to our Amazon Linux host while the security inbox is finishing up.

50:41.520 --> 51:15.970
Okay, I'm going to do the sudo ssh i 1 and the default user for the AZ Linux box or the Amazon Linux box is going to be ec2-user and we'll just paste this in here and again prompt it locally because my sudo and if i could type oh

51:19.070 --> 51:43.800
my goodness okay all right there we go all right so we're in the Amazon Linux node right now over here on this screen okay so we got that ssh session going there all right so it's not quite finished here Okay, so we've got those two SSH connections up now.

51:43.800 --> 51:53.420
Now what we'll do is really, I guess what you guys have been waiting for, not the boring AWS setup, but the actual mirror traffic configuration.

51:53.680 --> 52:01.180
Okay, so what we'll do now is go ahead and create our mirror filter, our mirror target, and our mirror session.

52:01.660 --> 52:09.960
So, go over here to VPC, and traffic mirror filters.

52:09.960 --> 52:22.000
We'll just go ahead and create the filter first, and we're just going to name it security.demo, and let's call it security.demo.

52:22.360 --> 52:29.020
Alright, now we want everything in this filter, we want all the traffic, all the things.

52:29.180 --> 52:50.000
So we'll do a quad zero here, here, the inbound and the outbound, we'll do a quad zero for the source and destination, because it will actually filter out the inbound and outbound from the traffic it's mirroring if you're not careful, so that's why we're doing that here.

52:51.760 --> 52:54.260
Okay, and we'll hit close.

52:54.260 --> 52:59.340
So we've created our traffic mirror filter, what defines what will be forwarded to the mirror target.

52:59.420 --> 53:02.360
Now we'll go ahead and create that mirror target.

53:03.120 --> 53:12.400
Alright, and this is going to be the security.onion.sniffing demo.

53:14.600 --> 53:20.880
And what we'll do here is we'll choose the target ENI, or network interface.

53:21.000 --> 53:26.460
And right here, as you can see, these primary network interfaces aren't going to be it, those are going to be management interfaces.

53:26.500 --> 53:30.620
So we know that it's this one right here, otherwise we might have to go check.

53:33.680 --> 53:36.040
Alright, so we'll hit create.

53:37.340 --> 53:47.100
So we've created our traffic mirror filter and our traffic mirror target, so now we just need to associate all this with a source inside of a mirror session.

53:48.840 --> 53:57.200
And that's what we'll do here is our security.onion.demo.mirror.session.

53:58.680 --> 54:06.260
And our mirror source, again, is going to be one of these primary network interfaces.

54:06.260 --> 54:17.620
However, we don't know just yet, so we'll need to go over here to instances, and we'll need to go to the instance where we want to mirror and find that source network interface.

54:17.620 --> 54:19.400
And here it is, eth0.

54:19.660 --> 54:27.260
So we're going to click that, we're going to grab this interface ID and copy it so that we know for certain which one we want to monitor.

54:27.800 --> 54:30.220
And it's this primary network interface.

54:30.540 --> 54:33.640
And we know here our target, so we'll select that.

54:33.940 --> 54:44.340
And one thing that always gets me is that you'll have to enter in here, even though it's prepended, or pre-populated with a 1, it's not really filled out, you have to enter a 1 there for the session number.

54:46.180 --> 54:49.720
And then we'll hit create... I didn't add my filter.

54:49.840 --> 54:54.120
So we'll need to add filter here, and that's going to apply that filter, right?

54:54.120 --> 54:55.980
So let's create that.

54:57.400 --> 55:03.620
So we've now got our security.onion.demo.mirror.session, our traffic mirror session, created.

55:03.620 --> 55:10.420
So from a networking standpoint, security.onion, or at least the box, should be able to see all this traffic on the network interface.

55:11.660 --> 55:16.400
So let's go back to our SSH session.

55:16.580 --> 55:17.020
Okay.

55:17.700 --> 55:19.280
So setup is now complete.

55:19.280 --> 55:22.300
I'm just going to check the status and make sure everything looks good.

55:24.680 --> 55:25.560
Okay.

55:26.200 --> 55:35.100
And real quick, before we dive into any of the other stuff, I'm just going to check real quick with the tcpdump command to check and see if that traffic is coming by.

55:36.000 --> 55:37.780
I don't see anything just yet.

55:38.320 --> 55:39.940
But if we type here...

55:41.140 --> 55:43.660
and let's see if I can break this out into a different one.

55:44.680 --> 55:49.840
We can see now that our traffic is being mirrored.

55:50.460 --> 55:50.800
Right?

55:50.800 --> 55:51.580
So that's it.

55:51.580 --> 55:54.940
It's that simple to create the mirror sessions, right?

55:55.860 --> 56:00.820
It's a little bit of work to get the infrastructure set up.

56:01.100 --> 56:06.100
And to... I guess once you go through it a couple of times, it's a little bit easier to grasp, I guess.

56:06.640 --> 56:09.360
But it's fairly straightforward to get that set up.

56:10.020 --> 56:19.620
And now once we have that, since we're using security engine, and we want to see that traffic, we can actually use something like... where is it?

56:19.780 --> 56:22.260
Test my nids, which I was referring to earlier.

56:23.420 --> 56:32.340
And so what this does is it's going to execute a series of tests, callouts to this actual website, testmynids.org.

56:32.340 --> 56:35.740
It's going to simulate that bad activity.

56:36.740 --> 56:45.220
So if we just do this here, and there's several options right here, we're going to enable pure chaos and run them all, as always.

56:46.360 --> 56:52.500
And it looks like maybe on Amazon Linux, Netcat is not installed by default, which is fine.

56:53.560 --> 56:56.860
So maybe that one didn't go through, but that's fine.

56:56.860 --> 57:00.320
We can just do yum.install.netcat if we want.

57:03.620 --> 57:05.920
Install-y netcat.

57:09.290 --> 57:10.990
I'll just run it one more time.

57:17.670 --> 57:19.070
And just let it run through there.

57:19.070 --> 57:22.990
So it's just going to simulate some nice traffic for us to be able to see in security engine.

57:33.090 --> 57:35.030
All right, still going there.

57:35.710 --> 57:40.350
All right, I think that's probably more than enough for us to take a look at.

57:40.790 --> 57:53.870
So I'm going to get off of this TCB dump here, and I'm going to allow access locally, because even though we've run or allowed the port in the firewall for AWS, we have not allowed it for the local firewall.

57:54.030 --> 57:58.910
So we'll want to allow that for the analyst, the port 443.

57:58.910 --> 58:08.290
It's going to give us 22443 and 7734 in case you wanted to run the SQL client, which is... I honestly didn't mention it previously.

58:08.290 --> 58:10.510
I didn't mention all of the tools in security engine.

58:10.810 --> 58:18.830
But if some of you have used SQL before, you can use that SQL client to connect up there and view that alert data.

58:20.830 --> 58:25.850
So I'm just going to do... before I do this, I'm going to do who real quick.

58:26.290 --> 58:27.910
Grab this business.

58:28.030 --> 58:28.690
Okay.

58:29.710 --> 58:31.030
And you can do the same thing.

58:31.030 --> 58:32.810
Run who to get that IP.

58:33.550 --> 58:35.050
Just paste that in there.

58:36.270 --> 58:37.390
All right.

58:37.970 --> 58:41.350
And we'll just hit enter, and it's going to refresh and throw that rule in there.

58:42.230 --> 58:46.110
And then we're going to access the web interface of that external IP.

58:46.430 --> 58:52.410
So let's go back and get our... where am I going?

58:52.410 --> 58:53.090
Okay.

58:53.290 --> 58:54.690
EC2 instances.

58:57.860 --> 59:01.600
And we're going to grab the public IP of the security in an instance.

59:02.560 --> 59:03.980
And we're going to go over here.

59:07.520 --> 59:08.780
That's not it.

59:11.020 --> 59:13.540
If I can copy... copy pasta.

59:13.540 --> 59:14.400
Come on, people.

59:15.560 --> 59:16.220
All right.

59:20.450 --> 59:24.210
Copy and paste is not being happy with me today.

59:25.490 --> 59:27.470
I'll just copy it from over here.

59:27.750 --> 59:28.430
Copy.

59:33.410 --> 59:34.390
There we go.

59:34.390 --> 59:35.010
Okay.

59:36.110 --> 59:36.990
Okay.

59:37.610 --> 59:40.730
So we get here, of course, it's a self-signed certificate.

59:40.730 --> 59:43.530
Obviously, you would want to change this if you deploy it in your environment.

59:43.590 --> 59:45.350
But for us, it's just fine.

59:45.350 --> 59:48.330
For Catalina, it's annoying.

59:48.330 --> 59:50.590
So we type this is unsafe.

59:51.550 --> 59:56.350
And then here we are on the just kind of splash page for security.

59:56.350 --> 01:00:01.490
And there's some links here for Cyber Chef, which we include for data transformation.

01:00:01.650 --> 01:00:11.190
And, you know, if you've got things like encoded bits of text, compressed stuff, performing other types of data analysis and whatnot, it's really good for that.

01:00:11.930 --> 01:00:17.510
And then also Squirt, which is going to be the web equivalent of Squeal, where you view that IDS alert data.

01:00:17.990 --> 01:00:21.030
So I can pop in there real quick if I want to.

01:00:21.030 --> 01:00:24.590
And I'll specify that username and password that I created earlier.

01:00:27.820 --> 01:00:30.180
And let's see.

01:00:30.180 --> 01:00:31.620
So okay.

01:00:31.620 --> 01:00:32.660
So we don't get much here.

01:00:32.660 --> 01:00:37.320
But let me pivot back over to Kibana.

01:00:45.730 --> 01:00:46.890
Okay.

01:00:47.150 --> 01:00:50.850
And let's see what kind of NIDS alerts we got here.

01:00:51.750 --> 01:00:52.350
Hmm.

01:00:52.350 --> 01:00:52.750
Okay.

01:00:52.750 --> 01:00:54.810
So we got the return to root one.

01:00:54.830 --> 01:00:57.150
But we didn't get many others.

01:00:57.870 --> 01:00:59.070
I think I know why.

01:00:59.070 --> 01:01:05.030
I think it's because we didn't enable EVX and decapsulation for Cercata.

01:01:05.030 --> 01:01:18.810
So this is something important to note, that we do not enable this by default, just because of the potential overhead of having to run it and not the percentage of folks who actually don't run VXLAN traffic compared to on prem.

01:01:18.990 --> 01:01:22.270
So we'll want to enable that real quick in Cercata.yaml.

01:01:22.350 --> 01:01:27.370
And I feel like it's good for folks to be comfortable with that and know where that exists.

01:01:27.810 --> 01:01:30.150
So right here we see VXLAN.

01:01:30.150 --> 01:01:32.090
I'm just searching for it in here.

01:01:32.290 --> 01:01:34.410
And then we see a VXLAN enabled.

01:01:34.910 --> 01:01:36.270
Stanza right here.

01:01:36.730 --> 01:01:38.350
I'm just going to change this to true.

01:01:40.960 --> 01:01:42.900
And yes, I really want to edit it.

01:01:42.900 --> 01:01:45.560
And just to make sure that it's still there.

01:01:46.760 --> 01:01:47.440
Okay.

01:01:47.440 --> 01:01:51.000
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:22.320
And this is kind of what I alluded to previously, is no matter if you're watching the traffic or recording the traffic with seeing that VXLAN traffic, it's very important to be able to have an IDS or a mechanism to be able to decapsulate that or unwrap that so you can actually see and alert on what's going on underneath.

01:02:23.140 --> 01:02:29.200
So if we run this command again, let it run through.

01:02:29.200 --> 01:02:31.240
And I'm going to give it a minute before we refresh.

01:02:31.240 --> 01:02:33.940
But we should see some more data in there.

01:02:33.940 --> 01:02:42.880
Hopefully, you know, several more NIDS alerts and then, you know, something that we can have a little meat towards.

01:02:47.230 --> 01:02:47.970
All right.

01:02:47.970 --> 01:02:49.370
So I'll give that a minute there.

01:02:49.510 --> 01:02:49.830
Okay.

01:02:49.830 --> 01:02:51.070
So it looks like it's done.

01:02:52.110 --> 01:02:59.390
And if we go back, it will take... it does take about 30 seconds for Elasticsearch to refresh its indexes.

01:02:59.790 --> 01:03:02.550
So we'll just do this.

01:03:02.870 --> 01:03:08.190
And by refresh, I mean basically making it available for search, even though the data is in there.

01:03:09.530 --> 01:03:14.670
And so now that we've enabled that VXLAN decapsulation, we're seeing a lot more.

01:03:14.830 --> 01:03:18.730
As I mentioned, it's very important that that's enabled when you're doing this in the cloud.

01:03:19.130 --> 01:03:22.290
So we can see all sorts of types of alerts here.

01:03:22.290 --> 01:03:26.670
And then if we go down here, we can see that stuff here as well.

01:03:26.790 --> 01:03:29.910
Let me see if I can put it down just a little bit.

01:03:30.310 --> 01:03:30.590
Right.

01:03:30.590 --> 01:03:34.190
We get an ET policy PDF with an embedded file.

01:03:34.190 --> 01:03:35.370
That's interesting, right?

01:03:35.370 --> 01:03:37.590
We could go investigate that.

01:03:37.590 --> 01:03:41.790
We could see what other activity was associated with this.

01:03:41.810 --> 01:03:48.070
So if I wanted to search for this particular IP, this destination IP, or how about the source IP here?

01:03:48.070 --> 01:03:49.110
This is strange, right?

01:03:49.110 --> 01:03:51.250
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:10.070
So it's going to give me other snort alerts.

01:04:10.250 --> 01:04:12.730
So these are the Suricata alerts.

01:04:12.830 --> 01:04:18.130
To clarify, we just called the data type snort, just for our parsing purposes.

01:04:18.130 --> 01:04:22.070
It's just what we've done so far that will change in the future.

01:04:22.470 --> 01:04:29.130
And then we can see the Ebro connection records, or ZEKE connection records, and then the ZEKE files records.

01:04:29.130 --> 01:04:32.610
Again, we've kept the older naming convention for now.

01:04:32.610 --> 01:04:34.830
And then the HTTP records, right?

01:04:34.830 --> 01:04:40.490
So we also see different stuff that this destination IP address was associated with.

01:04:43.700 --> 01:04:50.080
And then we can see some other, if there were any other source destination IPs that communicated, right?

01:04:50.080 --> 01:04:55.120
And then, let's see, get some different MIME types here.

01:04:55.260 --> 01:05:00.220
And you can really, at least from here, go off in each type of these, right?

01:05:00.220 --> 01:05:11.220
If you want to filter down for, say, HTTP, you can scroll down here, look at these HTTP logs that we've indicated via the indicator dashboard, drill into those.

01:05:11.420 --> 01:05:14.360
And then, now this is important as well.

01:05:14.900 --> 01:05:24.230
In fact, I don't know many, even commercial solutions that can do this off the shelf is VXLAN decapsulated PCAP.

01:05:24.970 --> 01:05:34.310
So I will say that typically in the on-premise version, you can pivot to PCAP from here and see the full conversation, as I mentioned.

01:05:34.390 --> 01:05:47.570
One limitation currently with the current platform is that you can't necessarily pivot to PCAP, but you can enable stuff like Suricata, EJSON logging, and still log that packet.

01:05:47.570 --> 01:05:51.310
Or you can do other stuff with that PCAP, which I'll talk about in just a little bit.

01:05:52.350 --> 01:05:55.410
But again, you can see the breadth of data that we have here.

01:05:55.410 --> 01:06:06.570
As far as HTTP, we have MIME types, the file IDs that were basically Zykl pull-out identifiers for the files that it rips out of the network stream.

01:06:06.570 --> 01:06:12.070
So we can pivot based off of those into different types of data, and it can be very powerful.

01:06:12.890 --> 01:06:23.750
All right, so if we go back here again, if we just want to even get a summary of the connection data, so we can see all of the stuff that was even VXLAN.

01:06:23.750 --> 01:06:39.250
So if you want to separate out nodes that are maybe cloud nodes and maybe on-prem nodes, then you can 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:48.070
Let's take those out then.

01:06:50.030 --> 01:06:53.250
It's really going to be the categorized con logs and whatnot.

01:06:53.390 --> 01:06:56.850
So again, I mean, you can group by service.

01:06:56.850 --> 01:07:05.790
You can then, if you want to drill into, maybe you've got some weird SSL stuff, you know, you've got a high count here, then you can drill into the SSL data over here.

01:07:05.790 --> 01:07:22.790
All right, and then we can see the different server names that we have here, common names associated with the SSL, the validation status, if you want to track validation of certs, and maybe, you know, you see some certs that aren't valid or track expiration,

01:07:22.790 --> 01:07:23.770
stuff like that.

01:07:23.770 --> 01:07:27.570
There's a lot more here than, you know, just detection-oriented stuff.

01:07:27.830 --> 01:07:32.290
And, you know, a lot of that, even that stuff can lend its way to being detection-oriented.

01:07:34.110 --> 01:07:41.270
So, as you can see here on this Zeek hunting panel, there's tons and tons of data that we could pore over if we wanted to.

01:07:41.350 --> 01:07:50.470
We could see these query types and these response codes for DNS, obviously what server we reached out to, the actual queries, right?

01:07:50.470 --> 01:07:53.150
So, you know, hey, that's a weird query, right?

01:07:53.330 --> 01:08:01.450
So, it's pretty easy to stack this data and to see it and represent it in an easy-to-digest fashion.

01:08:04.460 --> 01:08:15.700
And then, again, with the HIDS alerts, if we had any host-based agents deployed, we would see those logs here, and we could, you know, drill into different details there.

01:08:16.180 --> 01:08:21.500
You can see the TCP dump that we ran locally earlier, and you can also see where we modified suricata.yaml.

01:08:21.740 --> 01:08:38.820
So, Suricata, I'm sorry, security in itself will run a local Wazoo or OSEC agent here on the box and watch everything that's going on its own box as well as any other agents or any other endpoints to which we deploy it.

01:08:40.740 --> 01:08:52.560
So, again, you know, being able to tie in, and we don't have any just at the moment, you can tie in autoruns data, beats data, and all that other good stuff to help augment this data.

01:08:52.560 --> 01:09:07.460
And, again, you know, there are things like CloudWatch, and there are these host-based events, but being able to have the network security monitoring component and being able 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:12.400
and in many cases can be very cost-effective compared to other solutions.

01:09:13.460 --> 01:09:20.540
So, let me just go back here to... let me make sure, see if I missed anything here.

01:09:21.680 --> 01:09:22.340
Okay.

01:09:22.440 --> 01:09:22.740
All right.

01:09:22.740 --> 01:09:24.160
So, we walked through that.

01:09:26.380 --> 01:09:27.880
Let me see.

01:09:28.540 --> 01:09:40.140
So, again, that's how you, you know, from scratch go and set up security in that environment in AWS, promote that traffic mirroring and whatnot.

01:09:40.140 --> 01:09:52.240
And I know I didn't go into a whole lot of the investigation, but I really just want to try to leave you guys wanting for more and exploratory there and being able to delve into a lot of that on your own and in your testing.

01:09:53.320 --> 01:10:01.100
But I will continue here, and what we're going to do is I'm just going to go ahead and terminate these real quick.

01:10:02.820 --> 01:10:03.960
Yes, terminate.

01:10:03.960 --> 01:10:15.040
I'm going to clean up the VPC here and then show you guys something else, which if you do have that Ubuntu host and you're able to have internet access, you should be able to follow along with.

01:10:17.040 --> 01:10:17.980
Let's see.

01:10:17.980 --> 01:10:18.180
Okay.

01:10:18.180 --> 01:10:23.400
So, it's going to take a second for those to get the story there.

01:10:23.400 --> 01:10:28.960
So, I'll go back here with the PowerPoint and I'll follow up on some more stuff while that's happening.

01:10:32.450 --> 01:10:33.610
So, we'll move on.

01:10:33.610 --> 01:10:35.850
I mentioned that supplementary data.

01:10:36.330 --> 01:10:42.830
So, if we want to bring in Azure logs, stuff from Azure Event Hubs, we can absolutely do that.

01:10:42.830 --> 01:10:46.390
Logstash has an Event Hubs plugin that we can use.

01:10:46.390 --> 01:10:50.450
So, we can pull all that telemetry, all of that data into Security Engine.

01:10:50.570 --> 01:10:54.030
If you've got multiple clouds, that can be a very effective solution.

01:10:55.310 --> 01:10:59.710
And what that looks like in summary is, you know, the instructions are here.

01:10:59.710 --> 01:11:03.590
I'm not going to go over these too much right now.

01:11:04.810 --> 01:11:08.850
I'll leave this as an exercise to the reader if they want to go and do that.

01:11:09.370 --> 01:11:16.230
But there is plenty of guidance on being able to do that and just ingest that data into Security Engine.

01:11:17.870 --> 01:11:20.690
This is kind of what it looks like, the configuration there.

01:11:20.730 --> 01:11:40.550
Again, once you configure that, you can pull those logs from Azure Event Hubs into Security Engine and then correlate that data across all of your other data and have, again, your cloud data and your on-prem data and whatnot all in one place through that single pane of glass.

01:11:44.720 --> 01:11:47.000
And this is kind of what it might look like here.

01:11:47.000 --> 01:11:49.800
So, we've got some stuff from Event Hub.

01:11:49.800 --> 01:11:52.380
We're just tracking administrative actions here.

01:11:54.740 --> 01:11:59.040
Different... looks like somebody listed some keys here in Azure.

01:11:59.040 --> 01:12:01.520
So, that might be an interesting event to go after.

01:12:01.520 --> 01:12:09.120
And there's tons and tons of stuff that you can glean there and throw in there to make that context even greater.

01:12:10.320 --> 01:12:15.120
And the same case with Google Cloud, which I'm not going to go over with too much right here.

01:12:15.120 --> 01:12:24.980
But you could also have things like VPC flow logs or audit logs sent to the cloud logging functionality, the export sync in Google Cloud.

01:12:24.980 --> 01:12:30.940
You could pick that up with something like PubSubBeat and have that transmitted to Logstash if you like.

01:12:30.940 --> 01:12:32.340
That is one option.

01:12:35.430 --> 01:12:38.670
And, again, I'm not going to go through that too much just right this second.

01:12:38.690 --> 01:12:40.790
It's kind of what the configuration looks like there.

01:12:40.790 --> 01:12:43.730
Fairly straightforward as far as PubSubBeat itself.

01:12:44.190 --> 01:12:54.450
And then once that data is in there, again, if you've got VPC flow logs from Google Cloud and you're not performing any other type of monitoring, then we can pull that stuff in.

01:12:57.550 --> 01:13:00.130
And the same thing with AWS, right?

01:13:00.130 --> 01:13:12.950
So, aside from traffic mirroring, we can still pull in CloudTrail, we can still pull in CloudWatch and throw them into S3 and have Logstash read from S3 and have those in security and in for that greater context.

01:13:15.270 --> 01:13:17.330
And I'm just going to skip through this.

01:13:18.410 --> 01:13:34.890
And so, before continuing any further, again, just again kind of harping on the idea that you can pretty much take any of this cloud data that you want to augment your current monitoring strategy with and send it to security, whether it be in the cloud or on-prem,

01:13:34.890 --> 01:13:42.850
and really have a powerful solution without having to buy into a bunch of commercial stuff, basically.

01:13:43.470 --> 01:13:48.350
So, to move along from that, I want to talk about 3CoreSec AutoMirror real quick.

01:13:48.350 --> 01:14:00.930
And what it is, is it's another open source tool by 3CoreSec, Tiago Faria and his folks, and it really allows for that quick and easy facilitation of NSM.

01:14:01.050 --> 01:14:15.270
Now, we talked about the mirror config, and obviously going and adding stuff to a mirror session can, if you have a ton 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:21.190
So, one of the solutions here is to use 3CoreSec AutoMirror in AWS.

01:14:22.110 --> 01:14:32.150
And what this means is that if we have instances tagged with mirror equals true, a mirror tag that equals true, then we can do that upon creation.

01:14:32.150 --> 01:14:37.850
That can be a default and a template, and then these will be added to a VPC mirror session for a mirror target.

01:14:38.190 --> 01:14:49.030
And what that means is that we can spin up one host, we can spin up another host, we can spin up another host, and these will all be added to the mirror session, 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:54.990
Now, it sits as a Lambda function.

01:14:55.270 --> 01:14:57.450
Tiago has released a serverless app.

01:14:57.570 --> 01:15:04.390
The way I use it, 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:23.610
Another thing I want to talk about, automating the deployment is one of the things that I mentioned at the beginning, and something that really doesn't take too much time.

01:15:23.810 --> 01:15:38.190
This is where we can automate the deployment of security on end and 3CS AutoMirror so that we're deploying a security on end node, we're deploying maybe a Ubuntu instance for a lab environment or for POC.

01:15:39.650 --> 01:15:42.470
Ultimately, you could do this with a production environment.

01:15:42.470 --> 01:15:49.830
Although the templates here aren't necessarily suited for a production environment, you could tweak them to do so.

01:15:51.370 --> 01:15:57.390
Again, that's kind of what I want to walk through here and get into the next demo here.

01:15:57.630 --> 01:16:00.670
I will hop out of this and check on our instances.

01:16:02.030 --> 01:16:03.670
Let's go ahead and do this.

01:16:03.990 --> 01:16:04.910
Ta-da!

01:16:06.650 --> 01:16:07.450
Refresh.

01:16:08.210 --> 01:16:09.810
Okay, so those are gone.

01:16:09.970 --> 01:16:11.790
Now I'm just going to clean up this VPC.

01:16:11.790 --> 01:16:13.430
I really don't want this thing anymore.

01:16:14.470 --> 01:16:19.870
You know, it's just we want to try to automate this thing, so let's just delete this whole VPC.

01:16:20.130 --> 01:16:21.850
I don't need this stinking thing.

01:16:22.810 --> 01:16:23.590
All right.

01:16:23.890 --> 01:16:25.750
All right, we blew it with smithereens.

01:16:26.670 --> 01:16:30.890
Okay, so now we've got a fresh account, right?

01:16:30.890 --> 01:16:32.290
No VPC, nothing.

01:16:32.910 --> 01:16:34.810
Now we want to automate this.

01:16:35.270 --> 01:16:36.830
How do we do that?

01:16:37.150 --> 01:16:38.990
So we're going to pop over.

01:16:38.990 --> 01:16:41.590
I've got any Ubuntu 18.04 box right here.

01:16:42.490 --> 01:16:44.030
Let me get out of this.

01:16:44.030 --> 01:16:45.290
This thing is in my way.

01:16:47.610 --> 01:16:52.750
Sorry, let me clear that up.

01:16:52.950 --> 01:17:03.630
Okay, so now what we're going to be utilizing here is going to be, let me go back real quick, this security onion cloud right here.

01:17:03.630 --> 01:17:08.690
So this page, it's in the link here in the document for this automated deployment.

01:17:09.130 --> 01:17:11.990
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:20.210
So I didn't put it in there.

01:17:20.450 --> 01:17:28.110
All right, so you can go there to take a look at that, and you can follow along.

01:17:28.150 --> 01:17:30.070
The steps I use are going to be a little bit different.

01:17:30.070 --> 01:17:31.590
It's not going to be as manual.

01:17:32.630 --> 01:17:34.510
So I'll just go from there.

01:17:34.910 --> 01:17:40.830
But let me go back to my host here, and what I've done is I've already get cloned security onion cloud.

01:17:41.090 --> 01:17:41.760
So I would just do...

01:17:45.070 --> 01:17:46.950
probably should have done this from fresh.

01:17:47.090 --> 01:17:53.310
All right, so we're going to do a get clone security and solutions security onion cloud right here.

01:17:54.170 --> 01:17:56.850
And then once that's cloned, we're going to cd into it.

01:17:56.850 --> 01:17:59.890
I'm going to cd into the Terraform AWS directory.

01:18:00.250 --> 01:18:02.650
So we can see all this good stuff in here.

01:18:03.810 --> 01:18:09.550
And what we're going to want to do is there are a few variables that we need to populate.

01:18:09.670 --> 01:18:16.210
First of all, when you're first installing it, you need to run obviously the prep.

01:18:16.210 --> 01:18:18.290
It's going to be the prep so script.

01:18:18.290 --> 01:18:22.190
So if you just clone that, it's going to be prep so right here.

01:18:22.190 --> 01:18:30.410
Just do a sudo prep so and super secret password.

01:18:30.670 --> 01:18:31.650
All right, it's going to run through.

01:18:31.650 --> 01:18:33.030
It's going to install Terraform.

01:18:33.030 --> 01:18:35.010
It's going to install AWS CLI.

01:18:35.010 --> 01:18:36.850
It's going to install jq.

01:18:37.790 --> 01:18:39.610
Just because we like things pretty.

01:18:40.610 --> 01:18:42.910
It's going to install...

01:18:45.530 --> 01:18:46.150
know what?

01:18:46.150 --> 01:18:47.510
What else is it going to install?

01:18:49.070 --> 01:18:56.050
It's going to basically get everything prepped for the Terraform thing that we're going to do here.

01:18:56.050 --> 01:18:58.970
And then it's going to prompt you to configure AWS CLI.

01:18:59.130 --> 01:19:02.350
Now, when you configure it for the first time, you're going to get this.

01:19:02.350 --> 01:19:05.970
It's configuring AWS CLI and then the access key ID right here.

01:19:06.230 --> 01:19:08.610
So it's not going to show secret right here.

01:19:08.610 --> 01:19:11.070
It's going to just be blank and you're going to have to enter in.

01:19:11.430 --> 01:19:13.810
Let me see if I can get it right here real quick.

01:19:14.050 --> 01:19:21.210
You're going to have to go here to my security credentials and access keys.

01:19:21.230 --> 01:19:25.430
Expand that and if you don't already have an access key, you're going to create one.

01:19:25.430 --> 01:19:28.270
And there's going to be an access key ID, right?

01:19:28.270 --> 01:19:33.330
So once you have that access key ID, you'll paste that into the first prompt.

01:19:33.330 --> 01:19:36.170
Then there'll be a secret key that's included with that.

01:19:36.170 --> 01:19:39.050
You'll paste that into the second prompt.

01:19:42.150 --> 01:19:48.330
So this access key ID isn't necessarily like your secret key.

01:19:48.710 --> 01:19:55.610
You may still want to protect it, but obviously you're not going to be able to do anything without the secret key as well.

01:19:55.930 --> 01:20:00.050
So we'll just press enter here to keep the secret access key.

01:20:00.150 --> 01:20:05.310
And then in the region, you're going to want to specify one of those regions that has access to that AMI.

01:20:05.410 --> 01:20:08.410
So in our case, that's going to be that US-East-2.

01:20:08.410 --> 01:20:15.810
It's going to be the US-West-2, the EU-Central-1, and EU-West-2, I think.

01:20:17.030 --> 01:20:18.850
Sorry, I've got terrible memory.

01:20:19.130 --> 01:20:20.450
EU-West-2, yep.

01:20:21.930 --> 01:20:23.130
Let me go back.

01:20:23.130 --> 01:20:26.870
Alright, so I've already got this configured, so it's just going to keep the defaults.

01:20:26.950 --> 01:20:29.550
And default output format is none, that's fine.

01:20:30.010 --> 01:20:34.570
Okay, and I've already... it's already generated a public-private key pair.

01:20:34.650 --> 01:20:46.850
It's going to prompt you on your first install, and you can just hit enter for the time being unless you want to protect it with a password, which obviously in a production case, you would want to take more secure measures, but for the purposes of testing,

01:20:46.850 --> 01:20:48.050
you should be fine.

01:20:49.250 --> 01:20:51.570
So we're not going to overwrite this.

01:20:54.170 --> 01:21:04.070
Alright, we're just going to... it's going to prompt us 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:14.030
Now, there's an option in the actual terraform.tfvars file that you can modify if you want this enabled or not, but this just helps you do it.

01:21:14.030 --> 01:21:16.830
So this is just less manual going in and doing stuff.

01:21:16.970 --> 01:21:29.210
So I'm just going to select yes, and then what it's going to do is it's going to populate this... terraform.tfvars.

01:21:29.530 --> 01:21:36.250
It's going to populate it with the path of the credential files, which should be the default that you're going to be using.

01:21:36.250 --> 01:21:45.230
It's going to already have the default path of the security and then key pair, and then it's going to have... where is it?

01:21:45.230 --> 01:21:47.110
The Ubuntu host right here.

01:21:47.330 --> 01:21:51.590
Now, this instance type and... I'm sorry, the AMI will get configured here in a minute.

01:21:51.590 --> 01:21:57.230
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:07.550
But thankfully, what we have here is a launch SO script, and what this is going to do, this is actually going to grab the latest AMI.

01:22:07.550 --> 01:22:20.870
It's going to substitute that in for that AMI in that file, and then it's also going to try to determine your public IP address, 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:23.790
So you don't really have to touch it a whole lot.

01:22:23.890 --> 01:22:28.470
Otherwise, you can go inside of that file, that TFR's file, and modify it yourself.

01:22:29.150 --> 01:22:40.830
So we're going to go ahead and click sudo launch so, and what it's going to do, it's going to run behind the scenes a Terraform init to initialize Terraform in this directory.

01:22:40.850 --> 01:22:50.850
It's going to also do the things I mentioned a second ago, and then also a Terraform apply auto approve so that it goes ahead and runs that action.

01:22:50.870 --> 01:23:06.310
And now what it's doing is creating that entire VPC, it's creating the subnets, it's creating the security groups, it's creating the instances, the mirror config, and auto mirror lambda function, and it's doing all of that behind the scenes.

01:23:06.610 --> 01:23:11.950
It may take a few minutes, so you know, if you see it sit there for just a couple minutes, that's normal.

01:23:12.990 --> 01:23:16.750
Wes, we do have a question that came up.

01:23:20.030 --> 01:23:21.770
It's one dumb question.

01:23:21.770 --> 01:23:26.010
Is it possible to make it work like a host intrusion prevention system?

01:23:26.010 --> 01:23:31.350
If not, are there any open source projects that can do that?

01:23:31.510 --> 01:23:38.730
Yeah, yeah, so I mean you can also not use the nids, the sensor components at all, right?

01:23:38.730 --> 01:23:47.370
You can send up security engine and only 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:23:55.890
Absolutely.

01:24:01.730 --> 01:24:05.730
Okay, so let me go ahead and copy that.

01:24:05.730 --> 01:24:14.130
So now you see that we now already, instead of spending the time, you know, going and configuring this manually, we now already have these

01:24:21.160 --> 01:24:25.820
ready to go, right?

01:24:25.900 --> 01:24:28.040
And what did I do?

01:24:28.120 --> 01:24:29.420
Exit it?

01:24:34.010 --> 01:24:37.310
Hmm, what did I... I did something wrong.

01:24:37.310 --> 01:24:38.430
Let's see.

01:24:40.540 --> 01:24:41.460
Hmm.

01:24:43.740 --> 01:24:45.480
Dee dee dee dee.

01:24:45.480 --> 01:24:46.700
What am I doing?

01:24:47.440 --> 01:24:57.270
Let's just get that out of there.

01:24:57.270 --> 01:24:58.210
Typos.

01:24:58.230 --> 01:24:59.810
Typos galore.

01:25:00.970 --> 01:25:02.270
WLAM root.

01:25:03.530 --> 01:25:05.470
Hmm, okay, well that's strange.

01:25:05.470 --> 01:25:06.910
I tested this.

01:25:07.010 --> 01:25:10.650
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:24.060
SSHI security.

01:25:24.060 --> 01:25:25.180
Do I have a typo?

01:25:33.050 --> 01:25:35.070
Okay, that's why.

01:25:35.850 --> 01:25:35.950
Okay.

01:25:38.550 --> 01:25:44.410
Okay, so I've actually... I must have the same public IP in here and then host.

01:25:44.670 --> 01:25:45.350
Let's see.

01:25:47.350 --> 01:25:48.950
Listen and host.

01:25:49.450 --> 01:25:52.350
Okay, let me take a step back real quick.

01:25:54.590 --> 01:25:55.330
And do

01:26:04.230 --> 01:26:06.970
a SSHI.

01:26:11.850 --> 01:26:13.650
Okay, so let's try this one.

01:26:13.650 --> 01:26:15.090
See if this one works.

01:26:28.630 --> 01:26:31.210
Okay, so something with the permission of the key.

01:26:31.310 --> 01:26:31.750
Let me...

01:26:32.550 --> 01:26:33.250
All

01:26:36.730 --> 01:26:44.210
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:19.130
There we go.

01:27:19.170 --> 01:27:24.170
All right, so basically, that's how it works there.

01:27:24.170 --> 01:27:27.550
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:55.410
All right, so onion at security, onion zero.

01:27:55.410 --> 01:27:58.470
That's going to be the security and then host, right?

01:27:58.470 --> 01:28:02.110
So we could go ahead, if we wanted to, just get the interface up.

01:28:02.330 --> 01:28:04.510
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:28.270
validate.

01:28:29.690 --> 01:28:35.790
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:12.630
Again, I wanted you to get the feel and get the understanding of how to build that manually, 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:29.530
And then if we want to go over real quick, just to view it while we wait for the reboot, 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:03.510
And once again, you know, obviously, if we run something like testmyniz and generate a bunch of traffic,

01:31:07.560 --> 01:31:09.700
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.640
But again, you can kind of see how easy it is to sand this stuff up and have it automatically mirrored.

01:31:23.640 --> 01:31:34.620
So I would definitely recommend that you check out the Terraform stuff and AutoMirror in general, 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:51.940
But feel free, if you have some time and you want to experiment, and please do offer any 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:24.200
So it's yet another way to quickly and easily spin up security in Google Cloud and do a very 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:46.450
we write the PCAPs to disk, they are VXLAN encapsulated, but we just don't have the technology in the current platform to actually render that ASCII transcript.

01:32:46.710 --> 01:32:56.430
But if you would like to take the PCAP and be able to import it into other tools that also don't understand VXLAN encapsulation, you can use VXLAN to PCAP.

01:32:56.890 --> 01:33:00.670
And I'm sorry, I should play from the current slide and make that a little bit bigger for 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:12.970
It will take off that VXLAN wrapper, and then you're left with the PCAP that you would normally see on the wire if it was not transported by VXLAN.

01:33:13.550 --> 01:33:22.570
So that's another pretty cool tool to be able to use if you've got VXLAN encapsulated PCAP 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:39.000
You can absolutely use a miter attack cloud matrix with some of this stuff when you're pulling this stuff in, right?

01:33:39.000 --> 01:33:49.020
And when you're pulling in cloud trail data, when you're pulling in NSM data, you can create detections with Elastic Alert rules.

01:33:49.020 --> 01:33:59.340
You can use Sigmac from the Sigma authors to convert this to Elastic Alert rules and base those on those techniques and tactics, right?

01:33:59.600 --> 01:34:04.840
And then you can test those detections using something like Atomic Red Team, right, if you want to do that.

01:34:04.840 --> 01:34:16.520
And we've got some really exciting stuff coming up in the next release of Security Onion 2.0, which is in plans to be released hopefully soon.

01:34:16.640 --> 01:34:26.500
Right now we have an RC1 release, Candidate 1 release, of Security Onion 2.0 that you 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:38.200
Playbook is going to be basically taking the Sigma rules and converting them to Elastic 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:59.000
Being able to go in there and have those events fire from the Sigma rules and then have them 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:33.420
And then if you want to download, obviously, the current platform on Security On-End, 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:57.460
And then if you're already using Security On-End or you really want more help figuring out how to set it up in the cloud or you want training or support, then we have professional services available for that as well if you need that.

01:35:57.460 --> 01:36:09.700
But anything else, if you have any other questions or feedback, anything else, just feel free to reach out to me at the real W.

01:36:09.700 --> 01:36:11.200
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.