[00:02.640 --> 00:06.700] Hi, this is Austin Scott. And this is five quick wins for [00:06.700 --> 00:11.200] improving your ICS cybersecurity posture. I'm a Principal [00:11.200 --> 00:14.240] Industrial Penetration Tester as part of the Dragos [00:14.240 --> 00:18.900] Professional Services team. And I really see the world from the [00:18.900 --> 00:22.760] perspective as a pen tester, just like a hammer sees the [00:22.760 --> 00:26.840] world as a nail. I really see everything from an adversarial [00:26.840 --> 00:30.860] perspective. And that's the point of view we'll be taking in [00:30.860 --> 00:34.840] this presentation today. Really, we're looking for ways [00:34.840 --> 00:39.220] to make it more difficult for an adversary to move through an [00:39.220 --> 00:42.820] ICS environment. Now, my recommendations in and of [00:42.820 --> 00:45.780] themselves won't give you a bulletproof cybersecurity [00:45.780 --> 00:49.780] program or industrial cybersecurity program. But they [00:49.780 --> 00:53.240] will raise the bar for your security posture. Of course, [00:53.240 --> 00:55.400] there's a lot of other things involved in running an [00:55.400 --> 00:58.800] industrial cybersecurity program that are outside of the scope of [00:58.800 --> 01:02.120] this presentation. But in my presentation today, we're going [01:02.120 --> 01:04.540] to talk about a lot of the common things that as an [01:04.540 --> 01:08.320] industrial penetration tester, as an industrial cybersecurity [01:08.320 --> 01:12.320] assessment, practitioner, these are the things that we see over [01:12.320 --> 01:15.740] and over again. And a lot of them can be addressed fairly [01:15.740 --> 01:21.200] easily without a lot of capital or operational expenditure. So [01:21.200 --> 01:24.840] we'll talk about how to address some of these risks and what [01:24.840 --> 01:30.400] these common issues that we identify are. So a lot of this [01:30.400 --> 01:36.500] is based on the 2019 Dragos year in review report. We see a lot [01:36.500 --> 01:40.980] of these common issues as we do assessment after assessment. [01:40.980 --> 01:46.440] It's common to see things like limited visibility or credentials [01:46.440 --> 01:50.540] laying around or routable connections from your corporate [01:50.540 --> 01:56.240] environment into the ICS environment, and even ICS [01:56.240 --> 01:59.900] components directly accessible from the internet these days. So [02:00.760 --> 02:03.180] a lot of these common findings are highlighted in this year in [02:03.180 --> 02:06.120] review report. And we'll be talking about the top five and [02:06.120 --> 02:10.400] how to really address those or identify them in your own [02:10.400 --> 02:16.440] environment and remediate them. So we think it's important to [02:16.440 --> 02:22.080] take a threat-based approach when you're looking at risk in [02:22.080 --> 02:27.300] your industrial cybersecurity environment. Now within Dragos, [02:27.300 --> 02:31.020] we track a number of activity groups that target these [02:31.020 --> 02:34.040] environments. And this will be really done from the perspective [02:34.040 --> 02:39.960] of our own internal activity group called Kyberite, where we [02:39.960 --> 02:44.500] develop our ICS tactics and techniques, really based on a [02:44.500 --> 02:46.700] lot of the other activity groups that we see. So we try to do [02:46.700 --> 02:49.140] some threat emulation as we're working through these networks [02:49.140 --> 02:54.660] and use a lot of the common techniques that we see being [02:54.660 --> 03:03.300] used against ICS environments. And of course, tactics, [03:03.300 --> 03:08.380] techniques and procedures are part of the equation. But we [03:08.380 --> 03:11.140] find these really change depending on the environment [03:11.140 --> 03:15.160] that you have. And it's important to, of course, start [03:15.160 --> 03:18.020] with understanding what you have, whether you're running [03:18.020 --> 03:21.200] Windows Active Directory or Windows Workgroup, what kind of [03:21.200 --> 03:25.300] security controls you have, how the internet access works, how [03:25.300 --> 03:28.860] industrial vendors get in, what your firewall rules look like. [03:28.860 --> 03:33.880] Once you understand these basic environmental factors, and [03:33.880 --> 03:38.020] understand how they change the tactics and techniques of an [03:38.020 --> 03:42.280] activity group, that can really help you reduce your risk and [03:42.280 --> 03:46.600] understand where you need to invest your time and energy to [03:46.600 --> 03:52.000] mitigate some of these risks. Of course, if you if you study [03:52.000 --> 03:56.000] activity groups like Electrum and Xenotime, there are publicly [03:56.000 --> 04:01.720] known techniques that they have used against environments. And I [04:01.720 --> 04:04.080] certainly believe those techniques would change [04:04.080 --> 04:08.000] depending on what was available. As a pen tester, as an [04:08.000 --> 04:11.640] adversary, we're always very dynamic with our approach, we [04:11.640 --> 04:17.400] need to roll with the punches and adjust our techniques to [04:17.400 --> 04:21.720] align with the environment we're faced with. So that's why it's [04:21.720 --> 04:24.800] not one size fits all, you can't take all these TTPs that are [04:24.800 --> 04:28.840] identified and directly apply them to your environment [04:28.840 --> 04:33.540] necessarily. Often the environment dictates what the [04:33.540 --> 04:40.060] TTPs are going to be used, which TTPs are going to be used. So [04:40.060 --> 04:43.980] during this presentation, we'll be talking about our top five [04:43.980 --> 04:48.280] ICS assessment findings for 2019. These are related to [04:48.280 --> 04:52.020] firewall rules, access management, system hardening, [04:52.020 --> 04:55.100] logging and network visibility. So we'll be talking about some [04:55.100 --> 04:58.160] of the tools that we use as penetration testers and ICS [04:58.160 --> 05:01.940] network assessment professionals, some of the tools [05:01.940 --> 05:05.880] that can be used safely in ICS environments without introducing [05:06.760 --> 05:10.860] operational risk or very, at the very least, minimal operational [05:10.860 --> 05:15.800] risk when they are being leveraged in these environments, [05:15.800 --> 05:19.200] how to identify these risks using these tools, and then also [05:19.200 --> 05:24.680] how to mitigate some of these common findings. So at the end [05:24.680 --> 05:29.820] of the day, if you're able to take ownership of your [05:29.820 --> 05:34.540] industrial cybersecurity posture, do some self assessment [05:34.540 --> 05:38.340] work. It's not difficult to do once you understand what tools [05:38.340 --> 05:43.900] are available and how to approach some of these problems [05:44.420 --> 05:47.080] and highlight some of these problems. If you're able to [05:47.080 --> 05:51.200] mitigate a lot of these common issues, even prior to doing [05:51.200 --> 05:54.200] another assessment, it allows that red team or that [05:54.200 --> 05:57.400] penetration testing team or that assessment team to really focus [05:57.400 --> 06:00.080] on the more interesting problems. So you're getting rid [06:00.080 --> 06:04.140] of all the low hanging fruit. So the adversary group has to dig [06:04.220 --> 06:08.260] a lot deeper and focus on some of the more challenging [06:08.260 --> 06:13.080] problems. And you're also raising the bar like when you [06:13.080 --> 06:16.180] when you address a lot of these low hanging fruit, a lot of [06:16.180 --> 06:22.260] these low level issues, it really reduces the playbook that [06:22.260 --> 06:27.440] the adversary can can use. They're not able to fall back on [06:27.440 --> 06:33.120] their normal, normal operating plans, they need to think [06:33.120 --> 06:35.920] outside the box a little more, they need to experiment more, do [06:35.920 --> 06:38.280] more reconnaissance. And whenever they do that, when they [06:38.280 --> 06:42.400] have to work harder, you have more opportunities to detect [06:42.400 --> 06:45.800] them, you have more opportunities to stop them. And [06:48.460 --> 06:51.140] and also you make their lives a lot more difficult, which is, [06:51.140 --> 06:53.840] you know, something you want to do. You want these, these [06:53.840 --> 06:56.860] adversaries who are targeting critical infrastructure, who [06:56.860 --> 06:59.800] are trying to turn the lights off in your in your town or, or [06:59.800 --> 07:04.540] impact these important industrial processes, you want [07:04.540 --> 07:07.960] them to have to lay in bed at night, questioning their life [07:07.960 --> 07:12.220] choices that brought them to that position of why they're [07:12.220 --> 07:16.680] targeting civilian infrastructure. So starting off [07:16.680 --> 07:21.120] with firewall rules, what we see when we do these assessments, [07:21.120 --> 07:26.880] often will ask for the the rules to be shared with us. Usually [07:26.880 --> 07:31.680] like a white box approach is best. When we're doing ICS [07:31.680 --> 07:34.860] assessments, we really need to be transparent with the [07:34.860 --> 07:39.940] operating operators, the sites, and the site personnel. Turns [07:39.940 --> 07:44.220] out, industrial asset owners and industrial operators don't like [07:44.220 --> 07:49.140] surprises. So we found that it's very important to be open and [07:49.140 --> 07:52.280] clear with what we're doing, whenever we're doing it within [07:52.280 --> 07:57.900] these ICS assessments. The more information we can share, the [07:57.900 --> 08:02.640] more we can work closely with the operations team and start to [08:02.640 --> 08:07.680] build that trust and that build that bridge between the [08:08.320 --> 08:12.900] cybersecurity team and the OT or the ICS operations team, which [08:12.900 --> 08:16.660] is which is so important to be successful in this environment. [08:16.800 --> 08:20.600] So when we ask for these firewall rules, we'll usually [08:20.600 --> 08:26.180] use a tool to make sense of them. There's dozens of different [08:26.180 --> 08:30.100] firewalls out there and they all provide their rules in different [08:30.100 --> 08:33.280] formats. Fortunately, there are some commercial tools that you [08:33.280 --> 08:36.880] can use and even some free tools you can use to make sense of [08:36.880 --> 08:39.600] these rules and work through them in more of an Excel [08:39.600 --> 08:44.240] spreadsheet kind of format. One free tool we like to use is the [08:44.240 --> 08:48.980] SolarWinds free firewall browser. So what you can do is [08:48.980 --> 08:52.500] export your firewall rules and then import them using this [08:52.500 --> 08:57.120] SolarWinds free firewall browser and then just go kind of line by [08:57.120 --> 09:02.440] line. What you're really looking for is interactive protocols [09:02.440 --> 09:08.780] that allow remote access between your different trust zones. So [09:08.780 --> 09:12.740] typically between your corporate network and your ICS network, or [09:12.740 --> 09:15.850] even between different trust zones within the ICS network. [09:16.430 --> 09:20.770] You're looking for SSH, Telnet, remote desktop, VNC, even things [09:20.770 --> 09:27.430] like WMI or remote management, RPC, SMB, even protocols like [09:27.430 --> 09:33.490] OPC, like OPCDA, the older OPC protocols can allow remote [09:33.490 --> 09:42.510] access and often do. So we often find there are temporary [09:42.510 --> 09:49.530] firewall rules still in these configurations from the time of [09:49.530 --> 09:53.810] commissioning, we find there's vendor dictated rules and vendor [09:53.810 --> 09:56.110] access rules that have never really been evaluated or [09:56.110 --> 09:58.850] questioned. So it's important to go line by line and really [09:58.850 --> 10:01.390] question why do we have this? Like what, what purpose does it [10:01.390 --> 10:04.270] serve? Who's using this? And to knock off as many of those [10:04.270 --> 10:09.990] temporary or vendor dictated rules as you can. Of course, you [10:09.990 --> 10:12.890] want to communicate with your vendor, if that vendor is using [10:12.890 --> 10:18.270] that for remote access, you want to identify those and make sure [10:18.270 --> 10:22.270] they are still able to access or maybe propose a more secure [10:22.270 --> 10:27.950] method if the method that you're using is introducing risk in [10:27.950 --> 10:32.550] your environment. So this is what the free firewall browser [10:32.550 --> 10:36.850] looks like. It just breaks down the rules line by line in sort [10:36.850 --> 10:39.590] of an Excel spreadsheet format. And you can see we've got a [10:39.590 --> 10:44.530] couple interesting interactive rules here on 3389, which is the [10:44.530 --> 10:47.690] remote desktop protocol. So things to watch out for when [10:47.690 --> 10:51.230] you're going through these assessments. There's commercial [10:51.230 --> 10:54.130] tools you can use as well like Nipper that can help you [10:54.130 --> 11:00.990] identify issues. Often we still find any rules or what's [11:00.990 --> 11:03.850] equivalent to any rules. Sometimes these firewall rules [11:03.850 --> 11:08.210] can get quite complicated. And you put enough rules overlapping [11:08.210 --> 11:12.070] on top of each other and it can basically equate to any rule. [11:12.070 --> 11:15.170] So it's important to study these firewall rules closely and [11:15.170 --> 11:18.970] identify opportunities to pivot through these different trust [11:18.970 --> 11:25.570] zones. Now another common issue that we run into is access [11:25.570 --> 11:31.610] management. And what we really find is it's not necessary most [11:31.610 --> 11:40.210] of the time to use any exploits or have to dig too deep in [11:40.210 --> 11:47.430] these ICS networks to pivot or escalate privilege because the [11:47.430 --> 11:52.250] access management is so poor in these environments. Often we'll [11:52.250 --> 11:58.010] run into shared Active Directory environments between corporate [11:58.010 --> 12:03.730] and the ICS. So once we take that corporate Active Directory [12:03.730 --> 12:06.190] environment, we're able to easily pivot and take full [12:06.190 --> 12:09.810] control over the ICS environment. Other situations where there is [12:09.970 --> 12:13.290] a dedicated Active Directory environment in the ICS, it's [12:13.290 --> 12:17.970] poorly maintained and hasn't really been configured properly. [12:17.970 --> 12:21.330] So usually we see almost everybody's a domain admin or [12:21.330 --> 12:24.430] there's lots of service accounts that are domain admins. Lots of [12:24.430 --> 12:29.790] these common issues in Active Directory that we run into. So [12:29.790 --> 12:32.990] what do you do? How do you identify these issues? Well, what [12:32.990 --> 12:37.690] we typically do is run a tool called Bloodhound. Now it's a [12:37.690 --> 12:43.350] free open source tool and it's been used by pen testing teams [12:43.350 --> 12:49.450] and red teams to unravel the yarn ball that is Active [12:49.450 --> 12:53.190] Directory. For years, Active Directory kind of experienced [12:53.190 --> 12:57.650] this security through obscurity where it's so complicated that [12:57.650 --> 13:00.850] even the adversaries couldn't really figure out all of the [13:00.850 --> 13:03.810] groups and groups and users and groups and how all those [13:03.810 --> 13:06.570] unwind to different permission levels. But with the [13:06.570 --> 13:10.670] introduction of Bloodhound, this tool uses graph theory to [13:11.370 --> 13:14.490] really map out what the implications of all these [13:14.490 --> 13:19.050] permissions are, how to unravel all these groups to determine [13:19.050 --> 13:22.670] who's really a domain admin and how you can pivot from the [13:22.670 --> 13:26.870] average user to domain admin fairly easily. So it shows you [13:26.870 --> 13:29.430] all these different paths and overprivileged accounts that [13:29.430 --> 13:32.570] you can identify and potentially lock down. And it's fairly [13:32.570 --> 13:35.830] safe, too. There's a very low operational risk because it [13:35.830 --> 13:39.330] only communicates with the Active Directory server in the [13:39.330 --> 13:41.850] network. It's not going to scan your network or hit all the [13:41.850 --> 13:44.590] PLCs in your network or anything like that. It's only going to [13:44.590 --> 13:48.590] communicate with the Active Directory environment. And it's [13:48.590 --> 13:51.870] only going to send LDAP requests, which are fairly [13:51.870 --> 13:55.270] normal. It's just the same kind of network activity that you [13:55.270 --> 13:59.390] would introduce if you were logging into a machine or remote [13:59.390 --> 14:03.470] desktoping into a machine. It's nothing unusual for that [14:03.470 --> 14:08.430] environment. There's certainly a big spike of LDAP when you use [14:08.430 --> 14:11.510] that tool, but it's nothing that would create an operational [14:11.510 --> 14:16.690] risk in that environment. So what does that look like? So [14:16.690 --> 14:21.430] here's an example of Bloodhound unraveling a path to the domain [14:21.430 --> 14:26.490] admin from this RTAM user. We can see he's a member of this [14:26.490 --> 14:30.630] group that's an administrator on this machine. And because [14:30.630 --> 14:36.150] they're an admin on this machine, they're able to gain [14:36.730 --> 14:45.170] access to potentially the password or the hash of this [14:45.170 --> 14:48.150] user who is also logged into this machine, and then use that [14:48.150 --> 14:53.950] user's privilege to gain domain administrator access in that [14:53.950 --> 14:57.450] network. So this can really make sense of Active Directory and [14:57.450 --> 15:01.350] help identify some of those common issues and common [15:01.350 --> 15:05.410] misconfigurations. So access management part two. So what if [15:05.410 --> 15:08.270] you don't have Active Directory? What if it's a Windows work [15:08.270 --> 15:11.850] group environment, which is also fairly common to see in ICS? And [15:11.850 --> 15:15.150] even if you do have Active Directory, there's other [15:15.150 --> 15:18.430] passwords that exist outside of Active Directory within these [15:18.430 --> 15:23.150] ICS networks. So I'm talking about things like VNC and SSH, [15:23.150 --> 15:28.670] credentials into switchgear, networkgear, stuff like that. [15:28.750 --> 15:32.170] There's usually passwords just laying around the network and [15:32.170 --> 15:36.710] Excel spreadsheets or notepad files or default credentials for [15:36.850 --> 15:41.830] a lot of devices. Often we find credentials are stored in things [15:41.830 --> 15:47.530] like Chrome or stored in things like Putty or WinSCP or [15:47.530 --> 15:52.470] BatchPatch, or other other tools like that. And when you when you [15:52.470 --> 15:56.070] click that option to save your username and password in these [15:56.070 --> 16:00.650] tools, these tools don't always securely manage those [16:00.650 --> 16:04.270] credentials. So it can be quite trivial for an attacker to pull [16:04.270 --> 16:09.930] out those stored credentials. So what you can do is leverage some [16:09.930 --> 16:15.250] of these client side tools, like Session Gopher that are [16:15.250 --> 16:19.830] free, Session Gopher from FireEye, or even performing [16:19.830 --> 16:23.770] things like an LSAS dump, or using tools like Mimi Cats, Mimi [16:23.770 --> 16:27.570] Kittens, and some of these Nirsoft password utils. Now Mimi [16:27.570 --> 16:30.490] Cats is it's something that's used by almost every activity [16:30.490 --> 16:35.830] group. Once these activity groups get a foothold in an [16:35.830 --> 16:38.850] environment, one of the first things they do is dump their [16:38.850 --> 16:42.590] post exploitation tools. A lot of those are just trying to find [16:42.590 --> 16:46.910] passwords to escalate privilege and move laterally in that [16:46.910 --> 16:50.010] environment. So you want to try to understand how you're storing [16:50.010 --> 16:52.150] your passwords, what passwords are stored on different [16:52.150 --> 16:55.450] endpoints. And you can automate that process just like the [16:55.450 --> 17:01.010] activity groups typically do. So what can you do once you've [17:01.010 --> 17:07.870] identified the issues or the mis-storage of passwords, you [17:07.870 --> 17:13.590] can implement some kind of password storage mechanism, or [17:14.110 --> 17:16.790] a privileged access management system, or even just like a [17:16.790 --> 17:22.650] vault, or a last pass, or some password vault solution that [17:22.770 --> 17:27.110] does a better job protecting these important credentials than [17:28.610 --> 17:36.210] WinSCP, or Putty, or other tools typically do. So here's a quick [17:36.210 --> 17:37.510] example of running Mimi Cats. And it's something I'd [17:37.510 --> 17:43.610] recommend. It's something we always try to do on a safe [17:43.610 --> 17:48.510] environment, running Mimi Cats, just to see if it's detected, if [17:48.510 --> 17:53.630] it triggers any kind of alerts. If we're able to do like what [17:53.630 --> 18:00.950] we're doing here, dump the LSAS memory to a file. So if we dump [18:00.950 --> 18:05.410] the LSAS memory using the task manager, just right click on the [18:06.670 --> 18:11.090] local security authority process and go create dump file, we can [18:11.090 --> 18:15.250] copy that dump file off of the machine and run it through Mimi [18:15.250 --> 18:18.650] Cats to see what kind of passwords we pull out of memory. [18:18.650 --> 18:24.690] If your Windows endpoints are not hardened, you'll usually be [18:24.690 --> 18:31.950] able to pull out the hashes and often clear text passwords from [18:31.950 --> 18:35.390] any account that has recently logged into that machine. So [18:35.390 --> 18:38.830] it can be quite eye opening to to see that and see these [18:38.830 --> 18:42.430] passwords coming through in clear text using Mimi Cats. So [18:42.430 --> 18:47.330] it's something we we recommend that our customers do in a safe [18:47.330 --> 18:51.790] and safe manner. And even just copying the Mimi Cats [18:51.790 --> 18:55.450] executable into one of your ICS assets just to see if it gets [18:55.450 --> 18:58.870] caught by Windows Defender or Norton AV and, and to see if [18:58.870 --> 19:03.330] that alert makes it someplace to see if you know the your [19:04.950 --> 19:08.910] monitoring is set up properly. It should create alerts, it [19:08.910 --> 19:11.290] should set off all kinds of alarm bells. So it's a great way [19:11.290 --> 19:18.590] of testing your, your monitoring, or malicious files [19:18.590 --> 19:23.830] in your ICS network. Here's another example of another tool [19:23.830 --> 19:28.010] the FireEye Session Gopher, it looks for passwords and other [19:28.010 --> 19:34.270] tools like WinSCP and PuTTY and RDP, like your stored passwords [19:34.270 --> 19:39.990] in your remote desktop client. So it'll pull out clear passwords [19:39.990 --> 19:43.070] like we see in this example below. And this can be very [19:43.070 --> 19:46.670] valuable to an adversary who's looking to move laterally or [19:46.670 --> 19:49.890] escalate their privilege in the network. And we almost always, [19:49.890 --> 19:53.290] always find credentials when we're doing these assessments. [19:53.290 --> 19:56.350] One way or another, there's there's always, almost always [19:56.870 --> 20:01.410] poor storage of these credentials. So another thing [20:01.410 --> 20:06.330] that can help address that credential storage issue is some [20:06.950 --> 20:11.210] basic Windows system hardening. It's a very common issue that we [20:11.210 --> 20:14.850] see where a lot of these ICS Windows assets, they haven't [20:14.850 --> 20:18.290] performed any hardening. Often we find things like the firewall [20:18.290 --> 20:22.630] is completely turned off on these Windows endpoints. Just [20:22.630 --> 20:29.170] because these ICS networks are so sensitive at times, once the [20:29.170 --> 20:33.690] operators or the system integrators get things working, [20:33.690 --> 20:36.350] they're afraid to change anything or lock anything down [20:36.350 --> 20:41.590] in case it breaks something. So usually, once they get things [20:41.590 --> 20:45.410] working, they just kind of leave it as is. And it's rare to find [20:45.410 --> 20:49.190] any system hardening really performed. And without some [20:49.190 --> 20:53.070] basic Windows system hardening, it's so easy to cut through [20:53.070 --> 20:57.350] those networks as an adversary. The default Windows [20:58.270 --> 21:01.990] installation, especially Windows 7 and older Windows versions, [21:01.990 --> 21:07.390] there's just so many backwards compatibility features that are [21:07.390 --> 21:10.670] turned on that make it so easy to pull passwords, escalate [21:10.670 --> 21:15.950] privilege to a system that once you're in that network, you can [21:16.480 --> 21:20.510] own it within a matter of minutes without some system [21:20.510 --> 21:41.040] hardening happening. Oops, looks like my internet connection had [21:41.120 --> 21:44.340] a bit of a blip there. I'll start that over. Now system [21:44.340 --> 21:48.140] hardening does have the potential to create an operational [21:48.140 --> 21:51.820] or introduce operational risk, you'll need to work closely with [21:51.820 --> 21:55.480] your vendor to ensure that any hardening you're doing won't [21:55.480 --> 22:00.840] impact your operating process. Often, the major vendors will [22:00.840 --> 22:05.220] have system hardening guides that you can follow, and the [22:05.220 --> 22:11.040] recommended hardening that they have tested and approved. So [22:11.040 --> 22:13.420] it's important when you're building a new greenfield [22:13.420 --> 22:17.020] system, when you're building an ICS system from the ground up [22:17.020 --> 22:21.820] to ask them to implement these system hardening features to [22:21.820 --> 22:25.880] turn security on. Because what we find is if you don't ask the [22:25.880 --> 22:27.900] vendors or the system integrators to do these things, [22:27.900 --> 22:32.540] it just doesn't happen. If you don't set that standard or make [22:32.540 --> 22:36.800] that request, they're not going to do it. So it's very important [22:36.800 --> 22:40.540] to be clear that you want the systems hardened, they need to [22:40.540 --> 22:44.360] be part of their commissioning plan, part of their site [22:44.360 --> 22:47.320] acceptance testing or factory acceptance testing checklist, [22:47.320 --> 22:51.960] that these hardening features are turned on and the [22:51.960 --> 22:54.700] recommended best practices for system hardening for that vendor [22:54.700 --> 22:59.420] have been implemented. And if the vendor does not, if they're [22:59.420 --> 23:04.380] not very mature, and they don't have a hardening guide, you can [23:05.840 --> 23:10.860] you can use some of the tools like some of the ones I've [23:10.860 --> 23:13.600] listed here, like CHAPS, the configuration hardening [23:13.600 --> 23:19.240] assessment, PowerShell script from Cutaway Security, to [23:19.240 --> 23:23.460] identify some of the common hardening issues. And you can [23:23.460 --> 23:30.040] raise those up with the vendor to get them approved or ensure [23:30.040 --> 23:36.380] that they're on board with making these changes. But [23:36.380 --> 23:39.280] there's other tools, Microsoft has a great tool called the [23:39.280 --> 23:41.940] Security Compliance Toolkit, which does a very thorough [23:41.940 --> 23:44.940] analysis, it does require you to install some software in your [23:44.940 --> 23:48.160] ICS environments that could cause some issues with your [23:48.160 --> 23:51.180] vendors, same with the CIS tools and the state tools, they do [23:51.180 --> 23:54.980] require software to be installed in order to make them work. But [23:54.980 --> 23:57.080] that's why I love the CHAPS tool, it's just a PowerShell [23:57.080 --> 23:59.580] script you can run, it doesn't require any software to be [23:59.580 --> 24:04.180] installed, it just will do some data collection on that endpoint [24:04.900 --> 24:09.520] and highlight some of these common hardening issues. So [24:09.520 --> 24:11.680] again, you have to work closely with the vendor when you're [24:11.680 --> 24:13.780] running these things. But here's an example of the CHAPS [24:13.780 --> 24:22.620] hardening demo in action. You can just run it as a PowerShell [24:22.620 --> 24:26.600] command, like I've done above. And then it gives you sort of a [24:26.600 --> 24:31.500] pass fail view, things like W digest DNS client, this, if you [24:31.500 --> 24:35.440] implement these hardening recommendations, it will prevent [24:35.440 --> 24:39.160] an adversary from being able to pull clear text passwords out of [24:39.160 --> 24:45.200] memory, clear hashes out of memory. It'll prevent them from [24:45.200 --> 24:47.860] downgrading to PowerShell 2 and bypassing a lot of the [24:47.860 --> 24:53.180] PowerShell security features. So it also helps reduce the chances [24:53.180 --> 24:55.740] of man-in-the-middle attacks and things like that in your ICS [24:55.740 --> 24:59.720] network. So just a little bit of hardening and lockdown can have [24:59.840 --> 25:07.900] a huge impact. So what we're seeing from a logging [25:07.900 --> 25:11.820] perspective is usually a complete lack of logging, or no [25:11.820 --> 25:14.520] centralized logging. Sometimes logging is turned on on the [25:14.520 --> 25:16.640] Windows endpoints, but it's just not going anywhere. It's just [25:16.640 --> 25:21.460] being stored locally. And if it is turned on and being centrally [25:21.460 --> 25:25.660] managed, they're not always logging the right stuff. In [25:25.660 --> 25:28.640] these ICS environments, they're not logging PowerShell commands [25:28.640 --> 25:32.300] or, or new processes. They're not using things like sysmon to [25:32.300 --> 25:37.120] really get the details you need to do proper forensic analysis [25:37.120 --> 25:41.180] and incident response in these environments. And it's not hard [25:41.180 --> 25:46.280] to do, it's not difficult to turn these, these things on. And [25:46.280 --> 25:49.820] again, that CHAPS tool can help you identify some of the common [25:50.400 --> 25:54.060] logging issues that you may encounter and some of the things [25:54.060 --> 25:58.580] you'll want to turn on in your ICS environments. And really [25:58.580 --> 26:02.220] just having that centrally managed logging environment can [26:02.220 --> 26:07.000] be such a huge win. If you ever are doing like an incident [26:07.000 --> 26:11.560] response, you'll be so grateful to have that centrally managed [26:11.560 --> 26:14.080] logging environment. And it's all built into Windows, you [26:14.080 --> 26:16.180] don't need to have Splunk or anything like that. You can just [26:16.180 --> 26:20.560] use Windows Event Forwarding to centrally manage those those [26:20.560 --> 26:23.560] Windows events without having to spend any extra money. Just [26:23.560 --> 26:27.900] having that those events all in one place can really facilitate [26:27.900 --> 26:32.140] things like threat hunting, and can speed up incident response [26:32.140 --> 26:38.320] and give you better visibility into your ICS network as well. [26:38.860 --> 26:43.500] So what we recommend is understanding what your Windows [26:43.500 --> 26:47.160] event logging capabilities are today, what's being logged, [26:47.160 --> 26:50.520] what's not being logged, where is it going, and using again, [26:50.520 --> 26:55.140] that CHAPS tool can help identify these issues. There's [26:55.140 --> 26:58.460] really a pretty low operational risk. It may produce a little [26:58.460 --> 27:02.060] more traffic on your network. But for most modern networks, [27:02.060 --> 27:09.240] this shouldn't be a huge issue. Now here's the output of that [27:09.240 --> 27:13.360] CHAPS tool again, that PowerShell script. And it can [27:13.360 --> 27:19.420] show you some of the issues if you have the PowerShell task [27:19.420 --> 27:25.680] scheduler, WinRM, WMI activity, all these different log files [27:25.680 --> 27:31.460] are important to have turned on and have a larger log size and [27:31.460 --> 27:33.080] ensure that they're being forwarded to a central [27:33.080 --> 27:36.180] location. So the CHAPS tool can help identify a lot of these [27:36.180 --> 27:41.580] common issues. So if you turn on the recommended logging from [27:41.580 --> 27:44.980] CHAPS, it will make a big difference and reduce your risk [27:44.980 --> 27:51.380] quite a bit. Now on to network visibility. Another common [27:51.380 --> 27:57.120] issue that we see is, as a pen test or a red team, we're able [27:57.120 --> 28:01.360] to operate within these ICS networks undetected. Once we're [28:01.360 --> 28:04.500] in them, there's usually very little or no visibility. So we [28:04.500 --> 28:09.760] can move about, move laterally, escalate privilege, take over [28:09.760 --> 28:16.260] the domain without any alarm bells going off, and maintain [28:16.260 --> 28:23.020] perpetual access as well. So what you can do is, if you don't [28:23.020 --> 28:26.380] have network visibility today, you can start to lay that [28:26.380 --> 28:32.440] foundation and start to see if you get the value out of it in a [28:32.440 --> 28:37.820] low cost sort of introductory kind of method. First of all, if [28:37.820 --> 28:43.400] you just identify the points in your network that you should be [28:43.400 --> 28:46.560] monitoring, what switches you should be attaching or [28:46.560 --> 28:50.700] configuring SPAN ports to, or better yet, purchase some [28:50.700 --> 28:54.960] network TAPs and install them. And just having those, just [28:54.960 --> 28:58.080] having them in your network that you can tap into to collect data [28:58.080 --> 29:02.380] and collect PCAPs, it's extremely valuable in an incident [29:02.380 --> 29:05.980] response, or it's extremely valuable in a threat hunting [29:05.980 --> 29:10.700] exercise. So that can really enable your security operations [29:10.700 --> 29:15.820] team to do a lot more, just knowing where to plug in. That's [29:15.820 --> 29:18.420] the first step in getting that network visibility. And once you [29:18.420 --> 29:21.120] have that, you can start to collect PCAPs and do some [29:21.120 --> 29:23.680] analysis to better understand what's going on, what kind of [29:23.680 --> 29:26.860] traffic you see in your network, what's normal. And then [29:26.860 --> 29:29.460] you can start to use some, even some free tools that are [29:29.460 --> 29:34.820] available, or commercial tools to perform analysis on those [29:34.820 --> 29:38.920] PCAPs, or even install some hardware and software to do [29:38.920 --> 29:45.320] continuous monitoring of that network traffic. And again, it's [29:45.400 --> 29:49.800] a pretty low operational risk. You're connecting to SPAN ports [29:51.400 --> 29:56.200] or TAPs. Now, ideally, we always recommend you use dedicated [29:56.200 --> 30:01.700] TAPs, network TAPs rather than SPAN ports. SPAN ports, when [30:01.700 --> 30:04.780] they're configured on a switch, there is a risk that that switch [30:04.780 --> 30:07.400] can get kind of overloaded, especially if it's an older [30:07.400 --> 30:11.460] piece of equipment. You should be monitoring the CPU usage of [30:11.460 --> 30:15.340] those switches. Once you enable your SPAN port, if they're in [30:15.340 --> 30:21.760] the 80% or 90% utilization, kind of threshold, you may want [30:21.760 --> 30:26.580] to consider an alternate option, because that could just put it [30:26.580 --> 30:30.520] over the edge and create a network outage. So you need to [30:30.520 --> 30:33.280] need to be a little careful with that. But it shouldn't, it [30:33.280 --> 30:40.940] typically doesn't cause too many issues to set up those SPAN [30:40.940 --> 30:44.320] ports. But in some of the edge cases, it could create some or [30:44.320 --> 30:46.560] introduce some operational risks. So something to be aware [30:46.560 --> 30:51.780] of, something to watch. And of course, having visibility in [30:51.780 --> 30:55.020] your network can improve your threat detection and threat [30:55.020 --> 30:59.560] monitoring capability with the right tools and techniques and [30:59.560 --> 31:06.340] procedures. So there are two free products that Dragos [31:07.040 --> 31:12.240] provides. One of the free products is our old Cyber Lens [31:12.240 --> 31:16.520] product, which is it's well suited for PCAP analysis. It was [31:16.520 --> 31:21.060] really designed to just take a PCAP and help visualize what's [31:21.060 --> 31:26.000] inside, specific to the ICS protocols and ICS content. It's [31:26.100 --> 31:29.100] a great way to help you understand what assets are in [31:29.100 --> 31:32.260] your network. That's a common challenge we see in the ICS [31:32.260 --> 31:36.440] space. What do I have? What's on my network at any given time? So [31:36.440 --> 31:40.320] Cyber Lens can help you identify those. And Sophia is designed [31:40.320 --> 31:46.300] for more of the continuous monitoring. Sophia was the next [31:46.300 --> 31:49.980] defense product that was commercially sold to customers [31:49.980 --> 31:53.900] all around the world. And now it's available for free from the [31:53.900 --> 31:56.580] Dragos website. So if you want just continuous asset [31:56.580 --> 31:59.740] identification, monitoring just to know what's on your network [31:59.740 --> 32:02.500] and have that updated perpetually, Sophia is a great [32:02.500 --> 32:06.340] tool for doing that. And of course, there's commercial tools [32:06.340 --> 32:11.480] you can use, like Network Miner to do analysis of PCAPs. That's [32:11.560 --> 32:16.160] a very handy tool for digging into PCAP data. And of course, [32:16.160 --> 32:20.120] the Dragos platform is our commercial product that does a [32:20.120 --> 32:28.640] threat-based monitoring of ICS networks with playbooks and [32:28.640 --> 32:32.660] feeds into our Intel with the latest activity groups that are [32:32.660 --> 32:37.200] targeting these environments. So if you're ready, if you're [32:37.200 --> 32:42.920] seeing the value in your network monitoring, then maybe a [32:42.920 --> 32:46.180] commercial product is the next step for you. But it's always [32:46.180 --> 32:50.000] nice to kind of learn to walk before you run, kind of identify [32:50.000 --> 32:54.420] those spam ports and kind of ease your way into it to make [32:54.420 --> 32:58.520] sure you really see the value and take full advantage of that [32:58.520 --> 33:06.520] value of OT network monitoring. And of course, this is [33:06.520 --> 33:12.820] something these self-checks, these common self-assessments [33:12.820 --> 33:18.040] can be done regularly. And there's there's huge benefits to [33:18.040 --> 33:20.420] taking ownership of these, just doing like some mini [33:20.420 --> 33:24.120] assessments once a year, once every six months, just to see [33:24.120 --> 33:27.720] what's on your network, look at how passwords are stored, [33:27.720 --> 33:34.280] understand who the big accounts in your Active Directory [33:34.280 --> 33:37.660] environment are, who the domain admins are, and who has access [33:37.660 --> 33:41.560] to that. All these things should be done regularly. Once you [33:41.560 --> 33:44.800] really take ownership of your industrial cybersecurity, of [33:44.800 --> 33:49.560] your industrial cyber risk, you can make a big difference in [33:49.560 --> 33:53.600] that risk reduction. You can start to address that. And it's [33:53.600 --> 33:58.020] something that should be done on a regular basis, at a set [33:58.020 --> 34:01.080] interval once a year, once every six months, because ICS [34:01.080 --> 34:04.620] environments are quite dynamic, they do change. They're [34:04.620 --> 34:10.240] constantly being modified and updated and maintained. So it's [34:10.240 --> 34:13.740] good to do this on a regular basis. And it can be augmented [34:13.740 --> 34:17.040] once you get into this self-check and you're covering [34:17.040 --> 34:20.340] off a lot of the low hanging fruit. That's when you can bring [34:20.340 --> 34:24.080] in a professional team to do an assessment. And then they'll get [34:24.080 --> 34:26.760] to really dig into the interesting stuff, the stuff [34:26.760 --> 34:32.460] that is uncommon and would require an adversary to dig a [34:32.460 --> 34:37.800] little deeper, do more research, and have to sweat a little to [34:37.800 --> 34:43.120] move through your network. And that's the end of my [34:43.120 --> 34:46.160] presentation. Thank you so much for attending.