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

[Michael Silk <michaelslists () gmail com>]

On 4/12/05, der Mouse <[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'
>
> Except that sometimes the bugs are in the design rather than the code.

Sure, but that isn't the majority. At least in my experience.


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

Again, in my experience that is not true. Programs that are labelled
'Secure' vs something that isn't. In this case, there is a single
thing - Security - that has been included in one and not the other [in
theory]. Also, anyone requesting software from a development company
may say: "Oh, is it 'Secure'?" Again, the implication is that it is a
single thing 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).

Obviously a bit of discussion takes place, not just a flat-out 'No'.

-- Michael