George Capehart wrote:

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

Which brings up the next broken record. Management will not care until
it affects the bottom line not to care. As long as it costs money to
care (missed deadlines, more tools and training, etc.) and it doesn't
cost anything not to care, then they *shouldn't* care.  Either the
consumers have to care so that security problems cost sales, or
the liability laws need to change so that security problems result in
financial penalties. Consumers in  general are too diverse a group to
really change what they want. It would be very difficult to educate the
entire consumer base to the collateral costs of poor security in
products and to set valid expectations about what is and is not
possible. The "all software has bugs" mantra is now very ingrained.
Changing liability laws on the other hand is a simple solution. This
will force managers to do the proper due diligence just to CYA.
Sure, there will be increased litigation costs, but a couple high
profile cases and the whole process of development will change.

And I don't buy the "programming is too hard, there will always be bugs"
argument. Maybe there will always be bugs, but I don't think we have
reached the point where we can really make a call about how hard it
really is. We call programmers "engineers", but very, very few software
"engineers" deserve the title. Would you accept "it was too hard to
do a stress analysis" from the engineer designing a bridge?

It is bafflingly paradoxical that the United States is by far the
world's leading scientific nation while simultaneously housing the most
scientifically illiterate populace outside the Third World.
- Richard Dawkins
Brian Utterback - OP/N1 Revenue Product Engineering, Sun Microsystems
Ph/VM: 877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Reply via email to