The Façade Proxy

KuppingerCole analyst Craig Burton (of Burton Group originally) wrote a recent article about Façade proxies. You can read the article here: http://blogs.kuppingercole.com/burton/2013/03/18/the-faade-proxy/

As Craig notes,

“A Façade is an object that provides simple access to complex – or external – functionality. It might be used to group together several methods into a single one, to abstract a very complex method into several simple calls or, more generically, to decouple two pieces of code where there’s a strong dependency of one over the other. By writing a Façade with the single responsibility of interacting with the external Web service, you can defend your code from external changes. Now, whenever the API changes, all you have to do is update your Façade. Your internal application code will remain untouched.”

I call this “Touchless Proxy”. We have been doing the touchless gateway for over a decade, and now using the same underlying concept, we provide touchless API gateway or a façade proxy.

While Intel is highlighted as a strong solution in this analyst note by KuppingerCole, Craig raises the following point:

“When data leaves any school, healthcare provider, financial services or government office, the presence of sensitive data is always a concern.”

This is especially timely as the healthcare providers, financial institutions, and educational institutions rush to expose their data using APIs to their partners.

Content/ Context / Device aware Cloud Data Protection

In this two-part blog, I am going to talk about Intel Cloud Data protection solution that helps our customers utilize their data, in both context and content-aware manner.

This is the newer set of technologies that has hit the market in the last few years. In the past, we used to think just encrypting the transport layer (such as TLS/SSL) was good enough. Given the complex nature of services and API composition, we quickly realized that is not enough. Then we moved to protect the messages (most times the entire message), or field level to protect the specific sensitive fields. The problem with any of these situations is that it is somewhat static in nature; somewhere exists a definition of what “sensitive data” is, and it is strictly enforced. While this is good, when there is a real need to send sensitive data out, yet a need to protect that, making sure only the authenticated party can receive and/or use the message is very important.

(Click on the picture to enlarge the image)

Essentially “Content/ Context Aware” data protection is data protection on steroids. Remember yester years when we used the DLP technologies, identified data leakage/ data loss based on certain policies/ parameters and stopped the data loss but did nothing about it? The problem with DLP is it is passive in most cases. It identifies sensitive data based on some context/policy combination and then blocks the transaction. While this can work for rigid enterprise policy sets, this may not work for cloud environments where you need these policies to be flexible. Well, the issue with that is when someone really needs to have that data (who is authorized for it); it is annoying to have the transactions stopped. What if there is a way to do data protection which is identity aware, location aware, invocation aware and yet it is policy based, compliance based, and more importantly, very dynamic? In other words, what if you provide data protection based on content and context awareness? Gone are the days in which you get your systems compliant, and you are done. Read my blog on why getting compliant is not enough anymore. (link here). That is because your data is NOT staying within your compliant enterprise Ft. Knox anymore; it is moving around. Getting your systems compliant, risk averse and secure, is just not good enough as your data is moving through other eco-systems, not just yours.