Archistry

Survivability by Design™ since 2006

  • Home
  • About
    • Who Is Andrew?
    • C2T System™
    • The Agile Security System™
  • Contact
You are here: Home / Archistry Daily / That McLaren your cybersecurity team lost last year

June 1, 2020

That McLaren your cybersecurity team lost last year

Photo by Nirmal Rajendharkumar on Unsplash

A couple of years ago, McLaren – of F1 and supercar fame – unveiled their fiercest road-going effort yet, the McLaren Senna, inspired by one of history’s greatest racers. It costs just over $1 million. And it goes really fast.

In fact, it goes much, much faster than probably a few of the projects in your organization. You know the ones. The ones that get nearly to the end before someone in security finds out about them.

The ones that haven’t been built according to the organization’s established and approved security policies.

The ones that are full of more holes than a big block of U.S. Grade A Emmentaler cheese.

Those projects.

And in most organizations, there’s at least 18 of them a year, depending on how many projects you do. Who knows, there might be more.

But in these organizations, at least according to research from MIT, those 18 projects result in a pretty big pile of money. It’s a pile of money big enough to put you behind the wheel of that McLaren Senna supercar…

…or, as most organizations do, it’s money that’s taken out front of the building, soaked in gasoline and which erupts in a minor explosion when the match of your cybersecurity program strikes your organization’s project delivery budget.

Not only does your organization lose out on the $1 million-and-change it might otherwise use to purchase a bit of fun and excitement for the cybersecurity team’s recreational use. It does it every single year. And that’s assuming that your organization’s in the middle of the pack, rather than sitting on the high-side where nearly every project gets a case of the cybersecurity hiccups.

Now, you might argue on behalf of the DevSecOps zombies with their chants of “shift left…shift left” as the solution to the problem. That is a valid tactical play, but have you stopped to think about what you’re going to do if you get there?

What does left-shifted security look like?

More threat modeling?

More co-located, cross-functional teams huddled together in the daily scrum?

(Good luck with that for the next several months though)

Again, all good. However, unless you do more than shift the point of security upstream in the delivery cycle, all you’re going to do is save some of that money—not all of it. And that’s because you’re still going to be doing the same kind of analysis you did as a stage-gate keeper…

…which, depending on the tools you have…

…might even make your job harder, not easier, since you won’t have the benefit of a list of tangible and validated vulnerabilities to give the developers they should fix.

Maybe one of the steps you’ll think of taking as a left-shifted security star is to go beyond threat modeling and do a full-blown risk assessment—or maybe that’s outside the realm of responsibility for your team.

Maybe you’ll go through the detailed requirements, interview the stakeholders from a security perspective and understand what they’re really trying to accomplish and how this project fits into the overall world of the business…

…or maybe you’ll just email them a spreadsheet of security questions like they tell us how to do as part of somebody’s idea of “best practice”, along with a link to the 400 hyperlinked pages of the security polices in the enterprise content management system, with a little note that says:

“Your application must be compliant with the relevant security policies.”

Which, I’m sure they will diligently do since you’re so shifted-left you’re ahead of them in the delivery cycle that they see you as even more annoying telling them what to do in advance than you were when you were stopping their projects and telling them what they already did wrong.

You see, if we really want to solve the problem of the missing McLaren, we really have to not only get ourselves in the right place to exert the most influence…

…we also need to bring along the right tools to make us both efficient and effective.

Because our ultimate goal should be to paint a big red target on the back of that $1 million waste bucket and attempt to knock it into next week. Because if we did that, not only would we look like heroes to our beleaguered project management and development companions trying to get their solutions out the door. We’d also salvage enough dough to hire 9, highly-skilled security architects or at least 12 more engineers.

In fact, if we only solved HALF the problem for one, single, measly, annoying, we’ve-been-here-1000-times-before type of project, we’d be able to get a new security architect on the team—so they could either augment, or even spearhead, your security architecture efforts.

And if we did that, we’d be able to hopefully solve the real, underlying problem causing a good deal of that waste in the first place—a lack of a proper security architecture.

Because if we have a proper architecture… an architecture that’s defined in terms of the important things required to help the organization stay in business rather than identifying every single one of the 40,000 – 400,000 endpoints, servers, printers and other blinking boxen with an IP address.

An architecture that allows you to quickly and easily understand which controls you already have (and where they are) that should protect you from going full “headless chicken time” when you get your stack of daily vulnerability and threat reports.

An architecture that allows you to give focused policy compliance advice to new IT and business projects that come your way—quickly, easily and leveraging what you already know about the state of their world.

An architecture that allows you to actually DO NOTHING AT ALL for those projects who come along that are just like the other 45 projects you did this year where you already have high levels of confidence you have the right security controls in place…

…and where you have the metrics, assured measurements and regular reports to prove it.

Your security architecture is what tells you how everything fits together…how everything supports the business…why you made  the control decisions you did…

…and why, exactly, that particular approach to solving the problem that “the newbie” developer read about this morning on the Netflix or Facebook dev team’s blog – or that particular platform or technology they’re dying to put on their CV so they can more easily get their next job – has already been crossed off the list of possibilities…

…because it wasn’t aligned and compatible with where the organization actually said it wanted to go.

Shifting left doesn’t make you proactive and enabling. A proper security architecture is what makes you proactive and enabling—and, truth be told, it doesn’t matter all that much where you sit if you have one. Sure it’ll work better the closer you get to the end of the horse that bites…

…but it’s still going to add value if you’re stuck cleaning up the fall-out from the end with the built-in fly swatter too.

But you might not know how to get from where you are to where you’re behind the wheel of the mythical McLaren of which I spake. And that’s ok. Most people don’t. And even if they do, and they’ve invested in some of the right knowledge and tools, they might still have trouble making any progress.

So, maybe I can help. Because I’ve been helping people in that kind of situation get started with architecture since even before I met John Sherwood and found SABSA at a cracking little security conference in Croatia. And that was 15 years ago. Since then, I’ve taken all the wrong turns, raced all the wrong tracks, and been down all the dead-ends you too might encounter if you tried to streamline your cybersecurity program yourself.

Of course, there’s nothing stopping you from trying. While it might not take you the same time  it did me from when I first found SABSA to when I finally distilled the way I actually put it in practice into the 7 principles, 14 practices and 3 Baseline Perspectives™ of The Agile Security System™ in June and July of last year – and that was using it nearly every day – before you end up with your own approach. It just might take a bit more time and effort than you have at the moment—and you wouldn’t have any guarantee that it would actually work once you managed to get it together.

Or, you might already have everything you need and be giving the members of your teams their very own McLaren-like birthday gifts at the annual cybersecurity offsite in the Bahamas.

However, if you aren’t, and you think there’s a chance I can help, then here’s how we can find out for sure. You click this link, book the call, and if I can’t help you, I’ll tell you straight out. If I can, then we’ll take it from there. But it can’t happen without you taking that first step.

Here’s the link: https://securityleadershipcoaching.com

Ya never know. It just might end up transforming your whole program—and even the way you think about delivering security. Or it just might help you take that first step to building real architecture in support of the very project you’re working to deliver once you’re done reading this email. As always, it’s up to you to decide.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

Article by Andrew Townley / Archistry Daily / Agile Security, DevSecOps, Effectiveness, Security Architecture, Security Budget, Shift Left, Threat Modeling

  • Email
  • LinkedIn
  • Twitter
  • YouTube

EMAIL NEWSLETTER

Want to get DAILY email tips on how to build a more effective security program so you can prove your security investments deliver value to the business?

You can always unsubscribe at any time, and we won't sell your data to third parties.

About Us

Archistry works with you to ensure what you want to achieve actually gets done, linking strategy, risk, governance and compliance to enable sustained exceptional performance Read More…

Testimonials

Andrew is a highly skilled and experienced information systems architect and consultant, which in my view is a rare thing. He is innovative in his thinking and merits the title of 'thought leader' in his specialist domains of knowledge—in particular the management of risk. Andrew has embraced SABSA as a framework and, in doing so, has been a significant contributor to extending the SABSA body of knowledge."

— John Sherwood, Chief SABSA Architect

"Fabulous person to work with. Very engaging and insightful. Extremely good technical knowledge with ability to relate concepts together and overcome differing opinions. Makes things work."

— Kevin Howe-Patterson, Chief Architect, Nortel - Wireless Data Services

"Andrew was able to bring clarity and great depth of knowledge to the table. His breadth of thinking and understanding of the business and technical issues along with a clear and effective communication style were of great benefit in moving the process forward towards a successful conclusion."

— Doug Reynolds, Product Manager, MobileAware

"Andrew is a fabulous consultant and presenter that you simply enjoy listening to, as he manages to develop highly sophisticated subjects in very understandable way. His experience is actually surprising and his thoughts leave you without considerable arguments for any doubts in the subjects he covers."

— Biljana Cerin, Director, Information Security and Compliance

Recent Posts

  • If you want better security, you’d better have a better security architecture
  • The ultimate security song to keep you focused on what you’re doing
  • Security heroes
  • There’s always a people problem
  • Putting your data flow diagrams out to pasture…for good

Looking for something else?

  • Home
  • About
  • Contact

  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • Copyright © 2006-2025 Archistry Incorporated or its affiliates

"Archistry", the stained glass window logo, "Pragmantix" and the Pragmantix™ logo, "Archistry Execution Framework (AEF)", "Archistry Execution Framework, Cybersecurity Edition (ACS)", "The Agile Security System", "The Agile Business System", "Baseline Perspectives", "Architecture Wall", "Archistry Execution Engine", "Renegade Security", "Renegade Security System", "Security Value Delivery System (SVDS)" "Collapse-to-Traction", "Collapse-to-Traction System", "Adaptive Trust & Governance Model (ATGM)", and "Adaptive Trust & Governance Model for Organizations (ATGM4O)" are trademarks of Archistry Incorporated or its affiliates.