quick question - SXSW

[arian.evans at anachronic.com (Arian J. Evans)]

<my responses inline>

On Wed, Mar 12, 2008 at 6:08 PM, Benjamin Tomhave
<list-spam at secureconsulting.net> wrote:
> I think you misunderstood my points a little bit. SXSW was just a
>  current conference example. As Gary's pointed out, there are many
>  conferences. It's possible SXSW wasn't a good example, but it was meant
>  more symbolically. More comments inline...

Oh, I did miss your point. Overall, I agree. I've had mixed experiences
leading me to re-evaluate my stance.

A security-unaware dev friend recently told me about Microsoft coming
to some conference and demonstrating this new "SQL Injection" thing
to them, and he told me how amazing and cool it was. He asked if I
did SQL Injection.

That's the first time in several years he's responded to what I've primarily
worked on for 8+ years, and incidentally for over 10, and told him about
over god-knows how many Guinness. I don't blame the Guinness. (who can?)


>  > They just don't care.
>  >
>  > They will never care.
>  >
>  I fundamentally disagree. Everybody is the right crowd, assuming the
>  message is tailored appropriately. It's precisely the perspective you
>  espouse that concerns me greatly. I don't believe the security industry
>  _as_a_whole_ has maintained momentum, and I attribute that directly to
>  the SEP* effect. This goes directly to my larger point about ingraining
>  security considerations/thoughtfulness/practices into all aspects of the
>  business (not just coding, btw).

I think this approach is doomed to failure, though my thoughts and experiences
are mixed. Whilst I have quit evangelizing secure software, I do meet more
and more devs interested in software security -- whom were not merely 3 to
5 years ago. Something is definitely changing, but abstract interest in appsec
!= secure design & implementation.

While this isn't an argument -- just an observation -- I hear this
"build security in"
notion preached most often from the following:

(a) people new to the appsec "industry"
(b) academic-minded & PHD-type folks into taxonomies
(c) government folks/agencies out of touch with the business world
(d) eager kids just-out-of infosec college joining our "industry"
(e) people with livelyhood/agendas staked on these notions

Maybe I'm just jaded, but it doesn't seem to work in many, and
possibly most, cases. I think the the momentum is lost because
all these "build security in" and "Secure SDLC" things don't work
for a lot of people/organizations. I still have some suspicions
this may be due to implementation, but...

This industry cannot even get it's node-hierarchies right. Even
the mitre CWE is fraught with node-confusion betwixt attack
nodes, vulnerability nodes, and design & implementation weakness nodes.

But at the end of the day the business doesn't care.

"Will this model of car sell and will we get sued over defects in it?"

That's the world. If "building secure cars" was the answer Volvo
would have been a wild success many, many years ago.


>  If everyone starts coding more responsibly, then at some point the genre
>  of "secure coding" goes away, because it's inherent in everything that's
>  written. Today, I'd settle for all externally-facing apps being coded to
>  address the OWASP Top 10, and to get developers to think for a change
>  before doing silly things like implementing client-side filtering in the
>  client code.

Client-side filtering isn't silly. It's smart. You probably mean using it
as a security control, but it's that verbiage that arms legions of the
clueless appsec auditors now joining our industry that don't know
sh*t about software design or implementation, or business use-case,
and cause software professionals to scoff at our industry. I can't tell
you how many appsec reports I've seen that say "don't use client
side validation -- it's dangerous" and I start looking for more best
practice nonsense listed as "vulnerabilities".

"Don't allow dangerous characters in input". WTF?
"Insufficient input validation". For whom?

I think I see your perspective though.

I think the answer is: IDEs that make it harder to shoot oneself in the
foot, secure frameworks, and secure environments (for all us text-editor
types) and maybe even newer languages with some real notion of a
data/function boundary -- those are the keys. Leave "secure coding"
out of it.

Combine that with security controls that provide meaningful mis-use
case and fraud detection, instead of attack-vector blocking, and you
and can even allow weak password reset questions. Which is what
the business, and my mother, really wants.

I hesitate to say this, this is like fumbling with flame-bait, but over
the last two years I feel more and more like many in this industry,
including OWASP which you mentioned, are going astray down
this fantasy land of secure-coding and assurance.

The government (and contracting agencies by proxy) are into
assurance. The rest of the world is not.

The private sector is into mitigation, insurance, fraud detection
and incident response.

OWASP notions and directions feel to me like it's driven more
and more by people out of touch with the major producers of
software in the private sector, and the way the world creates
and innovates software products

Two things have driven this: I once was really into taxonomies
and classification and clearing up the muddled mess of appsec
and the utter lack of math and useless "science" that we have
in this "industry".

Second was a mix of learning more about the internals of Microsoft
and their appsec struggles and moving out here to Silicon Valley
and getting in the middle of software central.

Both those things have served to push me completed over
into the pragmatic camp and I look at appsec much differently now.

>  Hard-earned gains. How do we institutionalize these practices and get
>  beyond playing the role of Law Enforcement for the security department?

I don't know. I don't find many real-world analogues, quite frankly.
I had a sports car with a governor at 125mph once, but it was
easily removable. My sport bikes will do 180mph.

That's why we have LEO's. I'm not supposed to ride 180 mph on
public roads.

I think most devs I know look at "the art of writing secure code"
like I look at a sportbike governed at 85mph: "Get out of my way".


>  > Overall security is not a feature or a function that you can monetarize.
>  > It's not even cool or sexy. It's an emergent behavior that is only
>  > observed when it is making your software harder to use.
>  >
>  On the first sentence, I say "yes, exactly!" On the second sentence, I
>  couldn't disagree more. Security should not be "making your software
>  harder to use." Address XSS, CSRF, SQL injection, and input/output
>  filtering/encoding should not diminish the end-user experience. Things
>  like 2-factor authentication might have that result, but we're not
>  really talking about that right now.

I didn't say security *SHOULD* be about making your software harder
to use. I said that it does, in many, many, many cases.

Let's take your examples:

XSS: Facebook & Myspace don't agree with you.

CSRF: Everyone who has to re-authenticate. There is no other way
to protect against CSRF on weakly designed auth/session controls.
And re-auth sucks. Ask your mother.

SQL Injection.  This depends on the solution. I've seen nice, Irish,
Sarah O'Grady turned into the polish Sarah OGrady or the fractal (?)
Sarah O\Grady. Parameterized SQL certainly solves this neatly,
but the data-function boundary concept is missing from most modern
implementation-level languages. So you can't solve XSS that way.


>  > Not until insurance or substantial penalties are the norm (if they are
>  > ever the norm) will we have meaningful quantitative data to drive a
>  > justification for security as a requirement in startup or most open
>  > source software projects. That's my opinion, anyway.
>  >
>  I would really like for you to be wrong, but I can't really disagree
>  with your base conclusion here. Hence my frustration. It provides a good
>  case for shelving all security departments until the business starts
>  taking major hits and they come begging for help. Honestly, I don't
>  understand it. Businesses don't disagree that they need properly secured
>  code/sites/etc. Yet, by the same token, they don't do what's necessary
>  up front to secure their code/sites/etc. It's a truly bizarre disconnect
>  that boggles my mind.

It's not a disconnect my man. It's reality.

Businesses don't ship code to show off Secure Software.

They ship code to make money.

Software security is an emergent behavior that changes over time
with software use, evolution, extension, and the changing threat
landscape. It's not an art you get people inspired in.

Take the threat landscape: Phishers are just starting to use XSS in ernest now.

No one knows what in the world is really out there that we are facing,
except maybe IBM's Global Managed network services (who is starting
to monitor and measure this stuff now). They probably have the
biggest sample of real-world traffic.

I know folks at a number of large software companies/websites out
there on the 'net that face regular attacks and have a decent idea
what real attacks are and what dealing with them costs, but they
are all private sector and none of them are going to release anything
in the way of data about it.

Releasing facts might raise their cost of business.

>  Thanks for the response! :)

You too. Yours was well reasoned; I still disagree on points though.

A third thing I'll add -- my employer for the last 1.5 years has enabled
me to see about 500-600 production websites, and their vulnerability
posture from a black-box perspective, but also how people fix things,
what they fix, why, what they assume the risk on, etc., and have my
customers tell me what is attacked and how.

Having that much real-world data has also changed my perspective
from a once-purist "design & write more reliable code" and "look at
your code, fix your code" to more of a "this is how the world is; let's
make better band-aids cause we're always going to need them" view.

I've been meaning to write an essay on Idealogies and Idealogy Wars
in appsec. There's at least three major idealogue camps, and wars
between them starting to brew, but most folks new to this field have
no idea what the agendas and perspectives are, why they exist, and
what drives the different ideals.

Thanks for the stimulating though, ciao

-- 
Arian Evans
software security stuff