Wednesday, November 6, 2013

Developer Games

The typical developer focuses on business functionality, complex integrations, making sites work and look great, and so on. Those of us in the business or elsewhere in the technology org see a lot of the mistakes they make. We call their babies ugly.

Infosec folks find ourselves apoplectic about the developer’s ignorance about the security domain, like when they start talking about firewalls when you are trying to explain why their SQL injection flaw is a big deal. We’re frustrated when, year after year, we have the same conversations with the same developers.

But don’t fool yourself into thinking that developers are incompetent or even that they don’t care. I am a developer (mostly in my spare time these days). I know too well the pressure developers are under. They have to contend with impossible deadlines, ridiculous politics, poor technology decisions made elsewhere (often by execs over a game of golf), an IDE that corporate approves rather than the one that they like, and last minute requirement changes. What they love mostly is solving challenging problems.

The developer employed as the attacker has to be a whole different matter. I can only speculate since I have not practiced the dark arts outside of ethical hacking on behalf of the business with approvals.

We know from what we see in attack patterns that there is a tendency to go after low hanging fruit. This means that the developer-as-attacker is often focused on the weakness du jour. With this kind of focus, a good developer can really excel. I can just imagine the amusement they get from plowing through poor defenses. Good defenses are probably even more fun.

The infosec review process is often seen as yet another distraction, further dividing focus from the developer’s point-of-view. For that matter, the secure SDLC adds further complexity to a process that many developers already view as an imposition from irrelevant wonks who care about the wrong things.

We can’t estimate the threat by judging our adversaries by our own day-to-day. This isn’t because the attacker is far superior, it’s because they are far more focused.

Introducing your developers (and the org) to the process of attack helps them understand defense. Business would benefit from allowing their developers and other technology folks to turn they focus away from the day-to-day. Beyond having developers tinker with WebGoat, a red-team/blue-team exercise (gaming, if you want to look like a hip leader) would surely satisfy a developer’s intellectual curiosity while also strengthening their understanding of defense. Developers will see that infosec is not irrelevant, if anything, because they don’t want to face the embarrassment of being on the losing end of the game. This would also foster a less abstract sense of ownership and even accountability.

Written with StackEdit.

No comments: