December 2009 Archives

Unhappy New Year - Unemployed Again

Hey folks - I just lost my job again. ARGH! I'm at a loss for what to say. In the meantime, I need a new job, and asap. I'm currently based in Fairfax, VA. Relo is not an option this time, but I am open to travel.

Resume is here: [ PDF ] [ DOCX ] [ DOC ]

2010 Prognostication

| 1 TrackBack

I don't recall doing any sort of predictions for the coming year before, so I thought I might try it this year. Of course, far be it for me to deliver the line straight, so if you detect a wee bit of snark, then you might want to adjust your sarcasm meters, because I'm going for the gold here. :)

Without further adieu...

NSS Labs Releases IPS Results

| 2 Comments | 1 TrackBack

NSS Labs released their Q4 2009 Network IPS Comparative Test Report last week, and it's a whopper! The following findings are very interesting:
* Tuning Is Very Important: While some vendors did ok out-of-box, the simple fact was that tuning greatly improved the effectiveness of even the worst performing system. It's imperative that a skilled engineer by brought in for initial tuning, and that tuning be done on a regular basis.
* You Get What You Pay For: It was striking to me how poorly Juniper did in the testing. They were the worst product by a long shot. It goes to show that saving big bucks is only useful if the product still does a decent job. However, sometimes cheap is just that: cheap.
* Surprising Top-Performers: The top recommendations were for IBM and McAfee products, with Sourcefire coming in at third. You'd expect Sourcefire to do well, and they definitely did not disappoint (except for missing one class of fragmentation avoidance technique). However, who would have guessed that IBM and McAfee were producing top-of-the-line products? These vendors must be ecstatic. Let's hope that it serves to motivate their competition to step up their respective games.

If you're going through IPS product selection, then this is a must-read report. It covers products from Cisco (1), IBM (2), Juniper (3), McAfee (2), Sourcefire (1), Stonesoft (3), and TippingPoint (3). Hopefully next go-round it will also include some other vendors, such as Nitro Security, to see how they compare, particularly out-of-the-box.

More On Possibility and "Risk"

Hopefully few of you wasted time reading my rant Tuesday on possibility, probability, and an analyst who really got my goat. Today, instead of ranting I wanted to revisit this whole "possibility is not probability" notion, and particularly its relationship to risk and risk management. The main goal here is to put a stake in these semantic games once and for all and make some very clear points. We'll see how I do...

The problem with the overly simplified "possibility is not probability" line of argument, in a risk management context, is that it doesn't speak to key attributes of risk. At it's most fundamental, "risk" is a matter not just of the threat or vulnerability, but also of the likelihood it will be exposed, the likelihood it will be attacked, and the overall impact should it come to fruition. When we talk about risk, we have to consider all of these factors as they apply to our specific environment. You cannot take any one attribute and jump to a risk assessment generalization that applies equally to every situation or environment.

Quick Security Lessons From Target

I really hate shopping at Target, which is probably why I end up spending so much time there every week. Every time I go to one it's like going on safari: you never know what you'll see, but you're hopeful you'll get something good. And, frankly, it's absolutely maddening. I've lost count of the number of times that I've purchased something trivial there (soap, for instance) only to come back to restock and find that the product is out or, more likely, not carried any more.

How Not To Talk To Customers


I really hate dealing with tech support and customer service reps, especially on technical issues. It doesn't matter if I'm calling or sending email, inevitably someone says or does something so incredibly stupid that the entire process gets set back minutes if not hours. It can be something as simple as rigidly sticking to a troubleshooting flow chart, or as egregious as being rude and sloppy.

Recently I had two negative experiences with tech support. In the first case, I tried to tunnel a Linux-based client over SSH to an X console on my workstation as a workaround until firewall rules could be implemented, but kept getting a segmentation fault (often a sign of bad programming, not generally indicative of something with the X session itself). In the second case, a vendor tech support rep was sloppy in reading the submitted ticket, replying with troubleshooting details that didn't apply to the appliance we had, despite the pertinent information being in the very first sentence (of a 4-5 sentence email).

[[ Please Note: This post has been significantly redacted since it's original posting. The original opening of the post was a personal attack against an industry analyst. I found myself extremely offended by the tone and timbre of the analyst's responses in a Twitter thread, compounded by his publishing a follow-up blog post that changed the message completely and tried to make it sound like he had been reasonable all along. Regardless, it did not justify in any way my publicly lashing out like I did, and as such I have cut all that nasty BS out of this blog post. Hopefully now this thread will represent a worthwhile contribution to the community. Of course, with the change, the title of this piece doesn't really make as much sense, but I'm sure we'll get over it... ]]

The Twitter Thread That Started It All

The full transcript of our exchange is below for you to read. Allow me to preface all of this by saying that trying to get a point across in 140 characters is darn near impossible, as can be evidenced by the fact that the other party completely missed my point numerous times. It's not completely his fault, of course. Human nature makes us want to be consistent with our beliefs, even in the face of overwhelming evidence that we're being a total prat.

The original tweet that started it all was:

"Other than worms, viruses, botnets, and drive-bys, can anyone think of security threats Mac users don't really have to deal with?"

My immediate response was to ask if he was being serious. Because, honestly, I thought he was joking. Why would you ever tell anybody that they shouldn't have to be concerned about common malware or targeted attacks, regardless of platform? This is tantamount to telling people "move to Mac, you'll be safer" - which is not definitively true!

The problem throughout this exchange is that the other person uses circular reasoning to defend his original statement. I consistently question his assertions, and he simply points back into his own argument as proof that he's right. It's a pity, because I really would like to see his evidence that malware is not a threat to Mac users. Unfortunately, despite what his "1337 dudes who understand that stuff" tell him (I think his comment was in reference to 64-bit architecture), the people I've spoken with in the know say that Mac malware exists and is commonly used, though more in targeted, rather than widespread, attacks. I'll comment on this more below.

Embrace Murphy's Law

| 1 TrackBack
"Anything that can go wrong will go wrong." -Murphy's Law

Oftentimes misadventures and quirky failures are attributed to the Fates and Murphy's Law, as if we should have a reasonable expectation that everything will go smoothly all the time. Of course, given even the shortest amount of thought, the notion is absurd; especially if you work in IT! Whether we like it or not, we are dealing with complex systems every day, whether those be computers or cars or trains or planes or humans. The amount we don't know pretty much always exceeds what we do know.

As such, it's time that we embrace Murphy's Law. Instead of fighting the inevitable, as has been the modus operandi of security the past few decades, we need to adopt a survivability mentality that focuses on defensible and recoverable systems and processes. Murphy's Law enlightens us greatly in this regard: if we don't embrace failure, then failure will embrace us. And, as no position is absolutely defensible, it seems that a good place to start embracing Murphy's Law is in enhancing system and process recoverability.

I grow increasingly impatient over the entrenched status quo. Throughout all the blah-blah from vendors, analysts, consultants, etc., there is very little new - let alone hopeful - news to look forward to. Why? Because the old school mindset fails time and time again. Why? Because the objectives are all wrong. Forget about risk - there's almost no point in trying to manage it right now (for a number reasons, as if organizations are really managing info risk right now anyway). If you want to survive, then you must establish a (legally) defensible position and then focus on recoverability, since it's not if but when bad things will happen.

Fear not... despite the semi-angst-like nature of my opening paragraph, not all hope is lost. In fact, honestly, there's reason to be very hopeful, if only we can get mainstream thinking to shift away from the failed old ways. Old ways such as relying on "best practices" (aka "mediocrity") and checklists (*cough*PCI*cough*). You cannot simply look for a list of known bad things (*ahem*AVIDSIPSFWACLDLP*ahem*) and then hope that everything will be ok. Instead, you absolutely, positively MUST build a program that is flexible (see my Sept. '09 ISSA Journal article "Elasticity: Will your organization bend or break?"), that seeks to achieve a (legally) defensible position, and that optimizes recoverability for its environment (see "Defensibility and Recoverability").

About this Archive

This page is an archive of entries from December 2009 listed from newest to oldest.

November 2009 is the previous archive.

January 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives


  • about
Powered by Movable Type 6.3.7