Having completed my part of the Quickdraw project, my time at Digital Bond is winding to a halt. But I thought I’d just post a retrospective on some of the things I learned on the Quickdraw project. Because this post is a bit on the long side I have decided to split it into two parts, I plan to post part two on Thursday.
Since this is my swan song, I guess it’s ok if I sound a little bit like ‘chicken little’ as I review some of the things I encountered in the Digital Bond control systems lab. This stuff is, I guess in a sense, just trivia that I kind of expected; but, it turned out to be even more frightening than I imagined it would.
Basic Access Control is not available…
Even the basic kernel mode / problem mode access control model is non-existent on most devices. Authentication, much less admin / user privilege models, are practically non-existent. Usually it is non-trivial to even distinguish engineering access vs. functional access.
Insecure protocols and defaults are prevalent…
Insecure by design protocols e.g. TELNET and FTP, are the rule, not the exception. Most control system protocols do not have rudimentary authentication or encryption options and even those that can theoretically be securely configured (e.g. dnp3) require substantial effort to secure. (Requiring site visits to change keys may not be a workable solution.) The industry is insecure by default. On the rare occasion when a web interface is not passing credentials in clear-text, the credentials are base-64 encoded without a SSL, much less PKI, infrastructure.
Reboots / halts are not protected…
Rudimentary TCP / IP attacks, much less buffer over-flows, are over-kill in the control system environment. Denial of Service can be accomplished by simply sending reset / reboot or halt commands.
Software is not protected…
IEC 61131 control logic can be pulled, edited and pushed back to devices at will. There is a myth that it would be hard to understand what the logic actually does; but, as an example, even simply changing a few fail-open to fail-close outputs and vice versa could convert a safe plant into a sea of land minds.
Firmware is not protected…
It is actually easier to push firmware over ethernet in the control system industry than in traditional IT environment. Even when firmware over ethernet is not supported, legacy hooks from partial porting of serial protocols to ethernet means firmware destruction over ethernet is supported!!! There is a myth that pushing firmware attacks is over-kill in the control system environment. In fact, it can be difficult for even a very experienced software engineer to JTAG away firmware corruption. This means that a simple firmware corrupting virus or worm could produce hours and even several days of denial of service per incident, on an industry-wide basis. More sophisticated firmware attacks could plant logic bombs that would be virtually undetectable and could be planted years or decades in advance of being triggered.
Web technology provides easy compromise vector…
Although sometimes hardly mentioned in product documentation, many devices by default install with mini web servers that make it easy for even the not very control system savvy attacker to finger-print and control the control system network.
Security Semantic variation is even greater than expected…
Although the Quickdraw project proved that a set of SEM events could be developed and applied to multiple devices, it also shows that there is enormous variation in the semantics from device to device. Sometimes even the implementations of the same protocol have significant differences, especially when they reference custom objects. Web interfaces generally provide alternate attack vectors for every security event further complicating the security event semantics to syntax mapping.
Ethernet to serial connectivity is ubiquitous…
There is a myth that serial devices are not accessible from the web. This is because there are many instances of dial up access to devices that are not necessarily ethernet capable. However, cursory review of typical devices indicates that there are three prevalent ethernet to serial attack vectors. First, because many basic functions are not possible without serial connectivity, and increasingly all systems are centrally managed via the ethernet, it is inevitable that ethernet enabled PC’s provide serial access. Second, and really more important, especially when dealing with electrical transmission, communications concentrators facilitate sending ethernet commands to devices that forward the commands as serial commands. Third, perhaps most important of all, IEC 61850 can enable throwing relays from ethernet with the end device either transferring the command over serial lines or just over the bus.
‘Non-routable’ protocols can be MORE dangerous than routable protocols…
Especially in the world of electrical transmission, the notion of a ‘safe’ non-routable protocol is a myth. Substation communication concentrators provide ‘routing’ at layer 2, instead of at layer 3, but the effect is the same. What is worse, one can ‘route’ the way to the communication concentrator and the communication concentrator is often ONLY accessible via TELNET. (maybe going cheap with the CIP ‘Non-routable Critical Cyber Assets Exception” ain’t such a good idea).
Control System protocols are API’s, not strictly request / response models…
Although functional data is generally handled in some variation of a basic request / response model, most security significant functionality, (e.g. locking, logging, exception handling) generally requires custom application event handling in the control logic, it is not provided by the control system device OS. This further complicates developing common semantics, testing, or signature approaches, not to mention PCAP generation ;-).
Binary transfer issues exceed current IDS technologies…
Although Quickdraw has proven that a large number of Snort detection rules can be developed to trigger alarms based on obvious security events, many important events can not be detected using Snort. For example, basic critical security information is sometimes buried in binary transfers instead of via a basic command request / response model. If you don’t parse the binary, you can’t detect the request / response. So a command to change the welcome banner looks just like a command to lock out all remote engineers or a command to force all system relays to throw.
Where are the Control System application proxy firewalls?…
While Quickdraw has shown that a lot can be done with existing data generation (e.g. snort) and data fusion (e.g. OSI PI server) technologies to create control system specific cyber intrusion detection systems; a bigger lesson from Quickdraw is just the extent to which control systems need MORE protection than comparable IT systems. We need control system specific application defenses e.g. Data Diodes & Control System application-proxy firewalls.
Biggest myth: Internal defenses are only required to thwart insider threats…
The state of current control system architectures testifies volumes. To think current practice makes sense at all you basically have to believe that internal defenses are only required to thwart insider threats. If you understand that internal defenses are necessary to mitigate the impact of external intruders; you can’t in good conscious, procure these systems. If you have to, you can’t link them to the Internet, or think non-application specific firewalls or DCOM security is going to save you. And for goodness sake, you can’t link your functional systems to your safety instrumented systems.
And finally a quick thanks to Dale and all the Digital Bond team members for giving me the opportunity and support to work on this interesting project!
-Martin