May 27, 2020
If you look at the stats on who’s making all the noise in the DevOps/DevSecOps space – at least those who care to comment on some of the industry surveys – 60% of the adoption of DevOps is in organizations with under $1 billion in revenue. Now, you might be wondering why I bring this up, but there’s a method to my money-focused madness.
The poster children for DevOps are large, deep-pocketed organizations predominately built around a single service, e.g, Netflix. Even then, Neflix’s revenue was around $16 billion, squeaking it in the $10B+ plus rank in the adoption surveys…
…but from the perspective of the Global 500, that’s chump change since the bottom of the global ranking is around $26 billion. Not quite twice, but almost.
That means that while the largest adopters of DevOps are small, fast-moving organizations, members of the Global 500 generally aren’t the organizations that have the luxury of being brainwashed to think that CI/CD of a single family of apps (or even a single app) is the biggest information and cybersecurity problem they have.
Sure, there may be cutting-edge teams in some of these large organizations, and they may think that their app’s importance makes Tony Stark look like a brainless, 98 pound weakling walking around in a reject Halloween costume in comparison…
…but the harsh reality is, you’re not Netflix. And, the even harsher reality is that your organization’s got a lot more to worry about than just AppSec, which, let’s face it, is all that DevOps and DevSecOps tend to worry about. That is, unless you like just chasing threats and vulnerabilities all day as the end rather than as part of an integrated and effective enterprise security program.
If you’re like the majority of the organizations I work with, you’re sitting somewhere well above the $20B+ revenue bracket, and you’ve been around for a rather lengthy amount of time, have a heavy investment in legacy systems, and are probably subject to few pretty prescriptive sets of regulations. And that means, unlike some of the smaller, DevOps shops built primarily around single service family…
…failing to take a comprehensive, enterprise-wide view of security is going to land you in a heap o’ trouble. And because of all this, it’s pretty important that you make figuring out what the state of the world is, how it connects and what it’s really supposed to be doing for your organization and its customers.
That, my friend, requires a proper security architecture effort. And it’s even more of a necessity because many of these types of organizations are filled with, dare I say it, average to midling development and delivery teams who aspire to do something beyond connect yet another SAP information service to some kind of web interface just like the previous 10 they’ve done for the last 5 years—but who can’t, so they generally invent exciting excuses for playing with the latest and greatest toys and methodologies.
Mind you, I’m not trying to be critical here. I’m just going on what I’ve seen firsthand in many different organizations and consulting organizations. And, as a result, there’s not a high degree of architecture skills around. Maybe the team’s had TOGAF training, or maybe Zachman, or maybe something else along the way, and maybe they try to do their best.
But that’s still going to be Goldilocks territory more often than not, and the level of documentation around the architecture and design of any solution security is supposed to approve is going to be basic. So, even if we’re working with a highly unique, outlier team who’s leading the pack in terms of DevOps and CI/CD…
…the stats say that even the leaders only have security involved during the design of the solution about half the time, and security’s involvement at the requirements-gathering stage is even less.
And that’s the leaders, not the majority. The majority are damn close to sitting in the corner and wearing a dunce cap after school because the just haven’t quite figured out how to get security involved at all.
Oh, and I’ll leave it to you to ponder why distinct phases are articulated in a DevOps adoption survey…but then that’d get us off on a tangent about the precise nature of security involvement in each of the standard DevOps delivery steps, and today’s not the day for that one.
So…since your typical app doesn’t generally deserve Tony Stark levels of self-importance…
…and since your typical business project implementation design generally isn’t that solidly connected into architecture of any kind, not the least of which is security architecture…
…then being able to catch any kind of crazy design document you’re thrown and turn it into something firmly grounded in the business and security priorities of the organization is a pretty necessary skill to have. And yet, it’s often a pretty big gap in the security team, because a good many people on the security team are a lot more comfortable playing in the infrastructure world than they are in the architecture world.
To fix this, I’ve dedicated the entirety of the upcoming June issue of the print Security Sanity™ newsletter to showing you how to take these kinds of solution sketches and link them to the existing security requirements of your organization, both traceably…and really, really quickly.
And as part of this process, you might find some conflicts, you might find some gaps, and you might find some areas where you really don’t yet know what the definition of security is supposed to be. Far from being a problem, that’s actually the whole point.
So if you want to be confident and quick about doing these things, then you’re going to also need to be confident that subscribing to the newsletter is the right thing to do…
…and quick about doing it before the upcoming deadline at the end of the month. To get all the details, caveats and cautions to make sure your confidence is justified, you’ll need to go here:
Just remember, the clock is ticking, and if you somehow manage to sneak in and your subscription payment is processed after 11:59pm US/Eastern on Sunday the 31st, you’re gonna miss this issue completely. Your subscription will start with the July issue, and there’s no way to get the one I’m talking about here, because back issues of the newsletter aren’t available.
Do with the above what you will. But whatever you do, you’re running out of time to decide.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
