Re: Application Insecurity --- Who is at Fault?

[Michael Silk <michaelslists () gmail com>]

Dave,

> What you're proposing is that the ironworker should reengineer the
> bridge in-situ (as if he even has the authority!), causing weeks of
> delay, cost overruns, and possibly lead to his employer never getting a
> bridge contract again.

That's not at all what I'm suggesting... guess my point wasn't so obvious :)

I'm not saying the programmer should totally redesign the application
if it's not secure.

I am saying that they _SHOULD_ do the simple, 'trivial' things within
the context of their current job. Validating input, handling errors
properly, ensuring ownership of various id's, etc. All of these things
fall in this category.

Yet these days, when programmers actually _DO_ do these things, they
call these things 'security features' and themselves 'secure
programmers' (or whatever). And that's what I think is ridiculous.

Other things, like designing a secure protocol/management of your
encryption system can be though of as 'something extra' but these
types of problems aren't the _MAJOR_ problems (they are big problems,
however) that we deal with.

There are, of course, design concepts that shouldn't really be billed
as 'extra' either [like appropriate user management/access systems,
etc].

And back to the main point of this discussion, is that lack of these
things in application shouldn't be blamed on consumers (or even
management) for not asking. These things should be assumed...

-- Michael

> Somehow, that just doesn't hold water.
> Kind Regards,
> -dsp