Security is not merely a quality issue

For a long time I’ve said that security is a quality issue.  It sounded good, it resonated with me, but by and large I am coming to the conclusion it’s an insufficient understanding.  While I still believe the two issues are similar enough for discussion, the nuanced efforts required to fix a security bug vs. a quality bug is night and day.  Patching, as we’d fix a quality issue, has permeated the collective InfoSec mindset as a defensive solution in protecting our infrastructures.  Virtually or locally, however, relying on that patching mindset is a death sentence and will always lose to a skillful opponent.

“Will you walk into my parlour?” said the Spider to the Fly. – Mary Howitt

The issue of patching ultimately boils down to being reactive or being proactive.  By proactive, I do not simply mean finding issues before the code reaches production– although that’s indeed important.  Instead, I mean it in direct relation to that of initiative and rhythm within an interaction.  It’s perhaps best to understand this within the context of chess:

Initiative in a chess position belongs to the player who can make threats that cannot be ignored. He thus puts his opponent in the position of having to use his turns responding to threats rather than making his own [1]

When we allow the opponent to dictate the rhythm of an interaction, be it in chess or InfoSec, we are effectively walking into a trap—even if it may feel as though we are winning.  In chess, the person playing on the white side of the board always starts the game off with the initiative.  They move first, so they set everything in motion– but that surely does not mean they always win.  For black to regain initiative, white must be forced into playing blacks game; this always requires the defender to strike back and apply pressure*.

I’d like to be careful to note here that striking back here doesn’t necessarily imply “hacking back” as some others are proposing**.  It simply means that if, in the course of an interaction, we can make our opponent deal with our threats (read: countermeasures) we can regain initiative—and perhaps equally important, time and space.  There are unlimited opportunities for doing so.  In fact, this is perhaps the most important bit to all of this— attack and defense are the same.  We always have the same opportunities to be creative and solve problems; it usually comes down to being bold enough to leverage them.

As an example, lets explore a reasonably effective security countermeasure—CSRF cryptographic tokens. I find these can be among the most annoying little boogers around when testing a site.  Their simple presence disallows numerous tools to work effectively without modifications (or at all); and often I must write custom scripts to test the site.  While this doesn’t stop me by any means, by simply forcing the POST of a page to be dependent on information in a previous GET—you limit how I can approach the engagement and cut my effective speed by 50%.

If we coupled this countermeasure with the injection of fake targets such as form fields which act as a tripwire, we can drastically increase the feedback loop of when someone is attacking our systems.  Any value outside of the one I set in those fake fields is invalid and a surefire sign of manipulation.  The aggressor would need to be right the first time, otherwise I would know immediately when they are up to no good.  The net effect here is that the aggressor has become encumbered with having to solve various challenges, while the defender has increased his ability to make an informed decision on what to do next.

Ironically, the CSRF protections listed above were not directly intended to cause either of the things I mentioned.

However, if those protections are not in place, as is often the case, the deck is already stacked against the defender.  The only way to realistically know of the malicious interaction is either via logs or some form of IDS.  In either case, by the time you are made aware, the window of time you have to respond is very small.  Indeed, it might even be too late for a patch to even solve anything.

So—lets reconstruct this for the sake of clarity.  Security bugs still need to be resolved.  Similar to a quality bug, these issues can be remediated either through design improvements or by patching.  However, dissimilar to a quality bug—that’s simply not good enough.   We need to be additionally focused on security countermeasures that not only help us regain awareness of what is happening to our applications, but at the same time require aggressors to engage the game under our terms, not theirs.

Sadly, there are very few defensive frameworks in place today for the web that do either of this well.  But I am working on numerous things that I think can help change that.

– A

* It’s also common to attempt to wait for an opponent to make a mistake to regain advantage.  However, this type of thinking is also dangerous because it precludes that the attacker will make one.
** It also doesn’t negate it either.

Post a comment or leave a trackback: Trackback URL.


  • Andre Gironda  On December 5, 2010 at 1:34 am

    I am finding that anti-automation tricks e.g. CSRF tokens are actually smart to put into production, but not in testing/staging/dev/integration. And should probably be able to be removed temporarily using good Green-Blue deployment techniques for certain reasons.

    There’s no good reason to slow down the penetration-testers working to help find issues. At the same time, it doesn’t really slow them down either — certainly this doesn’t help when an adversary finds a simple flaw via non-fault-injection methods.

  • Rob Lewis  On January 22, 2011 at 4:22 pm

    This might be of interest to you then:

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: