How to Build a Layered Approach to Application Security Testing

Siloes still exist in cybersecurity, where related functions and activities operate asynchronously with other parts of the organization. This is especially true with application security. 

Various tests occur throughout the software development life cycle (SDLC), but they often lack context or are not in sync with other security activities, leaving organizations with gaps in coverage and a narrow view of their AppSec program.  

To help change the way we approach application security testing today, three Appsec experts came together to discuss this topic in the webinar, Application Security In Depth: Understanding The Three Layers Of AppSec Testing. In this blog, we’ll share key takeaways from the discussion, which features Moshe Zioni, VP of Security Research at Apiiro; Nabil Hannan, Managing Director at NetSPI; and Samir Sherif, CISO at Imperva. 

Why Context is Key During Application Security Testing 

Contextual data is important. It helps organizations understand their SDLC through a broad lens and assists in prioritization of workflows and next steps. Not all vulnerabilities identified will be fixed immediately, and context is key to remediating those that pose the highest risk to the business first and fastest. 

Moshe shares the following five different contextual triggers security leaders should pay close attention to in the SDLC. 

Five Contextual Triggers to Leverage in the SDLC 

1. Design: At the design stage, prioritize according to what threat model sessions you’d like to have. If there are several designs going through an agile development life cycle, prioritize that by balancing between the capacity we have as security practitioners to the actual deployment. This stage is also important for triggering contextual compliance review. If something is required for compliance and you didn’t prepare for it, this will costly and difficult to go back and implement. 
2. Branch: After a pull request, you should have context around the code itself. First, analyze the code. This can be accomplished by a review or any automatic tool to enrich the data and provide us with data for the code itself. Through this context point, you can get multiple triggers according to workflows, how lean you want to get, and what priority you have for the commit itself. If you have a commit, which is highly prioritized in terms of sensitive data or a new developer, these context points create a weighing system to help automate the risk questionnaire and code governance. Once the automation is developed, you’ll have some cadence and governance rules for when to trigger each point instead of triggering everything. 
3. Repository: At the repository level, you gain context about the repository, what kind of business impacts we will have for the application, what information passes through the application, and who is the customer. These points provide you with a coherent view of what needs to be done to secure your application. This is especially true if you need to have compliance rules. The repository is not to be overlooked and should have triggers and workflows.   
4. CI/CD: The last point of the coding journey is the CI/CD system, or any integration and deployment processes. CI/CD is fluent, so there will be cycles going on throughout the organization. There should also be a lean and safe process for the CI/CD itself. Integrity and provenance for the CI/CD are important to have in terms of automation – as well as putting in place integration for integrity checks across the CI/CD life cycle. 
5. Production: Before production, you should have another set of eyes look at the information for anything that looks suspicious. 

Along with the context points and material changes, Moshe explains that “all of this comes together to a create a complete picture and mission, which is an ongoing cycle that doesn’t disrupt and interrupt the deployment process but gives you confidence on what kind of design and code you’re going to push to the cloud.” 

Best Practices for Application Penetration Testing and Secure Code Review 

Many different application security testing activities are completed throughout the SDLC, but penetration testing and secure code review are two of the most common and effective.  

A larger concern, however, is that organizations struggle to optimize the results of these due to a lack of clarity on the results they want to achieve. Below are five best practices organizations can implement to optimize these tests. 

Five Best Practices for Application Penetration Testing 

1. Determine your business objectives. Organizations need to have a clear understanding of their business objectives and how they will make money. This will aid in building a proper application security roadmap and help organizations allocate resources and identify which areas to focus on. 
2. Contextualize the vulnerabilities. Don’t just perform a security test, fix the vulnerabilities identified. This means understanding the vulnerabilities, contextualizing them based on the business risks, and figuring out which ones to remediate first.  
3. Acquire buy-in from finance and risk leadership. Gaining support from finance, the Chief Compliance Officer, and other risk leaders and partners will enable organizations to perform testing on a regular cadence with the appropriate resources and budget for testing. 
4. Perform proper threat modeling and design level analysis. Then, utilize the results to determine new and creative ways that attackers may be trying to gain access to company-wide assets or software that can’t be derived from regular pentesting. 
5. Invest in continuous pentesting. Point-in-time testing is no longer sufficient if organizations want to protect their software and assets. Instead, it’s time to invest in continuous pentesting to keep up with the rate of change organizations face today. 

One of the earliest times to detect a vulnerability is when the code is being written. Nabil shared this advice on how to start, “From a secure code review perspective, make sure you start aligning different tooling technology and code review activities with your software development cadence so that they are in lockstep in how they’re performed.” 

Here are six additional best practices for secure code review. 

Six Best Practices When Performing a Secure Code Review 

1. Don’t get complacent. Organizations should be rotating the people who are reviewing source code over time, so everyone is immersed in devising creative ways to discover and fix vulnerabilities.   
2. Build a methodology for code review. Create a champions program where developers are being trained to write secure code from the get-go. Then reward them for their efforts.  
3. Transparency is key. Similar to the pentesting best practice above, organizations need to make sure they’re involving folks in leadership and other areas. This means explaining the need for security testing at the code level and how tooling, manual reviews, and automation are helpful with the development process and help build the software securely. 
4. Prioritize onboarding and scan frequency. Organizations should be testing the right assets, the right applications, and at the right frequency and key timeframe. 
5. Provide the proper training: Determine how to deal with the different bugs and vulnerabilities that were discovered. This is where it’s important that developers are equipped with the right training and education to fix these vulnerabilities. Another thing to consider is to gamify training so that folks can consume remediation guidance in bite-sized pieces.  
6. Measure and Improve: Aim for continuous improvement. To accomplish this, organizations need to ensure they’re capturing key metrics and evaluating remediation rates. Are there vulnerabilities that keep recurring? Are developers writing better quality code over time? Are they able to abstract out certain security controls and put them into a secure development framework to help you reduce the cost, time, and effort it takes to fix the vulnerabilities? 

Want to read more on secure code review? Check out these blog posts: 

• The Importance of Reviewing Source Code for Security Vulnerabilities:
  Two Years After the SolarWinds Breach 
• Shifting Left to Move Forward: Five Steps for Building an Effective
  Secure Code Review Program 

Solutions to Consider in the Implementation Journey 

In application security, risk is one of the key drivers in delivering effective solutions for your application security program. “At the end of the day, it’s really about risk. How you manage risk and how you manage resiliency for your solutions. Not only from the AppSec perspective but also from the perspective of running your business and supporting the business that you’re in today,” shared Samir.  

Samir explained that the three biggest drivers for security testing include: 

• How well am I protecting customer data? 
• How effectively am I building resilience for the technologies that I am providing as a service to customers? 
• How well do all the different capabilities from infrastructure security to monitoring solutions interplay with each other in application security? 

What matters most in application security? According to Samir, there isn’t a single solution. We need to have a comprehensive view across the whole environment. Here, Samir shares examples of solution capabilities he recommends that security teams must implement – especially if you are selling or servicing solutions to your customers.  

• Awareness and Education
• In-App Protection
• Advanced Solutions
• Code Analysis
• Perimeter Protection
• Proactive Solutions 

Awareness, education, and code analysis will continue to evolve. Adversaries are always changing the game when it comes to finding vulnerabilities given the popularity of third-party and open-source components. There is always a new need to look at different capabilities based on this risk context. Solutions that are not only advanced but practical will be increasingly important.  

Samir continued, “Shift left-to-right is critical.” To measure the application security program, organizations need to look at the SDLC from one end to the other. From different contexts – how they develop and train their engineers to what they’re seeing on the infrastructure side with solutions that provide visibility into how they’re deploying and the types of attack patterns that target their applications.  

Understanding the interplay between these capabilities will help organizations understand what to address and prioritize to drive the effectiveness of their application security program. 

A Layered Approach to Application Security Testing  

Using the strategies discussed in this blog post and in the webinar, you’ll be able to implement a layered approach to AppSec that will help you build a world-class AppSec program. It starts with learning how to incorporate a risk context across the SDLC, then determining the key timeframes to implement application security testing and understanding how your solution capabilities interplay with one another.

Team NetSPI