On Sat, 19 Jun 2004 21:41:35 PDT, "Mr. John" <johnspood@xxxxxxxxx> said: > Suppose that I am technical chair of a software group > and we have a software that security consideration > is important for us. How can I test our software to > ensure that no security vulnerabilities (like buffer > overflow vuln) exists in our software product. Or it > is question for me how for example eEye find many > vulnerabilities in software products. Is there a > regular and formal way? Is there some tools, technics, > method, ... for this purpose, for finding a > vulnerability in a software? Note that the techniques for *finding* holes are totally different from the techniques for writing software correctly in the first place. Your best bet for actually doing it right in the first place: 0) Understand that proper design is a better idea than being able to test a broken design... 1) get copies of Howard's "Writing Secure Code (2nd ed)": http://www.amazon.com/exec/obidos/tg/detail/-/0735617228/qid=1087847205/sr=1-1/ref=sr_1_1/104-5132183-7002350?v=glance&s=books or other good book on the subject (I happen to like Howard's book, but others on the list will certainly have other suggestions), and make sure *all* your code people read it *and Get It*. If your programmers Just Don't Get It, you're screwed no matter how much testing you do. 2) Make sure security is considered in all your design reviews.. Screw-ups like failing to "canonify a string exactly once and then verify what the string means" are at the root of essentially all the myriad different unicode/ directory traversal bugs. And usually, getting this sort of thing right during the design is a lot easier than trying to fix it once you have several hundred thousand lines of code doing it The Wrong Way. 3) Do proper testing, verification, and source code management (which you probably should be doing already, anyhow, right? ;) Hope that helps...
Attachment:
pgp00051.pgp
Description: PGP signature