As a Customer Success Manager at CA Veracode, I work with over 60 clients to help optimize their application security programs. Security programs come in all shapes and sizes, as they should, because not every organization is built the same. However, I’ve worked with enough clients to say that, regardless of whether your organization is in the Fortune 500 or Tom, Dick & Harry, Ltd., there are steps that any company can take to operationalize a successful AppSec program.
First and foremost, understanding your application layer will be the first step to understanding where to focus your remediation efforts. I always tell my customers “you don’t know what you don’t know,” and as your organization introduces more and more applications into the environment, the “don’t know” starts to outweigh the “know” quickly when it comes to potential risk. It’s fairly typical for even the most mature AppSec programs to focus their efforts on web-facing applications or any apps that process critical data (PCI, PII, HIPPA, etc.). However, legacy applications, marketing websites, third-party/open source apps and even internally facing apps comprise some portion of your risk. At the very least, having awareness into your overall application inventory will help your team prioritize its remediation efforts.
Building a culture of secure coding is an alien concept to a lot of organizations, especially since functionality and deadlines usually trump all else. With that said, more and more security personnel that I speak to are working to institute a culture of security within the development environment by providing their developers context around what secure code actually entails. Many young developers just entering the workforce haven’t been exposed to the nuances of cybercrime, since it is not a major component of many computer science programs. Considering all of this, instituting a programmatic Developer Training curriculum can help bolster the understanding of the inherent risks of software vulnerabilities and how to go about fixing them. This can come in the form of a thorough eLearning program catered to specific programming technologies or, even better, live instructor-led seminars focusing on a specific area of AppSec that is relative to your dev team. There are also a slew of security conferences and roadshows that pop up in almost every major US city (OWASP, BlackHat, DefCon, etc.). It’s never a bad idea to get people out of the office to network with other like-minded security professionals to discuss experiences and best practices.
Part of instituting a security-minded culture is to make security testing as seamless as possible. I can tell you that instituting a draconian “fix everything” security policy is a surefire way to bring your AppSec program to a screeching halt. Security policies are meant to be aggressive, but attainable, as not every flaw is necessarily exploitable.
Setting up a solid application security policy is often an iterative process. Starting with basic policy rules such as disallowing any high- or critical-severity flaws is a good starting point as it provides an actionable baseline without discouraging developers altogether. Over time, as your developers become more accustomed to security testing, you can fine-tune your policy to scale with your program as it matures. Instead of keeping the bar set at disallowing only highs and above, raise the bar to include medium-severity flaws and require more frequent scans before pushing to production. Developer adoption is one of the top reasons why AppSec programs stall, so it pays to minimize the barrier of entry, at least until you can gain traction and promote value across your dev teams.
Organizations have varying approaches to implementing security testing into their application deployment. Some choose to run tests just prior to launch while others take a more proactive approach and integrate directly into their development lifecycle. I speak to enough developers to know that the last thing they want to do is log into yet another portal to run a scan on their app in hopes of passing policy. They often ask how they can make security testing as streamlined as possible, and my answer always involves incorporating it directly into their development process. Incorporating testing as early in the SDLC as possible is the best way to minimize friction with security teams and ensure that your team is shipping safe code without sacrificing speed to market. That is why I push my more agile customers to integrate testing directly into their CI tools, like Jenkins, so that security scans are automated with each build. This enables dev teams to fix flaws as they find them. Granted, not everyone builds code the same way, but there is almost always a way to incorporate testing at each phase of the development process; it is just a matter of what makes sense for your team.
What does success mean for your application security program? We’d love to hear how you’ve leveraged these tactics as well as any others to gain traction with your program.
In addition, you can get more detailed information on our solution, and how our customers are finding success with their AppSec programs, in our new guide, From Ad Hoc to Advanced Application Security: Your Path to a Mature AppSec Program.