Re: [WEB SECURITY] "Enterprise Web Application Security Program"... necessary steps

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

Heya Dave & Rafal! This is one of the most important, overdue threads
on this list. Forgot about that article Mark wrote. The content is a
nice general overview.

Of course make sure you lie and tell Mark I said nice things about
him. (Mark and I worked together on the problem of software security
for many years for those confused by the banter. :))

You probably remember I got frustrated with these kinds of "Shopping
Lists" laying out all possible things that you can do in software
security in linear sequence, as if suggesting you should do them all
in that order. I found, time and time again, that giving people a long
list of options and "things to do" not only confused them -- but
ironically -- they often did less than they would if you gave them a
clear direction with small, bite-sized chunks.

The challenge with these shopping lists is that no one can afford to
do all of these things effectively, and few can afford to do more than
a few of them broadly, and even fewer effectively. Most companies are
not in the business of "writing secure code".

(Again for encore...Most companies are *not* in the business of
writing secure code and I am not sure they should be. Noting that
Writing Secure Code != Maintaining Secure Applications. And yes, I've
changed my thinking on this from where I used to be 5-10 years ago.)

What I see, almost every day, is that most folks at companies in
business to make money are looking for something that defines a
simple, clear starting line, multiple possible finish lines
appropriate for their business case, and a blueprint for how to get
"from here (start) to there (chosen finish line)".

In response to Rafal's last post -- I published a 5-point program
outline that folks could use to start building a decision tree of
"what to do where and why" and also for making blueprints for "how to
get from here to there".

Mark's shopping list follows the general flow of the 5-points I
suggested. :) But what people really need is for us to add evaluation
and selection criteria that allows for peoples' specific business
cases.

Mark and I have been helping people build software security programs
like this for a good five or six years, and have been experimenting
with "secure software" programs for a decade or so. Not much has
changed, other than people get attacked a lot more, and people buy
more tools and underestimate the resources required to use them
effectively. Pretty the same way the world of "network" security
evolved.

Most of the "program/strategic direction" people get today comes from
SCA vendors and the efforts often wind up focused on dealing with
artifacts and effects of "insecure coding" and "developers who write
insecure code". (I'm thinking of things like CLASP here). This focus
on code and developers has led quite a few companies to start blaming
their code and their developers. Which is often the *effect* of their
business model, and not the Root Cause of their issues.

So included in our programs we must enable people to include a context
of their business, and make their decisions around that context. If
insecure code and insecure coding is an artifact of their business
process, and that process is otherwise highly successful, I have a
hard time telling people that they need to change their development
process to fit some model of "secure coding" that someone says is
"best".

This creates a juxtaposition between providing Risk Management vs.
Root Cause Remediation. We see this juxtaposition across our entire
industry today.

The folks who make their bread and butter off of Root Cause
Remediation have kind of pushed that perspective above the importance
of Risk Measurement and Risk Management. Or, rather, they have defined
"defect detection" as the standard for "Risk Reduction" and "Risk
Management" in software security.

Put another way: In most cases it appears to me that we are pulling
out our rulers and measuring as many defects as we can with them, and
then using largely quantitative numbers of defects found as the basis
for calculating Risk and acting on it. Very little qualitative data
comes from this type of analysis.

If Risk = (Impact | Loss), which is what Risk always means to a
business, then we need to change our way of thinking and start holding
our rulers up to some other places to measure. We need to define
threats more clearly, and factor in goals of the attacker vs. intended
outcomes of the business. From this we can better establish a context
to view quantitative metrics, and also from this we can start
producing qualitative metrics that are actually valuable to the
business.

So an effective Web Application Security program has to enable people
to evaluate real Risk, and decide if Root Cause even matters, and if
so, where it matters (everywhere? some places?). It must also give
them guidance on how to measure the success of any
tools/techniques/approaches at measuring and reducing Risk. It needs
to produce ways of demonstrating to the business what they have really
accomplished in terms of real-world Risk and Threat reduction, and
whether the money invested justifies the accomplishments. There are
many ways to skin that cat and not every way works for every
organization.

That -- is what people are really asking for, and what they need.

This material should take the form of checklists and decision-trees,
more so than Top N Lists, as I'm sure most on this list will agree.

Sorry for the late reply, wanted to think through my wording.

---
Arian Evans

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA