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.

Federal CIO VanRoekel details his ‘first’ priorities

With nearly three months on the job, federal chief information officer Steven VanRoekel is revisiting some long-standing technology priorities.

VanRoekel gave his first major policy speech recently, since taking over for Vivek Kundra in August, signaling how he plans to move the administration’s IT reform ball forward.

In this Federalnewsradio.com post, read about how:

• OMB will promote “Share first” policy –The Office of Management and Budget will begin promoting a “share first” policy. VanRoekel said the idea is to have agencies look to others when buying technology or upgrading systems before going off on their own.
• “I envision a set of principles like XML First, Web Services First, Virtualize First and other firsts that will inform how we develop our Government’s systems.”
• “All of these elements are really grounded in the foundation that is cybersecurity.”

 

 

 

Toward these goals, you can deploy Intel Expressway Service Gateway, a purpose-built cross domain service gateway that enables secure collaboration amongst agencies.

You can address perimeter defense with wire speed XML threat protection, complex security policy enforcement and ready multi-factor integration to identity infrastructure.

And you get the Intel advantage since Intel Expressway Service Gateway has been engineered to take advantage of Intel hardware optimizations to deliver best in class performance and hardened, high-assurance security.

Please reach out to us at  intelsoainfo@intel.com or call 978-948-2585 if you need assistance.

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

Radian Uses Intel Expressway Service Gateway to Power Data Transformation Security

Radian, a national provider of private mortgage insurance and risk management products  is discussed in a new case study involving Intel Expressway Service Gateway.  Radian looked to Intel to help build an architecture that utilized XML as a common format for back-end systems, while separating policy enforcement and data transformation from back-end systems in a dedicated security and transformation layer.

Read on to learn more about how Radian is benefiting from simplified integration security with a scalable solution and lower total cost of ownership (TCO).

Click here to download this case study.

Trusted Client to Cloud Access

Cloud computing has become an integral part of all IT decision making today across industries and geographies. This market is growing at a rapid pace. By 2014, IDC expects public cloud spending to rise to $29.5 billion growing at 21.6 percent per year. At the same time, Forrester predicts the cloud security market to grow to $1.5 billion by 2015. This is good news, yet there are many CIOs sitting on the fence and not jumping on the opportunity cloud computing presents as they worry about security of data and applications. The figure below lists survey results from top CIOs when asked about their top of mind concern for using cloud services by TechTarget.

Loss of control, Compliance implications, and Confidentiality and auditing topped the results. Under these 3 themes, the issues they listed are:

•          They find it hard to trust cloud providers security model

•          Manage proliferation of user accounts across cloud application providers

•          Extended enterprise boundary complicates compliance

•          Shared infrastructure, if the cloud gets hacked so do you

•          Audit log silos on proprietary cloud platforms

This blog post lists a potential solution to address these issues and more.

Security Layers

First, lets look at the various layers that are required to secure cloud applications and data.

You need to protect applications and data for assurance and compliance, access control, and defend against malicious attacks at the perimeter. Yet, the weakest link remains the client as malware and phishing attacks can send requests as if it were coming from a human user. To achieve end-to-end security, you need to look holistically at how to provide “trusted client to cloud access”. You can watch a webinar on this topic I recently did with security expert Gunnar Peterson.

Solution

One solution to this problem is to have a trusted broker that provides the glue between client security and cloud security. It should be able to determine if cloud applications are being accessed from trusted and attested client devices or not, and block access from all non-trusted clients. One way to get client attestation is through Intel® Identity Protection Technology (IPT) which embeds 2^nd factor authentication in the processor itself.

While a trusted broker enforces above check it should also be able to provide supplemental security on top of what cloud applications provide by offering:

• Federated Single Sign-On (SSO) using industry standards such as SAML, OAUTH and OpenID
• 2 factor strong authentication with convenient soft OTP token support
• Elevated authentication (term to represent step-up authentication on a per request basis, coined by Mark Diodati of Burton group in his latest report on Authentication Decision Point Reference Architecture)
• Automated account provisioning and deprovisioning with automated identity attribute synchronization to ensure that all identity attributes across enterprise and cloud applications never go out-of-sync
• Centralized audit repository with common audit record across cloud applications
• Orphan account reporting to catch unauthorized account creation by administrators in cloud applications
• And, a single dashboard to get 360 degree visibility on how cloud applications are being accessed by users (aka user activity monitoring)

Such a “Trusted Broker” software can insure that Enterprises adopt cloud applications providing tools to achieve “Control, Visibility, and Compliance” when accessing cloud applications. View  more on Intel’s solutions in this space.

Industry initiatives

Cloud Security Alliance (CSA) is working feverishly to provide awareness and guidance with reference implementations to address some of the security concerns listed earlier in this blog post. At the CSA summit 2011 held at RSA conference 2011, I presented a roadmap for Trusted Cloud Initiative (TCI) which is one of the sub groups of CSA. In it’s reference architecture, TCI lists the following use cases for trusted access to the cloud.

TCI also published a whitepaper covering identity and access control for cloud applications.

Summary

While cloud application providers continue to enhance their security posture, it’s in the best interest of enterprises to supplement it with additional security controls using technologies such as “Trusted Broker” that enable end-to-end secure client to cloud access and provide 360 degree visibility and compliance into how various cloud applications are being accessed by enterprise users. One such implementation of a “Trusted Broker” is provided by Intel Expressway Cloud Access 360 product. Visit http://www.dynamicperimeter.com to learn more.

Vikas Jain, Director of Product Management for Application Security and Identity Products with Intel Corporation has over 16 years experience in the software and services market, with particular expertise in cloud security, identity and access management, and application architecture. Prior to joining Intel, Vikas has held leadership roles in product management and software development at a wide-range of technology companies including Oracle, Oblix, Wipro and Infosys. You can follow him on twitter @ VikasJainTweet

Securing the Extended Enterprise with Bi-Directional Protocol Handling

Large Enterprises face a constant challenge in balancing technology costs with new business goals. Many enterprises have existing business processes bound up in applications that communicate using ‘legacy’ protocols such as FTP and MQ, which were really designed for behind the firewall operation in a trusted network. Given these constraints what’s the best way for a large Enterprise to extend these applications to external customers and partners without relying on an expensive re-engineering effort or concentrating risk in a single vendor?

One option is to use a security gateway such as the Intel® Expressway Service Gateway to centralize security policy deployment, increase performance, reduce development costs, and simplify the architecture. In this post, Blake Dournaee describes a recent customer use case for a Service Gateway that highlights the value of this class of products.

http://software.intel.com/en-us/blogs/2011/01/28/beyond-the-simple-proxy-using-a-service-gateway-to-secure-the-extended-enterprise-with-bi-directional-protocol-handling/

 

 

 

Visit us at HIMSS Healthcare IT Conference and Exhibition in Orlando February 20th-24th

Join us at HIMSS11 – Healthcare IT Conference and Exhibition and learn about the first purpose-built SOA integration appliance for healthcare.

The event is taking place Februay 20th – 24th at the Orange County Convention Center in Orlando, Florida.

We’ll be in booth #2963.

Intel^® SOA Expressway for Healthcare delivers best-in-class performance, open standards, and simplified security. It provides real-time, accelerated message processing, legacy connectors, and service enablement capabilities to power best-of-breed Health Information Exchange solution architectures for systems integrators, governments, health plans, and large providers.

 

 

Infosys on Service Oriented Architecture

Check out this interesting blog written by an Infosys Architect comparing hardware SOA appliances to software SOA appliances.  The author takes a stab at summarizing the differences, and makes some comments about Intel’s SOA Expressway. Just thought I’d chime in here and help flesh out the picture and add a few words from my own perspective being that I’m on the Intel team. SOA Expressway is a Service Gateway that complements and augments middleware products from any vendor.

And While middleware, BPM, and ESBs are good solutions for service mediation within a specific domain…it’s been our experience that customers have trouble scaling ESB products across domains to the edge of the network where they tend to have security and performance security gaps. It should be noted that ESBs can perform security policy enforcement but generally require additional plug-ins as well as code development.

Service gateways enable services to be composed for sets of ESBs, BPM systems and middleware deployed across different domains in the Enterprise. Service Gateways are deployed for cross-domain service mediation, threat prevention, security policy enforcement, AAA functions and are generally used for shorter-running transactions.

As for deployment models, the preferred way to deploy two gateways, one in the DMZ for threat prevention, external user authentication and application security, generally in a hardware appliance form factor and then a second gateway (software or hardware) closer to the middleware for trust functions, acceleration, and non-XML format handling.

If you have any questions and want to learn more, please don’t hesitate to email me at  jeffreyx.m.goldberg AT intel.com . Definitely take the time to visit www.dynamicperimeter.com for more info.

http://www.infosysblogs.com/soa/2010/11/soa_appliance_-_opportunities.html

 

 

 

Just thought I’d chime in here and add a few words from my own unique perspective being that I’m on the Intel team. SOA Expressway is a Service Gateway that complements and augments middleware products from any vendor.

 

While middleware, BPM, and ESBs are good solutions for service mediation within a specific domain…it’s been our experience that customers have trouble scaling ESB products across domains to the edge of the network where they tend to have security and performance security gaps.

 

It should be noted that ESBs can perform security policy enforcement but generally require additional plug-ins as well as code development.

 

Service gateways enable services to be composed for sets of ESBs, BPM systems and middleware deployed across different domains in the Enterprise. Service Gateways are deployed for cross-domain service mediation, threat prevention, security policy enforcement, AAA functions and are generally used for shorter-running transactions

As for deployment models, the preferred way to deploy two gateways, one in the DMZ for threat prevention, external user authentication and application security, generally in a hardware appliance form factor and then a second gateway (software or hardware) closer to the middleware for trust functions, acceleration, and non-XML format handling.

 

 

 

 

 

How to Protect against the 2010 — OWASP Top 10 threats to Web Applications

The Open Web Application Security Project (OWASP) maintains and publishes an ongoing list of top ten threats to web applications. With few exceptions, the threats listed in the OWASP top ten can be applicable to any service, be it a web application, REST service, SOAP service or custom application.  Read along point by point as Blake Dournaee, Product Manager for Intel SOA Expressway Service Gateway goes through the risks for 2010 and see how these are addressed with Intel(R) SOA Expressway, Intel’s service gateway product.

http://software.intel.com/en-us/blogs/2010/11/09/using-a-service-gateway-to-protect-against-the-owasp-top-10/