August 27th, 2014

Why Banks Have the Same “Drivers” as Uber with APIs

Image credit: Adam FagenI’ve heard many banking IT staff declare definitively “we’re not exposing an API to the public.” I get it. It’s scary to create yet another point of entry, a potential vulnerability to the organization. Better to just lock it up tight. Throw away the key. In fact, to maximize security, we should probably just turn off all the computers.

Not really.

Do it or be Disrupted
There was a bit of consternation over Uber’s latest valuation. There’s a simple explanation for the high valuation. It’s not about the market for taxi rides. It’s about the platform:

  • “It’s interesting to think of Uber as the new Amazon. Amazon is a platform company, not a books company (and arguably not a retailer).” – Benedict Evans on Twitter

Uber Everywhere
Last week, Uber launched its API. I was surprised at how obvious it sounded but more surprised when a number of apps on my phone updated to add Uber reservation functionality. It was a very nice launch. Uber is now where I am: If I’m flying United, there’s Uber. If I’m making a reservation at OpenTable, there’s Uber.

The Power of an API
That’s an API impacting channel distribution. That’s also an API impacting brand power, demonstrating the real power of the application economy. Uber isn’t waiting for the customer to remember to open the Uber app; it’s in the app the customer is using at the moment they need Uber’s service. It’s beautiful.

Getting Banks to Think Like Software Companies
The key thing to remember is that someone will figure it out in financial services. If the banks don’t figure out how to create a financial services platform, someone else will. The banks realize they’re competing with Silicon Valley and believe they’re ready. Perhaps they are, from a technical-chops perspective. But from a perspective perspective, banks are not yet thinking like software companies.

The Business Case for Exposing a Loyalty Point API
Banks have the same drivers Uber does. (Hah! Going to leave that pun there.) The API is just a technology – just an interface implementation for integration. Banks are already doing external integration. My favorite example is the ability to pay with Chase Rewards points while shopping at Amazon.

It’s so easy to imagine Benedict Evans’ quote above tweaked to explain my point:

  • “It’s interesting to think of Chase as the new Amazon. Chase is a platform company, not a bank (and arguably not a financial services company).”

I can pay for my Amazon purchase with Chase rewards points. This has a clear business benefit, if I can be so crass as to summarize it simply:

  • More opportunities to pay with points are more opportunities to take the points off the balance sheet
  • The more points can be used, the more valuable they become and the more people care about the benefit
  • If an API is done properly it becomes much easier to use than the current architecture for external integration, which means the ROI for enabling smaller players becomes achievable thereby creating a virtuous cycle of more points off the books, more value to the points, more customers who care about the program
  • And with broad and visible distribution, there’s a Big Data play for analyzing shopper value and tweaking the point-dollar relationship to reduce the reward program’s costs

Why have they limited this to Amazon? (Rhetorical question. I imagine it’s because the non-API integration strategy takes a lot of effort and so doesn’t scale unless it’s with someone big like Amazon. Though I don’t know for certain.) Imagine if everywhere you could book an Uber, you could also pay with Chase Rewards points?

Interested in learning more about how financial services organizations can differentiate, extend reach and establish trust using APIs and mobile technology? Join me on September 25 for the webinar Adapting to Digital Change: Use APIs to Delight Customers & Win.

Sign up for the webinar >>

April 25th, 2014

The Importance of Context to Mobility

Written by
 

Mobile ContextMy grandfather has a bumper sticker on his pickup truck that says “He who dies with the most toys, wins.” Since my world revolves more around API Management than collecting die-cast models of John Deere tractors, I have my own version of the saying – “He who has the most context wins.” Context has always been an important part of managing data or applications, but the proliferation of enterprise B2E (business-to-employee) and B2C (business-to-consumer) mobile apps has significantly increased the need for context-based policy.

The Layer 7 family of API Gateways has always been good at context. Not only does a Gateway have access to the full request and response content, it can also access header content (from a wide variety of protocols) and transaction metadata (latency, source information etc.) Then it adds in user credentials and attributes retrieved from the request and backend identity management systems. These inform decisions around access control but also around traffic routing, prioritization, rate limiting, quota fulfillment etc.

However, mobility introduces a few new entities to the equation, all of which have to be taken into account for ideal contextual decision-making. The first is familiar: users; but mobile users might have additional attributes that come into play. Phone number and email become more important, since they provide other connection points accessible to the user on the same device (smartphone, tablet etc.) The inclusion of social login – available in the 2.1 release of our Mobile Access Gateway – provides social graph information that might also have relevance when deciding how a user request should be processed.

The second entity providing contextual attributes is the app itself. An app ID or API key can tie an application back to the developer who created it. Signer information, permissions and other internal details can give context around existing app security. The Mobile Access Gateway can collect some of this information using our Mobile SDK and more data can be gathered via integration with CA (or third-party) MAM and MDM products.

The third important entity is the device itself. Not only can APIs be tailored to return data structures specific to a screen size or even a specific device type but behavior can also be tracked to a single device ID to analyze the risk involved. There might be more risk delivering sensitive data to a family iPad than there would be on a personal smartphone – or to a phone in an airport rather than a laptop in the office. This level of risk (and the associated response) increases dramatically when interacting with an unlocked device rather than one locked down by corporate security policies.

In my new role across the CA Securecenter product line, I’ve focused quite a bit on the integration of Layer 7 with other CA products. The result has been a flood of new contextual information with which to make richer decisions. Gathering risk profiles from CA RiskMinder or data categorization from CA DataMinder provides an even stronger understanding of who is trying to access what, from where. And the decision made from this context doesn’t necessarily have to result in a thumbs-up or thumbs-down; with CA AuthMinder, suspicious requests can simply require an additional level of authentication.

Every industry has its own variables, vulnerabilities and potential optimizations. Our goal is to give customers the right context with which to make the best decisions for their specific use cases. Our rich interface management capabilities and strong integrations with other proprietary and standards-based mobile technologies give us the best palette of access control and policy options in the API Management industry. In a world where context is king, we’re continually fighting for that crown.

February 21st, 2014

Why an Open API is Like a Loaded Gun

APII recently participated in another of the excellent TechViews tweetchats, hosted by my friends from CA Technologies using the handle @TrendsInTech, on the topic, ‘The Risks & Rewards of API Development’. It was a great chat and you can check the full chat summary at Storify.

Among other things, I was at one point inspired to tweet that “an open API is a bit like a loaded gun: Harmless ‘per se,’ but lethal in the wrong hands.” Soon after, I received an email from someone reading the chat, asking for clarification, so I thought I would jot down my thoughts here.

My intent was to say that that, like a loaded gun, an open API is not necessarily bad per se but it certainly can be very dangerous if not handled correctly. It depends on what it does, who uses it, how they use it, what they intend to do and what they actually do (even accidentally). An open API with wide-open access, no throttling, no identity controls etc. is fine if it is used as intended. However, if it is used by a malicious actor, with malicious intent, and/or for a malicious outcome, then it can be very dangerous indeed.

One example of what can happen when an API is not protected, controlled and monitored happened recently with the Snapchat API.

Snapchat had an accessible (though not openly published) API that allowed any mobile Snapchat app user to provide a cellphone number and get back Snapchat profile details of the user with that phone number. This was designed to help users find their friends – innocuous enough on the surface, though clearly not informed by historical breaches caused by the same functionality.

As designed, this API was intended to accept a small number of cellphone numbers in each call, to return just a handful of known profiles. However, it was not well secured or properly throttled, leading to some dangerous unintended consequences. A small group of Australian security researchers known as Gibson Security figured out they could use the API programmatically to hammer the Snapchat servers with tens of thousands of phone numbers per request – some valid, many not. Pumping up to 75,000 requests into the API at a time ultimately resulted in Snapchat divulging profile details to 4.6 million users.

In this respect, the Snapchat API was like a loaded gun just lying around. Only authorized users were meant to have access to it but there were no safeguards to make sure of this. Like a loaded gun, the API was harmless as long as the trained and registered owner (i.e. the Snapchat app) used it as intended. Yet it was still just lying around where anyone could get to it and when an unauthorized user eventually did access it, with intent to use it maliciously, there was no protection at all.

It wasn’t that the API was inherently malicious. Like a gun, it could be used for good or bad purposes but like a gun, handled by a malicious actor without protections, it became a harmful weapon.

From a customer perspective, this is unacceptable. Witness the outrage from the Snapchat user community when this was discovered (although you could be forgiven for thinking it really didn’t matter in the end). From a governance, audit, security and compliance perspective, no business should ever consider opening up their APIs to any users — internal or external — without adequate controls, such as identity and access management, threat protection, error detection, usage tracking and rate limiting.

It is not just Murphy who knew that anything that can go wrong will go wrong; security analysts live and breathe this every day. You cannot assume an open API will not be abused; indeed, you must assume the very opposite. Even if you don’t publish details for an open API, you cannot assume no-one will find it; there is no such thing as security through obscurity.

API protection is as important to your systems and data as a safety, a holster, a trigger lock or a gun safe is to a loaded weapon. Fortunately, CA Technologies has invested in solutions that can help resolve these issues. The CA Layer 7 API Security & Management Suite “provides enterprises with a comprehensive set of solutions that externalize APIs in a secure, reliable and manageable way.”

So, next time you are working on an open API, make sure you drop by CA.com first. After all, you wouldn’t want to be the programmer that left a loaded gun around, would you?

[This post first appeared on the CA Security Management blog ]

February 19th, 2014

New eBook: 5 Simple Strategies for Securing Your APIs

5 Simple Strategies for Securing APIsRecently, I wrote about the excitement I feel working within CA. This company is full of talented people and when you draw on their capabilities, amazing stuff happens. Here in R&D, we have some innovative solutions underway that are tangible results of CA and Layer 7 working well together. I can’t reveal these yet but you can see the same 1+1=3 equation at work in other groups throughout the organization.

Here is a good example: It’s an eBook we’ve assembled to help managers and developers build more secure APIs. The material started with a presentation I first delivered at a recent RSA show. We updated this with best practices developed by real customers facing real challenges. The content is solid but what I love is the final product. It’s accessible, easy to digest and the layout is fantastic. Half the battle is delivering the message so that it’s clear, approachable and actionable. This is just what we delivered. And best of all, it’s free.

The last year has been a difficult one in security. The Snowden affair made people talk about security; this, at least, is good and the dialog continues today. But if 2013 was a year of difficult revelation, 2014 is going to be about back-to-basics security.

APIs offer tremendous business value to enterprise computing. But they also represent a potential threat. You can manage this risk with a solid foundation and good basic practices but you need to know where to start. This is the theme of our new eBook. It offers simple guidelines, not tied to any particular technology. You should apply these whenever you deploy APIs.

I hope you find this eBook useful. As always, I’d love to hear your feedback.

Download the eBook: 5 Simple Strategies for Securing Your APIs

February 14th, 2014

The Truth About CA & Layer 7

CA Layer 7Has it really been almost a year since my last post? I suspected I was near that milestone but it’s still surprising to discover it has been so long.

The story of the last year, of course, is the acquisition of Layer 7 by CA Technologies. Today being Valentine’s Day, I’m reminded that acquisitions are very much like relationships and I’ve been completely consumed with making this one a success. So, the last year is a blur of integration, customer outreach and some terrific innovations — but not a lot of writing.

Hopefully, now that the smoke has at least partly cleared, I’ll get back to blogging regularly and maybe even writing some lengthier pieces of content.

For now though, let’s get back to talking about the acquisition because I know people are curious. The number one question I get asked is how am I doing at a large company and — more specifically — how is CA? It is a logical question but one always delivered with a slightly raised eyebrow that really implies “just give me the dirt — the juicer the better”.

I respond with the truth. And the truth, to be honest, is quite a bit less salacious than everyone secretly hopes. At CA and Layer 7, we are steering clear of  the all-too-common pitfalls of start-up/enterprise marriages. We seem to be finding a very effective approach that works nicely for everyone.

Like all good relationships, this one is founded on a base of mutual respect and a healthy dose of trust. CA recognizes that the Layer 7 team in Vancouver is a great engine of innovation. So, the team stays together and has the mandate to continue pushing the envelope around APIs and mobility. We all recognize that we are part of a much larger narrative now, but honestly, this is what excites us most of all.

CA is a large company but it isn’t overwhelming. Indeed, I’ve been struck by what a small big company this actually is. In just seven months, I feel as though I’ve got a good handle on who all of the key players are and I can pretty much engage anyone I need to and be taken seriously. It’s a level of engagement I never dreamed of.

So, while the truth is boring and my anecdotes are not sexy, that’s all a very good thing. Actually, it’s a great thing. The numbers are high, opportunity abounds and there is a sense we can affect real change when change makes sense. This is a good place to be and I can promise you that there are very good things to come. Stay tuned.