The cyber security industry often frames application
security as a singular entity with a similar model, approach, and employee requirements
across the full range of organizations.
If only that were correct.
A key difference among application security models and
approaches isn't the toolsets involved or the level of automation of those tools in the build pipeline, it's where the analysis of defects found by those tools takes place. The differences
in each approach or model drive requirements for skillsets, resources, and scope with potential impacts
outside of the cyber security team.
Your organization will have some fundamental decisions to make.
In some models, the development team performs the analysis
of app security defects. The app security engineers tend to be tool focused.
The output is simply passed to the development team. Application security engineers
only need to have some familiarity with OWASP and other app security
vulnerabilities as the analysis, prioritization, and severity of the defects is
performed by the dev team. The downside
of this model is that (1) the dev team will need to be resourced to handle this
analysis and (2) in many organizations, it’s the devs that have to process
through the inevitable false positives and duplicates.
In other models, an outsourced vendor performs the analysis
of app security defects. They may also run the tools. From interviews, I’ve
learned that some with the title, “application security engineer” actually
represent the organization to manage the app security vendors. The downside
here is (1) the potential cost of buy vs. build and (2) the organization may
not be building longer term expertise, knowledge, and historical data around
application security.
In still other models, the application engineers perform the
analysis of the defects. The upside of this model is that the app security team
provides tangible value identifying false positives, removing duplicates, and
often validating the automated classifications provided by the scanning tools. The
downside is the depth of specific application development knowledge and
experience required of the app security engineers. In my team’s case, we focus on hiring previous
developers and automated test engineers as we’ve rarely interviewed security
engineers that have the ability to perform such tasks at a high level.
So, when you are doing comparison between programs or
listening to other senior cyber describe their application security program,
there may be variances that don’t necessarily fit your organization’s goals,
budget, or ability to resource. Some organizations can do great with a high
percentage of app security interns because the work and the costs of detailed
defect review are likely being borne elsewhere.
You’ll also need to dig in during interviews to determine the
fit of candidates. The title of “Application Security Engineer” can mean many
things from “I throw the switch on tools” to “I manage a vendor” to “I look at
defects and analyze them”.
One size does not fit all in application security. As they say, “all models are wrong but some are useful.”
Hopefully, you find these useful.
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
