What Makes a Secure Development Process?

Let's look at a Secure Development Process that I developed working with Alec Muffett and the Penrillian team. First, there are several kinds of threat, as I discussed here.  Mainly they come from human attackers who wish to cause harm of some kind to the users; our job is to prevent them.  But there are other forms of security too; any situation where the software misbehaving could do harm is a security issue.

 

So a secure process is different from a normal development process in that it needs to cater for these rather abstract threats – which may include indeed the developers themselves.

So what do we need to ensure? We’ll need to do quite a few things:

• Think in advance what the threats might be, so that we code around them.
• Create mitigations for each threat – ways we can change our code, or a design to counter the threats.
• Ensure we implement the mitigations in the code.
• Have external testers do "penetration testing", pretending to be attackers, and seeing what standard attacker techniques will achieve against our code.
• Have reviewers, external specialists in security, look at our code for possible weaknesses.
• Ensure that we learn from any issues that we identify, external testers identify, and other reviewers identify, so that we don't incorporate them again in future projects.
• Make sure that nothing falls between the gaps: that our responsibilities and the responsibilities of other participants in the project are clearly separated, so that there are no misunderstandings as to who is responsible for what.

Now we could imagine a nice heavyweight process with lots of form filling and bolshie "security experts" ensuring that everything is done right.  But that doesn't work well with an Agile process; instead we like to keep everything as lightweight as possible.  So we need a secure agile development process for secure projects.  We want to achieve all the above (and even the ISO certification) with a minimum of overhead.  How do we do that?

The essential documentation is that which forces us to consider the problem, and that provides a record for the future.  For a secure development process to cater for the above risks, we believe we need a minimum of three documents:

1. A threat identification document, identifying the threats and mitigation for each.
2. A security scope document, identifying the boundaries to the project and specifying what threats are out of scope.
3. A database of some kind, whether a large document, a spreadsheet, or something else, identifying specific security threats we've encountered, available for use as a checklist on future projects.

That’s handled the documentation. For the database we can use any defect tracking system, by adding tags for the security-related issues.

All the rest is development process. The project manager and team need to:

• Ensure the security mitigations are scheduled along with the other function points for development.
• Commission Penetration testing and Code review by security experts as required, and negotiate and implement changes based on their feedback.
• Ensure the Testers test the ‘mitigations’ described in the documents.

It can be useful to have a ‘security officer’, who keeps track of all the issues across projects and educates the individual teams on what’s needed.  But it’s not essential.

 

And that’s it.  A lightweight process that nevertheless will produce reliably secure software.

 

- Charles

 

Image credit: EtiAmmos/shutterstock.com.  Text by Charles Weir, copyright (c) Penrillian Ltd, used by permission.