It seems the above is very much “the question” on the minds of security teams looking to take the CI/CD plunge (or who’ve already jumped in, and are splashing with the sharks without their chain-mail wetsuits).
But what does it mean? This “re-architecting” of which you speak?
And, just when that young lad in the back, jumping up and down and waving his arm was about to answer…
…he tripped over a step labeled “SCOPE”.
So, once agin, we’re back to that overflowing pack fo assumptions we all trudge around with on our back as to exactly what we’re supposed to really do when we take the CI/CD plunge and “re-architect our security controls.”
I know it sounds like you’re back in Kindergarten, but in order to figure out what we should really be doing here vs. what probably goes on in 80-90% of today’s organizations doing DevOps, we’re going to have to step back a bit.
What’s a security control?
Well, again, it depends on whether you step firmly onto that step marked SCOPE or end up doing a face-plant because you got too excited and didn’t see it lying there in the path.
My definition of “control”, the verb, is to be able to start and stop something at will. So what is that thing we’re trying to control?
Our context might help us here, because otherwise we’re just going to wander in the wilderness. If we’re talking about CI/CD, then we’re talking about the scope of enterprise applications, because that’s what you manage using that toolchain. Sure, the fact that many enterprise applications – especially doing DevOps – can end up being their own little, thick-walled silos shouting KEEP OUT to anyone who walks by doesn’t help, but at least we know something about where we should focus.
And so, if we’re talking about the enterprise applications, then what we’re probably talking about “re-architecting” is the way we deal with application security. So, again, we’re talking about how we choose to implement the security controls we think we need…
…not trying to re-evaluate whether they’re actually the right ones we should be using.
What I found interesting when I first went hunting for a clear definition of what “re-architecting” was after I saw it in the list of actions in response to somebody’s list of “top disruptors” of security in 2020 was that there really isn’t one.
Sure, we can guess. But the thing about guessing is that my guess might not exactly be the same as yours, because our backpack full of assumptions wasn’t packed by the same person.
Hell, it probably wasn’t even bough at the same store!
But one I found was embedded in a series of blog posts by Armor Defense that basically says:
Re-architecting is completely customizing your environment to meet your business and cloud needs to take advantage of cloud-native architectures and services (containers, server less and PaaS or SaaS offerings). Re-architecting allows you to reap the benefits of cloud-native functions, adopt DevOps early to build applications into your environment, and optimize operational costs and efficiencies in the cloud.
After some deft surgery with the special anti-marketing scalpel, it basically boils down to this:
Shifting and changing the deck chairs of your implementation choices to deliver security for your enterprise applications so that they fully use the new technology choices at your disposal.
Security requirements: no change.
Application requirements: no change.
Application and solution design: potentially big chances.
So what’s glaringly out of scope here is anything that actually starts with revisiting and re-evaluating the direction, purpose and coverage of your overall enterprise security program. If you weren’t aligned with the business before, you’re still going to be un-aligned after this level of re-architecting your security architecture…
…because, as we all clearly know, your security architecture is simply the choices you make about which technical security controls you buy and how you plug those into your infrastructure.
Right?
Er….nope. No, it isn’t. That’s certainly part of your overall security architecture, but it isn’t the sum-total, end-to-end, ultimate and forever definition of the scope of what your security architecture is.
It’s much bigger than that. And that’s why if it’s missing, your security operations on the ground aren’t going to get a whole lot of prioritization and direction input from the organizations they’re trying to protect.
But don’t let your organization get sucked into the whole “re-architecting” as a new way to deliver security. It just swaps out your manual transmission for an automatic…or maybe adds a turbo or something.
The point is, it sounds big, but it isn’t. And since many organizations don’t really have strong alignment between their security programs and their organizations, it’s pretty tough to demonstrate there’s value in continuing to pour money and people down that particular security rat hole…
…when there’s all these new, shiny, business-enabling IT technologies to spend money on, and all that new R&D effort we might put in to our new products and services.
So if you want to take advantage of the whole “re-architecture” opportunity for security, you’re gonna need to think about it a bit differently than you do right now. If you’ve got it, then I’ve just rambled on for 900 words or so for nothing. Thanks for reading.
However, if you don’t have it, or you don’t really know why I’m making such a big deal about this and claiming how critical it is to the success of your security program and maintaining your own personal sanity…
…then why don’t we talk about it on a brief call. At the bottom of this page is the link to set it up:
https://securityleadershipcoaching.com
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
