Cloud Security series - issues around PII, privacy, and audit compliance »

Greg recently sat down with Ryan Bagnulo, Security Architect for ASPECT-i, to discuss a number of cloud security concerns and issues.   

We captured these discussions in six short videos, each focusing on a  topic.  Here are the first two on PII, data filtering, and audit and regulatory concerns,  (see the full series here.)

In this first video, Greg and Ryan set things up with discussions on:

• Challenges in deploying cloud, starting with: should you trust your cloud administrator?
• Good data for early cloud adoption (such as public data like news, stocks)

This 2nd short focuses on:

• issues around PII (personally identifiable information)
• counter-measures, such as de-identifying data with filtering, screening or access control
• privacy and regulatory risks around stored in the cloud.
• best practices for protecting data
• implications for violating security breaches privacy regulations

We'd love your thoughts and comments.

Protect your API: Twitter’s Denial of Service Attack and API Security »

Lots of news on the Twitter attack last week. There’s general consensus that it was a distributed denial-of-service attack (DDOS) that it targeted a particular account.

DDOS attacks are tricky things. There’s no one technique, product, or protocol that will stop them. That’s what makes them so nasty. To defend against one, a company needs to be able to quickly take countermeasures at all the different levels of the protocol stack, including firewalls, routers, load balancers, and even in the application itself. And even more importantly, you need to have experienced, well-trained operations people who know how to quickly identify an attack and come up with a way to minimize its effects.

When a DDOS attack affects a web service – and there’s an good chance that the Twitter attack made use of the Twitter API – then proper traffic management at the API level is an important part of this stack of protection.

For instance, if a DDOS attack targets a particular user account, or API key, it may be possible to block those particular requests before they get to the back-end application servers, so that the effect of the attack is limited. Or, if the attack always sends some of the same parameters in an HTTP query string, or in the body of an HTTP POST, it may be possible to detect those patterns and reject the requests, again before they reach the back-end application servers. In the worst case, it may even be necessary to shut off access to a particular web service or web service operation, allowing other services to function as best they can while the attack is neutralized by other means.

In other words, just as it may be possible to stop a DDOS attack by blocking a range of IP addresses, or redirecting certain URLs, or configuring traffic shaping in a router or an ADC, it may sometimes be necessary to stop a DDOS attack closer to the application level. The ability to inspect requests at the web services level and take action based on the request content gives an operations team one more weapon to use against an attack.

The Twitter API already has a usage quota on each user account, a rate limit on each IP address, and extensive caching. Imagine how much easier a DDOS attack might have been if they didn’t even have those things.

-Greg

(Greg Brail is the CTO of Sonoa and writes on API Security topics such as API Keys, OAuth, and API Security Recommendations.) 

Indecent Exposure: API Data & Threat Protection »

None of us ever want to see accidental customer data exposure through our APIs. Especially like Paris experienced last year (an API auth issue)  

Last time in our series we talked about identity, authentication, and authorization.   But another important aspect of API management is data protection - specifically: 

 > Encryption - protecting your API data from eavesdropping.
 > Threat detection - ensuring client API requests won't cause back-end problems.
 > Data masking - preventing inadvertent data exposure in API responses.

First, protecting sensitive data requires knowing what and where it is, and how sensitive it is to you and your customers. There are a lot of regulations and best practices for Social Security numbers, credit card numbers, home addresses, birthdays, and such (more on compliance in another post - data protection is just one aspect).  Once you know which data is sensitive, you can think about how to best protect it in your API.

Encryption

Encryption is a basic technology that must be part of any API with sensitive data. Some relevant technologies include SSL and XML encryption. For most APIs, the most critical encryption mechanism is SSL.  It works on every platform, and the overhead is minimal (less than 5% through our own products in benchmark tests.) Using SSL to encrypt any sensitive data is the least your API should do. 

Another alternative is to encrypt either all or part of each message using XML Encryption. (This is a W3C standard implemented by many SOA products.) However, this requires you and your clients to manage public/private key pairs, so deploying this technology can be more complex and it has a larger performance impact. But XML Encryption is tremendously useful when it’s important to manage sensitive data behind the API. For instance, if API data must not only be transmitted securely over the Internet, but also stored in internal systems in encrypted form on a disk or in a database.  Otherwise, stick with SSL. 

Threat Detection 

Any server that receives data over the Internet is subject to attack. Some attacks are more specific to an API and merit additional consideration. 

The first is SQL injection. This attack takes advantage of internal systems that construct database queries using string concatenation. If there’s a way to take data from the client and paste it inside a database query, then there may be a way to compromise the system using SQL injection. The best way to prevent SQL injection is to code the back-end systems so that an SQL injection attempt is not possible. But it’s also important to stop SQL injection attempts before they get to the back end. 

The second is an XML attack - taking advantage of the flexibility of XML by constructing a document that could cause a problem for a back-end system. For example, causing the XML software to try to allocate more memory than is available. Or, an XML document that is nested many levels deep, or with extremely large entity names or comments.

A simple check to ensure that XML or JSON is well-formed can save resources on the back end that would otherwise be devoted to generating and logging error messages. These attacks aren’t always intentional. Ever used an API like StAX to construct an XML document, but forgotten to add all the “end tags?”  An invalid XML document that appears to be nested very deep can cause problems for the back end servers, or at least tie up more CPU and memory resources. Fortunately, there are many products, including our Apigee Enterprise, that contain pre-defined policy templates to defend against these types of attacks. 

Data Masking 

In some cases, it may make sense to try and re-use internal services and data.  However, you might need to screen – or mask-  some private data for the API or for some users of the API. This means using an XML or JSON transformation to either remove or obfuscate certain data from an API response. While this technique must be used with care – there may be cases in which only certain API users are authorized to see certain information. For example, there might be an API call that returns a “user” record with all the details when the user him or herself calls this API, but only limited data when a customer service reps access the “user” record using the API. 

In that case, you could implement this by building only one version of the API on a back end server and adding a data transformation rule that removes the user’s home address if the request is coming from a CSR’s account.  If you have many services, you might consider having a common layer that performs these types of transformations – especially if you ever want to add or manipulate payload fields as well as masking or clipping fields.  (more on that in a section on API Mediation). 

Recommendations

• Use SSL when the API includes sensitive data, or if the authentication mechanism in use does not include an encryption component. (HTTP basic authentication, for instance, allows an eavesdropper to intercept the password unless SSL is used; OAuth does not.)
• Always defend against SQL injection, either in the back end server, at the edge of the network, or both.
• If your API accepts XML input via HTTP POST or some other way, then defend against the many types of XML attacks.  These include large inputs, payloads or attachments, ‘header bombs’, replay attacks, message tampering and more.
• Consider using data masking in a common transformation layer if your back end servers may return some data that should not be given out to all users of the API.