Practice Manager, Application Security, CISSP, CCSP, OSCP
Shawn Asmus is a practice manager with Optiv’s application security team. In this role he specializes in strategic and advanced AppSec program services and lends technical expertise where needed. Shawn has presented at a number of national, regional and local security seminars and conferences.
Quick Tips for Building an Effective AppSec Program – Part 1
An application security (AppSec) program can be defined as the set of risk mitigating controls and business functions that support the discovery, remediation and prevention of application vulnerabilities. Controls take the form of written policies, procedures, guidelines and standards for ensuring secure development practices, along with technology and operational processes that implement them. Focus is typically on internal software development capabilities, but may also encompass applications developed by external third parties and those from commercial vendors.
In this three part series, I’ll outline some key components to consider when building a comprehensive application security program.
Leverage Existing Frameworks and Models
If you are an information security professional tasked with constructing an AppSec program for your organization, we understand that you may feel overwhelmed. The good news is that there is little reason to start from scratch, as much of the foundation has been established and defined by various software assurance frameworks and models.
Frameworks such as the OWASP Software Assurance Maturity Model (SAMM) can be leveraged not only to create, but implement, measure and mature your AppSec program over time. One added benefit in aligning to a framework is that it gets various stakeholders (security, development, risk and audit) on the same page and talking the same language when defining objectives and desired outcomes.
When building out a program for the first time, you’ll want to define a roadmap that establishes program objectives, deployment timelines, scope and measurements for success. For greater likelihood of program viability and adoption, keep objectives achievable and activities only as complex as they need to be. Also remember to gain quick wins and document successes.
According to the OWASP SAMM: “There is no single recipe that works for all organizations. A software security framework must be flexible and allow organizations to tailor their choices based on their risk tolerance and the way in which they build and use software.”
Create an Application Catalog
An application catalog is possibly the next most critical element for developing an effective AppSec program. The catalog is an inventory of the enterprise’s applications that serves as a point of reference for making smart risk-based decisions, prioritizing testing and remediation activities, and maintaining proper governance and oversight of the entire program. Among other things, it should align with your organization’s risk assessment framework, rank applications by business criticality, and document compliance and regulatory testing requirements.
Depending on the complexity of your environment, discovering what applications are present in and utilized by the enterprise, including those in the cloud, can be challenging. Automated tools and manual methods can be utilized to produce an initial inventory. It’s equally important to incorporate catalog maintenance into change management processes.
See a previous blog I wrote (Secure SDLC Lessons Learned: #1 Application Catalog) for more on application catalogs.
Know Your Application Architecture
Understanding your organization’s application architectures is essential for both managing your technical risk exposure and constructing other portions of your program. By knowing what technologies are in play, you can start defining architecture standards and “secure by default” design patterns to abide by. Additionally, this information is useful for selecting and tuning tools used in the assessment toolchain.
For more mature programs, teams will de-compose application tiers into technical components and perform threat modeling to document mitigating controls and residual risk. Software composition analysis (SCA) technology and design documentation are helpful in the initial discovery of architectural components.
Chances are you already have some of these elements in place and just need to spend some time formalizing your program. With research showing that 50 percent of enterprises claim the application is attacked more frequently than the network in their organizations, it’s probably time to assess your program’s capabilities. We’re hoping these tips provide a little more insight to mature your program. In our next blog we’ll turn our attention to assessment toolchains, defect tracking systems, and vulnerability management.