Re: Standards for developing secure software

From: Stefan Schildt (stefan.schildt@piceng.se)
Date: 01/08/03

  • Next message: Frank Knobbe: "Re: PGP scripting..." 
    Date: Wed, 08 Jan 2003 08:55:47 +0100
From: Stefan Schildt <stefan.schildt@piceng.se>
To: secprog@securityfocus.com

    "Steven M. Christey" wrote:

    > David Wheeler said:
    >
    > >The problem is that developers don't grok _ANY_ of the books.
    >
    > I wonder if some of this has to do with how the books are laid out.

    I doubt thatīs the main reason.

    I deal with leading programmers, and it seems to me that they are very
    well trained to always think about performance in terms of memory and
    CPU
    usage. They rarely never are trained to think about security from line
    one.

    When pressing them to do so, this is considered to be a burden. Almost
    like when the teacher forced you to make your first flowchart instead of
    just launching the it all in the code editor.

    When asking why I seem to get three answers:

    (1) Many programmers see security as something extremly difficult. This
    leads them to give up before they even started.

    (2) "It wonīt happen to my application anyway"

    (3) This is a job for the network and technet-guys to do.

    The common ground is that this is not part of what they think is an
    important part of an application. It doesnīt seem to be part of their
    professional pride in the same way as saving memory and CPU power is.
    This
    in turn seems logical if you look at the world ten years back: no
    networks, expensive memory and slow CPU:s.

    So what we need is a wake up call, with lots of missionary work. The
    main
    thing I would say is that all the people devoted to this list should
    also
    be active in other forums for programmers. The programmers want come
    here
    fast enought, so we should come to them.

    /Stefan

    Relevant Pages

    • Re: Forcing data into RAM memory only?
      ... Programmers often ask for help with a solution to a problem instead of ... security issue that will get a better answer in the security newsgroup. ... locking memory is a bad one, but I am not a security specialist. ... to disk unless the program wants to write it. ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Lisp and low-level operating system development
      ... > more writing to memory that isn't allocated by accident. ... >> modern software design: that of security. ... By demanding that programmers should deal with _both_ ... It isn't an software virtual machine in the way you're envisioning. ...
      (comp.lang.lisp)
    • Re: Garbage collection
      ... Some of them have been mentioned in other responses; ... I'll add that encouraging programmers to lose track of when their ... dynamic objects are valid does not "increase security". ... each memory piece, less mistakes are done in big software projects, ...
      (comp.std.c)
    • RE: Standards for developing secure software
      ... I'm not an expert in security but I am a programmer and I do ... > I deal with leading programmers, and it seems to me that they are very ... > CPU ... I'm still more oriented towards CPU and memory, ...
      (SecProg)
    • Re: Determine calling function
      ... to encourage programmers to escape from following dogma mindlessly. ... ad absurdem of an insistence on checking malloc(), ... I don't know how much memory starting at ... Obviously a *hard* setrlimit() cannot be employed for throttling ...
      (comp.lang.c)