This was a topic that came up during one of today’s sessions at COSAC. Originally, it was about software developers making business decisions because they weren’t aware (or chose to ignore) key business or legal requirements when they were actually implementing the software that runs the business.
Now there’s a lot of issues with this, but it’s actually the same root cause that I’ve been talking about for the last couple of weeks. It’s a breakdown in the Requirements Engineering process used to capture and translate the real requirements into something you can use to guide the implementation, validation and testing of the software.
When you extend this to security policies, it’s truly the birth of the Department of No. It gives the security team license to claim they’re making decisions in the name of keeping the organization safe.
Unfortunately, that’s not good enough. It’s only half of the mission and purpose of security. You can’t just keep the organization safe in a vacuum, because you don’t know what safe really means. Safe from what? The basics?
What basics?
What’s the value in safety anyway? Keeping the organization safe to do what?
These are all questions that are either answered in a way that empowers and enables the organization…
…or in a way that stops it dead in its tracks, destroys your reputation and credibility within the organization, and makes you the target of active avoidance tactics as far as your business customers are concerned.
Because that’s what you’re doing if you can’t walk the traceability between the organization’s security policies and the goals, objectives and the operating constraints they’re meant to support.
Getting it wrong gets that much more complicated in Agile environments, and even in traditional SDLC or V-model environments, additional layers of “translation” between the security team and the customer can result in security making business decisions about what is right and wrong.
That’s not our job, and we can do better.
But you won’t understand how until you understand what Requirements Engineering really is, how it works, and how it relates to the security policies you’re really trying to create.
We’re down to the wire to get your hands on the October issue of the Security Sanity™ print newsletter that tells you about how to do this right and build the right security policies that are flexible and modular enough to both enable the organization and traceably justify the value.
And while if you know SABSA already, you can go a long way with that basic knowledge, there’s more to it than just core SABSA that many people don’t realize. And when you don’t realize it, you’re going to continue making the same mistakes we’ve been making for the last 30 years.
To make sure you get this issue, you’re going to need to make a decision today. After today, you’ll have missed it.
Maybe that matters. Maybe it doesn’t.
If you decide it does, and you want to have confidence you’re enabling the business and can fully justify and demonstrate the business value of your security decisions,
here’s the link: https://securitysanity.com
It’s the last chance. After 11:59pm US/Eastern, you’ll have missed the boat.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
