Wednesday, October 2, 2019

An Application Security Program Is More Than Scanning

Just like vulnerability management is larger than just patching, application security is larger than just scanning applications. We can’t confuse performing a group of application security activities with having a application security program. 

If execs don’t understand the connection of the program to their business objectives, then you don’t have a “program”.  You have activities. Activities that aren’t likely sufficiently understood, connected, or compelling to have the level of funding that is needed to cover the requirements of securing your key applications. 

In that context, why should executives provide more resources?  Would you?

A comprehensive application security program will have multiple components:

Security governance: Written standards and policies that define and guide application security in the organization. You can’t hand out speeding tickets without speed limit signs. 

Application inventory: a security team can only protect what they know about. The list should have a prioritization based on organizational strategy and compliance requirements. 

Application Scans: Static and dynamic scans that provide baseline data for analysis to evaluate the quality of secure code and vulnerabilities that may be present. 

Regular team engagement: a regular drumbeat of formal meetings between teams to understand current priorities and identify/track issues from a common backlog 

Developer training: A program of instruction around the secure development and design standards as well as formal training for devs and architects 

Threat modeling: Answering the questions, “what are we doing?”, “what can go wrong?”, “what will we do about it?” and “how are we doing?”

Penetration testing: A capability that periodic tests the security of applications based on their prioritization. Pen testing can also be used to determine the efficacy of threat modeling efforts. This can be internal or external. 

Reporting and metrics: Using program data and program outputs to answer questions such as, “how are we doing?”, “where should we be focused right now?”, “what are our gaps?”, “are we getting better over time?” and “are appsec resources being used to maximum value?”

Capability building and Projects: The roadmap and project oversight to address program gaps and audit findings.

Security architecture: Definition of required application security controls/tools as well as ensuring controls coverage that protects application integrations, data entry/exit points, and development processes. I’d also include any network compensating controls here. 

The program data points are drawn from the long list of activities noted above. Gaps are gaps. Note them as such.

 Now, a cyber security leader has to turn all of this activity that determines current state into a program with objectives, a roadmap, resources, and gaps. This is the part that the execs should be hearing about and seeing, not the nitty-gritty details. 

Objectives. Current state. Roadmap. Resources. Gaps. 

In short, a summarized but compelling presentation of how application security fits into the business and the value that the program provides. 

Only then will you have a true application security program that can be briefed to executives in a way that they'll understand. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.


No comments:

Post a Comment