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.

Perfection Series: Forgotten Data in your Logs (Log Redaction Service) by Andy Thurai

From a business standpoint, leaking sensitive information into your logs is not only bad, but could lead to compliance, liability, and risk disaster sooner than you think. While there are solutions, including DLP, out there to inspect the data traffic and help capture sensitive data leakage, not many solutions out there are proactive and intrusive enough inspect the backplane of your systems for sensitive data leakage or regulatory compliance analysis. This becomes more pronounced when you have multiple ways that you allow users (especially the admin users) to access your system – such as browser, command line, XML interface, etc. You need to worry not only about the logs for each of these interfaces, but also the types of logs that are kept and where they may go in the future; i.e. – records such as trace log, transactional log, exception log, command log, admin log. etc.

Recently Intel/McAfee Service Gateway (ESG/MSG) have seen a lot of activity and interest in providing API services in/from the cloud. One of the major issues, faced was that the log, which is stored in the cloud, might contain information that is sensitive or a compliance issue, especially when you offer this as a service (SaaS) and exposed 24×7 to the hackers in the cloud. While this detailed logging may not be an issue for the enterprise customers that keep the actual log information in a centralized secure storage, most times this becomes an issue when you offer a multi-tenant environment and share resource with other users.  In order to provide more control to the customers in the cloud, we introduced a new log redaction feauture, which can be used either in the enterprise version or in the cloud version. This helps customers with sensitive information such as PAN data (especially with credit card information), personal data PII, names, addresses, SS#, DOB and other pertinent information including passwords in verbose modes. Intel’s solution allows that data to be removed/masked with ease and it is user definable, both for patterns and for masking specifics.

I was talking to a customer of mine few days ago on this very topic and I told them how cool this is. He replied, “I think our system is very secure and we have taken ‘extra measures’ given that they deal with multiple compliance standards and issues.” So I suggested to perform a log spider scan. He called me 2 days later panicked with what he found. If you don’t know whether you should worry about this or not there are spider scan tools available on the net, just Google it and see what your logs tell you. If you don’t like what you see don’t blame me .

While most customers take extra care of their transactional messages, I have seen a lot of customers a bit lax in regards to logging and administrative interfaces. I recently blogged about an incident with a customer with exposed data in the logs which you can read here.

Our solution allows them to tighten their logs up multiple notches. It comes with about 30 or so pre-defined filters, with an option for customers to build more on their own, using a simple visual tool. It can be applied to any level of logs including the most verbose levels. The masks are user defined and are flexible. Once you turn them on, define them, there is no need to restart your system, it is always on after that until you explicitly turn it off. What is even cooler is that the logs would be instantly cleaned once you push the config, and the push is cluster wide into all node points. Imagine the power of controlling the sensitive log data in all edge devices (whether Enterprise edge or extended to the cloud) in one push of a button.

In reality, the logging system normally logs the content given from many different underlying components, such as from input server, invocation agent, runtime workflow, mediation engine, security engine, etc. This makes it complicated to manage with so many components. For instance, when you log things from the input side (at some verbose log levels, such as detailed trace), it can log the wire data which can be anything (imagine that most solutions out there log everything that comes on the wire for auditing purposes). So it is very hard to prevent the sensitive data from being logged without special handling, contrary to what you may think.

Imagine if you are dealing with PCI, HIPAA, etc and have an edge device to define, saying I need my logs to be cleaned of said sensitive data and define masking/encryption on transactional data as well. You can be sure that from your edge inside, or going out, your message and logs are all cleaned to your satisfaction and for compliance.

If you need more information on this or on our solutions in general please check out www.intel.com/go/identity or reach out to me.

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.

Perfection Series: “Data Loss Prevention – Taking it to the Next Level with McAfee DLP Integration in Stopping Data Leakage” by Andy Thurai

Intel recently announced that by combining the strength of Intel® accelerated processing and McAfee® enterprise-level security we are taking our solutions to the next level and help our customers to extend their applications far beyond the traditional perimeters in a very secure manner.

I had a privilege of a preview to our integration between the Enterprise Service Gateway (ESG) and McAfee DLP (Data Loss Prevention) and it was amazing. I am so excited and wanted to share with you some of those features and what you can expect in coming releases.

McAfee DLP is a data leakage solution that safeguards business critical information by scanning the network for sensitive data and ensuring that it doesn’t leak outside the corporate network. It also offers pre-configured policies for HIPAA, PCI, etc.

ESG is a Swiss army knife, which can be used as a secure gateway, XML Firewall, application level gateway, identity mediator, Web Service proxy, edge security device, etc.

Obviously this applies only to data in motion and not for data at rest. What is more interesting is that it is policy driven and can be identity based or role based. Now, that is powerful.

The ESG is in the line of traffic and sends the messages to DLP to find out if any part of the message is considered sensitive. If the message is considered sensitive then it can be terminated. Keep in mind it could apply as a reverse proxy as well for the incoming messages if you want messages containing certain sensitive information to enter your enterprise for compliance, auditing reasons.

 

As you can see, integrating with a DLP is as simple as dragging the DLP action item and dropping it in the palette.  Once you’ve done this, enter the host/port and any other relevant information and your workflow is DLP activated. Essentially this means all of your edge devices can be connected to one central place to scan for outgoing sensitive information to stop sensitive data leaks. Now imagine the power of that. All of your edge devices – whether it is Application Firewalls, Web Gateways, XML Firewalls – can all be connected to a central place, which can scan your outgoing (and incoming if necessary) messages for sensitive information based on corporate policies and compliance requirements.

The great thing is you can start building policies as needed. McAfee DLP has functionality is known as capture. Using McAfee capture technology you can not only look for data, but you can capture all the data that is going out.  The captured data helps you see real world patterns of data usage and possibly replay this history to adjust and refine your scans.  This provides the comfort and confidence that you are aware of planned and new threats as they evolve.

We integrated with McAfee DLP, not just to show off that we are part of a bigger security organization, but also because this is a top notch solution available in the market. As you can see in the picture below by Gartner and Forrester the analysts agree.

 

 

 

 

 

I hope you will be as excited as I am when you see this solution in action and see how easy it is to configure and use (and re-use).  If you need more information on this or on our solutions in general please check out www.intel.com/go/identity or reach out to me.

 

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/andythuraiandythurai.

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

Intel Expressway Outpaces IBM DataPower by 6x to 10x in a Direct “Apples to Apples” Comparison

Prior to the release of Intel’s XEON processor E5-2600, Intel Expressway Service Gateway (also available as McAfee Services Gateway under the McAfee Cloud Security Platform Suite) was already providing superior performance and value. However, with the record breaking E5-2600 – delivering leadership performance, best data center performance per watt and break through I/O innovation, the distance between — front-runner Intel, and IBM WebSphere DataPower XI50 has  increased dramatically.

Our customers can take advantage of continuous chip improvements with the easily upgradeable software appliance form factor. Intel Expressway Service Gateway outpaces IBM DataPower by 6x to 10x in a direct “apples to apples” comparison at a fraction of the total cost.

Read this performance comparison report to learn all about it:

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

The Fast Track on 3 Use Cases for a Service Gateway as Part of Your Cloud Strategy

How does an Enterprise with a hybrid cloud strategy use emerging platforms such as PaaS and IaaS?

This is one of several questions that Intel Product Manager Blake Dournaee will help answer in this short 5 1/2 minute video. When utilizing those platform services for API communication, you need to typically worry about perimeter defense, Authentication Access Control and Authorization (AAA), Data Protection, Auditing, and Visibility as transactions move from the Enterprise to the Cloud.

Watch this short video and quickly ramp up on 3 use cases for a Service Gateway and how it can address all these domains of concern. Learn how a Service Gateway can act as a single control point and provide the necessary visibility when using PaaS or IaaS. Also learn about the Cloud API management  and Cloud Service Brokerage usage models.

For more information about Intel Expressway Service Gateway (also available from McAfee as McAfee Services Gateway), please visit: 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.

Intel Expressway Service Gateway deployed at DoD for Cross Domain Sharing

Have you read the latest case study involving a top defense contractor that deployed Intel^* Expressway Service Gateway at the DoD?

The top contractor deployed Intel Expressway Service Gateway to secure data sharing and achieve wire-speed content attack prevention, provide support for multiple message formats without the need for custom programming and lower their cost and time to implementation.

You can learn more about Intel Expressway Service Gateway and the other Intel Expressway products by visiting www.intel.com/go/identity

 

 

Visit Intel at HIMSS 2012

As HIMSS 2012 approaches  (Feb 20-24 at the Venetian Sands Expo Center in Las Vegas), we’d like to give you the opportunity to sign up for complimentary Intel workshops.

You’ll have a chance to discuss critical healthcare IT challenges and opportunities with industry experts, and to encounter leading-edge solutions and practice models from security to mobile to cloud.
Simply go to the link below, where you can review abstracts and use our easy tool to select the free workshops you’d like to attend.

If you can’t make all of the sessions, make sure not to miss a review of the standardized reference architecture proposed by VisionWare* and Intel for secure, scalable master data management, using the Intel® Expressway Service Gateway and the VisionWare MultiVue* products.

The Need for Secure, Scalable State Healthcare Registries

Tuesday, February 21
9:00am – 10:00am

Read Abstract & Register

At the next session, following an overview of  Healthcare Cloud Service Brokers, the service broker enabling technologies will be demonstrated for a hands-on look at security, API management, and integration workflows.

Simplify Member-Provider Information Exchange through Healthcare Cloud Service Brokers
Tuesday, February 21
10:00am – 11:00am

Read Abstract &  Register

Lastly, here’s another session that you should not miss:

The Creation of a Healthcare Insurance Exchange Using Your State Medicaid Management Information System (MMIS) As a Foundation

Wednesday, Feb. 22
5:00pm – 6:00pm

Read Abstract & Register

You can register for any of the sessions  here.

If you would like more information about Intel Expressway Service Gateway for Healthcare, please visit our site: www.intel.com/go/identity

We look forward to seeing you there!