RE: Standards for developing secure software

From: Witness (bmeyer67@calvin.edu)
Date: 01/21/03

  • Next message: Glynn Clements: "RE: PGP scripting..." 
    From: "Witness" <bmeyer67@calvin.edu>
To: <secprog@securityfocus.com>
Date: Tue, 21 Jan 2003 01:41:55 -0500

    Disclaimer: I'm not an expert in security but I am a programmer and I do
    want to learn more about writing more secure software - that's why I'm
    on this list. So please take what I say with a grain of salt. That
    said, I've enjoyed this discussion and many others on the list.

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

    It may not be the main reason, but it could be a very big one. I'm a
    slow reader and as such I don't have much time to actually read most
    books. Instead, I keep books around and use them mainly for a reference.
    If I'm looking something up, it's on how it would be useful to me at
    that moment. E.g I wouldn't be looking up "How to prevent a buffer
    overflow" but rather "strcpy()" or "strncpy()". Thus, if the book is
    more oriented towards what I am doing and give ideas under that topic on
    how to prevent other issues (like a buffer overflow) then I would be
    more likely to come across the topic. That said, I would probably also
    see the security topic (e.g buffer overflows) and if thought it to be
    important enough have read it anyway.

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

    I'm just graduating college this year, but I've been programming for
    about 6 or 7 years. I'm still more oriented towards CPU and memory, and
    I believe that programmers should always be worried about CPU and
    memory. Over the last few years programs have become larger and larger,
    partially because programmers have stopped worrying so much about CPU
    and/or adding additional functionality, but more likely some combination
    thereof. Writing better programs (IMO) means writing the program that
    is less CPU/memory intensive _and_ at the same time being more secure.
    Why should we have to give up one for the other? I believe we can do
    them both.

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

    This is probably because of how it is presented to most programmers.
    There are things that seem daunting, and trying to go over every single
    line of code to make sure that a program is up to some security spec
    isn't very difficult for small programs, but most programs aren't
    small - most are hundreds of thousands of lines of code and that is
    difficult.

    > (2) "It wonīt happen to my application anyway"
    > (3) This is a job for the network and technet-guys to do.

    Unfortunate, no? I do agree here, people need to change their perception
    of where the problems lie. A sys-admin should not need to be
    implementing the security that program X needs because the programmer
    didn't do it the right way. Unfortunately, that is what is has become.

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

    IMO, the best thing to do is to educate programmers on certain
    principles - like how to avoid a buffer overflow - and also educate the
    people in the other parts of the structure. Security does not exit the
    programming process by a failure at any one point, but rather by a
    failure at all of them. If the programmer knows how to put the security
    into the program, then they ought to do so; if the designer fails to put
    it in, the programmer ought to compensate as needed by the code catching
    the failure of the designer. And likewise for the entire process. Each
    level should catch what the other levels fail to find. (While not
    specifically to security, is this not one of the reasons why the process
    is there to start with?)

    Regards,

    Benjamen R. Meyer

    http://theosproject.sourceforge.net
    Revolutionizing Operating Systems

    Relevant Pages

    • Re: OT Dual core CPUs versus faster single core CPUs?
      ... Then one core could be assigned to each application process ... The OS cpu will assign it a task, create its memory image, set up its ... "Most people fail to consider that good programmers are very ...
      (sci.electronics.design)
    • 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: Thou shalt have no other gods before the ANSI C standard
      ... >> are sold a year, then guess how many embedded systems are sold a year. ... > When's the last time someone tried to exploit a security hole in the ... Too many programmers are hearing about buffer ...
      (sci.crypt)
    • Re: [Full-Disclosure] DCOM RPC exploit (dcom.c)
      ... Information Security Engineer ... > IMHO it is TIME to sue corporations like microsoft for their stupidity ... they're sending all their programmers ... interpreted languages, meaning .net. ...
      (Full-Disclosure)