Assessing the security posture of an asset owner’s SCADA or DCS typically does not involve looking for new, zero-day attacks. Instead, it focuses on identifying protection against known vulnerabilities, as well as good practice configuration and implementation, architecture, redundancy, recovery … see a summary of our methodology.
One area we deviate slightly from this philosophy is with controllers and other field equipment such as RTU’s, PLC’s, IED’s and communication gateways. Loyal blog readers know my thoughts on protocol stacks in these devices. The problems are so common that we treat this as a known vulnerability and do some basic data storm or stress testing on Ethernet, IP and TCP protocols.
We use the ISIC family of tools – – specifically esic for Ethernet, isic for IP, and tcpsic for TCP. It is free and easy to use, but there are other options out there. This tool likely will cause the tested interface to be unavailable during testing because the network is saturated. This is an infrastructure issue, but what we are looking for are the residual consequences to the field device.
The results tend to fall in the following four categories (in increasingly level of severity).
1) The controller operates properly throughout testing and the tested interface is available immediately after testing. (Passed the test)
2) The controller analog or digital I/O stops working during the testing, but it resumes proper operation, along with the tested interface, when testing stops. So during the storm polling stops, and this is often due to the shared resources in the controller architecture.
3) The tested interface crashes and the controller requires a partial or complete reboot to get the tested interface working again. The severity of this is obviously tied to the purpose of the tested interface, but if this is used for control center communication this can be serious.
4) The tested interface crashes and a reboot does not bring the controller back to proper operation. This may require reloading the configuration or in some cases the firmware to recover. Hope you have a good backup and recovery process implemented.
This isic testing is a classic low-hanging fruit approach and is the tiniest fraction of the testing that should be done by the vendor. However, it is a reasonable measure for an asset owner – – obviously in a lab or carefully constructed environment.