Re: How do we improve s/w developer awareness?

[George Capehart <gwc () acm org>]

On Tuesday 30 November 2004 11:58, Evans, Arian allegedly wrote:
> I've almost completely ignored this thread because like
> George I believe it's the same old broken record I first
> heard Marcus Ranum spin up a decade ago. When it comes to
> this subject I feel like we [security professionals] are
> a bunch of myopic carriage horses sprinting through the
> forest wondering where all the trees are coming from.

Nice analogy.  :)

> Among other things, I teach classes on webappsec; how to
> design and build secure apps, how to crack them, and so
> on. It's fun and exciting to see the lightbulb go on with
> your classic VB ASP newbie.
>
> It's also a waste of time for several reasons.
>
> One: I'm talking to the wrong people:
>
> I have a 3-hour 'morning' class for development managers,
> business line owners, and c-levels. It is about real life
> *incidents*\ and incident response, business process and
> risk management, and how to shim security into a development
> process so it fits hand in glove with business requirements.
> No BUFD and BPPST (big post-production 'security test').
>
> People rarely attend that class. Maybe I'm just a bad presenter.

No, they just don't care.

> Two: the world's web apps are always going to be coded by
> entry-level VB ASP people. Security is a complex and ephemeral
> subject. We don't expect developers of this skill set to
> be responsible for optimizing compiled code, so who in their
> right mind thinks they are going to become security experts?

They don't need to be security experts.  They just need to be able to
follow design specs and coding policies and processes.  This just goes
back to the absence of governance and risk management.  The design
specs should specify a "secure design."  Coding policies should specify
"secure coding practices" and the build processes should enforce the
policy.

> I do know I've made developers very aware of security,
> and even have a few that keep in touch and use me for
> a 'recommended reading' list.
>
> But it is 8pm Friday night and this app was supposed to go
> live by 5pm and we just got it rolled to prod, QA thumbs-up
> and business signoff, and I've got a wife with a cold dinner
> and a kid waiting for me to come home.

That's not a coding problem.  It's a project management problem.

> And a manager that's not worried about security because
> the business is not worried about security issues and they
> pay those folks in the security department to run their
> scanners anyway. CISSPs. Security is their job.

Again, an absence of governance and risk management . . .

> Now, Yogi Berra.
>
> Nothing changes until something changes.
>
> We need a change in framework and development tools. This
> can solve for technical issues (e.g.--buffer overflows)
> that are the legacy and gift of C and her children.

To a large extent, yes . . . iff, management is worried about security
issues and insists that frameworks and tools that promote
application-level security are used.  But, as you noted above, that is
not the case . . .

> Logical issues, design issues, will always exist and we
> exist to help find them and help educate the business to
> find case to correct them, if such case exists.

Yes, assuming management cares . . . and that's *my* broken record . . .
:)

If the tone of my comments was a bit harsh, it is most emphatically not
intended to be directed at your thoughts.  It is only because of my
intense frustration with the situation.  When "Management" wants
software systems to be secure, they will be.  Not perfectly so, but
within published limits.  "Management" will see to it that the
appropriate policies and processes are in place to assure it.
"Management" will see to it that delivering a product that passes the
certification process is more important than delivering a product by a
certain date.  "Management" will require that a security architecture
be in place before the design process starts, etc., etc., etc.  The
board will hold "Management" accountable for the risk that the use of
the system entails.  When that happens, "Management" will come to
realize that security is *their* problem, *not* InfoSec's problem.
/Until/ that happens, changing frameworks, development tools,
methodologies or whatever will not solve the problem.  "The Problem"
just isn't in IT.

As Dennis Miller says:  "But that's just my opinion.  I could be wrong."

/g