I'm busy working on my blog posts. Watch this space!
Developer, Hear My Call (please?)
October 9, 2017
At the risk of bringing down the wrath of the most powerful workers in the modern economy - that is, software engineers - I would like to spend a few paragraphs discussing their job.
Calm down, now. It will all turn out alright. I promise.
It's just that with all these breaches and leaks and media attention to them that I keep finding a curious lack of focus on what should be an obvious, mundane aspect of software development, and which by all rights should be front-and-center in the conversation.
What do I mean by that?
Well, if you're a developer, and as is my wont, let me ask you a simple question: what is your job?
In almost every case, the answer can be reduced to some variation of: "to code". That is, to build software which becomes a product which makes money which leads to higher valuations which lead to an exit which hopefully leads to a fat option-exercise-fueled bank account.
And this is exactly where I wish to step in with my boring update of this answer. It is so obvious that it should almost be too silly to mention. But here is the thing: we work with many dev teams. All the time. A large portion of our time advising, consulting on and managing security programs for companies large and small is spent interacting with (software) engineering. And the sad reality is that this concept is somehow rarely, if ever, actually followed.
You see, if you're a developer in this day and age, your job is not "to code". Your job is to code securely.
It really is that simple. See, in today's age where everything is some sort of abstraction layer, where network security controls are, at best, an infrastructure footnote due to virtualization, cloud and whatnot, where continuous development and integration means traditional gates on the way to production are felled faster than a three year-old who wants ice cream right now... in this modern age, where devs clearly have the upper hand in the battle for tech supremacy, a significant portion of the responsibility traditionally given to other teams (hello, infosec!) now falls on them, whether they like it or not.
Because if I can't keep you honest and provide checks and balances on what you're doing, then it's up to you to make sure you're not just playing cowboy. And the truth is, no matter how good your patching practices might be, your developer can easily sink the ship by creating an exposure in the app. This is even more true when everything is done via custom APIs, meaning that testing things gets even more complicated and dependent on the human interface between the tester and coder. One which is often, shall we say, sweet and sour.
You think I'm exaggerating my case? not in the slightest.
In (more than) one company we'd worked with, the engineers figured out that the easiest way to satisfy the security peer review requirement is one of the oldest in the book: "you accept mine and I'll accept yours". It didn't matter how you paired folks up, this unwritten understanding was endemic. Trust me, that approach is not uncommon.
Show me one engineering organization where developers are actually held accountable to the quality of their code from a security perspective, and I'll show you this gorgeous black opal I (wish I) had. In other words, it exists, but it's really rare and precious.
Thing is, the incentive to do better should come from the devs themselves. Why? because they are often incentivized by stock options. Lots and lots of them. You know how much harm a breach can cause to a brand? there's a certain Richard Smith you may be interested in discussing that with. But even if comp package is not about the stock, it certainly is a high one worth protecting.
Yet that connection rarely seems to be made explicit. It rarely, if ever, comes up. Secure coding? oh, that's when infosec "agreed with" the engineering head, who really is the crown-prince of the company and doesn't need to do much more than pretend to listen to anybody, that devs will follow OWASP principles, and then check each other's work for such adhrence (via that peer review). Uhh... right.
I recently spent an hour delivering a brownbag about security to a dev team at one of those super-cool, bleeding edge companies doing really neat things in the cloud. If I hadn't experienced this a zillion times before, I'd have been surprised: the bored looks reflecting the barely held back resentment about having to do the session (well, at least the lunch is free) changed rapidly as soon as I made my case about the benefits of secure coding to one's checking account balance. We ended up running over the allotted time, and to my great satisfaction, every single one of those present had at least one relevant, interesting, smart question to ask. Heck, some I couldn't even answer.
In other words, we were engaged. And when smart people like this team become engaged, you don't need to burden them with all sorts of process, because if there is one thing they are good at, it is fixing things. That is a big part of their strength, just like we in security are good at... you guessed it, breaking things.