Application-Aware Firewalls

You may have heard the term "application-aware firewalls" 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.

Most of the organizations don’t have the same solid security at the application level as they do at the network level.

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.

About the Author

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 http://cloudsecurity.intel.com/ on Security, SOA, Identity, Governance and Cloud topics. You can find him on LinkedIn at http://www.linkedin.com/in/andythurai.