/mar 30, 2017

A Veracode Program Manager’s Perspective: Best Practices for Scaling an AppSec Program

By Griff James

“Amateurs talk tactics, professionals study logistics.” -- General Robert Barrow, Commandant of the USMC

In military circles, “cyber” is spoken of in the same terms as the traditional spheres of conflict, namely land, air and sea. To that end, General Barrow’s quote is particularly apt. Unlike the other realms of conflict where armies, navies and air forces protect individual citizens, cyberspace is distinct in that private organizations are now on the front lines.

As cybersecurity professionals, we need to take a wider perspective on the threats posed to the organisations we protect, especially at the application layer. It is no longer sufficient to conduct a limited range of security tests on a small number of critical applications. Any external application is now subject to exploitation from attackers, and internal applications can be part of a complex attack chain to exfiltrate sensitive data.

With ever more applications in production and exposed to ever-increasing threats, security program managers need methods to rapidly scale their application security programs. It then becomes not a question of the tactics to secure a handful of apps – but the logistics to secure hundreds.

Defined by the Oxford Dictionary as “the detailed organization and implementation of a complex operation,” logistics in the application security space can be understood through:

  • Organisation of work via the analysis of the work
  • The implementation of process via analysis of the context

In 2015, I was part of the Veracode team asked to scale a global financial institution’s third-party AppSec program from 100 applications to over 400. We had to do this without a significant increase in resources. To achieve this ambitious goal required a thorough understanding of the tactical aspects of AppSec, a clear-eyed analysis of the work and the context, and the right tools for the job. 

The Work

Working to deliver the expanded AppSec program led to the creation of the 8 Steps to Application Security, which are common to all AppSec programs:

1. Scope Definition

2. Data Gathering

3. Onboarding

4. Uploading

5. Scanning

6. Review

7. Remediate

8. Mitigate

Scaling your AppSec program is fundamentally about moving applications through the work associated with these steps efficiently. Here, the “Theory of Constraints” developed by Eli Goldratt is particularly helpful.

This theory dictates that the speed of any process is limited by the number of constraints. Conceptually, each of the eight steps is a possible constraint. Agile and Kanban philosophies can help as they are about keeping work in progress to a manageable level – effectively managing the constraints and organising the work. This is exactly what we did by dividing the workload into sprints, incorporating backlog refinement meetings, sprint planning sessions, and sprint review sessions to iteratively improve our processes. 

The Context

Analysis of the program’s performance and blockers within the Agile delivery model gave us a much better idea of the distinct context for the Five Parts of Third-Party Application Security. We learned that each consideration enables and supports the other stages, for example:

  • Application Inventory is enabled by Governance, and supports the:
  • Internal Mandate, which supports the:
  • External Mandate, which in turn supports:
  • Software Supplier’s Participation, which is itself enabled by the:
  • Governance of the program.

Understanding the aspects of these considerations within a client dictates how to best implement an AppSec program. 

The Logistics

A thorough knowledge of the work that needs to be done (and how to do it) can be combined with an awareness of the context for implementation in order to scale an AppSec program effectively. 

To this end, to deploy a logistical approach to AppSec at the client, we focused on three workflows. We designed each workflow in conjunction with the client’s security team to fit their internal culture. Finally, we learned from our observations about the context of a third-party AppSec program to manage dependencies:

  1. Internal Briefings – Combined scope definition and data gathering with an information session to confirm the application inventory and reinforce the internal mandate. This organisation of work addressed the key dependency of accurate data collection while recognizing the context of winning internal stakeholder support. 
  2. Supplier Briefings – Building off the internal briefing, the program onboarded and enabled suppliers while emphasizing the external mandate to win the software supplier’s participation in the third-party AppSec program. This focused on the critical work element of “Onboard” while addressing the context of winning supplier participation. 
  3. Supplier Onboarding Sessions – With a software supplier’s participation agreed, Veracode took the lead to onboard the developers, lead the upload of code, and provide guidance on the review, remediation and mitigation of any flaws found. With this work stream, the return on investment was realized in the “Review” work item, and the context addressed to implement a process to review the results. 

Overarching and supporting these three workflows was a Governance structure that promoted an “up or out” philosophy. This allowed the program to always be moving forward with little rework. Suppliers agreed within an established time and cadence, or were escalated to the client’s vendor management team. 

Summary Table:  Linking AppSec Work to the Considerations of Third-Party AppSec Programs

Time Boxed Work Stream

8 Steps of AppSec Achieved

5 Parts to Third-Party Security Achieved

  1. Internal Briefing
  1. Scope Definition
  2. Data Gathering
  1. Application Inventory
  2. Internal Mandate
  1. Supplier Briefing
  1. Onboard/Enable
  1. External Mandate
  2. Supplier Participation
  1. Supplier Onboarding
  1. Upload
  2. Scan
  3. Review
  4. Remediate
  5. Mitigate
  1. Governance

 

Introducing or scaling an AppSec program is subject to the same forces as any other change management program – namely people, process and technology. I’ve focused on people and process primarily because the technology is not a constraint. Veracode’s Software as a Service (SaaS), cloud-based platform is always on, and has no realistic limit on the number of applications that can be scanned at one time. Developers and testers do not need to be enabled, or profiles configured. By its very nature, the Veracode platform is biased towards a logistical approach to AppSec. 

By combining the SaaS technology with Veracode’s understanding of the people and processes of application security, we designed and delivered a professional AppSec program focused on logistics – achieving security at scale and speed.

Find out more about expanding an application security program in our new guide, Ad Hoc to Advanced Application Security: Your Path to a Mature AppSec Program.

[nid-embed:27891]

Related Posts

By Griff James

Griff is a Senior Associate Security Program Manager who joined Veracode in 2014 after previously working as a Scrum Master. He has a Master’s degree from the London School of Economics, and qualified as an infantry platoon commander in the Canadian Army. He lives and works in London, England.