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? -- blu
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