It’s surprising how many software development teams lack the fundamental knowledge of what they are defending against in terms of security and privacy.
This is not a new problem. Indeed, misunderstanding of non-functional requirements go back to as long as software development itself. I remember many years ago when I was working with Reuters on dealing room systems, I happened to be in a dealing room and see an angry financial dealer say of my system “The prices are out of date! Get this thing off my desk – I never want to see it again.” And I realised that the one non-functional requirement that a dealing room system had to have was never, ever, to show out of date prices without a warning. But—and this is worrying—I had worked for five years in teams delivering dealing room software without learning that. None of my developer colleagues knew it either.
And the fundamental requirements in terms of security and privacy can be just as unobvious to the technical development team as that one was. For example, I worked recently with a brilliant team working on strategy planning software for large companies. They were very successfully defending that software against possible attacks from unknown nuisances in North Korea. But when they thought about it, they realised that the worst possible thing to happen would be for someone else within a customer company to see information they weren’t supposed to; if senior management is considering major changes, having software leak it to the wrong people could be a disaster! Their main security requirement was very different from standard ‘security’.
Indeed, I have worked with many teams on this, and I find almost every time misunderstandings between the technical team and the business team about the importance of different aspects of security and privacy. So, what do we do about it?
The answer turns out to be Threat Assessment. This is not the same as what Microsoft call ‘threat modelling’, which is generally looking for actual defects or ‘vulnerabilities’. Threat Assessment is looking to see what aspects of security and privacy are important, and why. To do that of course you start with a simple “what could possibly go wrong?” Or, more commonly, “who might do what bad thing to whom?” Either way, as we’ve already established, the results will usually not be what you expect. The best ways to do this are usually some sort of brainstorm or ideation session. To the ideas you generate in that way, you can add lists or pre-existing threat assessments.
I’ve written elsewhere on how you can take the list of threats and prioritise them based on likelihood and impact; and then of course you have the interesting challenge to present them to the business in a way that makes decisions about them easy. And we can help there, too!