May 21, 2020
On a call today, I was reminded of one of the recent challenges facing security architects – or even security leaders (BISOs and CISOs) – who understand the value of architecture and know that it has an essential place in software development—no matter what approach you’re using. This challenge is most often heard from “agile” teams, and by the quotes, I’m generally meaning those teams using what Andy Hunt, one of the originators of the Agile Manifesto calls “flaccid agile.”
Real agile is a risk-based approach to software development. It works, and there’s no question that security should be a part of it.
Flaccid agile is people pretending that they’re doing agile just for the “no rules” and “burn the processes” cries against the establishment like they were trying to live the myth of the 1968 bra-burning protest, during which, of course, no actual bras were torched—only trashed.
While not exactly called out in surveys, as best I can tell, of the 97% of organizations who claim to actually use agile development methods, most are still falling flaccid in practice, since when you drill in and look at the actual practices employed, many pick-and-choose what’s convenient or fun, falling perfectly into Andy’s description:
“And if you only pick a handful of rules that you feel like following, and ignore the hard ones, then you’ve got it made! You are ‘doing agile’ if anyone asks, and you can focus your energy on enforcing a small set of largely useless rules. Everyone feels better. Until It’s time to actually ship something.”
Judging by my reading, the flaccid camp makes up between 80-90% of those 97% of organizations “doing agile.” And because they don’t really understand what they’re doing, they’re exactly right:
There is no time for security.
In fact, there’s no time for anything “hard” at all…like actually embedding a customer into the age team…like allowing the designs to emerge organically based on what the ongoing and changing needs of the customers actually are.
However, I didn’t say let the *architecture* emerge organically. That’s a whole different game. That’s why it’s hard. But even that its hard, most of the agile teams are spinning their wheels with their particular agile methods and automated tooling rather than getting their principles right…
…and delivering value in an agile way.
So the response to the “we don’t have time” mantra is really asking the simple question:
Where are you spending all that time if you don’t have time for security?
Because agile security done right is completely integrated to agile delivery. And that’s true because agile security is actually PREPARED AHEAD OF TIME for just about everything the delivery team is going to need to do, face or counter.
Why?
Because they have the right security architecture in place. A risk-based architecture that understands what’s significant and what will vary across each and every one of those 10,000 deployments a day your delivery teams claim to do.
Do those 10,000 deployments represent 10,000 different applications?
…built on different technology?
…processing different information?
…storing data in dramatically different places?
…serving different sets of customers?
…delivering dramatically different value?
Um…gimme a minute. No. Hold on.
Um.
No.
Nope.
No.
No.
Nope.
And not a chance.
So, in that model, I dare any development teams with performance issues to show me precisely where all this “extra time” it takes for security is supposed to come from.
Sure, they might try. But, without exposing their own DD (development disfunction), they’re not going to be able to do it.
Because all those places where they claim, “Security just slows us down, man!”
Are all places where they’re avoiding the “hard stuff” of agile in the first place.
And speaking of hard stuff, if you want to keep your security program ready for action as well, you need to avoid much the same types of traps, or you’re gonna end up with a flaccid security program so dead that no amount of blue anything is going to be able to wake it up.
Naturally, I think the key to all this is security architecture. And, in particular, security architectures built with SABSA. But not just done any ol’ way. They need to be done in a way that delivers guaranteed incremental value, focuses on principles over process and which can “float like a butterfly and sting like a bee” with Mohammed Ali levels of true agility.
But before you think this is totally impossible based on what you may or may not know about SABSA, I have 15 years of practical experience that would tell you otherwise. And there are a growing list of global organizations who’ve been successful in seeing that value first-hand in the last 11 months since the very same method I’ve honed into the hardened steel of a fine katana that is The Agile Security System™ was first published last year. It’s a tool sharp enough to cut through the crap and dead weight keeping you, as an individual architect, from starting immediately to build the security architecture you need…
…to help you make the correct, prioritized control decisions your security customers desperately need so that they can focus on getting done whatever it is they’re doing…
…instead of waiting with dread for yet another visit from the Security Policy Police intent on shutting them down, locking them up and throwing away all that potential business value they were trying to create.
As a security architect, you have a choice. You can take the time to figure out how to do proper risk-driven security architecture on your own, from scratch, and earning with pride all the bumps, scrapes, bruises and setbacks you’re gonna face on your way to get there…
(I know. I’ve made probably every possible mistake you could make in that 15 years)
…or, you can decide to invest 7 weeks and a small bit of cash to learn what I know now, and fast-forward through all that crap and get focused on adding value to your organization, building a more effective security team, and increasing your own personal skillset and marketability.
It’s up to you.
If you’d like to thrash your way though the thicket on your own, I won’t try and stop you. After all, I did it, so I can’t blame you for wanting to try it too.
But if you’d like to take the 8-lane highway to building a true security architecture you can begin using immediately following the program (if not before)…
…not to mention ask me anything you want to know about how to put what we’re covering and the exercises you’re doing into practice to address your own architecture problems, each and every week on our live Q&A calls for the duration of the program…
…then here’s the link to register for the next cohort, starting the 6th of July:
And if you act in the next 2 days, 8 hours, 52 minutes and 20 seconds as I write this email, you’ll be able to get in on the Pre-registration discount and save $1,000 off the regular registration fee that kicks in at 12:00am US/Eastern on Sunday, May 24th.
Thicket or Thunder Road? Which choice makes the most sense for you and your organization?
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
