Jaime Ryan

Jaime Ryan

Jaime Ryan is the Partner Solutions Architect at Layer 7 Technologies. Jaime has been building secure integration architectures as a developer, architect, consultant and author for the last 15 years. He lives in San Diego with his wife and two daughters.

August 1st, 2014

Balancing Security & Developer Enablement in Enterprise Mobility: Gartner Catalyst 2014

Gartner Catalyst San Diego 2014It’s that time of year again… time for another beautiful late-summer Gartner Catalyst conference in America’s Finest City: San Diego. Aside from being my hometown, the reason San Diego is so great is that it has balance. The warm sun is balanced by the cool ocean breeze, the strong business climate is balanced by the laid-back surf culture and the delicious fish tacos are balanced by a cold Corona. Balance makes everything better. Maintaining this balance is just as important when you’re talking about mobile strategy for your enterprise; that’s why I’ll be presenting a talk titled Balancing Security & Developer Enablement in Enterprise Mobility at Catalyst.

Enterprise IT security departments have always had a somewhat adversarial relationship with application developers, even when the applications ran entirely within the intranet. Now that internal data and applications are being exposed to employees, partners and customers through a whole new breed of mobile apps, these teams could potentially clash even more often. Security architects are more concerned than ever about core principles and security standards while developers are more focused than ever on providing incredible user experience rather than worrying about internal restrictions.

I’ll be discussing how these two groups – enterprise and security architects on one side and mobile app developers on the other – can accomplish the same goals. CA’s Layer 7 API Management solutions enable the enterprise to enforce the latest security specifications to the letter, protecting against malicious (or even accidental) threats to critical systems. But at the same time, they enable mobile app developers to very quickly consume the appropriate data through secure APIs, without having to implement the client side of those cutting-edge security standards. Stop by my talk on August 12 at 12:45pm to get the details or come by the Layer 7 booth (#113) to talk in more depth about how we can bring balance to your workplace.

 

June 27th, 2014

Drones, Phones & Pwns:
The Promise (& Dangers) of IoT APIs

DroneEarlier this month, CA Layer 7 participated in yet another great conference – this time, it was QCon New York. As a three-time QCon attendee, I have always really appreciated the level of technical knowledge displayed by attendees. At this show, it’s rare that I have to explain the basics of APIs; most attendees are already using APIs in some form or another. And even though many of them are very hands-on developers, they are savvy enough to realize when it is and isn’t appropriate to “build it yourself.”

Many of my conversations began with, “We’re exposing APIs but we don’t have a good way to manage our developer community.” Even more interesting were the ones which began, “We built our own API Management layer but it doesn’t…” There was a wide array of endings to that sentence, including “scale well,” “provide any real security” and “help our developers build applications quickly.” Security was an especially common theme as these folks are smart enough to realize they are not primarily experts at implementing OAuth-based access control or protecting APIs against structural or content-based threats. They’d rather let Layer 7 worry about the implementation and simply configure which options are relevant to their applications. And, of course, many examples of app hacks, data breaches and identity theft are in the news these days; nobody wants their company to be the next victim.

Aside from being a common theme in discussions at the show, maintaining security and privacy in an increasingly interconnected world was the theme of my talk, titled Drones, Phones & Pwns: The Promise (& Dangers) of IoT & APIs. In the first half, I discussed the recent transition of drones from military/intelligence use cases to commercial/personal use and talked about some of the cool technologies already being enabled by these and other data-gathering “things”, such as our phones. I used personal examples to show how my life and the lives of many others are made more pleasant and efficient by this connectivity and data aggregation. After delving into the broad range of use cases made possible by the Internet of Things, it was time to take a look at the other side of the coin.

The second half of my presentation was about the darker side of all the personal data flowing around the Internet and the leaking/sharing/exposure that happens with or without our awareness. I tried not to mention obscure exploits that are unlikely to ever be used; instead, I used real-world examples of glaring privacy holes in devices and apps that we use every day. Rather than simply fear mongering, I tried to make a point about the trust that people – myself included – place in the companies and entities around them. And I followed up those bits with some advice about what we can do to make our future a little less frightening.

The reaction to my presentation was pretty surprising. Even amongst a very technical audience, I still had people approaching me all day afterward, explaining that I had scared them so much they weren’t ever going to look at their phone/car/gaming console/app the same way again. For those that were already familiar with some of the examples I had given, it provided a great conversation starter about security and what sort of cultural shifts will be required to alleviate some of the more pervasive issues.

These are the types of conversations we like to have with our customers – realistic assessments of the risks and challenges encountered by enterprises opening their data and applications to customers, partners and employees, followed by specific discussion of solutions. Considering the interest our customers are showing in these discussions, we’ve decided to do an encore presentation of my conference talk for a larger audience. I’m excited to announce the Layer 7 webinar Drones, Phones & Pwns: The Promise (& Dangers) of IoT & APIs will be held on July 23 at 9am Pacific Time. Registration is now open.

Sign up for the webinar >>

April 25th, 2014

The Importance of Context to Mobility

Written by
 

Mobile ContextMy grandfather has a bumper sticker on his pickup truck that says “He who dies with the most toys, wins.” Since my world revolves more around API Management than collecting die-cast models of John Deere tractors, I have my own version of the saying – “He who has the most context wins.” Context has always been an important part of managing data or applications, but the proliferation of enterprise B2E (business-to-employee) and B2C (business-to-consumer) mobile apps has significantly increased the need for context-based policy.

The Layer 7 family of API Gateways has always been good at context. Not only does a Gateway have access to the full request and response content, it can also access header content (from a wide variety of protocols) and transaction metadata (latency, source information etc.) Then it adds in user credentials and attributes retrieved from the request and backend identity management systems. These inform decisions around access control but also around traffic routing, prioritization, rate limiting, quota fulfillment etc.

However, mobility introduces a few new entities to the equation, all of which have to be taken into account for ideal contextual decision-making. The first is familiar: users; but mobile users might have additional attributes that come into play. Phone number and email become more important, since they provide other connection points accessible to the user on the same device (smartphone, tablet etc.) The inclusion of social login – available in the 2.1 release of our Mobile Access Gateway – provides social graph information that might also have relevance when deciding how a user request should be processed.

The second entity providing contextual attributes is the app itself. An app ID or API key can tie an application back to the developer who created it. Signer information, permissions and other internal details can give context around existing app security. The Mobile Access Gateway can collect some of this information using our Mobile SDK and more data can be gathered via integration with CA (or third-party) MAM and MDM products.

The third important entity is the device itself. Not only can APIs be tailored to return data structures specific to a screen size or even a specific device type but behavior can also be tracked to a single device ID to analyze the risk involved. There might be more risk delivering sensitive data to a family iPad than there would be on a personal smartphone – or to a phone in an airport rather than a laptop in the office. This level of risk (and the associated response) increases dramatically when interacting with an unlocked device rather than one locked down by corporate security policies.

In my new role across the CA Securecenter product line, I’ve focused quite a bit on the integration of Layer 7 with other CA products. The result has been a flood of new contextual information with which to make richer decisions. Gathering risk profiles from CA RiskMinder or data categorization from CA DataMinder provides an even stronger understanding of who is trying to access what, from where. And the decision made from this context doesn’t necessarily have to result in a thumbs-up or thumbs-down; with CA AuthMinder, suspicious requests can simply require an additional level of authentication.

Every industry has its own variables, vulnerabilities and potential optimizations. Our goal is to give customers the right context with which to make the best decisions for their specific use cases. Our rich interface management capabilities and strong integrations with other proprietary and standards-based mobile technologies give us the best palette of access control and policy options in the API Management industry. In a world where context is king, we’re continually fighting for that crown.

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