Colleague (in a meeting): “For twenty years, people have been leaving security till last.”
Me (in response): “You could have left out those last two words.”
This article will be a short one, and it’s a plea. It’s also not aimed at my regular readership, because if you’re part of my regular readership, then you don’t need telling. Many of the articles on this blog, however, are written with the express intention of meeting two criteria:
- they should be technical credible[1].
- you should be able to show them to your parents or to your manager[2].
I suspect that it’s your manager, this time round, who I’ll be targeting, but I don’t want to make assumptions about your parents’ roles or influence, so let’s leave it open.
The issue I want to address this week is the impact of not placing security firmly at the beginning, middle and end of any system or application design process. As we all know, security isn’t something that you can bolt onto the end of a project and hope that you’ll be OK. Equally, if you think about it only at the beginning, you’ll find that by the end, your requirements, use cases, infrastructure or personae will have changed[3], and what you planned at the beginning is no longer fit for purpose. After all, if you know that your functional requirements will change (and everybody knows this), then why would your non-functional requirements be subject to the same drift?
The problem is that security, being a non-functional requirement[4], doesn’t get the up-front visibility that it needs. And, because it’s difficult to do well, and it’s often the responsibility of a non-core team member “flown in” as a consultant or expert for a small percentage design meetings, security is the area that it’s easy to decide to let slide a bit. Or a lot. Or completely.
If there’s a trade-off around features, functionality or resource location, it’s likely to be security, and often, nobody even raises the point that there has been a trade-off: it’s completely invisible (this is one of the reasons Why I love technical debt). This is also the reason that whenever I look at a system, I try to think “what were the decisions made about security?”, because, too often, no decisions were made about security at all.
So, if you’re a manager[6], and you’re involved with designing a system or application, don’t let security be the invisible trade-off. I’m not saying that it needs to be the be-all and end-all of the project, but at least ensure that you think about it. Thank you.
1 – they should be accurate, to be honest, but I also try not to dive deeper into technical topics than is absolutely required for context.
2 – to be clear, this isn’t about making them work- and parent-safe, but about presenting the topics in a manner that is approachable by non-experts.
3 – or, equally likely, all of them.
4 – I don’t mean that security doesn’t function correctly[5], but rather that it’s not one of the key functions of the system or application that’s being designed.
5 – though, now you mention it…
6 – or parent – see above.
Alice, Eve and Bob - a security blog 