Application Security Isn’t A Business Advantage Until You Frame It As One

Leading a successful application security program would be so much more effective and easy if there was a “security as a business advantage” easy button. Maybe even a scan or framework that could ensure that security is aligned with the business. Unfortunately, there isn’t. Application security has often been omitted from that alignment….

The result is a particularly hard problem for many CISOs: how to link application security activities to business objectives or, harder yet, keep sufficient interest in the building of an application security program that provides tangible business advantage.

The challenges to demonstrating business value are multi-dimensional:

• Identifying/remediating application vulnerabilities suffers from the same issues as cutting costs in some organizations. Neither is usually a primary driver for calculating business value until real pain is felt. While we, as security practitioners, can see the value, the average business leader won’t prioritize these against revenue, customer engagement scores, etc.
• The application security function is largely defined by tools and vendors. These vendors have done their marketing and sales jobs well. I’ve spoken with CISOs that believe that the breadth of application security focus involves vulnerability scanning.
• The OWASP Top 10 are a great resource for guiding effective developer level conversations, “shifting left” engagement, developer standards, and application security policy but, beyond some fundamental education value, the Top 10 list are by themselves far too tactical to demonstrate business value for senior executives or Boards
• Pen testing is only a small sliver of the overall application security landscape and, again, tightly focused on finding vulnerabilities. While coverage might be interesting at the executive level, the findings from pen tests are often very tactical.

Preparing To Frame Business Value Conversations Around App Sec

So how can senior cyber security leaders think and frame conversations differently about the application security function in a way that business leaders can clearly see and understand value? Let’s dig deeper to see how to prepare.

We’ll have to first understand our organization’s broader business objectives. No blog post can do this for you. The author can’t possibly know what the key levers are in your organization.You’ll find examples to try in this post but they may or may not directly apply to your organization. The levers for success can vary widely (revenue, customer engagement scores, intellectual property portfolio, etc.), particularly in less regulated industries . Please regard the examples included in this post as a starting point for your thinking and not as a checklist.

Once you understand the broader business objectives, you will need to transcend the current capabilities limitations of application security tools. Tools are not your program. If we assume that programs are built on 5 elements — goals, roadmap, current state, resources/capabilities, and gaps — tools should only represent a small percentage of any program. You’ll need to think through the breadth of a robust application security program.

You’ll also need to flesh out how you want to measure business value. You’ll want to use measures that can raise the level of discussion from the tactical to the senior executive level. I like coverage and effectiveess measures but there are likely lots more ways to frame status, progress, and gaps.

Some areas to consider…..

Adding Business Value To Application Security Standards And Governance

You may be thinking that standards and governance are obvious areas to demonstrate business value. You might even point to your OWASP Top 10 focused application development standards or policy. I’ll agree that general software development and secure coding standards are a great start. Data security standards in development environments also can be helpful.

That said, coding standards are simply table stakes for the business conversations around value. Some organizations place value simply in having the document. But, from a program perspective and business value calculation, once in place, now what?

While the OWASP Top 10 are a really important measure and guide for secure coding, there are lot of other areas for attention outside of the Top 10 that need to be considered as well. How do you measure and communicate that the standards are being followed? Can you demonstrate how well these secure coding stadards are being internalized? Code rework, perhaps? Do you know what teams tend to develop the most secure code? The least? Why in either case? What can be more broadly replicated across the organization to make code more secure?

Coding standards are fairly distant from providing measurable business value. What if the security team shaped the standards and principles for more non-traditional areas that were more directly aligned with business value?

Right off the top of my head….

Is the security team engaged with the contracts team to ensure that the right contractual clauses are in place to ensure that software development vendors follow your security standards? Have you helping to contractually define the required set of security controls set that would be needed if vendors don’t use your code repository? The access requirements and frequency for code reviews and vulnerability scans? Working through these issues requires business engagement beyond a console but also generates value to the business.

Let’s shift gears with a different example. I’m thinking about an organization that’s building a service oriented architecture so external organizations to consume APIs.

Everyone thinks about the start of the API lifecycle. Who in your organization id effectively thinking about (or is even aware) of how to sunset APIs? Is it part of your business conversations? Is it a challenge? For instance, how would an API consumer know that a given API is being deprecated or has already been deprecated? How would security issues be handled? Is the response process clear to your API customers? Are there situations that a customer’s app might break for a serious security issue? These are architecture and business conversations to which the security team can not only contribute but also help provide value in implementation.

A third example: what if the team defined the security standards and principles around customer self service for API access? Without continuing to dwell on contracts too long, if any of the self served APIs included personal information, would the developers know to ensure that the consumer has the right model clauses in place to cover GDPR requirements?

The possibilities are endless.

Adding Business Value To DevOps

The DevOps function, its ownership, and relationship with the cyber security function can vary widely by organization. For some organizations, the cybersecurity function is the DevOps function. In others, infrastructure engineers have had a name change to “DevSecOps” and added some security related logging. In still others, static and/or dynamic scanning is the extent of the application security aspects of DevOps.

Who owns what? A lesser emphasized area for providing the cyber security team to business value is around the definition, governance, and coverage of security controls around the build process. I’m not a big fan of governing developers in pre-production but cloud based development and integration of third party libraries into code require some level of basic governance.

Lots of great questions to ask? Is there a controls catalog or library of security controls that govern pre-production development environments? Static, dynamic, and license cans are one type of security control in the build process but not the only kind. Pen testing is another but, again, don’t limit yourself to these areas even if major conference agendas focus heavily in these areas. In short, you’ll not only need to think through the individual security controls for each step of the build process but also also collectively analyze your control coverage as well.

Do you measure your controls coverage of the devops pipeline? If not, there likely is an opportunity to do regardless of the devops ownership model in your organization. If so, is the current controls coverage sufficient, reasonable, and nimble to cover the risks for your business leaders? Your application security tools can be of help here. Can you capture the business value of “sufficient”, “reasonable”, and “nimble” in terms that the business can understand if each of these are being met? What are the associated costs if they are aren’t being met?

These are all possible data points for business conversations driven by your application security control strategy and the current state of coverage. The results of findings from a relatively comprehensive application security maturity model such as SAMM (Software Assurance Maturity Model) can also add value to that business conversation.

Adding Value To The Online Or Mobile Customer Experience

Wait. What?!?

You might be thinking that the cyber security team isn’t part of the customer experience, but perhaps it should be. Is there any better way to demonstrate tangible business value to executives than being integrated with and ensuring a secure and frictionless experience to online or mobile customers?

A key point before continuing: Your cyber security team will only be able to build or add value to customer experiences if their security house is mature and otherwise in order. If that house isn’t in order, any security investments are better focused on maturing the broader security capability.

With that said, where are some engagement opportunities for a cyber security teams to influence the customer experience outside of vulnerability scans?

Deeply integrating security into the existing business process to design and build your organization’s software is clearly a value-add. Having a separate process would lkely be less so. One of the most impactful places would be involvement and representation in the enterprise level scrum process. To me, the obvious touchpoints would be grooming of security specific stories and epics as well as security/privacy reviews of non-security stories and epics.

As part of the broader enterprise scrum process, your application program should also be better plugged into major new initiatives, deployments, and changes. These should provide new surface area for continuing to define business value for application security.

Owning or facilitating a robust threat modeling process is another area to add direct and tangible business value. Threat modeling is part of providing value in the design phase of both applications and infrastructure changes. Don’t confuse “robust” with “onerous”. A relatively light threat model process that ensures that three simple questions are answered about critical functionality can be incredibly valuable. The three key questions are:

• What are we building?
• What can go wrong?
• What are we doing about it?

Again, determining coverage of threat modeling efforts can help to define value and gaps. This is particularly for ensuring that critical functionality like billing or login meets threat modeling goals for the business.

Security teams can also add value by become directly involved in the coding of security features and/or automation. While respurcing might be a consideration here, this may result in business opportunities from this work to add to a organization’s intellectual property portfolio or to “productize” the functionality for sale externally.

Summary

Application security teams have myriad opportunities to expand their capabilities in ways that provide more direct and measurable value than just vulnerability scans and pen tests. This post has only touched on some ideas and possible opportunties around standards, DevOps, and influencing the online or mobile customer experience.

What makes business value hard to calculate is that it tends to be very specific to your organization. That said, there are common themes lke measuring coverage and effectiveness that can bring an otherwise tactical discussion to a senior executive or Board level.

If you are a CISO or senior cyber leader, you own framing the value. Hopefully, this post has started the thought process.