Security Engineering

One of the really cool things my job allows me to do is go teach developers and managers about application security.

In the past, I’ve half jokingly said “when the revolution comes, X will be first against the wall”, where X is a product or company who has no clue about security and worse, they pissed me off. Well, I felt the wall and the hood with these students – they wanted to revolt!

My crime? For daring to suggest that they do not belong in production.

READ MY LIPS! DEVELOPERS DO NOT BELONG IN PRODUCTION! END OF RANT

We have to end the developer cult where they believe they are a black magi sending code from on high. Those days never really existed. It was only because any old oxygen bandit* could get paid (and paid well) to write crap. Guess what? Crap may be the state of the art of today, but you’ll have to do better, and soon. 

Real engineers are fallible, but they know this and design around it. Coders seem to think they are magically immune from engineering problems, and do not code in any defense in depth. One of the key ingredients for software security is production management. And part of that is that developers do not have logins for production systems. They do not have access to promote code by themselves. They do not need special features just because they are developers. 

Developers need to learn basic production hygiene. I help teach it, but they have to accept it and live the life. If you are a developer, and you have access to development, it’s time to lose those credentials. If your code has backdoors that let you do more than anyone else, that’s a sackable offense at many financial institutions and government shops.

Let’s start being engineers instead of cowboys. 

* Oxygen bandit. adj. Someone who breathes air they don’t deserve, is able to dress themselves in less than 30 minutes, and who is able to drag a few controls onto code someone else developed. For more details, see one of my favorite sites.

Comments

One response to “Security Engineering”

  1. Mark Avatar
    Mark

    I’m curious about your thoughts on sql injection and at what level you should attempt to handle it… Let me explain. I interviewed a project manager before auditing the application belonging to him. When I asked him how they were handling sql injection, he told me ‘at the stored procedure’. I was a little puzzled by this as usually the input validation is handled at the web server level. Do you see any problem with handling it at the database level?

    Thanks in advance,
    Mark

Leave a Reply

Your email address will not be published. Required fields are marked *