Stealthwatch Enterprise can be leveraged to monitor vulnerable devices, and alert on potential exploitation by bad actors looking to exploit Ripple20 and other potential vulnerabilities.
Note that the concepts and procedures outlined here can be used for many different situations wherein the monitoring of segmentation and allowed/disallowed communication is desired.
For this specific scenario, there are 3 components required for Stealthwatch:
For purposes of this example, we’ll say that there are IOT devices identified as being potentially vulnerable that manage HVAC function that are only assigned IP addresses in 10.201.3.0/24.
Additionally, there are IOT devices used to control industrial processes at three different locations, also only assigned to the following ranges:
The HVAC devices should not be communicating to anything but an internally hosted control server, assigned to IP address 10.201.10.100 over port 2030/tcp and a third-party external control service hosted at 126.96.36.199, over port 3440/tcp.
Additionally, the industrial controller IOT devices should only be communicating to an internal control server with the IP address 10.201.10.110 over ports 4040/tcp and 6070/tcp.
The IP and/or range(s) of IP addresses of the devices to monitor need to be defined within Stealthwatch’s Host Group structure.
NOTE: The best practice for this would be to create group(s) for the monitored IOT devices under the By Function parent host group.
For additional granularity, if you have the device IP space carved up into groupings for specific devices, you could define them into separate host groups beneath the parent host group for IOT devices.
In this way, you could assign overarching monitoring policies across all IOT devices while giving yourself the option of more granular management. This will also help in identifying device type when investigating activity.
Like what was done for the IOT devices, we will now create host groups for the Industrial Devices Controller and HVAC Controller servers.
NOTE: Since these are internal servers, best practice would be to create a Host Groups for them beneath Inside Hosts > By Function > Servers parent host group.
Similarly, for our internal hosts we wanted to track we will now create a host group for the external/3rd party HVAC Control Service that the HVAC Devices communicate with as part of their normal function.
NOTE: Since this server/service is outside the control of your organization, best practice would be to organize this under the Outside Hosts > Trusted Internet Hosts parent host group, as it is a resource that hosts within your environment will be making use of and is trusted.
Now that the proper host groups have been defined for the hosts to be monitored and their related servers and services, we will now make use of Stealthwatch’s Custom Application feature to define the traffic to the management resources, to easily build policy around the allowed communications.
Now that we have organized the hosts, services and traffic we’d like to monitor, we will now model the desired policy within Stealthwatch so it will alert on violations.
NOTE: When creating CSEs, you should run a similar flow query for the last 24 hours, as the results will show the number of events that would have been generated.
To define this policy in Stealthwatch:
NOTE: Best practice for naming a custom security event is to preface the name with .CSE.
This makes it easier to identify in reporting and alarming.
Once the Custom Security Events are enabled, Stealthwatch will display violations on the main Network Security dashboard.
They are categorized as their own specific Event type, as well as a Policy Violation.
These alarms can also be tied into Stealthwatch’s built in Response Management and reporting functionalities, as desired.
In the scenario described above, defining a Custom Application was done to overcome a limitation in defining Custom Security Event parameters: specifically, the inability to include certain “OR” type conditions in a single defined event. Many of the parameters can have multiple conditions, but they can’t span different items; e.g. - specific ports for one host group and specific ports for another host group in the same CSE.
For the Industrial IOT devices that communicated to a single host group over multiple ports, you can define policy without having to create a Custom Application type, using the parameters as shown below.