Re: How do we improve s/w developer awareness?

[Gunnar Peterson <gunnar () arctecgroup net>]

Concur that security is more colorless than most of the other ilities. My point
is that the other domains which serve up the non-functional requirements are
colorless to some degree as well. So in terms of how the other ility domains
approach the quantification and elaboration of the goals that emerge from their
domains and getting them in the hands of architects and developers, there may
be some activities and artifacts in there that we can learn from.

-gp

Quoting Jeff Williams <[EMAIL PROTECTED]>:

> We certainly have a lot to learn from the other communities, but security is
> worse than the other *-ilities, because it is more difficult to see.
> Consumers can tell which operating system is easier to use, and which one is
> faster, but there is no way to know which is more secure today.
>
> Until consumers can tell the difference between a security program and one
> that is not, they will not pay more for the secure one.  Which means that it
> is not going to make many managers' radar screen, and therefore developer
> awareness will never happen on a broad scale.
>
> In my opinion, the way out of this trap is to get more information to
> consumers about the security in software.  Information like how many lines
> of code, what languages, what libraries, process used, security testing
> done, mechanisms included, and other information can and should be
> disclosed.
>
> --Jeff
>
> ----- Original Message -----
> From: "Gunnar Peterson" <[EMAIL PROTECTED]>
> To: "Yousef Syed" <[EMAIL PROTECTED]>
> Cc: "Secure Coding Mailing List" <[EMAIL PROTECTED]>
> Sent: Friday, November 12, 2004 6:58 AM
> Subject: Re: [SC-L] How do we improve s/w developer awareness?
>
>
> > > Making software secure should be a requirement of the development
> > > process. I've had the priviledge to have worked on some very good
> > > projects where the managers emphasised security in the beginning of
> > > the projects life cycle since it was a requirement of the client.
> >
> > Making software secure absolutely should be part of the development
> > lifecycle, and as early as possible, too. My overall point was that if
> > you talk to the people who really care about usability (as
> > distinguished from just "features") you will hear very similar
> > frustrations about their ability to get what they consider true
> > usability requirements into the end product. So in terms of learning
> > from other communities I think as opposed to beating our heads against
> > the same wall it can be helpful to learn from another *-ility community
> > to see what ways they have tried successfully/unsuccessfully to
> > increase the quality in software from their viewpoint. My suggestion is
> > that the problem is not just software security but run a little deeper
> > to the main problem of software quality of which security is one of the
> > factors (albeit an important one).
> >
> > So what are the common threads amongst usability and security? For
> > examples it is interesting to note that both communities seem to value
> > early involvement in the development lifecycle and striving for
> > simplicity in design. Software security does not need more barriers,
> > but to the extent that we can find allies with similar goals and issues
> > from other communities (could be *-ilitity, business, compliance, legal
> > btw) and collaborate with them to communicate the value of quality,
> > then our chances for shipping better software are increased.
> >
> > -gp
> >
> > "Societies have invested more than a trillion dollars in software and
> > have grotesquely enriched minimally competent software producers whose
> > marketing skills far exceed their programming skills. Despite this
> > enormous long-run investment in software, economists were unable to
> > detect overall gains in economic productivity from information
> > technology until perhaps the mid-1990s or later; the economist Robert
> > Solow once remarked that computers showed up everywhere except in
> > productivity statistics.
> >
> > Quality may sometimes be the happy by-product of competition. The lack
> > of competition for the PC operating system and key applications has
> > reduced the quality and the possibilities for the user interface. There
> > is no need on our interface for a visible OS, visible applications, or
> > for turning the OS and browsers and e-mail programs into marketing
> > experiences. None of this stuff appeared on the original graphical user
> > interface designed by Xerox PARC. That interface consisted almost
> > entirely of documents--which are, after all, what users care about.
> > Vigorous competition might well have led to distinctly better PC
> > interfaces--without computer administrative debris, without operating
> > system imperialism, without unwanted marketing experiences--compared to
> > what we have now on Windows and Mac.
> >
> >   Today nearly all PC software "competition" is merely between the old
> > release and the new release of the same damn product. It is hard to
> > imagine a more perversely sluggish incentive system for quality.
> > Indeed, under such a system, the optimal economic strategy for market
> > leaders may well be the production and distribution of buggy software,
> > for the real money is in the updates and later releases.
> >
> > One of Philip Greenspun's points in his introductory programming course
> > at MIT is that the one-semester course can enable students to create
> > the programming equivalent of the amazon, eBay, or photo.net websites.
> > So why it is so hard to get it right the first time? Or at least by the
> > Release 8.06th time? See Software Engineering for Internet Applications
> > (MIT 6.171) at http://philip.greenspun.com/teaching/one-term-web
> >
> > -- Edward Tufte, June 28, 2002 "
> > http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?
> > msg_id=0000D8&topic_id=1&topic=Ask%20E%2eT%2e