If you haven’t got your (applications’) health, then you haven’t got anything

allergensIf you happen to be unlucky enough to suffer from Celiac disease - gluten intolerance (wheat, barley, oats, rye) - then you know how important it is to keep gluten out of your diet. If you don’t know let’s just say that you have to keep even trace amounts of gluten out of your diet lest you suffer the consequences, which can be different from person to person, but none are pleasant.

You feed off food; applications feed off requests and responses. Like those who suffer from gluten intolerance, applications are sensitive, too, and need a pure diet free of “bad stuff” – including malicious content, malware, and illegitimate requests that attempt to infiltrate your network for nefarious purposes.

Like those learning to adopt a gluten-free diet, you need to be ever vigilant for not only the obvious sources of “bad stuff” but the hidden ones, too. This takes time and effort and requires reading every label. Obviously this increases the total time it takes to do your grocery shopping but it’s totally worth the peace of mind that comes from knowing you aren’t subjecting your health to something that would jeopardize it.


Like gluten that sneaks into the diet you may not know when “dirty” content has snuck into your applications. Unlike gluten, which affects only the intolerant person’s health, dirty content in application data can spread and infect other applications – and clients. Unless clients are able to track down the source of the contamination you may not figure out for months that you’re that source. And unlike sources of gluten attackers are intelligent. They specifically target websites and web applications with the intention of spreading their particular brand of unhealthy data to others in the hopes that they’ll score big.

One of the most interesting tidbits often offered by Jeremiah Grossman is not that attacks are increasing but that the target of the attacks has slowly morphed from your systems to your users. Attackers are still trying to leverage your systems but rather than treat them as the target they are merely a vehicle, a distribution point through which malicious code and scripts can be forced upon unsuspecting users. The intended use of your systems is to inevitably gain access to juicy data that can result in identity theft or compromised financial accounts of various types. And it’s working, according to most reports. Consider that identity theft is a growing problem:

According to the Federal Trade Commission, the number of identity theft reports filed from the Shoals area to the FTC increased more than 45 percent from 2007 to 2008.

And then further consider how you – and your applications – may or may not be contributing to the problem. Like third-party manufacturers of spices and “flavorings” your applications may be indirectly responsible for poisoning the health of of clients. If your applications have been contaminated you may be an unwitting partner in the most widespread crime spree of the decade: the spread of malicious code via web applications.

Consider, too, the business costs to you of not only potentially being a party to aiding identity theft but in being a victim of it as well. If someone purchases your goods or services illegitimately, well, you’re going to lose it in the end because it wasn’t legit.

40% of business costs for individual cases of identity theft exceed $15,000. The Aberdeen Group has estimated that $221 billion a year is lost by businesses worldwide due to identity theft.

If you aren’t doing everything you possibly can to prevent it then you just aren’t doing everything possible to protect your customers and users from the toxicity of tainted data. And considering the potential loss of business revenue to you from such events wouldn’t it be nice if other businesses enabled the same protections on their applications?


Like reading labels, inspecting requests and responses as they are flowing through the system takes time. It delays the time it takes for a  request to be fulfilled but in the end it’s totally worth it because the end result is peace of mind knowing that the data is free of “bad stuff” that can harm the health of your applications.

Whether it’s DLP (Data Leak Prevention) through outbound content inspection or inbound inspection of requests that potentially carry malicious code it behooves every security professional to understand the potential ramifications of allowing sensitive data to leave the corporate network – or malicious data to enter it.

Yes, thorough content inspection takes time – just like it takes time for gluten sensitive individuals to thoroughly read labels – but do you really have a choice other than potentially poisoning your own applications or your users/customers with contaminated data? The addition of a few microseconds – even one full second – is likely not worth the risk.

Whether it’s via a web application firewall, DLP specific solutions, or a programmable platform capable of bi-directional content inspection, it’s should be a regular part of every organization’s security strategy to enforce inspection of content – inbound and out – on every web application for which you are responsible. This is particularly true for Web 2.0 applications where user-generated content is king. User-generated content increases the risk of attack as well as the potential for contamination and should always be viewed suspiciously.

Anything else is just risking your applications’ health. And if you haven’t got your (applications’) health, you haven’t got anything.