February 27th, 2014

New API Academy Team Member: Irakli Nadareishvili

Irakli NadareishviliThe API Academy team has a new member: Irakli Nadareishvili who has joined CA Layer 7 as Director of API Strategy. Before joining CA, Irakli served as Director of Engineering for Digital Media at NPR, which is noted for its leadership in API-oriented platform design. He has also participated in the creation of the Public Media Platform, worked with whitehouse.gov and helped a number of major media companies develop publishing solutions using open source software.

I recently sat down with Irakli to discuss what he has in mind as he joins API Academy.

MM: You once told me that you believe the future of Big Data is “linked APIs”? That sounds intriguing. Tell me more about it.

IN: In most people’s minds, “Big Data” is synonymous to “very large data”. You may hear: “Google-large” or “Twitter-large” or “petabytes”. The Wikipedia definition of Big Data is slightly more elaborate:

“Big data is the term for a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications”.

In my work, I see the “complex” part of the definition becoming more important than the size. We have gotten pretty good at taming the large sizes of data. Tooling for horizontal partitioning and parallel processing of large data sets is now abundant. Still, most Big Data sets are contained and processed in the isolation of single organizations. This is bound to change very soon. The end of siloed Big Data is near: I believe that the next phase of Big Data challenges will have to do with data sets that cross organizational boundaries.

APIs will play a major role in this. Web APIs represent the most effective available technology that allows data to cross organizational boundaries. APIs efficiently connect and link data at a distance.

MM: Can you give an example of what you mean by “data sets that cross organizational boundaries”? And what challenges do these pose?

IN: You see, a lot of people have the notion that the data they need to process can be stored in a database maintained by a single organization. This notion is increasingly inaccurate. More and more, organizations are having to deal with highly-distributed data sets.

This can be very challenging. The infamous healthcare.gov is a good example of such a distributed system. The main technical challenge of implementing healthcare.gov’s backend was that it had to integrate with data in many existing systems.

The $500 million initial public fiasco of healthcare.gov is also a vivid indication of just how complex it is to build truly distributed systems. Practically the only successful implementation of such a large, distributed information system is the World Wide Web. There’s a lot we can learn from the architecture of the Web. It’s a battle-tested blueprint for building distributed systems at scale.

I believe the Big Data challenges of the future will be solved at the intersection of APIs with Web/hypermedia architecture, linked data and what we currently call Big Data tooling. I call this intersection “Linked APIs”, to differentiate it from the current, siloed state of most Web APIs.

MM: What practical advice would you give to the developers of future Big Data APIs?

IN: I think the most important thing is that we need to stop falsely assuming all of the API data is local data. It is not. Despite the name, an API for a distributed system is really not a “programming interface” to local data/assets. Rather, it is a programmable data index. Think of APIs as a programmable search index for a distributed collection of data sets.

I don’t like to think of the term “API” as an abbreviation anymore. Maybe it was one a while ago but it has since evolved way past that. Much like IBM doesn’t think of itself as “International Business Machines” anymore, APIs aren’t merely “application programming interfaces”. Most of what IBM does these days isn’t even necessarily about “machines”. Likewise, most of what we need out of APIs isn’t about any single application or an interface to it.

MM: Big Data represents one important challenge for computing today. What about IoT?

NN: The Internet of Things is already here, in small ways. The IoT we have today consists of a vast number of Web-connected devices, acting as sensors, sending myriads of signals to the cloud. That, by the way, is what creates many Big Data challenges. The future is much more interesting, however. Once the connected devices start engaging in peer-to-peer interactions, bypassing central authority, we will enter a significantly different realm. The most important challenge in that world, from my perspective, will be identity. Identity is always key in distributed systems but especially so in peer-to-peer networks.

MM: What excites you the most about your new role at Layer 7?

IN: Thank you for asking this question. I will start by telling you what terrifies me the most. The API Academy and Layer 7 teams represent a gathering of  ”scary” amounts of world-class brainpower and expertise in the API space. It is extremely humbling to be part of such a distinguished group.

Obviously, it also means that there is a lot of very fundamental thinking and innovation that happens here. Especially now that Layer 7 is part of CA Technologies, there’s really very little that we couldn’t accomplish if we put our hearts to it. That feels extremely empowering. I really care about all things related to APIs and distributed systems, the role they can play for the future of technology. I am super excited about the possibilities that lie ahead of us.

February 26th, 2014

What We Should Learn from the Apple SSL Bug

Written by
 

What We Should Learn from the Apple SSL BugTwo years ago, a paper appeared with the provocative title “The Most Dangerous Code in the World.” Its subject? SSL, the foundation for secure e-commerce. The world’s most dangerous software, it turns out, is a technology we all use on a more-or-less daily basis.

The problem the paper described wasn’t an issue with the SSL protocol, which is a solid and mature technology but with the client libraries developers use to start a session. SSL is easy to use but you must be careful to set it up properly. The authors found that many developers aren’t so careful, leaving the protocol open to exploit. Most of these mistakes are elementary, such as not fully validating server certificates and trust chains.

Another dramatic example of the pitfalls of SSL emerged this last weekend as Apple issued a warning about an issue discovered in its own SSL libraries on iOS. The problem seems to come from a spurious goto fail statement that crept into the source code, likely the result of a bad copy/paste. Ironically, fail is exactly what this extra code did. Clients using the library failed to completely validate server certificates, leaving them vulnerable to exploit.

The problem should have been caught in QA; obviously, it wasn’t. The lesson to take away from here is not that Apple is bad — it responded quickly and efficiently the way it should — but that even the best of the best sometimes make mistakes. Security is just hard.

So, if security is too hard and people will always make mistakes, how should we protect ourselves? The answer is to simplify. Complexity is the enemy of good security because complexity masks problems. We need to build our security architectures on basic principles that promote peer-reviewed validation of configuration as well as continuous audit of operation.

Despite this very public failure, it is safe to rely on SSL as a security solution but only if you configure it correctly. SSL is a mature technology and it is unusual for problems to appear in libraries. But this weekend’s events do highlight the uncomfortable line of trust we necessarily draw with third-party code. Obviously, we need to invest our trust carefully. But we also must recognize that bugs happen and the real test is about how effectively we respond when exploits appear and patches become available. Simple architectures work to our favor when the zero-day clock starts ticking.

On Monday at the RSA Conference, CA Technologies announced the general availability of the new Layer 7 SDK for securing mobile transactions. We designed this SDK with one goal: to make API security simpler for mobile developers. We do this by automating the process of authentication and setting up secure connections with API servers. If developers are freed up from tedious security programming, they are less likely to do something wrong — however simple the configuration may appear. In this way, developers can focus on building great apps, instead of worrying about security minutia.

In addition to offering secure authentication and communications, the SDK also provides secure Single Sign-On (SSO) across mobile apps. Use the term “SSO” and most people instinctively picture one browser authenticating across many Web servers. This common use case defined the term. But SSO can also be applied to the client apps on a mobile device. Apps are very independent in iOS and Android, and sharing information between them, such as in an authentication context, is challenging. Our SDK does this automatically and securely, providing a VPN-like experience for apps without the very negative user experience of mobile VPNs.

Let me assure you that this is not yet another opaque, proprietary security solution. Peel back the layers of this onion and you will find a standards-based OAuth and OpenID Connect implementation. We built this solution on top of the Layer 7 Gateway’s underlying PKI system and we leveraged this to provide increased levels of trust.

If you see me in the halls of the RSA Conference, don’t hesitate to stop me and ask for a demo. Or drop by the CA Technologies booth where we can show you this exciting new technology in action.

February 21st, 2014

RSA Conference 2014 Preview & a Special CA Layer 7 Event

RSA Conference 2014Despite all our advances in communications — from social networking, to blogs, to actually functional video meetings — the trade conference is still a necessity. Maybe not as much for the content, which makes the rounds pretty fast regardless of whether you attend the show or not, but for the serendipitous meetings and social networking (in the pre-Facebook/Twitter sense).

I find something comforting in the rhythm and structure a handful of annual conferences bring to my life. The best ones stay rooted in one location, occurring at the same time, year after year. They are as much defined by time and place as topic.

If it’s February, it must be San Francisco and the RSA conference. I’ve attended for years and despite the draw from the simultaneous Mobile World Congress in Barcelona, RSA is a show I won’t skip. But I do wish MWC would bump itself a week in either direction so I could do both.

As everyone knows, this year the press made much ado of a few high-profile boycotts of the conference and the two alt-cons, Security B-Sides and TrustyCon, that sprung up in response. But I think it’s important to separate RSA the company from RSA the conference. The latter remains the most important security event of the year.

Every year, one theme rises above the rest. I’m not referring to the “official” theme but the trends that appear spontaneously in the valley. The theme this year should be security analytics. The venture community has put this idea on an aggressive regime of funding injections. We should expect an entertaining gallery of results, both good and bad. But either way, we will learn something and it would be a poor move to bet against this sector’s future.

I’m also expecting 2014 to bring some real SDN traction. Traditional security infrastructure is low-hanging fruit vendors too often miss. RSA is where SDNs for security will finally get a long-awaited debut.

MWC may be the premier event for mobile but most mobile security companies cover both conferences and CA is no exception. At RSA, we’ll be unveiling the new version of our Mobile Access Gateway. This features SDKs for iOS, Android and JavaScript that make enterprise authentication simple for mobile developers.  As a bonus, these SDKs offer cross-app SSO. This means users sign on just once, from any authorized app. You should definitely come by the CA Technologies booth at either show to have a look. And if you do see me at the RSA show, be sure to ask me about the integrated PKI — surely one of the coolest, unsung features underneath the SDK hood.

CA and Layer 7 will also be hosting an afternoon event on Monday Feb 24 at the nearby Marriott Marquis and you are invited. You may recall we’ve held a few of these before but this year, we have a very special guest. The event will feature Forrester analyst Eve Maler, who will talk about zero trust and APIs. It will be a great way to kick off RSA 2014 and we’ll even give you a nice lunch. Who could refuse that?

To join us, sign up here.

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

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.