Security Negotiation

It’s rarely the programmers’ decision which security enhancements to implement. So help your product manager by expressing problems, risks and costs in helpful terms! 

When you have identified threats, and done a risk and mitigation cost assessment for each  what should be your next step?

In a few cases, simply knowing about each threat may be sufficient: the developers can make choices that avoid the security issues. They may require care in coding, or influence the architecture and design choices. However, for many of the threats the mitigations will require support: either because they involve significant cost or effort; or because they are outside the scope of the development team. What do we do about those?

In most projects, it won’t be commercially sensible to address all the security issues identified. There will always be a trade-off between the effort and cost required for security improvements, and other practical demands such as the need for new functionality or the need to save and money. The best commercial decision may also be to defer some mitigations to a later stage in the project. 

And it has to be a bit of a trade off as well in terms of business. You’ve got to make the trade off as to what’s good for getting a solution available now, and having one available in a year’s time, which no one will buy, because everyone’s gone with one which doesn’t even consider security at all. (Business App Developer)

This means that perfect security is not only very difficult; it is not in fact what we want. It is sensible and good business practice for an organisation to accept a level of insecurity. 

And actually the way this works, in practice is you have to do less than a perfect job, in order to have a measurable degree of failure or fraud or whatever, so that you can adjust your investment and say ‘I am managing this to an economically viable level’ because if it is zero, you have invested too much. (IoT Security Consultant)

How are the development team to support the decision which security mitigations are carried out? 

Software development involves many choices: what functionality to include; what non-functional requirements to satisfy; how best to implement it. Software security adds to these choices: how do the benefits of mitigating each security issue weigh up against other possible uses of the resources required? 

Let’s call the role that makes those choices ‘Product Manager’. In practice, the people concerned may have a variety of titles: ‘CEO’, ‘customer’, ‘product committee’, ‘project manager’, amongst others – or it may even be the developers themselves.

What is apparently new for a Product Manager is that security decisions involve understanding risk: rather than ‘if we choose this, that will happen’, it is usually ‘if we don’t choose this, that may happen’. But is it really new? Even without considering security, Product Managers already make decisions based on uncertainty: development timescales usually involve risk of overrun; choices between functionality involve uncertainty as to which will pay off; many other factors make the outcomes uncertain. Product Management already deals with risk.

In order to make good decisions, though, a Product Manager needs to understand the risks involved, the potential costs of not having each mitigation, and the actual costs of implementing it. It is the role of the development team to provide that information. 

For each threat that needs consideration, the Project Manager will need:

1. Cost estimate: An estimate of the effort required to implement the changes required – in time, and in some cases money.
2. Impact description: A non-technical description of what the threat could mean in practice for the organisation and the software users. E.g. ‘A public leak of our customer data, reported in all the news services; and a corresponding very large fine.’
3. Risk description: An estimate of the likelihood of the threat being realised over a given timeframe if nothing’s done. E.g. ‘very likely within the next two years’.

This may be quite informal. One developer describes the negotiation as a conversation about security:

[When I started] a project I’d go back and ask [my customer]…‘You do realise this [information] can be seen’. It goes from there: ‘how secure do you want it to be?’ (Secure App Developer)

In an agile development environment, these mitigations typically appear as tasks, for the product manager to organise and prioritise along with the rest. 

To us as developers, the choices made by product management aren't always what seem right to us. But, hey! That's business.