If you're reading this, I'm going to assume that you are an application security professional and that you don't need me to tell you about SolarWinds and Log4j. You already know all that stuff. So let's cut right to the chase.
Whenever you’re trying do something, whatever it is, it’s always best to begin with the end in mind. What is your goal? What are you trying to accomplish? Once you know that, the process of achieving your goal becomes easier.
In the world of application security, our primary goal is this: Securing software applications at the lowest cost. That’s our main purpose, right? Okay, then let’s dive right in.
Typically, our application security budget is spent on people and tools. Let’s create a hypothetical scenario in which we have four AppSec engineers and some automation tools. If each engineer is paid $250,000 per year and the tools cost $100,000, our total spend is $1.1 million.
$250,000 X 4 + $100,000 = $1,100,000
But here’s where things get sticky. Automation technology can generate more work than the engineers can handle, resulting in fatigue, frustration and burnout. Some of our engineers will quit, which will require you to replace them. Replacing them will be difficult since there are already 100 openings for every available AppSec engineer. Even if we manage to hire a replacement engineer in six months, he or she will probably cost us more than the engineer they are replacing.
If we stick with the current methodology, we’ll likely end up chasing our tails, because the automation technology will generate more manual work, the engineers will quit and we’ll need to hire new ones to replace them. Over time, our costs will rise and our ability to secure our software may actually decline.
Now I’d like you to imagine a new scenario in which traditional AppSec automation tools are replaced by AppSecOps tools with intelligent automation baked in. In this scenario, the AppSecOps tools significantly reduce the number of manual tasks that must be performed by the AppSec engineers. Reducing workload, in turn, enables us to reduce headcount. So instead of requiring four engineers, we need only three. Now our spend looks like this:
$250,000 X 3 + $100,000 = $850,000
This scenario saves us $250,000 per year and improves the overall performance of the AppSec team. Instead of four engineers trying to manage an endless flood of tickets, you have three engineers focusing on critical vulnerabilities that could undermine the company and threaten its existence.
Crossing the Chasm
There are a variety of ways to game out these scenarios and they all end up pretty much the same: the AppSecOps tools reduce tedious manual effort and save money. From our perspective, AppSecOps looks like the right choice.
If it’s the right choice, you might ask, why isn't everyone jumping on the AppSecOps bandwagon? That’s a great question and it has a simple answer: We’re still in the early stages of the technology adoption life cycle.
I’m sure that most of you have read or heard of Geoffrey A. Moore’s excellent book, Crossing the Chasm. In his book, Moore explains how the adoption life cycle resembles a bell curve with five distinct parts, each marked by a different level of adoption based on how people and markets respond to a new technology. The five parts are of the curve are:
- Innovators
- Early adopters
- Early majority
- Late majority
- Laggards
Moore’s insight was that there are gaps between the parts in the curve, and a substantial chasm – hence the title of his book – between the early adopters and the early majority market segments. The chasm described by Moore is not a trivial matter. Crossing the chasm is a make-or-break challenge.
AppSecOps is somewhere between parts 1 and 2 of the adoption curve. We’re still educating and informing people about the value and benefits of AppSecOps tools and methods. Ideally, by the time we get to the chasm, enough people will have gotten the message and we’ll have no trouble crossing over into the early majority segment of the curve.
At this moment, however, people are just beginning to learn about AppSecOps and most executives don’t really grasp the concept. Our job here in this chapter of The Purple Book is to educate, inform and awareness. We genuinely believe that AppSecOps is an emerging category of important new tools that will revolutionize the practice of application security. And we’re trying to get the word out to the larger security community. How will we know when we have succeeded? When every security organization has a budget for AppSecOps tools, we can declare success!
Don’t Be Pennywise and Pound Foolish
Let’s step back for a minute and look at the history of security in the modern enterprise. For years, the typical security budget has been divided into infrastructure security and application security. Most security organizations allocated roughly 75 percent of their budget to infrastructure security and roughly 25 percent to application security. Within application security, the budget was sub-divided into people and tools. Paying AppSec engineers typically accounted for 90 percent of the budget. The remaining slice of the budget was spent on tools.
Okay, that was the traditional model. But a lot has changed since that model was developed. Cloud migration, for example, has significantly reduced the amount of money we need to spend on infrastructure security. At the same time, people and organizations are more aware of the risks posed by software vulnerabilities. And software itself is becoming more complex. Monolithic applications are being supplanted by microservices, which means that instead of getting by with a limited number of tools, you might need a slightly different tool for each microservice within the application.
As a result of these converging trends, we are seeing a shift in spending, with less money budgeted for infrastructure security and more money budgeted for application security.
That’s good, right? Not necessarily. We’re scanning more code and using more tools, all of which creates more work for AppSec engineers. Yet there aren’t nearly enough AppSec engineers to fill the existing openings. So now we have a problem that money alone cannot fix. We have to start being smarter about how we approach application security. That’s why we’re talking about AppSecOps. We believe that AppSecOps is the right approach for achieving security at the lowest cost.
Frankly, I don’t think it’s a stretch to say that we need a new category of tools for enabling and supporting an AppSecOps strategy. It’s not unusual for new categories to emerge as circumstances and conditions change. For example, when collecting and analyzing data from multiple sources became a serious challenge for security teams, SOAR (security orchestration, automation and response) platforms emerged as part of the solution. SOAR, of course, focuses on infrastructure security. But I see no reason why we shouldn’t have a category of specialized tools and solutions for AppSecOps.
As mentioned earlier, I think the category is already emerging and is gradually working its way through the early stages of the technology adoption life cycle. Precisely how long this evolution will take is hard to say, but I am certain that it will continue. The pain is real and the problems won’t go away by themselves. The more important question, I believe, is what can we do to accelerate the process and educate more people about the benefits of the AppSecOps approach? I am confident that as more people become aware of AppSecOps, adoption rates will pick up speed. We all can’t be early adopters, but when it comes to AppSecOps, being a laggard seems like a poor choice.
Build or Buy?
Now that we’ve established the argument in favor of AppSecOps, the next logical question is whether to build or buy. This question should be relatively easy to resolve. Unless you are Amazon, Google or Facebook, the chances are that you will use SaaS tools to handle your application security operations. Building them in-house may seem appealing, but the costs will be prohibitive for all but a handful large companies. Developing your own tools can cost tens of millions of dollars, as opposed to buying them, which may cost hundreds of thousands of dollars.
The good news here is that the custom-made tools used by the large tech companies today often become the SaaS tools of tomorrow. If you don’t want to wait for the custom-built tools to go mainstream, however, you can find vendors providing first-rate AppSecOps tools on The Purple Book Community’s resource page. Also, it’s important to remember that you will likely want to tweak the tools you are using to suit your organization’s specific requirements. Here’s where it pays to have a close working relationship with a small or medium sized vendor who is more likely to respond quickly to your needs than a huge company with millions of customers.
Concluding Thoughts
We’re living in unsafe times. What was considered common wisdom now appears questionable. Appearances can be deceiving. Strategies that were successful yesterday may not be successful today or tomorrow. You need to be aware of what’s happening in the moment, and adjust your plans accordingly.
It is indisputable that application security is a paramount issue. The sooner you develop a strategy for managing it, the better off you’ll be in the long run. As mentioned earlier, some will argue whether it’s better to build or buy. At this point, frankly, building seems like a poor choice. Here’s why:
Building takes time, which means that you are prolonging your exposure to potentially devastating risks.
The talent required to build an application security solution from scratch will be hard to find. There is already a serious shortage of qualified software developers. And let’s be honest: great developers don’t really want to work on what they perceive as unsexy back-office applications, so you will probably end up paying a premium for their services – assuming that you can hire them in the first place.
After you’ve built it, you need to integrate it, manage it and maintain it. None of these are easy or simple tasks that you can merely delegate. Believe me, they will add significant costs to your operation.
You will need to update whatever you build, which will add more costs and more headaches.
From my perspective, the greatest problem with building it yourself is the loss of time. There are a finite number of minutes in every day, and you should be using them wisely. Spending 12 to 18 months managing the development of an application security solution is not, in my estimation, the best use of an executive’s time. Again, your time is precious. I think it’s fair to say that at this moment, taking the SaaS route is the best strategy.
.svg)
.svg)
