Well, your subject opens up an opportunity to plug a couple of pretty decent
books on the subject.

Michael Howard and David LeBlanc wrote a book entitled "Writing Secure Code"
that is published by Microsoft Press. (ISBN:0-7356-1588-8). It does a decent
job of covering a lot of the basic foundation for secure code development,
and covers a gambit of areas, including Windows programming. I think its
well rounded to cover writing secure code in general as well as focusing in
on some areas such as .NET, ActiveX and DCOM, RPC and even web-based
services.

Depending on exactly what you are trying to accomplish, I would also
recommend some reading in security engineering. Your last question about
"completely secure and not exploitable" makes me believe that it might be a
good idea for you to understand more of the focus on how security plays into
the quality and reliability of software development. Absolute security is a
myth, and it is a panacea that can never be reached, because with enough
time and money there are ways around virtually anything. What good is the
best network security software if the attacker can walk in and sit down at
the console, or even take the harddrive?

A great book on this subject is from a pretty kewl guy over at the
University of Cambridge named Ross Anderson. He wrote "Security Engineering:
A guide to Building Dependable Distributed Systems", and is published by
Wiley (ISBN:0-471-38922-6). I'm in favour of any book that is willing to
lighten the mood by explaining security engineering as it relates to
"Nuclear Command and Control" and how biometric systems break down.
*snicker*

On a serious note, the ideal to write completely secure code should be the
goal of everyone. However, this is a game we can't always win, so the best
we can do is take what we know and have learned and mitigate the risks as
best we can. Some people may disagree with me on this list, but in my view
it is better to write code that does the best to fail safely in the most
hostile environments in unknown circumstances and hope to mitigate all of
the unknown risks while preventing all the known risks from ever entering
the master sources. (ie: Over/Under-flows, dangerous API calls etc that have
been the same stupid issues for over 20 years) and find ways to auto-recover
than to work towards the unobtainable goal of "completely secure code". Many
APIs that you may use may have vulnerabilities you cannot control, or the
operating system your application is on may be vulnerable to future attacks
we don't know about. You can very much mitigate many of these issues with
the knowledge you can gain from these books. As an example, Michael goes
into pretty good detail on the use of least priviledge and the mitigation of
"escalation or priviledge attacks". You might not be able to prevent an
overflow of someone elses module, but you can damn well contain it. And its
this kind of thinking that goes a long way to make more robust and quality
driven code with security in mind.

Hope thats helpful for you and a good start. I recommend those two books as
required reading on the subject. Heck, I buy those two books for everyone
that comes and works with me on any of my teams and it has been found to be
well worth the investment.

---
Regards,
Dana M. Epp

----- Original Message -----
From: "Rahul Chander Kashyap" <rahul (at) nsecure (dot) net [email concealed]>
To: <secprog (at) securityfocus (dot) com [email concealed]>
Sent: Friday, December 27, 2002 4:46 AM
Subject: Writing Secure code

> Hi people,
>
> I've been going through some articles on how to write secure code esp.
> from: http://www.shmoo.com/securecode/
>
> I am looking for something more specific for the windows platform. Are
> there any specific guidelines/standards that one could follow?
>
> And one more thing...<this one might be intresting ;-)> Is it possible
> to write code that is completely secure and not exploitable?
>
> Thanks for parsing thru my mail :-)
>
> Regards,
>
> Rahul Kashyap
>
> www.nsecure.net
> ------------------------
> Layered Defence
> ------------------------
>
>

[ reply ]