OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Ogle Ron (Rennes) (ron.ogle_at_thomson.net)
Date: Tue Nov 26 2002 - 11:46:58 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    There are programmers out there who are professionals and will use best
    practices and produce great code. Then there are the average programmers,
    who out of ignorance and/or laziness will continue to provide the bare
    necessity to keep the pointy-haired manager off their back. For a product
    to fail, it only takes one average programmer to screw-up a product. BTW,
    how does a pointy-haired manager tell who's average and who's professional
    when they are hiring? Certifications, yah right.

    George has got it right for reality. So how do the caring professionals fix
    the real problems to making better code? A couple of suggestions (the first
    2 can be accomplished on an individual level):

    1. Through personal development. Each person should strive to continue
    learning better ways of doing your job.
    2. Through mentoring less-experienced. Most of you on the list know what
    should be done, try to instill the same concepts in your teams.
    3. Support legislative efforts to make companies responsible for the code
    that they produce. Legal liabilities can be just as strong or stronger in
    incentivizing a company to do the right thing.
    4. Try to get your company interested in the Software Engineering
    Institute's Capability Maturity Model (SEI CMM). The target would be to
    produce the right product on time and in budget.
    5. Support ethical hacking. We've seen many companies at least start to
    acknowledge that they have a problem through the efforts of external hacking
    and vulnerability testing. This is the part where consumers start to get
    educated because of the bad press.
    6. Join ACM and IEEE and try to push for more professional standards in
    software development.

    My .02 Euro (Now worth more than .02 US cents)
    Ron Ogle
    Rennes, France

    > -----Original Message-----
    > From: George Capehart [mailto:gwccapehassoc.com]
    > Sent: Saturday, November 23, 2002 01:17 AM
    > To: David Wheeler
    > Cc: secprogsecurityfocus.com
    > Subject: Re: secprog Digest 18 Nov 2002 18:35:57 -0000 Issue 113
    >
    >
    > David Wheeler wrote:
    > >
    > > > Before the rest of my response, I'd like to make clear
    > that I believe
    > > > that poor programmer education is one of the primary
    > reasons we have
    > > > so many vulnerabilities.
    > >
    > > I believe the _MOST_ important step to take today is to get
    > > EVERY software developer trained in how to write secure
    > applications.
    > > It is _CRIMINAL_ that we still permit computer science and
    > > software engineering graduates to graduate without knowing
    > > the fundamentals on writing secure programs!
    >
    > <snip>
    >
    > I've bitten my tongue through the "bad developer library"
    > thread on this
    > list, but I can't stand it any longer. <rant> Seems to me there are
    > several problems that contribute to the proliferation of insecure
    > software. Certainly programmer ignorance is one. I agree
    > 100%. Having
    > said that, I really believe that if one of the criteria for hiring
    > programmers was their ability to write secure code, the training
    > institutions would graduate programmers who could write
    > secure code. I
    > have been in the industry a long time and have worked in and
    > around many
    > different organizations . . . from the very small to the very
    > large. I
    > have worked with/in software development firms, manufacturing
    > companies,
    > financial services organizations, county governments and everything in
    > between. *Never once*, in the 21 years that I have been in the
    > industry, have I heard a product manager, project manager or
    > development
    > manager place better over faster and/or cheaper. This translates out
    > to: "To hell with doing it The Right Way (TM), get it done
    > yesterday!
    > Just get it working . . . we can fix it when somebody complains."
    >
    .....
    > Based on the preceding two paragraphs, it would be easy to "blame" the
    > the "pointy haired managers" for not caring about the lack of security
    > that their insistence on haste engenders. In the end,
    > though, I believe
    > it is the customer who ultimately defines the level of
    > security that is
    > built into systems. Customers get what they are willing to pay for.
    > Educated customers who require top quality, secure products get them.
    > Windows customers get what they deserve. Personally, I want
    > to deliver
    > the best possible product I can. There are many companies
    > that do so.
    > There *are* six-sigma companies. These companies operate in spaces in
    > which their customers are educated and have a point of
    > reference. What
    > point of reference does the average Windows user have? Windows. What
    > point of reference does the average pointy-haired manager have?
    > Whomever yelled loudest at him. The rest of the argument is
    > left as an
    > exercise for the reader.
    >
    > So, is there any mystery that there is no emphasis on secure
    > programming
    > in the educational process? Who cares? The employers? Who is
    > sophisticated enough to demand and recognize secure software when it
    > bites them? Not the pointy-haired manager. Not the average Windows
    > user . . .
    >
    > So, when will we see secure software? A) in the isolated
    > shop that that
    > takes a craftsman's pride in delivering a top quality
    > product, and/or B)
    > when consumers demand it. For now, I'm looking for A.
    > </rant>
    >
    > gwc
    > --
    > George W. Capehart
    >
    > Capehart Associates LLC Phone: +1
    > 704.678.1660
    > 1604 Nottingham Drive Fax: +1 704.853.2624
    > Gastonia, NC 28054
    >
    > "We did a risk management review. We concluded that there was no risk
    > of any management." -- Dilbert
    >