5 Considerations When Creating an Application Security Program

Last updated at Fri, 12 May 2023 20:33:34 GMT

This is part one of a three-part series in our All in on AppSec Series.

Your customers expect it, compliance regulations require it, and your data depends on it. We’re talking about application security. Whether you have a brand-new or tenured security program, there are often dozens of questions that arise when it comes to implementing application security: Can it simply be an extension of our vulnerability management program? What should we prioritize? Who should be involved?

In a recent podcast, Rapid7 Product Consulting Manager Ben Glass and Penetration Testing Director Jay Paz explained how to address application security and how this translates into building better code. If you didn’t have a chance to tune in, here is a complete recap below:

Navigating the application security landscape

If you leverage any application internally or externally, you need the ability to continuously assess its threat, vulnerability, and overall risk exposure. As you get started, it’s important to understand the appsec landscape and how it differs from network or hardware security.

There are hundreds of tools out there, from WAST to SAST to DAST, and each tool is designed for a specific use case. However, how do you ensure a tool fits your use case? To begin, look at the makeup of your team. Who is in charge of developing and securing applications, and what skills do these team members have? Your answers will help you pinpoint what kind of tool(s) you should invest in. You want to buy a solution that your team knows how to use, tune, and get the most value from.

Building an effective appsec program also requires understanding the overall business strategy and doing proper due diligence during the buying process. Knowing what your overall environment looks like, which apps you use internally and externally, how you assess them today, and how security fits into your overall IT infrastructure will help you sort out the tools that aren’t a good fit from the ones that are.

Another important factor in deciding which technology to use is how fast it can provide value. Take dynamic application security testing (DAST) as an example. DAST tools give teams the ability to perform application assessments from the attacker perspective to see how applications respond if different components are exploited. This information is immediately useful because it can show you what to do to prevent an attacker from actually exploiting your applications.

This is very different from the static application security testing (SAST) most developers are accustomed to. SAST is designed to provide a single view of the security of the written code, while DAST provides many different perspectives and can be integrated into the build, scanning, and production processes to give you the full picture of the application in any environment. Most importantly, this can be done before it hits production, where it’s much less expensive and time-consuming to fix.

To see how an appsec tool works in action, how easy it is to implement, and how quickly it can provide value, we recommend running a proof-of-concept (PoC). By installing it in your actual environment, you can see how it works, how your team would use it, and what it’s like to maintain and tune it so you can make a well-informed decision.

Prioritizing your application security objectives

The next logical step when building your appsec program is to ask yourself where you should start and how you can prioritize what is important. As a security professional, it’s important to understand not only the technology side of the business, but also how application security can play a role to support the bigger picture. Knowing how your appsec initiatives will affect the overall business, IT, and security strategy also helps you determine how to measure impact.

Ensuring security won’t hinder productivity

With nearly every business today valuing agility, one common consideration when it comes to security is whether a new strategy or technology will help or hinder progress and speed, especially when it comes to the software development lifecycle (SDLC). Getting stakeholders involved in the decision process is key, as they each play a role in the SDLC and will be affected by any new technology that is brought into the mix.

Developers, application owners, CISOs, the vulnerability management team, operations team, reporting team, and QA team will all need to be involved, as well as cross-functional teams such as DevOps and NetOps. A PoC will help you see firsthand how efficient a tool is, how it affects your various stakeholders, and how it fits into the bigger picture.

Why your current vulnerability management program may not cut it

A question we often hear from security teams with existing vulnerability management programs is whether they can extend their current vulnerability management program to address application security. The short answer is no. Application security is about performing assessments to catch vulnerabilities before they actually become accessible to the public or internally to the company. It goes beyond scanning assets based on IP addresses.

While you can certainly start your appsec program with the foundation of your vulnerability management program, the real focus should be on building relationships with the application teams and finding ways to perform remediation before the code is pushed to a production environment. Plus, most application environments are dynamic, and therefore not well-suited for vulnerability scanners that are built primarily for static development environments. Especially if you’re looking to do dynamic application testing, you’ll need the ability to scan the entire IT stack—the applications and the networks they’re deployed on—and make sure all stakeholders are aware of what’s happening and why.

Introducing application security into your SDLC

While appsec is also about tools and testing, you first need to start by educating your team about what you’re looking to accomplish. It’s easy to treat technology as a silver bullet, but no technology will be entirely useful if your team doesn't know how to use it or why it's there.

To do this, begin by clearly explaining what application security is, why now is the time to implement it, how the SDLC will change with testing, and the type of testing that will be conducted. The specific tools and details of the process will come after this step. This will help stakeholders who are responsible for creating code, fixing vulnerabilities, or tuning the appsec solution understand how their role would change or be affected and what additional tasks, if any, they would be responsible for. There’s nothing worse than being blindsided, so educate them early on and be sure to get buy-in. From here, you can begin a PoC with a vendor to see the impact it has on your environment and team.

Is DAST right for your environment?

Having a robust application security program is especially crucial for teams operating in multiple environments—from cloud to on-premises to hybrid. Dynamic testing is key for fast-moving environments, allowing you to see how an application would stand up in any environment and giving you the ability to spot vulnerabilities before code hits production. This is in stark contrast to manual code reviews, which can fall victim to human error and oversight. Too often, developers get comfortable with the code and cannot account for unique and emerging situations that DAST solutions are built to find, meaning vulnerabilities can often slip under the radar during manual reviews, whereas they could be caught instantly by a DAST solution.

Fast-moving teams today are moving toward DAST solutions to spot issues faster and with more accuracy. To find the one best suited for your organization, we recommend starting with a PoC to see it live in your environment.