The first problem any security project has is to get executive support. The second problem is to find a way to make use of and direct that executive support.
Developers should be prepared to defend against a Manager in the Middle attack.
— Alun Jones (@ftp_alun) November 9, 2015
So, that was the original tweet that seems to have been a little popular (not fantastically popular, but then I only have a handful of followers).
I’m sure a lot of people thought it was just an amusing pun, but it’s actually a realisation on my part that there’s a real thing that needs naming here.
Executives support security
By and large, the companies I’ve worked for and/or with in the last few years have experienced a glacial but certain shift in perspective.
Where once the security team seemed to be perceived as a necessary nuisance to the executive layers, it seems clear now that there have been sufficient occurrences of bad news (and CEOs being forced to resign) that executives come TO the security team for reassurance that they won’t become the next … well, the next whatever the last big incident was.
Obviously, those executives still have purse strings to manage, and most security professionals like to get paid, because that’s largely what distinguishes them from security amateurs. So security can’t get ALL the dollars, but it’s generally easier to get the money and the firepower for security than it ever was in the past.
So executives support security. Some of them even ask what more they can do – and they seem sincere.
Developers support security
Well, some of them do, but that’s a topic for another post.
There are sufficient numbers of developers who care about quality and security these days, that there’s less of a need to be pushing the security message to developers quite how we used to.
We’ve mostly reached those developers who are already on our side.
And those developers can mentor other developers who aren’t so keen on security.
The security-motivated developers want to learn more from us, they’re aware that security is an issue, and for the most part, they’re capable of finding and even distinguishing good security solutions to use.
Why is security still so crap, then?
If the guys at the top, and the guys at the bottom (sorry devs, but the way the org structure goes, you don’t manage anyone, so ipso facto you are at the bottom, along with the cleaners, the lawyers, and the guy who makes sure the building doesn’t get stolen in the middle of the night) care about security, why are we still seeing sites get attacked successfully? Why are apps still being successfully exploited?
Why is it that I can exploit a web site with SQL injection, an attack that has been around for as long as many of the developers at your company have been aware of computers?
Someone is getting in the way.
So, who doesn’t support security?
Ask anyone in your organisation if they think security is important, and you’ll get varying answers, most of which are acknowledging that without security in the software being developed, so it’s clear that you can’t actually poll people that way for the right answer.
Ask who’s in the way, instead…
Often it’s the security team – because it’s really hard to fill out a security team, and to stretch out around the organisation.
But that’s not the whole answer.
Ask the security-conscious developers what’s preventing them from becoming a security expert to their team, and they’ll make it clear – they’re rewarded and/or punished at their annual review times by the code they produce that delivers features.
There is no reward for security
And because managers are driving behaviour through performance reviews, it actually doesn’t matter what the manager tells their underlings, even if they give their devs a weekly spiel about how important security is. Even if you have an executive show up at their meetings and tell them security is “Job #1”. Even if he means it.
Those developers will return to their desks, and they’ll look at the goals against which they’ll be reviewed come performance review time.
The Manager in the Middle Attack
If managers don’t specifically reward good security behaviour, most developers will not produce secure code.
This is the Manager in the Middle Attack. Note that it applies in the event that no manager is present (thanks, Dan Kaminsky!)
@ftp_alun @TimelessP also, a No Manager In The Middle attack
— Dan Kaminsky(@dakami) November 10, 2015
Managers have to manage
Because I never like to point out a problem without proposing a solution:
Managers have to actively manage their developers into changing their behaviours. Some performance goals will help, along with the support (financial and moral) to make them achievable.
Here are a few sample goals:
- Implement a security bug-scanning solution in your build/deploy process
- (Even “grep strcat *.c *.cpp” is better than nothing)
- But, you know, Fortify, Veracode, or go find a list like https://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html (but from this decade, ideally)
- Track the creation / destruction of bugs just like you track your feature burn-down rate.
- It’ll be a burn-up rate to begin with, but you can’t incentivise a goal you can’t track
- Prevent the insertion of new security bugs.
- No, don’t just turn the graph from “trending up” to “trending less up” – actually ban checkins that add vulnerabilities detected by your scanning tools.
- Reduce the number of security bugs in your existing code
- Prioritise which ones to work on first.
- Use OWASP, or whatever “top N list” floats your boat – until you’ve exhausted those.
- Read the news, and see which flaws have been the cause of significant problems.
- My list: Code injection (because if an attacker can run code on my site, it’s not my site); SQL Injection / data access flaws (because the attacker can steal, delete, or modify my data); other injection (including XSS, because it’s a sign you’re a freaking amateur web developer)
- Don’t be afraid to game the system – if you can modularise your database access and remove all SQL injection bugs with a small change, do so. And call it as big of a win as it truly is!
- Prioritise which ones to work on first.
- Refactor to make bugs less likely
- Find a widespread potentially unsecure behaviour and make it into a class or function, so it’s only unsecure in one place.
- Then secure that place. And comment the heck out of why it’s done that way.
- Ban checkins that use the old way of doing things.
- Delete old, unused code, if you didn’t already do that earlier.
- Share knowledge of security improvements
- With your colleagues on your dev team
- With other developers across the enterprise
- Outside of the company
- Become a sought-after expert (inside or outside the team or organisation) on a security practice – from a dev perspective
- Mentor another more junior developer who wants to become a security hot-shot like yourself.
That’s quite a bunch of security-related goals for developers, which managers can implement. All of them can be measured, and I’m not so crass as to suggest that I know which numbers will be appropriate to your appetite for risk, or the size of hole out of which you have to dig yourself.