Nissan LEAF, API Security, Who Owns API Security, and How Much Security Is Enough?

This post was originally published as “Nissan LEAF, API Security, Who Owns API Security, and How Much Security Is Enough?” on the Levvel Blog.

What does API Security look like? Who owns API Security? How much security is enough? Nebulous questions to be sure, but very important.

Nissan offers a mobile app (iOS and Android devices) to Nissan LEAF owners that allows the user to access information about their car and turn the heat and air conditioning on and off. You can see a detailed description of what happened to the Nissan LEAF CarWings App recently here; for anyone who doesn’t want to subject themselves to the details, you can read the high-level version here. In this instance, it was possible to retrieve personal information (username, driving history) and enable the heat & air conditioning without providing authentication information beyond the Vehicle Identification Number (VIN). VINs are more-or-less public information; it is essentially being used as an API Key — API Keys are supposed to be secret, not publicly obtainable. I discuss the use of API Keys (or Subscription Keys) briefly in my earlier posts (“Protecting Server Resources Hosting Unauthenticated APIs” and “What Are APIs?”). In general, an API Key should only be used by an application that is capable of keeping it secret. A mobile application is not capable of keeping that key a secret. The phone can be rooted, the application code can be decompiled, the key can be found. There are several tricks you can play to attempt to obfuscate the key, but the determined party will eventually be able to find it. So, API keys with native mobile apps is a bad idea.

So, we have established that using the VIN as an API Key is not a good idea.

So, how could they have gone about securing this CarWings API? I briefly introduced my methodology for analyzing security requirements for really any type of IT system here. Basically, every application security solution to some extent addresses the following topics:

Authentication: The process of proving your identity to the system.

Authorization: The process of determining if the authenticated identity is allowed to access the requested server resource based upon a predefined authorization policy.

Confidentiality: Limiting access to the data to parties that should be allowed to see it in transit or at rest.

Integrity: Ensure that the message was not modified in transit between two actors.

Non-Repudiation: Assurance that the actor who sent the message cannot deny that it sent it.

Availability: Measure of the system performing as required.

Auditability: Ability of an Information Security Auditor to have sufficient information after the fact to reproduce an event of interest and confirm that appropriate security policies are in place regarding all aspects of the system (for application users and administrative users

Identity Propagation: A mechanism that, ideally, securely transmits an authenticated identity from one system actor to another (think SAML 2.0 Bearer Tokens or JWT tokens).

The answer to these questions is largely driven by the sensitivity of the data involved and how that data can be manipulated. In the Nissan LEAF example, were two basic access issues: 1) unauthorized third-parties gaining access to driving history and 2) being able to remotely turn the heat and air conditioning on or off without the proper authentication & authorization. The first one is obviously a privacy violation of the car owner. The second is annoying and potentially dangerous (if the battery runs down in a remote location). The first is a basic data access issue that came about due to no authentication on the API. The second issue is a real-world, side effect of a third-party being allowed to manipulate data that they should not have been allowed access too. The measure of data sensitivity is a Data Classification Standard. Every organization should have a Data Classification Standard — if yours does not, it would behoove you to define one. Some examples of Data Classification Standards (from a quick Google Search):

Ideally, a Data Classification Standard would match your organizations structure, the type of data it deals with, and how that data is used. As a simplistic example, is any data allowed to be access by external parties? If so, the Data Classification Standard should reflect that. More on that in a later blog post. For our immediate purposes, let’s define all data related to the operation of a vehicle or its owner and driver as sensitive information that can only be accessed by either the car owner or an appropriate company or business partner employee. Business Partners with a legitimate need to access this data could be the dealership that sold the car and a certified mechanic shop that the vehicle owner has chosen to use. Let’s further assume that the vehicle owner has to actually grant these organizations access to their personal information and to the vehicle’s data. In the real world, the security requirements are almost certainly more complicated than this, but this is a blog post that is supposed to be read in ten minutes or less (yes, Chris, I have been listening to your feedback).

I referred to application security a moment ago; API Security is one type of application security. Is securing an API really that different from securing other application components? Not really. Whether securing a SOAP Web Service, REST API, Web Application, or a native Windows Desktop Application the same criteria I mentioned above need to be sufficiently addressed in any legitimate application security model. But, APIs are what we’re talking about and APIs, API Management, and API Security is my focus right now; so, we’ll keep calling it API Security. API Security has its own standards and methodologies for addressing the security criteria I mention above.

Let’s establish how each of these security criteria should be addressed.

From the public commentary and my thoughts above, it is pretty obvious that Authentication to this API is required. The system as we understand it has several actors that need to be authenticated in various use cases; the end-user (car owner) using a mobile app, the mobile app invoking the CarWings API, the car company employees that maintain the system, third-party car dealerships that sold these cars to car owners, the mechanic shop working on the car, and likely others. Unfortunately, we must focus on the use of the API for this discussion. By extension, since the Mobile App is invoking the API, we’ll also discuss the authentication of the car owner using the mobile app. Unlike the consumers of the unauthenticated API I previously described, this Nissan app requires the end-user to log into the application based on my understanding of how it works. If the app does not require the user to be authenticated previously, it is going to have to now. So, let’s assume that the end-user identity has been authenticated by the application via an Identity Provider (either controlled by the car company or by a trusted third-party such as Azure Active Directory, Google, Ping ONE, many others). This mobile app authentication step can be handled via three-legged OAuth with Azure Active Directory and an Open-Source AAD client library that Microsoft has published for various mobile platforms (among many other potential solutions). The end result would be a OAuth 2.0 access_token that can be cached in memory for a time and periodically refreshed using the refresh_token that was also included in the final OAuth response. Let’s go one step further and assume that OpenID Connect is being utilized and that the access_token is a JSON Web Token (JWT). At this point, the mobile app is going to act as an API Consumer and begin making calls to the CarWings API. Every API Request must have a JWT token in the HTTP Authorization header as defined in RFC 6750. The CarWings API must implement an authentication layer that validates the JWT per the JWT spec. There are numerous guidelines, best practices and case-by-case considerations that are beyond the scope of this limited discussion.

For the Authorization criteria (again, focusing on the API), the information we have learned about the gaps and ways to exploit the existing API, leads to the conclusion that an authorization decision for each authenticated request is a must. For example, just because Joe Shmoe the LEAF driver is who he claims to be (an authenticated user), does not mean that he gets to access Jon Smith’s (another LEAF driver) data and enable his air conditioning. Likewise, if the same identity provider is used across Business-to-Consumer (B2C), Business-to-Employee (B2E), and Business-to-Business (B2B) concerns (a possibility depending on the Identity Stack architecture), then simply allowing any authenticated user to access any functionality the API offers would allow car company employees or employees of third-party business partners to access information about any LEAF car driver. Obviously, this is undesirable. So, an authorization step is needed that a) validates the caller is a LEAF owner, b) the owner has registered for use of the CarWings platform, c) is attempting to access information or manipulate data for the car they own. Requirement (a) could be implemented with a simple Role-Based Access Control (RBAC) check. In Security Models I design, I generally characterize this as a Course Grained Authorization decision. Requirement (b) could be implemented via an attribute set for that user in the User Repository (think Azure Active Directory tenant or LDAP instance) — this is often referred to Attribute-Based Access Control (ABAC). ABAC often comes into play in more advanced Fine Grained Authorization decision use cases. The difference between Coarse Grained Authorization and Fine Grained Authorization is very loosely defined. I usually recommend defining use cases and characterizing them as one or other.

For example, a classic RBAC scenario is a Coarse Grained Authorization decision; anything that requires more domain or business context information to implement is a Fine Grained Authorization decision. I have witnessed some very heated debates regarding the definition of these terms; the definitions tend to vary between organizations. The authorization policy must also define rules for all other categories of users that will interact with this API. There are numerous products (proprietary and standards-based) and Open Source projects that can be used to define and enforce authorization — that for a blog post in the future. The authorization decision enforcement layer should generally reject any request that doesn’t have a specific allow rule defined.

For Confidentiality, between the Mobile App and the API endpoint, all API calls should be made over HTTPS (over TLS 1.2). This is driven by the use of JWT Bearer Tokens, OAuth 2.0, and OpenID Connect — these specs call for the use of transport layer security (ie, TLS). Likewise, the nature of the data (personal information that should remain private) would also drive us towards passing all data over an encrypted channel.

For Integrity, given that the only thing that can be changed or modified is the activation/deactivation of the environmental controls, I don’t believe that something like a digital signature on every request is necessary. Likewise, implementing something like that securely on a mobile app would be difficult (but, not impossible). Likewise, the use of TLS provides a level of message integrity that should be more than sufficient for this use case.

For availability, I’m going to assume that any large car company that has advertised features like this have built up some expectation that the mobile app will generally work — I can imagine the fine print. It sounds like the API is deployed in multiple countries. So, there is a significant level of redundancy built into the API around the world. Ideally, each locale would have multiple data centers that are capable of functioning independently. Even better, the API and its supporting systems would be deployed on one of the major cloud providers and data would be replicated across instances relatively efficiently. Let’s assume the car company has invested sufficiently in IT infrastructure, process, and automation to achieve 3 9’s (99.9% availability) — 4 9’s would be better.

The articles referenced at the beginning of this post suggest that while the API is deployed locally in each country where the Nissan LEAF is sold, there seemed to be differences in the API that could be attributable to different groups within the company or various third-parties control each one. So, there is no central control of the API and the security layers that have been described here. This is where an API Gateway solution such as Apigee Edge Public Cloud or one of its competitors could come in very handy. It would provide a centrally-managed, highly-available, cloud-hosted platform that could provide the authentication & authorization enforcement, TLS termination point, a common interface for APIs across regions and numerous other benefits (SQL Injection detection, Cross-Site Scripting vulnerability detection, JSON Threat Protection, monitoring, statistics logging, and a bunch of other things I mentioned in previous blog articles).

For Auditiability, sufficient information should be recorded in any system where authentication and authorization is used to retrace the steps of actions any user took. Those logs should be retained per a pre-defined Information Security data retention policy that applies across the organization — this is very likely a function of the Data Classification Standards in play.

For Identity Propagation between the Mobile App and the API endpoint, JWT tokens are used to transmit the authenticated identity with each API Request.

So, that is our basic API Security Model for this situation. Is that sufficient? It’s a good start. You can’t really know whether it is sufficient until after going through the full-cycle of:

Development
Unit Testing
QA Testing
Load Testing
Penetration Testing
User Acceptance Testing

And, nothing is quite as effective as real world use — be careful with that. Some readers are probably rolling their eyes at all those layers of testing. Organizations that are fanatical about testing process and methodology are far less likely to be caught be surprise.

Now, is this API Security Model too much security? Let’s assume it’s your personal information and your car that gets stuck in the middle of nowhere because of an API security vulnerability. Still too much security? Didn’t think so. There are situations where an overbearing or over-engineered Application Security Model is causing more harm than good. Likewise, a poorly managed Security Model and Identity Stack will be extremely difficult to work with — whether it is a good Security Model or not. But, I believe what has been described here will become the minimum, acceptable level of security for APIs as we move forward when anything beyond public data is in play. With a little forethought and planning, it can be done by organizations of any size.

I have an image in my mind of a developer at one of my clients who for years has not been able to get past the same basic question: why do we need security (in particular, API Security)? They stopped inviting him to meetings on the topic.

Now, who owns API Security? Who owns Application Security? Ideally, the answer to the two would be the same. This one can vary dramatically between organizations. It may be centralized; it may be distributed across all the development teams. I very much prefer the centralized model; this makes implementing advanced application security concepts in a distributed computing environment (pretty much everything we are talking about) orders of magnitude easier. But, this requires a very well run Identity and Access Management group. That can be a challenge for organizations of any size, especially with a large user population or a small Identity team. API Security ties together:

User provisioning
User repositories (and different populations of users)
Authentication mechanisms
Authorization policy authoring
Run-time enforcement of authentication and authorization
API interface definitions
How the various stages of testing work
API management, governance, and life-cycle management
Identity propagation

Responsibilities for these spans the Identity team, Information Security, Development Teams, API Gateway support team, and the group responsible for API Management & API standards. The API Security model should be owned by a group (an Application Security Center of Excellence or similar organizational construct) composed of representatives from each of these groups.

Please provide comments.