I try to avoid engaging in these types of conversations, but I recently I read a blog post, “Low and Slow, Persistence, Loud and Proud, And The Fundamentals” and felt compelled enough (and a bit goaded) to offer some rebuke about it’s content.  Quite plainly, I think this article is mostly off base.

You can ignore most of the content of the first 8 paragraphs or so– unless you feel a need to invest time in feeling bad about yourself.  They seem to merely exist as preface to solidify the final points of using fundamentals, including:

It’s time to refocus on egress filtering. We’ve spoken about the data breach triangle for years. You need valuable data, an exploit, and egress for a breach to happen. Since we have little control over data and exploits, we need to focus on egress.

But, if the doom and gloom paragraphs are true and we are cannot stop people from getting in and taking data– why should we be so compelled to believe that we can stop them (or even be aware of) from leaving with it?  If bad guys don’t live in a world of technical reality on the way in, why is it any better on the way out?  The argument and proposed solution is a bit self negating.

This article seems to follow with a myriad of other fatalist type articles which spend most of the time discussing failures of an industry, and sprinkling in “solutions” at the end which are generally trite and or have no real basis in reality.  In this article specifically, the author exclaims,

“SQL injection is behind most of these new attacks. Come on, man! Any Web application scanner will find those holes. Then you need to systematically work with the developers to fix the issues, or deploy a Web application firewall to stop the bleeding.”

Sounds easy right?  But there are so many problems with that statement.  The issue of SQL injection* can’t be mitigated by simply throwing a scanner at it.  Most scanners cannot handle the complexities of modern web applications today.  They lack the ability to create enough state and insight into operations to be able to exercise it enough to find the problem.  This is true for both dynamic web scanners and static code analysis (depending on the code structure).  What about 3rd party integrations where teams don’t have visibility into the code or what’s going on behind the scenes?  Or the SQL injection is through some non-HTTP protocol for a connected service?  Or even sites that are totally forgotten in the first place.  Scanners will solve that?  Really?

But it gets better.  Throwing a WAF at the problem requires time, planning, technical talent and expertise to tune and configure it to be of any value.  If the people who’ve created the problem can’t fix it in their own code– why should we entrust them to configure a WAF appropriately?  Even more pointedly– why should we trust the WAF either?  WAFs have a history of being bypassed through various strategies, many can’t parse entire types of traffic (Flash AMF for instance) and some have even exploited entirely!  The only thing worse than no security is false security.

This article comes across as a poor rehash both problems and solutions.  But I do agree that we need more active defenses, coupled with better training.  Someone recently said something like: “People, Process, THEN Technology.”  That is where our focus should stand for actual solutions.  Strategies that can be measured, training to get people onboard, and testing to ensure it’s actually working.

* Security risks lists like the OWASP top 10 can be very useful, or they can be a huge crutch.  The issues we face aren’t merely due to “vulnerabilities”– it’s about all the other things that make us vulnerable in the first place.  Yet we obsess over the symptoms.  People (this article included) point out that SQL injection is still around– yet ignore the reality that there are a vast majority of other attacks (including buffer overflows) which have been around as long if not longer.

Post a comment or leave a trackback: Trackback URL.


  • Andre Gironda  On July 6, 2011 at 4:52 pm

    “WAFs have a history of being bypassed through various strategies, many can’t parse entire types of traffic (Flash AMF for instance) and some have even exploited entirely!”

    I accidentally the whole WAF

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: