Incident Response for Connected Hardware

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.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *