Last updated: 
3 months 2 weeks ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Incident Response for Connected Hardware

Monday, June 17, 2019 - 17:38

An interesting talk from Rockwell at this year's FIRST conference looked at how to organise incident response in environments containing network-connected hardware devices. Though Rockwell's focus is on industrial machinery, the same ideas should apply to smart buildings and other places where a security incident can cause physical, not just digital, harm. This is not the only difference: connected hardware devices tend to be much more diverse than PCs, and they are expected to have much longer lifetimes. Those deploying Operational Technology (OT) are also more likely to focus on availability and integrity, whereas their colleagues in Information Technology (IT) worry mostly about confidentiality.

The traditional advice for OT devices has been to place them on a separate, segmented network, and rely on a strong perimeter defence. However this becomes harder as connected hardware systems increasingly depend on controllers implemented as cloud services. This turns out to be an area of convergence with IT: nether can now function as isolated islands cut off from the Internet.

Instead we need to use "home field advantage": ensuring that defenders know more about their networks and what is connected to them than attackers do. For OT, in particular, this requires processes and protocols that help defenders work together. Network monitors may well spot what seems to be an unusual flow, but without input from the OT side they will find it hard to determine its meaning or importance. Is this proprietary flow a relatively harmless device receiving a software update, or a safety critical device being compromised? Rockwell are developing a single incident response platform where people from IT and OT sides can collaboratively analyse events, but also, at a more basic level, establishing communications channels and mutual understanding so incident responders can contact equipment operators in real-time to say "we've just spotted X: were you expecting that?". That way we can not only respond effectively to current alerts, but learn together to handle future ones better.