Some people think agile is about going fast and being unconstrained by processes. That’s part of it, but that aspect alone is also not that far from the definition of anarchy: a state of disorder to due the absence of authority.
What agile is really about is being able to make effective decisions, and that those decisions are made based on doing the right things to hit the target you’ve set without getting lost.
That means real agile is about is how to successfully manage the risks so you deliver what you’ve set out to do, whether that’s deliver a piece of software or create value for a customer.
I know I’ve talked a lot about architecture the last couple of days, and that’s certainly a key part of it, but when we frame agility in terms of making decisions, what we discover is that there’s two different types of decisions we need to think about in security.
The first set of decisions are the ones we make every day, and that’s why the principles of The Agile Security System™ are so important. In fact, they align exactly with the guidance in a recent HBR article for achieving both alignment and autonomy in an organization.
According to the article, which references the unique challenges the military faces to both provide strategic direction yet allow tactical freedom in how to get the job done, there are two key elements:
- what’s called “Commander’s Intent” or the purpose of the operation and the conditions of success, and
- Doctrine, or the fundamental principles that guide action in support of delivering the purpose
So with the 7 Principles of the system, we have the guides in place that guide our actions in security—and it’s not just about building architecture. It’s about the end-to-end delivery of security across the whole team. After all, the name isn’t The Agile Security Architecture System.
And we already have a mission and purpose of security that would meet the Commander’s Intent aspect above. It’s about making sure we’re making security decisions that are aligned with keeping the business doing what it needs to do.
But the second part – the second set of decisions – is where it gets really interesting, and it’s also where the value of the architecture becomes really apparent.
If I create a security architecture according to SABSA, the purpose of that architecture is to define the structure and requirements of my organizational security polices. We get those based on evaluating the risks for each of the different types of risks that each set of significant elements are subject to in our organization.
The way we represent those policies are based on the attributes and their performance targets associated with those domains. That’s basically what defines part of the security intent, and the rest is defined by the control and enablement objectives we establish for each of those domains. Effectively, depending on how you structure those, and because the beauty of principles is that they can nest, we can almost say that these are elements of doctrine—taken in the context of our core principles of the system itself.
Why?
Well, the point of the policies – and those attributes and the performance targets – is to give parameters for making decisions across not only security, but the entire organization. This is where I was coming from with the whole “Organizational Mind Control” vibe in some of the emails for the October newsletter.
Without the architecture, we don’t know what intent and doctrine applies where. The decisions people make are effectively unconstrained when it comes to security, and we have a big mess.
We can also go too far the other way—constraining people’s activity and behavior to the point where they can’t make any decision, and that’s basically when we stop the business.
But if we do it right, we establish boundaries and constraints on the nature and scope of the decisions that can be made, and by doing this, we give people the freedom to do what they need to do, their morale is better, and they’re also automatically aligned with the overall mission and purpose of the organization.
That’s really what The Agile Security System is all about putting in place. Architecture’s a key part, but it’s really the system that builds a framework for making decisions that’s what really sets it apart from the process-heavy, prescriptive and overwhelming approach to delivering security that we’ve been led to believe is necessary.
It isn’t.
So, if this sounds intriguing to you, you can learn all about how to apply the system in your own organization in the upcoming book, The Definitive Guide to The Agile Security System, whether you’re a security leader or a security architect, or really anyone else who needs to make security decisions.
But there’s a catch, and you probably know what it is. We’re still shy of my target of 10 pre-orders to guarantee the book actually gets finished and will ship in mid-January.
Normally, learning about the system and how to apply it takes working with me in our online courses (either 7 or 14 weeks of intensive, practical skill development) or as part of our flagship coaching and mentoring program, which normally runs in 3-month sprints.
As you might guess, they cost several thousands of $$$, and that means they’re not accessible to everyone. But the book brings the method, it’s application and 3 fully-worked examples to a wider audience for the pre-order price of $247.
Still not cheap. And it’s only going to be available as a print book, shipped to you months from now, and if and only if there’s enough interest in it.
If we do hit the target, then the price will go up on the 1st of November by at least $100 for the pre-orders, and then in January, the only way to get it will be paying the full price of almost $500.
There’s also some bonuses I’ve talked about too. There’s a SABSA-ized version of the CIS20 control library that you can plug into your existing security architectures (and see where both it and you are not as covered as you might’ve thought)
And then there’s the set of 55 attributes lifted from the Archistry Execution Framework Reference Architecture that are primarily different to those found in the Blue Book, each with full documentation, annotated and typed using the Archistry Security Modeling Language™ (ASML) ontology for some super-secret stuff coming in the future.
And then there’s the ASML stencils themselves as Bonus #3, so you can draw consistent security architecture models and not have to roll your own notation for the essentials of building and communicating security architecture.
But it’s probably not for everyone. You may not agree with my approach, or you might not agree with my take on SABSA. You might want to take your own 14-year journey to come up with something new, different and quite possibly better than the system I’ve developed based on my own practice.
It’s all possible.
Still…if you don’t want to go through years of false starts, blind-alleys, hair-pulling, and sometimes screaming in frustration as to “there’s gotta be a better way!”
…then maybe the book’s a good place to start. If you want to be one of the first to get it – and be responsible for helping to make it happen in the first place – then you’ve only got just over 2 more days to pre-order it for $247 before the price goes up using this link right here:
If you do, super, and I will really appreciate it. If you don’t, then, hey, maybe next time. Everyone needs to make their own decisions about the best path forward in their own personal and professional skill development.
Nobody can make that decision for you. Just don’t take too long to decide if you’re sitting on the fence and get all upset that if you change your mind later you could end up paying twice as much.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
P.S. And if you’re interested in subscribing to the monthly print Security Sanity™ newsletter where The Agile Security System™ first appeared, you can start with the next issue here: https://securitysanity.com
