February 19th, 2014

New eBook: 5 Simple Strategies for Securing Your APIs

5 Simple Strategies for Securing APIsRecently, I wrote about the excitement I feel working within CA. This company is full of talented people and when you draw on their capabilities, amazing stuff happens. Here in R&D, we have some innovative solutions underway that are tangible results of CA and Layer 7 working well together. I can’t reveal these yet but you can see the same 1+1=3 equation at work in other groups throughout the organization.

Here is a good example: It’s an eBook we’ve assembled to help managers and developers build more secure APIs. The material started with a presentation I first delivered at a recent RSA show. We updated this with best practices developed by real customers facing real challenges. The content is solid but what I love is the final product. It’s accessible, easy to digest and the layout is fantastic. Half the battle is delivering the message so that it’s clear, approachable and actionable. This is just what we delivered. And best of all, it’s free.

The last year has been a difficult one in security. The Snowden affair made people talk about security; this, at least, is good and the dialog continues today. But if 2013 was a year of difficult revelation, 2014 is going to be about back-to-basics security.

APIs offer tremendous business value to enterprise computing. But they also represent a potential threat. You can manage this risk with a solid foundation and good basic practices but you need to know where to start. This is the theme of our new eBook. It offers simple guidelines, not tied to any particular technology. You should apply these whenever you deploy APIs.

I hope you find this eBook useful. As always, I’d love to hear your feedback.

Download the eBook: 5 Simple Strategies for Securing Your APIs

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!

October 4th, 2013

Can Your API be BREACHed?

Secure APITLS and SSL form the foundations of security on the Web. Everything from card payments to OAuth bearer tokens depend on the confidentiality and integrity that a secure TLS connection can provide. So when a team of clever engineers unveiled a new attack on SSL/TLS – called BREACH – at July’s Black Hat conference, more than a few eyebrows were raised. Now that it’s Cyber Security Awareness Month, it seems like a good time to examine the BREACH threat.

There have already been a number of articles in the technology press identifying threats BREACH poses to traditional Web sites and suggesting ways to mitigate the risks but it is important for us to examine this attack vector from an API perspective. API designers need to understand what the attack is, what risks there are to Web-based APIs and what can be done to mitigate the risks.

The BREACH attack is actually an iteration of  a TLS attack named CRIME, which emerged last year. Both attacks are able to retrieve encrypted data from a TLS connection by taking advantage of the way data compression works in order to guess the value of a confidential token in the payload. While CRIME relied specifically on exploiting the way TLS-based compression works, the BREACH exploit can target messages sent with compression enabled at the HTTP/S level, which may be much more widely enabled in the field.

HTTP compression is based on two compression strategies for data reduction: Huffman coding and LZ77. The LZ77 algorithm accomplishes its goal of data compression by identifying and removing duplicate pieces of data from an uncompressed message. In other words,  LZ77 makes a message smaller by finding duplicate occurrences of data in the text to be compressed and replacing them with smaller references to their locations.

A side effect of this algorithm is that the compressed data size is indicative of the amount of duplicate data in the payload. The BREACH attack exploits this side effect of LZ77 by using the size of a message as a way of guessing the contents of a confidential token. It is similar in nature to continually guessing a user’s credentials on a system that provides you with unlimited guesses.

While the premise is scary, the good news is that the BREACH attack doesn’t give an attacker unfettered access to the encrypted TLS payload. Instead, it is a targeted attack that attempts to retrieve a confidential token through repeated and iterative guesses. In fact, the attack isn’t an exploit of the TLS protocol at all, rather it is an attack that can be applied to any messaging system that uses the gzip compression algorithm (which is a variation of LZ77).

On top of this, BREACH is not an easy attack to pull off. A would-be BREACHer must:

  1. Identify an HTTPs message which has compressed data, a static secret token and a property that can be manipulated
  2. Trigger the application or server to generate many such messages in order to have a large enough sample size to iteratively guess the token
  3. Intercept all of these messages in order to analyze their sizes

Each of these requirements is non-trivial. When combined, they greatly reduce the attack surface for a BREACH attack in the API space. While API messages certainly contain data that may be manipulated and while many APIs do provide compressed response data, very few of those API messages also contain confidential tokens.

But designers of APIs shouldn’t dismiss the possibility of being BREACHed. There are at least two scenarios that might make an API susceptible to this attack vector.

Scenario 1 – Authentication & CSRF Tokens in Payloads:
Many APIs return an authentication token or CSRF token within successful responses.  For example, a search API might provide the following response message:

<SearchResponse>
    <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
    <Terms>…</Terms>
    <Results>…</Results>
</SearchResponse>

If this response message was compressed and the attacker was able to coerce a victim into sending many requests with specific search terms, it would only be a matter of time before the AuthToken credential was retrieved.

Scenario 2 – Three-Legged OAuth:
APIs that support the OAuth 2 framework for delegated authorization often implement CSRF tokens, as recommended in the OAuth 2 RFC. The purpose of the token is to protect client applications from an attack vector in which a client can be tricked into unknowingly acting upon someone else’s resources (Stephen Sclafani provides  a better explanation of the CSRF threat here.)  Due to the fact that CSRF tokens are reflected back by the server, the three-legged OAuth dance becomes a possible attack surface for BREACH.

For example, an attacker could coerce a victim to send repeated OAuth 2 authorization requests and utilize the state parameter to guess the value of the authorization token. Of course, all of this comes with the caveat that the OAuth server must be compressing responses to become a target. The fact that a new authorization code is generated for each authorization attempt would make this attack less practical but still theoretically possible.

Ultimately, the simplest way to mitigate the BREACH attack is to simply turn off compression for all messages. It isn’t hard to do and it will stop BREACH dead in its tracks. However, in some cases, designers may need to support compression for large data responses containing non-critical information or because they are supporting platforms with low bandwidth capabilities.  In these instances, it makes sense to implement a selective compression policy on an API Gateway.

While disabling compression will certainly negate the impact of the BREACH attack, a more general solution is to impose smart rate limiting on API requests. This will not only negate the sample size that a BREACH attacker needs to guess data, it will also stop other side-effect attacks that don’t rely solely on compression. In addition, log analysis and analytics will make it easier to spot any attempt at an attack of this kind.

An API Gateway is the key component for this type of security mitigation in the API space. A Gateway can provide the level of abstraction needed to enforce configurable compression and rate limiting policies that server side developers may not have the security background to implement effectively. In addition, the Gateway acts as a central enforcement point for security policy – particularly useful in larger federated organizations.

TLS is core to most of the security implementations that have evolved on the Web, including the OAuth 2 framework. This latest published attack does not render the world’s TLS implementations useless but it does introduce an interesting attack vector that is worth protecting against in the API domain. Remember, API rate limiting and usage monitoring are useful for much more than just monetizing an API!

October 1st, 2013

Cyber Security Awareness Month & the Internet of Vulnerable Things

IoT SecurityDid you know that October 2013 is the 10th National Cyber Security Awareness Month in the US? While I usually emphasize the enormous potential of the Internet of Things (IoT), let’s use the occasion to look at the security risks of the Internet of really vulnerable things.

Over the last couple of months, a casual observer could have noticed a variety of security scares related to “connected things” – from hacked baby monitors to hacked cars. In August, my colleague Matthew McLarty wrote about the security vulnerabilities of the Tesla Model S. Regulators also started to take notice and felt compelled to act.

Given that the problems appear to be systemic, what can companies do to mitigate the risks for connected devices? Rather than looking for yet another technological solution, my advice would be to apply common sense. It’s an industry-wide problem, not because of a lack of technology but because security and privacy are afterthoughts in the product design process. To get a feeling for the sheer scale of the problem, I suggest taking a look at the search engine Shodan. Both SiliconANGLE and Forbes have recently run articles covering some its findings.

Yet these problems did not start with IoT. For instance, Siemens was shipping industrial controllers with hardcoded passwords before the dawn of IoT – enabling the now infamous Stuxnet attack. Despite all the publicity, there are still vulnerabilities in industrial control systems, as noted in a Dark Reading article from the beginning of the year.

All the best practices and technologies needed to address these problems exist and can be applied today. But it is a people (designer, developer, consumer) problem and a (product design) process problem, not a technology problem. Designing fail-close (rather than fail-open) systems, using meaningful authentication, authorization and encryption settings and so on – all of this can be done today with little or no additional effort.

Essentially, our legal process has not caught up with technology. And it won’t for as long as the lack of security merely inconveniences us rather than threatening us with loss of property – or even life! Conversely, we are pretty good at applying security best practices in aviation because most serious problems with an aircraft in flight are inherently catastrophic. So, let’s hope that the recent news of hackers accessing airplane flight control systems acts as a wake-up call for the industry.

As API Management providers, we at Layer 7 are, more often than not, actively involved in shaping the API security policies and best practices of our customers. Since we believe APIs will form the glue that will hold IoT together, we are using our API Academy to disseminate API best practices in a vendor-neutral way. Most of what we have learned regarding scalability, resilience and security from the SOA days is still applicable in the API space and will be applicable in the IoT space. As the magnitude of interconnectedness grows, security remains paramount.