In early 2011, engineers at the Fuel Enrichment Plant at Natanz in Iran were suddenly confronted by a baffling increase in centrifuge failures. As many as a thousand units – used to separate Uranium isotopes during nuclear material enrichment – failed due to vibration and stress.
It quickly became clear that these failures were no accident. Extremely sophisticated malware, which soon became known as “Stuxnet”, had deliberately targeted programmable logic controller (PLC) systems principally manufactured by Siemens. The malware deliberately altered the critical motor speeds with the intention of damaging or destroying the centrifuges themselves.
With the explosion in automation, more and more critical manufacturing and prototyping processes depend on complex technology such as computer-driven robotics, milling machines, conveyor systems, 3D printers, and cameras, the industry should have been on guard, Yet, despite being managed by computers which often run the same general-purpose operating systems (such as Windows and Linux) as the servers which run the company’s line of business applications, these devices are often far less secure.
>See also: Quality over quantity: Women in cyber security
These systems are often connected to corporate networks, so that they can both be controlled and in turn provide critical diagnostic and statistical information back to reporting systems.
Even where systems are ‘airgapped’ from corporate networks, they often support the use of portable storage devices such as USB thumb drives, to facilitate the transfer of information. However, in the case of Stuxnet, the malware had been designed for this precise scenario and was able to proliferate across the network using infected USB drives as an alternate vector.
Apart from hard-coded administrator accounts and passwords, PLC controllers often run fixed, older versions of operating system software, which is never patched, because to do so would risk disruption and downtime. In many cases, patching is not possible because customisation to the operating system and ancillary software, for example, vendor-specific drivers, precludes it.
In the present febrile world political climate, nation state attacks intended to disrupt the economy of a target state are becoming increasingly common. Along with this, an increasingly skilled set of malevolent actors are using so-called ‘ransomware’ to extract significant sums of money from victims whose critical data has been encrypted by malware.
Automated process control systems therefore represent a significant risk to organisations. An attacker could shut down production lines, possibly inflicting secondary damage at the same time. It would not be difficult, for example, to start a serious fire or explosion by interfering with a high pressure gas or solvent storage system.
Industrial control systems represent only one facet of the growing ‘Internet of Things’ (IoT) problem. Security has historically not been a priority in the design of these devices and systems. Indeed, at the low end (such as internet-connected cameras) security is not even a design consideration. This is because implementing physically secure systems requires not just software support but also underlying hardware support.
>See also: Ex-Army researcher links Conficker to Stuxnet
For example, modern high-end CPUs support the ability to flag regions of memory as ‘not executable’, thus guarding against a whole range of attacks whose mechanism relies on overflowing memory buffers to gain access.
But in cost-sensitive areas such as cameras, distributed sensor systems and so forth, the increased cost of CPUs which support these features can significantly impact the total cost of the device bill of materials. As a consequence, vendors choose cheaper hardware which lacks intrinsic security protection.
Aside from this, vendors of IoT products – even large, complex PLC systems – are often also inexperienced in good security design practices, or fail to give them due consideration. They implement ‘backdoors’ into their products to facilitate support and servicing, store credentials insecurely and use ‘off the shelf’ software components that are themselves intrinsically insecure. These practices lower vendor costs at the expense of purchaser security.
Knowing what devices are actually network-connected allows an organisation to itemise its vulnerabilities. So-called agentless discovery capabilities allow inventory management systems to scan network subnets and determine the type of devices that are attached, without requiring intrusive access to the device or its software. Once this information is captured, you can start to implement firewall rules and network segregation to make sure that vulnerable devices are ringfenced and not reachable except by a very limited set of trusted peers.
>See also: US and Israel built Flame as well as Stuxnet – report
At the same time, network monitoring can pick up any anomalous patterns of access which might indicate external attack. Often, long before an actual attack is launched, malevolent actors probe and scan corporate networks, looking for weak points. This traffic can be detected, giving you valuable time to harden your defences and ensure an attacker cannot penetrate the outer perimeter of your network.
Finally, organisations need to control the use of portable storage devices. Locking down computers so that these devices can’t be used to move data insecurely is a very good starting point, along with comprehensive staff training on good security practices.
Sourced by Andy Mayo, 1E Tachyon Engineering Team Lead
