It can definitely be tempting if your engineers don’t have a whole lot of security expertise to get a consultant in. Indeed this can be a great way to bootstrap a security process, however it then needs to be owned and executed inside the team. The reason has mainly to do with the goals of your developers and of the consultant.
Fuzzy logic
The consultant’s high fee is based on being able to come in to a new team and quickly make a high impact. This means, of course, rapidly reporting low-hanging problems. It also means that all of the reported problems are important – it’s a good job you hired methis anonymous consultant, having found all of those critical issues, no?
The fact is that most of the security problems found by external security consultants and penetration testers are those that can be found in short order by a script kiddie – in other words, ones it would take very little effort to write automated tests for. In fact that’s pretty much what consultants, pen testers and script kiddies do, and it’s called fuzzing. Now, if you’d given the task of writing the fuzzing tools to one of your developers, you’d be slightly more behind schedule (than you already are because you’ve got to fix those data-handling defects), and you’d have a developer who knows how to write fuzzing tools.
Finding architectural and requirements-level security problems is not impossible for a consultant, however we only really have a second hand knowledge of the requirements and architecture (and it’s likely that we got that from talking to your developers, unless you have some really shit-hot and surprisingly relevant documentation. Hint: you don’t). What we bring to the party is a thorough knowledge of threat analysis and risk management, which we then get to apply to an unknown project. Your developers have an inside-out knowledge of the project, but probably aren’t as experienced as me at carrying out security assessments.
Don’t get me wrong, the consultant will definitely find real problems and will probably leave you in a position to deliver a more secure product. However, in order to get most value out of the consultant’s input, you need to make sure that your project’s security model and security knowledge remain up to date, and that means bringing it at least partially in house.
Security champions
Make sure that every development team has its own security champion. That person’s responsibility is:
- Define the team’s security process:
- How is the threat model discovered/updated?
- How are security problems found and reported?
- How are they addressed?
- Ensure the process is followed
- Define security criteria for each iteration, user story, or whatever makes sense in your project management setup
The champion is authorised to:
- Delegate responsibility for carrying out tasks in the security process
- Declare any build/user story/iteration/whatever to be a failure until its security criteria are satisfied
As we know, responsibility without authority just means you have someone to fire. A team can only get things done if they’re actually allowed to ensure they get things done. Sounds like common sense, but many software engineering managers fail to grasp it.
In our team, everybody is the security guy. We share the responsibility.
Bullshit. You get nothing done. If everyone is responsible for a problem, then everyone knows that somebody else can deal with it. I’ve seen software released with known and rather heinous vulnerabilities, all because no-one wanted to be the person who delayed release just before the ship date. Don’t allow your project to get into that state – give someone ownership of the security efforts.
