Impressive, Inspiring, and Inexplicable

This is a story to remind us all to enjoy what we do, and to do what we enjoy:

It started absently enough.  Someone asked: “What’s the difference between three nines and four nines?”  The first hit on Google was

It’s a slick little calculator, showing what each level of 9s in uptime translates to, in minutes/hours/etc.  So I got my answer, and normally that might be the end of it – but something on the page caught my eye:

Secret alien technology, heh. –Wait, what’s that in the alien’s trunk?  A flag? And it says … lisp?!

Lisp is a programming language taught in prehistoric Intro CS courses, with – as far as I could ever tell – the sole purpose of hazing students.  I figured it was there to winnow out the students who thought “Hey, this could be a lucrative career” from those who really had a passion for programming.  Since leaving that course (back when dinosaurs ruled the earth), I never heard of that language again.  What’s the story?

The story is at the top of the tool’s own page.  It describes how an Norwegian IT lawyer decided to write this simple but useful tool, and basically decided to write it in Lisp, just to be perverse.

I love it.

It reminds me that – yes, this is our job, and often we have to race to find the best solutions for things, but that far too often we’re constrained by fear, or by worry, or by concern.  We design things as best we can because there’s a certain artistry in good design, but mostly because we don’t want the phone to ring at 3 am.

But it’s supposed to be fun.  It’s too easy to forget that.  Mr. Miazine, apparently decided, just for the sheer giddy foolishness of it, to write the thing in the most bloody-minded language he could find.  Look at his grin, in the picture on the article.  He knows.  He knows he could have written something quick and easy and common, fired it off, and left it to be used but forgotten in a corner of the internet like some kind of programmer’s paper towel.

Instead, he created art.  Intentionally or not, he made a statement that said, “Do what you love and love what you do.”  Even though – or perhaps because – that statement was written in the most archaic language possible.

Cheers, Sir.  I salute you, and thank you for reminding us to pursue our passions.

(Comments particularly welcome.)

Spelling Food

My grandfather couldn’t spell for anything, God bless him.

It’s not a surprise, of course – he left the Pennsylvania schooling system at 8th grade, and went straight to the Navy*. And it’s not like the Pennsylvania public schooling system in the early ’40s was a model for educational excellence.

(Of course, the people of that generation were supermen and superwomen. A substandard education by their standards is pretty much a gifted education by ours.)

If there was one thing that he couldn’t do, it was to properly spell a possessive or a plural. (e.g. “we serve bean’s”.)  But my favorite, still to this day, is seeing a dropped letter on a past tense.  Show me a sign that says “We serve bake beans” and I’ll show you a slightly teary ex-Pennsylvanian.

The point is, I have an irrational trust of such a place.  Like, one person might think “eww, they can’t even spell corned beef. What must it taste like?”, but I think “Ah, home. Bet they cook like my grandparents used to.”

So this predilection also skews me in unexpected ways. My grandfather, my best friends, my extended family – they can’t spell for squat either; you’d think they never picked up a book in their lives. So when I’m helping the kids with their homework, I should try to nudge them towards spelling more accurately, right?

Maybe.  But then again…

I think of all the people I’ve been blessed to have in my life, and they’re rocking just fine without reading like the New Oxford. Which maybe isn’t the best educational perspective, but what can I say?  It’s all I got.

And if I’m lucky, one of those … creative spellers … will even learn to cook like my grandfather did.

* (Yes, that means he enlisted a few years early.)

Once QA, always QA.

Before I launch into my sociotechnological observations, let me define some terms, and maybe fill you in a little on my background.

QA stands for Quality Assurance1 – in this particular context, Software Quality Assurance.  Infosec is short for Information Security, the people charged with protecting us all from (for example) having our iphone data or Sony accounts posted on the web.  IT of course stands for Information Technology.  And by the way, IT is more than just being the poor bastard who gets sent out to the desk of a wonky computer: it means infrastructure and phones and usually power and AC and sometimes fire suppression. It means the care and feeding of all the computers that keep the business running, not just the computer where the boss reads email.  Currently I work as a technologist of broad scope, encompassing both IT and Infosec and pretty much everything in between. 

I was very fortunate to start my career in Quality Assurance at Broderbund Software, along with a small army of incredibly wonderful people – almost all of whom still stay in touch, decades later2.  One of those wonderful people was a lead technician, and she had a favorite quote: “Once QA, always QA.”  She was usually referring to people who used QA as a launching pad to other tech jobs – R&D, product management, IT, or such.  The context was usually “You will always think like you do in QA, no matter what job you take in life, hahaaa welcome to our brain damage” – but, as I’ve discussed with her recently, it goes somewhat beyond that.

QA people – the ones who really have the brain damage, I mean, not just the checkbox-compulsive metricmonkeys – have this weird kind of perversion in their blood, where they like to dance on the heads of systems and break them.  The idea is to make those systems stronger, of course, but chasing down the holes in the plan is where all the fun is.

(Sound familiar at all?)

Back then in QA, the first thing we’d usually do to a new product was to run it as it was intended once or twice.  This would give us a rough set of expectations as to how the program should run in general.

From there, we’d usually move into doing silly things – trying to click everywhere all at once, typing random characters3, trying to run as many instances of the program as possible, and basically just doing things that would make the poor computer shed silicon tears of bewildered frustration.  I’d say it’s a short hop from that mentality into Infosec, particularly pentesting – well, either that, or to a white jacket in a rubber room. 

Of course, I’m not saying that mentality’s limited to QA.  Anyone in Infosec – or even IT/Desktop Support – or anyone whose account has gotten compromised – has had enough times on the phishing merry-go-round at least to mouse over a URL before clicking on it.

(And you’re doing that too, right?)

What I am saying, though, is that those of us with more inquisitive backgrounds tend to think that way already. It’s a comfort as we pursue our professions, but that philosophy soon bleeds into everything else we do, especially things that don’t have anything to do with personal computing.

For example: I automatically look for video cameras wherever I am.  It’s not really about being paranoid, so much as reflexively wondering where I would place them if I were the head of security, and looking to see if there’s a camera where I would place one.  After all, I used to play small-stakes dominoes in my local bar, which had cameras covering every corner.4

Now, I certainly don’t care whether or not I am on camera, but I do want to know where the cameras are.  What does interest me is where the cameras are looking, and why.  More to my point, by thinking this way I’m not usually looking where my attention is being directed.  Sure, I’ll look once – but that’s about all, just as as QA testers we ran the program once “normally”, just to get an idea of what everyone else is intended to see.

Here’s a more digital example – about a year ago, I watched someone in our company exploit a pretty major vulnerability on an internal webpage that actually sent the employee’s ID through a CGI GET process. It was tempting to keep playing with the information we got as part of this hack, but part of being good at Infosec involves hewing to a certain level of trustworthiness, and making a good-faith effort to report vulnerabilities to the people who can actually fix them, before getting all Jack Sparrow with the digital loot we find5

How did he find the vulnerability? By reading the URL of the internal link he had to click on for one reason or another.  And I mean the complete URL, not just the first few characters that confirms that he’s going to a trusted site.  He noticed his employee ID in the URL, and basically said “Hm, I wonder what happens if I change a particular digit or two in this URL.”  And voila, he was able to verify whatever the company was asking – not just for him, but for anyone whose employee ID was similar to his.  Or he could have just found out the employee ID of anyone he wanted, given an automated script and probably a good few hours or so.6

See what magic awaits us just behind the spotlight?

That’s one of the byproducts of a QA background: we don’t just click on a link like a lemming, we might just read the damn thing first. Check to see that where it goes is where you intend. 

From there we (the QA tester, the Infosec, and me) start to branch out from just URLs, or even computers in general, and start to really look around us, almost unconsciously, and start thinking about what we see.  If we see a set of floodlights in a corner of the ceiling, we’ll probably ask ourselves what might live behind them. Is there a camera posted behind those lights? Or perhaps a small set of speakers?  After all, why waste such a perfectly lovely hiding place?

That thought process is really how I see the main connection between QA and Infosec, and – in this example – between coming from such careers and knowing where to look for the cameras, and wondering why those cameras are there.

Once QA, always QA.  The complexity of the systems and the tests may have changed dramatically over the last two decades, but the underlying philosophy really hasn’t.

And the more you look behind the curtain, the harder it gets to pretend that you haven’t.

[1] As opposed to “QnA”, meaning “Questions and Answers.”  A QA department usually has more of the former than of the latter.

[2] In fact, we just had a reunion party a few days ago, at the time of this writing. We’ve had one every few years or so, and it’s been almost fifteen years since that company got bought out.

[3]This was well before the relevance of a SQL injection – hell, it was before any Internet game that I know of besides Nethack.

[4] They knew that we were gambling for money of course; they just didn’t care. That wasn’t what the cameras were there for and that absolutely wasn’t what they were worried about.

[5] Of course he made a report right away.  And, surprise!  The report went ignored. Not even an automated rejection letter.

[6] I want to make it very clear: he did none of this.  His ethics are strong.  But he could have.
(And while I’m here, yes: he’d started his career in QA as well.)

LinkedIn: Last Name Conceal, Account-Based. Swing And A Miss.

Dear LinkedIn:

I somewhat like the idea that you block viewing last names of third-degree contacts. It makes company-mining slightly more difficult, and is a cute way to upsell your account upgrades.

Trouble is, no one seems to have told the “Viewers of this profile also viewed…” widget, which goes right on ahead and blasts out the full names of those that viewers of a profile have also viewed.

Not that I care, really.  In fact, as regards myself, I honestly couldn’t care less.  If I didn’t want people to see my full name and title, I wouldn’t have a public profile on LinkedIn.

But, it does seem to defeat the purpose of blocking last names on the main page, when the widget – just a quick scroll down on the exact same page – totally undermines this effort.

(PS: thanks for leaving that bug in; it really does make data mining easier ; )

[Note: I’d like to put in screen shots, and will if I ever get around to creating a blank LinkedIn account.]

BSides LV Memory x2


We’re having a little … discussion … over on the BSides group list, and Erin most appropriately started us off with the lovely memories.

Mostly so I don’t have to choke the thread with a 300K JPG, and also so it’s somewhere else, I post the picture here.

For context, here’re two of my favorite BSides memories, in this case about LV #2:

– Track #2, the “game house”, was over capacity and overheated from the jump on day one.  Jack managed to miracle a 3-ton unit literally overnight. (I’ve pulled some huge honkin’ rabbits out of my ass before, but Jack wins the prize for this.  He must have been bleeding for months.)

– Track #2, end of day one.  As speaker wrangler, I noticed the last talk of the day in that overheated and under-oxygenated room was a panel, and (IIRC) my contact for that panel was Leigh Honeywell. I went to her and started to ask, “Since y’all are a panel, do you need A/V, or can we just leave the doors open for that hour?”

I got as far as “do you…” in that sentence, and Leigh finished that sentence for me with the words “… want to run it by the pool?”

I blinked for a few seconds, and said, “Give me 15 minutes.”  Went to Vyrus and Jack, and damn if within 15 minutes Vyrus hadn’t redirected all the necessary A/V to the poolside – in particular, the beach. Jack got the video camera set up on the walkway in about that time, and off we went.

That’s what I’m talkin’ ’bout.

But a picture’s worth 1000 words, as we know, so I’ll just STFU and leave you with this.

Four Great Ways to Fry your Identity

This is an old post (from 3/09) on BigFix(now an IBM company)’s blog site.  I recreate it here for posterity.  And I need to write more.


The paper describing the hijacking of the Torpig botnet by the fine folks at UCSB is very engaging, even if one has technical training of less than Olympic caliber. Among the topics covered are the browsing patterns of an estimated 182,000 infected hosts.

While the technical details were of great interest — in particular, the concept of Domain Flux and the infrastructure of a botnet—as an IT engineer of a growing technical company, the browsing analysis jumped right off my page. I’d like to point out four very special points the paper raised.

Since these are browsing habits of people who are already infected, chances are that if you see anything familiar, you might rethink the way you – or your community – use the web.

1. The first thing that caught my attention in sec. 6.1 was the discussion of the number of financial accounts that were stolen. That was idly interesting, but the last sentence woke me up:

“38% of the credentials stolen by Torpig were obtained by the password manager of browsers, rather than by intercepting an actual login session.”

I can’t tell you how many times I’ve shoulder-surfed people “logging in” to data-sensitive sites with a single click. These metrics on its risk are sobering.

Personally, I have no use for a browser’s password manager, but if you do: think seriously about how much you do, or don’t, want be one of those 38%.

(In passing, I do have to admire the botnet’s approach on this topic: kind of the digital equivalent of hitting it with a wrench.)

2. In section 6.4, we are reminded again of the importance of having a good password policy:

“Our analysis found that almost 28% of the victims reused their credentials for accessing 368,501 web sites.”

There are ways to make a gaggle of passwords different, easy to remember, and yet not require a password manager. I would love to get into some ideas on how to do that, and welcome the discussion it would generate … but perhaps another time.

To paraphrase one of the popular metaphors in the paper’s conclusion: people understand the concepts of the security of a car but don’t bother to apply those same concepts to their computing environment.

Fundamentally, would you leave your car, house, and work keys all on the hood of your car every time you parked it? That’s the effective risk incurred by reusing passwords among such sites through a browser’s password manager. The only real difference is that not to see the risk usually means not to think about it*.

3. Section 6.5 of the paper glances at the infected computers themselves, and discusses the zeitgeist of peoples’ actual browsing activity. The highest single observable interest of Torpig-infected users is to seek jobs and submit resumes, at 14%.

Sure, in today’s economy, a pile of those are probably home users. But if I were to somehow sniff any company’s web traffic on any given day, I would fully expect to see non-manager-initiated job board HTTP requests. What I mean to say is that just because it’s a work computer doesn’t mean it’s inherently safe. Yes, it’s presumably being protected by the IT staff, but no security measures are foolproof, and they haven’t been since the first rooster crowed at the dawn of civilization.

4. Finally, the paper noted that:

“… online security is a concern of the infected population (almost 10% of [infected emails] mention phishing, viruses, and spyware), but only a few people seem to suspect that they are using an infected machine.”

Torpig in particular builds sophisticated phishing pages for common banks, eBay, and PayPal sites that are very devoted to passing surface authenticity tests (sane URLs, valid SSL certs, etc.), so it isn’t too surprising that once infected, the users would only have dug the machine deeper into the disease.

Still, standard rules apply – in a nutshell, if you think something’s suspicious, it probably is. Specifically, if you log in to a site that immediately asks for your bank account number or social security number – look to your computer’s health, it might well be running a temperature.

The constant war between security and convenience rages on like the climax of a John Woo movie. No one wants to go through all the work they need to in order to keep a secure and sane computing environment. I can’t blame them—I didn’t used to lock my car until after it got looted a few times**.

Managing risk is something that can’t be done only by your CI/SO, just like managing corporate costs can’t be done only by the CFO. At some point, on some level, everyone has to be involved.

You can park your car with the windows down with the keys in the ignition***, or you can take the keys and roll up your windows. You can keep using the same password that you’ve had for years, (your firstborn’s name, your favorite candy, what have you), and use that for everything you do online, or you can devise some memorable means of switching up your passwords that is unique to every site yet meaningful only to you, so you can wean off the training wheels of a browser’s password manager.

After all, it’s easier to replace your car than your identity.


*cf. “turn up the radio when the engine starts to make funny noises” and other such metaphors by Tim Keanini
** Yes, I’m a slow learner.
***Or, if you live in the San Francisco Bay Area, you can leave your laptop visible in the back seat of a locked car.