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

February 18th, 2014

A World of Apps & APIs

Apps WorldApplications – and specifically mobile apps – occupy a key battleground for companies trying to woo customers, differentiate their products and drive growth. This is happening across many industries but banking provides a good example. Mobile applications that put banking services in the palm of your hand have become a much more important differentiator than interest rates, which were previously used to lure customers. A well-designed mobile app drives a more engaging experience for customers and this, in turn, drives customer acquisition and retention.

During the recent Apps World show in San Francisco, we saw some examples of this trend and the extraordinary growth right across the application ecosystem. Of course, behind every great app there’s usually a great API and my “State of the Union” address on APIs highlighted the hard work and success we’ve seen over the past few years. But it also served as a reflection on the key areas enterprises much consider as they accelerate innovation via APIs and engage customers in new ways.

Identity and security were recurring themes and we’ll certainly be hearing more about these issues in the coming months. With public awareness of mobile exploits and loss of personal information growing fast, mobile app security is going to dominate the thoughts not just of product managers everywhere but also those of lawmakers seeking to define stricter legislation to protect consumers.

In this context there’s an increasing need to double down on the fundamental requirement for strong-but-user-friendly identity and security functionality in mobile apps. For developers building apps against enterprise APIs, meeting this requirement can be extremely challenging. Thankfully, enterprises can simplify the situation by leveraging the advanced identity and security features of API Management platforms. Right now, app security is often a stumbling block but – by making some smart infrastructural decisions early on – enterprises can turn it into a serious differentiator.

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 7th, 2013

The Software-Defined Telco

Software Defined TelcoBack in 2011, Marc Andreessen famously stated that “software is eating the world” and predicted that – over the subsequent decade – almost every major industry would be disrupted and transformed by software and the innovations of Silicon Valley. Just over two years later, it’s pretty clear he was right on the money. In order to remain relevant, many industrial behemoths need to transform themselves and they are looking at the software revolution as a way to enable a fresh wave of innovation and development.

This revolution has never been more important to the telco world, where it must start at the very core of the organization. Every layer – from network, to infrastructure, to application – should be considered a service enabler, be defined in software and be driven by APIs. A new wave of thought leadership and investment around “network functions virtualization” (NFV) is acting as a catalyst for this transformation and telcos can finally start to eschew the limitations of legacy networks and allow operators to more easily keep pace with Silicon Valley.

Finally then, APIs and API platforms can regain their intended utility in the telecommunications sector, emerging from a meandering journey through failed open developer ecosystems and misguided monetization strategies. APIs are meant to be at the very core of product development, they are supposed to be the foundation of a product or service and not tacked on the side afterwards. APIs enable an architectural paradigm that is essential to the software-defined network and they provide a scalable, documented and secure way of integrating systems and clients.

Layer 7 will be presenting a vision for the future of APIs in the software-defined telco at the Telecom APIs event in London (Nov 11 – 13) and the Telecom Application Developer Summit in Bangkok (Nov 21 – 22).