In Threat-Driven Software Development, we focus heavily on the nuances of Operational Security and how to secure online services from modern threat actors. There are many books on Application Security, but not on this important operational aspect. How are they different? I think this quote sums it up best:

Application Security is an investment. Operational Security is a commitment.

Here is the full exerpt:

Understanding operational security

One phrase really helps underscore the difference between application security and operational security:

Application security is an investment. Operational security is a commitment.

At the surface, an application or service can really be thought of as a bunch of code and configuration. You can secure this code and configuration by investing in secure development, robust security assurance, and extensive validation (such as penetration testing). For a single instant in time, and with sufficient investment in the process, you can be fairly certain that you have a secure system

When considering a standalone application that users run on their home computers or servers, application security is essentially all there is. Your application security will likely be the same 10 years from now as it is today. You can look back at applications written decades ago, and the level of their application security was frozen in time the day the last developer submitted their final change.

Granted: in the dozens of years that passed, we have probably realized that there was more they should have done back then, such as preventing memory corruption vulnerabilities, but that is the rising tide of security. Still, the application did not suddenly become vulnerable to attacks it had previously been protected from.

For services, however, operational security has a half-life. It atrophies over time. If you walk away from a service and don’t touch it for 10 years, you’ll return to a crater where it used to be. The operating systems you’ve built on will have released patches for security issues that the whole world now knows about, and so will the open-source components that you’ve woven throughout your application. Your cryptographic keys and external HTTPS certificates will have expired. Keeping even these minimal aspects secure is no longer a one-time investment; it’s a commitment.

Things get even more complicated in a service that you’re actively improving. Just as with isolated application security, the security investments you make while building and designing new parts of the service will protect and secure the new additions. Unlike isolated application security, however, these new investments—because they are being accomplished by humans—will very likely reduce the security of what you used to think of as “done.” New microservices will add additional network exposure.

New service components, such as databases and key stores, will now need to maintain proper authentication standards. Then, as you discover new threats to systems, defending against these threats must happen not only for the new things you’re working on, but also for parts of the system that were previously considered “complete.”