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.

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 take Action on the 2010 HIMSS Security Survey to Improve Network Security & Protect Patient Data

Tomorrow, November 30th (1:00 PM Eastern / 12:00 Noon Central / 11:00 AM Mountain / 10:00 AM Pacific),  be a part of the must-attend webinar for those charged with safeguarding patient data, addressing regulatory compliance, or securing systems and networks. You’ll learn about the pitfalls of putting in place point security solutions and how a comprehensive Security Gateway approach addresses all layers of security to more effectively manage your security environment. Register here now.

Encrypt a response with a certificate taken from a request

Sometimes it is not possible to share public keys among all clients but still necessary to provide some level of message security. In this case it’s possible to validate an incoming request and use a certificate from the request to encrypt a response. Boris Kaplounovsky’s blog post shows how to create the proxy workflow for the SOA Expressway providing such functionality.

http://securingsoa.blogspot.com/2010/11/encrypt-response-with-certificate-taken.html

 

 

 

 

Securing the Cloud with Intel(R) SOA Expressway

The Intel Cloud Builder program has launched a forum and discussion board today. I am not sure if you have seen it yet, but there is a great paper that outlines a number of cloud security use cases built around Intel(R) SOA Expressway. Grab the paper entitled “Intel® Cloud Builders Guide: Cloud Design and Deployment on Intel® Platforms.”

The paper shows how Expressway can be used as a control point for some interesting use use cases: (i) As a secure proxy for auditable virtual machine controls, (ii) single sign-on using an on-premise STS to map internal credentials to SAML assertions for a payroll application and (iii) secure credential federation for a hybrid cloud environment in a cloudburst scenario. The paper has a lot of detailed information on what some of these applications might actually look like once deployed on Expressway. You can request an evaluation copy of Intel(R) SOA Expressway at the dynamic perimeter microsite, located here.

Intel® SOA Expressway as a Secure Token Service for Lightweight Clients

Most of you are familiar with deploying Intel® SOA Expressway as an XML gateway for protecting your SOAP and REST services.   You might be interested in reading a very interesting use case written up by Ritu Kama where Intel SOA Expressway acts as a Secure Token Service (STS) for a lightweight client requestor.

While a formal STS generally assumes WS-Trust aware clients and SOAE can support that, this need not be the case and imposes additional requirements on a lightweight client. Instead of a formal WS-Trust request, the client can pass a simple credential in the form of a username/password token and retrieve the proper token for the web service they are trying to access. As long as we are sticking with common standards such as HTTP, HTTP Basic Authentication and SSL, WS-Trust isn’t necessary for simple cases.  In the model proposed in Ritu’s post, Expressway is acting as a STS used to broker the authentication between a lightweight client and web service requiring a SAML assertion.

http://software.intel.com/en-us/blogs/2010/09/21/intel-soa-expressway-as-secure-token-service-for-lightweight-clients/

Service Gateway Usage Scenarios 101 – Securing SOAP & REST Services

Don’t miss this really engaging webinar with Gunnar Peterson, recognized Security Expert & MVP, that promises to provide an excellent introduction to the Service Gateway security model.  It’s live, tomorrow, September 15th at 1pm EST (GMT – 0400). SOAP and REST based security practices will be outlined, and typical attack vectors will be covered. Learn how architects & developers can collaborate using a gateway.

Register here.

Reading this after September 15th? Register for the replay!

How to Extend XSLT Using Built In Extension Functions

XSLT 2.0 and to some extent 1.0 are powerful languages when it comes to transforming documents and even for performing some tasks. But, as is often the case, to do something odd or unusual can often be impenetrable or just plain difficult.  One of the advantages of using Intel® SOA Expressway –  Service Gateway,  is that most of the extension functions we have written to make configuration easier for BPEL based workflow are also available to the XSLT developer. Read Pete Logan’s post as he guides us through the range of extension functions and how they are used.

http://software.intel.com/en-us/blogs/2010/09/07/how-to-extend-xslt-using-built-in-extension-functions/

Have a Cisco ACE XML Gateway? Intel(R) SOA Expressway to the Rescue

Cisco has issued both an end-of-sale and end-of-life announcement for their Cisco ACE XML Gateway.  Read the blog that, Blake Dournaee, Product Manager for Intel(R) SOA Expressway has written about this –  with the special offer that the SOA Expressway team has teed up for Cisco customers looking to replace the XML Gateway.

Gunnar Peterson’s Secure the Edge Web Service Security Tutorial Series

Don’t miss the technical webinar series specifically designed  for architects and developers! Security expert Gunnar Peterson will help you master critical security skills needed to project enterprise security policy beyond the network edge. Gunnar will spend the first half hour describing the issues and techniques followed by a screen-share to configure the use case using a Service Gateway. Space is limited — so reserve your spot for the first tutorial as part of this free training series before September 15th. Other dates to hold on your calendar are September 21st, September 29th,  October 7th and October 13th.

http://dynamicperimeter.com/solutions/latest-webinar