- SheeldS Contributor
Predicting Automotive Cyber-Security Technologies – Insight from Other Industries – Part 4 of 6
Examining cyber-security technologies used to defend IT and ICS/SCADA industries sheds light on what to expect for automotive cyber-security. Part 4 of 6.
On our first post in this series, we walked through a brief introduction of the history of connectivity and networking in IT, and ICS/SCADA industries. Our second post looked at historical initial, decisive and critical cyber-security events in these areas, and how they can be used to predict potential upcoming attacks on the automotive industry. Last month’s post examined the impact and response from industry to these formative events.
This instalment dives into the more technical aspects of cyber-security in these industries. We look at the network characteristics employed by each sector, and common and differentiating potential attack vectors. We also explore the state of current security installations and look at how updates are managed.
In IT networks, user behavior is often unpredictable and chaotic. For example, each user may attempt to access any website at any time, and it would be legitimate behavior in most cases. This makes protection complex.
These networks are static and deterministic with very clear and predictable behavior. If, during installation, a baseline is established it is unlikely ever to change. If, for example, a PLC communicates with the historian – a connection is set from the PLC IP address to the historian IP address. This uses clear layer 4 protocols such as the Transmission Control Protocol (TCP) and a designated and predefined service port that will never change. Even the volumetric measurements are predictable over time. There is no reason for a PLC to suddenly start communicating with a neighbor PLC under any circumstances. Known changes are a function of well-determined events – such as day/night/weekend routines – or the presence of a technician on site. Protection of these networks is made somewhat easier for as a result.
In this case, automotive is the same as ICS/SCADA. An ECU will always generate specific messages, which can be detected and monitored. For example, a vehicle’s infotainment system has no business suddenly sending commands to the power train. The vehicle cannot jump from 10 Km/h to 100 Km/h in 100ms. Here too there are contexts under which rules can change dependent on function – moving between switch off, accessory attachment, or the on position. Connection of diagnostic devices through the Onboard Diagnostic (OBD) port will change network behavior too but in a well anticipated and determined fashion.
Initially, these started as head-on attacks – for example, directly targeting databases. But as time went on these attacks became much more complex. Hopping from one type of software and one server to another, utilizing different means until reaching the target. Currently, there is a virtually infinite range of possibilities beyond the scope of this article.
Here too the process has evolved but the complexity is much greater. Simple cases of direct attacks on ICS/SCADA devices grow more common and more advanced. A recent case involved the US retailer Target. It was attacked using a mixed attack scenario combining several technologies and networks. The attack began on a Heat Ventilation and Air Conditioning (HVAC) technician’s laptop, this infected the ICS/SCADA of the building management network. From there, the malware was propagated via the OT-IT connection into the IT side of the network, aiming for the database. As a result, 110 million customer credit card details were leaked onto the internet. Since we anticipate state actors to play in this field, it is likely the sophistication of such attacks will grow.
Access via the internet is the immediate and most likely attack path but not the only one. Connected devices such as the infotainment system normally reside on a separate network bus than the attacker’s target (mostly engine ECUs). This makes the attack process complex. An attacker will need to hop from ECU to ECU, traversing the related gateways to reach their target.
Despite this complexity, vehicle hackers have a distinct advantage – exact examples of the target vehicle (make, model and year) are easily obtained. This means malicious actors can test and improve their attack methods undisturbed until their scenarios are ready.
This is quite different than with IT and ICS/SCADA where an attacker might possess some components of the system. Having full access to the system, which would allow access to previously unknown components, might cause the hacker’s target to differ from expected behavior. Trying various methods on the real system might allow other vulnerabilities to be discovered in early attack planning stages.
Currently, security installation is performed during the initial setup of any networked device. Additionally, security software is frequently updated via the network for the device’s entire lifecycle. This includes both endpoint protection, such as Host Intrusion Detection & Prevention Systems (HIDPS), and Network Intrusion Detection and Prevention Systems (NIDPS).
A wide variety of tools and methodologies exist to support this, including secured architectures secured design, secured development. A layered approach is employed since there is no silver bullet that protects all cases. The assumption being that each security measure can be breached. End-point protection is used in the form of a host firewall and anti-virus. This compliments usage policy and other organizational processes that are used together with VLANs, VPNs, network firewalls, NATs, among other solutions. NIDPS and honeypots are deployed for additional surveillance of the network.
Education and awareness need to be actively pursued in every organization. Physical security such as fences, surveillance cameras, barriers, area segregation and access control need to be widely embraced to prevent unauthorized access to sensitive locations such as data centers.
For legacy installations, the security installation process is an attempt to update and harden the existing setup, together with the addition of new security options. In many cases, the original ICS/SCADA devices were not designed to provide resources for – or accommodate – additional security software. This is because no threat scenarios existed at that time.
Furthermore, engineers resisted such processes since it involved downtime, require extensive testing, and itself was a potential vector for malware penetration. As such, most ICS/SCADA security devices are focused on network protection.
For new installations, designing a secured architecture during the design phase, together with endpoint protection and network security is a viable option. Updates can be distributed relatively easily via the network, but as mentioned earlier, this is an expensive and complex procedure due to the rigorous testing those systems need to receive before they can be deployed to the field.
In automotive, the situation is like that of ICS/SCADA. For aftermarket, non-connected cars, any software and cyber-security update implies, in most cases, a recall of the whole vehicle fleet. This was the case for the Jeep Cherokee with immense direct costs and as yet unresolved lawsuits. For connected cars, line-fit of cyber-security solutions is possible during assembly. In such cases, a combination of secured architecture design, endpoint protection, and network security can be implemented. Additionally, updates can be distributed Over-The-Air (OTA) but unless the vehicle is designed to support OTA from the beginning, retrofitting for this can be a costly and complex process.
For IT this is a relatively easy process. Mechanisms are common and well established for many types of software updates, including, among others, security updates, anti-virus software and signature database updates.
IT staff can control and delay the installation of select updates. This allows time for testing in sandbox environments. However, this can expose the organization to zero-day attacks that might have been prevented if the installation of the update had not been delayed.
This is generally regarded as a nightmare. ICS/SCADA updates are generally only rolled out for very special cases and it is a rare event. The working concept is: if it ain’t broke, don’t fix it. One can find many cases where PLCs were not updated for more than 10 years (since they performed adequately). It is very common to find computers running on an outdated and unsupported Operating System (OS) such as Windows 95 and Windows XP.
Performing an upgrade to a power sub-station can be at least a six-month project. Any changes must undergo extensive testing before implementation. In recent years – due to increased industry awareness – updates have become more frequent. However, even these updates are regarded as something best avoided if possible.
For legacy fleets, updates are possible during diagnostics, during a recall or via a silent recall (during regular servicing). Testing of vehicles is relatively simple in comparison to ICS/SCADA. It can be performed on dedicated vehicles that are identical to those on the road. This key difference between ICS/SCADA and automotive installations is that automotive updates must be made to a live system.
In recent years OEMs have begun to adopt OTA updates. This is despite indecision about who should shoulder the financial burden. OTA updates are usually achieved via cellular networks which require the payment of data transfer fees, either by the vehicle owner or by the OEM.
While the OTA process enables quicker software updates, it presents new threats and hurdles. These include providing opportunities – as we have seen in the case of ICS/SCADA – for hackers to inject new malware into the vehicle. Despite this, the opportunity to perform a fast, remote update is much more common in the automotive industry than it is in the ICS/SCADA world.
**Cerrado, previously known as Arilou