CISO’s Guide to a Modern AppSec Program

A guide for CISOs and security leaders to enable a business with Application Security and a shift left approach.

By: James Chiappetta

Disclaimer: The opinions stated here are my own, not necessarily those of my employer.

Background

If your organization produces or consumes software then it’s quite likely someone has thought about the security of it. From my perspective, there are a few main areas as it relates to securing software that I would like to discuss.

1. The first is how security leaders influence culture with the proper “shift left” design and processes to mature an existing security program so that it can be a business enabler.
2. The second is simply how one just gets started with building a modern Application Security (AppSec) program.
3. Lastly, there will obviously be organizations out there that may fall in the middle or even stand firmly on the opinion that “we just don’t need a full fledged security program yet”.

Irrespective of where organizations are, I wanted to share highlights of the playbook I have used in the past(1) that may help either guide or validate the path many are on for building their “world’s best” security program (more on that up next).

First Things First

World’s Best — Before we get started I want to discuss a fairly broad generalization. If you look at the vision statements of most security teams, they may very well include something about being the “world’s best”. This reminds me of the scene from Elf where Buddy the Elf sees the sign on a diner in NYC saying they have the world’s best cup of coffee. Always a good chuckle from me when I see this. But just because you are marketing that you either are or want to be the best, doesn’t mean you are even close to it.

Source: Elf (2003)

So, where are you really in the journey to world’s best and how can Application Security be a key program that helps you get there? Even if you are looking to achieve “not negligent” or “industry standard”, we will need to cover a couple of high level areas to making it all happen:

• Cybersecurity influence on Organizational Culture Change
• The Product and Application Security Program Checklist
• Building out AppSec Focus Areas

Let’s get to it!

Cybersecurity’s Influence on Organizational Culture

Find ways to meet the business where they are and work backwards from there —

More and more organizations want to have security be a core principle or tenet that enables how they do business. The challenge is, at the end of the day, security simply doesn’t drive most businesses. Many companies just aren’t close enough to lean on security as a business enabler, yet. Getting there will mean influencing its culture, just a bit. Changing a company’s culture is often a moon shot. Security Leaders need to bring security thinking and practices into the culture to enhance and evolve the culture as it matures.

The goal should be to not be a blocker but rather an enabler. Shifting left is a very common way to think about it. This to me means that you are moving the things that the security team focuses on (typically security controls and healthy vulnerability free systems or software) and getting those things accounted for sooner in the Software Development LifeCycle (SDLC). The image below is a super basic thought flow on how this can be illustrated.

Cybersecurity Cultural Influence

The Path to World’s Best

Relevance of Application Security —

At the onset of the post, I mentioned that someone has likely thought about the security of the software either consumed or produced by an organization and that is likely true. Application & Product Security, from my experience, has been a core area of Cybersecurity but one that has often been misunderstood (or not understood at all).

Why? Products and software vary company to company. Companies take different approaches because they are solving different problems and when it comes to organizations that build software, everyone thinks they are unique. On the flip side, some companies do not need an AppSec team, especially at places such as law firms or restaurants. That’s not to say law firms and restaurants don’t have a dependency on technology, but creating software is just not usually a core driver of their business. Organizations that do produce software, whether it’s embedded on a device or a web service, will likely benefit the most from the following checklist of AppSec activities.

The Application Security Program Checklist —

This checklist below should help you get started, close gaps, or validate the path you are on.

1. Assess the level of effort to influence change in the current software development lifecycle (SDLC). You will need to understand the entire process, tooling, and tech stack used across the organization.
2. Set up relationships with Product and Engineering leaders. Work to establish a support/partnership model for each business unit (more on this in the AppSec Partnership section).
3. Inventory the products and decompose the products and apps into components where possible. Extract relevant metadata about each. You can’t assess the security of your applications without having an inventory of them.
4. Dig into product development practices. Find what docs/templates and work tracking systems are in place. These are key integration points.
5. Survey engineers for the appetite of security involvement. Find those who have the greatest appetite and work quickly to build relationships. These could be your future security champions.
6. Embed security specific questions and tasks into the design and implementation phases of the SDLC. Lead with lightweight design reviews and threat models.
7. Use threat models to map out security requirements and prioritize alongside Product and Engineering. Track these in tickets.
8. Build a threat and control inventory using a standard framework (e.g. MITRE ATT&CK or CKC) and track TTPs. Consider the supply chain and infrastructure as a part of the overall product. This is just as important to secure these things as the first party code.
9. Build out a product and application risk register. This helps provide transparency about the level of risk the organization is living with day to day and can be a key way to get further investment.
10. Find opportunities to bring security to the masses for free or at low cost but with high impact by preventing vulnerabilities from ever making it to source code (a more technical look at that here). Some examples are secure libraries/middleware, SAST/DAST in CI/CD, training and education. This is how you reduce friction from the developer experience when implementing security visibility and controls.
11. Establish a set of basic security guardrails with engineers as a core driver in the conversation (this gets buy-in established early on). This is an opportunity that allows them to bring solutions to the table and make a broad impact across Engineering. For instance, deploy secure libraries to deal with XSS or setting basic headers or cookies.
12. Build out later stage development cycle security controls and processes. Use the data to inform earlier stage controls and processes to prevent things earlier based on threats and real world activity. Security penetration testing, bug bounty, web application firewalls (WAFs), external vulnerability scanning, and CAST.
13. Track the most important data that helps clearly articulate the value of the program to the business: time & cost savings, risk reduction or prevention, and developer engagement with the AppSec team. Use these data points as a way to baseline the program and establish the keep the lights on cost model for the team. Use it for strategy too: think about what will move the needle and what it will cost and when it could be delivered.
14. Empower the entire Product and Engineering team to “own” their security destiny. They will ultimately be accountable for the day to day decision making of the security of their products and software. Consider creating and collaborating on a RACI matrix as this can be an effective tool for identifying dysfunction and resolving conflicts with ownership. The AppSec team is there to partner to help make the best and most balanced decisions. Having the right tooling (CI/CD security scanning) and processes (Security Design Reviews) keeps things balanced and in check. Additionally, this should funnel into your risk register (see #9).
15. Always lead with the thought of business enablement and partnership. The AppSec team should exist to support the organization through continuous and ongoing help, not continuous and ongoing blocks.

Pro Tips:

• On the topic of risk ownership: Working with AppSec, the Product Owners should specify what the risk tolerances are for CIA (confidentiality, integrity, availability), so that when AppSec assessments uncover vulnerabilities they can be scored consistently and with the context of the product’s risk profile. This helps clearly prioritize what needs to be done and importantly what isn’t worth doing. This will get business on your side. Let Product answer the question of how important their Product is based on Risk. Then when vulnerabilities come up this helps them manage what importance each vulnerability has. For the best outcome, risk appetite decisions should be made with a threat modeling mindset.
• The more positive Product and Engineering engagement you have, the more Security will be in their decision making while developing. Additionally, taking a self-serve approach is the best way to get and maintain engagement with the development org.
• Where possible, take strategic approaches to eliminate or prevent entire vulnerability classes instead of playing whack a mole. One way to do this is to encourage or require safe libraries and frameworks. For example, if all frontends use React then you’ve virtually eliminated cross site scripting.

Building out AppSec Focus Areas

AppSec Partnerships —

This is an area of your program dedicated to the first couple of the SDLC phases (design and implement) where Product Owners and Engineers are the core stakeholders. Core services and activities that would be expected of this area would be security training, secure design reviews, product risk assessments, day to day advisory, and early secure code review.

Pro Tip: This is where you will want to build a personnel scaling model where for either/or X number of dollars or Y number of headcount behind a product line or business unit then Z number of AppSec partners focused engineers will be staffed. This model shouldn’t be one way and allow for contraction and shifts in Product specific capacity. This will allow for existing resources to be refocused as things change.

Security Tooling and Infrastructure —

This area is the backbone of the program and will span across the entire SDLC. The area would cover the building out of any core security controls for both the Application Security team and the Product and Engineering organization. Automation is going to be an essential part of what this area will bring to the table for the entire program. Examples that come to mind are tying tools into the CI/CD systems to surface vulnerabilities, implementing cloud security controls (e.g. Apache or Windows/Linux), and creating secure defaults for various technologies (e.g. Apache or Windows/Linux). Additionally, this area could own any workflow tools that the AppSec team needs for supporting the other two focus areas.

Testing and Operations —

This area focuses on a couple distinct areas which encapsulates the testing of the entire tech stack and the operational work. This is a vital area of the program where there will be a lot of manual effort. Testing would encompass full pre-production readiness assessments with penetration testing (pentest), externally scope pentest, bug bounty. Operations would own maintaining policies of any security controls such as a WAF or any SAST/DAST tools.

AppSec Focus Areas for Shifting Left

Pro Tips:

• This section gives an overview of the major focus areas of a successful AppSec program. To dive deeper into the details check out these AppSec maturity models: OpenSAMM and BSIMM.
• Be thoughtful on how you want the organization to be shaped. If you haven’t already, take a look at How to Develop an AppSec Team That Will Last Forever and keep an open mind about the design of the org as things change or evolve.

Takeaways

1. The Security leaders of an organization will ultimately need to shape the program and its focus areas to best map to the business. There are a number of steps and measures that can be taken to get you pointed in the direction of business enablement. Find ways to meet the business where they are and work backwards from there. This is going to be key in influencing the culture with the security thinking that is needed across an organization.
2. Put the effort in to map out the people, teams, processes, and technology of the organization. Don’t just understand this once but make it something that becomes an incremental way to rationalize priorities.
3. Place a focus on partnerships with Product and Engineering at a minimum. This is how you can make the biggest impact up front with both the program and influencing the culture. Support this with growth in tooling, infrastructure, testing, and operations but remember, you can’t shift any further left than the human brain (or at least I haven’t seen an instance yet where that isn’t the case).

Words of Wisdom

Everyone has a different view on the level of importance of Cybersecurity and it’s often for good reason. For some companies its table stakes and others its a line item in the cost of doing business. My guess is you made it to the end of this article because you want to make it more than just the cost of doing business. I will leave you with two quotes:

You did it! Congratulations! World’s best Security Program! Great job, everybody! — Future me to you

“Do the best you can until you know better. Then when you know better, do better.” — Maya Angelou

Contributions and Thanks

A special thanks to those who helped peer review and make this post as useful as it is: Brian Lozada, Luke Matarazzo, John Nichols, Conor Sherman, Farhan Ahmed, Ryan Weeks, and Jay Militscher

A special thanks to you, the reader. I hope you benefited from it in some way and I want everyone to be successful at this. While these posts aren’t a silver bullet, I hope they get you started.

Please do follow my page if you enjoy this and my other posts. More to come!