Two talks on the first day of the FIRST conference highlighted the increasing range of equipment and data that can be found on the Internet, and the challenges that this presents both for risk assessment and, if incidents do happen, assessing the severity of the possible breach and what measures need to be taken.
Eireann Leverett discussed Industrial Control Systems. When, under the alternative name of SCADA, these devices first acquired IP connectivity, the fear was that they were all used to control heavy industrial processes involving high temperatures and pressures and dangerous chemicals. That turns out not to be true – on various national and manufacturer estimates only between one in seven and one in fifty involves that level of safety criticality. The majority do things where disruption or compromise could cause discomfort or disruption – for example turning off the fans in an office – but probably nothing worse. The problem is that it’s probably impossible from the network side to work out which is which. Identical Heat/Ventilation/Air-Conditioning (HVAC) controller modules may be keeping office workers comfortable or pumping fresh air into a road tunnel. A rental agency remotely setting thermostats in empty properties may well be reducing the overall risk of serious injury as compared with having an employee drive to visit each one: having those controllers on the Internet, even if they contain vulnerable code, may be rational. But for the unknown one in seven or one in fifty, which may be controlling the temperature in a plant manufacturing medical devices, it definitely isn’t.
Scott McIntyre looked at the problems caused by mixed data. A few years ago Telstra discovered that an order tracking system was accessible without authentication from the Internet. That was clearly an incident and the vulnerability was quickly fixed. But then there was the challenge of working out what personal or other sensitive data might have been accessed and notifying affected customers what can be done to remedy the problem. For structured fields in the database that is straightforward, but unfortunately there were also unstructured fields where helpdesk operators made notes of support calls and how they had been resolved. Most of the content is harmless information on the progress of orders, but there may also be things like “password temporarily set to elephant123”. The volume of information is far too big to be scanned by human eye, so how to instruct a computer to find all such problems, without too many false positives? If “password” is written in full that may not be too hard, but helpdesk staff may instead write “pwd”, “pw” or anything else that humans (but perhaps not computers) will recognise. Worse, the system also sometimes copied users’ own e-mails into the field, including things like “while we’re talking, could you charge my account to card 1234567890111234?”. There was a strong feeling that, eighteen months on, Scott is still coming up with new searches he needs to run.
Both talks suggest that there may be a problem with over-simplified breach notification requirements that, like the proposed European Data Protection Regulation, require an immediate report of what information has been exposed, what the implications are, and what both the provider and user need to do about it. I’ve written before that such reports are likely to be incomplete: these examples suggest that on short timescales like the 24 hours required by the draft Regulation they may well be hopelessly wrong.
