1. Change defaults. Most IIoT devices, and indeed most IT software, ships with default passwords. Get these changed immediately to something strong and unique (definitely don’t use the same password for everything…). Avoid any equipment with hard-coded passwords; if it’s hard-coded, it is already known by every hacker out there.
2. Separate networks. Do not put IIoT devices on your corporate network, or on the same network that you use for your OT equipment. This really is asking for trouble. A single device should not be able to access multiple networks either, otherwise they can be used as a ‘bridge’.
3. Disable unnecessary functions. See that TV you have on the wall of your meeting room? Bet you it’s a smart TV. Bet no-one’s turned off the Bluetooth functionality. Or its microphone. Or the webserver that it operates. Unnecessary functions can be used as a ‘way in’, both to the device and to the wider network that it sits on. Turn things off programmatically, or physically disable them; a pair of pliers or liquid epoxy are simple ways to permanently disable a USB socket for example.
4. Stay up-to-date. Software vulnerabilities are very common, but what’s more common is known fixes to these vulnerabilities not being applied promptly. Ensure firmware and software are regularly updated and have a process to do this, particularly if it involves planning in downtime. You’re not going to be able to take a 24x7 assembly line down, but you should be able to tolerate downtime in condition monitoring sensors.
5. Test test test. Hire a specialist penetration tester who has expertise with industrial equipment and operational technology – not all of them do. This is a specialist area that requires specialist knowledge of PLCs and SCADA equipment and you want a friendly face to test it before an unfriendly one does. Most importantly, follow their recommendations – you may not be able to fix everything, but make risk-based decisions on what you do fix, what you mitigate through another route and what you accept.
6. Be clear who’s doing what; even if you’re buying a supposedly ‘turnkey’ solution, it’s never quite as simple as that, particularly if the service provider is themselves relying on a number of third parties. Understand where your data is going, who has access to it and how it’s being protected. “It’s in BigCloudProvider’s datacentre, it’s secure” is not a good enough answer.
7. Finally, and most importantly: have a plan for when things go wrong. Run some scenarios and regularly test it via a simulation or a dry run. In the event of a security incident, it needs to be very clear who does what and when, and having this clearly documented and easily accessible, including templated communication statements, will save a lot of time and adrenaline.