There’s a lot of talk about Agile these days. Everyone’s doing it—well, almost everyone. And those who aren’t are a particular shade of green with envy and full of laments, remorse and frustration as to why they can’t be agile too.
But here’s the thing about “agile”…it’s the thing that applies to quite a lot of concepts and words in particular—especially in security. And this thing was very eloquently voiced by Inigo Montoya in The Princess Bride when he said:
“You keep using that word. I do not think it means what you think it means.”
And I can’t promise that I won’t use that phrase more than once over the next few days and months,
…because the reality is that we’re faced with this sort of thing all the time.
In linguistics, it’s called “semantic overload” or sometimes you’ll also see “concept overload”. And this is something that happens when a word or phrase has more than one meaning…
…and what “meaning” really “means” (pun intended) is that it has more than one interpretation.
Now, if you think about it, the only thing you have to truly disambiguate – or clarify, for those non-Wikipedians – is the context in which it’s used.
But context is in the eye of the one making the statement, unfortunately. Not from the perspective of those hearing the word.
Which brings us back to our word for today, “agile.”
Now, for several years now, “agility” has been the holy grail of business, and then, having successfully demonstrated “agility” in a manufacturing context, “The New New Product Development Game” article was published in HBR in 1986, giving rise to the Scrum we know today. And then…the early movers and shakers in the “agile” software development codified all that learning from the physical manufacturing world and gave us the “Agile” movement for software development.
But let’s be clear: there’s a big difference between the “agile” of the business is after that they call “business agility” and the “agile” that we generally encounter on a day-to-day basis in the technology world.
For the business, we’re closer to the dictionary definition. I’m writing this on a Mac, so I’m using Apple’s dictionary.
It says: “able to move quickly and easily.”
Because that’s what the business wants to do. They want – as an organization – to be able to recognize a new market opportunity, create a product or service and start making money from it as quickly and easily as possible.
So the organizational ability of “being agile” is to be able to put up the lemonade stand on a hot day in the front lawn before the kid across the street so that the moms and dads out walking dogs, pushing strollers or mowing the lawn give you money before the next guy.
But that’s about today. Tomorrow, it might be about buying a lawnmower and going around knocking on doors with an overgrown lawn and offering to solve that problem for only money and let the buyer sit around in his boxer shorts, watching TV and drinking beer with the AC cranked so they don’t have to go out and try not to have a heart attack.
Bear in mind: this is the same organization. Not different ones. Not two, independent start-ups. One. Big. Organization—with deep pockets and the resources to pull it off. Build…buy…steal. Doesn’t matter. It’s about being able to react to the opportunity.
And when the opportunity passes, then we set fire to the lemonade stand, or we sell the lawnmower for $30 at the second-hand shop, and we move on to the next one.
Today – at least in the tech darlings of the world and to the avid hordes of wannabes following their every move like a Chav follows the highs and lows of the celebrities in Hello! Magazine—while wearing their pajamas to do the shopping at Tesco, mind you – Agile has a bunch of different cults, each with their own lexicon, rules and rituals…
And that’s fine. While it might seem like I’m anti-Agile, I’m not.
I just get tired when people don’t really understand it—and if you’re thinking that I don’t understand it either, well…that may be. I certainly won’t hold it against you if you think so.
But “agile” in technology generally means it’s about building software.
And software…is an application.
And a “service” is one or potentially more than one application working together – possibly supported by one or more manual processes – that creates some kind of value to Ye Who Hold The Olde, Almighty Credit Card.
But it’s basically still just an application with a severe case of narcissism—at least from the perspective of the rest of the organization.
So, you have Agile (development)…
…and then you have Agile done a particular way, and it’s name is DevOps
…and then it got tired of crashing against the nearly impenetrable walls of The Department of No (us silly security people, just in case I lost you)
…and thus DevSecOps was born—thrust into the world as the salvation of Agile and the way to smite the problems of The Department of No forever!
[cue the amazing brass-led soundtrack, thunderclaps and lightning effects]
And, of course, DevSecOps is “the future of security as we know it!”
“Security Self service”
“Security as Code”
“Security Shifted Left”
Ok…sure. There’s actually lots of great things about DevSecOps.
But it’s “security” in the middle of – and concurrent with – DevOps.
And DevOps is what?
A way of doing agile software development.
And why do we develop the software?
Because we want to build an application.
But not just any application, the Tony Stark of applications c. the first Iron Man movie.
Which means that the “salvation of security” is really about only one thing: Application Security.
So what about the rest?
Unless you’re an Internet or Web company built around a pretty tight set of services (or an amalgamation of lots of individual internet companies each running more-or-less autonomously), there’s a “the rest.”
And in fact, there’s always a “the rest”—even in the Internet and Web companies we’ve worked with as customers.
So where’s DevSecOps in relation to the rest?
It’s an island.
Sure, it’s an Agile island, but it’s still an island.
So unless you are (or report to) the CASO (Chief Application Security Officer), if you want to have truly agile security across the whole organization, you’re gonna need a different plan.
What is it?
Funnily enough, that’s exactly what I’ll be writing about in the August issue of the brand new Security Sanity™ newsletter.
It’s expensive. It’s not for everyone. It’s real paper you can hold in your hot little hands.
And it’s only available to you if you subscribe before the end of the month when it goes to the printer for distribution to the four corners of the Earth.
So, if you don’t want to miss it, head ye on over to the link below and subscribe now:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
P.S. Here’s something you can do if you liked today’s post: you can sign up for those daily emails that annoying pop-up keeps asking you about. Or, if you want to know more about what you’re going to get if you do and how it works, then just go knock on the front door: https://archistry.com and you’ll get the whole deal.
Or…you can just keep reading the blog, or ignore me and Archistry all together. I’m good either way.
