Context Aware Data Privacy (part II)

If you missed my Part 1 of this article, you can read it here when you get a chance (link).

As a continuation to part 1, where I discussed the issues with Data Protection, we will explore how to solve some of those issues in this article.

People tend to forget that hackers are attacking your systems for one reason only –  DATA. You can spin that any way you want, but at the end of the day, they are not attacking your systems to see how you configured your workflow or how efficiently you processedyour orders. They could care less. They are looking for the golden nuggets of information that either they can either resell or use to gain some other kind of monetary advantage. Your files, databases, data in transit, storage data, archived data, etc. are all vulnerable and will be of value to the hacker.

Gone are the old days when someone was sitting in mom’s basement and hacking into US military systems to boast about their ability amongst a small group of friends. Remember Wargames,  the movie?  Modern day hackers are very sophisticated, well-funded, often in for-profit organizations, and are backed by either big organized cyber gangs or by other entities within their respective organizations.

So you need to protect your data at rest (regardless of how the old data is – as a matter of fact, the older the data, the chances are, they are less protected), data in motion (going from somewhere to somewhere – whether it is between processes, services, between enterprises, or into/from the cloud or to storage), data in process/usage. You need to protect your data with your life.

Let us closely examine the things I said in my last blog (Part 1 of this blog), the things that are a must for a cloud data privacy solution.

More importantly, let us examine the elegance of our data privacy gateways (code named: Intel ETB – Expressway Tokenization Broker) that can help you with this costly, scary, mind-numbing experience go easily and smoothly. Here are the following elements that are embedded in our solution that are going to make your problem go away sooner.

1.       Security of your sensitive message processing device

As they say, Caesar’s wife must be above suspicion (did you know Caesar divorced his wife in 62 BC). What is the point of having a security device that inspects your crucial traffic, if it can’t be trusted? You need to put in a solution/devices where a vendor  can make assertions regarding security and have the necessary certifications  to back up those claims. This means that a third party validation agency should have tested the solution and certified it to be ‘kosher enough’ for an enterprise, data center or cloud location. The certification must include FIPS 140-2 Level 3, CC EAL 4+, DoD PKI, STIG vulnerability tested, NIST SP 800-21, and support for HSM, etc. The validation must come from recognized authorities, not just from the vendor.

2.       Support for multiple protocols

When you are looking to protect your data, it is imperative that you choose a solution that not only can handle the HTTP/ HTTPS/ SOAP, JSON, AJAX and REST protocols. In addition, you need to consider whether the solution supports all standard protocols known to the enterprise/cloud, with “Legacy” protocols such as JMS, MQ, EMS, FTP, TCP/IP (and secure versions of all of the above) and JDBC. More importantly, you also need to determine whether the solution can speak industry standard protocols natively such as SWIFT, ACORD, FIX, HL-7, MLLP, etc. You also need to look at whether or not the solution has the capability of supporting  other custom protocols that you might have. The solution you are looking at should give you the flexibility of inspecting your ingress and egress traffic regardless of how your traffic flows.

3.       Able to read into anything

This is an interesting concept. I was listening to one of our competitor’s webcasts… there was complete silence when what appeared to be a dreaded question, was asked of the person speaking on behalf of that company: “How do you help me protect  a specific format of data that I use in transactions with a partner?”Without hesitation, the presenter answered the question by  suggesting their solution lacked support for it. While I’m not trying to be unnecessarily abrasive, the point is that you should have the capability to be able to look into any format of data that is flowing into, or out of, your system when the necessity arises. This means that you should be able to inspect not only XML, SOAP, JSON, and other modern format messages. A solution should be able to retrofit your existing legacy systems to provide the same level of support. Message formats such as COBOL (oh yes, we will be doing a Y10K on this all-right), ASCII, Binary, EBCDIC, and other unstructured data streams that are of equal importance. Sprinkle in the industry format messages such as SWIFT, NACHA, HIPAA, HL7, EDI, ACORD, EDIFACT, FIX, FpML to make the scenario interesting. But don’t forget our good old messages that can be sent in conventional ways such as MS Word, MS Excel, PDF, PostScript and good old HTML, etc. You need a solution that can look into any of these data types and help you protect the data in those messages seamlessly.

4.       Have an option to sense not only the sensitive nature of the message, but who is requesting it and on what context and from where

This is where we started our discussion. Essentially, you should be able to not only identify data that is sensitive,  but take necessary actions based on the context. Intention, or heuristics, are a lot more important than just sensing something that is going out, or in. So this essentially means you should be able to sense who is accessing what, when, from where, and more importantly from what device. Once you identify that, you should be able to able to determine how you may want to protect that data. For example, if a person is accessing specific data from a laptop from within the corporate network, you can let the data go with the transport security, assuming he has enough rights to access that data. But if the same person is trying to access the same data using a mobile device, you can tokenize the data and send only the token to the mobile device. (This allows you to solve the problem where location is unknown as well. ) All conditions being the same, the tokenization will occur based on a policy that senses that the request came from a mobile device.

5.       Have an option to dynamically tokenize, encrypt, format preserve the encryption based on the need

This will allow you to be flexible to encrypt certain messages/ fields, tokenize certain messages/ fields or employ FPE on certain messages. While you are at it, don’t forget to read my blog on why Intel’s implementation of the FPE variation is one of strongest in the industry here.

6.       Support the strongest possible algorithms to encrypt, storage, and use the most random possible random number for tokenization

Not only should you verify the solution has strong encryption algorithm options available out of the box (such as AES-256, SHA 256, etc.), but you should also ensure that the solutions delivers cutting edge security options when they become available – including support for the latest security updates.

7.       Protect the encryption keys with your life. There is no point in encrypting the data, yet giving away the “Keys to the Kingdom” easily

Now this is the most important point of all. If there is one thing you take away from this article let this be it: When you are looking at solutions, make sure that not only that a solution is strong on all of the above points, but most importantly, ensure that you  protect the proverbial keys with your life. This means the key storage should be encrypted, and  should be capable of having: an SOD (separation of duties), key encrypting keys, strong key management options, key rotation, re-key options when the keys need to be rotated/expired or lost, key protection, key lifetime management, key expiration notifications, etc. In addition, you also need to explore if there is an option to integrate with your existing key manager in house such as RSA DPM (the last thing you need is to disrupt the existing infrastructure by introducing a newer technology).

8.       Encrypt the message while preserving the format so it won’t break the backend systems

This is really important if you want to do the tokenization or encryption on the fly without the backend or connected client applications knowing about it. When you encrypt the data and  preserve its format, it will not only look and feel the same as the original data, but the receiving party won’t be able to tell the difference.

If you are wondering Intel comes into the picture in this area, we address of all of the discussion points mentioned in #1 to #8, with our Intel Cloud data privacy solution (a.k.a. Intel ETB – Expressway Token Broker) and a lot more. Every single standard that is mentioned in here  is supported, and we are working on adding the newer, better standards as they come along.

Check out information about our tokenization and cloud data privacy solutions here.

Intel Cloud Data Privacy/ Tokenization Solutions

Intel Cloud/ API resource center

I also encourage you to download the Intel Expressway Tokenization Broker Data Sheet:

 

Andy Thurai — Chief Architect & Group CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 25+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can also find him on LinkedIn at http://www.linkedin.com/in/andythurai

 

Composite Distributed Applications and RESTful APIs

I was at Gartner Catalyst last week in San Diego for a luncheon keynote where I explored the concept of a composite distributed application. This is an idea that I have been chewing on for some time and is a direct result of how Enterprises are thinking about application architecture in light of “cloud” and “big data” as well as some of the trends we are seeing in our own customer base for Intel(R) Expressway Service Gateway.

First question: Where do Enterprise applications begin and end in 2012? Let’s state the obvious: the definition of an application as a monolithic piece of object code is ancient history. Let’s try the next definition, a standard n-tier shared nothing web application. This is certainly more timely, but I would also consider it dated.

If we add external cloud services, such as xPaaS (to use Gartner’s terminology) and disparate data warehouses or “big data”, located in geographically dispersed data-centers, this n-tier definition located in a single place doesn’t quite capture all of the application and may leave out important pieces. Key pieces of functionality may live “elsewhere” and this is where our standard enterprise application becomes distributed, with pieces in different physical locations as well as composite which means the inclusion of external xPaaS services such as storage, queuing, authentication or similar services.

So when we think about the larger boundaries of a composite distributed application, what are some salient properties? I came up with the following list for my talk:

Composite Distributed Application Properties

•Hybridized – Includes new feature development as well as the integration of legacy code, which can be done by integrating legacy message or document formats and protocols. In other words, Enterprises don’t want to throw out existing functionality, even if it happens to be written in a different programming language

•Location Independent- Important pieces of logic, persistence and functionality may be split across 1-n clouds, a mix of standard data center deployment, private cloud and public cloud. The application is essentially living across different clouds. All clouds can win.

•Knowledge Complete -  As traditional enterprises emulate web companies with big data analytics and web intelligence, distributed applications must access the results of “Big Data” analytics, which are possibly owned by different factions in the Enterprise. The composite distributed application will need to aggregate results and make important predictions across these sources as well as include any relevant data warehouse and JDBC sources.

•Contextual – Produces just-in-time results based on client context, device and identity. For example, the application I/O model must meet the demands of mobile devices, such as REST APIs, as well as internal enterprise stakeholders

•Accessible & Performs – Produces data compatible with any client on any operating system, with minimal latency. Scales to hundreds of thousands of users where clients are a mix of smart phones, tablets, browsers, or devices.

•Secure and Compliant - Meets compliance and security requirements for data in transit and data at rest, such as PCI, HIPAA and other requirements. This may involve a mix of traditional “coded-in” security,  security at the message level (via a proxy), standard transport level security, and data tokenization prior to analytics

Common Service Layer

A common theme of current Intel service gateway customers is the creation of a common service layer that unifies existing back-end services.What happens is that services grow organically on different platforms and operating systems, written in different languages but can be orchestrated under a common RESTful theme (for more background on REST fundamentals see DZone’s REST Reference Card paper). For instance, many of our customers have a mix of REST-style or SOAP web services and then use a gateway facade or layer to unify these. Unification, however, is only one of the requirements. The second requirement is external exposure to new clients and partners with appropriate performance, trust, threat, and increasingly, throttling/SLA features. Trending right now are OAuth and API key mechanisms, especially when the clients are expected to be mobile devices.

How does this architecture grow into a composite distributed application? This is where location can play a role: as enterprises adopt more cloud PaaS services, their existing services will grow beyond what is found in the data-center, to what is found outside the data-center.

For example, one large service provider that we work with uses Intel Expressway Service Gateway to create a facade for 50+ RESTful services. In the future as they adopt cloud, additional services may also be delivered from the cloud that fit under the facade,  so the RESTful facade and services together may all be properly called “the application”  – here the application is a mash-up of services split among clouds.

We call it “the application” because its all three pieces, the gateway, the internal services and the cloud services that comprises the pieces.  The next question here is how to secure these API interactions and ensure this new breed of application meets performance and compliance requirements.

I think the answer here is that you have to focus on the data itself sent and received at each API hop. This means more emphasis on tokenization and encryption, as well as an understanding of the relevant authentication and authorization controls and how they apply depending on who needs to access the data. For “Big Data” this may mean pre-processing map/reduce input to provide tokenization or encryption prior to performing analytics, essentially ensuring compliance prior to processing.

-Blake

Next Gen Enterprise API Architecture for Mobile

The Enterprise software industry has grown up around the standard three tier-architecture for web applications, which was pioneered circa 1995. This architecture is ideal for web browsers, which have become the universal client of the Enterprise.

With the introduction of Enterprise mobile applications, we are seeing new avenues for innovation, new user experiences and increased convenience. In some ways, however, we are rolling back the clock.

Allow me to clarify: If we accept the premise that native mobile applications deliver the best functionality on disparate mobile platforms, we are at the cusp of re-introducing “thick client” applications back into the enterprise. Native mobile applications are rich in their design and functionality but behave like monolithic applications: They provide their own persistence tier, slick user-interfaces, natively compiled code, require upgrades and updates on the client device, and utilize a mix of synchronous and asynchronous communication. Sure they use REST for communication, but is this due to historical accident?

Other than the physical platform itself (which is a smartphone or tablet), native mobile applications may have more in common with old “Win32 client/server apps” that existed before the browser revolution. Are we moving forwards or backwards?

Further, what about web mobile applications that run in the browser on the mobile device? How do they factor in? How do new technologies like HTML5 affect these types of applications? How do REST APIs affect the mobile architecture?

Is the Enterprise ready for mobile? How does the standard three tier architecture fare in light of these trends?

I try to get a handle on these issues in our new whitepaper, A Unified Mobile Architecture for the Modern Data Center

Happy Reading,

Blake

New Mobile Middleware Whitepaper

The transition from a browser-only world to the mobile app proliferation of today, necessitates a host of new considerations when it comes to securing the enterprise network.  Our latest whitepaper, “A Unified Mobile Architecture for the Modern Data Center,” analyzes the mobile application landscape and what it means for the prevalent multi-tier architecture, which for some time has been tailored around browsers as the main entry point.  As RESTful API calls surpass traditional web traffic for the largest app providers, this concern becomes even more immediate.

With the understanding that most enterprise networks are a mix of both on premise and cloud-based solutions, this whitepaper takes this viewpoint as the basis for its analysis.  Given the heterogeneity of the mobile app landscape in terms of platforms and operating systems, each with their own unique programming language and set of best practices there is an added layer of complexity in adapting existing enterprise architecture for this new mobile user base.

For the complete whitepaper on mobile middleware, click here.

Application-Aware Firewalls by Andy Thurai

You may have heard this term recently and wondered what it meant. When it comes to security, everyone thinks of Firewalls, Proxies, IPS, IDS, Honeypots, VPN devices, email security and even Web security, but most people don’t think in terms of application level security unless either you are the developer, admin, or user of those specific services or perhaps a hacker. Especially when your traditional network boundaries disappear you can’t carry all of those devices with you. When you move out of your traditional boundaries, towards the cloud, you trust the cloud provider to provide you these features. But you can’t do the same with application level security.  That is because those devices work on a level below the Application Layer (Or Layer 7 in the ISO-OSI architecture model). And those standards are very well defined and established, whereas, to an extent, the application layer is still evolving – from COBOL to API, everything is fair game.

There is a reason why enterprises are looking for devices which can do it all. I was reading a security research report the other day, which suggested that attackers are moving up the stack to the application layer since it is so easy to hack into applications nowadays; especially with the applications moving to the cloud, thus introducing new vectors of attack, including a whole layer of API/ XML threats (if you are still bound to XML/SOAP and can’t free yourself). Most of the organizations that I see don’t have the same solid security at the application level as they do at the network level. This discrepancy developed over last few years as more and more applications came out with new technologies exposing themselves to newer threats. Plus there is no unified standard amongst developers when they develop application level security.

The network security we have today is not “application aware”. This means that API/XML and other application level threats go right through the regular network defenses that you’ve built up over years. Many people think that if they use REST or JSON then they are not as prone to attacks as those who are using SOAP/XML/ RPC, which is a funny thought.

Add this to the fact that when your applications move your enterprise boundary to go to a cloud, they are exposed to hackers 24×7 waiting to be attacked.  This leaves you subject not only to direct attacks on your application, but also to bounces off another application that is hosted in a multi-tenant environment. So your new “firewall” should be able to inspect, analyze application traffic, and identify threats. But the issue doesn’t stop here; you also need to analyze for viruses, malware and the “intention” of the message (and its attachments) as they pass through. Most times the issue with Firewalls inspecting traffic is that they look at where information is going (port and maybe an IP address), but not what the message is intended to do. There is a reason why injection attacks such as SQL Injection, XSS, Xpath injection all became so popular.

Now there is another issue, and this relates to the way applications are built nowadays. In the olden days you controlled both the client, the server, and even the communication between them to an extent. Now we expose APIs and let others build interfaces, middleware, and the usage model as they see fit. Imagine a rookie or an outsourced developer developing a sub-standard code and putting it out there for everyone poke and prod for weaknesses.  As we all know, the chain is as strong as the weakest link. A problem arises because it is hard to figure out which is your weakest link. So application-aware firewalls can not only inspect, analyze or control traffic to applications, but also utilize inherent knowledge allowing them to work at a deeper level too.

This gives you freedom to move the necessity of application level security from your applications/ services/ API to a centralized location, so your developers can concentrate on what they are supposed to do – develop the services that matter to your organization and not worry about other nuances, which can now be left to the experts.

This is where Intel/McAfee comes into play. We have solutions that can help you build solid applications/services/ APIs and insulate and abstract the ancillary services in a centralized or de-centralized location, and manage them globally. Our solutions allow you to abstract application security, mobile middleware, data mediation, message transformation, message routing, Quality of Service, Service Level based enforcements, protocol mediation, application firewalls, Web App Firewalls (WAFs), etc. in a standards-based fashion thereby freeing your developers.

Check out our solution set Intel ESG (Enterprise Service Gateway), McAfee MSG (McAfee Service Gateway), McAfee MWG (McAfee Web Gateway), Intel API Gateway which will all help you take your Enterprise and Cloud services to the next level.

http://software.intel.com/en-us/articles/Expressway-Service-Gateway/

http://software.intel.com/en-us/articles/Cloud-Service-Brokerage-API-Resource-Center/

http://software.intel.com/en-us/articles/REST-Web-Services-API-Security/

http://www.mcafee.com/us/products/services-gateway.aspx

http://www.mcafee.com/us/products/web-gateway.aspx

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can find him on LinkedIn at http://www.linkedin.com/in/andythurai.

What You Need to Know about API Security

Since the growth of APIs “hockey-sticked” around 2005, the proliferation of web-based APIs has spanned every industry and vertical from e-commerce to map services to enterprise. APIs like that of Twitter, Amazon, and Netflix garner billions of API calls every day, and these represent just a few of the more visible.  With this rapid growth, on the order of 300-400 new APIs arriving each month, security is an ever-increasing concern.  Enterprise focused, SaaS based APIs are among the fastest growing segments, and in light of this, securing company assets and Data Loss Prevention are paramount.  The perimeter of enterprise networks has become amorphous as workflows increasingly leverage platforms and applications beyond the firewall.  So what does that mean for your organization’s security?

Attend our May 10^th webinar featuring Intel, McAfee, and tech analyst & CTO, Dan Woods for an advanced perspective on what you should do to ensure API Security, specifically as related to Authentication, DLP, and Validation Controls.

 For more information about Intel Expressway Service Gateway — with free webinars, tutorials and expert blogs on securely exposing Web Services in the Cloud, please visit us at: www.intel.com/go/identity

Andy Thurai on, “the API – You Can’t Live Without It”

The unprecedented explosion of modern technologies combined with a burgeoning mobile space has forced enterprises to rethink previously held beliefs about the static enterprise perimeter. Remember the olden days when you said your enterprise was completely self-contained in one data center, with your apps inside the firewall and with everyone nearly as confident about it as being as secure as Ft. Knox?  With an explosion in mobile computing, demand for cheap or “free” usage of resources, and a sharp reduction in cost with the cloud delivery model,  it is expected (or rather demanded) that every enterprise expose their APIs not only from their enterprise but from a cloud based model. (NOTE:  The cloud is referred to in a  loosely defined delivery model be it —  public, private, community or hybrid variety).

Couple this inexorable progression for having a cloud based model with the need for mobile enablement and web 2.0 technologies,  and you are forced to expose not only your SOAP APIs,  but also JSON, REST and other fast, quick TTM (time to market) APIs that can be easily manipulated and consumed.

This brings an interesting issue to the fore-front. You are forced to rethink your corporate security strategy. Many organizations (and the C levels that I speak with on a regular basis) are scared to move their sensitive applications (and processes, data) to the cloud, mainly, because of security. But that doesn’t stop them from exploring and moving some of the non-sensitive applications to the cloud and “testing the waters”, so to speak. Once they see how easy and cheap it can be, they begin losing sleep thinking about all of the money they can save by moving everything to the “cloud” due to the constant pressure to plan and come in under budget.

It’s no wonder that API traffic has exploded over the past few years. According to a recent survey, about 60% of the enterprise traffic is API based. According to Programmable Web,  75% twitter traffic is API based. According to Programmable Web there are at least 5000+ APIs (http://blog.programmableweb.com/2012/02/06/5000-apis-facebook-google-and-twitter-are-changing-the-web/) and the pace is growing. Programmable Web has a neat tool where you can search all the publicly available APIs (http://www.programmableweb.com/apis/directory). If you check this out you will immediately notice that most of the social APIs are mostly REST/ JSON based. There is obviously a good reason for that.

When it comes to APIs there are two distinct, broad categories – Social APIs and Enterprise APIs. The Social APIs are created by, and for, our society which is hungry for instant data updates. (Remember the AT&T 4G commercial “so 42 seconds ago”  (http://www.youtube.com/watch?feature=player_embedded&v=bvVVQGgbKk0) . I miss the good old days where we found out what happened in the world by checking CNN website once an hour or so.

In general, the social APIs tend to be fast,  easy to implement, REST only — without any enterprise class security, not monetized,  and focused on publishing  content etc.

You can’t afford to have the enterprise APIs published and consumed the same way. Your Enterprise class security needs to move with your applications API wherever it is going or however it is accessed.  And it is not a question of if, it is a question of when. The success of companies with API as the core of their business models transformed the industry – look at Google, Twitter, Facebook, and other smaller players. According to Programmable Web “The most popular API category from the last 1,000 APIs is government. In total, we list 231 government APIs and nearly half of them have been added in the last four months.”  When the government adopts a technology standard, you know that there is no going back, it is here to stay forever .

As applications migrate out of your own “Ft. Knox”,  the issue will become more pronounced. You’ll still need the same quality of security, management, SLAs,  centralization of usage based information – predicated on policy & identity information.

Most cloud providers just give you the base platform and leave most of this to you.  However, your enterprise class APIs need to provide enterprise class security, governance, lifecycle management , API Key and credential management, throttling and quota management, security, protocol translation and versioning, API performance optimization, key management, discovery. The need to expose your APIs in  multiple formats (as talked above such as REST, JSON, SOAP, etc), can multiply the complexity of an implementation exponentially.

Having set the stage (without wanting to scare you about the inherent risks of exposing your APIs to the cloud), let’s talk about how Intel can help you effortlessly achieve all of these things regardless of your usage model –  without the need to be concerned about whether  APIs are REST based, or full SOAP APIs or even JSON based mobile APIs.

Intel has been in the Web Services, XML, SOAP security space since the acquisition of Sarvega (circa 2005).  Our expansion into the API security space has been a natural progression. We brought out an API security gateway last year which caught the attention of many of our customers. Especially given that it can help enterprises move enterprise grade security policies without having to rewrite the policies (and allow for subsequent enforcement of them in the cloud) makes it even more interesting.

With the addition of OAuth 2.0 to the API gateway in our latest release, it seems like a timely opportunity to talk about the capabilities of our API gateway. When you move your enterprise applications to the cloud and expose APIs from there,you can either retool your application to fit that platform/ delivery model . Or, you have a second option. Use our API gateway as the API middleware which can help you solve a lot of those issues. APIs have become strategic control points for the cloud.

So essentially you want to abstract the following functionality to API middleware:

1. Keep your implementation technology agnostic. Provide a mechanism to support REST, JSON, SOAP, etc and mediate to the backend supported format in a non-intrusive manner. Most times this end result can be achieved by configuring the API gateway solution to act as a facade to the existing application. This is really important in the ever changing API world.  JSON, REST APIs have evolved in the past few years.  By being agnostic, you’ll be prepared for the next “flavor” in whatever way that instantiates itself.
2. Keep your security and API management closer to your APIs and be transparent about it with your  customers.
3. Remove security, scalability, management and audit functionality and issues away from the an actual API implementation.
4. Ensure that you have strong API monitoring, metering, logging, auditing, & versioning features.

Check out our API Gateway details to see how we can help you make this migration easy and painless.

http://software.intel.com/en-us/articles/Cloud-Service-Brokerage-API-Resource-Center/

For more information about Intel Expressway Service Gateway, case studies, testimonials and tech tutorials, please visit www.intel.com/go/identity

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel. Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role he is responsible for helping Intel/McAfee field  and technical teams and customer executives. Prior to this role he has held technology and architecture leadership and executive positions with L-1 Identity Solutions, IBM Datapower, BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

Andy Thurai on “Social SOA with API Gateway”

In a recent conversation with a large customer of ours, some interesting facts came to light. This blog is a recapitulation of the insights I got from that discussion. I’ll not only tell you how this customer is using our solution, but also, how it is helping them to take their online presence to the proverbial next level.

Our customer, an online university, is using our solution, as middleware – providing both security and data mediation functions, to push through SOAP &  REST API transactions to the backend. They are processing about 18 million messages per day. Now think about that for a second. The number in itself is mind staggering. While most educational institutions use freeware middleware solutions due to being part of an ultra cost-conscious milieu, this University decided to use our solution to bring their presence to a whole new level  – while still doing so in a completely cost effective fashion.

We also helped the University  integrate with a home grown single sign-on solution fairly easily so they would not be forced to “rip and replace” all of their technology,  unlike some of the implementation plans that would be thrust upon them by some of our competitors.  We integrate with identity management systems,  as well solutions that address governance, various registries ,and an array of monitoring solutions.  For us, it’s never about pushing an entire stack to a customer. Instead we feel customers should have the latitude to choose a technology from a range of available options, consistent with a “best of breed approach.”

Though it initially started off as more of an academic security experiment for a University, our solution has been embraced much more widely and has grown into a solution that encompasses SSL offloading, XSLT transformation, service aggregation, and service mediation. In addition, our solution is being used to abstract the authentication layer to communicate with a custom authentication service. We provide the backbone of their social SOA.

The initial services were mostly SOAP based, however, when the REST services were ready — we were ready too,  to help them out with a product that similarly could address all of the same relevant security concerns.

The true reason everyone is excited, though, is  because the University is looking to move their service offerings to the cloud.  At first glance, moving all your services (or even just a service abstraction layer) to the cloud and exposing that 24×7 to hackers can be quite the daunting task!  Another concern revolves around their customers’ resource utilization.  Especially when you are offering your  services for free (at least most of the time,) if you expose those services without throttling  them,  can be asking for a lot of trouble. Rest assured —  Intel has a feature built in our solution set that will help them with both their security concerns and their ability to implement throttling .

Our Quality of Service (QOS) functionality allows service providers to limit the usage of services, a classic need in a cloud delivery model which is often overlooked due to the perception about the elasticity of the cloud. In my mind, just because you can throw resources without any limit – ignoring fundamental architecture design principles such as TOGAF, DoDAF, Zachman – should be a huge concern, and “top of mind” for everyone. While you can implement some of these functions at the application/services level,  , a lot of overhead will be added to the application itself.  Moreover, here will be no uniformity across applications on how this feature is implemented.

If, on the other hand, you  were to use our QOS functionality -   you can monitor API usage, meter the usage based on the identity of the user (technically,  not only based on the identity, but you can even go lower than that. Think more along the lines of something location + identity + invocation based).

You not only can limit the service usage based on predefined policies,  but you can enforce those policies globally.  Our solution provides for the ability for a backend application to recover in case of overload. This built-in “self healing” feature should allow many services to recover without a need to bounce / reboot often. And the built-in auditing, reporting, logging tool keeps extensive details so it can be used not only for a forensic analysis, should the need arise,  but also when implementing a charge back system if so desired.

For more information about Intel Expressway Service Gateway, case studies, testimonials and tech tutorials, please visit www.intel.com/go/identity

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel. Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role he is responsible for helping Intel/McAfee field  and technical teams and customer executives. Prior to this role he has held technology and architecture leadership and executive positions with L-1 Identity Solutions, IBM Datapower, BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

McAfee Adds Two New Solutions to Cloud Security Platform

We are excited to announce the latest additions to the McAfee Cloud Security Platform – McAfee Services Gateway and McAfee Cloud Identity Manager. Developed with Intel, these new products add breadth and depth to the McAfee Cloud Security Platform, extending McAfee security to Web Services and to SaaS access management.

McAfee Services Gateway provides a layer of security, control, and management for application-to-application traffic (e.g., SOA or REST). More than just middleware, an XML Gateway, or an XML firewall, Services Gateway delivers a unique set of features tailor-made to integrate, mediate, secure, and scale services in a dynamic application perimeter.

McAfee Cloud Identity Manager enables total control for the entire lifecycle of cloud-based applications. In addition to providing convenient Single Sign-on for users, it provides automated provisioning for SaaS applications, strong authentication based on policy, one-time password and two-factor authentication capabilities, as well as consolidated logging and audit trails for user SaaS access.

For more information on these products, check out www.mcafee.com/cloudsecurity.

Essential Elements of API Management

Here’s a question – do we really care about SOAP or REST any longer? With the advent of cloud and the increased focus on the rapidly changing software consumption model, it seems like Enterprises should come full circle back to API. What do I mean by API in this context? Yes, it’s a programming interface, but as I’ll argue in this post, it’s a generalized programming interface accessible over HTTP. I’m not talking about a .NET DLL or Java RMI interface here.

General interfaces can be implemented in a few ways and the specific implementation (while important) is no longer the salient aspect. Instead, the goal for an Enterprise is how to manage such an API, how to secure it, how to scale it and make it work for the business.

API management, then, is about securing, managing and auditing an increasingly important Enterprise I/O point, one that has enormous potential to connect and expand the Enterprise to new customers through all manner of technology including smart-phone applications, browsers, middleware, legacy applications and just about anything that can talk HTTP.

I also think that this focus on API management is historically connected to SOA and services. Here is how I think we got there:

• First, behind the firewall “SOA” brought low-cost, HTTP-based standard SOAP APIs into the Enterprise mindshare. Rather than thinking in terms of RMI, we can think in a platform independent way and expose interfaces outside the Enterprise.
• Then, Web 2.0 trends and the REST hype coupled with the use of the “WS-* complexity backlash” (new term!) brought REST APIs into the Enterprise mindshare, but Enterprises continued to use SOAP because REST lacked a coherent security model
• Next, the cloud consumption model begins to emerge and software service providers such as Salesforce.com and Amazon want thriving developer communities. Unmarred by any previous history, they offer both SOAP and REST APIs (aka ‘query’ APIs).

If we compose these previous events they lead to a conclusion that moves the discussion from SOA to Services to APIs. I will argue that what Enterprises care about is how to manage API connectivity outside their organization and leave it up to the technology providers to not only make the piping work, but also make it secure, reliable, cheap, scalable, standards-based and compliant. At Intel, we have the concept of a service gateway or enforcement point specifically for this.

From what we’ve seen, there are three conceptual usage models centered on three actors: Enterprise, Service Provider, and Consumer.

The Enterprise is a traditional enterprise normally thought of as one that exposes services to other enterprises for some B2B transaction. Service providers are the term I use to describe a software service provider such as Salesforce.com or Amazon, which expose different types of services (IaaS, PaaS, or SaaS), and Consumers can be end-consumers with a smart-phone, a developer, or thick client.

 

API Management Use Cases

The three use cases are:

1. Enterprise Edge Security – Here the enterprise wants to securely expose services to business partners, with a focus on authentication, auditing, and perimeter security for B2B transactions. A variation on this case is a set of enterprise services exposed to customers, consumed through a tablet or smart-phone. Here is a conceptual picture of the use case with a gateway shown as a control point for the API

1. API Security – Here the service provider wants to securely expose services to customers and developers, with a focus on quality of service enforcement, authentication and API mediation

1. Hybrid Cloud Gateway – This category has three important sub-usage models:
1. Data Gateway – Here the enterprise wants to securely utilize a service provider like Amazon, Microsoft or Google as for additional platform-level services such as queuing and storage. Here the focus is on quality of service enforcement, data protection (encryption/tokenization), authentication and attack prevention
2. Control Gateway – Here the enterprise wants to securely utilize a service provider like Amazon EC2 or Rackspace to as a way to spin-up and spin-down additional server capacity and enforce authentication, authorization and quality of service enforcement on access to external, hosted virtual machine instances.
3. Hosted Edge Security – Here the enterprise deploys a service at a cloud service provider and needs Enterprise class security on the exposed API. Focus is on authentication, attack protection, secure migration and policy consistency between the service provider and Enterprise.

 

The hybrid cloud use cases are shown in the following diagram.

Use case (a) is the conceptual deployment for a control or gateway gateway and use case (b) is the case where an Enterprise is beginning to externally host their infrastructure on a cloud service provider. Here, the gateway is augmenting the API management capabilities provided by the cloud service provider and allowing policies to migrate from the Enterprise to the cloud.

It should be emphasized that there are many, many variations to case (b). Sometimes, the applications themselves are created using the cloud service provider’s own infrastructure, such as Microsoft Azure or Google Apps engine (PaaS). In other cases (depicted in the diagram), it’s Enterprise middleware or other systems migrated to the cloud and hosted (IaaS) with a requirement for Enterprise security policies.

It’s also clear that some of these variations are more speculative than others – it’s an open question whether Enterprises will be willing to risk migrating their core information systems and business processing to the cloud. This is really the big question on everyone’s mind – how much can Enterprises risk today and what can they do to minimize this risk? We think that a service gateway can help minimize this risk, but the Enterprise must place a high degree of trust in the cloud service provider.

These are the three cases that we’ve come across. Notice that the issue of API type is really not at the forefront – any of these could be done with a SOAP/XML, REST/XML or REST/JSON implementation style. What is needed is a way to control and secure these exposed APIs – which is the topic of API management.

I’d love to get comments on this idea and especially new usage models. In some upcoming blogs I’ll be expanding on these and then trying to get into specific details.

-Blake