Getting locked out of your car is frustrating. Getting locked out of your car because the app controlling it crashed is even more baffling. This is exactly what happened recently to Tesla’s customers who suffered from a network outage that prevented them from accessing their cars. Needless to say, the company’s operations and business also took a serious hit. The cause? A broken network API.
According to the recent “Connected Car Market” report, the global connected car market is projected to reach $212.7 billion by 2027, up from an estimated $ 42.6 billion in 2019.A major driver of this growth comes from the rapid development of new technological functionalities and features that were added to the modern car experience. These include connected apps, in-car internet, remote software upgrades/diagnostics. There’s even in-car delivery service provided by Amazon.
These notable developments also create new points of entry for cyber-attacks.
The role of APIs in this new industry landscape
What happened to Tesla is much more than an example of vulnerabilities to API. It shows just how much APIs have become part of our day-to-day lives. APIs used to just help us operate apps and external services. But as time goes by, we increasingly rely on them to interact also with the physical world.
APIs play a crucial role in supporting the digital transformation, innovation and growth of the connected car industry. For an industry being very sensitive to trust and reputation, API vulnerabilities create three main challenges:
- Protect of PII and sensitive data of car owners and drivers
- Prevent attacks from crossing into the physical assets
- Maintain interoperability with the automotive ecosystem, e.g. fleet operators
Consider the following example:
A remote control system was installed in new cars under their own brand or under one of many OEM brands. The user (car owner) then installed an aftermarket telematics unit that adds smartphone-controlled geolocation and remote start/stop and lock/unlock capabilities to a vehicle with a compatible remote start unit.
The Breach: The controls of the aftermarket-installed mobile application contained hard-coded admin credentials, which were used by the attacker to gain access to the API server and, subsequently, access to data and functionality of the car.
A compromised endpoint (e.g. car or service provider) can enable an attack on the OEM servers and on the entire fleet which could lead to:
- Massive data privacy leakage
- Ransomware attack fleet-wide
- Fleet-wide loss of control
- Denial of Service attack
Protecting connected cars requires continuous monitoring and analysis of data flux between cars and their immediate environments. The inherent lack of API security and their proprietary nature makes APIs a prime target for the next big wave of cyberattacks in the realm of connected cars.
API security best practices for the connected car industry
For connected cars, the rapid identification and prevention of API breaches is of paramount importance. As such, embedding API security capabilities into the automotive SOC facilities can allow real-time monitoring and detection of abnormal behaviors of data flux in connected car API calls.
Once a breach is detected, the SOC receives complete information about the incident, and the system is set to immediately block the attacker. The SOC can then close the loop by researching the API vulnerability and work with the development team to fix the underlying issue/vulnerability in the software.
Based on our experience, we’ve gathered some best practices we wanted to share with you:
- Keep a tidy and up to date inventory of your APIs. According to Gartner: ”Each new API represents an additional and potentially unique attack vector into your systems”. This makes the task of keeping an API inventory into the cornerstone of providing an effective response. Such inventory should start with a full, up-to-date list of all APIs used, both internally and externally, but more importantly: include a definition of each and every API’s purpose, takinginto consideration the API’s entire lifecycle. Now that you have a comprehensive view of all APIs across the enterprise, it’s time to get a complete picture of their security risks. Next step would be to prioritize the APIs listed on the inventory by their risk level. Leading organizations today are defining their API taxonomy in a way that is highly correlated with their risk level.
- Gather knowledge. The average API has approximately 27 major vulnerabilities, and organizations can have up to tens of thousands of APIs. That’s a lot of potential blindspots to cover. To enable better capabilities to tackle API threats it is important to gain insights about the exposure of vulnerabilities and attack pathways. Vulnerabilities mapping should incorporate data from various sources. The maps display connections to vulnerabilities between and within APIs and also the attacker’s potential lateral pathways. After mapping the known security vulnerabilities you can plot out where those vulnerabilities exist, and develop mechanisms to stay on top of emerging threats and trends.
- Gain real-time visibility. Proactively identifying API anomalies and responding to attacks wherever and however APIs are deployed is crucial. When it comes to APIs, “business as usual” is what we strive for. Any unexpected deviation in API behaviors can be classified as an anomaly. Keep in mind that anomalies can be either negative or positive. Some anomalies may be easier to detect than others. Occasionally, you’ll see massive deviations in API’s behavior. And other times there are those subtle, unnoticed glitches. Real time visibility results in results in miniscule false positive rates
All these best practices can be done using various tools and methods. But like in many other cases, when automation is involved it’s better.