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.

Well, I guess that’s enough for Part #1, be sure to tune in Thursday for Part #2!