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.

December 23rd, 2013

Thanks to All Who’ve Been Good This Year

Layer 7 Holiday Promo 2013The year 2013 has been one heck of an adventure for me. My work with Layer 7, CA Technologies and the API Academy team (yes, we have many names!) has taken me around the world, allowed me to speak at several amazing conferences and provided the chance to interact with some remarkable organizations working on APIs for the Web and enterprise. Along the way, I’ve met many incredibly smart and generous people.

In the last year, I’ve worked with organizations striving to reinvent the role of the enterprise architect from a controlling force to an enabler – a person who ensures the development environment is a safe place to be creative; a person who provides help to product groups and development teams via research and guidance taken from a wide range of sources; someone who works to empower teams and cut down on unneeded ceremony and red tape. These are good people and they’ve been a pleasure to work with and learn from along the way.

I’ve also met many conference organizers and community leaders doing essentially the same thing from a different angle. Along the way, I’ve met people who are devoting huge chunks of time, effort and resources to creating events that improve communication, facilitate collaboration and foster success across a range of communities. It’s been really amazing to be a part of these events and to meet so many giving and open people working toward a common goal.

My experience online has been equally enlightening. In the last year, I’ve “met” many new and interesting people, discovered several helpful efforts and organizations. I am lucky that I can learn something new every day online from those I’d likely never meet in person, simply because we are physically far apart.

One experience in particular has marked 2013 for me. I had the honor to work closely with Leonard Richardson on a book project – RESTful Web APIs. It was Leonard’s idea to create the book and I was happy he invited me to help shape the message and content. I’ve learned a great deal from him and I can see the results of that work in online comments and reviews. I am pleased to be associated with Leonard’s talent and vision.

There’s a common thread through all these experiences: I’ve had the luck and privilege of meeting many “good” people this year. This blog post is my way to give a blanket shout out to everyone who challenged me, taught me, invited me, supported me and hosted me in so many ways in the last year. Thanks!

As another small way of saying thanks, we’re offering several free copies of the RESTful Web APIs book to some of those who’ve been “good” this year. All you need to do is add yourself to our “nice list” (go ahead, you know you deserve it). We’ll be giving away a couple dozen copies of the book soon after the holidays.

So, again, thanks to all for your help and support in 2013. And look out for us in 2014 – things are just getting started!

December 10th, 2013

Layer 7 at Gartner AADI Las Vegas 2013

Gartner AADI 2013Last week, I attended the Gartner Application Architecture, Development & Integration Summit in Las Vegas for the third consecutive year. Aside from the cool alumni sticker on my attendee badge, returning annually to this conference also provides a really interesting touch-point with a familiar cross-section of potential (and existing) customers.

In past years, talking to other attendees during exhibit hours involved some amount of basic education around the value of APIs to enterprises, potential use cases and the need for security and management of those APIs. This year was a totally different experience, as there was no education necessary. Instead, I found these decision makers already informed – eager to implement or continue implementing their API strategies in order to achieve real-world mandates from their management and lines of business.

They told me about mobile initiatives requiring apps developed for customers, partners and/or employees; they talked about modernization of legacy infrastructure and a deeper embrace of hybrid cloud; they recognized the need for developer enablement and a shift toward continuous deployment. Most importantly for us, they recognized that APIs are essential to the successful deployment of each of these initiatives.

In a world quickly moving toward “software-defined everything,” they also acknowledged the importance of API security and management. Instead of asking why they would need our solution, they asked for differentiators in the marketplace and our latest innovations. I was happy to talk with them about the recently-released version 2.0 of our Mobile Access Gateway, which enables developers to focus on creating the best apps possible while maintaining an unprecedented level of end-to-end security from the native app to the enterprise datacenter.

We also talked about: advanced features in the latest releases of our Gateway and API Portal products; our unparalleled capabilities in security and integration; our recognition from analysts as leaders and innovators in the industry. And we talked about the future – what new technologies are being considered and how they’re going to transform the enterprise even further.

As 2013 comes to a close, this year is beginning to look like a turning point. This may be remembered as the year enterprises embraced the API, leading to a broad range of innovative programs. We’ve seen massive consolidation and investment in our space, including our own acquisition. APIs have certainly joined the mainstream. Now it’s time to see what great things we can help our customers accomplish. I’m really looking forward to 2014!

December 2nd, 2013

How I Lost Weight & Learned About APIs

How I Lost Weight with APIsTrying to stay in shape is one of those never-ending life battles that I’ve come to expect as I get older. I’ve bounced between being a healthy shape and a not-so-healthy one for years and I’ve managed to live life just outside the edge of ideal fitness. A few months back, I reached an apex point and dedicated myself to losing a few pounds (again) and set off on a journey to change my life (yet again). Little did I know I’d learn something about APIs along the way.

Everyone has their own way of losing weight but I’ve always preferred a measurable, rationalist approach: I count the calories I consume, I subtract the calories I burn and I budget accordingly. The nice thing is that this method forces me to think about what I’m consuming and what I’m doing. The massive downside is that keeping track of all of the data is a monotonous and soul-destroying effort that often leads to me giving up.

Of course, there is an app for everything now and I started using  a tool to keep a log of foods that I ate along with their associated caloric burdens. One problem with this type of tool is that, while it’s easy to log consumption of food using features like bar code scanners and crowd-based data, the process of logging exercise and calorie expenditure is entirely manual. This can make fitness goals harder to achieve as users like me end up either under or over estimating their daily calorie burn.

Thankfully, devices to monitor your physical exertion do exist and they are reasonably affordable. These are wearable devices that provide a tally of steps taken, stairs climbed and physical exertion throughout the day, providing a wealth of personal data to mine. To be honest, I’d always viewed these devices in the same category as things like Google Glass – really cool pieces of technology that bleeding-edge enthusiasts wear publicly at the cost of their own dignity. But something changed for me when I realized that I’d be able to connect the calorie-counting app I was using with the wearable fitness device. So, I made a purchase.

By connecting the food-tracking application with the activity-tracking device, I was able to get a much more accurate picture of my caloric budget for the day. The systems integrated remarkably well and the quantification of remaining calories along with a few gamification features provided extra incentive for me to keep moving and eat less.

In the end, this behavioral conditioning of triggers, alerts and feedback loops worked well for me and I was able to drop a few pounds. Of course, I lost the tracker on an airplane about a month in and I’m currently racing back towards a pear shape but that isn’t the point. What is more interesting is what we can learn about integration from my journey:

1.  An API is a Great Way to Extend Customer Reach to Platforms
When we think about building APIs, we usually think about extending out to mobile devices or social platforms. But organizations should consider how their products can be extended to niche and non-traditional platforms that their target user base actively uses. If the wearable tracker I purchased didn’t work with the calorie-counting application I was already using, I never would have considered buying the tracker in the first place. But thanks to the API-based integration, I could visualize myself using it and this was the trigger that resulted in a purchase decision.

2.  Integration is Becoming a Core Requirement Instead of a Feature
Something I noticed when scanning the forums on the tracker device’s Web site was the number of posts related to integration with other exercise platforms. For this user base, integration with their favourite run-tracking, calorie-counting or fitness-gamification tools isn’t just a nice-to-have – it is the minimum expectation. It seems that end users are increasingly expecting product vendors to support their platforms of choice and want the freedom to make their own decisions. In other words,  users don’t want to be punished for choosing a less popular tracking tool or a mobile phone operating system that has less market share.

3.  Integration with Potential Competitors can Pay Off
What I didn’t mention in my story was that the fitness tracker I purchased did come with a calorie-consumption-tracking feature. In fact, part of the revenue stream for this product is the sale of subscriptions to the manufacturer’s fitness portal, as part of an end-to-end fitness management program. This means that supporting out-of-the box integration with other fitness trackers actually comes at a potential revenue cost for the tracker vendor. But I would imagine that the overall revenue benefit from attracting customers like myself outweighs the revenue lost from users who choose not to subscribe to the portal. Integrating with competitive products can be a risky proposition but a smart gamble can really pay off.

As interest in the Internet of Things (IoT) continues to increase, I expect to see an increasing variety of interesting device-to-platform integration stories. Businesses will need to have coherent business strategies for extending to this new world, with APIs as an important supporting action.

Also, if you happen to see me in person, don’t forget to tell me how great I’m looking nowadays.

November 13th, 2013

QCon San Francisco 2013

QCon 2013This Thursday, I’ll be at QCon San Francisco to lead the RESTful Web APIs tutorial. This will be the second time QCon has hosted the full-day workshop and I’m very much looking forward to it. Most of the material I’ve prepared for this workshop is based on the book of the same name by Leonard Richardson and myself. That book was released in September of this year and we’ve been getting very positive feedback on it.

Participants in the workshop will learn how to design a hypermedia type, how to implement servers that safely and consistently expose business functionality using hypermedia and how to build client applications that understand the hypermedia messages and can interact with servers to create enjoyable user experiences.

Along the way several key principles will be explored, including:

  • Why a hypermedia-based message model is better than a code-based object model
  • How Web servers can expose operations as stateless resources instead of as function calls
  • How client applications can recognize and use hypermedia workflow to create quality user experiences
  • Why the hypermedia approach makes it easier to make small changes on the server without breaking existing client applications

The full-day session will also cover important technical aspects of implementing distributed applications over the Web. We will focus on identifying and managing the boundaries between services in order to increase both security and stability over the lifetime of the service. Attendees will get a chance to use existing services as a guide when creating their own and will even get a chance to introduce changes on the backend to see how their client applications can adapt and continue to function.

I always enjoy these extended workshops because it gives everyone (even myself) a chance to write real-life code for real-life services. I spend quite a bit of my time lecturing and advocating for increased reliance on adaptable distributed systems and it’s a rewarding experience. However, it’s also very energizing to work with people in a hands-on atmosphere where everyone is focused on getting things up and running in a working environment.

Of course, there will be lots of fun in the day, too. We have trivia breaks, I offer some handy prizes and we have plenty of time to relax and get to know each other. Overall, these full-day, hands-on workshops represent one of my favorite ways to spend a day with smart, talented people. And I’m grateful to the folks at QCon who make it all possible.

So, if you’re in San Francisco this Thursday and don’t have anything pressing to do, come on over to QCon and join us. Bring your laptop loaded with your favorite Web coding tools and your thinking cap. We’ve got a place all ready for you.