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.

July 17th, 2013

Secure APIs: The Road to Business Growth

CA Technologies Mobile SolutionsBusinesses today are under intense pressure to reach new customers, collaborate with new partners and build new mobile apps that transform business processes.

If you’re a bank, you might want to sign customers up using a tablet on the street corner. If you’re servicing cell phone towers, you might want a technician’s tablet or cell phone to know his location, open the right support ticket and send him the proper documentation for that work site. If you’re selling to end customers, you want to give them exactly the information they need, when they need it, on whatever device they choose, when they’re ready to buy.

But when the business comes to IT for such applications, we often tell them “no” – or, at least, “not now.” One reason is that IT is short on developers. But IT’s hesitance also stems from an appropriate concern with issues like access control or the possibility that backend systems might crash under the load from mobile applications or the cost of converting data for these new services and devices. As we learned from connecting our backend systems to the Web, adding a new platform can mean a profound change in how these systems are used – instead of checking a flight once when the travel agent makes a reservation, people now check on-flight information dozens of times as they search for the best flight on the Web or check their mobile phones to see whether Grandma’s flight has arrived yet.

IT can help meet these needs if we realize the business is not asking for a series of huge new standalone apps. What it’s asking for is the ability to experiment, to try a lot of new ideas quickly and at low enough risk and cost that even if some ideas fail, that’s still okay – as long as one or two succeed in a big way. As Linus Pauling put it, “If you want to have good ideas you must have many ideas. Most of them will be wrong and what you have to learn is which ones to throw away.”

Such experimentation is often impossible in-house and not just because of a lack of the skills. The hand-coding process used in most organizations today forces them to build the same app multiple times, once for the browser, once for mobile, once for Google Glass or whatever the next platform is. That not only delays deployment, it also increases cost and risk so much that experimentation in the business is not possible.

But secure APIs can make that experimentation possible. Here’s how.

Secure APIs provide a single gateway for developers from smaller companies that are in your organization’s “ecosystem” to access and monetize the backend systems, databases and information that are your core assets. If you can support outside developers in creating great apps for you, you avoid grinding out that code yourself. That makes you much more agile and reduces your cost and delivery times. It also lets you tap outside developers if you need help in a new or emerging area, such as a Google Glasses app or Big Data or for a short-lived app like one that works with a Super Bowl promotion.

In addition, outside developers might see ways to monetize your internal systems that you cannot. They might come up with, say, a social banking app that builds brand loyalty by using a customer’s social group to encourage her to contribute to a retirement account. They might develop a branded pedometer app for a health plan to track a member’s exercise routine. This is no different than when Twitter or any other social media platform lets third-party developers connect to their information systems, delivering revenue in ways the business might never have imagined.

Organizations taking advantage of this market opportunity are building on a platform that allows them to abstract security and data transformation tasks into a technology layer purpose built to enable this innovation. Think of this as a mobility Gateway that streamlines development and reduces risk by eliminating the need to write everything from security to access control, caching and load management for every application. If those functions are delivered from the Gateway, developers can focus on quick revisions of the front-end application to go after those potential big market wins.

At CA Technologies, we are now providing such a secure Gateway, following our acquisition of Layer 7. The Layer 7 technology provides a secure Gateway that sits in front of your backend systems, exposing them via simple and secure APIs. It provides everything from identity verification to caching through a single security and IT optimization layer, giving developers – and the business – the freedom to experiment and innovate.

The way to build out your APIs is to start slowly using budget from individual projects but keeping the long-term architecture in mind. Don’t try selling it to the business in terms of APIs, caching and security layers. Instead, tell it how you’re giving it the ability to rapidly and securely experiment with new business models at low cost. Talk about how you’re letting it roll out a new mobile application more quickly or giving an outside developer the tools to find a new route to market for you.

We’re seeing that customers who build APIs, not applications, are leveraging the creativity of a world of clever developers. What challenges and rewards have you found on your API journey?