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 >>

June 27th, 2014

Drones, Phones & Pwns:
The Promise (& Dangers) of IoT APIs

DroneEarlier this month, CA Layer 7 participated in yet another great conference – this time, it was QCon New York. As a three-time QCon attendee, I have always really appreciated the level of technical knowledge displayed by attendees. At this show, it’s rare that I have to explain the basics of APIs; most attendees are already using APIs in some form or another. And even though many of them are very hands-on developers, they are savvy enough to realize when it is and isn’t appropriate to “build it yourself.”

Many of my conversations began with, “We’re exposing APIs but we don’t have a good way to manage our developer community.” Even more interesting were the ones which began, “We built our own API Management layer but it doesn’t…” There was a wide array of endings to that sentence, including “scale well,” “provide any real security” and “help our developers build applications quickly.” Security was an especially common theme as these folks are smart enough to realize they are not primarily experts at implementing OAuth-based access control or protecting APIs against structural or content-based threats. They’d rather let Layer 7 worry about the implementation and simply configure which options are relevant to their applications. And, of course, many examples of app hacks, data breaches and identity theft are in the news these days; nobody wants their company to be the next victim.

Aside from being a common theme in discussions at the show, maintaining security and privacy in an increasingly interconnected world was the theme of my talk, titled Drones, Phones & Pwns: The Promise (& Dangers) of IoT & APIs. In the first half, I discussed the recent transition of drones from military/intelligence use cases to commercial/personal use and talked about some of the cool technologies already being enabled by these and other data-gathering “things”, such as our phones. I used personal examples to show how my life and the lives of many others are made more pleasant and efficient by this connectivity and data aggregation. After delving into the broad range of use cases made possible by the Internet of Things, it was time to take a look at the other side of the coin.

The second half of my presentation was about the darker side of all the personal data flowing around the Internet and the leaking/sharing/exposure that happens with or without our awareness. I tried not to mention obscure exploits that are unlikely to ever be used; instead, I used real-world examples of glaring privacy holes in devices and apps that we use every day. Rather than simply fear mongering, I tried to make a point about the trust that people – myself included – place in the companies and entities around them. And I followed up those bits with some advice about what we can do to make our future a little less frightening.

The reaction to my presentation was pretty surprising. Even amongst a very technical audience, I still had people approaching me all day afterward, explaining that I had scared them so much they weren’t ever going to look at their phone/car/gaming console/app the same way again. For those that were already familiar with some of the examples I had given, it provided a great conversation starter about security and what sort of cultural shifts will be required to alleviate some of the more pervasive issues.

These are the types of conversations we like to have with our customers – realistic assessments of the risks and challenges encountered by enterprises opening their data and applications to customers, partners and employees, followed by specific discussion of solutions. Considering the interest our customers are showing in these discussions, we’ve decided to do an encore presentation of my conference talk for a larger audience. I’m excited to announce the Layer 7 webinar Drones, Phones & Pwns: The Promise (& Dangers) of IoT & APIs will be held on July 23 at 9am Pacific Time. Registration is now open.

Sign up for the webinar >>

February 19th, 2014

End-to-End Mobile Security for Your Consumer Apps

Mobile Security WebinarAccording to Harvard Business Review, 82% of the average user’s mobile minutes are spent using apps, compared to just 18% with Web browsers. Increasingly, the mobile app is replacing the Web site as the primary channel through which consumers get information on or interact with products and services. Consequently, apps have become central to strategic initiatives focused on achieving marketplace differentiation and driving business growth.

For example, look at the way Nike is using an app to drive consumer engagement from the ground up. Runners can use the Nike+ app and device to monitor their performance, collaborate and share information. This is not Nike’s typical elite marketing model, centered on high-profile sports figures but the company attributed 30% of its 2012 running division growth to this app-based approach.

However, adopting an app-based strategy comes with risks. Consumers are using mobile apps to access banking records, healthcare benefit plans and retail accounts. This creates security risks for companies because it requires them to expose backend systems and data via APIs. It also means that consumers’ sensitive information is being placed at risk of compromise.

Businesses have recognized the opportunity at hand, have made mobility a top priority but in the meantime have put security in an awkward position. Information must be exposed and shared in a much more “open” architecture in order to take full advantage of mobile app opportunities. Security must now adapt, focusing on how to protect and reduce the risk in the context of this new open architecture.

What are the options for mobile app security? Solutions exist in a range of categories, including mobile device management (MDM), mobile application management (MAM), containerization, wrapping and more. Generally, these solutions enable a level of control over the device that is not appropriate in consumer scenarios. In fact, many organizations are finding that this level of control is often too restrictive and impinges excessively on user privacy when trying to secure enterprise data on employees’ devices.

What’s the alternative? As previously mentioned, most enterprises’ consumer-facing apps expose valuable backed systems via APIs. Using an API security solution to protect these backend interfaces and the sensitive consumer data they expose is therefore a vital part of the process. It is also vital to control access to the apps that leverage the exposed systems and data. Through the implementation of OAuth and OpenID Connect, organizations can apply risk-based access control to mobile apps. Not only is access controlled to the app but app access to the backend API is also controlled, delivering a complete end-to-end mobile app security solution.

Overall, an acceptable mobile app security solution for consumers should contain a variety of flexible features, including multi-channel authentication, mobile social login, two-factor authentication, geolocation access control, mutual SSL, fine-grained API access control and threat protection against SQL injection, cross-site scripting and DDoS attacks – features that provide an acceptable level of control while maintaining the convenience of the device and preserving the privacy of the user.

To hear more about this, please join tomorrow’s CA Layer 7 webinar as Leif Bildoy and myself walk through the 5 Steps for End-to-End Mobile App Security with Consumer Apps.

October 16th, 2013

Intelligent APIs for Big Data & IoT

Written by
 

Big Data Webinar“Data is the new oil” is an oft-repeated phrase. But when was the last time you went out and bought a barrel of crude oil?  The value to consumers is in the refined product: gasoline. With data, the refined product is information – the distilled and actionable essence of multiple sources of raw data.  So, if “data is the new oil” then “information is the new gasoline”.

There’s a lot of data out there and IoT is going to increase it greatly. For large organizations, refining Big Data stores is a significant challenge. This is partly because data doesn’t start out big but gets collected from lots of relatively small sources. Also, data seldom arrives in the right format for sharing and monetization. Furthermore, responsibility for securing and managing data is not always in the same hands as responsibility for sharing data.

We have explored some of these issues in recent blog posts like Was is DaaS? and How APIs Grease the Data Wheels. In tomorrow’s webinar, Intelligent APIs for Big Data & IoT, Matt McLarty and I will try to bring it all together and talk about how APIs are becoming the pipelines and tankers that move the gasoline from its source to the user.

September 17th, 2013

Mobile SSO: Give App Users a Break from Typing Passwords

Written by
 

Mobile SSOJust a reminder – on Thursday, I’ll be presenting a webinar alongside Tyson Whitten, Director of Solutions Marketing at CA Technologies. We will be talking about CA/Layer 7’s new Mobile Access Gateway 2.0 release and how it addresses two important questions associated with enterprise-level mobile app development, including business-to-consumer apps and internal/BYOD apps:

  • How do you establish security for mobile apps that consume backend APIs?
  • How can you create a Single Sign-On (SSO) session for multiple apps?

Tyson and I will also be discussing how you can use the Mobile Access Gateway to manage the relationships between users, apps and devices by leveraging standards like OpenID Connect, OAuth and PKI. The Gateway makes it possible to maintain mappings between the different token artifacts so that IT security can set fine-grained access policies for securing the backend APIs the apps use.

Mobile Relationships

If you have already deployed CA SiteMinder or a mobile device management (MDM) solution, you should consider deploying the Mobile Access Gateway to get your infrastructure ready for the app revolution.

If you haven’t already signed up to webinar, you can do it here: