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.)
