Login
At Black Hat USA 2020, Trend Micro presented two important talks on vulnerabilities in Industrial IoT (IIoT). The first discussed weaknesses in proprietary languages used by industrial robots, and the second talked about vulnerabilities in protocol gateways. Any organization using robots, and any organization running a multi-vendor OT environment, should be aware of these attack surfaces. Here is a summary of the key points from each talk.
Rogue Automation
Presented at Black Hat, Wednesday, August 5. https://www.blackhat.com/us-20/briefings/schedule/index.html#otrazor-static-code-analysis-for-vulnerability-discovery-in-industrial-automation-scripts-19523 and the corresponding research paper is available at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/unveiling-the-hidden-risks-of-industrial-automation-programming
Industrial robots contain powerful, fully capable computers. Unlike most contemporary computers, though, industrial robots lack basic information security capabilities. First, at the architectural level, they lack any mechanism to isolate certain instructions or memory. That is, any program can alter any piece of storage, or run any instruction. In traditional mainframes, no application could access, change, or run any code in another application or in the operating system. Even smartphone operating systems have privilege separation. An application cannot access a smartphone’s camera, for instance, without being specifically permitted to do so. Industrial robots allow any code to read, access, modify, or run any device connected to the system, including the clock. That eliminates data integrity in industrial robots and invalidates any audit of malfunctions; debugging becomes exceptionally difficult.
Industrial robots do not use conventional programming languages, like C or Python. Instead, each manufacturer provides its own proprietary programming language. That means a specialist using one industrial robot cannot use another vendor’s machine without training. There are no common information security tools for code validation, since vendors do not develop products for fragmented markets. These languages describe programs telling the robot how to move. They also support reading and writing data, analyzing and modifying files, opening and closing input/output devices, getting and sending information over a network, and accessing and changing status indicators on connected sensors. Once a program starts to run on an industrial robot, it can do anything any fully functional computer can do, without any security controls at all. Contemporary industrial robots do not have any countermeasures against this threat.
Most industrial robot owners do not write their own programs. The supply chain for industrial robot programs involves many third-party actors. See Figure 1 below for a simplified diagram. In each community, users of a particular vendor’s languages share code informally, and rely on user’s groups for hints and tips to solve common tasks. These forums rarely discuss security measures. Many organizations hire third-party contractors to implement particular processes, but there are no security certifications relevant to these proprietary languages. Most programmers learned their trade in an air-gapped world, and still rely on a perimeter which separates the safe users and code inside from the untrusted users and code outside. The languages offer no code scanners to identify potential weaknesses, such as not validating inputs, modifying system services, altering device state, or replacing system functions. The machines do not have a software asset management capability, so knowing where the components of a running program originated from is uncertain.
Figure 1: The Supply Chain for Industrial Robot Programming
All is not lost – not quite. In the short term, Trend Micro Research has developed a static code analysis tool called OTRazor, which examines robotic code for unsafe code patterns. This was demonstrated during our session at Black Hat.
Over time, vendors will have to introduce basic security checks, such as authentication, authorization, data integrity, and data confidentiality. The vendors will also have to introduce architectural restrictions – for instance, an application should be able to read the clock but not change it.. Applications should not be able to modify system files, programs, or data, nor should they be able to modify other applications. These changes will take years to arrive in the market, however. Until then, CISOs should audit industrial robot programs for vulnerabilities, and segment networks including industrial robots, and apply baseline security programs, as they do now, for both internally developed and procured software.
Protocol Gateway Vulnerabilities
Presented at Black Hat, Wednesday, August 5, https://www.blackhat.com/us-20/briefings/schedule/index.html#industrial-protocol-gateways-under-analysis-20632, with the corresponding research paper available here: https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/lost-in-translation-when-industrial-protocol-translation-goes-wrong.
Industry 4.0 leverages the power of automation alongside the rich layer of software process control tools, particularly Enterprise Resource Planning (ERP), and its bigger cousin, Supply Chain Management (SCM). By bringing together dynamic industrial process control with hyper-efficient “just-in-time” resource scheduling, manufacturers can achieve minimum cost, minimum delay, and optimal production. But these integration projects require that IIoT devices speak with other technology, including IIoT from other manufacturers and legacy equipment. Since each equipment or device may have their own communication protocol, Industry 4.0 relies heavily on protocol converters.
Protocol converters are simple, highly efficient, low-cost devices that translate one protocol into another. Protocol converters are ubiquitous, but they lack any basic security capabilities – authentication, authorization, data integrity or data confidentiality – and they sit right in the middle of the OT network. Attackers can subvert protocol converters to hijack the communication or change configuration. An attacker can disable a safety thresholds, generate a denial of service attack, and misdirect an attached piece of equipment.
In the course of this research, we found nine vulnerabilities and are working with vendors to remediate the issues. Through our TXOne subsidiary, we are developing rules and intelligence specifically for IIoT message traffic, which are then embedded in our current network security offerings, providing administrators with better visibility and the ability to enforce security policies in their OT networks.
Protocol converters present a broad attack surface, as they have limited native information security capabilities. They don’t validate senders or receivers, nor do they scan or verify message contents. Due to their crucial position in the middle of the OT network, they are an exceptionally appealing target for malicious actors. Organizations using protocol converters – especially those on the way to Industry 4.0 – must address these weak but critical components of their evolving infrastructure.
What do you think? Let me know in the comments below or @WilliamMalikTM
The post Black Hat Trip Report – Trend Micro appeared first on .
Connected cars are on the move. Globally their number is set to grow 270% between 2018 and 2022 to reach an estimated 125 million in a couple of years. Increasingly, these vehicles are more akin to high-performance mobile computers with wheels than traditional cars, with features including internet access, app-based remote monitoring and management, advanced driver-assistance, and autonomous driving capabilities. But this also leaves them exposed to sensitive data theft and remote manipulation, which could create serious physical safety issues.
This is where a new standard comes in. ISO/SAE 21434 creates detailed guidance for the automotive industry to help it navigate these challenges and reduce reputational and cyber-risk. A new report from Trend Micro details what industry stakeholders need to, along with our recommendations as cybersecurity experts.
Packed with power
Modern automobiles do far more than transport their occupants from A to B. They are filled with computing power, sensors, infotainment systems and connectivity to help improve the car experience, traffic safety, vehicle maintenance and much more. This all creates complexity, which in turn leads to the emergence of cybersecurity gaps.
For example, there are now more than 100 engine control units (ECUs) in many modern vehicles, packed with software to control everything from the engine and suspension to the brakes. By hijacking the execution of any ECU an attacker could move laterally to any target in the vehicle, potentially allowing them to remotely cause life-threatening accidents.
As our report explains, there are three fundamental issues that make securing connected cars challenging:
Vulnerabilities are difficult to patch due to the highly tiered mature of car supply chains, firmware interoperability and long update times. If updates fail, as they can, a vehicle may be left inoperable.
Protocols used for connectivity between ECUs were not designed with security in mind, allowing attackers to conduct lateral movement.
Aftermarket products and services represent a third area of risk exposure. Akin to unsecured IoT devices in the smart home, they can be abused by attackers to pivot to more sensitive parts of the vehicle.
These vulnerabilities have been highlighted in research dating back years, but as connected cars grow in number, real-world attacks are now starting to emerge. Attack scenarios target everything from user applications to network protocols, to the CAN bus, on-board software and more. In short, there’s much for the bad guys to gain and plenty for carmakers to lose.
Here to help
This is where the new standard comes in. ISO/SAE 21434 “Road vehicles – Cybersecurity engineering” is a typically long and detailed document designed to improve automotive cybersecurity and risk mitigation across the entire supply chain — from vehicle design and engineering through to decommissioning.
As a long-time collaborator with the automotive industry, Trend Micro welcomes the new standard as a way to enhance security-by-design in an area coming under the increasing scrutiny of attackers. In fact, eight out of the world’s top 10 automotive companies have adopted Trend Micro solutions for their enterprise IT.
In order to follow ISO/SAE 21434 and protect connected cars, organizations need comprehensive visibility and control of the entire connected car ecosystem, including: vehicle, network and backend systems. They should then consider developing a Vehicle Security Operations Center (VSOC) to manage notifications coming in from all three areas and to create a bird’s eye view of the entire ecosystem.
Consider the following capabilities in each of these key areas:
Vehicle: Detect in-vehicle vulnerabilities and possible exploitation, including those in critical devices that connected the in-vehicle network to outside networks, for instance, in-vehicle infotainment systems (IVI) and telematic control units (TCUs).
Network: Apply network security policy, monitoring traffic to detect and prevent threats including connections between vehicle and backend cloud and data centers.
Backend: Secure data centers, cloud and containers from known and unknown threats and bugs without compromising performance.
Vehicle SOC: Take quick and effective action by correlating threats detected from the endpoint, network, and backend with individual notifications from each, enabling a bird’s eye view of comprehensive elements.
In uncertain times for the industry, it pays to get ahead of the game, and any prospective changes in local laws that the new ISO/SAE standard may encourage. For carmakers looking to differentiate in a tough market, and do the right thing by protecting their customers, Trend Micro is here to help.
To find out more, read the full report here.
The post ISO/SAE 21434: It’s time to put the brakes on connected car cyber-threats appeared first on .
Intelligent transportation systems (ITS) require harmonization among manufacturers to have any chance of succeeding in the real world. No large-scale car manufacturer, multimodal shipper, or MaaS (Mobility as a Service) provider will risk investing in a single-vendor solution. Successful ITS require interoperable components, especially for managing cybersecurity issues. See https://www.trendmicro.com/vinfo/us/security/news/intelligent-transportation-systems for a set of reports on ITS cybersecurity.
The good news is we now have a standard for automotive cybersecurity, ISA/SAE 21434. This standard addresses all the major elements of connected car security including V2X, reaching from the internals of ECUs and communications busses including CAN to the broader issues of fleet management and public safety. See https://www.iso.org/standard/70918.html for the current draft version of this standard.
Intelligent transport systems rely on complex, contemporary infrastructure elements, including cloud (for data aggregation, traffic analysis, and system-wide recommendations) and 5G (for inter-component networking and real-time sensing). ITS also rely on aging industrial control systems and components, for vehicle detection, weather reporting, and traffic signaling, some dating back forty years or more. This profound heterogeneity makes the cybersecurity problem unwieldy. Automotive systems generally are the most complex public-facing applications of industrial IoT. Any information security problems with them will erode public trust in this important and ultimately critical infrastructure.
Robert Bosch GmbH began working on the first automotive bus architecture in 1986. Automobiles gained increasing electronic functions (smog controls, seat belt monitors, electric window controls, climate controls, and so on). With each new device, the manufacturers had to install additional point-to-point wiring to monitor and control them. This led to increasing complexity, the possibility for error, extended manufacturing time, more costly diagnosis and repair post-sales, and added weight. See Figure 1 for details. By replacing point-to-point wiring with a simple bus, manufacturers could introduce new features connected with one pair of wires for control. This simplified design, manufacturing, diagnosis, and improved quality and maintainability.
Figure 1: CAN Networks Significantly Reduce Wiring (from National Instruments https://www.ni.com/en-us/innovations/white-papers/06/controller-area-network–can–overview.html)
The bus was simple: all devices saw all traffic and responded to messages relevant to them. Each message has a standard format, with a header describing the message content and priority (the arbitration IDs), the body which contains the relevant data, and a cyclic redundancy check (CRC), which is a code to verify that the message contents are accurate. This CRC uses a mathematical formula to determine if any bits have flipped, and for small numbers of errors can correct the message, like a checksum. This is not as powerful as a digital signature. It has no cryptographic power. Every device on the bus can use the CRC algorithm to create a code for messages it sends and to verify the data integrity of messages it receives. Other than this, there is no data confidentiality, authentication, authorization, data integrity, or non-repudiation in CAN bus messages – or any other automotive bus messages. The devices used in cars are generally quite simple, lightweight, and inexpensive: 8-bit processors with little memory on board. Any device connected to the network is trusted. Figure 2 shows the layout of a CAN bus message.
Figure 2: The Standard CAN Frame Format, from National Instruments
Today’s automobiles have more sophisticated devices on board. The types of messages and the services the offer are becoming more complex. In-vehicle infotainment (IVI) systems provide maps, music, Bluetooth connectivity for smartphones and other devices, in addition to increasingly more elaborate driving assistance and monitoring systems all add more traffic to the bus. But given the diversity of manufacturers and suppliers, impeding security measures over the automotive network. No single vendor could today achieve what Robert Bosch did nearly forty years ago. Yet the need for stronger vehicle security is growing.
The ISO/SAE 21434 standard describes a model for securing the supply chain for automotive technology, for validating the integrity of the development process, detecting vulnerabilities and cybersecurity attacks in automotive systems, and managing the deployment of fixes as needed. It is comprehensive. ISO/SAE 21434 builds on decades of work in information security. By applying that body of knowledge to the automotive case, the standard will move the industry towards a safer and more trustworthy connected car world.
But the standard’s value doesn’t stop with cars and intelligent transport systems. Domains far beyond connected cars will benefit from having a model for securing communications among elements from diverse manufacturers sharing a common bus. The CAN bus and related technologies are used onboard ships, in aircraft, in railroad management, in maritime port systems, and even in controlling prosthetic limbs. The vulnerabilities are common, the complexity of the supply chain is equivalent, and the need for a comprehensive architectural solution is as great. So this standard is a superb achievement and will go far to improve the quality, reliability, and trustworthiness of critical systems globally.
What do you think? Let me know in the comments below or @WilliamMalikTM.
The post Connected Car Standards – Thank Goodness! appeared first on .
“Alexa, turn on the TV.”
”Get it yourself.”
This nightmare scenario could play out millions of times unless people take steps to protect their IoT devices. The situation is even worse in industrial settings. Smart manufacturing, that is, Industry 4.0, relies on tight integration between IT systems and OT systems. Enterprise resource planning (ERP) software has evolved into supply chain management (SCM) systems, reaching across organizational and national boundaries to gather all forms of inputs, parting out subcomponent development and production, and delivering finished products, payments, and capabilities across a global canvas.
Each of these synergies fulfills a rational business goal: optimize scarce resources across diverse sources; minimize manufacturing, shipping, and warehousing expense across regions; preserve continuity of operations by diversifying suppliers; maximize sales among multiple delivery channels. The supply chain includes not only raw materials for manufacturing, but also third party suppliers of components, outsourced staff for non-core business functions, open source software to optimize development costs, and subcontractors to fulfill specialized design, assembly, testing, and distribution tasks. Each element of the supply chain is an attack surface.
Software development has long been a team effort. Not since the 1970s have companies sought out the exceptional talented solo developer whose code was exquisite, flawless, ineffable, undocumented, and impossible to maintain. Now designs must be clear across the team, and testing requires close collaboration between architects, designers, developers, and production. Teams identify business requirements, then compose a solution from components sourced from publically shared libraries. These libraries may contain further dependencies on yet other third-party code of unknown provenance. Simplified testing relies on the quality of the shared libraries, but shared library routines may have latent (or intentionally hidden) defects that do not come to life until in a vulnerable production environment. Who tests GitHub? The scope of these vulnerabilities is daunting. Trend Micro just published a report, “Attacks on Smart Manufacturing Systems: A Forward-looking Security Analysis,” that surveys the Industry 4.0 attack surface.
Within the manufacturing operation, the blending of IT and OT exposes additional attack surfaces. Industrial robots provide a clear example. Industrial robots are tireless, precision machines programmed to perform exacting tasks rapidly and flawlessly. What did industry do before robots? Factories either relied on hand-built products or on non-programmable machines that had to be retooled for any change in product specifications. Hand-built technology required highly skilled machinists, who are expensive and require time to deliver. See Figure 1 for an example.
Figure 1: The cost of precision
Non-programmable robots require factory down time for retooling, a process that can take weeks. Before programmable industrial robots, automobile factories would deliver a single body style across multiple years of production. Programmable robots can produce different configurations of materials with no down time. They are used everywhere in manufacturing, warehousing, distribution centers, farming, mining, and soon guiding delivery vehicles. The supply chain is automated.
However, the supply chain is not secure. The protocols industrial robots depend on assumed the environment was isolated. One controller would govern the machines in one location. Since the connection between the controller and the managed robots was hard-wired, there was no need for operator identification or message verification. My controller would never see your robot. My controller would only connect to my robot, so the messages they exchanged needed no authentication. Each device assumed all its connections were externally verified. Even the safety systems assumed the network was untainted and trustworthy. No protocols included any security or privacy controls. Then Industry 4.0 adopted wireless communications.
The move, which saved the cost of laying cable in the factory, opened those networks to eavesdropping and attacks. Every possible attack against industrial robots is happening now. Bad guys are forging commands, altering specifications, changing or suppressing error alerts, modifying output statistics, and rewriting logs. The consequences can be vast yet nearly undetectable. In the current report on Rogue Robots, our Forward-looking Threat Research team, collaborating with the Politecnico di Milano (POLIMI), analyzes the range of specific attacks today’s robots face, and the potential consequences those attacks may have.
Owners and operators of programmable robots should heed the warnings of this research, and consider various suggested remedies. Forewarned is forearmed.
The Rogue Robots research is here: https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/rogue-robots-testing-industrial-robot-security.
The new report, Attacks on Smart Manufacturing Systems: A Forward-looking Security Analysis, is here: https://www.trendmicro.com/vinfo/us/security/threat-intelligence-center/internet-of-things/threats-and-consequences-a-security-analysis-of-smart-manufacturing-systems.
What do you think? Let me know in the comments below, or @WilliamMalikTM.
The post Securing Smart Manufacturing appeared first on .
FreshRSS 