Connected cars: Managing and securing data exchange and processing
The automotive sector is making great strides in the IoT space. Cars increasingly include sensors which produce a stream of data, creating a phenomenon called the “connected car,” which uses web APIs to feed information to the consumer and manufacturer. This produces a huge amount of data which must be managed. In addition, APIs are used to control vehicle functionality.
For example, a car owner can use a mobile application to remotely lock/unlock their vehicle and activate the air conditioning five minutes before they get in. This mobile app connects to an API in order to interact with the connected car. In addition, within the transportation industry, an organization can remotely monitor its fleet to ensure its drivers are not driving longer than permitted, potentially falling asleep at the wheel. Car manufacturers such as Ford, Audi, Toyota, and BMW have already jumped on board the connected car trend, and it’s only going to grow as car companies start collaborating with external developers. In fact, cars are on track to soon outnumber mobile apps as API consumers. The sheer amount of data sent to APIs by sensors in cars is staggering.
The rise of the connected car promises a host of benefits, but as with the rise of any new Internet-connected device, data privacy could become a stumbling block to adoption. When it comes to data ownership, the lines between the driver and the manufacturer have the potential to become increasingly blurred. Indeed, in the case of data collected for maintenance purposes and to ensure good service from the manufacturer, it may be assumed that the data belongs to the manufacturer. But what happens for connected cars that provide access “through” the car to Internet services? Whom should the user grant ownership of his/her data to? And consider the scenario of someone driving a car across national borders – how will the car/user, producing a stream of data including sensitive information such as geographical location, impact privacy?
Currently, there are very few regulations around privacy specifically for the connected car. Therefore, organizations need to be able to manage the exchange and processing of data when cars are using APIs from various regulatory jurisdictions with differing data privacy policies. For now, let’s discuss how car manufacturers can soothe privacy fears, manage the APIs that consume data from connected cars, and how this will be fundamental to data security in the future.
In an age of data paranoia, will the current lack of transparency doom the success of the intelligent vehicle? Anything connected to the Internet (including cars) has an “attack surface”, or entry point for malicious activity. Simply trying to keep the system secret is not good enough. An example is Tesla, whose APIs were sniffed and reverse engineered, further demonstrating that you cannot rely on “security through obscurity.”
In a Forbes article earlier this year, reporter Kashmir Hill discussed just how much our cars can know about us. Data recorders in Tesla’s Model S know the temperature settings in the car, the battery level throughout the trip, the car’s speed from minute to minute, and the exact route taken. A Tesla’s wireless communication system allows the vehicle to send information to Tesla Service using cell phone signals. And Tesla isn’t the only car manufacturer monitoring data.
According to the same article, 85% of new cars have black boxes that capture information about the few seconds before and after a crash. Even the US Department of Transportation wants cars to go wireless so they’ll be able to communicate with each other in order to prevent crashes. All of this communication will be conducted through APIs.
Security expert Bruce Schneier said, “[The Tesla controversy] gives you an idea of the sort of things that will be collected once automobile black boxes become the norm. We’re used to airplane black boxes, which only collected a small amount of data from the minutes just before an incident. But that was back when data was expensive. Now that it’s cheap, expect black boxes to collect everything all the time. And once it’s collected, it’ll be used. By auto manufacturers, by insurance companies, by car rental companies, by marketers. The list will be long.”
In addition, Hill states that “We should think now about who gets access to that data and how they do so, because one day soon, your car is going to be as much of a privacy concern as your smartphone.”
And she’s right. Just because cars are now smarter than ever, that doesn’t mean they’re secure. To that point, the more intelligent our cars become, the more adaptable the technology running them needs to be. Car manufacturers are in a sticky situation: how do they ensure the most stringent privacy policies and ease consumer fears as cars become more connected than ever? Because APIs are the mechanism by which connected cars transmit their data, the answer is to understand API requirements and put a successful API management strategy in place.
We know that most applications now have several interfaces, built on different technologies, targeting particular types of users (in this case, car manufacturers and consumers), and are built by a range of interested parties. As APIs become the primary customer interface used for technology-driven products and services, a well-executed API management strategy is key in driving business value while ensuring security.
But what will this strategy will look like? The manufacturers producing these connected cars will have to make sure to approach their associated APIs as an IT project, closely aligned with the vehicle design and manufacturing process. COBIT, for example, provides a four-domain framework that applies directly to API management:
Plan and Organize — This phase ensures that the right APIs are built the right way. Since these APIs are tied to back-end transaction systems that are highly protected and/or secured, it will require more planning than typical consumer APIs. In addition to the APIs themselves, the developer registration and application security model needs to be defined. And the security monitoring and update/patch processes need to be outlined, in case a security problem crops up months or years down the road. Build (Acquire and Implement) — This involves coding and/or re-configuration of APIs and the API management infrastructure. It can involve complete rebuilding of new REST- or SOAP-style APIs, or it can utilize a mediation technology (e.g., an API gateway) to transform old interfaces. Existing developer or partner registration mechanisms can be extended, or in some cases, new programs need to be built out. Deliver and Support — This phase involves delivering all the interdependent aspects of the API management infrastructure and the API implementations themselves. Some phasing may be required, depending on the “app” ecosystem intended to surround the APIs. Closely held apps may be delivered at the same time the API is made public, with partner-developed or community apps following. Monitor and Evaluate — This is all about measuring the usage of APIs, creating baseline metrics and tracking trends and anomalies. For commercialized APIs, there is a major focus on billing and the execution of the revenue cycle. This is also essential in managing the data that APIs collect.
As car manufacturers expose more enterprise APIs that handle sensitive data and business-critical functions, security, management, and access control have become must-have capabilities. Protecting car owners means granting API access only to approved and authenticated parties, and preventing the kind of attacks and breaches that can result in dangerous situations, legal challenges, and compliance penalties. And the growth of the connected car trend is dependent on making it easy to integrate and aggregate partner APIs, no matter what interface protocols or authentication schemes they use.
Managing the data starts with monitoring it. Comprehensive reporting and monitoring capabilities help give visibility and understanding into the performance and quality of API operations. An API reporting architecture should provide flexibility to capture data as required. Additionally, reports should be made accessible, automatically emailed, and delivered to log-management and system-management tools.
Statistics gathered through API reporting provide insight into which APIs are being used, how frequently, and when they’re used, as well as who is using them. Real-time system and traffic monitoring tools that help administrators investigate transaction flows and API-server performance are also essential to a successful API management strategy. In this way, the API usage made by connected cars is visible, monitored and managed.
In summary, IoT devices such as connected cars will overtake mobile apps as the largest consumers of APIs. Car manufacturers can address privacy fears by ensuring that a secure and reliable API management strategy is in place, including a strong monitoring policy that will accurately consume and manage the data from connected cars. Doing so will provide the security needed in order for car manufacturers to successfully enter and thrive in the world of connected cars.
About the author:
John Thielens is CSO at Axway, a global integration and security software company focused on data flow governance. John’s background is in software development and security, and his latest area of research is related to the rapidly evolving API landscape and the new approaches to security required in this area.
This article first appeared in EDN (www.edn.com)
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
