054 – Secure Your Products, Secure Your Business: Insights from Envestnet’s Derek Fisher

Show Notes 

• 10:15 – Product security vs. application security and DevSecOps
• 11:52 – Product security budgeting: Approaches and helpful metrics
• 15:54 – Tips for clear communication between application security
  and engineering teams 
• 17:33 – Balancing security and business risk in the development lifecycle

What is product security and how is it different or similar to AppSec or DevSecOps?

Product security is the umbrella that application security and DevSecOps fall under. While application pentesting focuses on protecting software deployed in an environment, DevSecOps is about integrating security into the rapid deployment model and providing fast feedback from production to development.

“Infrastructures as code (IaC), cloud deployment, DevSecOps, application, mobile – all of that really falls under that product security umbrella where we shouldn’t be focused on certain aspects of the application, like in application security, but instead be focused on the holistic vision and view of what securing software looks like.”

How do you approach getting a particular domain of budget from application security, network security, or cloud security applied to product security? What metrics are effective?

Product security focuses on building security into the development lifecycle and decreasing the number of vulnerabilities deployed to production. Derek reminds us that the challenge lies in quantifying the benefits of such efforts and proving their impact.

“Lately, I’ve been trying to follow more of a QA type of model for product security where we’re doing quality assurance just with a security lens. Nobody questions the fact that when we find things early in testing, we’re saving money in production fixes… and that’s really where it helps to get that information so that when it comes time to budget for new tools, new processes, [and] headcount that you have a metric that can show savings.”

He recommends collecting the following metrics to help with budget conversations:

• Reduction in vulnerabilities going into production 
• Mean time to remediation 
• The coverage of security tools across the organization (i.e., ensuring that all products are covered by production tools for virtual patching and protection against vulnerabilities that cannot be fixed quickly) 

In your role, you work with a cross-functional team. What tips or advice do you have for successful communication between the application security team and engineers? 

It’s important to have a partnership between the application security team and the engineering team. The security team should not be the “team of no” but instead focus on managing risk and vulnerabilities.  

“At the end of the day, we’re here to manage risk and the vulnerabilities that are identified. It doesn’t mean that we’re going to stop a release from going out. We know that there’s going to be releases that go out with vulnerabilities in it. Can we appropriately manage those vulnerabilities, and can we provide protection while we work on a remediation? Those are the types of conversations that I think are helpful with engineering so that it’s more of a partnership as opposed to an adversarial type of relationship.”

How do you balance moving along the development lifecycle while also minimizing risks from security implications?

Derek acknowledges the challenge of balancing security risks with the need to release new features or meet business obligations. He emphasizes the importance of understanding and managing both security risks and business risk: 

“We need to understand what that actual risk is because a lot of times when we find risks or vulnerabilities within a product, we say this is a critical issue that was found by our scanning tool, but we dig into it, find out that this isn’t even being executed or exercised by the application. Or, we have some other mitigation and mitigating control in place, which allows us to provide some level of protection or something to that effect. It’s important to make sure that we really understand what is the actual risk from a security perspective and what is the risk to the business of not releasing that feature or that code.”

Derek is an award-winning author and works professionally as a leader, university instructor, and conference speaker in the security space. He is also the author of the Application Security Program Handbook and Alicia Connected, a book series educating children about safe technology use. Outside of work, he enjoys participating in a series of obstacle running races called Spartan Races. Follow Derek on LinkedIn and check out his security blog!