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

[der Mouse <mouse () Rodents Montreal QC CA>]

> > 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'

Except that sometimes the bugs are in the design rather than the code.
Module A has a spec saying that checking a certain aspect of the input
arguments is the caller's responsibility; module B, calling module A,
is written to a spec that makes it A's responsibility to check those
values.

Neither programmer is at fault; each module was written correctly to
spec.  The real problem is that the specs are incompatible - whatever
part of the design and specification process allowed the two specs for
module A to get out of sync with one another is at fault.  (This
shouldn't happen, no, but anyone who thinks that it doesn't is
dreaming.)  Sometimes even the specs are identical, but are written
badly, leaving enough unsaid for such mismatches to occur - the art and
science of writing complete interface specs, that's another subject I
could rant at some length about....

> 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.

"Security" is not a single thing that is included or omitted.

Another common source of security problems is that a module (call it A)
is implemented in a way that is secure against the threat model then in
effect (often this threat model is unspecified, and maybe even A's
coder was careful and went and asked and was told "no, we don't care
about that").  This module is then picked up and re-used (hey, re-use
is good, right?) in an environment where the threat model is
drastically different -> instant problem.  Security was included, yet
security failed, and the fault does not lie with the original coder.
(It lies with whoever reused the module in an environment it was not
designed for.)

> > 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.

"The programmer" quite likely doesn't have that choice.  Refusing to do
what your manager tells you is often grounds for summary firing, with
the work being reassigned to someone who will follow orders (and
probably will be even more overloaded).

It's also not always clear whether a given thing constitutes a security
risk or not.  A certain validation check that's omitted could lead to
nothing worse than, say, a one-cycle delay in recognizing a given
signal in the initial design, but reused in another way that nobody
knew even existed at first writing, it could cause a crash (and
associated DoS) or worse.

/~\ The ASCII                                der Mouse
\ / Ribbon Campaign
 X  Against HTML               [EMAIL PROTECTED]
/ \ Email!             7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B