WEBVTT 00:00:01.940 --> 00:00:03.180 For this demonstration, 00:00:03.500 --> 00:00:07.340 we are going to look at why it can be important to create a decoy network, 00:00:07.340 --> 00:00:08.860 and within that network, 00:00:08.860 --> 00:00:13.160 deploy cloud services to see how an adversary might exploit those resources. 00:00:14.240 --> 00:00:17.720 Then we will perform an assessment using Prowler that will look at 00:00:17.720 --> 00:00:19.710 the configuration of your cloud environment, 00:00:20.130 --> 00:00:23.350 specifically looking at services that may be exposed to the internet. 00:00:24.240 --> 00:00:26.160 This is an important assessment, 00:00:26.160 --> 00:00:30.130 as internet exposed services may be more vulnerable to attack from 00:00:30.130 --> 00:00:32.759 any threat actor who has access to the internet. 00:00:34.340 --> 00:00:36.050 So why create a decoy network? 00:00:36.940 --> 00:00:40.150 Decoy networks can be an effective strategy that can give 00:00:40.150 --> 00:00:43.700 security teams advanced warning your organization is being 00:00:43.700 --> 00:00:45.160 targeted by threat actors. 00:00:45.940 --> 00:00:48.570 They can also deflect attention away from your more 00:00:48.570 --> 00:00:50.160 sensitive cloud environments. 00:00:51.040 --> 00:00:54.660 A decoy network can be as simple or as complicated as you want, 00:00:55.210 --> 00:00:57.870 and it very much depends on the needs of your organization, 00:00:57.870 --> 00:01:00.960 and what your organization is the most afraid of. 00:01:01.940 --> 00:01:04.330 This demo will not give a step‑by‑step guide to 00:01:04.330 --> 00:01:06.420 creating a decoy network in the cloud, 00:01:07.140 --> 00:01:10.160 because it really does vary on organizational requirements. 00:01:11.140 --> 00:01:11.750 Also, 00:01:11.750 --> 00:01:14.150 there are specific Pluralsight courses that cover 00:01:14.150 --> 00:01:15.760 cloud infrastructure management. 00:01:16.540 --> 00:01:18.160 Let's look at this high‑level design, 00:01:18.640 --> 00:01:20.830 which includes some of the core components you would 00:01:20.830 --> 00:01:22.660 expect to see in a decoy network. 00:01:23.740 --> 00:01:26.260 Firstly, you may want to have a separate cloud account, 00:01:26.940 --> 00:01:30.360 and this account is in no way connected with any business environments. 00:01:30.940 --> 00:01:32.960 Next, you'll want a separate network. 00:01:32.960 --> 00:01:37.850 Here this is represented by a virtual private cloud known as a VPC. 00:01:38.840 --> 00:01:41.110 This VPC contains an internet gateway, 00:01:41.540 --> 00:01:44.060 which means the network is routable to the internet, 00:01:44.640 --> 00:01:48.920 and we need this so our threat actors can find the exposed internet services. 00:01:48.920 --> 00:01:53.510 Within the VPC, you could have one or many networks divided into subnets, 00:01:53.760 --> 00:01:55.560 and here I'm using one subnet. 00:01:56.120 --> 00:01:57.400 And then within the subnet, 00:01:57.650 --> 00:02:01.990 you can deploy as many cloud services as required. In this demo, 00:02:01.990 --> 00:02:06.220 one of the decoy systems will be a Linux machine with SSH access. 00:02:06.220 --> 00:02:09.440 Within your environment, you can have, for example, 00:02:09.449 --> 00:02:13.880 a server with exposed database services, or a website that gives the 00:02:13.880 --> 00:02:16.560 appearance of being the company human resource system. 00:02:17.140 --> 00:02:18.440 When creating decoy systems, 00:02:19.250 --> 00:02:23.140 you're only limited by your imagination. And then finally, 00:02:23.470 --> 00:02:25.380 you're going to want some method to monitor. 00:02:26.140 --> 00:02:29.300 This is usually done through logging events. Again, 00:02:29.300 --> 00:02:32.120 logging and monitoring is outside of the scope of this 00:02:32.120 --> 00:02:34.480 course, but I will demonstrate logging the connection 00:02:34.480 --> 00:02:36.360 attempts to the decoy environment. 00:02:36.840 --> 00:02:38.990 You can always monitor for more specific events, 00:02:38.990 --> 00:02:43.590 like brute‑force password attempts against a fake HR system, or the 00:02:43.590 --> 00:02:45.960 more relevant events based on your requirements. 00:02:48.740 --> 00:02:49.210 Okay, 00:02:49.210 --> 00:02:52.380 so now let's quickly review for awareness what an example 00:02:52.380 --> 00:02:54.780 decoy system looks like within AWS. 00:02:55.640 --> 00:02:58.450 This is a Linux system with SSH access, 00:02:59.040 --> 00:03:01.960 but it can be anything you want. Looking at my EC2 00:03:01.960 --> 00:03:04.350 instance here, we can see it's running. 00:03:04.840 --> 00:03:09.060 It has a public IP address, and it's publicly discoverable on the internet. 00:03:09.940 --> 00:03:14.160 This is within a VPC instance I have called DecoyNetwork, 00:03:14.810 --> 00:03:18.070 and is using a subnet called DecoySubnet1. 00:03:20.140 --> 00:03:24.460 Let's look at the security settings for this EC2 instance. I have created 00:03:24.460 --> 00:03:28.660 a unique security group called decoyLinuxSSHInstances, 00:03:29.250 --> 00:03:30.420 and within that group, 00:03:30.520 --> 00:03:34.350 I'm allowing connections to services available on port 22, 00:03:34.350 --> 00:03:37.350 and I am allowing any outbound traffic. 00:03:38.840 --> 00:03:43.960 So that's the EC2 instance running as a decoy system. I want to 00:03:43.960 --> 00:03:47.660 see who is trying to connect to the decoy system because this may 00:03:47.660 --> 00:03:50.510 warn me of attackers. To do that, 00:03:50.520 --> 00:03:54.350 I have enabled the VPC flow logs for the decoy network. 00:03:55.350 --> 00:03:57.920 Those logs are being sent to my CloudWatch service, 00:03:58.540 --> 00:04:03.160 and the logs are stored in a log group I have called decoyNetworkLogGroup. 00:04:03.840 --> 00:04:06.560 From here, I can search and alert on the logs. 00:04:07.110 --> 00:04:10.250 This example I'm using will generate a lot of traffic, 00:04:10.640 --> 00:04:14.810 but more specific decoy systems can be created to generate specific 00:04:14.810 --> 00:04:17.260 logging and alerting to your own requirements. 00:04:17.940 --> 00:04:22.170 Now let's perform an assessment using Prowler. Prowler as an 00:04:22.170 --> 00:04:26.210 assessment tool will identify potential security misconfigurations, 00:04:26.560 --> 00:04:28.760 just like you've seen in the decoy network. 00:04:29.440 --> 00:04:33.590 Prowler will alert on these misconfigurations so that security teams can 00:04:33.590 --> 00:04:38.190 assess and take appropriate action to secure. Here, I'm running Prowler to 00:04:38.190 --> 00:04:43.400 only check for exposed port 22 inbound access. Prowler will assess each of 00:04:43.400 --> 00:04:45.860 the regions within my AWS account, 00:04:46.540 --> 00:04:49.540 and you can see the results. Regions where security 00:04:49.540 --> 00:04:52.500 misconfigurations are not found are shown as a pass. 00:04:54.640 --> 00:04:58.160 One reason to limit an assessment to only the required checks 00:04:58.460 --> 00:05:00.760 is that it reduces the time to complete. 00:05:01.740 --> 00:05:04.200 Other assessments could be performed using Prowler, 00:05:04.640 --> 00:05:08.250 but it's important to focus assessments on the needs of your business. 00:05:08.940 --> 00:05:11.110 It's very easy to use Prowler as a tool, 00:05:11.420 --> 00:05:14.660 but it's much more time consuming to read through all of the reports. 00:05:15.340 --> 00:05:20.360 Thankfully, my example organization is really only concerned about SSH access. 00:05:23.740 --> 00:05:27.660 So now we can see some of the results are highlighted in red as a fail. 00:05:28.600 --> 00:05:32.210 This means a potential security misconfiguration has been identified. 00:05:32.940 --> 00:05:36.630 The security team will need to verify the results, and maybe take 00:05:36.630 --> 00:05:39.660 corrective action to update the security group rules. 00:05:40.840 --> 00:05:45.060 Also listed in the results is a security group for the decoy network. 00:05:45.440 --> 00:05:48.420 This is a useful verification of the Prowler tool, 00:05:48.690 --> 00:05:50.950 and you need to make sure this is not corrected. 00:05:51.290 --> 00:05:51.920 Otherwise, 00:05:51.920 --> 00:05:56.450 the decoy network will no longer function if the security rules are removed. 00:05:57.740 --> 00:05:58.150 Okay, 00:05:58.150 --> 00:06:01.300 so that concludes this demonstration, how to defend and 00:06:01.300 --> 00:06:03.450 assess for internet exposed services. 00:06:04.140 --> 00:06:08.360 Next up, we'll look at performing an AWS benchmark assessment using Prowler.