Project Basecamp: Tempest in a Teapot

I have been thinking about the DHS ICSJWG Spring Conference of a week ago, and the 2-hour debate at the conference on device security and the Digital Bond "Project Basecamp" project that was announced at January's S4 conference. The debate showed there is still resistance to device authentication, but among end users more so than among vendors. I think Jonathan Pollet's comments about this debate echoing the 1990's IT encryption debate are on the mark. That said though, I still think it will take a long time before device authentication becomes commonplace. Project Basecamp Digital Bond's Project Basecamp released information about a number of RTU and PLC vulnerabilities and created Metaspoit modules to exploit those vulnerabilities. Dale Peterson's stated objective in the effort was to "... make demonstrating the ease of compromise and potential catastrophic impact possible for any owner/operator, vendor, consultant or anyone else involved in ICS. C-level executives running the critical infrastructure SCADA and DCS will know beyond any doubt the fragility and insecurity of these devices. Hopefully they will find this unacceptable, demand their vendors offer a secure replacement, and spend the money to replace the PLC’s." Vendors and end users cried foul of course, to which Dale replied that we have seen essentially no progress in device security in ten years and so something needs to be done. The Elephant in the Room There are many forces at play in this debate. Let's start with plain-text communications protocols. They are the "elephant in the room" for ICS SCADA. The protocols are trivially hacked - any sender can connect to these devices and start giving them commands to activate or deactivate equipment, or even to reprogramm most of the devices. Given that the cost of compromising this equipment is already zero, what harm can releasing another few vulnerabilities or hard-coded passwords or metasploit exploits into the public domain do? You can't reduce the cost of compromise below zero, and Dale may be right about the benefits of greater C-level awareness. End users respond that equipment lifetimes in many industries are as much as twenty years. Attack technologies and corresponding defenses both are expected to evolve enormously over the next 20 years, and nobody expects to be able to retrofit modern protections into 20-year-old equipment - not now, and not twenty years from now. Given this, security-through-obscurity has some value. Public disclosure of vulnerabilities and incorporating those vulnerabilities into automated attack tools reduces obscurity. The vendors weighed in essentially saying they would love to have end users demand additional security features. I believe vendors could use security features as competitive differentiators and could even charge premiums for extra-secure equipment, provided that these were features customers were demanding. I suggest that both product and services vendors would love to see the twenty-year lifetime diminish to something closer to IT expectations of 3-5 year equipment lifetimes, because such a development would mean a bigger market for products and services. Users though, want nothing to do with this. Users expect obvious "holes" like low-security device web servers and hard-coded passwords fixed, but users in the ICSJWG audience went on record saying they do not want the extra operational headaches, costs and latencies they see coming from strong authentication or role-based security for devices. End users said they certainly do not want to pay for product and services to re-fit their facilities with new devices every 3-5 years. The cost of such a retrofit is of course much more than simply the cost of new hardware and software. A great deal of testing comes with any extensive change to control system components, to ensure the continued safe and reliable operation of what is often a large, dangerous physical process. End user comments from the audience indicated that they felt the present strategy of network segmentation/isolation and other measures were enough to compensate for the insecurity of plain-text protocols. Prediction So what will happen with device security looking forward? Well for starters, I agree with Jonathan Pollet's comment that this is the same argument which took place in the IT world in the 1990's. The debate was settled in favor of the PKI-based encryption and authentication technologies which are now ubiquitous in business and consumer computing. A comparable evolution is inevitable in the ICS space. That said, there are reliability and safety drivers in the ICS space which are not present in the IT space. These drivers are slowing the adoption of strong communications and device security technologies, but as Motorola demonstrated with their 3600 RTU presentation, these drivers are not stopping progress altogether. I predict that within another ten to fifteen years, the use of unauthenticated protocols will start to decline. At that time, the use of encryption technology for device authentication will clearly be increasing. The trend, however, will only become wide-spread when protocol standards groups and vendors have made stronger security trivial to implement. What would accelerate this? A widespread change in perceived threat would accelerate this. The ICS-CERT session on the activities of their fly-away teams was by far the best-attended non-keynote track at the ICSJWG meeting. Why are so many people interested in incidents? It is because they are looking for a sign - a sign that our adversaries are changing tactics. Organized crime produces high-volume malware, but does not specifically target critical infrastructures, yet. Exploiting plain-text protocols or exploiting Basecamp-style vulnerabilities is very much within the capabilities of these adversaries, but thus far they simply have not chosen to target critical infrastructures. Persistent, targeted adversaries have demonstrated an ability to penetrate both corporate networks and industrial control networks for purposes of industrial espionage. Using this attack vector to take control of and sabotage industrial assets is very much within the capabilities of these "advanced" adversaries, but again these adversaries do not seem to have chosen to use their capabilities for sabotage, yet. Safety First So how safe is it, basing our defenses on our enemies' intent, rather than their capabilities? Not very. The real problem is that cyber risks to safety are not taken seriously by asset owners and operators. Until this changes, it will be a long time before authenticated and secured PLCs are in widespread use.  Even then, the long life-cycle of ICS equipment means there will always be old equipment without "present day" security protections, no matter what the "present day" is. This means control network isolation should always play a role in ICS security in order to prevent targeted, firewall-penetrating remote control attacks -- network isolation either via outright air-gaps or using Unidirectional Gateways.