Shut down your application security program

No, I’m not kidding. Shut down your application security program. After speaking with hundreds of organizations and multiple analyst firms, one thing has become clear: they’re not effective. That’s not to say that security isn’t as important, if not more important than ever – the SolarWinds and PHP attacks have reminded us of that. But executive and Board-level discussions don’t focus on security – they focus on risk.

To stay relevant, Security professionals need to up-level their thinking and messaging to better align with how executives make decisions. The way to do this is to shut down your application security program and build an application risk program. By doing this, security practitioners can better participate in business discussions that come down from the executives and Board – this will drive a true digital transformation.

It may seem pedantic, but a poor choice of wording can lead to the wrong decisions. But shifting to an Application Risk Program goes beyond a shift in naming; it’s also a shift in technologies, processes, mindset and culture. Talking about “security” naturally focuses most people on vulnerabilities and implies a rigid perspective that leads to questions such as: “Have you closed all vulnerabilities with a CVSS score of >7.0?” Anyone who has spent any length of time triaging, investigating and remediating vulnerabilities understands that scan scores do not correlate well with the actual business risk of a specific application and significant time is wasted chasing vulnerabilities that lack real-world risk.

The right question to be asking is this: “Is our application security aligned to our business goals and tolerance for risk?”

Risk scores from the throngs of security tools spread throughout the organization tend to focus us on the wrong things. Scan “findings” are assigned to people to remediate without any regard for the context that affects the real-world risk of the finding. For example, a SQL Injection finding may have a “Critical” scan score but that label doesn’t tell the whole story. Is the application Internet-facing? Does the application contain PII? If so, this PII is exposed by an Internet-facing API with proper security controls? In many cases, a “vulnerability” with a score of 5 can be much more significant than another with a score of 10, depending on the context.

On top of that, a true risk-based, shift-left approach will focus on risky material changes before they even become vulnerabilities at the Pull Request. For example, Security and Development teams can automatically initiate a security review when a new developer changes the logic of a sensitive module that is responsible for a money transfer. It’s not a vulnerability, it’s a change with context that might introduce a business risk. When a UI element is changed – accelerate its path to production.

The role of a Security team at high-performing organizations isn’t to eliminate risk. There is such a thing as too much security, which occurs if security requirements are overly burdensome and impact the speed of development or the user experience to a significant degree. The role of Security is to have a very deep understanding of the security and compliance risks to the business and provide the appropriate level of security while enabling the business. This requires working with business leaders and executives to understand business goals, from growth requirements to risk tolerance.

As 2021 progresses, forward-thinking Security teams are shifting their approach towards understanding and evaluating their business’s appetite for risk. Taking an overly-restrictive hard line halts progress, stunts innovation, and marginalizes security. Would your organization be better off if it delivered software 20% faster but increased risk at the same rate? That is a business decision not a security decision!

As you build an Application Risk Program, keep in mind that it needs to not only focus on the software; it also needs to focus on the entire development process. The code is critically important but it’s only one part of a larger picture. Gaining an accurate picture of risk involves deeply understanding developers and their expertise. It requires understanding everything from the user stories to the commit messages to the pull request discussions to the settings on the API Gateway. In short, it requires a deep understanding of your SDLC process from design to code to cloud.