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

[Michael Silk <michaelslists () gmail com>]

Dave,

On Apr 11, 2005 9:58 PM, Dave Paris <[EMAIL PROTECTED]> wrote:
> The programmer is neither the application architect nor the system
> engineer.

In some cases he is. Either way, it doesn't matter. I'm not asking the
programmer to re-design the application, I'm asking them to just
program the design 'correctly' rather than 'with bugs' (or - security
problems). Sometimes they leave 'bugs' because they don't know any
better, so sure, train them. [oops, I'm moving off the point again].
All I mean is that they don't need to be the architect or engineer to
have their decisions impact the security of the work.


> If
> security is designed into the system and the programmer fails to code to
> the specification, then the programmer is at fault.

Security can be design into the system in many ways: maybe the manager
was vauge in describing it, etc, etc. I would question you if you
suggested to me that you always assume to _NOT_ include 'security' and
only _DO_ include security if someone asks. For me, it's the other way
round - when receiving a design or whatever.


> While there are cases that the programmer is indeed at fault (as can
> builders be), it is _far_ more often the case that the security flaw (or
> lack of security) was designed into the system by the architect and/or
> engineer.

So your opinion is that most security flaws are from bad design?
That's not my experience at all...

What are you classifying under that?


> It's also much more likely that the "foreman" (aka
> programming manager) told the builder (programmer) to take shortcuts to
> meet time and budget -

Maybe, but the programmer should not allow 'security' to be one of
these short-cuts. It's just as crucial to the finsihed application as
implementing that method to calculate the Net Proceedes or something.
The manager wouldn't allow you to not do that; what allow them to
remove so-called 'Security' (in reality - just common sense of
validating inputs, etc.).

-- Michael