2011-12-21

Cyber Attack: Whose Side is Your Thermostat on?

Today's WSJ lead story was on a cyber attack on the US Chamber of Commerce. After "overhauling" it's network security, the US Chamber reports that a thermostat is communicating with Chinese computers.  There has been significant press recently on both US assertions about Chinese attacks, and also some history from fairly reputable folks on this. Other attacks appear to have other sponsors-- stuxnet has become a reference example, and the subsequent death of an Iranian general which at least in theory might also reflect a cyber incursion.  From a professional perspective there are interesting aspects to this beyond any questions about who was behind various attacks, or why -- we need to continuously be prepared to expand our perspective of possible attack vectors, potential targets, and overall vulnerabilities.
Security needs to be built-in as part of design in applications from embedded systems to cloud computing. We also must be prepared to revise and maintain protections as new threats become evident. Perhaps most critical is recognizing which systems are at risk, and what that risk might be.  Which brings us back to the thermostat. I doubt that any serious security risk assessment was undertaken for the software engineering of that device.  Actually, it is quite likely that software engineering was not the discipline applied, rather fairly simple programming -- after all, what can go wrong if your thermostat fails? Perhaps a more serious question is what can go wrong if your thermostat, or your programmable logic controller, or your mobile 'everything' device get's captured by someone who has a different agenda for its use. When I questioned someone about the aurora vulnerability for power substations the response was: "that was not a valid test, they operated the systems outside of the acceptable procedures." This is one problem we face, folks attacking and abusing our systems are likely to operate them in ways that are not expected and with intentions that differ from the developer or the user. IT managers, security folks, and just-plain users and developers need to consider this.  In many cases, the best approach is the KISS principle, "keep it simple".  Why was the thermostat attached to the network ... why is it allowed to communicate beyond some immediate control system?  Is this level of automation really required?  And if it is, are we prepared to apply the appropriate security protocols to assure it is not creating an unexpected risk?
You don't  need to reply here to my questions ... just tell your thermostat, I'll get the message.