Application aware Firewalls

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, but 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 was suggesting  that attackers are moving up the stack to the application layer as it is so easy to hack into applications nowadays, especially with the applications moving to the cloud, and introducing new vectors of attack, such as 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. It developed over last few years as more and more applications are coming out with new technologies exposing themselves to newer threats plus there is no unified standard between developers when they develop application level security.

The network security we have today is not “application aware”. This means the API/XML and other application level threats go right thru your regular network defenses that you built over years. There are people out there thinking, if you use REST or JSON then they are not prone to attacks, as are others 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.  Not only direct attack on your application, but maybe a bounce off another application that is hosted in a multi-tenant environment. So your new “firewall” should be able to inspect, have visibility into, analyze application traffic and identify threats. But the issue doesn’t stop there; you also need to analyze for virus, malware and the “intention” of the message (and its attachments) as they pass through them. Most times the issue with Firewalls inspecting the traffic would be it will look at where it is going (port and maybe an IP address), but not what the message is intend 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 application are built now a days. In the olden days you controlled both the client and 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 put it out there for everyone poke and prod for weaknesses.  As we all know the chain is as strong as the weakest link. The problem is 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 having inherent knowledge it can 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 organization and not worry about other nuances and leave that to the experts.

That 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 out of it in a centralized, or de-centralized, locations 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 out 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


Advertisements

RSA 2012 Interview with Andy Thurai, Chief Architect of Intel’s Application Security Identity Products Group

Watch this interview between Tom Field and myself about API management and the attendant issues including security, management, auditing, metering, monitoring and monetization.

We talked about Social APIs vs Enterprise APIs, as well as how Intel is providing mobile enablement. Good conversation about a platform that is about technology, security, and identity agnostic, so that when messages are sent to a hosted app or a partners app, one has the appropriate mechanism to consume those messages coming in from mobile devices. Also hear about Intel’s latest announcement made at RSA, about Cloud SSO — visit http://www.intelcloudsso.com for more information.

%d bloggers like this: