June 9th, 2014

Jailbreak Your APIs

Jailbreak Your APIsAt this week’s Computers, Freedom & Privacy Conference, I gave a presentation titled Jailbreak Your APIs, in which I explored the concept of “linked APIs” and explained the potential these interfaces have for helping us create a freer, more open world. The global informational overload that we are constantly exposed to, can be overwhelming but ideas like linked APIs help us remember that the explosive surge of available data also brings us beautiful things such as transparency, openness and an unprecedented feeling of global connectedness.

We’ve never felt more connected to the rest of the world than we do now. Computers, mobile devices and the Internet have brought us closer than ever before. We now take it for granted that a person can be pretty much anywhere in the world and still get a real-time, front-row view of breaking news from half-way around the globe. While this disappearance of informational boundaries has surfaced many of our most polarizing differences, we still cherish our unprecedented ability to access information because access to information has always been our most powerful weapon for defending our rights and liberties.

In this context, the White House’s Open Data Policy (part of the Open Government Initiative) is particularly exciting. Never before has the American public had so much access to government information, at all levels. And all this happens directly through the Internet, in near real-time. The ability to access this information in a timely manner is crucial – we need access to information right when it is immediately relevant to guaranteeing our freedoms. This relates to my work with CA Layer 7’s API Academy because APIs supply the core technology for facilitating timely access to data.

Recent growth in the prominence of APIs is not simply a reaction to Open Government and Open Data. The API has organically become more important in recent years, due to our increasingly mobile lifestyles. APIs are vital to mobility because they connect our mobile devices to the cloud – specifically, to the datacenters that host the information and functionality that powers our apps. APIs have played an undeniably critical role in the mobile revolution of recent years. However, for APIs to play a similar role in the Open Data revolution, we need them to become much better.

The problem with APIs right now is that most of them are, at best, creating narrow windows into solid walls surrounding siloed data. Even the biggest, most well-known APIs (such as those provided by Twitter, Facebook and Google) to a large extent, only operate on the data that is within these organizations’ own databases. And most Government APIs don’t even allow any “write” functionality – they are strictly read-only.

In that sense, most current APIs create isolated, guarded data islands. This is very “anti-Web” — the World Wide Web was created in the spirit of decentralized equal participation. On the Web, everybody publishes everywhere, owns their data and then we have ways to reach that data through hyperlinks, through Google search and other methods. APIs have not really reached that stage of maturity yet. APIs are highly centralized, in terms of data storage and virtually none of them ever link to other APIs.

We need a new breed of interfaces: linked APIs, based on the same hypermedia design that we have on the rest of the Web. Such APIs will have the biggest impact for Open Data because they will link and make connections across datasets and organizational boundaries. Linked APIs are also very scalable, so they will be best suited to meeting the challenges of Big Data. After all, the Web is the largest, most distributed network of information humankind has ever created. We know the architecture of the Web can scale and linked APIs have the exact same architecture, with hypermedia as the engine.

For freedom of data, we really need more linked APIs. We can only truly have open and free data if we jailbreak the information out of the silos it is currently stashed-away in. Linked APIs provide us with keys to the data fortresses where large aggregators currently keep data. Linked APIs can ensure that our data isn’t stashed in centralized warehouses. Linked APIs represent the engine of data freedom on the Web. Let’s get the engine cranking!

January 3rd, 2014

Snapchat Snafu!

Snapchat Logo

When the folks at Snapchat recently turned down an acquisition offer of three billion dollars, I have to admit I was shocked by their incredibly high estimation of their own importance. After all, half of their “secret sauce” is an easily-reproducible photo sharing app; the other half is the fact that their users’ parents haven’t discovered it yet. I’ll admit a bit of jealousy and the fact that my age starting with “3” makes me demographically incapable of understanding the app’s appeal. However, what I do understand is that a frightening disregard for API security might have jeopardized the entire company’s value. Loss of user trust is a fate worse than being co-opted by grandparents sharing cat pictures.

While Snapchat does not expose its API publicly, this API can easily be reverse engineered, documented and exploited. Such exploits were recently published by three students at Gibson Security and used by at least one hacker organization that collected the usernames and phone numbers of 4.6 million Snapchat users. Worse, the company has been aware of these weaknesses since August and has taken only cursory measures to curtail malicious activity.

Before we talk about what went wrong, let me first state that the actual security employed by Snapchat could be worse. Some basic security requirements have clearly been considered and simple measures such as SSL, token hashing and elementary encryption have been used to protect against the laziest of hackers. However, this security posture is incomplete at best and irresponsible at worst because it provides a veneer of safety while still exposing user data to major breaches.

There are a few obvious problems with the security on Snapchat’s API. Its “find friends” operation allows unlimited bulk calls tying phone numbers to account information; when combined with a simple number sequencer, every possible phone number can be looked up and compromised. Snapchat’s account registration can also be called in bulk, presenting the opportunity for user fraud, spam etc. And finally, the encryption that Snapchat uses for the most personal information it processes – your pictures – is weak enough to be called obfuscation rather than true encryption, especially since its shared secret key was hard-coded as a simple string constant in the app itself.

These vulnerabilities could be minimized or eliminated with some incredibly basic API Management functionality: rate limiting, better encryption, more dynamic hashing mechanisms etc. However, APIs are always going to be a potential attack vector and you can’t just focus on weaknesses discovered and reported by white hat hackers. No security – especially reactive (instead of proactive) security – is foolproof but your customer’s personal data should be sacrosanct. You need the ability to protect this personally-identifiable information, to detect when someone is trying to access or “exfiltrate” that data and to enable developers to write standards-based application code in order to implement the required security without undermining it at the same time. You need a comprehensive end-to-end solution that can protect both the edge and the data itself – and which has the intelligence to guard against unanticipated misuse.

While our enterprise customers often look to the startup world for lessons on what to do around developer experience and dynamic development, these environments sometimes also provide lessons in what not to do when it comes to security. The exploits in question happened to divulge only user telephone and username data but large-scale breaches of Snapchat images might not be far behind. When talking about an API exposed by an enterprise or governmental agency, the affected data might be detailed financial information, personal health records or classified intelligence information. The potential loss of Snapchat’s $3 billion payday is serious to its founders but lax enterprise API security could be worse for everyone else.

CA’s line of API security products – centered around the Layer 7 API Management & Security Suite for runtime enforcement of identity management, data protection, threat prevention and access control policies – can help you confidently expose enterprise-class APIs to enable your business while preventing the type of breach experienced by Snapchat, among others.

October 31st, 2013

Security in the Frenetic Age

Written by
 

I AcceptHappy Halloween everyone!

There has been a lot of talk about data leaks and data privacy lately, not naming any names. The articles and blog entries on this topic are filled with outrage and spoken with dropped jaws. I have to admit that the only shock I experience on this subject is at how shocked people are. As divisive as these issues are, fundamental questions remain. How much privacy should be expected? How many times a week are you prompted to accept a long block of terms and conditions in order to access online services? How many times do you read them? Isn’t that the scary part?

The mobile revolution has brought us into the Frenetic Age. Hear two bars of a song you like? Buy it on iTunes. Order a tasty looking burrito? Instagram it.  Overcome by wit?  Facebook, Twitter, Tumblr…  Digitizing our social lives — and our lives in general — leaves a trail of data.  Eric Schmidt claims that we now create as much information every two days as we did up until 2003. “If you aren’t paying for the product, you are the product” goes the current mantra.  Should we accept this as easily as we accept those terms and conditions?

In this frenetic age, how can we protect our privacy? I believe data protection and access control will become increasingly vital topics for all of us. Being a responsible company that protects its consumers’ privacy will become a competitive advantage.  Providing safe harbour for third-party data will provide similar opportunities for companies in the next decade, as collecting private data did for social networks in the last decade. At Layer 7, we feel that our Data Lens solution offers a good starting point for companies who want to expose their data, their partners’ data and their customers’ data in an acceptable way.

January 3rd, 2013

CES 2013 Panel: Privacy & Security in the Cloud

CES 2013The Consumer Electronics Show (CES) 2013 is starting in Las Vegas next week and cloud computing is on the agenda. You can be sure that a technology has moved out of the hype cycle and into everyday use when it shows up at a show like CES, known more for the latest TVs and phones than computing infrastructure. People don’t really need to talk about cloud any more; it’s just there and we are using it.

Of course there will always be a place for a little more talking and I’ll be doing some of this myself as part of the CES panel Privacy & Security in the Cloud. This discussion will take place on Monday Jan 7, 11am-12pm, in LVCC, North Hall N259. The panel is chaired by my good friend Jeremy Geelan, founder of Cloud Computing Expo, who honed his considerable moderation skills at the BBC.

I’m planning on exploring the intersection between the cloud and our increasingly ubiquitous consumer devices. We will highlight the opportunities created by this technological convergence but we will also consider the implications this has for our personal privacy. I hope you can join us.

December 19th, 2012

Do You Agree to the Terms & Conditions? Mobile Devices & the Tipping Point of Informed Consent

Written by
 

End-User License AgreementSometimes, I wonder if anyone in the entire history of computing has every bothered to read and consider the contents of a typical end-user license agreement (EULA). Some Product Manager, I suppose (though truthfully, I’m not even sure of this one).

The EULA, however, is important. It’s the foundation of an vital consent ceremony that ends with only one effective choice: pressing OK. This much-maligned step in every software installation is the only real binding between an end user and a provider of software. Out of this agreement emerges a contract between these two parties and it is this contact that serves as a legal framework for interpretation should any issues arise in the relationship.

Therein lies the rub, as the emphasis in a EULA — as in so much of contract law — is on legal formalism at the expense of end-user understanding. These priorities are not necessarily mutually exclusive but as any lawyer will tell you, it’s a lot more work to make them coexist on a more-or-less equal footing.

Mobile devices may provide the forcing function that brings change into this otherwise moribund corner of the software industry. Mobility is hot right now and it is demanding that we rethink a wide span of business processes and technologies. These new demands are going to extend to the traditional EULA and the result could be good for everyone.

Case in point: the New York Times reported recently on a study conducted by the FTC examining privacy in mobile apps for children. The researchers found that parents were not being adequately informed about what private information was being collected and the extent to which it could be shared. Furthermore, many mobile app developers are channeling data into just a few commercial analytics vendors. While this may not sound like too big a deal, it turns out that, in some cases, these data are tagged with unique device identifiers. This means that providers can potentially track behavior across multiple apps, giving them unprecedented visibility into the online habits of our children.

Kid plus privacy equals a lightning rod for controversy but the study is really indicative of a much greater problem in the mobile app industry. Just the previous week, the State of California launched a suit against Delta Airlines alleging the company failed to include a privacy policy in its mobile app, placing it in violation of that state’s 2004 privacy law.

You could argue that there is nothing new about this problem. Desktop applications have the same capacity for collecting information and so pose similar threats to our privacy. The difference is mostly the devil we know. After years of reading about the appalling threats to our privacy on the Internet, we have come to expect these shenanigans and approach the conventional Web guarded and wary. Or we don’t care (see Facebook).

But the phone, well the phone is just… different.  Desktop computers — or even laptops — just aren’t as ever-present as phones. Your phone goes with you everywhere, which makes it both a triumph of technology and a tremendous potential threat to your privacy.

The problem with the phone is that it is the consumer device that isn’t. Apple crossed a chasm with the iPhone, taking the mobile device from constrained (like a blender) to extensible (like a Lego set) without breaking the consumer-orientation of the device. This was a real tour de force — but one with repercussions both good and bad.

The good stuff we live every day — we get to carefully curate our apps to make the phone our own. I can’t imagine traveling without my phone in my pocket. The bad part is we haven’t necessarily recognized the privacy implications of our own actions. Nobody expects to be betrayed by their constant companion but it is this constant companion that poses the greatest threat to our security.

The good news is that the very characteristics that make mobile so popular also promise to bring much needed transparency to the user/app/provider relationship. Consumer-orientation plus small form factor equals a revolution in privacy and security.

Mobile devices tap into a market so vast it dwarfs the one addressed by the humble PC. And this is the market for which consumer protection laws were designed. As we’ve seen in the Delta Airlines case above, the states have a lever and apparently they aren’t afraid to use it.

But legislation is only part of the answer to reconciling the dueling priorities of privacy and consent. The other element working in favour of change is size — and small is definitely better here. The multi-page contract just isn’t going to play well on a four-inch screen. What consumer’s need is a message that is simple, clear and understandable. Fortunately, we can look to the Web for inspiration on how to do this right.

One of the reasons I get excited about the rise of OAuth is because it represents much more than yet another security token (God knows we have enough of those already). OAuth is really about granting consent. It doesn’t try to say anything about the nature of that consent but it does put in the framework to make consent practical.

Coincident with the rise of OAuth on the Web is a movement to make the terms of consent more transparent. This will need to continue as the process moves to the restricted form factor of the mobile phone. I have no doubt that, left to their own devices, most developers would take the easy route and reduce mobile consent to a hyperlink pointing to pages of boilerplate legalese and an OK button. But add in some regulatory expectations of reasonable disclosure and I can see a better future of clear and simple agreements that flourish first on mobile devices but extend to all software.

Here at Layer 7, we are deeply interested in technologies like OAuth and the role these play in a changing the computing landscape. We are also spending lots of time working on mobile because, more than anything, mobile solutions are driving uptake around APIs. When we built our SecureSpan Mobile Access Gateway, we made sure this solution made OAuth simple to deploy and simple to customize. This way, important steps like consent ceremonies can be made clear, unambiguous and — most importantly — compliant with the law.