Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A DevOps Approach to Building Security

DZone's Guide to

A DevOps Approach to Building Security

While DevSecOps is gaining steam, there are still some basic lessons that DevOps can teach you about your approach to your project's security.

· Security Zone
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

This article is featured in the new DZone Guide to Proactive Security. Get your free copy for more insightful articles, industry statistics, and more!

DevOps has been posting some impressive numbers lately, including 46x more frequent deployments, 5x lower change failure rate, 96x faster mean time to restore service, and 2x more likely to exceed business goals. Security has been posting numbers too, but they’re terrifying. For example, the average application has 26.7 serious vulnerabilities, and the average breach costs $4 million.

The similarities between the problems security is facing and the challenges that DevOps addresses in software development are striking. Many people understand DevOps as being all about automation, but it’s much more fundamental. Fortunately, in “The Phoenix Project,” Gene Kim created a roadmap for reinventing security called the “Three Ways.”

Understanding Your "Security Work"

Most organizations do security work in large chunks, late in the lifecycle, with multiple handoffs involved, and there is no clear line of sight to the business reasons for the work. Not surprisingly, security accrues a lot of technical debt, creates waste, and blocks other processes from working efficiently. While there is a need for more security experts, no amount of heroes is going to fix these fundamental problems.

Image title

Sometimes security doesn’t seem like tangible “work.” People call it a “non-functional requirement” or one of the “engineering specialties,” but if we can frame security work in the same way as all other development and operations tasks, as a first-class category of work, we can apply DevOps principles to get it done faster, more accurately, and more reliably. In the diagram above, we can see that security work naturally breaks down into roughly the same categories as software work.

"The First Security Way": Establish Your Security Work Flow

The First Way is about getting security work to flow from development into IT operations smoothly. How do we get the work from the diagram above flowing? First, we have to make sure every bit of work has a clear “line of sight” to an outcome we care about. Getting the work flowing requires structuring it to work differently than we do today. We’re going to:

  1. Make the work visible.

  2. Reduce batch sizes.

  3. Limit work in process.

  4. Reduce handoffs.

  5. Focus on the constraint.

We can rethink all of the security work above using these principles. Here are a few examples of how this approach can transform security work.

Image title

With these transformations, security work is now focused on the outcomes that matter to the business. We’ve made the work explicit, broken it into digestible pieces, and simplified the processes significantly.

Instead of poking holes in security and reacting, the work is now generally focused on a “positive” approach to security, focused on ensuring that the right defenses are present, correct, and used properly.

"The Second Security Way": Ensure Instant Security Feedback

The Second Way is about establishing tight feedback loops so that the instant a security issue arises or security work goes off track, corrective action can quickly be taken. To achieve this, we need to:

  1. Make these problems instantly visible.

  2. Swarm on the problem.

  3. Seek the cause.

  4. Optimize for downstream security stakeholders.

Security assessment offers a perfect opportunity, but don’t forget it’s just one of many types of security work that isn’t as effective today. Simply shoving legacy scanning tools into the CI/CD pipeline is a perfect example of optimizing upstream from the constraint. Because it takes experts to triage false positives, running more scans actually exacerbates the bottleneck.

The only way to improve is to radically optimize for the security expert. Make security visible with a real-time security “bus” that allows threat and vulnerability telemetry to be gathered and analyzed across the lifecycle. The bus also enables all stakeholders (developers, testers, operations, audit, executives, etc.) to receive authorized security analytics and notifications through the tools they are already using. In addition, the bus can empower teams to respond to incidents and manage policy across the application portfolio.

Image title

This bus enables tight feedback loops so that vulnerabilities can be fixed quickly. It also encourages downstream security stakeholders, (like developers) to work with upstream providers (like security testers) to ensure that the work is optimized for them.

Vulnerability assessment is just one of many examples of long feedback cycles in security. Breaking these processes down and reinventing them as small tasks with rapid feedback prevents wasteful rework and saves both time and money.

"The Third Security Way": Encourage a Security Culture

Security, even more than most specialties, requires strategy and adaptation. One way of thinking is that security is an emergent property – the result of the constant tension between attackers and defenders. It’s an organization’s rate of evolution that matters. How fast can you adapt to new threats and vulnerabilities?

Unfortunately, most organizations target compliance standards that are several years behind the threat. We should be targeting the level of threat that we believe will exist several years in the future! How do we create a culture that constantly advances security with the threat? From The Phoenix Project:

“The Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.”

Every organization should have an advanced security team to continuously experiment with techniques to improve security by:

  • Looking for ways to enhance the organization’s
    threat model.

  • Enhancing and simplifying security architecture.

  • Making security defenses easier to use (both
    by programmers and users).

  • Using security to differentiate your product in
    the market.

This process requires a dedication to science. You’ll need to design experiments, measure carefully, and tie your recommendations to the business outcomes you desire. Every time you experience vulnerabilities, attacks, or breaches, take advantage of the opportunity and experiment with ideas to prevent these problems from ever reoccurring.

Get Started Today

If you’re in the process of transforming your business with software, and everyone is, then application security is critical to your future. You need to take it seriously and learn how to actually deliver application security work efficiently – as part of your normal engineering process. If you follow the Three Ways of Security, you’ll be able to eliminate a ton of wasted work, redefine what you need to deliver, and deliver results that actually matter to the business. The best part is that the vast majority of application security work can be delivered without security experts and without slowing your software development efforts.

This article is featured in the new DZone Guide to Proactive Security. Get your free copy for more insightful articles, industry statistics, and more!

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,devops ,vulnerability assessment ,threat modeling ,application security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}