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
This archive was generated by hypermail 2b30 : Wed Jan 22 2003 - 13:20:08 PST