Security at the speed of modern development

How security teams can keep up with the velocity of modern development

If you are an Application developer today, you are likely under pressure to deliver faster. Over the last decade of supporting digital transformations I’ve seen a few key drivers for this:

• Excel or die. Data shows that companies that fail to deliver with speed and stability quickly lose their competitive edge

• Digital business is disruptive. New business models, new interactions, smaller fleeting business opportunities all require the ability to act quickly

In response, I’ve seen development and ops teams be empowered to manage the entire application lifecycle and drive foundational changes to applications to accelerate delivery. With the adoption of DevOps & agile practices, cloud services, and infrastructure automation, these teams are generally positioned to deliver faster than ever before.

Security Challenges

Unfortunately, the reality is that most enterprises today are not able move with the speed they desire — and a big reason for this is security design and engineering teams cannot keep up. Companies that do achieve greater velocity, often take on significant security debt, or quickly reach a point where security becomes a bottleneck as they seek to scale across their application portfolio.

Most of my security colleagues in the industry are stuck constantly fighting fires and unable to find time to do the strategic work they were hired for. In my experience, there are several key reasons for this:

• Under-resourced security teams: According to industry surveys, most organizations have 100 developers to 10 IT ops to 1 security resource. To add to the problem, research consistently shows that there are millions of unfilled security jobs and this is growing. It is especially hard to find security architects (and as an industry we have also not done a good job of providing security engineers a pathway to grow into security architects, but more on that another day).
• Security design practices are not designed for Agile: Institutionalization of agile practices often does not address enterprise architecture adequately. I’ve seen security design methodologies built to align with enterprise and solution architecture practices quickly become outdated and slow. The result — security design teams are not able to engage and deliver on time, and time-to-market always takes precedence as development teams move forward without security.
• Modern architectures are continuously evolving: Development teams today can fundamentally change the architecture of the product with a few clicks or changes to the infra-as-code. I can hear my security colleagues screaming “scope-change!” There is an inherent asymmetry of effort here. Development teams can deploy a Lambda that post-processes business sensitive data from an S3 bucket within hours. Security architects often have to scramble to assess this new solution architecture and build appropriate security guidance. On top of that, there are often steep learning curves to effectively provide security design guidance for new and rapidly changing cloud services and features.
• Reactive tooling: Today many security issues are identified after the application is deployed. We know that it costs 100x more to address issues than if they were prevented during design. Even catching issues during testing is often too late. It means fighting for the development team’s time, and time-to-market almost always wins.
• Too many changes, too fast: The truth is that this unprecedented rate of change across an enterprise is not sustainable for any security team — even if the security team could fill every one of their open positions.

This creates friction between application development and security organizations at a time when businesses need to move faster or risk becoming irrelevant.

So what can we do about it?

Empowering Security to be In-Sync with Modern Development

What we want to strive for: Security, Development, and Ops teams effectively collaborate and share responsibility, and businesses deliver with velocity, stability, security, and agility.

The good news — we can get there. It requires empowering security teams in the same way the dev and ops teams have been empowered to own and manage the lifecycle of the application’s security design and implementation. Security Design and Engineering must be equal stakeholders in the organization’s DevOps journey.

From a process and technology perspective, this requires security to be a part of every stage of the development lifecycle:

• Engage Security early in Design — In order to build security-in, the lead time to engage Security and deliver security designs needs to be low. This requires security teams to have built security reference architectures & design patterns they can utilize to deliver faster. They need the ability to quickly build, update, and manage the lifecycle of security designs in a manner that is reusable, maintainable, and version controlled to support the varying use-cases they will encounter. This will help security teams quickly provide security design guidance when new applications or features are being designed.
• Security release automation — Security design and engineering teams require automation that fits into the existing CI/CD pipeline and infrastructure automation tools to assess, remediate and enforce the security design. With such automation, even under-resourced security teams can scale to address changes across the enterprise’s entire application portfolio.
• Continuous visibility post-deployment — It is not enough to build secure-by-design solutions. We also need to ensure that the application remains in this known-good state. A critical issue that enterprises run into today is that the infra-as-code repository is not the source of truth for what is actually deployed and running in operation. Security needs capabilities that provide visibility across the entire environment and detect any drift from the intended security design to ensure that no security-relevant changes are made outside of the development pipeline.

The cultural change is the hardest and most important. There are many considerations here including building independent autonomous teams with shared responsibility, improving the trust across Dev, Sec & Ops teams, and creating an environment free of fear of failure.

With security teams taking ownership of the security lifecycle for an application, it frees the development and ops teams to accelerate the delivery of amazing products that are stable.

Over the coming months, I’ll be diving deeper on some of these topics.