Blog: OT, ICS, IIoT, SCADA
Bluetooth + Electrical switchgear
The ongoing rapid growth of Industrial IoT (IIoT) across all business sectors continues to bring to focus the discrepancies that exist between the approaches to safety and cyber-security on safety critical sites.
Safety has been culturally ingrained into all aspects of industrial site operations for a long time, but cyber-security is still so often seen as an afterthought that is then bolted on (or not bolted on at all in some cases!)
The digital transformation and expansion of IIoT into safety critical sites is being driven by the same performance and productivity benefits they bring to other sectors. In addition, there is the potential to bring real world benefits with regards to improving the health and safety of personnel and reducing the environmental impacts of the business.
Let’s consider the use of IIoT for operating industrial electrical equipment, with a couple of examples:
Years ago, electrical maintenance engineers would manually push buttons and pump charging handles in order to operate circuit breakers. Maintenance personnel can now monitor and operate the same equipment remotely.
It’s a wise move for safety, as it means that engineers no longer need to operate the equipment from within the arc flash boundary, dramatically reducing the chance of injuries or death from arc flashover.
Ease of access
Pole mounted distribution transformers are used extensively across electricity distribution networks. They perform the last voltage transformation from distribution voltage to 120/240 volt power that we use in our homes. Pole mounted means they are inaccessible which reduces the risk of vandalism and injury to nearby animals and people.
Maintenance engineers will require access to the control cabinet to take readings and operate controls. This can either involve working at height or accessing equipment remotely.
We are now seeing Bluetooth and cellular implementations in industrial electrical products that allow remote diagnosis and operation.
We started looking at some tenders issued by power transmission companies and some of the datasheets and manuals for new Bluetooth switchgear and control panels. We were specifically looking for cyber-security controls. The results were not good!
The first device we discovered used Bluetooth Classic / BT-EDR and had a static pairing PIN. It was ‘0’, as per the manual:
There wasn’t a method we could find to change the PIN, nor was there a process for putting it in to a pairing mode. It was always pair-able.
The next device we looked at was a Modbus Bluetooth adaptor. The documentation gave details of the default PIN 6699 but this again had no method of changing the PIN or taking the device out of pairing mode.
This particular product model has recently been discontinued by the manufacturer yet is still readily available to purchase from multiple industry suppliers with no mention of being a discontinued product.
Another device we looked at did have a method of changing the PIN and wouldn’t enable serial port access until the PIN had been changed from the default to an 8-16 character PIN. There was a physical switch to put the device into configuration mode to allow PIN change.
There was also a configuration option to allow the device to enable / disable discoverable mode. The default setting was to allow connections and be discoverable.
Why are the issues above a potential cause for concern? They highlight the varying approaches to security that are seen in IIoT devices available on the market today. An incorrectly secured device could potentially allow any nearby Bluetooth device to connect to and operate the device just as if they had physically connected to a local serial port. Here’s an example of operations that can be performed.
- Auto recloser CLOSE / OPEN – an attacker could manually cause localised loss of power to the local vicinity
- Adjust protection sequence for Live Line working – manual override of safety measures designed to protect maintenance engineers
So a malicious local actor could cause power cuts, or perhaps re-enable power whilst the line was being worked on.
There is an inherent responsibility that falls on manufacturers and vendors for the security of their products throughout each stage of the product lifecycle. From inception and design, through development and testing and an ongoing commitment through deployment and onwards until product retirement.
Who knows whether vendors will accept that responsibility voluntarily, through market pressures from customers or forced to through some sort of IIoT governance?
Second, power transmission companies
“If you don’t ask, you don’t get” is the order of the day here. We reviewed several relatively recent tenders for provision of remote control systems for pole mounted switchgear that we found online.
Whilst all of these detailed requirements for remote access to the switchgear for safety reasons, either through cellular data or Bluetooth, not a single one had any reference to security.
Don’t get me wrong, many power companies are all over their security, but there are also those who need to catch up.
Bluetooth security can be achieved even in complex field based operations with multiple engineers and multiple devices to interface with the switchgear.
Even something as simple as a pre-shared key would make a difference here; whilst not ideal it certainly makes attacks harder. One would need to steal a device or otherwise recover the key.
Bluetooth Low Energy / BLE offers several options for security, from a simple ‘just connect’ with no security, through to a short term ‘pairing’ or a long term ‘bond’ with cryptographic key exchange.
Remote control of switchgear is undoubtedly a big plus for safety, efficiency and quick restoration of power. Indeed, proactive fault prediction will also help with uninterrupted power supply.
However, without security it actually could decrease safety in some circumstances and could affect power supply too.
Bluetooth is one option, however it’s important that cellular security is also addressed if used. There’s more on that here: https://www.pentestpartners.com/security-blog/how-to-crack-private-apn-keys-with-hashcat/