We're really bad in the software world at recognizing and taking action against real threats. We fail to see and fully grok the threats that are bearing down on us, and as a result, our software all too often contains security defects that are well understood by our adversaries. When that happens, things only get worse.
One of my passions is to show software developers the myriad ways in which software can fail to deliberate attacks. I do that in my hands-on lab sessions. One of my biggest motivators is when I notice one or two software developers "get it". We talk about common problems like SQL injection or cross-site scripting (XSS) and they all nod, but when they actually see it work when they enter poisonous data into a real app, a light goes on. It's those "ah ha!" moments that keep me doing what I do.
But even when we do that, I'm often asked by those same developers just how real the attacks are. How common are they? How much time and effort should they put into protecting their applications? It's one thing to understand a software security defect and even deeply grok how it works, but how does that translate into their world? How much testing is enough? How much code review is enough? What problems should they spend the most time on remediating?
Security folks want to tell those developers to fix all the problems. We want to tell them to scan every line of code and test their software rigorously. But when they hear that, they get overwhelmed and they realize that we're prescribing far too much for them to realistically accomplish.
How should those developers then budget their effort?
Of course, that's a hugely difficult question to answer in a general sense. There's no one size fits all solution. It depends... And so on.
Does that mean you should simply throw your hand up in the air and give up? Of course not.
One thing you might try to do is to seek out your security company's security folks, especially the incident response team. If your company has one, you might well find that they hold a treasure trove of real world data on how your company's systems come under fire in their production environments every single day. You might well find out the kind of tools and techniques your attackers are using right now. I personally spent many years working incident response operations myself, and I can say with confidence that these are the folks who most closely get to see real attacks and real security failures first-hand.
That, in turn, might help you better understand where you need to spend time in your software security efforts.
Sounds simple, right? You might even call this "common sense". And yet, in my own experiences at hundreds of companies, I've all too often encountered software developers who fail to seek out their own companies' security personnel.
At one client, I was working with a group of software developers and I asked them if they knew their own computer security incident response team (CSIRT). They didn't. However, when I walked around their office a bit, I found their CSIRT security operations center (SOC) right down the hall from where the software developers were sitting. They were right down the hall and yet they'd never met each other!
Don't let this happen to you and your company. I'm speaking here of a concept that I like to refer to as "confluence". Software development simply must involve not just the software developers and business owners, but also the various security stakeholders in a company. Seek them out and talk to them.
I provide various actionable tips on how to do this in my latest book, "Software Security: A Confluence of Disciplines". But even if you're not inclined to buy a book, I hope some of you reading this will join me at SecAppDev and try some of these hands-on lessons first hand.
