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.
SEE ALSO
No comments:
Post a Comment