Whether or not you’re cutting the rug with Linda Lou or shakin’ like a leaf on a tree, one thing you need to know about requirements if you’re going to have a hope of tryin’ to prove they’re the right ones you should be including into your security program is that there’s 3 types:
The first one is functional requirements. Now these are the ones most everyone knows at first glance, and they’re the main focus of most requirements exercises.
The second one is quality requirements. These are also referred to as the aptly un-descriptive “non-functional” requirements of whatever it is you’re trying to build or support.
And the third one is the constraint, which is…strangely enough, exactly what it says on the tin. These are what makes architecture architecture instead of pink fluffy clouds high in the sky where the rainbow-tailed unicorns frolic the day away.
Constraints drive architecture and design decisions, and they limit the scope of what you can and can’t do in trying to deliver or support those requirements.
So why am I telling you about this?
Well, first off, while you might understand requirements engineering in the general sense of systems development, but there are some twists on this when it comes to security that might trip you up. And its these same things that are also why your friendly, neighborhood BA might not be the bestest, tippy-top choice for engineering those security requirements after all.
Secondly, in terms of the priority of the requirements and their influence on the security controls in your organization, it’s almost the exact opposite of what they would be for systems development. Because the constraints and the quality requirements lead the way.
These are the ones that are most directly expressed in your “product” of security (which will have to remain a mystery for another day), and those functional requirements need to undergo a bit of massaging before they’re generally very useful from a security perspective.
So the question becomes: what does this mean to me, and how do I put it all together?
What it means is that there really is something to this whole RE lark after all, and the security requirements don’t just ooze up from the controls with blinking lights and vendor stickers on them. You need to turn the crank—but you need to turn the RIGHT crank…at the RIGHT time…so you get something useful you can point to, parade around and get everyone’s general consensus that these are, in fact, the droids you’re looking for.
How you put it all together requires you to understand how one system intermingles with another system inside the overall system of your organization. Because if you don’t, you’re going to make the same mistakes engineering teams have been making for over 30 years.
…but you don’t want to do that.
You want to have business-driven, traceable security programs that have their value so obvious it’s like they’re dancing on the table. You probably know the basics, but the basics aren’t enough to build credibility and trust with your customers.
If you want to know all the Wile E. Coyote ways you can ensure your security product is fit-for-purpose and you’re doing all the right things to earn that customer trust…
You might want to check out the upcoming October issue of the Security Sanity™ newsletter, where we do a bit of deep dive on the lesser-discussed parts of RE that will ultimately do more to make or break your security program than you might think.
In September you learned the techniques for effective stakeholder interviewing, so this month’s issue will ensure what you learn of your customers’ worlds is effectively poked, prodded and sometimes beaten into submission – delicately, of course – so you have the best chance possible of keeping your organization safe.
Here’s the link: https://securitysanity.com
The clock is ticking, however, because in exactly 7 days, it gets shipped out, and, just like that fellow with the hair colored yellow, you ain’t never gonna see it no more.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
