Using Stealthwatch to Monitor IOT devices for exploitation, e.g. – Ripple20

[pejohns2]

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:

1. Collected IP range(s) allocated to potentially vulnerable IOT devices within the network
2. Collected IP ranges(s) of any services (internal and/or external) that the devices are allowed to communicate with as part of normal operation
3. Defined policy on what monitored IOT devices are and aren’t allowed to communicate with

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:

• 10.201.4.0/24
• 10.201.5.0/24
• 10.201.6.0/24

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 209.182.184.2, 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.

Define what’s important – Devices to Monitor

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.

1. Navigate to the Host Group editor in the main dashboard menu bar under Configure > Host Group Management.
2. In the Host Group tree panel on the left side, expand the Inside Hosts parent host group, and locate and expand the By Function host group.
3. Mark the radio button beside the By Function host group.
4. Click the ellipsis (…) to open the context menu and select Add Host Group to create a child host group in the By Function group.
5. Create a host group named IOT Devices by entering it in the Host Group Name field, and clicking Save.
6. Locate the newly created IOT Devices host group, mark the radio button beside it, click the ellipsis (…) to open the context menu and select Add Host Group.
7. Now, create Host Groups for both types of IOT devices you will be monitoring. In this example, we will label them Industrial Control and HVAC Management.
8. We will also define the IP Ranges belonging to these groups of devices in the IP Addresses and Ranges box for each group. See the example pictures below.
9. When you have completed entering the information for a host group, click Save.
10. They will appear beneath the IOT Devices parent host group in the tree.
11. You have successfully organized the IP space belonging to the IOT devices you wish to monitor. Next we will classify the supporting assets.

 

Define what’s important – Internal Resources

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.

1. Navigate to the Host Group editor in the main dashboard menu bar under Configure > Host Group Management.
2. In the Host Group tree panel on the left side, expand the Inside Hosts parent host group, locate and expand the By Function host group, and locate and expand the Servers host group.
3. Mark the radio button beside the Servers host group.
4. Click the ellipsis (…) to open the context menu and select Add Host Group to create a child host group in the Servers group.
5. Create a host group named Industrial Device Controller by entering it in the Host Group Name field.
6. Enter the IP address for the server in the IP Addresses and Ranges box.
7. Click Save to finish.
8. Repeat the above process to create a host group for the HVAC Controller server.
9. When done, complete they will appear beneath the Server parent host group.
10. You have successfully organized the IP addresses belonging to the servers you wish to monitor. Next we will classify the external supporting resources.

 

Defining an external resource – 3rd party services you trust

Similarly, for our internal hosts we wanted to track we will now create a host group for the external/3^rd 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.

1. Navigate to the Host Group editor in the main dashboard menu bar under Configure > Host Group Management.
2. In the Host Group tree panel on the left side, expand the Outside Hosts parent host group, and locate and expand the Trusted Internet Hosts host group.
3. Mark the radio button beside the Trusted Internet Hosts host group.
4. Click the ellipsis (…) to open the context menu and select Add Host Group to create a child host group in the Trusted Internet Hosts group.
5. Create a host group named HVAC Control Service by entering it in the Host Group Name field.
6. Enter the IP address for the server in the IP Addresses and Ranges box.
7. Click Save to finish.
8. The host group will appear as a child to the Trusted Internet Hosts group in the tree.
9. You have successfully organized the IP addresses belonging to the external supporting resources you would like to build policy around.

 

Tracking Traffic – Creating Custom Applications for device activity

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.

1. Navigate to the Custom Application page in the main dashboard menu bar under Configure > Applications.
2. In the Custom Applications panel on top, click Add Custom Application.
3. First, we’ll classify all HVAC IOT traffic based on the Host Groups we’ve defined, and ports used in communication. Custom applications can be defined as a series of “AND” conditions, allowing for multiple sets of Host Groups/IPs and ports to contained within a single defined Application.
4. To define the HVAC IOT traffic, begin by giving it a meaningful Name and, optionally, a Description.
5. Next, you will add “rules” for the application definition.
6. To classify the communication to the Internal server, enter the port and protocol for it (2030/tcp) in the Port/Protocol field.
7. In the Server field, select Host Group.
8. In the Host Groups field, click the Select button, locate and select the HVAC Controller host group from the list.
9. Click Apply.
10. Click Add to Rules to save the parameter.
11. Repeat the above process to add the external HVAC Control Service host group, that communicates over 3440/tcp to the application definition.
12. When you are done, the defined parameters will appear under App Rules.
13. When you are done, click Save.
14.  Repeat the above process to define the Industrial IOT device traffic. This traffic goes to the server in the Industrial Device Controller host group, on ports 4040/tcp and 6070/tcp. When done, it should look like the below screenshot.
15. Click Save.
16. Once done adding a custom application, you must click Apply to permanently save the changes and have Stealthwatch begin classification.
17. Starting from the point that a Custom Application is saved and applied, all traffic observed by Stealthwatch matching those parameters will be classified as your defined Application. It becomes available as an Application “type” in Flow Queries, available to you in a myriad of different reports, and for purposes of this scenario, a parameter you can use to define policy in Stealthwatch.

 

Defining policy in Stealthwatch to alert on observed communication violations

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.

• All HVAC-related IOT devices in the HVAC Management host group are allowed to communicate to internal servers now contained in the HVAC Controller host group, over port 2030/tcp, and the external management service classified in the HVAC Control Service host group over port 3440/tcp. We have classified this traffic as a custom application, HVAC IOT Comms.
• The industrial controller IOT devices now contained in the Industrial Control host group should only be communicating to the internal control server contained in the Industrial Device Controller host group, over ports 4040/tcp and 6070/tcp. We have classified this traffic as a custom application, Industrial IOT Comms.
• Anything besides these communications to the IOT devices should raise an alarm.

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:

1. Navigate to the Policy Manager in the main dashboard menu bar under, located under Configure > Policy Management.
2. From the Policy Management page, select Create New Policy > Custom Security Event.
3. You will be presented with the Custom Security Event editor. We will begin by describing the policy parameters for the HVAC IOT devices.
4. Enter a descriptive Name for the policy.

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.

5. Optionally, you can enter a Description for the CSE explaining its purpose.
6. Click the “+” on the editing panel to begin adding parameters for the event.
7. Select Subject Host Groups from the drop-down list.
8. From the pop-out menu that appears, locate the HVAC Management host group under the IOT Devices host group, and click the radio button once to include it.
9. Click Apply.
10. Since we want to know if any of these IOT devices talk to anything other than the allowed internal server and external service, we will create exclusion conditions within the policy, which will cause it to alarm off anything but the defined parameters.
11. Click the “+” and select Subject Applications from the drop-down menu.
12. Select Exclude from definition field.
13. Locate and select the HVAC IOT Comms custom application defined earlier.
14. Click Apply to exclude this traffic from triggering an alarm for this event.
15. Click the “+” and select Peer Host Groups from the drop-down menu.
16. From the pop-out menu that appears, locate the HVAC Controller and HVAC Control Service host groups and click the radio button beside each host group twice to exclude them from alerting.
17. Under Status, toggle the switch to On.
18. The fully defined policy should look like the screenshot below.
19. As you define the parameters for the event, a plain-English description detailing the conditions causing the alarm to fire is generated. Copying and pasting this text into the Description field is helpful when investigating the alarm later, should you forget why it was defined.
20. Click Save. This will activate the policy and from this point forward Stealthwatch will monitor observed traffic for any communications coming from the HVAC IOT devices that doesn’t belong to the allowed communications between the internal control server and trusted external control service.
21. We will use the same basic process to define policy for the Industrial IOT Device group as well.
22. On the Policy Management page, select Create New Policy > Custom Security Event.
23. Enter a descriptive Name for the policy.
24. Click the “+” on the editing panel to begin adding parameters for the event.
25. Select Subject Host Groups from the drop-down list.
26. From the pop-out menu that appears, locate the Industrial Control host group under the IOT Devices host group, and click the radio button once to include it.
27. Click Apply.
28. As before, we want to know if any of these devices talk to anything other than the allowed internal server. Again, create exclusion conditions within the policy, which will cause it to alarm off anything but the defined parameters.
29. Click the “+” and select Subject Applications from the drop-down menu.
30. Select Exclude from definition field.
31. Locate and select the Industrial IOT Comms custom application defined earlier.
32. Click Apply to exclude this traffic from triggering an alarm for this event.
33. Click the “+” and select Peer Host Groups from the drop-down menu.
34. From the pop-out menu that appears, locate the Industrial Device Controller host group and click the radio button beside it twice to exclude it from alerting.
35. Under Status, toggle the switch to On.
36. The fully defined policy should look like the screenshot below.
37. As before, as you define the parameters for the event, a plain-English description detailing the conditions causing the alarm to fire is generated. Copying and pasting this text into the Description field is helpful when investigating the alarm later, should you forget why it was defined.
38. Click Save. This will activate the policy and from this point forward Stealthwatch will monitor observed traffic for any communications coming from the Industrial IOT devices that doesn’t belong to the allowed communications between them and the internal control server.

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.

Quick Addendum:

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.