I’m going to tell you how to be vulnerable. Now your wondering if I’m going to tell you its okay to cry when your kitten dies, or your hard drive makes the click-clack sound when you boot up. It makes me cry too, and no, it doesn’t make you a loser to cry.
Before you get offended that I’m suggesting the death of a kitten is the same as the death of a hard drive full of pictures of kittens, know that it was only a test. I just tested you.
With that test I made half of you all uncomfortable by showing my own vulnerability for crying over dead kittens/hardware, and I made the other half of you cringe-fully uncomfortable by using the two most common English spelling mistakes. Which makes one half of you dead inside and the other half of you annoying perfectionists. Therefore, none of you are any good at being vulnerable, so I’m going to teach you.
This is your first and only class on how to be vulnerable. Based on the strongly believed anecdotal evidence that thinking like the enemy makes you better at fighting enemies, we suggest that thinking like the vulnerability will make you better at fighting vulnerabilities.
I bet you thought all these articles are supposed to be about teaching you how to be secure and not about being vulnerable. Well you thought wrong. And you thought right. I don’t know, I just write what the raccoon tells me. Never mind, the point being that vulnerability is a big part of being secure.
Think about it, you need to be secure ALL the time. But you won’t be, and that’s backed by some statistics you can go reference on some smart infosec blog by someone with freaky sideburns and the fortune of having sat next to the person who built the first security thingy in 1968. So when you’re not secure, what are you? Exactly. You’re vulnerable. Like Mike Tyson kind of said, “Everyone has a vulnerability strategy until they get punched in the face.”
So it’s time you learn how to get good at being vulnerable, because believe you me, you will be vulnerable much more often than you will be secure. So, embrace your vulnerability or you won’t be able to fight it. And that is not something you want to lose to. Why? Because breach. The answer in vulnerability is ALWAYS breach.
Lesson 1: A vulnerability is like the popular kid in school: complicated, needlessly mean, and totally unaware of their own disastrous effect on those around them.
It might seem that the purpose of a vulnerability is cruelty, but it’s not. It’s blissfully unaware of its consequences and how much the software can suffer from it. Like being the victim of a popular kid’s attention, software doesn’t know it has a vulnerability problem until it’s painfully aware that it does.
What you need to understand is that vulnerabilities are often not obvious. We catalog and classify (badly) types of vulnerabilities that are KNOWN, but we don’t know all the types of vulnerabilities because we don’t know all the vulnerabilities yet (if ever). Vulnerabilities change with time, technology, and type of use.
So, one day you’re browsing the web and the next you’re dead. And by dead I mean inconvenienced. All it takes is that one badly or cleverly written JavaScript code to accidentally fuzz a vulnerability out of your browser that nobody, especially not your browser, was paying attention to yesterday. And boom, there goes your browser session. Dead. And mildly annoying.
By accident of course. Developers don’t put vulnerabilities in software on purpose. They don’t want them there any more than a school wants the popular kids in class (except for Mr. Fennel who was kind of weird that way).
So, keep in mind that like a runaway teen off the 11pm Hollywood bus, vulnerabilities aren’t made, they’re discovered.
Developers are well aware that the goal of software is functionality, and security is something that maintains that functionality. It makes no sense to add a vulnerability to software and compromise functionality, unless of course it helps with speed, stability, usability, or design….
All I’m saying to you developers is no, you shouldn’t introduce vulnerabilities on purpose into software, but maybe you do sometimes and that’s okay. <Editor’s Note: Developers please do not introduce vulnerabilities on purpose in software. It is NOT okay.>
So, to conclude the first lesson, to be vulnerable is to not know how you are affecting those around you until you just collapse in on yourself and take out everyone depending on you.
Lesson 2: Some vulnerabilities are like gems, despite being actually very common they are discovered through manual labor, which makes them more valuable.
Let’s call them artisanal vulnerabilities, because that’s the fancy way of saying they’re dug by hand out of software code with no more than talent and sweat. These vulnerabilities can’t be found by automated fuzzing or some other method to Julienne software, and would rot in obscurity if not for the hard work of vulnerability bug hunters.
Professional bug hunters who look for artisanal security vulnerabilities work for security consultancies, criminal empires, and government agencies. They do it as their job, but they also really like doing it because who doesn’t like to rip apart somebody else’s hard work?
But there’s also the growing number of bug hunters are the ones paid randomly through vulnerability reward programs and, like my neighbor who buys all those lottery scratch-offs, it’s something they do for fun that maybe someday pays a jackpot.
Now I’m not going to judge their brand of fun things one can do in their room alone... I’m just suggesting that maybe reading source code isn’t the best way to bond with friends.
But bug hunters don’t need friends because they’ve embraced the vulnerability. They have learned to respect the complicated fickleness a vulnerability can present and the frustration of being teased by it all night only to get nothing out of it. Until they do.
So, to conclude the second lesson, as a vulnerability you can only have importance if you make others work hard and long with their own hands to get through to you.
Lesson 3: Vulnerabilities are like 90’s action films, some unknown entity always destroys seemingly solid ventures.
Back in the late ‘80’s and early ‘90s, a public service series of documentaries called Die Hard showed us the dangers an unknown threat running around uncontrolled can have on even the best laid plans for financial improvement. It essentially foretold the doom that all business ventures could face if they didn’t prepare for the possibility of such unknown vulnerabilities. Now it’s easy for us to re-watch the film and see the glaringly obvious correlation between John McClane and a software vulnerability. In all the films, the protagonists were unprepared for the damage this single vulnerability could cause in their missions and how hard it would be to find it.
You see, when you’re a vulnerability you start out as an unknown. You get known only when the trouble starts. As others discover you, some try to use you for their own nefarious purposes and others just want to take you out. It’s all very last-century action movie, I assure you. The problem is that when nobody is prepared for the potential of unknown vulnerabilities, they lose. And in the 90’s they apparently all died too. But they’re all unknown vulnerabilities. All software is loaded with unknown vulnerabilities.
And that's exactly my point. If they knew, they could at least be like, “hey let’s not knock over the Nakatomi building until we think a bit about how we’re going to handle any unknown vulnerabilities. You know, let’s have a contingency like leave and try again another day.”
But they don’t know. Nobody ever knows. So maybe you’re going to pick up some bearer bonds and it’s all fun and drinks at the company Christmas party while you do, or maybe it’s let’s have a drink and then bullets rip through you and your dead. It’s the same with software.
You do your business thinking you’re all good until you realize you have a vulnerability. You didn’t know it before, but here it is. What’s your contingency? Did you plan for this? Do you have compensating controls for just this kind of thing? Or are you just going to keep going and hope for the best? Because I can tell you what really happens next: the bullet shower, and it ain’t pretty.
So, to conclude the third and final lesson, to be vulnerable is to never know how vulnerable you actually are. You need to realize you will always be vulnerable and to have contingencies for all the things you want to do in case that vulnerability shows up.
Always be prepared for the unknown vulnerability.
