Security Monkeys and Development Geeks

In my role as a security monkey, I often find myself in situations where I need to be the “informer of less than pleasant news”.

"Yep, that has a XSS vulnerability in it."

"If you do it that way, this method can DoS the site."

"We need to add X hours of security testing before we deploy "

It’s very easy for a security monkey to be seen as the dark cloud. It’s also very easy to start to develop a less than positive view of working with the monkey, which than leads the dev geeks to avoiding/working around security. Which then leads to dire security straits.

It’s also very easy for the security monkey to get dispirited and cranky, thinking the development geeks don’t care about security, and they look funny.

When these things happen, everyone suffers. The security crew, the app geeks, and worst of all, the users of the application. The workplace becomes hostile, the emails take an edge (even when they don’t mean to), and the friday donuts stop coming in.

What can we do as a team to work well together?

All parties need to realize 2 things

1. We all have the same fundamental goal, to provide the best product, site, widget, experience possible for the consumer of said thing.

Just like it says, Monkeys and Geeks, we are on the same team. An uber-awesome team of geek-monkey goodness. Step back for a moment and think, in the end, what do you want to do? Does that fall in line with your teams stated goals? If not, you might want to consider what drives you.

When we are working well together, there is nothing we can’t do.

Need a new user registration module? Easy.

What’s that, you want to deploy a secondary Hot DR site with real time data transfer? Ha, how about a challenge?!

Godzilla’s attacking Tokyo again? Geek-Kong-acho I choose you!

2. Different teams/people look at getting to that end in different ways.

Application Geeks:

It’s about the functionality and the slickness. The code needs to work well, work fast, and not be a pain for the user. On top of that, they are constantly being pushed by harsh deadlines, immense task lists, and at times, a shortage of mountain dew (the great dew shortage of ‘99 was thought to be a root cause of the the bubble burst).

This means that anything that may cause an interrupt to work or progress is hard to accept.

Security Monkeys:

Unplug it, then it’s secure. It’s a dangerous world out there and everyone is a threat. It’s overwhelming when you are a new security monkey, you start to see danger in every connection, threats in every ping. If the site that you are charged to secure gets hacked, you are the first called up, the last to leave, and the primary butt on the line for kicking. You’d rather new features not push, then to let something push without thorough review.

These are not irreconcilable differences. It takes communication, compromise and expectations to find the happy medium, but it is there.

Bad Example:

New code needs to push Friday. The dev geeks have worked 2 months on it, they push to staging, find issues, recode, recode, recode, and push again. The security monkey gets an email Tuesday asking for testing. Security monkey rages a little about the late notice, tests, finds two issues (one high, one low) and sends data to dev geeks. The devs work all night to fix the high and repush to staging thursday.

Security monkey slaps down furry foot and says “You can’t deploy with an issue still outstanding! This code is horrible". Dev-geeks fling back with “It’s a low, we fix later! No one would ever do that to the application.”

Result: Fights, animosity, and someone cries a little.

Better Example:

New code is pushing Friday, the dev-geeks have asked security monkey to be ready to test on tuesday, as there have been some project slides due to the work load. Security monkey saves a slot in the work day to be ready to meet the need. The code arrives tuesday with a quick brief on the integration and application path. Security Monkey flings magic, finds a high and a low. He sends the data to the App-geeks, what was found, how, where, and a recommendation. The app-geeks manager and the security monkey manager review and decide the High will be fixed before push, the low will be corrected in a hotfix later. The decision is documented and sent out, code gets fixed and rechecked, push happens.

Results: everyone gets candy.

Best Example:

New code has no issues, pushes into prod early.

Results: Happy monkey-geek dance.

I have been guilty of being a bad security monkey to my development geeks. At times, it’s a difficult task to balance the core drives of security with the core drives of development.

To all those development geeks I’ve pissed off in my career, I apologize. To all those that I will anger in the future, code it right the first time! (just kidding )