How Security Can Potentially DOUBLE Your Existing Software Delivery Capacity WITHOUT Adding More Developers Or Buying Expensive Tools

Since the early 1990’s, organizations have focused on “business agility” because it was clear that if you didn’t have the ability to quickly innovate and adapt to changes in the market, you might not be around long enough to correct your mistake.

There are many examples of companies once with household names which now are etched on the tombstones of business history:

Kodak – invented the digital camera, but filed for bankruptcy in 2012 because it didn’t want to cannibalize its existing film business.

Nokia – once the mobile handset manufacturer for the world, acquired by Microsoft in 2014 because it couldn’t adapt to consumer needs.

Blockbuster – where everyone went to rent their weekend movies, accumulated $1 billion in debt and filed for bankruptcy in 2013 because it was too slow to recognize what its customers really wanted.

These horror stories – along with many others – underscore the necessity of ongoing innovation and responding to customer feedback as the only way to maintain an ongoing competitive advantage.

But it’s an advantage that all too often is sandbagged by your security program.

In fact, according to recent research from Synopsys, 80% of organizations surveyed faced security-related delays to their delivery cycles—delays that could last up to 2-3 weeks.

Now, that might not initially seem like a lot. It’s only 2-3 weeks…out of 52 every year, so what’s the big deal, right?

Here’s the thing: additional research said that 84% of commercial codebases contained vulnerabilities…

…and 74% of those same codebases contained “high-risk” vulnerabilities.

So, given these startling facts…and the number of large organizations with understaffed security teams…teams who often get pulled into doing “last minute” security reviews that end up repeatedly finding the same things…

…and where these releases are deployed into production anyway…

There’s a very good chance that for each major release cycle of 100 sprints for a large application, up to 3 significant, security-related delays might occur.

And when you spread that out across a large, global organization with around 1500 developers…

…it starts to get serious.

Very serious.

In fact, I estimate that the average cost of delay over 100 sprints is almost EXACTLY the same as the resource cost of delivering 4 to 5 new features!

That’s right.

According to my calculations, security delays and issues – including remediations by the delivery teams – are keeping you from innovating and getting the critical customer feedback your organization needs to maintain its competitive advantage…

…by delaying value delivery and critical customer feedback by 4 to 5 months—an eternity in today’s competitive landscape.

And that’s not necessarily including the opportunity costs of not acquiring new customers or generating potential revenue.

But here’s where it really starts to hurt. Because if that’s not already a hard enough pill to swallow…

…those figures are per major business requirement or objective within an application.

So it can quickly become something that’s almost too painful to think about.

All because security issues are getting in the way of business value delivery from the customer-facing applications and services your organization provides.

It’s a big problem. In some organizations, it’s even too big a problem, so it often gets swept under the rug and ignored.

In fact, many organizations don’t even track the cost of delays in a way that can highlight there’s even a problem.

They just feel the impact, but they’re not sure why.

And on the ground?

Everyone’s overworked, over-stressed and hard to get along with. Morale is low. And cross-team communication and collaboration can make even the thought of going to work every day…

…seem like descending into the depths of hell itself.

The good news is that it doesn’t need to be this way. And it can be fixed—without investing in hiring a bunch of new people or buying the next, “latest-and-greatest, AI-enabled” security tooling.

But before I get too carried away, let me introduce myself.

My name is Andrew S. Townley, and I’m the Founder and Chief Executive of Archistry. What I do is help the Global 500 build effective, value-driven security programs. And a big part of ensuring that security truly delivers value…

…is putting in place the right approach to secure software delivery.

I call it Secure by Design. So do many of my clients around the world. However, since many international government agencies recently banded together to put out a joint definition of “secure by design” that’s focused on technology and software vendors, it’s caused some confusion.

Because some large enterprises don’t think secure by design is something that applies to them, simply because either they aren’t in that space as a technology or software vendor. Or, if they are, then their enterprise IT functions are managed completely separately from that part of the business.

So, in order to be extremely clear about what I’m talking about in terms of a secure software delivery capability vs. what some people may understand secure by design to be, let’s define…

The 3 types of Secure by Design.

When talking to the CIOs, CISOs and architects of large enterprises, I’ve found the following distinctions to be quite useful. I believe they make it pretty clear what secure by design is all about. They are:

Secure by Design (generally) is to ensure that security considerations are an integral part of product and service design and technology integration such that “security” is an outcome, and users of the final solution have confidence they can do what they want to do without exposing them to risks beyond their ability to manage.

Vendor Secure by Design (VSbD) is for software and technology vendors to build products to be secure by design and default so that they reduce the burden of cybersecurity to customers by facilitating easy automation, integration and application within customer security environments.

Enterprise Secure by Design (ESbD) is for organizations to build and maintain a resilient technology infrastructure that is secure by design and default so that it is aligned with the evolving needs of the organization and its customers by engaging security as early as possible in business and technology decisions.

With these distinctions, it should be pretty clear that garden-variety "secure by design" or SbD is something all designers and integrators of anything should strive to achieve. It also allows the vendors and everyone else to have their own rules and approach to doing it.

However, it still might not be quite clear why it’s such a big deal, so let’s take a closer look.

You see, Secure by Design, “security by design”, SbD. “shift left” security and even DevSecOps have gotten a lot of attention over the last few years—and with good reason. The rate at which critical CVEs have been discovered and reported is skyrocketing.

But those critical vulnerabilities don’t just impact commercial, off-the shelf software from major vendors.

Those critical vulnerabilities also exist in many of the almost invisible, key open-source dependencies used every single day to deliver business applications.

As a result, security teams generally adopt one of two different approaches—well, three if you count ignoring the problem altogether.

Option #1 is to obsess about each and every critical vulnerability separately. However, this quickly becomes a rat-race of security operations and threat response teams overwhelmed by mountains of scan results and buried in confusing and conflicting alerts after being run ragged, worrying about each and every APT and well-funded threat actor that goes bump on the interwebs.

Option #2 is to compile a “kitchen sink” list of mandatory security controls, described in dozens of different documents amounting to 100’s of pages that are presented from the perspective of security. Controls which developers are expected to have etched on the inside of their eyeballs so they can be instantly and reliably recalled as they’re frantically writing business-critical code that’s supposed to be delivered under tight deadlines.

Once the developers have accounted for these security controls – and integrated them into the certified, “secure” infrastructure-as-code bundles prepared by the Security Engineering team and provided as critical parts of the DevSecOps CI/CD pipeline – the world stops for a pre-deployment security review, a slew of missing security controls are discovered, the project is delayed, costs go through the roof, and to further minimize the delayed realization of revenue, an executive policy exception is granted so the project goes live anyway, exposing those control gaps to the hostile war-zone that is the modern-day internet.

Even if this approval takes place, there could still well be delays related to the provisioning and integration of those mandatory security controls into the operational infrastructure due to poor resource allocation and scheduling issues, amplifying the anxiety of an under-staffed and overloaded security team.

Obviously, neither of these two options are ideal.

Fortunately, there is an alternative. And that alternative is to spend more time focusing on the “design” part of Secure by Design rather than the “security” part.

Now, you might think this defeats the point. I mean, after all…the goal of “secure by design” is more secure software, isn’t it? It even starts with the word “secure,” so why would you not focus on security and security compliance first?

Because what focusing on “security” first actually does is that it treats “security” as a separate thing. This is reflected in the whole approach people have to security generally. They think that you can go ahead and build something…

…and then you can just “make it secure” by adding a few mandatory security controls to it.

This simply isn’t the case. You only need to read the headlines and understand what some of the root causes are to some of the most high profile breaches in the news today to see that this kind of thinking doesn’t really work.

Almost every single “best practice” approach to improving security eventually boils down to this same idea:

We provide a more extensive list of controls
We expect you to implement the controls
And we beat you up when you don’t (but we still let you get away with it anyway)

Even worse, what happens in common practice means that those controls are only presented after the primary design of the solution happens, and it moves into the development and delivery stages of the process—regardless of what delivery model is being used, be it Waterfall, Agile or some home-grown hybrid.

The typical “shift left” of security is either completely given over to the IT team, requiring developers to become security experts or security engineers to become permanently embedded in delivery teams. Or it involves more frequent “security reviews” by shifting the stage-gates “left,” yet still focusing on the point of detailed design and implementation…

…without actually addressing the overall solution design at all.

The only way to truly achieve Secure by Design is to change the way we’re thinking about security from an “optional extra” to an integral, essential success factor and outcome of what’s actually being delivered.

When you do this, it truly changes the game entirely, because everyone does what they’re really good at doing…

…delivery speed actually improves…

…and both the quality and the security of the resulting software gets better.

How?

Because you’re potentially eliminating up to nearly 8 weeks of delays over the course of every 10 epics you deliver—across your entire organization.

And you’re doing it because security isn’t an afterthought anymore.

Security is involved from the very initial stages of design, and it can proactively ensure that the required capabilities are available well before the delivery team needs to integrate them into what they’re building.

In fact, a recent survey of CISOs by Team 8 said that the single best investment with the biggest return they’ve made in the last 12 months was to focus on secure by design and enhancing the overall experience for software developers.

But, that’s not all it does. Because adopting a true, enterprise-focused approach to Secure by Design doesn’t stand alone as yet another island of security capabilities. It becomes the ongoing engine of business alignment and agility.

How Secure by Design Enables Ongoing Business Alignment and Agility

There has always been a struggle between security and the business to establish and maintain alignment. The highly-volatile security environment and the evolving threat landscape tend to push many organizations into focusing much more on the “here and now” of operational security and acting as incident and emergency response functions than being integrated and aligned as true business partners.

Research from PwC shows that only 40% of security leaders feel confident in communicating their security posture to business leaders…

…and only 50% of those same security leaders are actively working to align security to business objectives.

The result?

In many organizations, security remains very much “The Department of NO.” Or, on a good day…

…it’s at least “The Department of Delays.”

And given what I’ve seen in my own engagements and conversations with large organizations around the world, it shouldn’t be much of a surprise.

Security strategy is primarily based on control standards, industry maturity models and whatever technology initiatives come from IT. Cyber and Information Security risks are assessed only infrequently, and there’s very little visibility of what security capabilities are truly necessary to support the business.

Instead, the security control maturity model drives the security capability deployments. And the way those capabilities are ultimately deployed…

…isn’t optimized for the way they need to be used and integrated into day-to-day operations—especially when it comes to software delivery.

The security program ends up being a “muddy mess” of ponderous, siloed capability deployment happening against a backdrop of frenzied security operations, alert management, threat investigation and incident response.

Security requirements are published in voluminous tomes focused a lot more on the particular control standard being used than how those controls are applied through the organization. And proactive interaction with security by delivery teams is avoided at all costs, because the developers are under pressure to deliver, not dive through pages and pages of documentation searching for the right controls they need to apply.

Looking at the way the security world normally works, it’s hardly surprising that secure development ends up being deferred to “best effort” on the parts of individual developers and delegated to automated security scanners and manual compliance checks—often without any consequential change in the overall risk exposure of the applications being examined.

Compare this current reality – a reality that may be very familiar to you – with the potential sanity of a value-driven security program.

I look at the entirety of the security function as four separate aspects, each with defined relationships and requirements that govern the way they interact. This model applies systems thinking at its very core to understand what a security program needs to do—both for itself internally, and for its external security customers.

In order to deliver these functions, the Value-Driven Security Program is aligned with 3 fundamental value streams present in any organization: business strategy development, business initiative delivery and business improvement.

Using these core organizational activities as the basis, the value streams define the 4 aspects of Value-Driven Security:

Security Strategy – the activities associated with the definition, management and assurance of the organization’s enterprise-wide security strategy;
Security Capability Delivery – the activities associated with the delivery of both strategic and tactical security capabilities that are “business ready” for integration into all the required areas of the organization—including software delivery;
Secure by Design – the way the organization integrates security into internal project and software delivery in order to “take the pulse” of what’s required today and detect any issues or potential misalignments and shifts in the organization’s requirements for security policy and control; and
Security Operations – the operational activities, monitoring and event response functions that ensure the internal vulnerabilities and external threats are promptly and effectively addressed.

Supporting secure software delivery becomes a strategic imperative in the Value-Driven Security Program, ensuring the critical delivery capabilities like the CI/CD pipelines, deployment environments, identity and access management and auditing, logging and monitoring capabilities exist in a useful way before they’re ever needed by a software developer.

And the ongoing alignment and agility of the security program to define, augment or update the security control environment becomes a normal outcome of the operation of the Secure by Design aspect of the security program.

Once a new project is begun, the Secure by Design aspect understands the project, assesses the risks, and ensures that all the necessary control capabilities are present and fit-for-purpose—before they’re needed. And, if a control gap is found, it still doesn’t block delivery of the features that don’t require the control. Delivery continues as normal until the capability is delivered by the Security Capability Delivery aspect and made available by Security Operations.

Tracking the control capabilities used in each project ensures visibility on how many of the security controls are applied and actively reducing the organization’s attack surface. Proactively identifying the need for new or changed security policies and control capabilities from the inception of the project ensures that security remains aligned and responsive to the true needs of the organization.

In the Value-Driven Security Program, control capabilities can’t help but reflect the current reality of the business environment, and the days of marching down the maturity model list of mandatory controls to determine what’s required are long gone.

Operational responsiveness and agility is maintained through identification of issues or control performance problems so the organization remains vigilant in the current threat environment, and business responsiveness and agility is provided by iteration after iteration of Secure by Design.

From strategy to operations, the true needs and performance of security is clear. Security becomes “built in” from both the design of new projects and from adaptation to the external environment. And the executive team and the board have the confidence they require to feel that they’re as prepared as possible for whatever might happen.

In the Value-Driven Security Program, driven by Secure by Design, “security” truly becomes an outcome of the normal operation of the entire security program, working together as a fully integrated unit. It’s not just a collection of isolated, functional silos the way it often is today.

And as a result of this design, previous sources of security-related delays are eliminated as a function of the way your security program operates every single day—even if you start with Secure by Design, and don’t change anything else.

It’s still possible to effectively DOUBLE the overall delivery rate of your development teams simply by deeper integration and true alignment of security to all aspects of the business.

Surprisingly, the larger your organization – and the more developers you employ – the MORE you’re likely to increase the speed of feature delivery to your customers and thus your ability to pivot and innovate in direct response to their faster feedback.

However, you might be skeptical about what I’m saying. You might not believe that it’s possible to have security automatically become an outcome by focusing on design. You might not trust that your architects, designers, engineers and developers will do what they’re supposed to be doing without micro-management and direct, ever-present oversight and compliance checking by security. And you might even be wondering…

What makes me qualified to talk to you about Secure by Design?

All of the above are reasonable concerns—especially about whether or not you should believe what I’m telling you. So, I’m going to start with why I know a thing or 3 about what it takes to successfully deliver Secure by Design.

My background isn’t actually security at all. I have a Computer Science degree, and the first 20 years of my professional career were focused on software product delivery—first at a leading commercial software vendor doing quality assurance, software development and application architecture, and then later as the Enterprise Architect and Technical Design Authority for very large public sector projects with budgets extending into hundreds of millions of dollars.

I only really got into security out of necessity, because it was part of the scope of the architecture work I was doing from when I started application architecture. Later, I discovered the SABSA® methodology in 2005 while both John Sherwood and I were speaking on the same panel at a security conference in Croatia.

Fundamentally, I see security as an essential aspect of successful solution design, and I always have.

In fact, it’s always been surprising to me how we’ve “evolved” and specialized security into a separate thing in the name of complexity and “the ever-increasing threat” in ways that actually make it harder and less-likely that we’re going to achieve it.

Treating security as a separate thing to be optimized and enhanced independently of the organization it’s trying to protect – and the software it relies on to create and retain customers – is killing us in more ways than one.

And since 2015, I’ve been working with large global organizations around the world to address this issue by more closely re-integrating security into the design and the delivery of critical business software. Over the years, I’ve developed a number of different approaches for doing this successfully, whether the delivery process uses a more traditional “waterfall” or Stage-Gate product delivery approach, or if it’s done using some variation of Agile delivery.

My approach blends two core models: SABSA and the integration of Lean and Agile based on the work started by Al Shalloway’s LeanBan method and currently being enhanced and expanded by his Amplio System. As a result, I’m both a certified SABSA Security Architect and Amplio Consultant Educator. This, along with my decades of professional experience, means that I’m qualified to address all aspects of security and business agility from the individual, to the team and extending to the entire organization.

My approach is also very much anchored in the fundamentals of business and value delivery best summarized by the famous quote from Peter Drucker:

“There is only one valid definition of business purpose: to create [and retain] a customer. Because its purpose is to create a customer, the business enterprise has two – and only these two – basic functions: marketing and innovation. Marketing and innovation produce results; all the rest are ‘costs.’”

Unfortunately, since we’ve carved out security as a separate entity and “thing” that’s independently considered and managed, it’s easy to do what most people do—focus on security as a cost, as per the Drucker quote.

But that’s wrong.

Because security isn’t a cost.

Security is an investment that enables marketing and innovation.

And being able to prove this in concrete business terms that matter to executives and the board of directors requires that we not only shift security.

We must shift the way we think about security.

And, based on everything I’ve learned my entire career in both software delivery and as a security professional for nearly 30 years…

…the best, fastest and most effective way to achieve this goal and demonstrate that security is not simply a cost to be controlled and minimized where possible…

…is to fully embrace and adopt the potential of what Secure by Design actually means when it’s an integrated and essential part of software development and an enabler of business agility.

That’s why I’ve put together a brand-new, focused program to show you exactly how to implement Secure by Design properly in your organization; demonstrate the benefits and results of adopting it; and use it as the engine that establishes and maintains ongoing alignment of security with the business. I call it Secure by Design: Step-by-Step, and I’d like to introduce it to you now.

Secure by Design: Step-by-Step

Program Overview

Secure by Design is one of the most important, yet misunderstood, tools in the arsenal of an organization to protect itself from malicious attacks and embarrassing data breaches. These breaches can have a massive impact on an organization, its shareholders and its customers. In this program, you’ll find a step-by-step solution for effectively embedding Secure by Design into your organization—without turning your development team into security people, without turning your security team into developers and without simply “shifting left” the compliance-based, “stop the world” security assessment you already use.

At the end of this program, you will:

Create an effective, practical and straightforward adoption plan for Secure by Design in your own organization (even if you’re not already doing Agile delivery or you’re already operating a DevSecOps delivery pipeline).
Understand and be prepared to address the most common adoption challenges you’ll face doing Secure by Design the right way.
Learn what’s wrong with the typical approach to doing Secure by Design (and how to avoid falling into those same traps of separate security silos simply sporting spiffy new names).
Prepare your team the right way by learning how to select the projects that are the most appropriate for demonstrating the value of the approach the fastest way possible.
Craft the perfect communications plan to “sell” the benefits and get the buy-in of both your CIO and CISO to support your roll-out of Secure by Design.

Program Structure

The program consists of 6 modules delivered over two weeks. The material will be presented live via Zoom on Monday, Wednesday and Friday each week, and each session will be approximately 90 minutes. The first 60 minutes will be devoted to presenting the program materials, and the last 30 minutes will be reserved for participant questions and clarifications on the materials. Each module will also include appropriate worksheets, templates, examples and reference materials.

Each session will be recorded, and the recordings will be posted inside the Archistry Learning mobile app the same day they are delivered. This allows for both review and to accommodate schedule conflicts in the event that participants cannot attend a particular live session.

Additionally, to enable participants to get the most out of the program, a dedicated, private Slack workspace will enable participants to engage between sessions and post questions they would like answered in the next session. This private workspace makes it possible to participate in the program even if local timezone constraints make it otherwise difficult to attend the live sessions.

Prerequisites

This program is focused on the practical planning and execution steps of building and running an effective Secure by Design capability in your organization. It does not cover the core theory or fundamental techniques that are referenced in the materials or used in the examples. Understanding this core theory and these techniques is essential to your successful adoption of Secure by Design.

Therefore, the only requirement is that you have read the book Getting Started with The Agile Security System™. The electronic version of this book is included with the program and is immediately available to you once you have successfully registered. Reading the book will help you understand the fundamentals of why the approach will be successful in your organization and the reasons that it will be more than a tactical security step. It will also explain why, when done correctly, an effective Secure by Design capability will lay the foundation for an integrated and successful information and cyber security program.

Program Content

Each of the 6 core modules of the program are described in the following sections in the order they will be presented.

Module 1: Understanding Secure by Design

This module explains the true objectives of Secure by Design and how the approach presented by this program differs from current industry “best practice.” It provides an overview of why the current approach is not effective, and helps you prepare the business case necessary to get the support of the CIO and CISO for implementing Secure by Design the right way.