Here’s a scenario you might recognise.
You're a new employee at a company and on your first day, you get given a corporate laptop. You need to set your password, so you create a unique phrase, 3 words long, and add a single capital letter and number. In all, your password is 20 characters long.
But then the system says “no” even though the password seems strong. You’re told not to have any repeating characters, and to have a symbol. Your immediate reaction (after dammit, I'll fix that) is "Why? My password is already strong".
Often, when non-security folk come across controls like this while trying to get their job done, it’s simply frustrating. (Security settings like this are called “controls” in the lingo.) To them, the question is “Why is this limitation here?"
The same applies in development; the frustration around security controls that impede work for no obvious reason is especially prevalent. In an effort to meet the pressure they're under to deliver new features, developers look for the most speedy way to comply with security controls, even if they know of a better way that would take a little longer.
If I sound like I'm being harsh on developers here, I'm not trying to. They are under pressure to deliver new technology in the fastest possible way. In most tech businesses the pace of technology delivery is more important than anything else.
If the reason for a control isn't evident, developers (and users) will be far less motivated to comply with the spirit of the control, and instead, attempt to get around it. After all, everyone has jobs they're trying to do.
At the same time, the security teams in most tech organisations I've come across are under significant pressure. They will likely be facing a constant stream of security updates, a changing business risk picture, new application deployments (therefore shifting the attack surface) and alerts from a monitoring platform. That's before you get to the evolving capabilities of the attacker, proactively finding and configuring appropriate controls in your tech stack, reporting metrics to stakeholders, and so on.
The only way to help the security team stay on top of their wide remit is to nurture a healthy security culture. For that to happen, people need to be briefed, not just on what to do to stay secure, but on why those things help and why security is needed in the first place.
By explaining why a control exists, you help your users and developers understand the risk it is trying to mitigate, leading everyone to take the control more seriously. This is something we generally refer to as strengthening security culture.
The key to creating this culture is transparency and improving communication around an organisation's security posture.
Being transparent helps everyone understand what you're trying to achieve as a business and the importance of those daily ways security can be seen to impede the day job.
So, how do you get this transparency and communication, to boost your security culture and help manage the load on your security team?
My answer for tech businesses is the threat model. Threat models are a clear and comprehensive way to describe security measures in terms of the business risks they alleviate. Simply put, they link security controls to threats, and threats to risks. This is essential to improving the communications around your organisation’s security.