Sabotage & Subterfuge: Hacking Industrial Robots

INDUSTRY 4.0 IS COMING

The sage words below are an excerpt from a Nov 1, 2017 Blog by Danny Bradbury - see https://sector.ca/sabotage-and-subterfuge-hacking-industrial-robots/. I include this entry today because I want to take a closer look at the promised connected world of the Industry 4.0 platform, so that we all remember to address the cyber security issues along the way to the promised land of true Manufacturing Automation.

--------------------------------  

Isaac Asimov’s three laws of robotics are safe, sensible rules. First laid out in 1942, rule number one prevents a robot from harming a human being. The second forces it to obey orders given it by people, except where such orders would conflict with the first law. Finally, it must protect its own existence as long as such protection does not conflict with the First or Second Law.

Those are some pretty sound, sensible rules – and Stefano Zanero has persuaded industrial robots to break all of them.

Zanero, an associate professor at Italian university Politecnico di Milano, will explain how in his talk at SecTor later this month. He has found flaws in industrial robots and developed theoretical attacks that could dramatically affect corporate users, and worse.

“I was taking coffee with a colleague that works on robotics, and was looking at their labs. While we were talking, I was going through all the research that I had read in the last few years. I realized that I had not seen anybody look into one of these things,” he says. That’s not surprising. “Not everybody has an €80,000 robot sitting above their lab.”

Zanero did. Robotics is a key research area at the Politecnico di Milano, so he set to work investigating several robots’ underlying security protections. He found some common flaws.

“Most of the components in the robot were relatively weak. They were not designed to withstand hacking attacks,” he says.

In one of the robots he investigated, he found a default user that couldn’t be disabled, and a default password that couldn’t be changed. “When you compromise the first Internet-facing component, all the other components are basically also yours,” he explains. Those components all download the firmware from the first, compromised component without checking code signatures.

BREAKING LAW NUMBER TWO

In compromising this software, an attacker is able to violate Asimov’s second law by giving it new instructions that its original programmers didn’t intend.

Industrial control systems built to this level of security are not meant to be Internet facing, he adds, and yet the move towards ‘Industry 4.0’ – an increasingly connected factory environment in which robots and other industrial systems are accessible via IoT-based networks – is increasingly putting them there. Many industrial robots today are a browser away from the Internet or in some cases directly connected, he warns.

What could he make a robot do with these vulnerabilities? He came up with several possibilities. The first was the introduction of micro-defects.

“If you get control of a robot, you can introduce in a subtle way a lot of micro-defects into the parts being manufactured. These defects would be too small to be perceived,” he says. “Since the robot isn’t designed with this attack model in mind, there is absolutely no way for the people programming the robot to realise that it has been put off centre and miscalibrated.”

A slight offset in a welding algorithm could produce a structural flaw that could have significant implications for product safety. Imagine a production line altered to produce unsafe automotive components. A year after the attack, the attacker could make the flaw known and force a product recall, costing the victim millions and trashing their brand. Worse still would be not making the flaw known, waiting instead until road accidents started happening.

GOODBYE, LAW NUMBER THREE

“The second big area of concern is that using the same manipulations, you can actually make a robot destroy itself,” says Zanero.

There goes Asimov’s third law, and with it, your factory’s profit. Production lines have a high downtime cost, running into thousands of dollars per minute. Robots are also custom-configured and difficult to source, making them difficult to replace.

This also raises the possibility of ransomware, says Zanero. An attacker could incapacitate a robot and then demand a ransom payment to set it going again. That would change the attacker’s business model from industrial sabotage to pure profit.

VIOLATING THE MOST IMPORTANT LAW OF ALL

Another possibility is that the robot could be programmed to violate the first law, harming a human directly. This would admittedly be difficult for an attacker to do. Robots working alongside humans are tightly monitored and designed not to make movements that could harm their coworkers. Nevertheless, there is scope for abuse, Zanero says.

“Even if the robot moves slowly and doesn’t really harm you by moving, if the point of the tool is toward you, it could harm you,” he says. Robots are programmed to keep pointy things away from people. “They are super good at that. There is a lot of safety around that, but it is software, not hardware,” he points out, adding that an attacker could change that software.

To its credit, the industrial robot vendor that Zanero’s team contacted about the flaws was responsive and quick to react. It thanked the team and patched the bug in its products, which is an encouraging sign. Nevertheless, there is more work for the robotics industry to do.

“We have tested one specific robot, and then we tested others just to see if our architectural considerations would generalize,” he says. “And they did.”

Siemens Opens IIoT Cyber Security Centers in Ohio & Germany

While scanning Automation.Com yesterday, I noticed what I think is a first in the Industrial Internet of Things (IIoT) and perhaps the CIM world... 

Siemens has opened Cyber Security Operations Centers in both North America and Europe. This need for a cyber security has been predicted here and I am happy to see the commitment from our friends at Siemens in this area. Their press release is below.

I know that Cisco and IBM are also looking at this area as Cloud, Mobile and Wireless IIoT are dependent upon robust and secure connectivity. 

I liken the time now to what we had in the late 1990's when everybody knew that e-Commerce would be a major internet app, but many didn't trust it with their credit card. It really to indemnification from the banks and good security practices (SSL, HTTPS, CAPTCHA, etc) to make our comfort level high enough to grow the business side. Today we all use it and it has allowed eBay and Amazon to flourish. I predict that IIoT will be pervasive in less than 5 years like these e-commerce technologies and apps we enjoy today. We are moving closer every day - thanks Siemens!   

Press Release:

March 17, 2016 - Siemens opened Cyber Security Operation Centers (CSOC) for the protection of industrial facilities in Lisbon, Munich and Milford, Ohio. Siemens industrial security specialists based at these sites monitor industrial facilities all around the world for cyber threats, warn companies in the event of security incidents and coordinate proactive countermeasures. These protective measures are part of Siemens' extensive Plant Security Services with which the enterprise supports companies in the manufacturing and processing industry in encountering constantly changing security threats and increasing plant availability.

The increased networking of industrial infrastructures ("Internet of Things", "Industrie 4.0") calls for appropriate protective action for the automation environment. This is where the Siemens Plant Security Services enter the picture: these services range from Security Assessments and the installation of protective measures, such as firewalls and virus protection (Security Implementation), through to the continuous surveillance of plants with the Managed Security Services, which is now offered by the CSOCs themselves. If the Siemens experts detect an increased risk, they give the customer an early warning, issue recommendations for proactive countermeasures and coordinate their implementation.

The countermeasures are based on the criticality of the incident and the likely impact on the customer's business. They include modifying firewall rules or providing updates for closing gaps in security. In addition, Siemens provides forensic analyses of security incidents. Companies are then in a position to prepare reports that comply with international standards such as ISO 27002 or IEC 62443. And that is not all – companies also receive a transparent view of their plants' security status. Siemens' Plant Security Services use products from the company's collaboration partner, Intel Security. These include: McAfee VirusScan, McAfee Application Control, McAfee ePolicy Orchestrator (ePO) as well as McAfee Enterprise Security Manager with Security Information and Event Management.

Siemens AG (Berlin and Munich) is a global technology powerhouse that has stood for engineering excellence, innovation, quality, reliability and inter-nationality for more than 165 years. The company is active in more than 200 countries, focusing on the areas of electrification, automation and digitalization. In fiscal 2015, which ended on September 30, 2015, Siemens generated revenue of €75.6 billion and net income of €7.4 billion. At the end of September 2015, the company had around 348,000 employees worldwide. 

Source URL @ Automation.Com

Security is Paramount in the Internet of Things

This article was written by my friend Kim Rowe of RoweBots and it has been slightly adapted for this blog. The original can be read at http://www.embedded-know-how.com/article/1776/security-is-of-paramount-in-the-internet-of-things...

Security is of paramount concern for internet connected systems because it now controls all infrastructure, most entertainment, most factories, medical systems, all electronic communications – both corporate and personal, and all financial transactions. As a society, we are completely dependent on the Internet and without reliable Internet services society would not function.

 

This Internet dependence will only grow as we add more devices and capabilities creating the Internet of Things. Dependence will create significant vulnerabilities if the devices are not secure. Imagine a connected hospital without security for patient data collected in real time or a voting system vulnerable to hackers. How about traffic lights which can easily be changed by criminals? Without security on all devices, everything that surrounds us will be subject to attack and exploitation by terrorists, criminals, power hungry hackers and vandals. Our society, safety and freedom will be at risk.

If pervasive security is in place, our society will have the capabilities to become much safer, with greater freedom and improved safety and security. The tyranny of the masses could be minimized and a society responsive to individual needs could be created – from getting the right traffic lights while eliminating all accidents, through guaranteeing private information remains private and ensuring that medical results are both secure and immediately accessible. Internet of things devices will go into the field now but will remain viable for many years depending on the application. Traffic lights and utility meters are rarely changed. Communications infrastructure is designed to be compatible and operational for twenty years. Electrical transmission systems last thirty years or more. Homes, offices, industrial buildings and other structures are intended to last indefinitely with retrofits in terms of decades.

If new systems are not secure now, they could be a significant risk for the purchaser very quickly as threats grow. To preserve customers investments in their smart devices and protect society, security is an essential requirement for all new devices. The time to protect society is when systems are designed. How secure can small microcontrollers (MCUs) and microprocessors (MPUs) be? Of the 20-50B devices expected to go onto the Internet in the next few years, all can be secure to the point where abuse and misuse is minimal.  Small devices can be more secure than much larger devices for two reasons. First, they are not subject to the same type of threats – threats are much lower level. Second, they often lack the features to dynamically run new programs and the mechanisms that they have for reloading the program either require physical access or can be secured relatively easily. This does not mean that security is very easy, just that it is not as difficult if you properly exploit the features of MCUs and small MPUs for maximum security. The remainder of this article discusses how to protect small devices on the Internet of Things.

Hacking an Embedded Device

 In the case of systems with dynamic loading, modification of executable files and other sophisticated features, security is difficult. Imagine the following scenario:

• An intruder moves a file onto the machine using email, ftp or some other means.
• The file is dynamically loaded and when it runs, it corrupts other executable files. It then cleans up and deletes itself.
• If the virus is new or unknown to the system, it won't be recognized as a virus and will pass into the system and infect it.

Consider another scenario where communication links are not secure or not properly secured. In this case, there is likely a means to read data at a minimum. There might also be a means to inject new data into the data stream which could be used in turn to corrupt the receiving system. A good example of this is loading a non-secured image for a device over the Internet. When the new image is loaded and run, it could take over the system assuming that it has the correct access. In yet another scenario, a device with critical data on it is stolen. Unless the data is encrypted or sits in an encrypted file system, it could be possible to recover the restricted data from the device. This is another scenario to consider.

To ensure system security, often it is best to consider how the device information will be accessed. Typically, great security would require: something you know (password), something you have (debit card or a wearable device), and something that you are (an iris scan). For small devices this is typically overkill, but in cases where very high security is required, it is possible to achieve this through indirect means as long as the various elements are all secure. By securely interacting with a server which in turn securely accesses the device the device interfaces for security can run on larger machines and still be used to secure small devices.

Another critical element for secure systems is layered security and an assumption that someone will gain partial access. A good design practice uses layered security where possible. In this case, the intruder may access some part of the system but not all the system without significant additional work. Examples of this might be using two different firewalls in cascade to secure a server so that vulnerabilities in one are secured by the second firewall. Following a discussion of the processes required and the components or software elements which provide various security features, the use of these components will be discussed further in the context of system security, addressing each of these scenarios.

Securing Small Devices

 The first and most important thing that is required to secure a small system is the desire to make sure the device is impenetrable by all reasonable means. Without the proper motivation and mindset to make the system secure, it most certainly won't be secure. The second thing that is required is an approach that designs in layered security at the design level. After having completed a design, to then think about how best to secure the device is at best impractical. By using the correct approaches and knowing what is needed at design time, and actually using these tools to achieve a secure system is the next step to a secure system.

The third important approach is a well defined process for testing the security of the system after the implementation is completed and the device is properly configured. Through proper configuration followed with good testing approaches, the security of the final system can be assured; provided that the installation is correct. The final step to a secure system is a secure installation. A secure installation requires a rigorous procedure for installation which is strictly followed. Automation of the process is not necessary but is highly desirable as it can eliminate human error. Final in place testing will ensure that the install was correct and the security is operational.

Security Features

To completely lock down an MCU or small MPU at design time, the following security features are required. Some may not be necessary for your system, but in general, all should be considered. Security using standard information technology security solutions are the core security mechanisms for deeply embedded MCU and MPU products. These security protocols are:
•    TLS
•    IPSec / VPN
•    SSH
•    SFTP
•    Secure bootloader and automatic fallback
•    IP Filtering
•    HTTPS
•    SNMP v3
•    Secure wireless links
•    Encryption and decryption
•    DTLS (for UDP only security)
•    Secure email

TLS, IPSec/VPN, HTTPS, Secure wireless links, and DTLS are all means to secure communications links. SFTP provides secure file transfer while SSH provides secure remote access and Secure email provides email services over encrypted links. A secure bootloader with automatic fallback ensures that the system cannot be corrupted. SNMPv3, encrypted data, and an encrypted file system protects data through encryption either locally or as it is about to be transferred to another machine. IP filtering is really a firewall feature, intended to keep out unwanted and uninvited guests. Each section and each item will be discussed after a discussion on system level security.

System Security

Security is only as strong as its weakest link or component. To make a system secure, all the various communication channels, all the file transfer, all the data storage and any means to update anything must be secure. By making all of these things secure, the system becomes secure.

Figure 1. Network Security Components highlighted. The diagram shows the Unison OS Internet protocols, highlighting the components that offer the necessary security for that feature in order to build secure MCU and small MPU based devices. The security components require seamless integration across the entire set of protocols to provide high quality security.





The approach whereby the system is secured in layers using components is an excellent approach and the one used in the RoweBots Unison Operating System and most higher level environments. At the core, all operating system components are secure to protect against unauthorized tampering. Operating system security includes an encrypted file system so even if the device is stolen, the data is protected. Small MCUs use memory protection units (MemPU) and MPUs use their memory management units (MMUs) to ensure unauthorized changes to the programs are prohibited. Often flash reading is eliminated by using memory protection features which stop users from accessing the programs and or executing new programs from RAM or non program flash.

Secure boot and re-flash should be part of the core operating system security. By using the mechanisms provided by a secure boot system in conjunction with secure operating system features, all unauthorized tampering with the program can be prevented.  After the basic OS has been secured, attention is turned to the next layer of security – namely secure data link communications protocols. This includes wireless link level security and various military data link security protocols.

The next layer is at the IP level. This includes the following protocols:
•    PPP, PPPoE, PPTP
•    IPSec (or VPN)
•    IP filtering or firewall capabilities

These protocols securely transfer IP packets over the network. With reference to the OSI model, they all operate in the IP or network layer. IP filtering is used to authenticate and accept and reject connections. IPSec provides a virtual network built on top of the IP network using encrypted packets, and the remaining protocols provide encrypted and/or authenticated communications links for iP packets.

The next layer of security includes the transport, session and presentation layers. This end to end encryption layer includes TLS and DTLS. The remainder of the security protocols are application level protocols and provide the following features:
•    SSH – secure remote access
•    SMTP – secure email
•    SFTP – secure file transfer
•    SNMP v3 – secure device management
•    HTTPS – secure web server access
•    Encryption and decryption provide separately secured data in the environment to prevent unauthorized use.

Using all of these components and layers together, within a secure framework which has been thoroughly tested will ensure that your layered, secure design has optimal protection.

Figure 2. Unison Nanokernel Architecture – highlighted with security components. The Unison RTOS offers an additional secure boot feature at the lowest levels which completely locks down the system. Without an interpreter or other means to load a program which would run and then exploit a vulnerability of the system, it becomes extremely difficult for the system to be attacked.





System Security Revisited

Now consider the security of a MCU or MPU with limited resources needing to apply most if not all of these protocols to achieve security. To provide practical examples, this will be considered for the Unison OS, a tiny POSIX RTOS which has these features off the shelf in its tiny footprint. First, using secure communications protocols, all applications talking to the target device can be made secure. This includes phone applications, secure web based access to a tiny web server and more. Tricks like buffer overflow attacks are not possible because Unison is designed to run in minimal resources and must protect against any unreasonable resource use. Secure wireless links can be used. A VPN may be used.

To transfer files into the system SFTP can be used. This guarantees that the data is not corrupted during transmission – very important to secure the system updates. Adding filtering to the front end processing in the TCP server ensures that only authorized requests and updates are processed. This protects the device from intruders and significantly improves security. In addition, SSH can be used to remotely setup the device using a terminal based approach which may be more conducive to a scripted approach compared to a web server. This guarantees that the setup of the device is secure as well. At this point, the data flowing to and from the device is secure. Any changes or setup is secure and authorized applications and users can get access to the device's data and features. What if the device is stolen? To protect against this either encrypt the stored data on the device, keep no local data or use an encrypted file system. This will ensure that the critical data on the device is secured. If the user has the device, and has a password, this is generally regarded as reasonable security. Additional security in terms of fingerprint scans, iris scans, palm prints and other devices can be added for additional security either with the device or connected to a secure access station. If you review the security scenarios that were first discussed, you will see that all but one of the scenarios has been discussed. The issue of execution of a program which subverts the security system has not been considered in depth.

In the case of an MCU and some MPUs, the program is a single linked image that runs from flash memory. In this case, it is not possible to add anything to the system because the entire image runs from flash and if the boot mechanism or re-flashing mechanism is secure, then an intruder can't introduce new code. This is true in the Unison case which makes the system extremely secure. In the case where an interpreter is in the system, the same cannot be said. An interpreted program could go and change the system image with unfettered access on an MCU or MPU unless elaborate security mechanisms are put into place such as use of a memory protection unit or MMU.

Securing MCU and MPU Systems

In summary, MCU and small MPU systems can be completely locked down using standard IT security protocols, secure boot and by restricting interpreter use. Unison benefits from the complete integration of all these components and the attention paid to layers security as part of this integration. Security should not be an afterthought or something layered on top of the operating system – it should be designed into the system and integrated and tested as a unit for true security.

---

 Kim Rowe is the CEO of RoweBots Limited, the manufacturer of the Unison Operating System and builder of Internet of Things devices.

More information can be found at http://rowebots.com/products/unison_rtos .

Industrial Equipment & Network Security - A Growing Concern

Increasingly our industrial world is adopting Information Technology (IT) advances such as networking, remote control via the web, mobile interfaces, 802.11 wireless, USB support,  and now cloud based applications in the race to stay ahead in this competitive world. This application of technology may be coming a a cost of vulnerability and we need to look at this.

At the recent International Manufacturing Technology Show (IMTS 2014) in Chicago, exhibitors showed how they could leverage every advance in the IT world on to the factory floor. At the leading edge 100,000 sq ft DMG MORI booth, amazing new controllers and machines with remote OEM support options and high tech interfaces made in their new Davis, California plant were highlighted.

Following DMG MORI's lead, every manufacturer wants to reduce costs and yet enhance customer service - and leveraging IT is a great way to do so. That said, this openness cannot be done at the cost of making the system less secure and opening up the potential for a cyber attack and disaster.

Anyone in the defense industry (especially in the US) has heard of the International Treaty of Arms Reduction (ITAR) and the many security requirements that this program entails. Right now security on the factory floor is focused on perimeter control (network, magnetic card locks, video surveillance, etc) and the human element (checking out each worker and contractor). This may not be good enough in the future - we must get security into each machine.

The opportunity here is to investigate Machine to Machine (M2M) security systems - having part programs secure right to each machine (and perhaps once in them). Machine protocols like open source XML-based MTConnect need a secure version to be considered for ITAR or even cloud-based machine monitoring and Overall Equipment Effectiveness (OEE) programs.

In the days to come, Nexas will be looking into just what would be needed to provide secure factory communications to enable mobile, wireless and cloud-based applications. If factory floor network security is not yet a concern - I think it should be. This may indeed be the "next big thing" in the manufacturing sector worldwide...

Reference Links You Should Check Out...

1. 2014 Kaspersky Industrial Security Review
2. LoJack System for Cargo
3. IMPERVIO Information Rights Management System
4. Finding Your Cyber-Security Weak Spots
5. Tofino Factory Automation Security