How to Strike Gold in the Land of Continuous Security

This is our fourth installment of a six-part series dedicated to helping CISOs establish and maintain a successful application security program in an environment that often feels like the Wild West. We have used our unique position in the industry to process the pain points of security leaders today, who say dodging bullets in an old-fashioned gunfight has evolved into more modern concerns, like championing cybersecurity efforts, fostering a secure DevOps culture and adhering to stringent compliance regulations. Outlaw or cyberattacker, the threat is still real—and there’s still plenty to learn about what it takes to survive this new landscape.

(Read part one | part two | part three)

Digital transformation has changed virtually every aspect of how businesses operate. It’s a modern-day gold rush. But instead of every person becoming a prospector, every organization has essentially become a software company. They’re building CI/CD pipelines to capture the benefits of bringing innovations to market faster to create a competitive edge and grow revenue. Along with those advantages, they need to take on the responsibilities of modern application development, which must include creating secure software.

The Great Application Development Landscape Transformation

The Gold Rush of the mid-1800s transformed California from a small, unknown land into a state with a thriving economy. It was a risky journey, and many folks did not succeed in finding their fortune. Organizations today who don’t take precautions in their development and security efforts can find themselves in a similarly untenable position. There’s no question you need to invest in application security. But it is possible to make smarter investments, ones that improve your security posture and lower overall cost.

The later in the development process you identify a security issue, the more expensive it is to fix it. NIST looked at the relative cost of fixing a flaw at different stages of the SDLC[1] and here’s what they found:

  • A problem discovered in coding costs 5X what it would cost to fix if discovered in the requirements/architecture stage.
  • It goes up to 10X during integration/component testing, 15X in system/acceptance testing and 30X in production/post-release.

The Ponemon Institute uncovered even higher ranges[2]. An $80 cost to fix a vulnerability early in the development process ballooned to $7,600 if the fix happens in production. That’s a 95X increase. It’s easy to see why “shift left” has become the DevSecOps mantra. But to do that, you need to have the right tools and processes in place. With smart investments, you can drive down your total cost of ownership (TCO) of vulnerability discovery while maintaining or even improving your continuous security posture.

Extract Your Security Gold Effectively and at Scale

Reducing the costs of your security program without reducing your protection is like finding gold. But just as with prospecting, how much of that “gold” you can claim depends on your approach. Focusing on just the licensing costs of your security scanning tools is a lot like panning for gold, where early prospectors retrieved loose flakes or nuggets. It’s easy to purchase more and more tools, but as a solution, it’s not scalable—so the gains are limited.

You need more sophisticated mining methods, but they require investment. TCO takes into account the costs of acquisition, implementation, maintenance and support of tools. It’s not just a budget line item; it also looks at time and people in addition to dollar costs. You need to consider all the hard and soft costs related to the following activities:

  • Selection: Investment begins before security scanning tools are acquired. You must identify and evaluate potential candidates to make the best decisions. This takes time—time your team members can’t use to focus on other things.
  • Onboarding: Once you’ve acquired your tools, it’s time to provision and onboard them, which often requires tuning. And then you need to onboard all your applications into those tools. Just as with selection, this takes time and focus.
  • Triage and remediation: It’s important to understand the time and staffing required to execute scans and triage the results based on the tools and onboarded applications. The same goes for the process of rectifying issues and verifying remediation. Unlike selection and onboarding, these costs are recurring.
  • Board and executive reporting: With increasing board- and C-level visibility, you need to deliver vulnerability and risk information in a business context. The longer these reports take to create each month, the less time the team has to spend on primary activities.

Use a TCO calculator to help you jumpstart the process of calculating the cost of your vulnerability discovery program.

Getting Security Rich in the SDLC

Ensuring security is implemented early and often isn’t just modern speak for how to improve your vulnerability discovery process—it’s a business imperative. You must ensure continuous security throughout the software development life cycle (SDLC). But the costs of your program—all them, including time and effort—can’t weigh down your organization. By mining your program and tools for better-security-at-lower-cost gold, you can improve both your security posture and your TCO.


[1] Source: Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework

[2] Source: How Security Teams Are Handling The Risk

*** This is a Security Bloggers Network syndicated blog from Blog | ZeroNorth authored by ZeroNorth. Read the original post at: