Subject: RE: Secure software development documents - msg#00114

Previous Message by Date: click to view message preview

RE: Code Complexity vs. Security

Hi Skip, Of course, insecure design is a major issue too, but "metrics" don't measure that - I was commenting on the user of LOC or Cyclometric Complexity to measure your security effectiveness ("complexity") and how it seems not very wise to esimate complexity based on the larger sized code. And especially for buffer overflows, most of these could be avoided if the programmer decided to actually *check* the value he was passing to the allocate function (i.e. more code, hence metric-finder would call it less secure ;)). -- Michael -----Original Message----- From: Skip Carter [mailto:skip@xxxxxxxxxxx] Sent: Tuesday, 27 July 2004 7:48 AM To: webappsec@xxxxxxxxxxxxxxxxx Subject: Re: Code Complexity vs. Security > I would suggest that almost all programming errors (and > hence security problems) come from some programmer attempting > to be "smart" and reduce the size of his/her code. Hmmm. While I agree that ill considered programming cleverness is one source of problems. But there seems to be an entire class of security issues that have nothing to do with bugs but with an insecure design. Consider an absolutely bug-free program that controls access to a database via a text file using ROT-13 encryption. Skip -- Dr. Everett (Skip) Carter Phone: 831-641-0645 FAX: 831-641-0647 Taygeta Scientific Inc. INTERNET: skip@xxxxxxxxxxx 1340 Munras Ave., Suite 314 WWW: http://www.taygeta.com Monterey, CA. 93940 This email message and accompanying data may contain information that is confidential and/or subject to legal privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying of this message or data is prohibited. If you have received this email message in error, please notify us immediately and erase all copies of this message and attachments. This email is for your convenience only, you should not rely on any information contained herein for contractual or legal purposes. You should only rely on information and/or instructions in writing and on company letterhead signed by authorised persons.

Next Message by Date: click to view message preview

RE: Secure software development documents

Hi All Building Secure Software How to avoid security problem the Right way By John Viega, Gary McGraw This is a good book about this subject. And I think all read e-mails about secure software development pattern in the last few days, we can use that pattern as best practices for secure software development. Also I am very interesting about this subject. Because crackers (not hackers) more like to find software errors (Actually lot of crackers use software bugs to malicious attack. They do not like to analyze & brick more complex algorithms. What they do is simply explode this systems using software bugs such as buffer overflows, heap overflows) U all have time we can discuss more about secure software life cycle kind for process to for secure software development I also like to contribute for that. This is very brief and incomplete e-mail, sorry about that, I will post more about this subject in my bust. Regards, G J Asanka Priyanjith -----Original Message----- From: Mark Curphey [mailto:mark@xxxxxxxxxxx] Sent: Tuesday, July 27, 2004 6:18 AM To: webappsec@xxxxxxxxxxxxxxxxx Subject: RE: Secure software development documents With regards to testing specifically this is a draft of OWASP Testing Part 1. It is essentially a high level view of what to think about when building a testing function. It is draft but as we have been threatening to release it for ions I thought I would at least put this version on Sourceforge to download and get a flavor of what we (OWASP) are saying. It is not finished (we have a face to face this Weds to finally conclude this part and the re-write) so please just read the Chapters 7 and 8 in this context. Chapters 4, 5 and 6 are getting a re-write (significant prune) this week but this may help. It won't please everyone, especially the silver bullet brigade, but it is a good attempt and consensus that most people who have been responsible for building and running security testing of web app software in large dev shops have agreed on. You have to think strategically and testing after development is too little too late (despite some marketing claims to the contrary). http://prdownloads.sourceforge.net/owasp/TheOWASPTestingProjectPart1Draf t.pd f?download This is an interesting point in the software security industry I think. I have seen two distinct camps forming, those trying to solve the problem by promoting building better software and tackle the root causes (people, process and technology) and those selling shinier and shinier silver bullets (software or services) ;-( Basically we are saying you need to test your SDLC process itself and then discrete parts of it such as requirements, design, implementation and deployment. Today people seem to have a fixation on testing deployment only which is too little too late and too in-efficient. Note: As I was typing this I saw a mail from Skip Carter that re-enforces this. -----Original Message----- From: Scovetta, Michael V [mailto:Michael.Scovetta@xxxxxx] Sent: Monday, July 26, 2004 10:23 AM To: udayan pathak; webappsec@xxxxxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx Subject: RE: Secure software development documents Udayan, I would recommend first looking at OWASP (http://www.owasp.org/). Their guide is relatively complete and of good quality. If you have $$$ to spend, I would recommend the 2-day Blackhat course "Network Application Design & Secure Implementation" (http://www.blackhat.com/html/bh-usa-04/train-bh-usa-04-dm.html) I found the course to be incredibly helpful, and it comes with a custom manual that is very detailed. Together, these two would probably get you 85% of the way there. The rest is (a) experience, (b) staying current (bugtraq, webappsec, etc), and (c) just being an intelligent individual. Mike Scovetta -----Original Message----- From: udayan pathak [mailto:udayan_pathak@xxxxxxxxx] Sent: Monday, July 26, 2004 7:19 AM To: webappsec@xxxxxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx Subject: Secure software development documents Hi everyone I have a query! What are the documentation standards being followed as far as secure software development is concerned? I find that in the current software development process the document generated do not/ barely cover the security of the application being developed. All the normal documents for requirement specification, requirement tracking, high level and low level design documents etc have nothing more than a small section in their template format for security, which looks more like a formality and hardly serves the purpose. Especially as far a software testing is concerned one gets the feeling that the provision for security testing in test cases gets diluted in the sea of functionality testing. Has anyone got any insights into this? or any other standard being followed ? Please let me know Udayan Pathak __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail -------------------------------------------------------------------------------------------------- This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is intended for the addressee only. Any unauthorized disclosure, use, dissemination, copying, or distribution of this message or any of its attachments or the information contained in this e-mail, or the taking of any action based on it, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this message.

Previous Message by Thread: click to view message preview

RE: Secure software development documents

With regards to testing specifically this is a draft of OWASP Testing Part 1. It is essentially a high level view of what to think about when building a testing function. It is draft but as we have been threatening to release it for ions I thought I would at least put this version on Sourceforge to download and get a flavor of what we (OWASP) are saying. It is not finished (we have a face to face this Weds to finally conclude this part and the re-write) so please just read the Chapters 7 and 8 in this context. Chapters 4, 5 and 6 are getting a re-write (significant prune) this week but this may help. It won't please everyone, especially the silver bullet brigade, but it is a good attempt and consensus that most people who have been responsible for building and running security testing of web app software in large dev shops have agreed on. You have to think strategically and testing after development is too little too late (despite some marketing claims to the contrary). http://prdownloads.sourceforge.net/owasp/TheOWASPTestingProjectPart1Draft.pd f?download This is an interesting point in the software security industry I think. I have seen two distinct camps forming, those trying to solve the problem by promoting building better software and tackle the root causes (people, process and technology) and those selling shinier and shinier silver bullets (software or services) ;-( Basically we are saying you need to test your SDLC process itself and then discrete parts of it such as requirements, design, implementation and deployment. Today people seem to have a fixation on testing deployment only which is too little too late and too in-efficient. Note: As I was typing this I saw a mail from Skip Carter that re-enforces this. -----Original Message----- From: Scovetta, Michael V [mailto:Michael.Scovetta@xxxxxx] Sent: Monday, July 26, 2004 10:23 AM To: udayan pathak; webappsec@xxxxxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx Subject: RE: Secure software development documents Udayan, I would recommend first looking at OWASP (http://www.owasp.org/). Their guide is relatively complete and of good quality. If you have $$$ to spend, I would recommend the 2-day Blackhat course "Network Application Design & Secure Implementation" (http://www.blackhat.com/html/bh-usa-04/train-bh-usa-04-dm.html) I found the course to be incredibly helpful, and it comes with a custom manual that is very detailed. Together, these two would probably get you 85% of the way there. The rest is (a) experience, (b) staying current (bugtraq, webappsec, etc), and (c) just being an intelligent individual. Mike Scovetta -----Original Message----- From: udayan pathak [mailto:udayan_pathak@xxxxxxxxx] Sent: Monday, July 26, 2004 7:19 AM To: webappsec@xxxxxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx Subject: Secure software development documents Hi everyone I have a query! What are the documentation standards being followed as far as secure software development is concerned? I find that in the current software development process the document generated do not/ barely cover the security of the application being developed. All the normal documents for requirement specification, requirement tracking, high level and low level design documents etc have nothing more than a small section in their template format for security, which looks more like a formality and hardly serves the purpose. Especially as far a software testing is concerned one gets the feeling that the provision for security testing in test cases gets diluted in the sea of functionality testing. Has anyone got any insights into this? or any other standard being followed ? Please let me know Udayan Pathak __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

Next Message by Thread: click to view message preview

RE: Secure software development documents

Hi All Building Secure Software How to avoid security problem the Right way By John Viega, Gary McGraw This is a good book about this subject. And I think all read e-mails about secure software development pattern in the last few days, we can use that pattern as best practices for secure software development. Also I am very interesting about this subject. Because crackers (not hackers) more like to find software errors (Actually lot of crackers use software bugs to malicious attack. They do not like to analyze & brick more complex algorithms. What they do is simply explode this systems using software bugs such as buffer overflows, heap overflows) U all have time we can discuss more about secure software life cycle kind for process to for secure software development I also like to contribute for that. This is very brief and incomplete e-mail, sorry about that, I will post more about this subject in my bust. Regards, G J Asanka Priyanjith -----Original Message----- From: Mark Curphey [mailto:mark@xxxxxxxxxxx] Sent: Tuesday, July 27, 2004 6:18 AM To: webappsec@xxxxxxxxxxxxxxxxx Subject: RE: Secure software development documents With regards to testing specifically this is a draft of OWASP Testing Part 1. It is essentially a high level view of what to think about when building a testing function. It is draft but as we have been threatening to release it for ions I thought I would at least put this version on Sourceforge to download and get a flavor of what we (OWASP) are saying. It is not finished (we have a face to face this Weds to finally conclude this part and the re-write) so please just read the Chapters 7 and 8 in this context. Chapters 4, 5 and 6 are getting a re-write (significant prune) this week but this may help. It won't please everyone, especially the silver bullet brigade, but it is a good attempt and consensus that most people who have been responsible for building and running security testing of web app software in large dev shops have agreed on. You have to think strategically and testing after development is too little too late (despite some marketing claims to the contrary). http://prdownloads.sourceforge.net/owasp/TheOWASPTestingProjectPart1Draf t.pd f?download This is an interesting point in the software security industry I think. I have seen two distinct camps forming, those trying to solve the problem by promoting building better software and tackle the root causes (people, process and technology) and those selling shinier and shinier silver bullets (software or services) ;-( Basically we are saying you need to test your SDLC process itself and then discrete parts of it such as requirements, design, implementation and deployment. Today people seem to have a fixation on testing deployment only which is too little too late and too in-efficient. Note: As I was typing this I saw a mail from Skip Carter that re-enforces this. -----Original Message----- From: Scovetta, Michael V [mailto:Michael.Scovetta@xxxxxx] Sent: Monday, July 26, 2004 10:23 AM To: udayan pathak; webappsec@xxxxxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx Subject: RE: Secure software development documents Udayan, I would recommend first looking at OWASP (http://www.owasp.org/). Their guide is relatively complete and of good quality. If you have $$$ to spend, I would recommend the 2-day Blackhat course "Network Application Design & Secure Implementation" (http://www.blackhat.com/html/bh-usa-04/train-bh-usa-04-dm.html) I found the course to be incredibly helpful, and it comes with a custom manual that is very detailed. Together, these two would probably get you 85% of the way there. The rest is (a) experience, (b) staying current (bugtraq, webappsec, etc), and (c) just being an intelligent individual. Mike Scovetta -----Original Message----- From: udayan pathak [mailto:udayan_pathak@xxxxxxxxx] Sent: Monday, July 26, 2004 7:19 AM To: webappsec@xxxxxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx Subject: Secure software development documents Hi everyone I have a query! What are the documentation standards being followed as far as secure software development is concerned? I find that in the current software development process the document generated do not/ barely cover the security of the application being developed. All the normal documents for requirement specification, requirement tracking, high level and low level design documents etc have nothing more than a small section in their template format for security, which looks more like a formality and hardly serves the purpose. Especially as far a software testing is concerned one gets the feeling that the provision for security testing in test cases gets diluted in the sea of functionality testing. Has anyone got any insights into this? or any other standard being followed ? Please let me know Udayan Pathak __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail -------------------------------------------------------------------------------------------------- This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is intended for the addressee only. Any unauthorized disclosure, use, dissemination, copying, or distribution of this message or any of its attachments or the information contained in this e-mail, or the taking of any action based on it, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this message.