The Holistic Application Security Approach: The Journey of a Security Architect
For the past year, I’ve played the role of a security architect in an enterprise-grade company. Before that, I was mainly focused on the side of breaking the products that I now work to protect. Although having this expertise gives you the ability to think like a hacker and therefore hold a deep understanding of what you should protect from, it doesn’t give you a clue on how to build and maintain a secure product.
In this post I will try to give you a better understanding of what the role of a security architect is by discussing the various approaches to application security. We’ll start by diving into the advantages and disadvantages of the two approaches — top down and bottom up. Then, we will discuss a new, holistic third approach.
If you have ever felt like application security is an obstacle you can’t tackle, I want to share with you my idea on how it can actually work. This vision also describes the ideal security architect so if you are one, aspire to be one or work with one, you should find it interesting.
Application Security — Top Down & Bottom Up
Before presenting the full application, security vision or describing the security architect role, let’s get familiar with an analogy. In that analogy, application security can be split into two strategies: the top-down approach and the bottom-up approach.
The Top-down Approach
The top-down approach, which is the more common approach to application security, builds a centralized ecosystem that all products derived from.
This approach includes:
1. Deploying SAST/DAST solutions into the organization
2. Creating a central security experts’ group that supplies services to the product groups
3. Building a secure pipeline with integrated security controls such as container image scanner, third party vulnerability scanner or fuzzer that continuously try to break your product.
Even though it sounds like a tempting approach because it performs at scale, I found it failing to solve a very basic but critical problem — building a secure product.
The top-down approach will significantly improve your product security. It will cover all the security aspects related to the infrastructure (docker image, 3rd parties, tooling, etc.), but it will never fix an insecure architecture or a wrong product management prioritization. There is no existing tool that will prevent a lack-of-security-expertise developer from choosing too permissive security group for their AWS deployment or prevent a product manager from deprioritizing a security best practice because the feature must be delivered quickly. In other words, the top-down approach is required but not sufficient. This problem leads us to the second approach, the bottom-up approach.
The Bottom-up Approach
In this approach, the security starts from the shop floor and is considered within the first step of the SDLC and at every stage thereafter. The bottom-up approach is built upon the security mindset, which states that the security of a product must be a common effort shared by all of the stakeholders, 24/7. Every design for a new feature being escorted with a security review and threat modeling is being maintained for the product. When a developer adds new user input to the product, they know that this input must be validated and sanitized to exclude opportunities of injections and the product manager knows and accepts that the effort estimation of the feature will be increased due this validation.
Decentralizing application security may sound too good to be true, so here comes the “but”. Although a security mindset sounds like a reasonable prerequisite, in reality, it just isn’t. Product managers often fail to understand the importance of security or just collapse under the pressure of shipping value to the customer under a tight schedule. Developers sometimes lack the expertise to understand how a feature might affect product security.
The security mindset also creates something I call “the security mindset paradox”:
“whereas the security mindset enhances application security by distributing the security across all of the stakeholders, it diminishes it due to distributed ownership.”
In other words, distributing application security (aka bottom-up security) is not enough. There is still a need for a centralized persona that will own the security process. So here comes the holistic application approach, with its security architect role definition, to solve this conflict.
Combining Approaches into Holistic Secure Software Development
Summarizing the approaches, we can notice the following conclusion:
So, the trivial question is — can we combine these approaches into a holistic approach that leverages the advantages of both? And if so, how?
Security architect role definition
And here comes my bottom line — yes, it can be done. How? By refining the security architect role definition. This security architect integrates both approaches to create a holistic solution.
This holistic security architect serves the top-down approach by owning (but not necessarily doing) the integration between the central security group and its product. Some real-life examples would be integrating security tools into the CI/CD pipeline, escorting an external PT, answering to customers or handling the product security certification.
This holistic security architect also promotes the bottom-up approach, by creating a security mindset. The most important role of the security architect role is to be a highly accessible application security expertise. As inside-group-positioned, the security architect has deep product understanding, which in turn enables them to bring forward deep insights — which developers value. As opposed to generic and very high-level remarks that usually come from a central security group, the security architect should be very specific and focused. Then, the developers will get more and more interested in application security. I can’t count how many times developers have stopped by my door and asked a security-related question or shared their thoughts on some security concerns they have. Over time, this different point of view creates the security mindset that every company should aim for.
In my experience, it is far from trivial to get to the point where you, as a security architect, are fulfilling these requirements. But what’s important is the progress. As long as you have your vision in mind, and you come every morning into the office every morning thinking about how to promote it, your product will be more secure, one step at a time.
