From ken at krvw.com Thu Jan 3 09:25:01 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 3 Jan 2008 09:25:01 -0500 Subject: [SC-L] Code Testing Tools Could Be Acquisition Targets in '08 Message-ID: <603B2D24-780A-43F6-8ABF-599AF30CD149@krvw.com> New Year's greetings, SC-Lers, FYI, here's an interesting article about the application security testing space, from eWeek. http://www.eweek.com/article2/0,1759,2242973,00.asp?kc=EWRSS03119TX1K0000594 The author sort of compares apples and oranges a bit, IMHO, in comparing recent acquisitions of security testing product firms (e.g., SPI and WatchFire) with potential future acquisitions of source code analysis tool companies, but it's still worth a quick read. The good news in the article is, "The acquisitions, coupled with an increase in the number of providers offering vulnerability assessments, are indicators of a growing emphasis on increasing security in the development process." Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080103/317549ac/attachment.bin From yo at secappdev.org Sat Jan 5 12:44:39 2008 From: yo at secappdev.org (Johan Peeters) Date: Sat, 5 Jan 2008 18:44:39 +0100 Subject: [SC-L] secappdev 2008 Message-ID: <25b6e5cf0801050944l551e9239i769770e1626662fc@mail.gmail.com> secappdev.org organizes its annual course on secure application development in Leuven, Belgium, from March 3rd to 7th 2008. secappdev.org (http://secappdev.org) is a non-profit organization that aims to raise security awareness in the developer community and promote secure software engineering practices. In this course, we target experienced professional application developers. The course addresses a wide range of secure software engineering issues, so not only coding, but also requirements engineering, architecture and design, development processes and assurance. It does not focus on specific technologies, but uses them as examples to teach the underlying principles of software security. The faculty for the course are leading researchers and practitioners in software security and include - Bart Preneel, the head of COSIC, the renowned crypto lab that developed the AES. - Frank Piessens who pioneered application security teaching at university level. - Ken van Wyk, moderator of this excellent list and widely acclaimed author and lecturer. - Wietse Venema, the author of widely used, often seminal and erstwhile controversial, software such as the Postfix mail server, TCP Wrapper, an early host-based firewall, the Coroner's Toolkit, a forensics tool suite, and SATAN, a vulnerability scanner. There will be an opportunity to take the SANS GIAC Secure Software Programmer's (GSSP) exams at a sharply reduced price. The number of participants is limited. Register early to avoid disappointment. kr, Yo -- Johan Peeters http://secappdev.org http://johanpeeters.com From ken at krvw.com Wed Jan 9 13:00:15 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 9 Jan 2008 13:00:15 -0500 Subject: [SC-L] ENISA issue on Software Security Message-ID: <232F13A5-7E22-4D30-90D1-C902B05F1EB2@krvw.com> Greetings all, FYI, the European Network and Information Security Agency (ENISA) has just published their latest edition of ENISA Quarterly. This edition focuses on the issue of software security. You can download a PDF copy of EQ from: http://www.enisa.europa.eu/doc/pdf/publications/enisa_quarterly_12_07.pdf Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080109/60d392d6/attachment.bin From gem at cigital.com Wed Jan 9 19:48:16 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 9 Jan 2008 19:48:16 -0500 Subject: [SC-L] Darkreading: Getting Started Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> hi sc-l, One of the biggest hurdles facing software security is the problem of how to get started, especially when faced with an enterprise-level challenge. My first darkreading column for 2008 is about how to get started in software security. In the article, I describe four approaches: 1. the top-down framework; 2. portfolio risk; 3. training first; and 4. leading with a tool. We've tried them all with some success at different Cigital customers. Are there other ways to get started that have worked for you? By the way, I can use your help. Darkreading is beginning to track reaction to topics more carefully than in the past. You can help make software security more prominent by reading the article and passing the URL on to others you may find interested. Another thing that helps is posting to the message boards. Thanks in advance. Here's to even more widespread software security in 2008! gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From gunnar at arctecgroup.net Wed Jan 9 22:00:26 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Wed, 09 Jan 2008 21:00:26 -0600 Subject: [SC-L] Darkreading: Getting Started In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> Message-ID: Another approach is decentralized specialized teams, centers of excellence in current managementspeak, with a specific agenda and expertise on an area deemed strategic. This approach is probably best paired with 2,3, or 4 from your list. For example, a roving specialized threat modeling team that works with many groups to help develop threat models, attack patterns, tests, and so on. Or a roving team that focuses on build secure web apps and cuts across groups for specialized tasks for secure web app dev, say how do I use cardspace in my web app? Once you figure out what your strategic goals are for security - threat modeling, cardspace, static analysis, secure web app deve, etc. You can use #2 to focus them on the right stuff, or use #3 as roving advisers (like the cia in the cold war), or in #4 arm them with a tool or technology like XML Security gateway or static analysis tools to make a small band more effective in a large organization. -gp On 1/9/08 6:48 PM, "Gary McGraw" wrote: > hi sc-l, > > One of the biggest hurdles facing software security is the problem of how to > get started, especially when faced with an enterprise-level challenge. My > first darkreading column for 2008 is about how to get started in software > security. In the article, I describe four approaches: > 1. the top-down framework; > 2. portfolio risk; > 3. training first; and > 4. leading with a tool. > > We've tried them all with some success at different Cigital customers. > > Are there other ways to get started that have worked for you? > > By the way, I can use your help. Darkreading is beginning to track reaction > to topics more carefully than in the past. You can help make software > security more prominent by reading the article and passing the URL on to > others you may find interested. Another thing that helps is posting to the > message boards. Thanks in advance. > > Here's to even more widespread software security in 2008! > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From steingra at gmail.com Wed Jan 9 22:59:06 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Wed, 9 Jan 2008 19:59:06 -0800 Subject: [SC-L] Darkreading: Getting Started In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> Message-ID: <490a979e0801091959l748a2cffs121495a64e42fd02@mail.gmail.com> On Jan 9, 2008 4:48 PM, Gary McGraw wrote: > hi sc-l, > > One of the biggest hurdles facing software security is the problem of how to get started, especially when faced with an enterprise-level challenge. My first darkreading column for 2008 is about how to get started in software security. In the article, I describe four approaches: > 1. the top-down framework; > 2. portfolio risk; > 3. training first; and > 4. leading with a tool. Gary, I had success with #4, but not using the tools we usually think of for bootstrapping a program, namely static analysis or testing tools. When I took the position they had already settled on using Netegrity's Siteminder product for a common authentication and authorization scheme across all of the applications. I managed to get them to settle on doing a quasi-RBAC with Siteminder, using it almost as an identity service as well. Settling on one common high-quality authentication and authorization tool/framework had three effects: 1. It removed these services from the realm of development. They just had to integrate with it, but didn't have to figure out all of the corner cases to password changes, etc. that so often crop up, and people mess up in homegrown approaches. 2. It convinced developers to build clean interfaces in their code for things like authorization to call out externally and/or have the data provided to them in a standard fashion. By settling on RBAC it also helped a lot with role and permission modeling that did need to happen in the app. 3. In a shop that usually wanted to do everything itself, it broke that cycle and people got used to not having to write everything from scratch. It was a bit of a non-standard way to use a tool to bootstrap a security program. They essentially got sold Netegrity originally for the wrong reasons, but they picked it and in implementing it correctly did themselves a huge service. Just one data point on leading with a tool that focused more on architecture and design than it did on finding defects. -- Andy Steingruebl steingra at gmail.com From jim at manico.net Thu Jan 10 00:50:25 2008 From: jim at manico.net (Jim Manico) Date: Wed, 09 Jan 2008 21:50:25 -0800 Subject: [SC-L] Darkreading: Getting Started In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> Message-ID: <4785B221.9040607@manico.net> Gary, Interesting article. May I ask, why get started with only one of these approaches? Since 1-3 effects different parts of the organization (portfolio risk seems like a biz-management approach, top-down framework seems to effect software development management, and training effects developers, primarily) - why not *start* an initiative on all levels? In fact, doesn't it really take all of the above to truly effect permanent change in an organization? 4) Makes me nervous. I worry if you just toss a very expensive static code analysis or app scanning tool at development staff, you only provide a false sense of security since the coverage of even the best application security tools is very limited. Doesn't it take rather in-depth developer training and awareness for a tool to be truly useful? - Jim > hi sc-l, > > One of the biggest hurdles facing software security is the problem of how to get started, especially when faced with an enterprise-level challenge. My first darkreading column for 2008 is about how to get started in software security. In the article, I describe four approaches: > 1. the top-down framework; > 2. portfolio risk; > 3. training first; and > 4. leading with a tool. > > We've tried them all with some success at different Cigital customers. > > Are there other ways to get started that have worked for you? > > By the way, I can use your help. Darkreading is beginning to track reaction to topics more carefully than in the past. You can help make software security more prominent by reading the article and passing the URL on to others you may find interested. Another thing that helps is posting to the message boards. Thanks in advance. > > Here's to even more widespread software security in 2008! > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > > -- Best Regards, Jim Manico jim at manico.net 808.652.3805 (c) From ken at krvw.com Thu Jan 10 08:18:14 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 10 Jan 2008 08:18:14 -0500 Subject: [SC-L] Open Source Code Contains Security Holes -- Open Source -- InformationWeek Message-ID: SC-L, I imagine many of you have seen the results of Coverity's DHS-funded scan of a *bunch* of open source projects: http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All The stats are interesting, I suppose. I don't see any prioritization of the defects, but I imagine those were provided to the various open source project leaders. The question that isn't addressed here, and I'm sure was well outside of the scope of the project, is what each open source project *did* with the vulnerability information BEYOND just fixing the bugs? Did they merely fix the problems and move on? Or, did they use the defects as an opportunity to educate their team members on how to avoid these same sorts of things from creeping back in to the src tree? If they simply treated the vul lists as checklists of things to fix, then I'd expect a similar study in (say) five years to be just as bad as the recent Coverity study. I think it's important to learn from mistakes, not just fix them and get on with things. I sure hope the open source teams in this study did some of that. If any SC-Lers have insight here, please share. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080110/e0772486/attachment.bin From gem at cigital.com Thu Jan 10 08:48:50 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 10 Jan 2008 08:48:50 -0500 Subject: [SC-L] Open Source Code Contains Security Holes -- Open Source -- InformationWeek In-Reply-To: References: Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103821FF6@va-mailhub.cigital.com> Good points Ken. I lurk on a top-secret open source list that has been discussing this since New Years. I posted an entry on Justice League with my partially formed opinion: http://www.cigital.com/justiceleague/2008/01/09/on-open-source/ I have also written a longer piece, which will be posted one of these weeks on darkreading. The gist of my opinion is that these open source projects are excellent work that should be commended, but that focus exclusively on bugs. Coverity's PR has been straightforward and correct, but the press does not get it. For example, compare these two articles: http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All http://www.zdnet.com.au/news/security/soa/11-open-source-projects-pass-security-health-check/0,130061744,339284949,00.htm There's a /. thread on this to: http://slashdot.org/article.pl?sid=08/01/09/0027229 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Thursday, January 10, 2008 8:18 AM To: Secure Coding Subject: [SC-L] Open Source Code Contains Security Holes -- Open Source -- InformationWeek SC-L, I imagine many of you have seen the results of Coverity's DHS-funded scan of a *bunch* of open source projects: http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All The stats are interesting, I suppose. I don't see any prioritization of the defects, but I imagine those were provided to the various open source project leaders. The question that isn't addressed here, and I'm sure was well outside of the scope of the project, is what each open source project *did* with the vulnerability information BEYOND just fixing the bugs? Did they merely fix the problems and move on? Or, did they use the defects as an opportunity to educate their team members on how to avoid these same sorts of things from creeping back in to the src tree? If they simply treated the vul lists as checklists of things to fix, then I'd expect a similar study in (say) five years to be just as bad as the recent Coverity study. I think it's important to learn from mistakes, not just fix them and get on with things. I sure hope the open source teams in this study did some of that. If any SC-Lers have insight here, please share. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com From gem at cigital.com Thu Jan 10 08:52:24 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 10 Jan 2008 08:52:24 -0500 Subject: [SC-L] Darkreading: Getting Started In-Reply-To: <4785B221.9040607@manico.net> References: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> <4785B221.9040607@manico.net> Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103821FF8@va-mailhub.cigital.com> Hi Jim, Good question. Often a coordinated/distributed approach will work. However, to make things simple, I tried to untangle the threads. We have actual customers who have followed each of the 4 paths (with other interesting twists of course), so it made sense to carve things out that way to me. I agree with you on 4 (tool first), but the reality of the situation is that many enterprises were sold tools as a just-add-water solution and they've been looking around for the water ever since. That is one way to get started and it does work. Reality sucks, huh? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico Sent: Thursday, January 10, 2008 12:50 AM Cc: Secure Coding Mailing List (SC-L at securecoding.org) Subject: Re: [SC-L] Darkreading: Getting Started Gary, Interesting article. May I ask, why get started with only one of these approaches? Since 1-3 effects different parts of the organization (portfolio risk seems like a biz-management approach, top-down framework seems to effect software development management, and training effects developers, primarily) - why not *start* an initiative on all levels? In fact, doesn't it really take all of the above to truly effect permanent change in an organization? 4) Makes me nervous. I worry if you just toss a very expensive static code analysis or app scanning tool at development staff, you only provide a false sense of security since the coverage of even the best application security tools is very limited. Doesn't it take rather in-depth developer training and awareness for a tool to be truly useful? - Jim > hi sc-l, > > One of the biggest hurdles facing software security is the problem of how to get started, especially when faced with an enterprise-level challenge. My first darkreading column for 2008 is about how to get started in software security. In the article, I describe four approaches: > 1. the top-down framework; > 2. portfolio risk; > 3. training first; and > 4. leading with a tool. > > We've tried them all with some success at different Cigital customers. > > Are there other ways to get started that have worked for you? > > By the way, I can use your help. Darkreading is beginning to track reaction to topics more carefully than in the past. You can help make software security more prominent by reading the article and passing the URL on to others you may find interested. Another thing that helps is posting to the message boards. Thanks in advance. > > Here's to even more widespread software security in 2008! > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org List > information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) as a free, non-commercial service to the software security community. > _______________________________________________ > > > > -- Best Regards, Jim Manico jim at manico.net 808.652.3805 (c) _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From gem at cigital.com Thu Jan 10 08:54:39 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 10 Jan 2008 08:54:39 -0500 Subject: [SC-L] Darkreading: Getting Started In-Reply-To: <490a979e0801091959l748a2cffs121495a64e42fd02@mail.gmail.com> References: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> <490a979e0801091959l748a2cffs121495a64e42fd02@mail.gmail.com> Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103821FF9@va-mailhub.cigital.com> Hi Andy, Good point about 4 (tool first). Sometimes security feature rollout can provide a good impetus. We saw that too, focused around crypto for PCI with one of our major customers. The only real danger with following that path is that you tend to emphasize that security is a feature (and only a feature), which as we all know is a big misunderstanding among dev people. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -----Original Message----- From: Andy Steingruebl [mailto:steingra at gmail.com] Sent: Wednesday, January 09, 2008 10:59 PM To: Secure Coding Mailing List (SC-L at securecoding.org) Cc: Gary McGraw Subject: Re: [SC-L] Darkreading: Getting Started On Jan 9, 2008 4:48 PM, Gary McGraw wrote: > hi sc-l, > > One of the biggest hurdles facing software security is the problem of how to get started, especially when faced with an enterprise-level challenge. My first darkreading column for 2008 is about how to get started in software security. In the article, I describe four approaches: > 1. the top-down framework; > 2. portfolio risk; > 3. training first; and > 4. leading with a tool. Gary, I had success with #4, but not using the tools we usually think of for bootstrapping a program, namely static analysis or testing tools. When I took the position they had already settled on using Netegrity's Siteminder product for a common authentication and authorization scheme across all of the applications. I managed to get them to settle on doing a quasi-RBAC with Siteminder, using it almost as an identity service as well. Settling on one common high-quality authentication and authorization tool/framework had three effects: 1. It removed these services from the realm of development. They just had to integrate with it, but didn't have to figure out all of the corner cases to password changes, etc. that so often crop up, and people mess up in homegrown approaches. 2. It convinced developers to build clean interfaces in their code for things like authorization to call out externally and/or have the data provided to them in a standard fashion. By settling on RBAC it also helped a lot with role and permission modeling that did need to happen in the app. 3. In a shop that usually wanted to do everything itself, it broke that cycle and people got used to not having to write everything from scratch. It was a bit of a non-standard way to use a tool to bootstrap a security program. They essentially got sold Netegrity originally for the wrong reasons, but they picked it and in implementing it correctly did themselves a huge service. Just one data point on leading with a tool that focused more on architecture and design than it did on finding defects. -- Andy Steingruebl steingra at gmail.com From gem at cigital.com Thu Jan 10 08:58:16 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 10 Jan 2008 08:58:16 -0500 Subject: [SC-L] Darkreading: Getting Started In-Reply-To: References: <41945506397C0C4886A8C5BFF089B5CA3103821FD0@va-mailhub.cigital.com> Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103821FFB@va-mailhub.cigital.com> hi gp, Yup. I count that as 1 (top-down framework) because that approach often leads with the creation of a special ops execution team that becomes the software security group. By far, this is the most impressive approach in terms of results and the one that is the most effective in well-run enterprises. Please do note that getting started does not mean you have to stick with only one of the ways. Any mature approach to software security requires aspects of each of the getting started ways. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -----Original Message----- From: Gunnar Peterson [mailto:gunnar at arctecgroup.net] Sent: Wednesday, January 09, 2008 10:00 PM To: Gary McGraw; Secure Mailing List Subject: Re: [SC-L] Darkreading: Getting Started Another approach is decentralized specialized teams, centers of excellence in current managementspeak, with a specific agenda and expertise on an area deemed strategic. This approach is probably best paired with 2,3, or 4 from your list. For example, a roving specialized threat modeling team that works with many groups to help develop threat models, attack patterns, tests, and so on. Or a roving team that focuses on build secure web apps and cuts across groups for specialized tasks for secure web app dev, say how do I use cardspace in my web app? Once you figure out what your strategic goals are for security - threat modeling, cardspace, static analysis, secure web app deve, etc. You can use #2 to focus them on the right stuff, or use #3 as roving advisers (like the cia in the cold war), or in #4 arm them with a tool or technology like XML Security gateway or static analysis tools to make a small band more effective in a large organization. -gp On 1/9/08 6:48 PM, "Gary McGraw" wrote: > hi sc-l, > > One of the biggest hurdles facing software security is the problem of > how to get started, especially when faced with an enterprise-level > challenge. My first darkreading column for 2008 is about how to get > started in software security. In the article, I describe four approaches: > 1. the top-down framework; > 2. portfolio risk; > 3. training first; and > 4. leading with a tool. > > We've tried them all with some success at different Cigital customers. > > Are there other ways to get started that have worked for you? > > By the way, I can use your help. Darkreading is beginning to track > reaction to topics more carefully than in the past. You can help make > software security more prominent by reading the article and passing > the URL on to others you may find interested. Another thing that > helps is posting to the message boards. Thanks in advance. > > Here's to even more widespread software security in 2008! > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org List > information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) as a free, non-commercial service to the software security community. > _______________________________________________ > From coley at linus.mitre.org Thu Jan 10 16:31:19 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 10 Jan 2008 16:31:19 -0500 (EST) Subject: [SC-L] Open Source Code Contains Security Holes -- Open Source -- InformationWeek In-Reply-To: References: Message-ID: Another question is how many of the reported bugs wound up being false positives. Through casual conversations with some vendor (I forget whom), it became clear that the massive number of reported issues was very time-consuming to deal with, and not always productive. Of course this is no surprise to people on this list, but important to note. Regarding vendor responses - through my work in CVE, I've noticed that eventually, a developer who's been "tagged" often enough will eventually develop more systematic responses such as secure APIs, coding standards, or at least a thorough review. This is briefly touched on in the Unforgivable Vulnerabilities paper that I gave at Black Hat USA last year, where I discuss vulnerability complexity as a qualitative indicator of software security. - Steve From list-procurare at secureconsulting.net Wed Jan 16 08:25:58 2008 From: list-procurare at secureconsulting.net (Benjamin Tomhave) Date: Wed, 16 Jan 2008 08:25:58 -0500 Subject: [SC-L] XKCD on sane build environments Message-ID: <478E05E6.5000507@secureconsulting.net> A little something to make you smile... :) http://xkcd.com/371/ -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ [ Random Quote: ] Marge: Homer! There's someone here who can help you... Homer: Is it Batman? Marge: No, he's a scientist. Homer: Batman's a scientist?! Marge: It's not Batman! From gem at cigital.com Thu Jan 31 17:34:11 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 31 Jan 2008 17:34:11 -0500 Subject: [SC-L] Silver Bullet: Ed Amoroso Message-ID: <41945506397C0C4886A8C5BFF089B5CA310388D125@va-mailhub.cigital.com> hi sc-l, Last week we released the 22nd edition of Silver Bullet. This time, I have a conversation with Ed Amoroso, CISO of AT&T. Ed has a deep interest in software security and has been a high level executive champion for years. In the podcast we discuss software security, bugs/flaws, privacy and monitoring, and a host of other things: http://www.cigital.com/silverbullet/ I have been expanding the Silver Bullet target list to imclude executives (based on feedback from some of you on this list). Good? Bad? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From iggy69.e at gmail.com Fri Feb 1 23:52:22 2008 From: iggy69.e at gmail.com (Ignacio Evans) Date: Sat, 2 Feb 2008 12:52:22 +0800 Subject: [SC-L] Silver Bullet: Ed Amoroso In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA310388D125@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA310388D125@va-mailhub.cigital.com> Message-ID: Thanks, Gary. I saw it up on Silver Bullet yesterday, downloaded it immediately and listened to it - great stuff. I got hooked on Ed Amoroso from his podcast with Sondra Schneider and Frontline Security. It's so strange seeing him get hammered by the privacy zealots. It takes a top-notch interviewer to make an excellent podcast and you, Sondra Schneider, and Phil Windley are the best in the business. Stephen Evans On Fri, Feb 1, 2008 at 6:34 AM, Gary McGraw wrote: > hi sc-l, > > Last week we released the 22nd edition of Silver Bullet. This time, I > have a conversation with Ed Amoroso, CISO of AT&T. Ed has a deep interest > in software security and has been a high level executive champion for years. > In the podcast we discuss software security, bugs/flaws, privacy and > monitoring, and a host of other things: > > http://www.cigital.com/silverbullet/ > > I have been expanding the Silver Bullet target list to imclude executives > (based on feedback from some of you on this list). Good? Bad? > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080202/9f5a8499/attachment.html From vincent at zijnemail.nl Mon Feb 4 07:16:10 2008 From: vincent at zijnemail.nl (Vincent Verhagen) Date: Mon, 04 Feb 2008 13:16:10 +0100 Subject: [SC-L] Programming language comparison? Message-ID: <47A7020A.3080206@zijnemail.nl> Hi all, I was referred to this list by a fellow security consultant for this specific question. Please forgive me if this is the wrong forum :) We're in the process of creating a kind of handbook for third parties that develop web applications for us. One (quite extensive, I'm happy to report) chapter will be about security and for that I'm looking for a comparison of common programming/scripting languages (PHP, C variants, JAVA, etc) their specific risks and why or why not to use them. Has anyone created such an overview I could use as a basis to work from? Thanks in advance! Vincent Verhagen Simac ICT Netherlands From ramartin at mitre.org Mon Feb 4 08:27:30 2008 From: ramartin at mitre.org (Robert A. Martin) Date: Mon, 4 Feb 2008 08:27:30 -0500 Subject: [SC-L] Programming language comparison? In-Reply-To: <47A7020A.3080206@zijnemail.nl> References: <47A7020A.3080206@zijnemail.nl> Message-ID: Hi Vincent, While not a overview, you can find language specific weaknesses for C, Java, C++, and PHP on the "Other Views" page of the Common Weakness Enumeration (CWE) Project (see http://cwe.mitre.org/data/other.html). The "List" items give the names of the issues, the "Slice" gives a concatenated set of the write-ups of those items, and the "XML" will give you a concatenated extract of the XML for those items versus hunting for them in the complete XML for CWE. These aren't specific to web application issues so there will be some pruning of the list for your purposes. One way to focus the list would be to correlate them with the CWEs listed in the OWASP Top 10 as a start, which is another list on the above page that has 24 items listed but some of them are not language specific so they would be in addition to the others. The above lists include 56 for C, Java has 70, C++ has 58, and PHP has 10. You still need to add to that issues that apply to all languages versus these lists of language specific weaknesses and C and C++ have significant overlap given their relationship. Regards, Bob Martin CWE Project Leader MITRE Corporation P.S. Comments and suggestions for new items, clarifications, or additional examples are welcome for this community effort either directly to cwe at mitre.org or through the cwe-research-list which you can sign-up for on the site. At 1:16 PM +0100 2/4/08, Vincent Verhagen wrote: >Hi all, > >I was referred to this list by a fellow security consultant for this >specific question. Please forgive me if this is the wrong forum :) > >We're in the process of creating a kind of handbook for third parties >that develop web applications for us. >One (quite extensive, I'm happy to report) chapter will be about >security and for that I'm looking for a comparison of common >programming/scripting languages (PHP, C variants, JAVA, etc) their >specific risks and why or why not to use them. >Has anyone created such an overview I could use as a basis to work from? > >Thanks in advance! > >Vincent Verhagen >Simac ICT Netherlands > >_______________________________________________ >Secure Coding mailing list (SC-L) SC-L at securecoding.org >List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >List charter available at - http://www.securecoding.org/list/charter.php >SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >as a free, non-commercial service to the software security community. >_______________________________________________ From romain.gaucher at nist.gov Mon Feb 4 14:06:25 2008 From: romain.gaucher at nist.gov (Romain Gaucher) Date: Mon, 04 Feb 2008 14:06:25 -0500 Subject: [SC-L] Static analysis tool exposition - call for participation Message-ID: <47A76231.7040006@nist.gov> The NIST SAMATE project (http://samate.nist.gov/) is preparing an exposition for static analysis tools that find security relevant defects. Very briefly, tool makers run their tools on a set of real programs; the results are analyzed and then reported at a workshop. The details of the exposition are at http://samate.nist.gov/index.php/SATE We invite tool makers to sign up by February 8. If you would like to participate in the exposition, or if you have questions, please email Vadim Okun (vadim.okun at nist.gov). Sincerely, Romain Gaucher -- http://samate.nist.gov From coley at linus.mitre.org Mon Feb 4 16:41:45 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 4 Feb 2008 16:41:45 -0500 (EST) Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: On Mon, 4 Feb 2008, Robert A. Martin wrote: > You still need to add to that issues that apply to all languages > versus these lists of language specific weaknesses and C and C++ have > significant overlap given their relationship. There is an important point to keep in mind when using the (current) CWE views. Some weaknesses have been marked with an "All Languages" tag, even though they might be more prevalent in certain languages. For example, format string problems can happen in any language that uses format strings ("%99999999s" to fill up disk or memory, anybody?), so it's marked with "All" and it's not in the C-specific view, even though there's a heavy concentration of format strings in C/C++. On the opposite end, eval injection issues are labeled as affecting specific languages such as Perl and PHP, when a category of "any interpreted language with an eval() or equivalent" would be more appropriate. We haven't yet accounted for these subtleties within CWE yet, although we plan to do so. - Steve From gem at cigital.com Mon Feb 4 17:39:01 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 4 Feb 2008 17:39:01 -0500 Subject: [SC-L] Silver Bullet: spaf transcript Message-ID: <41945506397C0C4886A8C5BFF089B5CA310388D18B@va-mailhub.cigital.com> hi sc-l, As you probably know, around half of the Silver Bullet podcasts are printed as the "Interview" department of IEEE Security & Privacy magazine. We just put a transcript of the spaf (Gene Spafford) interview on the website: http://www.cigital.com/silverbullet/shows/silverbullet-018-spaf.pdf Please feel free to send copies all around, use printouts to start a fire, etc. BTW, the issue this transcript is in (Jan/Feb 2008) has incited some controversy on the net over an article describing security risks involved in the ironically-named Protect America Act. Check that out too: http://abcnews.go.com/Blotter/story?id=4224513&page=1 http://www.washingtonindependent.com/ http://it.slashdot.org/article.pl?no_d2=1&sid=08/01/29/1937207 Subscribe to S&P today. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ljknews at mac.com Mon Feb 4 20:51:36 2008 From: ljknews at mac.com (ljknews) Date: Mon, 4 Feb 2008 20:51:36 -0500 Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: At 4:41 PM -0500 2/4/08, Steven M. Christey wrote: > On Mon, 4 Feb 2008, Robert A. Martin wrote: > >> You still need to add to that issues that apply to all languages >> versus these lists of language specific weaknesses and C and C++ have >> significant overlap given their relationship. > > There is an important point to keep in mind when using the (current) CWE > views. Some weaknesses have been marked with an "All Languages" tag, even > though they might be more prevalent in certain languages. For example, > format string problems can happen in any language that uses format strings > ("%99999999s" to fill up disk or memory, anybody?), so it's marked with > "All" and it's not in the C-specific view, even though there's a heavy > concentration of format strings in C/C++. It is marked as "All" ? What is the construct in Ada that has such a risk ? -- Larry Kilgallen From cew at ACM.ORG Mon Feb 4 21:49:51 2008 From: cew at ACM.ORG (Craig E. Ward) Date: Mon, 4 Feb 2008 18:49:51 -0800 Subject: [SC-L] Programming language comparison? In-Reply-To: <47A7020A.3080206@zijnemail.nl> References: <47A7020A.3080206@zijnemail.nl> Message-ID: My final paper for my masters degree was on how some vulnerabilities manifest themselves, or fail to manifest, in different programming languages. I included C, C++, Java, Perl, and Standard ML. The title of the paper is "Implications of Programming Language Selection On the Construction of Secure Software Systems." You can find a link to it at my work web page: http://www.isi.edu/~cward/papers/LMU/index.html. One of the points I was trying to make in the paper is that the security attributes of a programming language were also important to take into consideration when selecting a language for a particular task. I'm glad that you're incorporating this into your process. Craig At 1:16 PM +0100 2/4/08, Vincent Verhagen wrote: >Hi all, > >I was referred to this list by a fellow security consultant for this >specific question. Please forgive me if this is the wrong forum :) > >We're in the process of creating a kind of handbook for third parties >that develop web applications for us. >One (quite extensive, I'm happy to report) chapter will be about >security and for that I'm looking for a comparison of common >programming/scripting languages (PHP, C variants, JAVA, etc) their >specific risks and why or why not to use them. >Has anyone created such an overview I could use as a basis to work from? > >Thanks in advance! > >Vincent Verhagen >Simac ICT Netherlands -- Internet: cew at ACM.ORG "If a program has not been specified, it cannot be incorrect; it can only be surprising." (Young, Boebert, and Kain) From vincent at zijnemail.nl Tue Feb 5 03:44:58 2008 From: vincent at zijnemail.nl (Vincent Verhagen) Date: Tue, 05 Feb 2008 09:44:58 +0100 Subject: [SC-L] Programming language comparison? In-Reply-To: <47A7020A.3080206@zijnemail.nl> References: <47A7020A.3080206@zijnemail.nl> Message-ID: <47A8220A.1060601@zijnemail.nl> Gentleman, Thanks for the contributions to my question. They've been helpful! Vincent Vincent Verhagen wrote: > Hi all, > > I was referred to this list by a fellow security consultant for this > specific question. Please forgive me if this is the wrong forum :) > > We're in the process of creating a kind of handbook for third parties > that develop web applications for us. > One (quite extensive, I'm happy to report) chapter will be about > security and for that I'm looking for a comparison of common > programming/scripting languages (PHP, C variants, JAVA, etc) their > specific risks and why or why not to use them. > Has anyone created such an overview I could use as a basis to work from? > > Thanks in advance! > > Vincent Verhagen > Simac ICT Netherlands > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From ken at krvw.com Tue Feb 5 13:26:27 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 5 Feb 2008 13:26:27 -0500 Subject: [SC-L] Tech Insight: The Buzz Around Fuzzing - Application and Perimeter Security News Analysis - Dark Reading Message-ID: FYI, for those who are interested in fuzz testing tools, here's an interesting article URL from Dark Reading. http://www.darkreading.com/document.asp?doc_id=144773&f_src=darkreading_section_296 Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080205/e148b83b/attachment.bin From coley at linus.mitre.org Tue Feb 5 16:44:57 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 5 Feb 2008 16:44:57 -0500 (EST) Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: On Mon, 4 Feb 2008, ljknews wrote: > > ("%99999999s" to fill up disk or memory, anybody?), so it's marked with > > "All" and it's not in the C-specific view, even though there's a heavy > > concentration of format strings in C/C++. > > It is marked as "All" ? > > What is the construct in Ada that has such a risk ? Hmmmm, I don't see any, but then again I don't know Ada. Is there no equivalent to format strings in Ada? No library support for it? Your question actually highlights the point I was trying to make - in CWE, we don't yet have a way of specifying language families, such as "any language that directly supports format strings," or "any language with dynamic evaluation." - Steve From rcs at cert.org Tue Feb 5 17:09:05 2008 From: rcs at cert.org (Robert C. Seacord) Date: Tue, 05 Feb 2008 17:09:05 -0500 Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: <47A8DE81.3010407@cert.org> Steven, A while back Hal Burch and I wrote an article on "Programming Language Format String Vulnerabilities" which is available here: http://www.ddj.com/security/197002914 In the article we looked at the potential consequences of format string vulnerabilities in Perl, PHP, Java, Python, and Ruby programs. Sorry, we didn't write anything about Ada. ;^) rCs > On Mon, 4 Feb 2008, ljknews wrote: > > >>> ("%99999999s" to fill up disk or memory, anybody?), so it's marked with >>> "All" and it's not in the C-specific view, even though there's a heavy >>> concentration of format strings in C/C++. >>> >> It is marked as "All" ? >> >> What is the construct in Ada that has such a risk ? >> > > Hmmmm, I don't see any, but then again I don't know Ada. Is there no > equivalent to format strings in Ada? No library support for it? > > Your question actually highlights the point I was trying to make - in CWE, > we don't yet have a way of specifying language families, such as "any > language that directly supports format strings," or "any language with > dynamic evaluation." > > - Steve > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From list-spam at secureconsulting.net Tue Feb 5 20:45:01 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 05 Feb 2008 20:45:01 -0500 Subject: [SC-L] a little coding humor... Message-ID: <47A9111D.1050003@secureconsulting.net> A little something to make you smile... infosec fellow for MS Mark Curphy posted an amusing cartoon to his blog on code review: http://securitybuddha.com/2008/02/06/funny-code-review-cartoon/ cheers, -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] The Law of False Alerts: "As the rate of erroneous alerts increases, operator reliance, or belief, in subsequent warnings decreases." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From ljknews at mac.com Tue Feb 5 23:36:45 2008 From: ljknews at mac.com (ljknews) Date: Tue, 5 Feb 2008 23:36:45 -0500 Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: At 4:44 PM -0500 2/5/08, Steven M. Christey wrote: > On Mon, 4 Feb 2008, ljknews wrote: > >> > ("%99999999s" to fill up disk or memory, anybody?), so it's marked with >> > "All" and it's not in the C-specific view, even though there's a heavy >> > concentration of format strings in C/C++. >> >> It is marked as "All" ? >> >> What is the construct in Ada that has such a risk ? > > Hmmmm, I don't see any, but then again I don't know Ada. Is there no > equivalent to format strings in Ada? No library support for it? Not that I know of, but if you can specify a Pascal equivalent I might be able to see what you are aiming at. Have you evaluated Pascal for this defect that is present in "All" languages ? > Your question actually highlights the point I was trying to make - in CWE, > we don't yet have a way of specifying language families, such as "any > language that directly supports format strings," or "any language with > dynamic evaluation." Your choice of terminology is yours to make, only within the bounds of reasonable use of English. In English there is a distinct difference between the terms ALL and SOME, between the terms ALL and MANY and even between the terms ALL and MOST. -- Larry Kilgallen From petesh at indigo.ie Wed Feb 6 04:56:55 2008 From: petesh at indigo.ie (Pete Shanahan) Date: Wed, 06 Feb 2008 09:56:55 +0000 Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: <47A98467.9000307@indigo.ie> ljknews wrote: > At 4:44 PM -0500 2/5/08, Steven M. Christey wrote: >> On Mon, 4 Feb 2008, ljknews wrote: >> >>>> ("%99999999s" to fill up disk or memory, anybody?), so it's marked with >>>> "All" and it's not in the C-specific view, even though there's a heavy >>>> concentration of format strings in C/C++. >>> It is marked as "All" ? >>> >>> What is the construct in Ada that has such a risk ? >> Hmmmm, I don't see any, but then again I don't know Ada. Is there no >> equivalent to format strings in Ada? No library support for it? > > Not that I know of, but if you can specify a Pascal equivalent > I might be able to see what you are aiming at. Have you evaluated > Pascal for this defect that is present in "All" languages ? > Pascal per-se does not have a format string vulnerability - you don't have any functions like that in the base language. Delphi (Borland's oo-pascal) however has a whole truckload of Format* commands which take a format string as the first parameter and thus would potentially be vulnerable to the DOS attack. Delphi has the capability of run-time bounds checking, which would catch a lot of 'variables not on the stack' errors, however this can be turned off for performance reasons. I don't have a ratio of on/off people. When I originally wrote Delphi code in '96 I switched off bounds checking as the systems I was running on could not take the hit. Now, it is left on continuously as the cost of cycles is not worth it to have better software From Brian.A.Shea at bankofamerica.com Wed Feb 6 12:35:59 2008 From: Brian.A.Shea at bankofamerica.com (Shea, Brian A) Date: Wed, 06 Feb 2008 09:35:59 -0800 Subject: [SC-L] Programming language comparison? In-Reply-To: References: <47A7020A.3080206@zijnemail.nl> Message-ID: It seems like this exchange is focused on whether bug / flaw classes can be applied to "All" programming languages or not. Isn't the question at hand which languages have the property "Subject to bug / flaw class XXX" (true | false), and not whether you can find one or more class that fits the "All" category? What we need is a coherent dataset showing the languages that have been assessed, and the classes of bugs or flaws each is subject to. Then I could search that dataset to find the listing of "all languages that are / are not subject to security bug class XXXX" when doing assessments or deciding on my coding language. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of ljknews Sent: Tuesday, February 05, 2008 8:37 PM To: sc-l at securecoding.org Subject: Re: [SC-L] Programming language comparison? At 4:44 PM -0500 2/5/08, Steven M. Christey wrote: > On Mon, 4 Feb 2008, ljknews wrote: > >> > ("%99999999s" to fill up disk or memory, anybody?), so it's marked with >> > "All" and it's not in the C-specific view, even though there's a heavy >> > concentration of format strings in C/C++. >> >> It is marked as "All" ? >> >> What is the construct in Ada that has such a risk ? > > Hmmmm, I don't see any, but then again I don't know Ada. Is there no > equivalent to format strings in Ada? No library support for it? Not that I know of, but if you can specify a Pascal equivalent I might be able to see what you are aiming at. Have you evaluated Pascal for this defect that is present in "All" languages ? > Your question actually highlights the point I was trying to make - in CWE, > we don't yet have a way of specifying language families, such as "any > language that directly supports format strings," or "any language with > dynamic evaluation." Your choice of terminology is yours to make, only within the bounds of reasonable use of English. In English there is a distinct difference between the terms ALL and SOME, between the terms ALL and MANY and even between the terms ALL and MOST. -- Larry Kilgallen _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From seba at deleersnyder.eu Mon Feb 11 08:47:30 2008 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Mon, 11 Feb 2008 14:47:30 +0100 Subject: [SC-L] CALL FOR TOPICS-PAPERS - OWASP AppSec Conference Europe 2008 - May 22-23, Belgium Message-ID: <6kft65$2pcmni@relay.skynet.be> *** CALL FOR TOPICS-PAPERS *** OWASP AppSec Conference Europe 2008 May 22-23, 2008 - Brussels, Belgium http://www.owasp.org/index.php/AppSecEU08 Call for papers: Business & Technical Sessions Following on from the great success of OWASP Conferences in 2006 and 2007 in the United States and Europe, the conference comes back to Belgium in May 2008. The conference will offer an opportunity for security professionals, developers, and managers to hear from industry recognised speakers on the latest critical security risks associated with application security. OWASP is seeking for presentations on Application Security and related OWASP projects from the community. Over the conference program there are 9 technical and 9 business presentation sessions running approximately 1 hour in length each. TOPICS OF INTEREST Topics of interest include, but are not limited to: - OWASP Project Presentation (i.e Tool Updates/Project Status etc) - Business Risk from Applications - Privacy Concerns with Applications and Data Storage - Baseline or Metrics for Application Security - Web application security - Secure application development - Security of Service Oriented Architectures - Threat modeling of web applications - Vulnerability analysis of web applications (code review, pentest, static analysis, scanning) - Countermeasures for web application vulnerabilities - Platform or language (e.g. Java, .NET) security features that help secure web applications - How to use databases securely in web applications - Access control in web applications - Browser security - Web services security As there a limited number of available presentations please email your proposed presentation ideas to: seba 'at' owasp.org Simply reply to this email with your idea and a short paragraph or two on what you propose to present on. Closing date for presentation ideas is March 1st 2008, with presentation material due May 1st 2008. Visit http://www.owasp.org for more information on OWASP and the Conferences. Thank you, Kind regards, Seba As in the previous editions, the OWASP AppSec Europe 2008 conference will also feature a refereed papers track which focuses on academic research. More information on http://www.owasp.org/index.php/OWASP_AppSec_Europe_2008_-_Belgium/CFP ORGANIZING COMMITTEE OWASP Conferences Chair: Dave Wichers - Aspect Security - dave.wichers 'at' owasp.org 2008 EU Planning Committee Chair: Sebastien Deleersnyder - Telindus - seba 'at' owasp.org Refereed Papers Chair: Lieven Desmet - KU Leuven - Lieven.Desmet 'at' cs.kuleuven.ac.be From gem at cigital.com Fri Feb 15 08:49:52 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 15 Feb 2008 08:49:52 -0500 Subject: [SC-L] Darkreading: code scanning Message-ID: <41945506397C0C4886A8C5BFF089B5CA310388D1ED@va-mailhub.cigital.com> Hi sc-l, This month, my darkreading column is about code scanning. Remember that flurry in the press about Coverity's scan project where half of the stories were positive and the other half negative? That prompted me to write this column (started with a Justice League posting as some of you will recall). Topics: open source, code scanning, architectural risk analysis, declaring security victory http://www.darkreading.com/document.asp?doc_id=146053&WT.svl=column1_1 In a sentence: code scanning is good and everyone should be doing it, but don't declare security too early and never forget the architecture. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Fri Feb 15 09:49:33 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Fri, 15 Feb 2008 09:49:33 -0500 Subject: [SC-L] Michael Howard's Web Log : Introducing SAFECode Message-ID: <1E7F8A1B-9EEF-4A7E-98CD-79373D6B7A13@krvw.com> FYI, from Michael Howard's blog: "Today SAFECode, the Software Assurance Forum for Excellence in Code, introduced its first white paper, "Software Assurance: An Overview of Current Industry Best Practices." The organization was founded by Microsoft, Symantec, EMC, SAP and Juniper to advance understanding and practices related to secure development and integrity controls. Our goal is to raise the security bar across the software industry to reduce vulnerabilities." Complete blog text, along with links to SAFECode and the white paper can be found here: http://blogs.msdn.com/michael_howard/archive/2008/02/14/introducing-safecode.aspx Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080215/d85bf7c3/attachment.bin From ken at krvw.com Tue Feb 19 10:04:23 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 19 Feb 2008 10:04:23 -0500 Subject: [SC-L] SDLCs and x.509 at OWASP Belgium, 4 March 2008 Message-ID: <3F3CDA5A-02A8-4576-B6EC-E72275E31FD8@krvw.com> During the SecAppDev (http://www.secappdev.org) class next month in Leuven, Belgium, there's also going to be a regional OWASP meeting. I've been asked to join in and present a short session comparing various secure development methodologies (Microsoft's SDL, Cigital's "Touchpoints", and OWASP's own CLASP, mainly). If you're in the area, I hope you'll join us. Local details are available on OWASP's site at http://www.owasp.org/index.php/Belgium . While I'm there, I'll also be doing a CAcert/Thawte x.509 "signing". So, if you're using either of these free x.509 certificate services, and are still trying to get the 50 assurance points necessary to have your real name on your certificates, stop by with two forms of government-issued ID (and photocopies, if using Thawte -- not necessary for CAcert). I'll be happy to help out with either/both 10 Thawte points or 35 CAcert points. No charge, of course. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080219/788de1e0/attachment.bin From ken at krvw.com Tue Feb 19 12:24:59 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 19 Feb 2008 12:24:59 -0500 Subject: [SC-L] SC-L Administrivia: How does the readership feel about sponsorships? Message-ID: <64441696-066A-4885-975E-298B8810757E@krvw.com> Greetings SC-L, So, I've always done my best to keep SC-L non-commercial since its inception in 2003. I'm curious, though, how you the readers would react to accepting sponsorships in the form of "sponsored by: " banners at the bottom of each posting. The banner presently points to the list, the list charter, along with a note saying that the list is hosted and moderated by my company. So, my question is this: could/should I accept sponsorships where the sponsor would get (say) two or three lines of text saying who they are and pointing to their web page? I welcome your candid/serious feedback on this. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080219/adaa67c7/attachment.bin From gem at cigital.com Tue Feb 19 15:06:32 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 19 Feb 2008 15:06:32 -0500 Subject: [SC-L] Silver Bullet 23 Message-ID: <41945506397C0C4886A8C5BFF089B5CA310388D23B@va-mailhub.cigital.com> Hi sc-l, Episode 23 of Silver Bullet just went up thid afternoon. In this episode, I have a conversation with Veracode founder and CTO Chris Wysopal (aka Weld Pond). We do lots of yabbering about software security as you might expect. Check it out: http://www.cigital.com/silverbullet/show-023/ Silver Bullet is co-sponsored by Cigital and IEEE Security & Privacy Magazine. Hope you like it! gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Mon Mar 3 16:39:39 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 3 Mar 2008 16:39:39 -0500 Subject: [SC-L] PCI: Boon or bust for software security? Message-ID: <264A9965-FFBB-4AA4-865F-87C96DE93FAC@krvw.com> Greetings SC-L, So here's a question to ponder. Now that PCI DSS 1.1 is out there (save a couple June 2008 deadlines still looming), has it been good or bad for software security as a whole? It does require secure development processes (as prescribed by OWASP). It does require sensitive cardholder data to be encrypted at rest and in transit. Has it improved the overall state of affairs, worsened it, or have things pretty much remained the same. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080303/0a939fd4/attachment.bin From eballen1 at qwest.net Mon Mar 3 19:06:38 2008 From: eballen1 at qwest.net (Bruce Ediger) Date: Mon, 3 Mar 2008 17:06:38 -0700 (MST) Subject: [SC-L] PCI: Boon or bust for software security? In-Reply-To: <264A9965-FFBB-4AA4-865F-87C96DE93FAC@krvw.com> References: <264A9965-FFBB-4AA4-865F-87C96DE93FAC@krvw.com> Message-ID: On Mon, 3 Mar 2008, Kenneth Van Wyk wrote: > So here's a question to ponder. Now that PCI DSS 1.1 is out there (save a > couple June 2008 deadlines still looming), has it been good or bad for > software security as a whole? It's a wash. And that only because PCI has mild good effects, to counteract "The Business" using it as a bludgeon to get some other concessions they want from various IT departments. Let's face it, current management and business practice is to regard all programmers as plug-compatible, and to put all their emphasis on the unattainable Holy Grail of "repeatable processes" (http://www.idiom.com/~zilla/Work/Softestim/softestim.html and http://www.idiom.com/~zilla/Work/kcsest.pdf). Maybe they need "repeatable processes" if they outsource to guys who can just barely spell "Java", but that's really another rant. In any case, the same management that puts all its faith in the prima facie nonsense of "repeatable processes" just did some checklist-style PCI remediation, implementing it without wisdom or imagination. Management, thy name is "CYA". They hired the minimum bid network scanners, who really didn't do much, but did turn in a spectacularly-well-formatted "Word" doc with lots of buzzwords in it. "The Business" put whatever effort is left over after plotting Corporate Domination (none) into understanding the PCI remediation checklist, and now believes that security is well taken care of, now and forever. PCI compliance is like boycotting gas stations for a day: that day's sales look pitiful, bu over the course of a week, it will all even out, since "compliance" gives "The Business" a false sense of security. From amurren at gmail.com Tue Mar 4 09:02:45 2008 From: amurren at gmail.com (Andy Murren) Date: Tue, 4 Mar 2008 09:02:45 -0500 Subject: [SC-L] PCI: Boon or bust for software security? In-Reply-To: References: <264A9965-FFBB-4AA4-865F-87C96DE93FAC@krvw.com> Message-ID: <346e8fa30803040602o33cf1c29o5558a60b7563396f@mail.gmail.com> Overall I concur with Bruce on this. PCI has too broad of a constituent base to cover to be truly effective. Some fixes were added after the TJX breach, but look at how much TJX paid versus how much the laid aside to pay. I am betting that the TJX lawyers produced documents showing that they were PCI compliant, and that Visa had accepted the annual findings. In the end TJX was able to claim that they were not negligent because they were PCI compliant. While PCI 1.1 points to OWASP for in house developed web applications, where are the standards for 'PCI Approved' vendor development? How secure is the development process at the middleware vendor that is part of that web app, how good are the standards those organizations use and are held to? I think until there is an industry wide generally accepts, and pushed, standard for integrating secure development into the SDLC we will see band aid approaches like the updated PCI. Andy From list-spam at secureconsulting.net Tue Mar 4 09:51:01 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 4 Mar 2008 09:51:01 -0500 (EST) Subject: [SC-L] PCI: Boon or bust for software security? In-Reply-To: <346e8fa30803040602o33cf1c29o5558a60b7563396f@mail.gmail.com> References: <264A9965-FFBB-4AA4-865F-87C96DE93FAC@krvw.com> <346e8fa30803040602o33cf1c29o5558a60b7563396f@mail.gmail.com> Message-ID: <65445.38.118.48.5.1204642261.squirrel@webmail.secureconsulting.net> Worse than that, I think that until businesses universally understand the value of secure coding practices, they will resist the up-front cost to take on such a transformational program. SOX vs PCI would make for a good case study. SOX is very high level and generic, which led to much confusion and wasted money initially. Some orgs were able to leverage it for the first year or two to drive improved security practices, but it seems that, for the most part, this leverage is gone. PCI, on the other hand, is for the most part quite specific (despite some ambiguity due to poor writing quality). It has primarily resulted in a checklist-oriented approach to "compliance" and has not seemingly led to transformational change, but rather many spot fixes. While it is still usable to leverage organizations, and it has moved the needle a little bit in terms of baseline security practices, overall I'd put it's effect on par with SOX. Thus, you have two sets of regulations that used very different approaches, but with very similar results: relative ineffectiveness. For me, this raises the question, Can regulation be used to stimulate the business to undertake transformational change to adopt and integrate holistic, pervasive security practices? The problem, I think, is that PCI is too easily relegated by the business to IT. This can be the case because PCI is technically specific. SOX, on the other hand, was not specific enough, and so eventually became almost dismissable by the business, eventually with minimal involvement from IT (perhaps a gross oversimplification). The key, then, seems to be in trying to construct requirements that will stick with the business instead of being easily delegated. Perhaps something risk-oriented would have the desired effect... fwiw. -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ "In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." Edward P. Tryon On Tue, March 4, 2008 09:02, Andy Murren wrote: > Overall I concur with Bruce on this. PCI has too broad of a > constituent base to cover to be truly effective. Some fixes were > added after the TJX breach, but look at how much TJX paid versus how > much the laid aside to pay. I am betting that the TJX lawyers > produced documents showing that they were PCI compliant, and that Visa > had accepted the annual findings. In the end TJX was able to claim > that they were not negligent because they were PCI compliant. While > PCI 1.1 points to OWASP for in house developed web applications, where > are the standards for 'PCI Approved' vendor development? How secure > is the development process at the middleware vendor that is part of > that web app, how good are the standards those organizations use and > are held to? > > I think until there is an industry wide generally accepts, and pushed, > standard for integrating secure development into the SDLC we will see > band aid approaches like the updated PCI. > > Andy > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From amurren at gmail.com Tue Mar 4 10:14:03 2008 From: amurren at gmail.com (Andy Murren) Date: Tue, 4 Mar 2008 10:14:03 -0500 Subject: [SC-L] Secure development after release Message-ID: <346e8fa30803040714o6e9fc013k63f9e87d80af1fbc@mail.gmail.com> Once an application is released or put into production, what are organizations doing to keep the applications secure? As new vulnerabilities and classes of exploits are released, how is that information being fed back to developers so they can update/patch in the software. At the network most organizations have a Network Operations Center (NOC) and some have a Security Operations Center (SOC) to look for problems and make changes to the network to defend against the problem. What is the equivalent at the software development level? Is there a formal method other than reacting to incidents? Is there a sort of Operations or Intelligence cell that proactively finds and processes new information and feeds that info back to the design and development teams so they can update the software? Andy From bugtraq at cgisecurity.net Tue Mar 4 14:03:42 2008 From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net) Date: Tue, 4 Mar 2008 14:03:42 -0500 (EST) Subject: [SC-L] Secure development after release In-Reply-To: <346e8fa30803040714o6e9fc013k63f9e87d80af1fbc@mail.gmail.com> Message-ID: <20080304190342.43569.qmail@cgisecurity.net> Hello Andy, > Once an application is released or put into production, what are > organizations doing to keep the applications secure? As new Some organizations purchase web application security scanners and perform periodic scanning (this could be done by the soc) or use a service such as whitehatsec to perform continuous application level scanning. It usually boils down to company resources, finding qualified people to configure/run a tool, and/or budget. If you're using a service ideally they should be identifying the false positives and removing them from your reporting. If you're using a tool you'll need someone qualified to be able to identify if an issue is real or not and remove it. For the sake of saying it no tool can find all issues and having a human/tool combination is really required. Tools do very poorly at logic flaws which are often the most damaging. For more critical applications (dealing with Personal Identifiable Information) or those dubbed risky one off deep dive pen tests may be needed in addition to continuous scanning/monitoring. This will depend on frequency of application changes, budget, and resources. > vulnerabilities and classes of exploits are released, how is that > information being fed back to developers so they can update/patch in > the software. At the network most organizations have a Network After the scanning is performed typically you'll have an assigned security resource (this could even be a QA/dev person depending on available resources) that files tickets with development (if this process isn't automated) to address each issue and owns the responsibility to follow-up on each discovery. Remediation timelines will vary depending on the flaw and unless their is a policy/management buy-in of some sort, forcing development to fix things in a given timeframe may be difficult. It is important to iron out the process regarding false positive identification otherwise development will take you less seriously when an issue is filed. > Is there a formal method other than reacting to incidents? Is there a Yes by proactively monitoring and testing your applications for 'security defects' (pen testing/security assessments). > sort of Operations or Intelligence cell that proactively finds and > processes new information and feeds that info back to the design and > development teams so they can update the software? > It is important to note that development people aren't security people and they never will be (no matter how much the security people want them to be). Sure they will get better and stop making certain mistakes over time but most developers aren't monitoring the usual security outlets for the latest threats to see if their code may be affected. It is typically the job of a security team (local, service, or SOC) or auditing team (regarding compliance e.g PCI/SOX) to ensure that a given application is reviewed against the latest threats at the time of the evaluation. Depending on your setup a SOC may handle monitoring/incident response and scanning. Hope this helps. Regards, - Robert http://www.cgisecurity.com/ Application Security news and more http://www.webappsec.org/ The Web Application Security Consortium http://www.qasec.com/ Software Security Testing From koved at us.ibm.com Wed Mar 5 17:11:11 2008 From: koved at us.ibm.com (Larry Koved) Date: Wed, 5 Mar 2008 17:11:11 -0500 Subject: [SC-L] CFP: W2SP 2008: Web 2.0 Security and Privacy 2008 Message-ID: This is a workshop that may be of interest to subscribers of this mailing list. This is a gentle reminder that the position statements / papers are due this Friday. Our keynote speaker will be Niels Provos, presenting "All Your iFrames Point to Us." Hope to see you at the workshop! Larry Koved and Dan Wallach W2SP 2008 co-chairs ---------------------------------------------------------------------------------- CFP: http://seclab.cs.rice.edu/w2sp/2008/cfp.html Workshop web site: http://seclab.cs.rice.edu/w2sp/2008/ 2007 workshop web site: http://seclab.cs.rice.edu/w2sp/2007/ Workshop Call for Position Papers W2SP 2008: Web 2.0 Security and Privacy 2008 Thursday, May 22 The Claremont Resort Oakland, California Sponsored by the 2008 IEEE Symposium on Security and Privacy The goal of this one day workshop is to bring together researchers and practitioners from academia and industry to focus on understanding Web 2.0 security and privacy issues, and establishing new collaborations in these areas. Web 2.0 is about connecting people and amplifying the power of working together. The mixing of technology and social interaction is occurring in the context of a wave of technologies supporting rapid development of these interpersonal and business interactions. Many of the new web technologies rely on the composition of content and services from multiple sources, resulting in complex technology compositions (mash-ups). The content composition trend is likely to continue. The lure of these technologies is the promise of simpler ways to compose software service and content, at lower cost. However, there are issues with respect to management of identities, reputation, privacy, anonymity, transient and long term relationships, and composition of function and content, both on the server side and at the client (web browser). While the security and privacy issues are not new, these issues are increasingly becoming acute as the technologies are adopted and adapted to appeal to wider audiences. Some of these technologies deliberately bypass existing security mechanisms. This workshop is intended to discuss the limitations of the current technologies and explore alternatives. The scope of W2SP 2008 includes, but is not limited to: - Identity, privacy, reputation and anonymity - End-to-end security architectures - Security of content composition - Security and privacy policy definition and modeling of content composition - Provenance and governance - Usable security and privacy models - Static and dynamic analysis for security - Security as a service - Click fraud - Software as a service - Web services/feeds/mashups - Next generation browser technology Due to space limitations of the workshop venue, registration is limited to 75 participants. Potential workshop participants should submit a paper on topics relevant to Web 2.0 security and privacy issues. We are seeking both short position papers (2-?4 pages) and refereed papers (a maximum of 8 pages). Papers longer than 8 pages may be automatically rejected by the co-chairs or workshop committee. From the submissions, the program committee will strive to select participants in a way that is balanced between academia and industry, as well as across topics. Selected papers will appear on the workshop web site. Workshop Co-Chairs: W2SP2008 at ieee-security.org - Larry Koved, IBM T. J. Watson Research Center - Dan S. Wallach, Rice University Important dates: - Paper submission deadline: March 7, 2008, (11:59pm US-Eastern) - Workshop acceptance notification date: March 28, 2008 - Workshop date: Thursday May 22, 2008 - Workshop paper submission web site: http://continue2.cs.brown.edu/W2SP08/ - Registration: Workshop registration will only be available via the 2008 IEEE Symposium on Security and Privacy conference web site. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080305/2e8c3e51/attachment.html From david.l.lawson at lmco.com Fri Mar 7 08:45:30 2008 From: david.l.lawson at lmco.com (Lawson, David L) Date: Fri, 07 Mar 2008 08:45:30 -0500 Subject: [SC-L] Secure Coding Books In-Reply-To: References: Message-ID: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> I've read several secure coding books in the past, and was wondering if anyone has recommendations for secure coding books (preferably from the last year or two). Thanks, David Lawson From goertzel_karen at bah.com Fri Mar 7 10:56:27 2008 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 7 Mar 2008 10:56:27 -0500 Subject: [SC-L] Secure Coding Books References: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> Message-ID: <184D5FFC5203644FB4F8864B0EE445B401F4A0D8@MCLNEXVS06.resource.ds.bah.com> Do you really mean "secure coding" only, or are you looking for books on "secure software development" more generally? -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.902.6981 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of Lawson, David L Sent: Fri 07-Mar-08 08:45 To: sc-l at securecoding.org Subject: [SC-L] Secure Coding Books I've read several secure coding books in the past, and was wondering if anyone has recommendations for secure coding books (preferably from the last year or two). Thanks, David Lawson _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080307/66e3e096/attachment.html From jim at manico.net Fri Mar 7 10:40:03 2008 From: jim at manico.net (Jim Manico) Date: Fri, 7 Mar 2008 09:40:03 -0600 Subject: [SC-L] Secure Coding Books In-Reply-To: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> References: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> Message-ID: <1683963C-D65C-49A3-AC2F-801DB71D410C@manico.net> "How to break web software" is one of the best web security coder- centric books I have read. Its concise and useful. Sent from my iPhone On Mar 7, 2008, at 7:45 AM, "Lawson, David L" wrote: > I've read several secure coding books in the past, and was wondering > if > anyone has recommendations for secure coding books (preferably from > the > last year or two). > > Thanks, > > David Lawson > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ From daswani at cs.stanford.edu Fri Mar 7 12:31:24 2008 From: daswani at cs.stanford.edu (Neil Daswani) Date: Fri, 7 Mar 2008 09:31:24 -0800 Subject: [SC-L] Secure Coding Books In-Reply-To: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> References: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> Message-ID: Hi David, There is a list of software security / secure coding books at: http://www.sans-ssi.org/references.php Gary McGraw has a blog post in which some of these references are chronologically ordered at: http://www.cigital.com/justiceleague/2007/04/23/software-security-now-2006-shows-impressive-growth/ If you're interested in secure coding for web applications, there is also a list at: http://www.webappsec.org/web_security_books.shtml In the interest of disclosure, my own contribution (http://tinyurl.com/33xs6g) which was published last year, is listed on these pages as well. I hope that some of the links above can help you find what you need. Sincerely, Neil Daswani, PhD http://www.neildaswani.com My book, "Foundations of Security: What Every Programmer Needs To Know" is available at http://tinyurl.com/33xs6g On Fri, Mar 7, 2008 at 5:45 AM, Lawson, David L wrote: > I've read several secure coding books in the past, and was wondering if > anyone has recommendations for secure coding books (preferably from the > last year or two). > > Thanks, > > David Lawson > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- From dean at fullfrontalnerdity.com Fri Mar 7 13:25:43 2008 From: dean at fullfrontalnerdity.com (Dean H. Saxe) Date: Fri, 7 Mar 2008 13:25:43 -0500 Subject: [SC-L] Secure Coding Books In-Reply-To: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> References: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> Message-ID: I'd check out "Security: What Every Programmer Needs to Know" by Daswani, Kern and Kesavan. I haven't read it cover to cover yet, but it seems to cover the topics in a nice amount of detail. -dhs Dean H. Saxe, CISSP, CEH dean at fullfrontalnerdity.com "Great spirits have often encountered violent opposition from weak minds." --Einstein On Mar 7, 2008, at 8:45 AM, Lawson, David L wrote: > I've read several secure coding books in the past, and was wondering > if > anyone has recommendations for secure coding books (preferably from > the > last year or two). > > Thanks, > > David Lawson > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080307/c553aab2/attachment.html From rcs at cert.org Fri Mar 7 13:17:22 2008 From: rcs at cert.org (Robert C. Seacord) Date: Fri, 07 Mar 2008 13:17:22 -0500 Subject: [SC-L] Secure Coding Books In-Reply-To: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> References: <3D5F7079BAF2F24CA3187EEBF32508C2132DCA22@emss04m02.us.lmco.com> Message-ID: <47D186B2.5020603@cert.org> David, I like "Secure Coding in C and C++" (http://www.cert.org/books/secure-coding/) The guy who wrote it is a bit of a jerk, but it has a lot of good technical information. Another book I like is The Art of Software Security Assessment (http://taossa.com/). rCs > I've read several secure coding books in the past, and was wondering if > anyone has recommendations for secure coding books (preferably from the > last year or two). > > Thanks, > > David Lawson > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080307/54a7724c/attachment.html From seba at deleersnyder.eu Sat Mar 8 05:29:08 2008 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Sat, 8 Mar 2008 11:29:08 +0100 Subject: [SC-L] Secure Coding Books In-Reply-To: <1683963C-D65C-49A3-AC2F-801DB71D410C@manico.net> Message-ID: <6kft63$33s3to@relay.skynet.be> There is a list on http://www.owasp.org/index.php/Education_Module_Good_WebAppSec_Resources I am currently reading a "Secure Programming with Statical Analysi" which I like. Regards Seba -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico Sent: vrijdag 7 maart 2008 16:40 To: Lawson, David L Cc: sc-l at securecoding.org Subject: Re: [SC-L] Secure Coding Books "How to break web software" is one of the best web security coder- centric books I have read. Its concise and useful. Sent from my iPhone On Mar 7, 2008, at 7:45 AM, "Lawson, David L" wrote: > I've read several secure coding books in the past, and was wondering > if > anyone has recommendations for secure coding books (preferably from > the > last year or two). > > Thanks, > > David Lawson > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.6/1317 - Release Date: 7/03/2008 8:15 From gem at cigital.com Mon Mar 10 15:35:08 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 10 Mar 2008 16:35:08 -0400 Subject: [SC-L] Secure Coding Books In-Reply-To: <6kft63$33s3to@relay.skynet.be> Message-ID: Hi all, I am the editor of the Addison-Wesley Software Security Series. It includes the Chess/West book "Secure Programming with Static Analysis" as well as a bunch of other books. You can learn about the series here: http://www.buildingsecurityin.com/ Or on Amazon (though this list is missing "Building Secure Software"): http://www.amazon.com/gp/series/93344/ref=pd_serl_books?ie=UTF8&edition=paperback I am always on the lookout for new books for the series. In particular, I would like to see some good books created on software security testing, software security requirements, abuse/misuse cases, architectural risk analysis, and possibly even penetration testing. Who wants to write a book for Addison-Wesley? Together with SEI/CERT, a new book in the series is almost ready for release. See more about "Software Security Engineering" here: http://www.amazon.com/Software-Security-Engineering-Project-Managers/dp/032150917X/ref=sr_1_1?ie=UTF8&s=books&qid=1205180964&sr=1-1 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 3/8/08 6:29 AM, "Sebastien Deleersnyder" wrote: There is a list on http://www.owasp.org/index.php/Education_Module_Good_WebAppSec_Resources I am currently reading a "Secure Programming with Statical Analysi" which I like. Regards Seba -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico Sent: vrijdag 7 maart 2008 16:40 To: Lawson, David L Cc: sc-l at securecoding.org Subject: Re: [SC-L] Secure Coding Books "How to break web software" is one of the best web security coder- centric books I have read. Its concise and useful. Sent from my iPhone On Mar 7, 2008, at 7:45 AM, "Lawson, David L" wrote: > I've read several secure coding books in the past, and was wondering > if > anyone has recommendations for secure coding books (preferably from > the > last year or two). > > Thanks, > > David Lawson > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.6/1317 - Release Date: 7/03/2008 8:15 _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From list-spam at secureconsulting.net Tue Mar 11 08:43:16 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 11 Mar 2008 09:43:16 -0400 (EDT) Subject: [SC-L] quick question - SXSW Message-ID: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> I had just a quick query for everyone out there, with an attached thought. How many security and/or secure coding professionals are prevalently involved with the SXSW conference this week? I know, I know... it's a big party for developers - particularly the Web 2.0 clique - but I'm just curious. Here's why: I'm increasingly frustrated by the disconnect between business/dev and security. I don't feel like we're being largely successful in getting the business and developers to include security as part of their standard operating procedures. Developers are still oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection holes. I then look at SXSW from afar and think: a) shouldn't I be there evangelizing security? and, b) shouldn't a major thread to all these conferences be about how security is integrating with dev processes and practices, making it better? Maybe I'm just too idealist. I'm curious what everyone else thinks. cheers, -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ "In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." Edward P. Tryon From amurren at gmail.com Tue Mar 11 11:20:26 2008 From: amurren at gmail.com (Andy Murren) Date: Tue, 11 Mar 2008 12:20:26 -0400 Subject: [SC-L] implementable process level secure development thoughts Message-ID: <346e8fa30803110920k6c8a91b2rc4c56c19ea18e394@mail.gmail.com> I have been working on developing a series of documents to turn the ideas encompassed on this list and in what I can find in books & articles. I am not finding, and it may just be I am looking in the wrong places, for any information on how people are actually implementing the concepts. I have found the high level ideas (like in "Software Security" and the MS SDL) and the low level code level rules, but there does not seem to be any information on how these two are being merged and used in actual development projects. Are there any non-proprietary materials out there? If there are none, could this be part of the problem of getting secure development/design/testing/coding out into the real world? Thanks, Andy From gem at cigital.com Tue Mar 11 12:01:34 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 11 Mar 2008 13:01:34 -0400 Subject: [SC-L] implementable process level secure development thoughts In-Reply-To: <346e8fa30803110920k6c8a91b2rc4c56c19ea18e394@mail.gmail.com> Message-ID: Hi Andy, We build and then execute plans to do that kind of activity all the time at Cigital. Unfortunately, the plans are all highly tailored to the politics and operations of our specific customers, and they are proprietary. Basically they do involve several aspects in common if you step way back and squint: * roles and responsibilities for disparate groups * a rollout plan for different touchpoints (including tools) * a portal for secdev data (guidelines, rules, tool usage data, ...) * a training program with ties to HR and advancement * legal guidance and assurance case plans for legacy and COTS software A plan for a large scale software security initiative usually encompasses activities slated to span several years. We have rolled them out in multi-national enterprises with over 10,000 developers. Measurement helps. Check out chapter 10 in "Software Security" for slightly more. Hope that helps. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 3/11/08 12:20 PM, "Andy Murren" wrote: I have been working on developing a series of documents to turn the ideas encompassed on this list and in what I can find in books & articles. I am not finding, and it may just be I am looking in the wrong places, for any information on how people are actually implementing the concepts. I have found the high level ideas (like in "Software Security" and the MS SDL) and the low level code level rules, but there does not seem to be any information on how these two are being merged and used in actual development projects. Are there any non-proprietary materials out there? If there are none, could this be part of the problem of getting secure development/design/testing/coding out into the real world? Thanks, Andy _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From roman.hustad at yahoo.com Tue Mar 11 13:40:28 2008 From: roman.hustad at yahoo.com (Roman H.) Date: Tue, 11 Mar 2008 11:40:28 -0700 (PDT) Subject: [SC-L] implementable process level secure development thoughts Message-ID: <389408.48733.qm@web32404.mail.mud.yahoo.com> Andy, I think this is a really good question. I am not aware of any comprehensive non-proprietary materials that are available, although I know lots of companies have developed this sort of thing either internally or with the help of a consultancy (full disclosure: I'm a consultant). I would agree with you that the apparent lack of concrete examples is probably hindering the spread of software security in the real world. In my experience, the actual software security processes that are implemented at a company need to be specifically tailored to fit with existing processes (i.e. SDLC, build and release) and technologies (e.g. CVS, Ant, testing tools, project management tools). Because each company has a unique combination of processes/tools and even individual projects may have varying tolerance for risk and compliance requirements, there is no "standard" way of doing it. That said, I think one or more case studies would be really helpful if they included things like: - source control branching to enforce code reviews and testing - change control - organization of the software security team - sanitizing sensitive production data for development - quick and dirty risk prioritization of applications - metrics Some of this is already out there. Things like threat modeling and penetration testing already have well documented methodologies so you could probably skip the detail for them. Gary McGraw just recently mentioned that he is looking for people to author books that provide this level of detail, so perhaps you could collaborate with him and get your documents published. OWASP and the DHS Build Security In project are other options. Can you provide the list with more detail about the particular topics you are writing about? Roman Hustad Andy Murren wrote: I have been working on developing a series of documents to turn the ideas encompassed on this list and in what I can find in books & articles. I am not finding, and it may just be I am looking in the wrong places, for any information on how people are actually implementing the concepts. I have found the high level ideas (like in "Software Security" and the MS SDL) and the low level code level rules, but there does not seem to be any information on how these two are being merged and used in actual development projects. Are there any non-proprietary materials out there? If there are none, could this be part of the problem of getting secure development/design/testing/coding out into the real world? Thanks, Andy _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080311/4217c182/attachment.html From amurren at gmail.com Tue Mar 11 14:05:01 2008 From: amurren at gmail.com (Andy Murren) Date: Tue, 11 Mar 2008 15:05:01 -0400 Subject: [SC-L] implementable process level secure development thoughts In-Reply-To: <389408.48733.qm@web32404.mail.mud.yahoo.com> References: <389408.48733.qm@web32404.mail.mud.yahoo.com> Message-ID: <346e8fa30803111205w6e574780s586b00f483cb2f99@mail.gmail.com> Roman, My starting point is sort of simple, how to weave secure development into the basic SDLC. I am assuming that regardless of what you call the steps most folks use a multi step process. Working with a 5 step process (Plan, Design, Develop, Test, Deploy) what is added to each of those steps. A lot of focus in on the Develop and Test steps with code standards and static code analysis tools. There is some higher level work at the Plan and Design stages, and there does not seem to be much at the Deploy. The post-deployment maintenance is barely covered in the reading I have done to date. I have a lot of questions about each step, here are a few: o During development and in post-deployment how does new information about threats gets tracked and added to the designers/developers knowledge base to both correct current mistakes and to avoid making mistakes in the future? o What are good metrics for measuring success that are objective and can be tracked in a meaningful way for bill payers? o When you add an application (third party or internally developed) to your network, what is an objective way of determining the actual security threat to your infrastructure? o What is the thinking on the tools to use to make sure important requirements, be they external legally mandated or internal standards, are included at the design phase? Are people using the Security Requirements Traceability Matix (SRTM) from DoD or are they using something else? This is just an example of the many things I am wondering about. I am in the same position and many on not being in a position to reveal company secrets, but I am looking to learn from experience of others and having an on going discussion on what seems to me to be the next logical step in the maturation of this field. I would like to thank everyone for their feed back so far on this topic, Andy From Kevin.Wall at qwest.com Tue Mar 11 14:39:40 2008 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Tue, 11 Mar 2008 14:39:40 -0500 Subject: [SC-L] implementable process level secure development thoughts In-Reply-To: <346e8fa30803110920k6c8a91b2rc4c56c19ea18e394@mail.gmail.com> References: <346e8fa30803110920k6c8a91b2rc4c56c19ea18e394@mail.gmail.com> Message-ID: Andy, You wrote... > I have been working on developing a series of documents to turn the > ideas encompassed on this list and in what I can find in books & > articles. I am not finding, and it may just be I am looking in the > wrong places, for any information on how people are actually > implementing the concepts. I have found the high level ideas (like in > "Software Security" and the MS SDL) and the low level code level > rules, but there does not seem to be any information on how these two > are being merged and used in actual development projects. Are there > any non-proprietary materials out there? > > If there are none, could this be part of the problem of getting secure > development/design/testing/coding out into the real world? Not sure what you are exactly looking for, but I recently reviewed the book Integrating Security and Software Engineering: Advances and Future Vision, Mouratidis H., Giorgini P., IGI Global, 2006, ISBN-10: 1599041480, ISBN-13: 978-1599041483. for Computing Reviews. (Review was posted online a 2 or 3 weeks ago. Not sure if it's still up or not.) The cost for the book on Amazon.com is ~$80. This book covered some of the "gaps" that you may be referring to. E.g., it covered quite a few secure design methodologies and how they (more or less) fit into an SDLC. NOTE: This book is very academic in nature and difficult reading and does not truly reflect current _practice_. However, it has a excellent bibliography that is useful if you wish to explore the topics more deeply. Can't really say much more about this (at least in a public forum) because Computing Reviews (http://www.reviews.com/) owns the copyright of the review. Contact me off-list if you want any specific question answered regarding this book. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. Kevin.Wall at qwest.com Phone: 614.215.4788 "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration" - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Jason.Bennett at thales-esecurity.com Wed Mar 12 04:32:08 2008 From: Jason.Bennett at thales-esecurity.com (Bennett, Jason) Date: Wed, 12 Mar 2008 09:32:08 -0000 Subject: [SC-L] Secure Coding Books Message-ID: Hi All, With all the questions about what are good books are there any views on actually implementing the principles i.e. using them on real programmes to drive security improvement. In particular the contrast between exisitng programmes and new programmes? Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmaster at thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited". From band at acm.org Wed Mar 12 11:40:22 2008 From: band at acm.org (William L. Anderson) Date: Wed, 12 Mar 2008 11:40:22 -0500 Subject: [SC-L] quick question - SXSW In-Reply-To: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> Message-ID: <47D80776.6030602@acm.org> Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I did not see many discussions that pay attention to security, or any other software engineering oriented concerns, explicitly. There was a discussion of scalability for web services that featured the developers from digg, Flickr, WordPress, and Media Temple. I got there about half-way through but the discussion with the audience was about tools and methods to handle high traffic loads. There was a question about build and deployment strategies and I asked about unit testing (mixed answers - some love it, some think it's strong-arm micro-mgt (go figure)). There was a session on OpenID and OAuth (open authorization) standards and implementation. These discussions kind of assume the use of secure transports but since I couldn't stay the whole time I don't know if secure coding was addressed explicitly. The main developer attendees at SXSW would call themselves designers and I would guess many of them are doing web development in PHP, Ruby, etc. I think the majority of attendees would not classify themselves as software programmers. To me it seems very much like at craft culture. That doesn't mean that a track on how to develop secure web services wouldn't be popular. In fact it might be worth proposing one for next year. If you want to talk further, please get in touch. -Bill Anderson praxis101.com Benjamin Tomhave wrote: > I had just a quick query for everyone out there, with an attached thought. > > How many security and/or secure coding professionals are prevalently > involved with the SXSW conference this week? I know, I know... it's a big > party for developers - particularly the Web 2.0 clique - but I'm just > curious. > > Here's why: I'm increasingly frustrated by the disconnect between > business/dev and security. I don't feel like we're being largely > successful in getting the business and developers to include security as > part of their standard operating procedures. Developers are still > oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection holes. > > I then look at SXSW from afar and think: a) shouldn't I be there > evangelizing security? and, b) shouldn't a major thread to all these > conferences be about how security is integrating with dev processes and > practices, making it better? > > Maybe I'm just too idealist. I'm curious what everyone else thinks. > > cheers, > > -ben > From list-spam at secureconsulting.net Wed Mar 12 16:31:50 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 12 Mar 2008 17:31:50 -0400 Subject: [SC-L] quick question - SXSW In-Reply-To: <47D80776.6030602@acm.org> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> Message-ID: <47D84BC6.4020608@secureconsulting.net> First, thanks for that Bill, it exemplifies my point perfectly. A couple thoughts... one, targeting designers is just as important as reaching out to the developers themselves... if the designers can ensure that security requirements are incorporated from the outset, then we receive an added benefit... two, a re-phrasing around my original thought... somehow we need to get security thinking and considerations encoded into the DNA of everyone in the business, whether they be designers, architects, coders, analysts, PMs, sysadmins, etc, etc, etc. Every one of those topics you mention could (should!) have had implicit and explicit security attributes included... yet we're still at the point where secure coding has to be explicitly requested/demanded (often as an afterthought or bolt-on)... How do we as infosec professionals get people to the next phase of including security thoughts in everything they do... with the end-goal being that it is then integrated fully into practices and processes as a bona fide genetic mutation that is passed along to future generations? To me, this seems to be where infosec is stuck as an industry. There seems to be a need for a catalyst to spur the mutation so that it can have a life of its own. :) fwiw. -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Augustine's Second Law of Socioscience: "For every scientific (or engineering) action, there is an equal and opposite social reaction." http://globalnerdy.com/2007/07/18/laws-of-software-development/ William L. Anderson wrote: > Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I > did not see many discussions that pay attention to security, or any > other software engineering oriented concerns, explicitly. > > There was a discussion of scalability for web services that featured the > developers from digg, Flickr, WordPress, and Media Temple. I got there > about half-way through but the discussion with the audience was about > tools and methods to handle high traffic loads. There was a question > about build and deployment strategies and I asked about unit testing > (mixed answers - some love it, some think it's strong-arm micro-mgt (go > figure)). > > There was a session on OpenID and OAuth (open authorization) standards > and implementation. These discussions kind of assume the use of secure > transports but since I couldn't stay the whole time I don't know if > secure coding was addressed explicitly. > > The main developer attendees at SXSW would call themselves designers and > I would guess many of them are doing web development in PHP, Ruby, etc. > I think the majority of attendees would not classify themselves as > software programmers. > > To me it seems very much like at craft culture. That doesn't mean that a > track on how to develop secure web services wouldn't be popular. In fact > it might be worth proposing one for next year. > > If you want to talk further, please get in touch. > > -Bill Anderson > praxis101.com > > Benjamin Tomhave wrote: >> I had just a quick query for everyone out there, with an attached >> thought. >> >> How many security and/or secure coding professionals are prevalently >> involved with the SXSW conference this week? I know, I know... it's a big >> party for developers - particularly the Web 2.0 clique - but I'm just >> curious. >> >> Here's why: I'm increasingly frustrated by the disconnect between >> business/dev and security. I don't feel like we're being largely >> successful in getting the business and developers to include security as >> part of their standard operating procedures. Developers are still >> oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection >> holes. >> >> I then look at SXSW from afar and think: a) shouldn't I be there >> evangelizing security? and, b) shouldn't a major thread to all these >> conferences be about how security is integrating with dev processes and >> practices, making it better? >> >> Maybe I'm just too idealist. I'm curious what everyone else thinks. >> >> cheers, >> >> -ben >> > > From steingra at gmail.com Wed Mar 12 17:05:53 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Wed, 12 Mar 2008 15:05:53 -0700 Subject: [SC-L] quick question - SXSW In-Reply-To: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> Message-ID: <490a979e0803121505w4d3ee137vfe58205d359476a2@mail.gmail.com> On Tue, Mar 11, 2008 at 6:43 AM, Benjamin Tomhave wrote: > I had just a quick query for everyone out there, with an attached thought. > > How many security and/or secure coding professionals are prevalently > involved with the SXSW conference this week? I know, I know... it's a big > party for developers - particularly the Web 2.0 clique - but I'm just > curious. > On a related note a quick perusal of the JavaOne conference tracks doesn't show a lot of content in this area either. Is this due to a lack of interest, or people in the security world not pitching talks to the development conference organizer? -- Andy Steingruebl steingra at gmail.com From ken at krvw.com Wed Mar 12 17:34:24 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 12 Mar 2008 18:34:24 -0400 Subject: [SC-L] quick question - SXSW In-Reply-To: <47D84BC6.4020608@secureconsulting.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> Message-ID: Ben, Your point is a good one -- the software security community needs to be vigilant in reaching out to developers and spreading "the word". FWIW, some dev conferences have done this. I spoke at SD West in 2006, and there was a significant security track there. Still, it'd be great to see that sort of thing at more dev-specific conferences. Cheers, Ken van Wyk SC-L Moderator On Mar 12, 2008, at 5:31 PM, Benjamin Tomhave wrote: > First, thanks for that Bill, it exemplifies my point perfectly. A > couple > thoughts... > > one, targeting designers is just as important as reaching out to the > developers themselves... if the designers can ensure that security > requirements are incorporated from the outset, then we receive an > added > benefit... > > two, a re-phrasing around my original thought... somehow we need to > get > security thinking and considerations encoded into the DNA of > everyone in > the business, whether they be designers, architects, coders, analysts, > PMs, sysadmins, etc, etc, etc. Every one of those topics you mention > could (should!) have had implicit and explicit security attributes > included... yet we're still at the point where secure coding has to be > explicitly requested/demanded (often as an afterthought or bolt-on)... > > How do we as infosec professionals get people to the next phase of > including security thoughts in everything they do... with the end-goal > being that it is then integrated fully into practices and processes > as a > bona fide genetic mutation that is passed along to future generations? > > To me, this seems to be where infosec is stuck as an industry. There > seems to be a need for a catalyst to spur the mutation so that it can > have a life of its own. :) > > fwiw. > > -ben > > -- > Benjamin Tomhave, MS, CISSP > falcon at secureconsulting.net > LI: http://www.linkedin.com/in/btomhave > Blog: http://www.secureconsulting.net/ > Photos: http://photos.secureconsulting.net/ > Web: http://falcon.secureconsulting.net/ > > [ Random Quote: ] > Augustine's Second Law of Socioscience: "For every scientific (or > engineering) action, there is an equal and opposite social reaction." > http://globalnerdy.com/2007/07/18/laws-of-software-development/ > > William L. Anderson wrote: >> Dear Ben, having just been at SXSW Interactive (I live in Austin, >> TX) I >> did not see many discussions that pay attention to security, or any >> other software engineering oriented concerns, explicitly. >> >> There was a discussion of scalability for web services that >> featured the >> developers from digg, Flickr, WordPress, and Media Temple. I got >> there >> about half-way through but the discussion with the audience was about >> tools and methods to handle high traffic loads. There was a question >> about build and deployment strategies and I asked about unit testing >> (mixed answers - some love it, some think it's strong-arm micro-mgt >> (go >> figure)). >> >> There was a session on OpenID and OAuth (open authorization) >> standards >> and implementation. These discussions kind of assume the use of >> secure >> transports but since I couldn't stay the whole time I don't know if >> secure coding was addressed explicitly. >> >> The main developer attendees at SXSW would call themselves >> designers and >> I would guess many of them are doing web development in PHP, Ruby, >> etc. >> I think the majority of attendees would not classify themselves as >> software programmers. >> >> To me it seems very much like at craft culture. That doesn't mean >> that a >> track on how to develop secure web services wouldn't be popular. In >> fact >> it might be worth proposing one for next year. >> >> If you want to talk further, please get in touch. >> >> -Bill Anderson >> praxis101.com >> >> Benjamin Tomhave wrote: >>> I had just a quick query for everyone out there, with an attached >>> thought. >>> >>> How many security and/or secure coding professionals are prevalently >>> involved with the SXSW conference this week? I know, I know... >>> it's a big >>> party for developers - particularly the Web 2.0 clique - but I'm >>> just >>> curious. >>> >>> Here's why: I'm increasingly frustrated by the disconnect between >>> business/dev and security. I don't feel like we're being largely >>> successful in getting the business and developers to include >>> security as >>> part of their standard operating procedures. Developers are still >>> oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection >>> holes. >>> >>> I then look at SXSW from afar and think: a) shouldn't I be there >>> evangelizing security? and, b) shouldn't a major thread to all these >>> conferences be about how security is integrating with dev >>> processes and >>> practices, making it better? >>> >>> Maybe I'm just too idealist. I'm curious what everyone else thinks. >>> >>> cheers, >>> >>> -ben >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2500 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080312/82d3b08e/attachment.bin From yo at secappdev.org Wed Mar 12 17:56:58 2008 From: yo at secappdev.org (Johan Peeters) Date: Wed, 12 Mar 2008 23:56:58 +0100 Subject: [SC-L] quick question - SXSW In-Reply-To: References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> Message-ID: <25b6e5cf0803121556k34c4ee53pcb565bb52938d039@mail.gmail.com> I agree. Reaching the development community, that's precisely what we are trying to do at secappdev. Thanks for helping with that too, Ken. I have also taken some security-related sessions to conferences such as XP Days Benelux, XP Days France and SPA. Appearing soon at ACCU. I would love to hear from anyone else in this niche. kr, Yo On 3/12/08, Kenneth Van Wyk wrote: > Ben, > > Your point is a good one -- the software security community needs to > be vigilant in reaching out to developers and spreading "the word". > > FWIW, some dev conferences have done this. I spoke at SD West in > 2006, and there was a significant security track there. Still, it'd > be great to see that sort of thing at more dev-specific conferences. > > Cheers, > > Ken van Wyk > SC-L Moderator > > On Mar 12, 2008, at 5:31 PM, Benjamin Tomhave wrote: > > > First, thanks for that Bill, it exemplifies my point perfectly. A > > couple > > thoughts... > > > > one, targeting designers is just as important as reaching out to the > > developers themselves... if the designers can ensure that security > > requirements are incorporated from the outset, then we receive an > > added > > benefit... > > > > two, a re-phrasing around my original thought... somehow we need to > > get > > security thinking and considerations encoded into the DNA of > > everyone in > > the business, whether they be designers, architects, coders, analysts, > > PMs, sysadmins, etc, etc, etc. Every one of those topics you mention > > could (should!) have had implicit and explicit security attributes > > included... yet we're still at the point where secure coding has to be > > explicitly requested/demanded (often as an afterthought or bolt-on)... > > > > How do we as infosec professionals get people to the next phase of > > including security thoughts in everything they do... with the end-goal > > being that it is then integrated fully into practices and processes > > as a > > bona fide genetic mutation that is passed along to future generations? > > > > To me, this seems to be where infosec is stuck as an industry. There > > seems to be a need for a catalyst to spur the mutation so that it can > > have a life of its own. :) > > > > fwiw. > > > > -ben > > > > -- > > Benjamin Tomhave, MS, CISSP > > falcon at secureconsulting.net > > LI: http://www.linkedin.com/in/btomhave > > Blog: http://www.secureconsulting.net/ > > Photos: http://photos.secureconsulting.net/ > > Web: http://falcon.secureconsulting.net/ > > > > [ Random Quote: ] > > Augustine's Second Law of Socioscience: "For every scientific (or > > engineering) action, there is an equal and opposite social reaction." > > http://globalnerdy.com/2007/07/18/laws-of-software-development/ > > > > William L. Anderson wrote: > >> Dear Ben, having just been at SXSW Interactive (I live in Austin, > >> TX) I > >> did not see many discussions that pay attention to security, or any > >> other software engineering oriented concerns, explicitly. > >> > >> There was a discussion of scalability for web services that > >> featured the > >> developers from digg, Flickr, WordPress, and Media Temple. I got > >> there > >> about half-way through but the discussion with the audience was about > >> tools and methods to handle high traffic loads. There was a question > >> about build and deployment strategies and I asked about unit testing > >> (mixed answers - some love it, some think it's strong-arm micro-mgt > >> (go > >> figure)). > >> > >> There was a session on OpenID and OAuth (open authorization) > >> standards > >> and implementation. These discussions kind of assume the use of > >> secure > >> transports but since I couldn't stay the whole time I don't know if > >> secure coding was addressed explicitly. > >> > >> The main developer attendees at SXSW would call themselves > >> designers and > >> I would guess many of them are doing web development in PHP, Ruby, > >> etc. > >> I think the majority of attendees would not classify themselves as > >> software programmers. > >> > >> To me it seems very much like at craft culture. That doesn't mean > >> that a > >> track on how to develop secure web services wouldn't be popular. In > >> fact > >> it might be worth proposing one for next year. > >> > >> If you want to talk further, please get in touch. > >> > >> -Bill Anderson > >> praxis101.com > >> > >> Benjamin Tomhave wrote: > >>> I had just a quick query for everyone out there, with an attached > >>> thought. > >>> > >>> How many security and/or secure coding professionals are prevalently > >>> involved with the SXSW conference this week? I know, I know... > >>> it's a big > >>> party for developers - particularly the Web 2.0 clique - but I'm > >>> just > >>> curious. > >>> > >>> Here's why: I'm increasingly frustrated by the disconnect between > >>> business/dev and security. I don't feel like we're being largely > >>> successful in getting the business and developers to include > >>> security as > >>> part of their standard operating procedures. Developers are still > >>> oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection > >>> holes. > >>> > >>> I then look at SXSW from afar and think: a) shouldn't I be there > >>> evangelizing security? and, b) shouldn't a major thread to all these > >>> conferences be about how security is integrating with dev > >>> processes and > >>> practices, making it better? > >>> > >>> Maybe I'm just too idealist. I'm curious what everyone else thinks. > >>> > >>> cheers, > >>> > >>> -ben > >>> > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > -- Johan Peeters http://johanpeeters.com From arian.evans at anachronic.com Wed Mar 12 18:07:01 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Wed, 12 Mar 2008 16:07:01 -0700 Subject: [SC-L] quick question - SXSW In-Reply-To: <47D84BC6.4020608@secureconsulting.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> Message-ID: So two thoughts Ben, purely my 0.02 USD: 1. This is largely the wrong crowd. Designers of small web2.0 stuffs, particularly the domain of widgets and WS interfaces for all the usual suspect platforms (flickr, facebook etc.) as well as most startups: They just don't care. They will never care. SXSW has "* long tail" and "* design pattern" 2007 buzzword compliant presentations. You could probably get a snazzy "top 5 web2.0 security mistakes everyone is making" or "Top 5 Security Design-Patterns" in there, but I don't think it's the right audience. OSCON might be a better fit, if you praise Ruby and release some open source "security" project. 2. This "security DNA" notion -- I don't really buy it. I don't think there's a big tipping point coming for "all hands in for writing secure software" in our near future. Maybe if people start dying because of insecure software, this will change, but until then ... I do see increasing awareness is mid to large size organizations (fortune 2000 +). Developers are more aware and more interested in security, but mostly in organizations that penalize (fire or domote) individuals involved in public security blunders. Overall security is not a feature or a function that you can monetarize. It's not even cool or sexy. It's an emergent behavior that is only observed when it is making your software harder to use. Not until insurance or substantial penalties are the norm (if they are ever the norm) will we have meaningful quantitative data to drive a justification for security as a requirement in startup or most open source software projects. That's my opinion, anyway. --- Arian J. Evans Software Security Stuff On Wed, Mar 12, 2008 at 2:31 PM, Benjamin Tomhave wrote: > First, thanks for that Bill, it exemplifies my point perfectly. A couple > thoughts... > > one, targeting designers is just as important as reaching out to the > developers themselves... if the designers can ensure that security > requirements are incorporated from the outset, then we receive an added > benefit... > > two, a re-phrasing around my original thought... somehow we need to get > security thinking and considerations encoded into the DNA of everyone in > the business, whether they be designers, architects, coders, analysts, > PMs, sysadmins, etc, etc, etc. Every one of those topics you mention > could (should!) have had implicit and explicit security attributes > included... yet we're still at the point where secure coding has to be > explicitly requested/demanded (often as an afterthought or bolt-on)... > > How do we as infosec professionals get people to the next phase of > including security thoughts in everything they do... with the end-goal > being that it is then integrated fully into practices and processes as a > bona fide genetic mutation that is passed along to future generations? > > To me, this seems to be where infosec is stuck as an industry. There > seems to be a need for a catalyst to spur the mutation so that it can > have a life of its own. :) > > fwiw. > > > -ben > > -- > Benjamin Tomhave, MS, CISSP > falcon at secureconsulting.net > LI: http://www.linkedin.com/in/btomhave > Blog: http://www.secureconsulting.net/ > Photos: http://photos.secureconsulting.net/ > Web: http://falcon.secureconsulting.net/ > > [ Random Quote: ] > Augustine's Second Law of Socioscience: "For every scientific (or > engineering) action, there is an equal and opposite social reaction." > http://globalnerdy.com/2007/07/18/laws-of-software-development/ > > > > William L. Anderson wrote: > > Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I > > did not see many discussions that pay attention to security, or any > > other software engineering oriented concerns, explicitly. > > > > There was a discussion of scalability for web services that featured the > > developers from digg, Flickr, WordPress, and Media Temple. I got there > > about half-way through but the discussion with the audience was about > > tools and methods to handle high traffic loads. There was a question > > about build and deployment strategies and I asked about unit testing > > (mixed answers - some love it, some think it's strong-arm micro-mgt (go > > figure)). > > > > There was a session on OpenID and OAuth (open authorization) standards > > and implementation. These discussions kind of assume the use of secure > > transports but since I couldn't stay the whole time I don't know if > > secure coding was addressed explicitly. > > > > The main developer attendees at SXSW would call themselves designers and > > I would guess many of them are doing web development in PHP, Ruby, etc. > > I think the majority of attendees would not classify themselves as > > software programmers. > > > > To me it seems very much like at craft culture. That doesn't mean that a > > track on how to develop secure web services wouldn't be popular. In fact > > it might be worth proposing one for next year. > > > > If you want to talk further, please get in touch. > > > > -Bill Anderson > > praxis101.com > > > > Benjamin Tomhave wrote: > >> I had just a quick query for everyone out there, with an attached > >> thought. > >> > >> How many security and/or secure coding professionals are prevalently > >> involved with the SXSW conference this week? I know, I know... it's a big > >> party for developers - particularly the Web 2.0 clique - but I'm just > >> curious. > >> > >> Here's why: I'm increasingly frustrated by the disconnect between > >> business/dev and security. I don't feel like we're being largely > >> successful in getting the business and developers to include security as > >> part of their standard operating procedures. Developers are still > >> oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection > >> holes. > >> > >> I then look at SXSW from afar and think: a) shouldn't I be there > >> evangelizing security? and, b) shouldn't a major thread to all these > >> conferences be about how security is integrating with dev processes and > >> practices, making it better? > >> > >> Maybe I'm just too idealist. I'm curious what everyone else thinks. > >> > >> cheers, > >> > >> -ben > >> > > > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From steingra at gmail.com Wed Mar 12 18:35:35 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Wed, 12 Mar 2008 16:35:35 -0700 Subject: [SC-L] quick question - SXSW In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3103702DB8@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA3103702DB8@va-mailhub.cigital.com> Message-ID: <490a979e0803121635u5c6395c1v7169cb288e81f91@mail.gmail.com> On Wed, Mar 12, 2008 at 4:30 PM, Gary McGraw wrote: > Hey andy, > > You mean AJAX one? Last time I went there was zero interest and even less clue about security among attendees. The only shining light was a long conversation I had with bill joy about security critical decisions those guys screwed up with Java (especially with regards to closure). > > A decade of evangelism only goes so far! Do help! Fair enough :) I was looking at the program for the just finished SD West and the security track actually looks to have been pretty good. I think one thing we're missing from there is more emphasis on actual SDL process, rather than focus on individual items within it. Activities like how to form a steering group within a company, how to bootstrap some of the practices, etc. Do folks here have suggestions of conferences we ought to be targeting with these sorts of presentations, papers, etc? JavaOne seems like it might have been a good place to target. There are some smaller developer conferences out there, some general security conferences, and there has been discussion here and within OWASP as well of how we can start better targeting these forums for our evangelizing... Thoughts? -- Andy Steingruebl steingra at gmail.com From gem at cigital.com Wed Mar 12 18:30:01 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 12 Mar 2008 19:30:01 -0400 Subject: [SC-L] quick question - SXSW Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103702DB8@va-mailhub.cigital.com> Hey andy, You mean AJAX one? Last time I went there was zero interest and even less clue about security among attendees. The only shining light was a long conversation I had with bill joy about security critical decisions those guys screwed up with Java (especially with regards to closure). A decade of evangelism only goes so far! Do help! gem www.cigital.com/~gem ----- Original Message ----- From: sc-l-bounces at securecoding.org To: Benjamin Tomhave Cc: SC-L at securecoding.org Sent: Wed Mar 12 18:05:53 2008 Subject: Re: [SC-L] quick question - SXSW On Tue, Mar 11, 2008 at 6:43 AM, Benjamin Tomhave wrote: > I had just a quick query for everyone out there, with an attached thought. > > How many security and/or secure coding professionals are prevalently > involved with the SXSW conference this week? I know, I know... it's a big > party for developers - particularly the Web 2.0 clique - but I'm just > curious. > On a related note a quick perusal of the JavaOne conference tracks doesn't show a lot of content in this area either. Is this due to a lack of interest, or people in the security world not pitching talks to the development conference organizer? -- Andy Steingruebl steingra at gmail.com _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From gem at cigital.com Wed Mar 12 19:06:12 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 12 Mar 2008 20:06:12 -0400 Subject: [SC-L] quick question - SXSW Message-ID: <41945506397C0C4886A8C5BFF089B5CA3103702DB9@va-mailhub.cigital.com> Hi again, I rebooted the security track completely at SD West in 2003 (thanks to tami who I cc'ed here). I'm on the advisory board. We're slowly inching our way toward SDL/touchpoints/CLASP stuffs at SD West, though when I tried to cover the touchpoints and enterprise security in 2006, interest was weak. After 5 years of pounding we're getting there though! My suggestion? Get involved organizing these conferences and helping with thought leadership. And just for the record, having your PR dingbats submit (stupid)marketing talks does not count. Others getting the same treatment; SD Best Practices STAR West Better Software MISTI CSI NDSS Usenix security Rock on gem ----- Original Message ----- From: Andy Steingruebl To: Gary McGraw Cc: list-spam at secureconsulting.net ; SC-L at securecoding.org Sent: Wed Mar 12 19:35:35 2008 Subject: Re: [SC-L] quick question - SXSW On Wed, Mar 12, 2008 at 4:30 PM, Gary McGraw wrote: > Hey andy, > > You mean AJAX one? Last time I went there was zero interest and even less clue about security among attendees. The only shining light was a long conversation I had with bill joy about security critical decisions those guys screwed up with Java (especially with regards to closure). > > A decade of evangelism only goes so far! Do help! Fair enough :) I was looking at the program for the just finished SD West and the security track actually looks to have been pretty good. I think one thing we're missing from there is more emphasis on actual SDL process, rather than focus on individual items within it. Activities like how to form a steering group within a company, how to bootstrap some of the practices, etc. Do folks here have suggestions of conferences we ought to be targeting with these sorts of presentations, papers, etc? JavaOne seems like it might have been a good place to target. There are some smaller developer conferences out there, some general security conferences, and there has been discussion here and within OWASP as well of how we can start better targeting these forums for our evangelizing... Thoughts? -- Andy Steingruebl steingra at gmail.com From gunnar at arctecgroup.net Wed Mar 12 20:49:23 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Wed, 12 Mar 2008 20:49:23 -0500 Subject: [SC-L] quick question - SXSW In-Reply-To: References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> Message-ID: <47D88823.70307@arctecgroup.net> I agree this is a big issue, there is no cotton picking way that the security people are solving these problems, it has to come from the developers. I put together a track for QCon which included Brian Chess on Static Analysis, John Steven on Threat Modeling, and Jeff Williams on ESAPI and Web 2.0 security. The presentations were great, the audience was engaged and enthusiastic but small; it turns that it is hard to compete with the likes of Martin Fowler, Joshua Bloch, and Richard Gabriel. Even when what they are talking about is some nth level refinement and what we are talking about is all the gaping holes in the previous a-m refinements and how to close some of them. http://jaoo.dk/sanfrancisco/tracks/show_track.jsp?trackOID=73 -gp Kenneth Van Wyk wrote: > Ben, > > Your point is a good one -- the software security community needs to be > vigilant in reaching out to developers and spreading "the word". > > FWIW, some dev conferences have done this. I spoke at SD West in 2006, > and there was a significant security track there. Still, it'd be great > to see that sort of thing at more dev-specific conferences. > > Cheers, > > Ken van Wyk > SC-L Moderator > > On Mar 12, 2008, at 5:31 PM, Benjamin Tomhave wrote: > >> First, thanks for that Bill, it exemplifies my point perfectly. A couple >> thoughts... >> >> one, targeting designers is just as important as reaching out to the >> developers themselves... if the designers can ensure that security >> requirements are incorporated from the outset, then we receive an added >> benefit... >> >> two, a re-phrasing around my original thought... somehow we need to get >> security thinking and considerations encoded into the DNA of everyone in >> the business, whether they be designers, architects, coders, analysts, >> PMs, sysadmins, etc, etc, etc. Every one of those topics you mention >> could (should!) have had implicit and explicit security attributes >> included... yet we're still at the point where secure coding has to be >> explicitly requested/demanded (often as an afterthought or bolt-on)... >> >> How do we as infosec professionals get people to the next phase of >> including security thoughts in everything they do... with the end-goal >> being that it is then integrated fully into practices and processes as a >> bona fide genetic mutation that is passed along to future generations? >> >> To me, this seems to be where infosec is stuck as an industry. There >> seems to be a need for a catalyst to spur the mutation so that it can >> have a life of its own. :) >> >> fwiw. >> >> -ben >> >> -- >> Benjamin Tomhave, MS, CISSP >> falcon at secureconsulting.net >> LI: http://www.linkedin.com/in/btomhave >> Blog: http://www.secureconsulting.net/ >> Photos: http://photos.secureconsulting.net/ >> Web: http://falcon.secureconsulting.net/ >> >> [ Random Quote: ] >> Augustine's Second Law of Socioscience: "For every scientific (or >> engineering) action, there is an equal and opposite social reaction." >> http://globalnerdy.com/2007/07/18/laws-of-software-development/ >> >> William L. Anderson wrote: >>> Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I >>> did not see many discussions that pay attention to security, or any >>> other software engineering oriented concerns, explicitly. >>> >>> There was a discussion of scalability for web services that featured the >>> developers from digg, Flickr, WordPress, and Media Temple. I got there >>> about half-way through but the discussion with the audience was about >>> tools and methods to handle high traffic loads. There was a question >>> about build and deployment strategies and I asked about unit testing >>> (mixed answers - some love it, some think it's strong-arm micro-mgt (go >>> figure)). >>> >>> There was a session on OpenID and OAuth (open authorization) standards >>> and implementation. These discussions kind of assume the use of secure >>> transports but since I couldn't stay the whole time I don't know if >>> secure coding was addressed explicitly. >>> >>> The main developer attendees at SXSW would call themselves designers and >>> I would guess many of them are doing web development in PHP, Ruby, etc. >>> I think the majority of attendees would not classify themselves as >>> software programmers. >>> >>> To me it seems very much like at craft culture. That doesn't mean that a >>> track on how to develop secure web services wouldn't be popular. In fact >>> it might be worth proposing one for next year. >>> >>> If you want to talk further, please get in touch. >>> >>> -Bill Anderson >>> praxis101.com >>> >>> Benjamin Tomhave wrote: >>>> I had just a quick query for everyone out there, with an attached >>>> thought. >>>> >>>> How many security and/or secure coding professionals are prevalently >>>> involved with the SXSW conference this week? I know, I know... it's >>>> a big >>>> party for developers - particularly the Web 2.0 clique - but I'm just >>>> curious. >>>> >>>> Here's why: I'm increasingly frustrated by the disconnect between >>>> business/dev and security. I don't feel like we're being largely >>>> successful in getting the business and developers to include >>>> security as >>>> part of their standard operating procedures. Developers are still >>>> oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection >>>> holes. >>>> >>>> I then look at SXSW from afar and think: a) shouldn't I be there >>>> evangelizing security? and, b) shouldn't a major thread to all these >>>> conferences be about how security is integrating with dev processes and >>>> practices, making it better? >>>> >>>> Maybe I'm just too idealist. I'm curious what everyone else thinks. >>>> >>>> cheers, >>>> >>>> -ben >>>> > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ From list-spam at secureconsulting.net Wed Mar 12 20:08:37 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 12 Mar 2008 21:08:37 -0400 Subject: [SC-L] quick question - SXSW In-Reply-To: References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> Message-ID: <47D87E95.40200@secureconsulting.net> I think you misunderstood my points a little bit. SXSW was just a current conference example. As Gary's pointed out, there are many conferences. It's possible SXSW wasn't a good example, but it was meant more symbolically. More comments inline... Arian J. Evans wrote: > 1. This is largely the wrong crowd. Designers of small web2.0 stuffs, > particularly the domain of widgets and WS interfaces for all the usual > suspect platforms (flickr, facebook etc.) as well as most startups: > > They just don't care. > > They will never care. > I fundamentally disagree. Everybody is the right crowd, assuming the message is tailored appropriately. It's precisely the perspective you espouse that concerns me greatly. I don't believe the security industry _as_a_whole_ has maintained momentum, and I attribute that directly to the SEP* effect. This goes directly to my larger point about ingraining security considerations/thoughtfulness/practices into all aspects of the business (not just coding, btw). *See http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem_field > 2. This "security DNA" notion -- I don't really buy it. I don't think > there's a big tipping point coming for "all hands in for writing secure > software" in our near future. Maybe if people start dying because > of insecure software, this will change, but until then ... > If everyone starts coding more responsibly, then at some point the genre of "secure coding" goes away, because it's inherent in everything that's written. Today, I'd settle for all externally-facing apps being coded to address the OWASP Top 10, and to get developers to think for a change before doing silly things like implementing client-side filtering in the client code. > I do see increasing awareness is mid to large size organizations > (fortune 2000 +). Developers are more aware and more interested > in security, but mostly in organizations that penalize (fire or > domote) individuals involved in public security blunders. > Hard-earned gains. How do we institutionalize these practices and get beyond playing the role of Law Enforcement for the security department? > Overall security is not a feature or a function that you can monetarize. > It's not even cool or sexy. It's an emergent behavior that is only > observed when it is making your software harder to use. > On the first sentence, I say "yes, exactly!" On the second sentence, I couldn't disagree more. Security should not be "making your software harder to use." Address XSS, CSRF, SQL injection, and input/output filtering/encoding should not diminish the end-user experience. Things like 2-factor authentication might have that result, but we're not really talking about that right now. > Not until insurance or substantial penalties are the norm (if they are > ever the norm) will we have meaningful quantitative data to drive a > justification for security as a requirement in startup or most open > source software projects. That's my opinion, anyway. > I would really like for you to be wrong, but I can't really disagree with your base conclusion here. Hence my frustration. It provides a good case for shelving all security departments until the business starts taking major hits and they come begging for help. Honestly, I don't understand it. Businesses don't disagree that they need properly secured code/sites/etc. Yet, by the same token, they don't do what's necessary up front to secure their code/sites/etc. It's a truly bizarre disconnect that boggles my mind. Thanks for the response! :) -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] "A man without a goal is like a ship without a rudder." Thomas Carlyle From arian.evans at anachronic.com Wed Mar 12 21:47:41 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Wed, 12 Mar 2008 19:47:41 -0700 Subject: [SC-L] quick question - SXSW In-Reply-To: <47D87E95.40200@secureconsulting.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> <47D87E95.40200@secureconsulting.net> Message-ID: On Wed, Mar 12, 2008 at 6:08 PM, Benjamin Tomhave wrote: > I think you misunderstood my points a little bit. SXSW was just a > current conference example. As Gary's pointed out, there are many > conferences. It's possible SXSW wasn't a good example, but it was meant > more symbolically. More comments inline... Oh, I did miss your point. Overall, I agree. I've had mixed experiences leading me to re-evaluate my stance. A security-unaware dev friend recently told me about Microsoft coming to some conference and demonstrating this new "SQL Injection" thing to them, and he told me how amazing and cool it was. He asked if I did SQL Injection. That's the first time in several years he's responded to what I've primarily worked on for 8+ years, and incidentally for over 10, and told him about over god-knows how many Guinness. I don't blame the Guinness. (who can?) > > They just don't care. > > > > They will never care. > > > I fundamentally disagree. Everybody is the right crowd, assuming the > message is tailored appropriately. It's precisely the perspective you > espouse that concerns me greatly. I don't believe the security industry > _as_a_whole_ has maintained momentum, and I attribute that directly to > the SEP* effect. This goes directly to my larger point about ingraining > security considerations/thoughtfulness/practices into all aspects of the > business (not just coding, btw). I think this approach is doomed to failure, though my thoughts and experiences are mixed. Whilst I have quit evangelizing secure software, I do meet more and more devs interested in software security -- whom were not merely 3 to 5 years ago. Something is definitely changing, but abstract interest in appsec != secure design & implementation. While this isn't an argument -- just an observation -- I hear this "build security in" notion preached most often from the following: (a) people new to the appsec "industry" (b) academic-minded & PHD-type folks into taxonomies (c) government folks/agencies out of touch with the business world (d) eager kids just-out-of infosec college joining our "industry" (e) people with livelyhood/agendas staked on these notions Maybe I'm just jaded, but it doesn't seem to work in many, and possibly most, cases. I think the the momentum is lost because all these "build security in" and "Secure SDLC" things don't work for a lot of people/organizations. I still have some suspicions this may be due to implementation, but... This industry cannot even get it's node-hierarchies right. Even the mitre CWE is fraught with node-confusion betwixt attack nodes, vulnerability nodes, and design & implementation weakness nodes. But at the end of the day the business doesn't care. "Will this model of car sell and will we get sued over defects in it?" That's the world. If "building secure cars" was the answer Volvo would have been a wild success many, many years ago. > If everyone starts coding more responsibly, then at some point the genre > of "secure coding" goes away, because it's inherent in everything that's > written. Today, I'd settle for all externally-facing apps being coded to > address the OWASP Top 10, and to get developers to think for a change > before doing silly things like implementing client-side filtering in the > client code. Client-side filtering isn't silly. It's smart. You probably mean using it as a security control, but it's that verbiage that arms legions of the clueless appsec auditors now joining our industry that don't know sh*t about software design or implementation, or business use-case, and cause software professionals to scoff at our industry. I can't tell you how many appsec reports I've seen that say "don't use client side validation -- it's dangerous" and I start looking for more best practice nonsense listed as "vulnerabilities". "Don't allow dangerous characters in input". WTF? "Insufficient input validation". For whom? I think I see your perspective though. I think the answer is: IDEs that make it harder to shoot oneself in the foot, secure frameworks, and secure environments (for all us text-editor types) and maybe even newer languages with some real notion of a data/function boundary -- those are the keys. Leave "secure coding" out of it. Combine that with security controls that provide meaningful mis-use case and fraud detection, instead of attack-vector blocking, and you and can even allow weak password reset questions. Which is what the business, and my mother, really wants. I hesitate to say this, this is like fumbling with flame-bait, but over the last two years I feel more and more like many in this industry, including OWASP which you mentioned, are going astray down this fantasy land of secure-coding and assurance. The government (and contracting agencies by proxy) are into assurance. The rest of the world is not. The private sector is into mitigation, insurance, fraud detection and incident response. OWASP notions and directions feel to me like it's driven more and more by people out of touch with the major producers of software in the private sector, and the way the world creates and innovates software products Two things have driven this: I once was really into taxonomies and classification and clearing up the muddled mess of appsec and the utter lack of math and useless "science" that we have in this "industry". Second was a mix of learning more about the internals of Microsoft and their appsec struggles and moving out here to Silicon Valley and getting in the middle of software central. Both those things have served to push me completed over into the pragmatic camp and I look at appsec much differently now. > Hard-earned gains. How do we institutionalize these practices and get > beyond playing the role of Law Enforcement for the security department? I don't know. I don't find many real-world analogues, quite frankly. I had a sports car with a governor at 125mph once, but it was easily removable. My sport bikes will do 180mph. That's why we have LEO's. I'm not supposed to ride 180 mph on public roads. I think most devs I know look at "the art of writing secure code" like I look at a sportbike governed at 85mph: "Get out of my way". > > Overall security is not a feature or a function that you can monetarize. > > It's not even cool or sexy. It's an emergent behavior that is only > > observed when it is making your software harder to use. > > > On the first sentence, I say "yes, exactly!" On the second sentence, I > couldn't disagree more. Security should not be "making your software > harder to use." Address XSS, CSRF, SQL injection, and input/output > filtering/encoding should not diminish the end-user experience. Things > like 2-factor authentication might have that result, but we're not > really talking about that right now. I didn't say security *SHOULD* be about making your software harder to use. I said that it does, in many, many, many cases. Let's take your examples: XSS: Facebook & Myspace don't agree with you. CSRF: Everyone who has to re-authenticate. There is no other way to protect against CSRF on weakly designed auth/session controls. And re-auth sucks. Ask your mother. SQL Injection. This depends on the solution. I've seen nice, Irish, Sarah O'Grady turned into the polish Sarah OGrady or the fractal (?) Sarah O\Grady. Parameterized SQL certainly solves this neatly, but the data-function boundary concept is missing from most modern implementation-level languages. So you can't solve XSS that way. > > Not until insurance or substantial penalties are the norm (if they are > > ever the norm) will we have meaningful quantitative data to drive a > > justification for security as a requirement in startup or most open > > source software projects. That's my opinion, anyway. > > > I would really like for you to be wrong, but I can't really disagree > with your base conclusion here. Hence my frustration. It provides a good > case for shelving all security departments until the business starts > taking major hits and they come begging for help. Honestly, I don't > understand it. Businesses don't disagree that they need properly secured > code/sites/etc. Yet, by the same token, they don't do what's necessary > up front to secure their code/sites/etc. It's a truly bizarre disconnect > that boggles my mind. It's not a disconnect my man. It's reality. Businesses don't ship code to show off Secure Software. They ship code to make money. Software security is an emergent behavior that changes over time with software use, evolution, extension, and the changing threat landscape. It's not an art you get people inspired in. Take the threat landscape: Phishers are just starting to use XSS in ernest now. No one knows what in the world is really out there that we are facing, except maybe IBM's Global Managed network services (who is starting to monitor and measure this stuff now). They probably have the biggest sample of real-world traffic. I know folks at a number of large software companies/websites out there on the 'net that face regular attacks and have a decent idea what real attacks are and what dealing with them costs, but they are all private sector and none of them are going to release anything in the way of data about it. Releasing facts might raise their cost of business. > Thanks for the response! :) You too. Yours was well reasoned; I still disagree on points though. A third thing I'll add -- my employer for the last 1.5 years has enabled me to see about 500-600 production websites, and their vulnerability posture from a black-box perspective, but also how people fix things, what they fix, why, what they assume the risk on, etc., and have my customers tell me what is attacked and how. Having that much real-world data has also changed my perspective from a once-purist "design & write more reliable code" and "look at your code, fix your code" to more of a "this is how the world is; let's make better band-aids cause we're always going to need them" view. I've been meaning to write an essay on Idealogies and Idealogy Wars in appsec. There's at least three major idealogue camps, and wars between them starting to brew, but most folks new to this field have no idea what the agendas and perspectives are, why they exist, and what drives the different ideals. Thanks for the stimulating though, ciao -- Arian Evans software security stuff From arian.evans at anachronic.com Thu Mar 13 03:11:49 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Thu, 13 Mar 2008 01:11:49 -0700 Subject: [SC-L] quick question - SXSW In-Reply-To: <490a979e0803121505w4d3ee137vfe58205d359476a2@mail.gmail.com> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <490a979e0803121505w4d3ee137vfe58205d359476a2@mail.gmail.com> Message-ID: On Wed, Mar 12, 2008 at 3:05 PM, Andy Steingruebl wrote: > On a related note a quick perusal of the JavaOne conference tracks > doesn't show a lot of content in this area either. Is this due to a > lack of interest, or people in the security world not pitching talks > to the development conference organizer? Both. Java is a tricky one. There were security sessions early on in Java conferences, but they were about the stuff no one on the planet actually does -- e.g. container security, code signing, and JVM/applet permissions. I think that turned a lot of devs off of security in Java-land. In related news we're building J2EE courseware in a "by developers, for developers" fashion and Anurag will be releasing some APIs for java developers to actually do things like output encoding, where Java/J2EE is about 4 years behind the rest of the world. I imaged later this year or next year you'll see a few of us focusing on developer (versus security) conferences, though I don't think this changes the business problem/reality at all. -- Arian Evans software security stuff From arian.evans at anachronic.com Thu Mar 13 04:03:29 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Thu, 13 Mar 2008 02:03:29 -0700 Subject: [SC-L] Software security definition(s) Message-ID: I hate to start a random definition thread, but Ben asked me a good question and I'm curious if anyone else sees this matter in the same fashion that I do. Ben asked why I refer to software security as similar to artifacts identified by emergent behaviors: > > Software security is an emergent behavior that changes over time > > with software use, evolution, extension, and the changing threat > > landscape. It's not an art you get people inspired in. > > > You keep using that phrase - "emergent behavior" - and I'm not sure what > you mean. So one of the biggest challenges for me was communicating to any audience, and most importantly the business and developers, what "secure software/applications" means. Around 2000/2001 I was still fixated on artifacts in code and in QA and secure software == strongly typed variables with draconian input validation and character set handling (canonicalization and encoding types). Yet I continued to have problems with the word "security" when talking to business owners and developers about software. This is because you say "security" and business owners see sandbags blocking their figurative river of profits. Corporate and gov developers see sandbags stopping them from going home and having dinner with the wife or playing WoW. Startup developers just laugh. I started using phrases like "predictable and dependable software" instead of security. Giving examples of "Rob's Report" -- it has all these user requirements it must meet to pass on to UAT, and if it fails, blah blah. SQL injection is a failure of degree, and not of kind. Same kind of failure as a type-mismatch error that stops the report from running -- but huge difference in degree of impact. Finally it dawned on me folks latch on to this secure software stuff as features and requirements, anyone using waterfall gets drowned in insecure software due to forever-pushed-back security "features". My experience also was that never, ever, is a Production app deployment identical to dev regions, let alone QA stages, UAT, etc. >From a security posture: prod might be better *or* worse than the other environments. Yet even worse -- sometimes I'd test app A and app B for a company, and they would both fair well when tested independently. I'd come back a year later and the company would have bolted them together through say some API or WS and now, together, apps A and B were really weak when glued together. Usually this was due to interfaces handling I/O that they weren't intended to. Long and short of it -- it struck me that security is a measure of behaviors. It is one quality of an application, like speed/ performance, but this quality is measured by the observed behaviors, regardless of what the source code, binary, or blueprint tells you... Note -- I am not saying any of these things are not valuable. There's things I'd still far rather find in source than black box, and things binary tracing is brilliant at. I'm simply saying that at the end of the day, the "proof in the pudding" is at run-time. The same way we perform the final measure the quality of commercial jets: I don't care about tensile strength exceeding tolerance standards if the wings are falling off at run-time. If someone compromises 1000 customer accounts, steals their prescription data, and tells the zoloft folks who is buying prozac so they can direct-market (real world example): you have a defective application. Those behaviors are always emergent -- meaning they can only ultimately be measured at runtime in a given environment with a given infra and extension (like plugging app B into app A through some wonky API). Sometimes it's the *caching* layer that allows you to insert control characters that lead to compromising the rest of the application, soup to nuts. You won't find any hint of the caching layer in source, in binary, in blueprint, in conversation with the devs, in dev or QA regions, in staging and UAT, or by running your desktop or network VA webapp scanner unauthenticated on the entry portal. You might find it in documentation, or during threat modeling. You will find it when you start measuring the emergent behavior of a piece of otherwise well-vetted software now sitting behind a weak caching layer and you start observing wonky caching/response issues and realize these behaviors are weak; you can attack them.... What is "secure" software? It is one quality of an application that can be measured by the emergent behaviors of the software while trying to meet and enforce its use-case in a given run-time environment. This now fits back to the whole ideology discussion that is sorely needed and overdue. -- Arian Evans software security stuff From rcs at cert.org Thu Mar 13 09:38:58 2008 From: rcs at cert.org (Robert C. Seacord) Date: Thu, 13 Mar 2008 10:38:58 -0400 Subject: [SC-L] CERT C Secure Coding Standard - last call for reviewers Message-ID: <47D93C82.5000701@cert.org> We would like to invite the community to review and comment on the current version of the CERT C Secure Coding Standard available online at www.securecoding.cert.org before Version 1.0 is published. To comment, you can create an account on the Secure Coding wiki and post your comments there. Our intent is to complete major development of Version 1.0 by April 18, 2008, with the published version of the standard being available in September. Once Version 1.0 of the standard goes to the publisher, we will begin development of Version 2.0. That is, we will continue to maintain the wiki to further advance the "working version" of the CERT C Secure Coding Standard. The published 1.0 version will become the official version, until replaced by a future version. It is unlikely a subsequent version will be released any time in the next 2-3 years, so we would like to ensure that Version 1.0 will be a high quality product that will promote and encourage secure coding practices. Thanks for any help and assistance you have already provided and for any additional contribution you may make. There are currently 158 individuals who have contributed to the development of this standard, without whom this effort could not have succeeded. rCs From ge at linuxbox.org Fri Mar 14 01:13:00 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 14 Mar 2008 01:13:00 -0500 (CDT) Subject: [SC-L] Secure Development World ? Message-ID: I am trying to understand if this conference is cancelled or not? From ramartin at mitre.org Fri Mar 14 06:45:26 2008 From: ramartin at mitre.org (Robert A. Martin) Date: Fri, 14 Mar 2008 07:45:26 -0400 Subject: [SC-L] Secure Development World ? Message-ID: Yes it is cancelled. At 1:13 AM -0500 3/14/08, Gadi Evron wrote: >I am trying to understand if this conference is cancelled or not? >_______________________________________________ >Secure Coding mailing list (SC-L) SC-L at securecoding.org >List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >List charter available at - http://www.securecoding.org/list/charter.php >SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >as a free, non-commercial service to the software security community. >_______________________________________________ From jsteven at cigital.com Fri Mar 14 08:39:08 2008 From: jsteven at cigital.com (John Steven) Date: Fri, 14 Mar 2008 09:39:08 -0400 Subject: [SC-L] quick question - SXSW In-Reply-To: <47D88823.70307@arctecgroup.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> , <47D88823.70307@arctecgroup.net> Message-ID: <41945506397C0C4886A8C5BFF089B5CA31037006F7@va-mailhub.cigital.com> All, I just got back from SD West where I spoke twice in the security track. My third year working this show I was shocked to find larger audiences, avid participation, and (what excited me the most) very clueful development types. Awareness will continue to be a big part of "getting the word out there". But what Gunnar attempted to do with his track at QCon was excellent and we should learn from it. He 1) organized a set of talks that followed each other clearly, building on previous content and 2) focused on more intermediate or advanced content. Too often, the security talks at conferences overlap. Even this year's SD West had two threat modeling talks and a secure design talk. I'm also sick of their patronizing structure and titles: "Top 10 Web Vulnerabilities". Smart developers interested in learning this stuff can avail themselves of strong web tutorials from a variety of sources at this point. Overlapping talks comprised mostly of top ten lists leave developers with the empty "So what do I do about it?" feeling. At SD West, I positioned my two talks as "advanced". I laughed looking at the conference board. I personally accounted for about half of the advanced talks for the conference. My "Static Analysis Tool Customization" talk generated great discussion. I was pleased. Almost every audience member worked for an organization that was piloting or had already adopted a tool. They had really used it, and crashed against a rock. Because experience varied (Coverity, KLocwork, Fortify, and Ounce experience all represented) we got to talk about more than just one tool. Comparison was very demonstrative. People took copious notes, stayed after, discussion continued. Yes, we still need more awareness but people want more advanced talks. They're ready. At SD Best, I'm working to modernize the curriculum. I'm working with the development track leads to make sure that things cohere. Rather than mixing old-school buffer overflow information, with web security, with some process help, with some tool demos, I'm going to try to organize instruction around some of the newer stuff that developers are beginning to play with and be excited about. We'll focus on web services and web 2.0. In my mind, teaching people to "think destructively" is important, but brining it back around and showing what to do about vulnerabilities is hugely important at a dev. conference. Last year I pushed speakers in this track to give constructive advice. I'll do the same this year. Whether we're speaking to security guys or developers, it's time to show people patterns and approaches that will help them solve the problems we've been talking about for years. Sum: Modernize advice. Talk to people in the languages and frameworks that they're using now. Get practical and constructive. Teach people how to build it right. Move beyond awareness to intermediate and advanced topics. It's time to raise the bar. ---- John Steven Technical Director; Principal, Software Security Group Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 Blog: http://www.cigital.com/justiceleague Papers: http://www.cigital.com/papers/jsteven http://www.cigital.com Software Confidence. Achieved. ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson [gunnar at arctecgroup.net] I agree this is a big issue, there is no cotton picking way that the security people are solving these problems, it has to come from the developers. I put together a track for QCon which included Brian Chess on Static Analysis, John Steven on Threat Modeling, and Jeff Williams on ESAPI and Web 2.0 security. The presentations were great, the audience was engaged and enthusiastic but small; it turns that it is hard to compete with the likes of Martin Fowler, Joshua Bloch, and Richard Gabriel. Even when what they are talking about is some nth level refinement and what we are talking about is all the gaping holes in the previous a-m refinements and how to close some of them. http://jaoo.dk/sanfrancisco/tracks/show_track.jsp?trackOID=73 From mlyman-cissp at comcast.net Fri Mar 14 09:06:46 2008 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Fri, 14 Mar 2008 09:06:46 -0500 Subject: [SC-L] quick question - SXSW In-Reply-To: References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> Message-ID: <47DA8676.5080703@comcast.net> Arian J. Evans wrote: > Overall security is not a feature or a function that you can monetarize. > It's not even cool or sexy. It's an emergent behavior that is only > observed when it is making your software harder to use. > Maybe it is just the US Department of Defense environment where I am currently working but I see developers start to see this as cool and sexy. Most are picking it up quickly and a few are even interested in diving in deep into the security world. They ask great questions and are doing a lot of independent research on it. We are in an environment where they get security awareness training a few times a year and are constantly bombarded with security messages but some of them really are getting into it. It gives them something new to learn and it is driving them to go deeper into some development subjects that they normally would not ever be allowed to look at due to delivery schedules. Security is giving them a good excuse to go learn more. -- Mike Lyman mlyman at west-point.org From mlyman-cissp at comcast.net Fri Mar 14 08:28:55 2008 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Fri, 14 Mar 2008 08:28:55 -0500 Subject: [SC-L] Software security definition(s) In-Reply-To: References: Message-ID: <47DA7D97.7040605@comcast.net> Arian J. Evans wrote: > What is "secure" software? > It is one quality of an application that can be measured > by the emergent behaviors of the software while trying to > meet and enforce its use-case in a given run-time environment. > Fairly new to the list so if I cover things discussed before or breach some list standards here feel free to jump all over me. What is secure software good discussion to help us set our sights on where we need to go. Want to keep it grounded in the reality of today though just a bit. I think one of the problems we have in the security industry is "secure" itself is a bad term. Somebody, somewhere can find a way to attack any computer as long as it exists. I've often told folks I'm beginning to work with that you could power off a computer, encase it in a block of cement, dump in it the ocean to try to secure the data in it it and Robert Ballard could probably located it and retrieve it for anybody willing to pay for it and meanwhile it hasn't been very useful to you. Even short of that drastic of a step, if users can use it, somebody can attack it. Features themselves are double edged swords; "del *.*" or "sudo rm *" can be useful commands or very dangerous ones. Even with draconian input validation, users could mess up the integrity of the data just by fat fingering input or selecting the wrong item in a pick list or a disk controller going bad could cause garbage. Somebody reading over a user's sholder can comprise the confidentially of the data or listening to them at lunch time. (Ever want to know what is going on at Microsoft just go to the opening day of any major science fiction movie at any theater in the Redmond area.) Flooded network pipes or cut cables can create DoS attacks. A user walking away from his desk without locking the computer opens up non-repudiation issues. "Secure" can be successfully attacked in too many ways and proven insecure. I try to focus more on secure enough to do the job it needs to do in the environment it will operate in. That adds a lot of complexity that is difficult to deal with since it makes simple check lists less useful but it can also simplify things. I've had experiences where we removed security features because they were unnecessary for the application and its environment. Had a design team engineer FT Knox to that could have protected data for years when that data was going live on a public website in less than 24 hours. They were rather surprised to have security remove things that were way too costly for the nature of what they were doing. Just started as the security reviewer/lead on a new project yesterday. Went into my standard introductions about how this is an ever changing world and what passes as good enough today may be wide open tomorrow and we just have to live with that fact. We don't have the time or budget to fully inject security into their development life cycle at this time or dive deep into their code but any improvement is still improvement. What we do now will make them better on the next version or the next project. (Have seen that happen in a big way with some of the teams we work with.) We may have a larger budget next time or get more mileage out of the same budget because of what they learn now. As is all too typical, our customers get us engaged after the project is already in progress so we can't inject security considerations from the beginning and help drive the design or the application or the specifications. We do what we can while in progress. It'll be better than it would have been without our efforts. When we are done, will it be secure? No, we couldn't ultimately achieve that anyway but will it be secure enough for its intended use and environment is the better question. Should be but even then I won't give concrete answer. Based on what we know today it probably will be but somewhere somebody may well be crafting that next attack that blows us out of the water. -- Mike Lyman mlyman at west-point.org From arian.evans at anachronic.com Fri Mar 14 10:55:33 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Fri, 14 Mar 2008 08:55:33 -0700 Subject: [SC-L] quick question - SXSW In-Reply-To: <47DA8676.5080703@comcast.net> References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <47D80776.6030602@acm.org> <47D84BC6.4020608@secureconsulting.net> <47DA8676.5080703@comcast.net> Message-ID: I'm not sure if the post made the list, but I outlined what I believe is a huge difference between government and beltway contractors, and the private sector. DoD (and most gov/gov-contractor corps) fall squarely into the "assurance" camps. Private sector is heavily into "mitigation" and "response". I get a completely different feel, due to entirely different organizational/business realities, from software startups and silicon valley in general. That's great that you see this, though. Good news. -ae On Fri, Mar 14, 2008 at 7:06 AM, Mike Lyman wrote: > Arian J. Evans wrote: > > Overall security is not a feature or a function that you can monetarize. > > It's not even cool or sexy. It's an emergent behavior that is only > > observed when it is making your software harder to use. > > > > Maybe it is just the US Department of Defense environment where I am > currently working but I see developers start to see this as cool and > sexy. Most are picking it up quickly and a few are even interested in > diving in deep into the security world. They ask great questions and are > doing a lot of independent research on it. We are in an environment > where they get security awareness training a few times a year and are > constantly bombarded with security messages but some of them really are > getting into it. It gives them something new to learn and it is driving > them to go deeper into some development subjects that they normally > would not ever be allowed to look at due to delivery schedules. Security > is giving them a good excuse to go learn more. > -- > > Mike Lyman > mlyman at west-point.org > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Arian Evans software security stuff From gem at cigital.com Fri Mar 14 10:58:54 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 14 Mar 2008 11:58:54 -0400 Subject: [SC-L] quick question - SXSW In-Reply-To: <47DA8676.5080703@comcast.net> Message-ID: hi sc-l, As many of you know, I have been doing this stuff for over a decade now. In terms of developer awareness and uptake, we have made great strides in the last three years. I taught my first training class on software security at Goldman in 2001. Since then, we've trained well over 8000 developers and others on software security (at Cigital where I work). Attitudes have definitely shifted, and the market continues to grow. Demand is up and interest is high. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 3/14/08 10:06 AM, "Mike Lyman" wrote: Arian J. Evans wrote: > Overall security is not a feature or a function that you can monetarize. > It's not even cool or sexy. It's an emergent behavior that is only > observed when it is making your software harder to use. > Maybe it is just the US Department of Defense environment where I am currently working but I see developers start to see this as cool and sexy. Most are picking it up quickly and a few are even interested in diving in deep into the security world. They ask great questions and are doing a lot of independent research on it. We are in an environment where they get security awareness training a few times a year and are constantly bombarded with security messages but some of them really are getting into it. It gives them something new to learn and it is driving them to go deeper into some development subjects that they normally would not ever be allowed to look at due to delivery schedules. Security is giving them a good excuse to go learn more. -- Mike Lyman mlyman at west-point.org _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From gem at cigital.com Fri Mar 14 11:10:48 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 14 Mar 2008 12:10:48 -0400 Subject: [SC-L] Software Security Bibliography Message-ID: Hi sc-l, I have been having some out of band threads with a couple of people about what to read in software security. I posted this once before to the list, but it's worth doing again... In my book "Software Security" there is an extensive annotated bibliography published as Chapter 13. The entire contents of that chapter are available for free on the book's website at this URL: http://www.swsec.com/book/annotated-biblio-from-SS.pdf Be forewarned, the bibliography is annotated with my opinions about the work cited and some may disagree with me. That's what science is all about! There are some new books that have been published since the bibliography was built. Finding those is left as an exercise to the reader. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From coley at linus.mitre.org Fri Mar 14 15:19:10 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 14 Mar 2008 16:19:10 -0400 (EDT) Subject: [SC-L] Secure Development World ? In-Reply-To: References: Message-ID: Gadi, All indications are that it was cancelled. Would have been nice if they'd informed the speakers. Too bad, too - it was looking like it would be a great conference. - Steve On Fri, 14 Mar 2008, Gadi Evron wrote: > I am trying to understand if this conference is cancelled or not? > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From ge at linuxbox.org Fri Mar 14 15:26:02 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 14 Mar 2008 15:26:02 -0500 (CDT) Subject: [SC-L] Secure Development World ? In-Reply-To: References: Message-ID: On Fri, 14 Mar 2008, Steven M. Christey wrote: > > Gadi, > > All indications are that it was cancelled. Would have been nice if they'd > informed the speakers. Too bad, too - it was looking like it would be a > great conference. They didn't inform me I am speaking, a Google alert did. They informed me it was cancelled, but just a couple of weeks to the conference and the web page doesn't indicate it. So making sure. > > - Steve > > > On Fri, 14 Mar 2008, Gadi Evron wrote: > >> I am trying to understand if this conference is cancelled or not? >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> > From gem at cigital.com Fri Mar 14 16:02:41 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 14 Mar 2008 17:02:41 -0400 Subject: [SC-L] Silver Bullet turns 2: Mary Ann Davidson Message-ID: hi sc-l, We just posted the 24th episode of the Silver Bullet Security Podcast. This time I speak with Mary Ann Davidson. Our conversation was almost exclusively focused on software security. What makes Mary Ann's position so interesting is that she is one of the only major CISOs whose role is tightly focused on software security (in this case Oracle product security). That's very cool. Check it out: http://www.cigital.com/silverbullet/show-024/ As usual, thanks to IEEE Security & Privacy magazine for co-sponsoring the podcast with Cigital. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From list-spam at secureconsulting.net Sun Mar 16 11:15:55 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Sun, 16 Mar 2008 12:15:55 -0400 Subject: [SC-L] 0x000000.com SuiGenchi Demonstration Message-ID: <47DD47BB.2010901@secureconsulting.net> Has anybody had opportunity to look at this tool for PHP source code analysis? Just wondering about the relative merits vs other tools already available. http://www.0x000000.com/?i=530 -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] "Think off-center." George Carlin From Jeremy.Epstein at softwareag.com Fri Mar 14 14:43:24 2008 From: Jeremy.Epstein at softwareag.com (Epstein, Jeremy) Date: Fri, 14 Mar 2008 15:43:24 -0400 Subject: [SC-L] Bringing two threads together: PCI & SXSW Message-ID: I've been backlogged, and just caught up on this list. One of the advantages of reading the list in batch mode is that it's easier to see parallels that are missed when you're in the weeds. So I'd like to bring together two threads: "PCI: Boon or bust for software security" and "quick question - SXSW". In gross terms, the conclusion of the former thread was that PCI has done more harm than good by giving checklists instead of addressing real problems, while the conclusion of the latter thread is that real developers don't care about software security. To the first of these, I offer a contrary view: PCI has been generally a Good Thing, although it's had some weird and unexpected side-effects. Working for a vendor whose products frequently come under the PCI microscope, it's given me leverage to get problems addressed in ways that weren't previously possible. Most customers previously wouldn't do any meaningful look at the security of our product. Those few who did would say "we'd like you to fix this security problem", but then didn't have the backbone to insist that the problem get solved. PCI has forced a much larger fraction of customers to pay attention to software security (even though what they're looking for is grossly incomplete), and because they can't get PCI approval without the fixes, it's given them the backbone to insist on solutions. That helps me, as the advocate for security, get problems fixed - and indirectly helps them because further down the road there will (hopefully) be fewer problems. The SXSW thread ties in directly - by having things like PCI making demands of vendors, even if indirectly, they're forcing the developers who attend SXSW to start paying attention to software security. No, they may not be there today, and they may not want to pay attention. But things are changing as a result of PCI (and the time spent fixing problems for PCI compliance), and I (hope) that in another year we'll see more real interest in software security. By contrast to PCI, I'd say SOX has been a total disaster for security - all the SOX money went into consultants who prepared checklists of meaningless stuff. While PCI isn't perfect, at least *most* of what it's looking for is rational. --Jeremy P.S. The "weird side effects" I mentioned for PCI include things like Qualys becoming the de facto definition of compliance - if Qualys says there's a problem, then by definition there is. When Qualys has false positives (and they occasionally do), we sometimes end up "fixing" the problem to avoid their false positive, since Qualys has no particular incentive to fix it, and the customer can't get their PCI sticker without Qualys signing off. Jeremy Epstein Senior Director, Product Security & Performance Software AG P +1 703.460.5852 | C +1 703.989.8907 AIM jeremyepstein | Skype jjepstein www.SoftwareAG.com "Those who would sacrifice system security for convenience deserve neither." Personal blog: http://abqordia.blogspot.com/ From vanderaj at owasp.org Wed Mar 26 17:02:56 2008 From: vanderaj at owasp.org (Andrew van der Stock) Date: Wed, 26 Mar 2008 18:02:56 -0400 Subject: [SC-L] quick question - SXSW In-Reply-To: References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <490a979e0803121505w4d3ee137vfe58205d359476a2@mail.gmail.com> Message-ID: <11604BAF-A8F6-4FFF-9C84-BA76743E60F5@owasp.org> Hi all, I have been specifically targeting developer conferences these last twelve months. I've had rejections from the likes of OSCON, and in fact, I was rejected from BlackHat, too. I have worked out the pattern to these conferences. You gotta SEX IT UP. Instead of submitting talks like "Safe Ajax Coding Techniques" or "Securely using mainframe transactions in your web app", submit talks that are titled: "How we pillage your app, identity rape your users, steal all your money, and retire in the Caribbean with the loot" Then when you get there, start with a demo or three to end all demos. Totally scare them witless. Followed by a picture of a girly drink with an umbrella in it with a beach in the background, and take the girly drink to the talk, too. Once you've put the fear of god (or at least malicious attackers) into them, then you can: * Do the talk you had in mind all along ("Securely using mainframe ..."), and they'll learn what they needed to learn by attending your talk. This is not to say you should be a boring presenter, but we shouldn't shy away from saying to developers that they MUST do this stuff, or they'll be pwned. Just before the folks fill in their presenter feedback forms, do an ASTONISHING demo. Something they will remember when they're filling in the feedback. When you're at the top of the feedback pile, you'll get invited back. The program committees for these trendy conferences - with some very notable exceptions - are for the most part just as hostile / apathetic / know little about security as the attendees. Sometimes worse - many are truly hostile to security as it gets in the way of their "fast and crappy beats correct every time" mindset. So make your submission interesting to the program committee, so much so that they want to come see it, too. Once they start accepting the talks, sooner or later, after 10 years or so, we'll be able to submit the useful talks without any such cover. See the design pattern folks for proof. Arian - ARGH! Tell Anurag to check out ESAPI - it has already hard core white list encoding, direct object reference maps, easy user object manipulation (logout that actually does the right thing with one call, etc), safe system(), encrypted property files, integrity protection and encryption for hidden fields and cookies, and so on and on and on. Encoder:: canonicalize() Simplifies percent-encoded and entity-encoded characters to their simplest form so that they can be properly validated. decodeFromBase64() Decode data encoded with BASE-64 encoding. decodeFromURL() Decode from URL. encodeForBase64() Encode for base64. encodeForDN() Encode data for use in an LDAP distinguished name. encodeForHTML() Encode data for use in HTML content. encodeForHTMLAttribute() Encode data for use in HTML attributes. encodeForJavascript() Encode for javascript. encodeForLDAP() Encode data for use in LDAP queries. encodeForSQL() This method is not recommended. encodeForURL() Encode for use in a URL. encodeForVBScript() Encode data for use in visual basic script. encodeForXML() Encode data for use in an XML element. encodeForXMLAttribute() Encode data for use in an XML attribute. encodeForXPath() This implementation encodes almost everything and may overencode. normalize() Normalizes special characters down to ASCII using the Normalizer built into Java. It's already done! However, there's more to do - let's work together on those gaps (client AJAX ESAPI) instead of re-inventing the wheel. thanks, Andrew On Mar 13, 2008, at 4:11 AM, Arian J. Evans wrote: > and Anurag will be releasing some APIs > for java developers to actually do things like output encoding, > where Java/J2EE is about 4 years behind the rest of the world. thanks, Andrew van der Stock Lead Author, OWASP Guide and OWASP Top 10 From vanderaj at owasp.org Wed Mar 26 18:32:37 2008 From: vanderaj at owasp.org (Andrew van der Stock) Date: Wed, 26 Mar 2008 19:32:37 -0400 Subject: [SC-L] Silver Bullet turns 2: Mary Ann Davidson In-Reply-To: References: Message-ID: <2E0A56DD-FF3F-470F-A02B-1CA6881E28BE@owasp.org> Gary, Good interview. The discussion on being unable to develop trust relationships with contractors who release exploits was interesting, and I wished that there was more discussion on that point. I would have thought signing a contract made it easier to sue for breach of contract than untested laws (or bad laws like the UK's RIPA), so much so you'd really think twice as well as the negative downside of being considered untrustworthy with confidential data - which is like a plague to any consultancy business. I really wish Ms Davidson had gone into detail on their SDL, as to what is really in there, and where we could read it and review it. Oracle's is an interesting turn around considering back in 2005 / 2006, the research community and Oracle's relationship was at an all time low, essentially begging Oracle to put in an SDL and address the security defects properly without outside folks finding them first. I have since read that fences have been somewhat mended between researchers, such as David Litchfield, and Oracle. I still wince at that episode - it was entirely unprofessional of Oracle to attack Litchfield, who was practicing responsible disclosure for up to 600-800 days, when 30 is the norm. I personally was extremely unimpressed with Oracle's approach of shooting the messenger rather than fixing the product. I must admit that episode led me to dismiss Oracle as the walking dead as they obviously couldn't be trusted with data of value, and so didn't follow news about Oracle ... until this interview. I'm glad they're now using automated SCA tools and fuzzers, they're now finding most of the security issues themselves, have an internal review team, and my personal favorite - developer awareness / education. This is a 180 degree turnaround from the prior to 2005/2006 era. I particularly like that she's going to the universities and ask them to teach coding security. This is what they SHOULD have been doing rather than attacking the research community. I'm glad that Oracle is now drinking the kool aid and treating security as a fundamental software engineering requirement. It's about time. thanks, Andrew van der Stock Lead Author, OWASP Guide to Writing Secure Applications and OWASP Top 10 From stephencraig.evans at gmail.com Fri Apr 4 00:19:01 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Fri, 4 Apr 2008 13:19:01 +0800 Subject: [SC-L] Silver Bullet turns 2: Mary Ann Davidson In-Reply-To: References: <2E0A56DD-FF3F-470F-A02B-1CA6881E28BE@owasp.org> Message-ID: <930fd0230804032219o17420c4bs70d17d50f806fd63@mail.gmail.com> Gary, Great interview. You've had some powerhouse interviews recently, for example with Chris Wysopal ("my dream is that a static tool can fix business logic flaws") and Ed Amoroso ("security researchers are the bomb defusers of the Internet"). I laughed at your blunt comment: "that would be great (everybody doing software assurance in 5 years) but also impossible". Andrew, in addition to your points: - I liked her self-deprecating humor when she talked about her coding skills - I think she made a justified, underhanded jab at the appsec community to make our stuff easier to use when she said: (At 4m 55sec) "There are a lot of people who are very well-intended and very sharp who come up with laundry lists of 8000 good things that we should do in security and all these things we should be doing and all these metrics ? and that's all great, but then ... what is the benefit for the cost of getting that information?" and "the do-gooders, and in this case I mean it in a good sense, need to do is to help people figure out what are the most important things to do first so that they'll get the biggest bang for the buck". - I liked her point, using a military analogy, is that products should be self-defended. Cheers, Stephen --------------------------------------------------- From: Andrew van der Stock Date: Thu, Mar 27, 2008 at 7:32 AM Subject: Re: [SC-L] Silver Bullet turns 2: Mary Ann Davidson To: Gary McGraw Cc: Kathy Clark-Fisher , Mary Ann Davidson , Secure Mailing List Gary, Good interview. The discussion on being unable to develop trust relationships with contractors who release exploits was interesting, and I wished that there was more discussion on that point. I would have thought signing a contract made it easier to sue for breach of contract than untested laws (or bad laws like the UK's RIPA), so much so you'd really think twice as well as the negative downside of being considered untrustworthy with confidential data - which is like a plague to any consultancy business. I really wish Ms Davidson had gone into detail on their SDL, as to what is really in there, and where we could read it and review it. Oracle's is an interesting turn around considering back in 2005 / 2006, the research community and Oracle's relationship was at an all time low, essentially begging Oracle to put in an SDL and address the security defects properly without outside folks finding them first. I have since read that fences have been somewhat mended between researchers, such as David Litchfield, and Oracle. I still wince at that episode - it was entirely unprofessional of Oracle to attack Litchfield, who was practicing responsible disclosure for up to 600-800 days, when 30 is the norm. I personally was extremely unimpressed with Oracle's approach of shooting the messenger rather than fixing the product. I must admit that episode led me to dismiss Oracle as the walking dead as they obviously couldn't be trusted with data of value, and so didn't follow news about Oracle ... until this interview. I'm glad they're now using automated SCA tools and fuzzers, they're now finding most of the security issues themselves, have an internal review team, and my personal favorite - developer awareness / education. This is a 180 degree turnaround from the prior to 2005/2006 era. I particularly like that she's going to the universities and ask them to teach coding security. This is what they SHOULD have been doing rather than attacking the research community. I'm glad that Oracle is now drinking the kool aid and treating security as a fundamental software engineering requirement. It's about time. thanks, Andrew van der Stock Lead Author, OWASP Guide to Writing Secure Applications and OWASP Top 10 _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080404/d8e13036/attachment.html From gem at cigital.com Fri Apr 4 07:24:52 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 4 Apr 2008 08:24:52 -0400 Subject: [SC-L] Silver Bullet turns 2: Mary Ann Davidson In-Reply-To: <930fd0230804032219o17420c4bs70d17d50f806fd63@mail.gmail.com> Message-ID: Thanks for the feedback Stephen. It's been a blast doing Silver Bullet for the last two years. For our next episode, I'm going to interview Jon Swartz who covers security for USA Today. That should be a twist! We're also planning to syndicate Silver Bullet through informIT soon. gem p.s. Can we have your permission to post this comment on the SB page? http://www.cigital.com/~gem On 4/4/08 1:19 AM, "Stephen Craig Evans" wrote: Gary, Great interview. You've had some powerhouse interviews recently, for example with Chris Wysopal ("my dream is that a static tool can fix business logic flaws") and Ed Amoroso ("security researchers are the bomb defusers of the Internet"). I laughed at your blunt comment: "that would be great (everybody doing software assurance in 5 years) but also impossible". Andrew, in addition to your points: - I liked her self-deprecating humor when she talked about her coding skills - I think she made a justified, underhanded jab at the appsec community to make our stuff easier to use when she said: (At 4m 55sec) "There are a lot of people who are very well-intended and very sharp who come up with laundry lists of 8000 good things that we should do in security and all these things we should be doing and all these metrics - and that's all great, but then ... what is the benefit for the cost of getting that information?" and "the do-gooders, and in this case I mean it in a good sense, need to do is to help people figure out what are the most important things to do first so that they'll get the biggest bang for the buck". - I liked her point, using a military analogy, is that products should be self-defended. Cheers, Stephen --------------------------------------------------- From: Andrew van der Stock Date: Thu, Mar 27, 2008 at 7:32 AM Subject: Re: [SC-L] Silver Bullet turns 2: Mary Ann Davidson To: Gary McGraw Cc: Kathy Clark-Fisher , Mary Ann Davidson , Secure Mailing List Gary, Good interview. The discussion on being unable to develop trust relationships with contractors who release exploits was interesting, and I wished that there was more discussion on that point. I would have thought signing a contract made it easier to sue for breach of contract than untested laws (or bad laws like the UK's RIPA), so much so you'd really think twice as well as the negative downside of being considered untrustworthy with confidential data - which is like a plague to any consultancy business. I really wish Ms Davidson had gone into detail on their SDL, as to what is really in there, and where we could read it and review it. Oracle's is an interesting turn around considering back in 2005 / 2006, the research community and Oracle's relationship was at an all time low, essentially begging Oracle to put in an SDL and address the security defects properly without outside folks finding them first. I have since read that fences have been somewhat mended between researchers, such as David Litchfield, and Oracle. I still wince at that episode - it was entirely unprofessional of Oracle to attack Litchfield, who was practicing responsible disclosure for up to 600-800 days, when 30 is the norm. I personally was extremely unimpressed with Oracle's approach of shooting the messenger rather than fixing the product. I must admit that episode led me to dismiss Oracle as the walking dead as they obviously couldn't be trusted with data of value, and so didn't follow news about Oracle ... until this interview. I'm glad they're now using automated SCA tools and fuzzers, they're now finding most of the security issues themselves, have an internal review team, and my personal favorite - developer awareness / education. This is a 180 degree turnaround from the prior to 2005/2006 era. I particularly like that she's going to the universities and ask them to teach coding security. This is what they SHOULD have been doing rather than attacking the research community. I'm glad that Oracle is now drinking the kool aid and treating security as a fundamental software engineering requirement. It's about time. thanks, Andrew van der Stock Lead Author, OWASP Guide to Writing Secure Applications and OWASP Top 10 _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From arian.evans at anachronic.com Fri Apr 4 16:28:58 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Fri, 4 Apr 2008 14:28:58 -0700 Subject: [SC-L] Silver Bullet turns 2: Mary Ann Davidson In-Reply-To: <930fd0230804032219o17420c4bs70d17d50f806fd63@mail.gmail.com> References: <2E0A56DD-FF3F-470F-A02B-1CA6881E28BE@owasp.org> <930fd0230804032219o17420c4bs70d17d50f806fd63@mail.gmail.com> Message-ID: I'll second this Gary. You've done nice work here. I think Mary Ann's comments are some of the most interesting concerning what our industry needs to focus on in the near future. (and I'd love to see you focus on this with your series) Her comments reminded me of a discussion on this list with Wysopal a year or so ago. Wysopal described defect detection in manufacturing, and gave software security analogues. This resonates with me as I'm fond of using analogues to airplane manufacturing, construction, and testing to explain what a software SDL should look like, and where/why whitebox, blackbox, and static analysis could and should fit in a mature SDL model. And how you evaluate/prioritize assets and costs. Important to this discussion is the vastly different degrees of defect detection we perform on human transport planes versus, say model airplanes, where the threat profile is (obviously) reduced. Yet in software, security folks at many organizations have a very hard time deciding which planes have more valuable payloads. What defect to address? The buffer overflow on the Tandems (that no one knows how to write shellcode for)? The SQL injection on the public content DB? The non-persistent XSS buried deep in the application? HTTP control-character injection in the caching proxy? Prioritization difficulty... Mary Ann is asking for metrics, including cost, and some measure of threat profiles from which to calculate or estimate the risk presented by defects. Ultimately I think we all want some sort of priority weighting by which to make better decisions about which defects are important, what our executive next-actions are, what to filter, etc. But this can't come from software analysis. This must come from organizational measurement data. The problem is, nobody in our industry has good data on what those metrics are. Many of us have little slices, but there is no universal repository for sharing all of that information (which is needed). The software-security marketing industry has relied as a crutch on software-defect cost-analysis studies done by large accounting consulting firms that have a vested interest in puffing up the "discovered" costs, so that they can sell multi-million-dollar, multi-year, software defect-reduction projects to their clients that are reading those reports. I don't think those reports have much to do with our industry. (We're all aware of the "we reduced 1 bug per 10 lines of code saving the customer millions" games those consultancies play, right?) We really need to know: Threat: + What are the attackers going after? + What is being attacked and how often? + What is being lost? Attack Surface: + What attacks are successful and how often? + What are the most common attacks? + What are the most common/successful targets? Then we need to map this back into software design patterns and implementation practices, and generate some metrics around costs to: + hotfix & support + release-fix and regression test + redesign and re-implement In the manufacturing world, the people who analyze this data are the actuaries or the government regulatory agencies. We have neither insurance or regulation to drive this. We also need to see if it really costs more to fix code after-the-fact, versus avoidance up front. I suspect this up-front avoidance is still cheaper with unmanaged code products, and maybe with all design issues. In the web software world, though, I think this is not always the case. (I suspect in the web world, especially with modern frameworks, it is just as cheap and easy to refactor/hotifx post-production software as it is to catch defects before final implementation or shipping code) Anyway -- there's a lot that has to happen to provide Mary with the data she wants (and indeed any smart CSO in an ISV should be asking for). In fact -- it's amazing we've improved so far, so fast, without even knowing what the tensile strength of our materials is, or having a concrete notion of what the cost of failure is in a final product. So where will this come from? Insurance? Regulation? Industry self-policing project? Is someone here working on this today? Cheers. Ciao -- -- Arian Evans, software security stuff On Thu, Apr 3, 2008 at 10:19 PM, Stephen Craig Evans wrote: > > Gary, > > Great interview. You've had some powerhouse interviews recently, for example > with Chris Wysopal ("my dream is that a static tool can fix business logic > flaws") and Ed Amoroso ("security researchers are the bomb defusers of the > Internet"). > > I laughed at your blunt comment: "that would be great (everybody doing > software assurance in 5 years) but also impossible". > > Andrew, in addition to your points: > > - I liked her self-deprecating humor when she talked about her coding skills > > - I think she made a justified, underhanded jab at the appsec community to > make our stuff easier to use when she said: > (At 4m 55sec) "There are a lot of people who are very well-intended and very > sharp who come up with laundry lists of 8000 good things that we should do > in security and all these things we should be doing and all these metrics ? > and that's all great, but then ... what is the benefit for the cost of > getting that information?" and "the do-gooders, and in this case I mean it > in a good sense, need to do is to help people figure out what are the most > important things to do first so that they'll get the biggest bang for the > buck". > > - I liked her point, using a military analogy, is that products should be > self-defended. > > Cheers, > Stephen > > --------------------------------------------------- > From: Andrew van der Stock > Date: Thu, Mar 27, 2008 at 7:32 AM > Subject: Re: [SC-L] Silver Bullet turns 2: Mary Ann Davidson > To: Gary McGraw > Cc: Kathy Clark-Fisher , Mary Ann Davidson > , Secure Mailing List > > > > > > Gary, > > Good interview. > > The discussion on being unable to develop trust relationships with > contractors who release exploits was interesting, and I wished that > there was more discussion on that point. I would have thought signing > a contract made it easier to sue for breach of contract than untested > laws (or bad laws like the UK's RIPA), so much so you'd really think > twice as well as the negative downside of being considered > untrustworthy with confidential data - which is like a plague to any > consultancy business. > > I really wish Ms Davidson had gone into detail on their SDL, as to > what is really in there, and where we could read it and review it. > > Oracle's is an interesting turn around considering back in 2005 / > 2006, the research community and Oracle's relationship was at an all > time low, essentially begging Oracle to put in an SDL and address the > security defects properly without outside folks finding them first. > > I have since read that fences have been somewhat mended between > researchers, such as David Litchfield, and Oracle. I still wince at > that episode - it was entirely unprofessional of Oracle to attack > Litchfield, who was practicing responsible disclosure for up to > 600-800 days, when 30 is the norm. I personally was extremely > unimpressed with Oracle's approach of shooting the messenger rather > than fixing the product. > > I must admit that episode led me to dismiss Oracle as the walking dead > as they obviously couldn't be trusted with data of value, and so > didn't follow news about Oracle ... until this interview. > > I'm glad they're now using automated SCA tools and fuzzers, they're > now finding most of the security issues themselves, have an internal > review team, and my personal favorite - developer awareness / > education. This is a 180 degree turnaround from the prior to 2005/2006 > era. I particularly like that she's going to the universities and ask > them to teach coding security. This is what they SHOULD have been > doing rather than attacking the research community. > > I'm glad that Oracle is now drinking the kool aid and treating > security as a fundamental software engineering requirement. It's about > time. > > thanks, > Andrew van der Stock > Lead Author, OWASP Guide to Writing Secure Applications and OWASP Top 10 > From arian.evans at anachronic.com Fri Apr 4 19:39:56 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Fri, 4 Apr 2008 17:39:56 -0700 Subject: [SC-L] Silver Bullet turns 2: Mary Ann Davidson In-Reply-To: <47F6A2BD.1090903@oracle.com> References: <2E0A56DD-FF3F-470F-A02B-1CA6881E28BE@owasp.org> <930fd0230804032219o17420c4bs70d17d50f806fd63@mail.gmail.com> <47F6A2BD.1090903@oracle.com> Message-ID: Mary -- Thank you for your reply and clarification. I am 100% on board with you about folks inventing taxonomies and then telling business owners and developers what artifacts they need to look for, measure, etc. without any real cost or business justification with regards to to your costs vs. return to track/measure in the first place, let alone *why* to fix them. I lumped a few things together which I shouldn't have... Defect decision making: Most organizations involved in the care and feeding of business software, whether or not they produced it, are still stuck at the instance level of "do I fix this vulnerabilitly/asset now or later"? You are at an entirely different level as a large producer. As one of the largest ISVs -- you likely have very different needs and perspectives. e.g.- you might be able to bear the cost of deeper software defect analysis than most software consumer organizations, due to the huge cost of regression testing and/or the support costs of post-hotfix deployments if they break things. The above is just a guess on my part, but we all know that hotfixing running production database servers is not the same game as implementing output encoding on a web application search field. Anyway, long and short, like Andrew and others -- those of us in the pragmatic "good enough" & "daily increments" security camps would love for you to share more of your experiences with this, Oracle's SDL journey, etc. and add that to our growing pool of what we know about this. A lot of what I mentioned we need to gather/answer is really more for the consumers of your software, writing their custom code on top of it, and then trying to operate in a reasonably safe manner while making money. As an ISV you have a slightly different operating model and bottom line, and you probably are afforded less ability to use temporary band-aids or mitigation steps versus flat-out fixing your software. Not everyone has to "fix" all their software, or make it self-defending. Which is ironic considering I used to present on the notion of "self-defending web applications', and help people implement SDLs. But I've become less of a purist now that I'm trying to help people secure dozens to hundreds of applications at once, with limited time and budget. It's hard not to feel like a charlatan when you can't give the business folks hard metrics on defect implications, failure costs, let alone just the cost of measurement vs. potential return. Thank you for doing Gary's interview, and the stimulating thoughts. Have a good weekend all. Come see me at RSA if any of you SC-L'ers are around. I'll be putting people to sleep with a talk on encoding, transcoding, and cannonicalization issues in our software (and WAFs :). (At RSA. Lol.) Ciao -ae On Fri, Apr 4, 2008 at 2:50 PM, mary.ann davidson wrote: > > Hi Arian > > Thanks for your comments. > > Just to clarify, I was not trying to look at this at the micro level of > should we "fix buffer overflows or fix SQL injections?" We (collectively) > now have pretty good tools that can find exploitable defects in software and > the answer is, if it is exploitable you fix it, and if it is just poor > coding practice (but not exploitable) you still probably should fix it, > albeit maybe not with same urgency as "exploitable defect" and you may only > fix it going forward. > > My issue is people who invent 50,000 idealogically pure development > practices, or artifacts or metrics that someone might want you to produce > (often, somoene who is an academic or a think tank person), and never look > at "Ok, what does it cost me to capture that information? Will being able to > "measure" X or create a metric help me actually manage better? If I can't > have a theologically perfect development process (and who does?), then what > are the best things to do to actually improve?" The perfect is really the > enemy of the good or the enemy of the "better." > > I like a lot of your suggestions after "We really need to know...". I do > realize that as you close one attack vector, persistent enemies will try > something new. But one of the reasons I do feel strongly about "get the > dreck out of the code base" is that, all things being equal, forcing > attackers to work harder is a good thing. Also, reducing customers' "cost of > security operations" (through higher security-worthy, more resilient code) > is a good thing because resources are always constrained, and the resources > people spend on patching, and/or random third party "add security" > appliances and software takes scarce resources that might be put to better > uses. > > If the Army has tank crews of 12, and 10 of them are busy fixing the tank > treads because they keep slipping off, they aren't going to be too ready to > fight an actual battle. > > Regards - > > Mary Ann > > > > Arian J. Evans wrote: > > I'll second this Gary. You've done nice work here. > > I think Mary Ann's comments are some of the most > interesting concerning what our industry needs to > focus on in the near future. (and I'd love to see you > focus on this with your series) > > Her comments reminded me of a discussion on this > list with Wysopal a year or so ago. > > Wysopal described defect detection in manufacturing, > and gave software security analogues. This resonates > with me as I'm fond of using analogues to airplane > manufacturing, construction, and testing to explain > what a software SDL should look like, and where/why > whitebox, blackbox, and static analysis could and > should fit in a mature SDL model. And how you > evaluate/prioritize assets and costs. > > Important to this discussion is the vastly different > degrees of defect detection we perform on human > transport planes versus, say model airplanes, > where the threat profile is (obviously) reduced. > > Yet in software, security folks at many organizations > have a very hard time deciding which planes have > more valuable payloads. What defect to address? > > The buffer overflow on the Tandems (that no one > knows how to write shellcode for)? The SQL injection > on the public content DB? The non-persistent XSS > buried deep in the application? HTTP control-character > injection in the caching proxy? Prioritization difficulty... > > Mary Ann is asking for metrics, including cost, and > some measure of threat profiles from which to > calculate or estimate the risk presented by defects. > > Ultimately I think we all want some sort of priority > weighting by which to make better decisions about > which defects are important, what our executive > next-actions are, what to filter, etc. > > But this can't come from software analysis. This > must come from organizational measurement data. > > The problem is, nobody in our industry has good > data on what those metrics are. Many of us have > little slices, but there is no universal repository > for sharing all of that information (which is needed). > > The software-security marketing industry has relied > as a crutch on software-defect cost-analysis studies > done by large accounting consulting firms that have > a vested interest in puffing up the "discovered" costs, > so that they can sell multi-million-dollar, multi-year, > software defect-reduction projects to their clients > that are reading those reports. > > I don't think those reports have much to do with > our industry. (We're all aware of the "we reduced > 1 bug per 10 lines of code saving the customer > millions" games those consultancies play, right?) > > We really need to know: > > Threat: > + What are the attackers going after? > + What is being attacked and how often? > + What is being lost? > > > Attack Surface: > + What attacks are successful and how often? > + What are the most common attacks? > + What are the most common/successful targets? > > Then we need to map this back into software > design patterns and implementation practices, > and generate some metrics around costs to: > > + hotfix & support > + release-fix and regression test > + redesign and re-implement > > In the manufacturing world, the people who > analyze this data are the actuaries or the > government regulatory agencies. We have > neither insurance or regulation to drive this. > > We also need to see if it really costs more > to fix code after-the-fact, versus avoidance > up front. I suspect this up-front avoidance is > still cheaper with unmanaged code products, > and maybe with all design issues. > > In the web software world, though, I think this > is not always the case. > > (I suspect in the web world, especially with > modern frameworks, it is just as cheap > and easy to refactor/hotifx post-production > software as it is to catch defects before final > implementation or shipping code) > > Anyway -- there's a lot that has to happen > to provide Mary with the data she wants > (and indeed any smart CSO in an ISV > should be asking for). > > In fact -- it's amazing we've improved so > far, so fast, without even knowing what > the tensile strength of our materials is, > or having a concrete notion of what the > cost of failure is in a final product. > > So where will this come from? > > Insurance? > > Regulation? > > Industry self-policing project? > > Is someone here working on this today? > > Cheers. Ciao > > > From seba at deleersnyder.eu Mon Apr 7 13:58:00 2008 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Mon, 7 Apr 2008 19:58:00 +0200 Subject: [SC-L] Invitation - OWASP AppSec Europe May 19-22 2008 - Belgium Message-ID: <6qb79d$37v4cj@relay.skynet.be> Hi, We would like to invite you to the European OWASP Application Security Conference! After successful OWASP Conferences in the United States (San Jose), Europe (Milan), Asia (Taiwan) and Australia (Queensland), we are back in Belgium: 5 tutorials and 2 conference tracks in the historic center of Ghent on May 19-22 2008! The conference is stuffed with top notch presentations from industry recognized speakers and technical experts on the latest application security risks and trends. Conference (May 21-22) Keynotes * The Great Information Security Scrap Yard Challenge (Mark Curphey) * Software Security: State of the Practice 2008 (Gary McGraw) Topics * The OWASP ESAPI project - Dave Wichers * Trends in Web Hacking Incidents: What's hot for 2008 - Ofer Shezaf * Evaluation Criteria for Web Application Firewalls - Ivan Ristic * HTML5 security - Thomas Roessler * The OWASP Orizon Project internals - Paolo Perego * Remo presentation (Input Validation) - Christian Folini * Best Practices Guide: Web Application Firewalls (OWASP German chapter) - Alexander Meisel * Google-Hacking and Google-Shielding - Amichai Shulman * NTLM Relay Attacks - Eric Rachner * The Law of Conservation of Bugs - Gunnar Peterson * Security in Agile Development - Dave Wichers * Security framework is not in the code - Sam Reghenzi * Exploiting Online Games - Gary McGraw * SHIELDS: metrics, tools and Internet services to improve security in application developments - Eva Coscia * Graph Analysis for WebApps: From Nodes to Edges - Simon Roses Femerling * The OWASP Education Project - Martin Knobloch * Dynamic Taint Propagation: Finding Vulnerabilities Without Attacking - Brian Chess * Threat Modeling for Application Designers & Architects - Shay Zalalichin * Scanstud: Evaluating static analysis tools - Martin Johns, * Office 2.0: Software as a Service, Security on the Sidelines? - John Heasman * How Data Privacy affects Applications and Databases - Dirk De Maeyer * The OWASP Anti-Samy project - Jason Li * Input validation: the Good, the Bad and the Ugly - Johan Peeters Refereed paper track * Refereed paper track keynote - Dieter Gollmann * Refereed paper track selections New for AppSec Europe: there is an expo with technical vendor demos and a Capture the Flag event! Tutorials (May 19-20) * Building and Testing Secure Web Applications * Leading the Development of Secure Applications * Building Secure Rich Internet Applications * Web Services and XML Security * Open Source ModSecurity Training OWASP Dinner (May 21) At every conference we have an evening social event the first night. They are always fun and allow participants to have some unstructured time to mingle with the other attendees. This year's event will be a Flemish buffet with special Belgian beers at the Monasterium (near the conference location). The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. More details and registration on http://www.owasp.org/index.php/AppSecEU08 Hope to see you all in May! Regards Sebastien Conference Committee OWASP Conferences Chair: Dave Wichers - Aspect Security - dave.wichers 'at' owasp.org 2008 EU Planning Committee Chair: Sebastien Deleersnyder - Telindus - seba 'at' owasp.org Vendor Exhibition Chair: Pravir Chandra - Cigital - chandra 'at' cigital.com Capture the Flag Chair: Pieter Danhieux - Ernst & Young - pieter.danhieux 'at' be.ey.com Refereed Papers Chair: Lieven Desmet - KU Leuven - Lieven.Desmet 'at' cs.kuleuv en.ac.be From gem at cigital.com Wed Apr 9 02:21:19 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 9 Apr 2008 02:21:19 -0400 Subject: [SC-L] InformIT: budgeting for software security Message-ID: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> Hi sc-l, Greetings from RSA. This year the marketing people outnumber the technical people 1000 to 1. There are over 18,000 people here. You do the math. I recently moved my monthly security column from darkreading to informIT. I am refocusing the column on software security and business. My first column just went live: http://www.informit.com/articles/article.aspx?p=1189519 It's about a business trick that Phil Venables uses with great success---that is, using TCO to drive security into software. This shows what you can accomplish with a combination of software insight and business acumen. I'm very much interested in your feedback on my move to informIT as well as the content of this first article. Let me know what you think. gem www.cigital.com/~gem From stephencraig.evans at gmail.com Wed Apr 9 22:03:13 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Thu, 10 Apr 2008 10:03:13 +0800 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> Message-ID: <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> Hi Gary, How can any security conference that has Al Gore as a keynote speaker be taken seriously? What does 'green technology' have to do with infosec? And why is his keynote the only one with the tag "*(Please note that this keynote session will not be available via webcast replay.)"? *Now there's openness for you (/sarc). What a joke. I'm looking forward to your new series of columns; they were getting too infrequent on Dark Reading. Cheers, Stephen On Wed, Apr 9, 2008 at 2:21 PM, Gary McGraw wrote: > Hi sc-l, > > Greetings from RSA. This year the marketing people outnumber the > technical people 1000 to 1. There are over 18,000 people here. You do the > math. > > I recently moved my monthly security column from darkreading to informIT. > I am refocusing the column on software security and business. > > My first column just went live: > http://www.informit.com/articles/article.aspx?p=1189519 > > It's about a business trick that Phil Venables uses with great > success---that is, using TCO to drive security into software. This shows > what you can accomplish with a combination of software insight and business > acumen. > > I'm very much interested in your feedback on my move to informIT as well > as the content of this first article. Let me know what you think. > > gem > > www.cigital.com/~gem > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080410/90addc7c/attachment.html From stephencraig.evans at gmail.com Thu Apr 10 09:50:49 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Thu, 10 Apr 2008 21:50:49 +0800 Subject: [SC-L] quick question - SXSW In-Reply-To: References: <48776.38.118.48.5.1205242996.squirrel@webmail.secureconsulting.net> <490a979e0803121505w4d3ee137vfe58205d359476a2@mail.gmail.com> <11604BAF-A8F6-4FFF-9C84-BA76743E60F5@owasp.org> Message-ID: <930fd0230804100650x6c2b0a27r6df7b6d4ea1386c6@mail.gmail.com> Hi Andrew, I was reminded of what you said in your post when I read the beginning of this prezo description from HITB 2007: "Using a lethal combination of various client side attacks we'll smash the same origin policy, punch our way through your firewall, and dropkick an Oracle database on your internal network (and we're NOT talking about SQL Injection!)." All good points you make that I'll keep in mind for my next attempt in SE Asia. Cheers, Stephen -------------------- > From: Andrew van der Stock > Date: Thu, Mar 27, 2008 at 6:02 AM > Subject: Re: [SC-L] quick question - SXSW > To: "Arian J. Evans" > Cc: Secure Coding Mailing List > > > Hi all, > > I have been specifically targeting developer conferences these last > twelve months. I've had rejections from the likes of OSCON, and in > fact, I was rejected from BlackHat, too. I have worked out the pattern > to these conferences. > > You gotta SEX IT UP. > > Instead of submitting talks like "Safe Ajax Coding Techniques" or > "Securely using mainframe transactions in your web app", submit talks > that are titled: > > "How we pillage your app, identity rape your users, steal all your > money, and retire in the Caribbean with the loot" > > Then when you get there, start with a demo or three to end all demos. > Totally scare them witless. Followed by a picture of a girly drink > with an umbrella in it with a beach in the background, and take the > girly drink to the talk, too. Once you've put the fear of god (or at > least malicious attackers) into them, then you can: > > * Do the talk you had in mind all along ("Securely using > mainframe ..."), and they'll learn what they needed to learn by > attending your talk. > > This is not to say you should be a boring presenter, but we shouldn't > shy away from saying to developers that they MUST do this stuff, or > they'll be pwned. > > Just before the folks fill in their presenter feedback forms, do an > ASTONISHING demo. Something they will remember when they're filling in > the feedback. When you're at the top of the feedback pile, you'll get > invited back. > > The program committees for these trendy conferences - with some very > notable exceptions - are for the most part just as hostile / > apathetic / know little about security as the attendees. Sometimes > worse - many are truly hostile to security as it gets in the way of > their "fast and crappy beats correct every time" mindset. So make your > submission interesting to the program committee, so much so that they > want to come see it, too. Once they start accepting the talks, sooner > or later, after 10 years or so, we'll be able to submit the useful > talks without any such cover. See the design pattern folks for proof. > > Arian - ARGH! Tell Anurag to check out ESAPI - it has already hard > core white list encoding, direct object reference maps, easy user > object manipulation (logout that actually does the right thing with > one call, etc), safe system(), encrypted property files, integrity > protection and encryption for hidden fields and cookies, and so on and > on and on. > > Encoder:: > canonicalize() Simplifies percent-encoded and entity-encoded > characters to their simplest form so that they can be properly > validated. > decodeFromBase64() Decode data encoded with BASE-64 encoding. > decodeFromURL() Decode from URL. > encodeForBase64() Encode for base64. > encodeForDN() Encode data for use in an LDAP distinguished > name. > encodeForHTML() Encode data for use in HTML content. > encodeForHTMLAttribute() Encode data for use in HTML attributes. > encodeForJavascript() Encode for javascript. > encodeForLDAP() Encode data for use in LDAP queries. > encodeForSQL() This method is not recommended. > encodeForURL() Encode for use in a URL. > encodeForVBScript() Encode data for use in visual basic script. > encodeForXML() Encode data for use in an XML element. > encodeForXMLAttribute() Encode data for use in an XML attribute. > encodeForXPath() This implementation encodes almost everything > and may overencode. > normalize() Normalizes special characters down to ASCII > using the Normalizer built into Java. > > It's already done! However, there's more to do - let's work together > on those gaps (client AJAX ESAPI) instead of re-inventing the wheel. > > thanks, > Andrew > > > On Mar 13, 2008, at 4:11 AM, Arian J. Evans wrote: > > and Anurag will be releasing some APIs > > for java developers to actually do things like output encoding, > > where Java/J2EE is about 4 years behind the rest of the world. > > > thanks, > Andrew van der Stock > Lead Author, OWASP Guide and OWASP Top 10 > > > > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080410/c86f94f8/attachment.html From jim at manico.net Thu Apr 10 15:57:12 2008 From: jim at manico.net (Jim Manico) Date: Thu, 10 Apr 2008 09:57:12 -1000 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> Message-ID: <47FE7118.6000100@manico.net> > What does 'green technology' have to do with infosec? Data centerers worldwide use at least 3% of all global electricity. With the growing cost of oil/power - most large corporations are looking for ways to reduce power consumption at their data centers. Google is building new database centers near cheap power, cheap land, and cheap water. Sun has "bet the farm" on Green issues. IBM and Intel have green/sustainability departments as well. http://www.baselinemag.com/c/a/Infrastructure/Disruptive-Forces-Sun-Microsystems/ - Jim > > Hi Gary, > > How can any security conference that has Al Gore as a keynote speaker > be taken seriously? What does 'green technology' have to do with > infosec? And why is his keynote the only one with the tag "/(Please > note that this keynote session will not be available via webcast > replay.)"? /Now there's openness for you (/sarc). What a joke. > > I'm looking forward to your new series of columns; they were getting > too infrequent on Dark Reading. > > Cheers, > Stephen > > On Wed, Apr 9, 2008 at 2:21 PM, Gary McGraw > wrote: > > Hi sc-l, > > Greetings from RSA. This year the marketing people outnumber the > technical people 1000 to 1. There are over 18,000 people here. > You do the math. > > I recently moved my monthly security column from darkreading to > informIT. I am refocusing the column on software security and > business. > > My first column just went live: > http://www.informit.com/articles/article.aspx?p=1189519 > > It's about a business trick that Phil Venables uses with great > success---that is, using TCO to drive security into software. > This shows what you can accomplish with a combination of software > insight and business acumen. > > I'm very much interested in your feedback on my move to informIT > as well as the content of this first article. Let me know what > you think. > > gem > > www.cigital.com/~gem > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080410/9e790d0a/attachment-0001.html From Kevin.Wall at qwest.com Fri Apr 11 09:14:54 2008 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Fri, 11 Apr 2008 08:14:54 -0500 Subject: [SC-L] InformIT: budgeting for software security References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com><930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> Message-ID: Jim, In response to Stephen's question, you wrote... >> What does 'green technology' have to do with infosec? > > Data centerers worldwide use at least 3% of all global electricity. With > the growing cost of oil/power - most large corporations are looking for > ways to reduce power consumption at their data centers. Google is > building new database centers near cheap power, cheap land, and cheap > water. Sun has "bet the farm" on Green issues. IBM and Intel have > green/sustainability departments as well. > > http://www.baselinemag.com/c/a/Infrastructure/Disruptive-Forces-Sun-Microsystems/ Maybe I need someone to connect the dots for me, but IMO, your response _still_ doesn't adequately answer Stephen's question. You addressed why 'green technology' is good in general and why businesses are pursuing it, but not what it has to do w/ information security. Certainly, if there is a connection here, is is not a direct one. I don't want to speak for Stephen (but will anyways ;-), but I think it's unfair to interpret his remark as implying that green technology is bad or some sort of voodoo. In the context, I think his concern was that in the past, the RSA conferences were focused on infosec, and on cryptography in particular. Apparently, based on Stephen and gem's comments, it seems to have lost its focus. I think that's all that was being implied here. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. Kevin.Wall at qwest.com Phone: 614.215.4788 "The reason you have people breaking into your software all over the place is because your software sucks..." -- Former White House cyber-security adviser, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From ljknews at mac.com Fri Apr 11 10:31:13 2008 From: ljknews at mac.com (ljknews) Date: Fri, 11 Apr 2008 10:31:13 -0400 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> Message-ID: At 8:14 AM -0500 4/11/08, Wall, Kevin wrote: > In the context, I think his concern was that in the past, the RSA > conferences were focused on infosec, and on cryptography in particular. Apparently, > based on Stephen and gem's comments, it seems to have lost its focus. I think > that's all that was being implied here. Some years ago at an RSA Conference I recall seeing Jefferson Starship. At least one song had altered lyrics for the GAK issue of the year, but that was not a whole lot of security content in a general session. -- Larry Kilgallen From gem at cigital.com Fri Apr 11 10:52:10 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 11 Apr 2008 10:52:10 -0400 Subject: [SC-L] InformIT: budgeting for software security Message-ID: <41945506397C0C4886A8C5BFF089B5CA310E05C9DD@va-mailhub.cigital.com> Hi all, Larry has it right. There was very little technical content at RSA this year. All of the vendors on the show floor had pitches that sounded exactly the same. Last year there was much more software security presence. The good news for our field is that at the (small) executive forum, there was a fair amount of discussion of software security. Justin Peavey from Omgeo put together a panel on software security that I helped with. That was good. Now attempting to fly home on the united cattle call cart. Moo gem ----- Original Message ----- From: sc-l-bounces at securecoding.org To: SC-L at securecoding.org Sent: Fri Apr 11 10:31:13 2008 Subject: Re: [SC-L] InformIT: budgeting for software security At 8:14 AM -0500 4/11/08, Wall, Kevin wrote: > In the context, I think his concern was that in the past, the RSA > conferences were focused on infosec, and on cryptography in particular. Apparently, > based on Stephen and gem's comments, it seems to have lost its focus. I think > that's all that was being implied here. Some years ago at an RSA Conference I recall seeing Jefferson Starship. At least one song had altered lyrics for the GAK issue of the year, but that was not a whole lot of security content in a general session. -- Larry Kilgallen _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From stephencraig.evans at gmail.com Fri Apr 11 11:34:08 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Fri, 11 Apr 2008 23:34:08 +0800 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: <47FE7118.6000100@manico.net> References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> Message-ID: <930fd0230804110834m5f794203q2a7e53488a53029b@mail.gmail.com> Hi Jim, I am an infosec newbie but a fierce historian. I have read your previous posts and I completely respect you. I cannot agree with your premise that resources are limited on Planet Earth. There are gobs and gobs of oil to be had within the boundaries of the United States but the eco-nazis have prevented it, hence creating $3 dollar gallon of gas and our dependence on very unsavoury characters. The same with nuclear power (look up a great George Gilder interview on itconversations.com). Of course, that's why all the big security vendors and their underlings (the mainstream press) create all of this hoopla; otherwise, they would be out of work. Cheers, Stephen P.S. Thanks to the Moderator for letting this through. On Fri, Apr 11, 2008 at 3:57 AM, Jim Manico wrote: > > What does 'green technology' have to do with infosec? > > Data centerers worldwide use at least 3% of all global electricity. With > the growing cost of oil/power - most large corporations are looking for ways > to reduce power consumption at their data centers. Google is building new > database centers near cheap power, cheap land, and cheap water. Sun has "bet > the farm" on Green issues. IBM and Intel have green/sustainability > departments as well. > > > http://www.baselinemag.com/c/a/Infrastructure/Disruptive-Forces-Sun-Microsystems/ > > - Jim > > > Hi Gary, > > How can any security conference that has Al Gore as a keynote speaker be > taken seriously? What does 'green technology' have to do with infosec? And > why is his keynote the only one with the tag "*(Please note that this > keynote session will not be available via webcast replay.)"? *Now there's > openness for you (/sarc). What a joke. > > I'm looking forward to your new series of columns; they were getting too > infrequent on Dark Reading. > > Cheers, > Stephen > > On Wed, Apr 9, 2008 at 2:21 PM, Gary McGraw wrote: > > > Hi sc-l, > > > > Greetings from RSA. This year the marketing people outnumber the > > technical people 1000 to 1. There are over 18,000 people here. You do the > > math. > > > > I recently moved my monthly security column from darkreading to > > informIT. I am refocusing the column on software security and business. > > > > My first column just went live: > > http://www.informit.com/articles/article.aspx?p=1189519 > > > > It's about a business trick that Phil Venables uses with great > > success---that is, using TCO to drive security into software. This shows > > what you can accomplish with a combination of software insight and business > > acumen. > > > > I'm very much interested in your feedback on my move to informIT as well > > as the content of this first article. Let me know what you think. > > > > gem > > > > www.cigital.com/~gem > > > > _______________________________________________ > > Secure Coding mailing list (SC-L) SC-L at securecoding.org > > List information, subscriptions, etc - > > http://krvw.com/mailman/listinfo/sc-l > > List charter available at - http://www.securecoding.org/list/charter.php > > SC-L is hosted and moderated by KRvW Associates, LLC ( > > http://www.KRvW.com) > > as a free, non-commercial service to the software security community. > > _______________________________________________ > > > > ------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > > > -- > Jim Manico, Senior Application Security Engineerjim.manico at aspectsecurity.com > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the sourcehttp://www.aspectsecurity.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080411/d426fadf/attachment.html From jim at manico.net Fri Apr 11 15:53:33 2008 From: jim at manico.net (Jim Manico) Date: Fri, 11 Apr 2008 09:53:33 -1000 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com><930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> Message-ID: <47FFC1BD.3050108@manico.net> No, there is not a direct connection but Green and InfoSec do have a few degrees of connection. InfoSec -> Is a part of -> IT -> manages -> Datacenters -> suck up 3% of word power -> is becoming more expensive - > Green - > Al Gore > RSA conferences *were *focused on infosec, and on cryptography in particular RSA is a Marketing/Fluff event - As Gary pointed out, there is a 1000-1 "Marketer vs attendee" ratio. Case and point: SANS is teaching there now! :D - Jim > Jim, > > In response to Stephen's question, you wrote... > > >>> What does 'green technology' have to do with infosec? >>> >> Data centerers worldwide use at least 3% of all global electricity. With >> the growing cost of oil/power - most large corporations are looking for >> ways to reduce power consumption at their data centers. Google is >> building new database centers near cheap power, cheap land, and cheap >> water. Sun has "bet the farm" on Green issues. IBM and Intel have >> green/sustainability departments as well. >> >> http://www.baselinemag.com/c/a/Infrastructure/Disruptive-Forces-Sun-Microsystems/ >> > > Maybe I need someone to connect the dots for me, but IMO, your response > _still_ doesn't adequately answer Stephen's question. > > You addressed why 'green technology' is good in general and why businesses > are pursuing it, but not what it has to do w/ information security. Certainly, > if there is a connection here, is is not a direct one. > > I don't want to speak for Stephen (but will anyways ;-), but I think it's unfair > to interpret his remark as implying that green technology is bad or some sort > of voodoo. In the context, I think his concern was that in the past, the RSA > conferences were focused on infosec, and on cryptography in particular. Apparently, > based on Stephen and gem's comments, it seems to have lost its focus. I think > that's all that was being implied here. > > -kevin > --- > Kevin W. Wall Qwest Information Technology, Inc. > Kevin.Wall at qwest.com Phone: 614.215.4788 > "The reason you have people breaking into your software all > over the place is because your software sucks..." > -- Former White House cyber-security adviser, Richard Clarke, > at eWeek Security Summit > > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080411/d3aa9f15/attachment.html From secureCoding2dave at davearonson.com Sat Apr 12 10:35:05 2008 From: secureCoding2dave at davearonson.com (Dave Aronson) Date: Sat, 12 Apr 2008 10:35:05 -0400 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: <47FFC1BD.3050108@manico.net> References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com><930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> <47FFC1BD.3050108@manico.net> Message-ID: <4800C899.3060401@davearonson.com> Jim Manico wrote: > Datacenters -> suck up 3% of word power Oh, that must explain why, as we become more and more dependent on companies with data centers, we find ourselves less and less able to actually communicate clearly with each other.... ;-) -Dave -- Dave Aronson "Specialization is for insects." -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ From stephencraig.evans at gmail.com Sun Apr 13 06:23:42 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Sun, 13 Apr 2008 18:23:42 +0800 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: <47FFC1BD.3050108@manico.net> References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> <47FFC1BD.3050108@manico.net> Message-ID: <930fd0230804130323j74de0a96n60cf865ad8bed2d2@mail.gmail.com> Hi Jim, Wow, that's a flimsy connect-the-dots if I've ever seen one :-) We could have fun with this but I don't want to stray 100% off-topic (if we not there already). Very coincidentally, I watched South Park Season 10 Episode 6 after my first post. I rest my case. I'm sure Al Gore's appearance was a pure Left Coast feel-good kumbaya "we're doing something to help because we care" type of deal. I hope you don't take my criticism too serially. > As Gary pointed out, there is a 1000-1 "Marketer vs attendee" ratio I guess the bright side is that the female to male ratio was a bit more even :-) Cheers, Stephen On Sat, Apr 12, 2008 at 3:53 AM, Jim Manico wrote: > No, there is not a direct connection but Green and InfoSec do have a few > degrees of connection. > > InfoSec -> Is a part of -> IT -> manages -> Datacenters -> suck up 3% of > word power -> is becoming more expensive - > Green - > Al Gore > > > RSA conferences *were *focused on infosec, and on cryptography in > particular > > RSA is a Marketing/Fluff event - As Gary pointed out, there is a 1000-1 > "Marketer vs attendee" ratio. Case and point: SANS is teaching there now! :D > > - Jim > > > Jim, > > In response to Stephen's question, you wrote... > > > > What does 'green technology' have to do with infosec? > > > Data centerers worldwide use at least 3% of all global electricity. With > the growing cost of oil/power - most large corporations are looking for > ways to reduce power consumption at their data centers. Google is > building new database centers near cheap power, cheap land, and cheap > water. Sun has "bet the farm" on Green issues. IBM and Intel have > green/sustainability departments as well. > http://www.baselinemag.com/c/a/Infrastructure/Disruptive-Forces-Sun-Microsystems/ > > Maybe I need someone to connect the dots for me, but IMO, your response > _still_ doesn't adequately answer Stephen's question. > > You addressed why 'green technology' is good in general and why businesses > are pursuing it, but not what it has to do w/ information security. Certainly, > if there is a connection here, is is not a direct one. > > I don't want to speak for Stephen (but will anyways ;-), but I think it's unfair > to interpret his remark as implying that green technology is bad or some sort > of voodoo. In the context, I think his concern was that in the past, the RSA > conferences were focused on infosec, and on cryptography in particular. Apparently, > based on Stephen and gem's comments, it seems to have lost its focus. I think > that's all that was being implied here. > > -kevin > --- > Kevin W. Wall Qwest Information Technology, Inc.Kevin.Wall at qwest.com Phone: 614.215.4788 > "The reason you have people breaking into your software all > over the place is because your software sucks..." > -- Former White House cyber-security adviser, Richard Clarke, > at eWeek Security Summit > > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > > > > > -- > Jim Manico, Senior Application Security Engineer > jim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the sourcehttp://www.aspectsecurity.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080413/2468f03a/attachment.html From ken at krvw.com Sun Apr 13 13:51:14 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Sun, 13 Apr 2008 13:51:14 -0400 Subject: [SC-L] InformIT: budgeting for software security In-Reply-To: <930fd0230804130323j74de0a96n60cf865ad8bed2d2@mail.gmail.com> References: <41945506397C0C4886A8C5BFF089B5CA310B6D908B@va-mailhub.cigital.com> <930fd0230804091903l18dfafbat89ca0a852ac7f425@mail.gmail.com> <47FE7118.6000100@manico.net> <47FFC1BD.3050108@manico.net> <930fd0230804130323j74de0a96n60cf865ad8bed2d2@mail.gmail.com> Message-ID: <9F46592F-81E0-4685-9C01-90EBA7E5C504@krvw.com> On Apr 13, 2008, at 6:23 AM, Stephen Craig Evans wrote: > Wow, that's a flimsy connect-the-dots if I've ever seen one :-) We > could have fun with this but I don't want to stray 100% off-topic > (if we not there already). Let's let this thread die away, please folks. Unless any replies are directly tied to the topic of software/application security, they'll be dispatched directly to /dev/null. Thanks! Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080413/642105cf/attachment.bin From gem at cigital.com Sat Apr 19 09:40:01 2008 From: gem at cigital.com (Gary McGraw) Date: Sat, 19 Apr 2008 09:40:01 -0400 Subject: [SC-L] Silver Bullet 25: Jon Swartz Message-ID: hi sc-l, >From time to time on this list, we discuss how to take the software security message to a wider audience. Who better to ask that question of than a popular USA Today reporter? Jon Swartz just so happens to be one of those. He's covered security for a long time and won many accolades for his work. He Just wrote a book called "Zero Day Threat" about cybercrime that's well worth checking out. Hope you enjoy this episode: http://www.cigital.com/silverbullet/show-025/ By the way, unfortunately this show has the poorest sound quality we've ever managed to scrape up on silver bullet. We put a new laptop in the mix. Needless to say, using Dell products in your audio chain is a really bad idea! It won't happen again. gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Mon Apr 28 15:13:27 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 28 Apr 2008 15:13:27 -0400 Subject: [SC-L] Lateral SQL injection paper Message-ID: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> Greetings SC-Lers, Things have been pretty quiet here on the SC-L list... I hope everyone saw David Litchfield's recent announcement of a new category of SQL attacks. (Full paper available at http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) He refers to this new category as "lateral SQL injection" attacks. It's very different than conventional SQL injection attacks, as well as quite a bit more limited. In the paper, he writes: "Now, whether this becomes "exploitable" in the "normal" sense, I doubt it... but in very specific and limited scenarios there may be scope for abuse, for example in cursor snarfing attacks - http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf . In conclusion, even those functions and procedures that don?t take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and don?t let this type of vulnerability get into your code. The second lesson is that no longer should DATE or NUMBER data types be considered as safe and not useful as injection vectors: as this paper has proved, they are. " It's definitely an interesting read, and anyone doing SQL coding should take a close look, IMHO. It's particularly interesting to see how he alters the DATE and NUMBER data types so that they can hold SQL injection data. Yet another demonstration of the importance of doing good input validation -- preferably positive validation. As long as you're doing input validation, I'd think there's probably no need to back through your code and audit it for lateral SQL injection vectors. Anyone else have a take on this new attack method? (Note that I don't normally encourage discussions of specific product vulnerabilities here, but most certainly new categories of attacks--and their impacts on secure coding practices--are quite welcome.) Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080428/6e98d087/attachment.bin From jim at manico.net Mon Apr 28 15:27:58 2008 From: jim at manico.net (Jim Manico) Date: Mon, 28 Apr 2008 15:27:58 -0400 Subject: [SC-L] Lateral SQL injection paper In-Reply-To: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> Message-ID: <4816253E.5080503@manico.net> > Anyone else have a take on this new attack method? If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. In Java (for Insert/Update/etc) just use PreparedStatement + variable binding. There are similar constructs in all languages. Although the attack is cool - the defense is still the same. Grey Box Testing (code review and pen testing) will uncover all SQL Injection flaws in even the largest app in very little time. - Jim > Greetings SC-Lers, > > Things have been pretty quiet here on the SC-L list... > > I hope everyone saw David Litchfield's recent announcement of a new > category of SQL attacks. (Full paper available at > http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) > > He refers to this new category as "lateral SQL injection" attacks. > It's very different than conventional SQL injection attacks, as well > as quite a bit more limited. In the paper, he writes: > > "Now, whether this becomes "exploitable" in the "normal" sense, I > doubt it... but in very > specific and limited scenarios there may be scope for abuse, for > example in cursor > snarfing attacks - > http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf. > > In conclusion, even those functions and procedures that don?t take > user input can be > exploited if SYSDATE is used. The lesson here is always, always > validate and don?t let > this type of vulnerability get into your code. The second lesson is > that no longer should > DATE or NUMBER data types be considered as safe and not useful as > injection vectors: > as this paper has proved, they are. " > > > It's definitely an interesting read, and anyone doing SQL coding > should take a close look, IMHO. It's particularly interesting to see > how he alters the DATE and NUMBER data types so that they can hold SQL > injection data. Yet another demonstration of the importance of doing > good input validation -- preferably positive validation. As long as > you're doing input validation, I'd think there's probably no need to > back through your code and audit it for lateral SQL injection vectors. > > Anyone else have a take on this new attack method? (Note that I don't > normally encourage discussions of specific product vulnerabilities > here, but most certainly new categories of attacks--and their impacts > on secure coding practices--are quite welcome.) > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > SC-L Moderator > > KRvW Associates, LLC > http://www.KRvW.com > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080428/88b40127/attachment.html From arian.evans at anachronic.com Mon Apr 28 18:04:13 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Mon, 28 Apr 2008 15:04:13 -0700 Subject: [SC-L] Lateral SQL injection paper In-Reply-To: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> Message-ID: David's papers are always interesting, but I think the most interesting thing is that we are starting to see advanced SQL injection like his recent work on cursor attacks/snarfing being used in the wild in mass-SQL injection exploits. Attackers are using multiple layers of encoding for both reliability of delivery, and and for obfuscation (for all of you that rolled your eyes every time I've talked about this for the last five years :) and as a result are bypassing interface input validation and blacklists. The attackers are using common stuff for filter evasion like using char(127), then hex URI- escaping or hex encoding that (with \hex, HTML entity, decimal, whatever), and then sometimes URI encoding every character of the resultant string. Internal parsers canonicalize down to the SQL interpretable string (e.g.char(127)) and the SQL parser obviously makes a nice ' out of that. There are a lot more clever things going on with the exploits, some of which could be restricted by simple privilege. Anyway -- the black hat crowd is paying as much attention to the lastest exploit techniques, if not more, than most of us are. They are using them in the wild, right this second, to make money. Interesting work by David, for sure, and great ammo if we have to beat the "strong data typing" drum in our software. -- -- Arian J. Evans, software security stuff. I spend most of my money on motorcycles, mistresses, and martinis. The rest of it I squander. On Mon, Apr 28, 2008 at 12:13 PM, Kenneth Van Wyk wrote: > Greetings SC-Lers, > > Things have been pretty quiet here on the SC-L list... > > I hope everyone saw David Litchfield's recent announcement of a new > category of SQL attacks. (Full paper available at > http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) > > He refers to this new category as "lateral SQL injection" attacks. It's > very different than conventional SQL injection attacks, as well as quite a > bit more limited. In the paper, he writes: > > "Now, whether this becomes "exploitable" in the "normal" sense, I doubt > it... but in very > specific and limited scenarios there may be scope for abuse, for example in > cursor > snarfing attacks - > http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf.. > > In conclusion, even those functions and procedures that don't take user > input can be > exploited if SYSDATE is used. The lesson here is always, always validate > and don't let > this type of vulnerability get into your code. The second lesson is that no > longer should > DATE or NUMBER data types be considered as safe and not useful as injection > vectors: > as this paper has proved, they are. " > > > It's definitely an interesting read, and anyone doing SQL coding should > take a close look, IMHO. It's particularly interesting to see how he alters > the DATE and NUMBER data types so that they can hold SQL injection data. > Yet another demonstration of the importance of doing good input validation > -- preferably positive validation. As long as you're doing input > validation, I'd think there's probably no need to back through your code and > audit it for lateral SQL injection vectors. > > Anyone else have a take on this new attack method? (Note that I don't > normally encourage discussions of specific product vulnerabilities here, but > most certainly new categories of attacks--and their impacts on secure coding > practices--are quite welcome.) > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > SC-L Moderator > > KRvW Associates, LLC > http://www.KRvW.com > From joe at joeteff.com Tue Apr 29 03:09:27 2008 From: joe at joeteff.com (Joe Teff) Date: Tue, 29 Apr 2008 02:09:27 -0500 Subject: [SC-L] Lateral SQL injection paper In-Reply-To: <4816253E.5080503@manico.net> References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> <4816253E.5080503@manico.net> Message-ID: > If I use Parameterized queries w/ binding of all variables, I'm 100% > immune to SQL Injection. Sure. You've protected one app and transferred risk to any other process/app that uses the data. If they use that data to create dynamic sql, then what? jt -----Original Message----- From: Jim Manico To: Kenneth Van Wyk Cc: Secure Coding Date: Mon, 28 Apr 2008 15:27:58 -0400 Subject: Re: [SC-L] Lateral SQL injection paper > > Anyone else have a take on this new attack method? > > If I use Parameterized queries w/ binding of all variables, I'm 100% > immune to SQL Injection. > > In Java (for Insert/Update/etc) just use PreparedStatement + variable > binding. > > There are similar constructs in all languages. > > Although the attack is cool - the defense is still the same. > > Grey Box Testing (code review and pen testing) will uncover all SQL > Injection flaws in even the largest app in very little time. > > - Jim > > > > Greetings SC-Lers, > > > > Things have been pretty quiet here on the SC-L list... > > > > I hope everyone saw David Litchfield's recent announcement of a new > > category of SQL attacks. (Full paper available at > > http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) > > > > He refers to this new category as "lateral SQL injection" attacks. > > It's very different than conventional SQL injection attacks, as well > > as quite a bit more limited. In the paper, he writes: > > > > "Now, whether this becomes "exploitable" in the "normal" sense, I > > doubt it... but in very > > specific and limited scenarios there may be scope for abuse, for > > example in cursor > > snarfing attacks - > > http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf. > > > > In conclusion, even those functions and procedures that don?t take > > user input can be > > exploited if SYSDATE is used. The lesson here is always, always > > validate and don?t let > > this type of vulnerability get into your code. The second lesson is > > that no longer should > > DATE or NUMBER data types be considered as safe and not useful as > > injection vectors: > > as this paper has proved, they are. " > > > > > > It's definitely an interesting read, and anyone doing SQL coding > > should take a close look, IMHO. It's particularly interesting to see > > how he alters the DATE and NUMBER data types so that they can hold > SQL > > injection data. Yet another demonstration of the importance of doing > > good input validation -- preferably positive validation. As long as > > you're doing input validation, I'd think there's probably no need to > > back through your code and audit it for lateral SQL injection > vectors. > > > > Anyone else have a take on this new attack method? (Note that I > don't > > normally encourage discussions of specific product vulnerabilities > > here, but most certainly new categories of attacks--and their impacts > > on secure coding practices--are quite welcome.) > > > > > > Cheers, > > > > Ken > > > > ----- > > Kenneth R. van Wyk > > SC-L Moderator > > > > KRvW Associates, LLC > > http://www.KRvW.com > > > > > > > > > > > > > ----------------------------------------------------------------------- > - > > > > _______________________________________________ > > Secure Coding mailing list (SC-L) SC-L at securecoding.org > > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > > List charter available at - > http://www.securecoding.org/list/charter.php > > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > > as a free, non-commercial service to the software security community. > > _______________________________________________ > > > > From pmeunier at cerias.purdue.edu Tue Apr 29 09:28:43 2008 From: pmeunier at cerias.purdue.edu (Pascal Meunier) Date: Tue, 29 Apr 2008 09:28:43 -0400 Subject: [SC-L] Lateral SQL injection paper In-Reply-To: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> Message-ID: <4817228B.9080903@cerias.purdue.edu> If I understand this correctly, it's difficult to exploit because if you can alter database types, you probably can send arbitrary SQL statements to the database somehow already. In that case, what extra capabilities does this attack give you? When I design applications using Postgresql, I define a "client" role that can only execute stored procedures (and nothing else) that were defined by another "definer" role with limited privileges (e.g., not create or drop tables, and certainly not redefine types...), and those procedures are executed with the privileges of the definer ("EXTERNAL SECURITY DEFINER;"). So, the client is quite constrained in its capabilities. Wouldn't the application of this scheme to an Oracle back-end prevent this attack? If so then it's not just a question of input validation, but of proper and careful configuration of database roles. Isn't this something that Oracle could "fix" relatively easily? For example, by forbidding the redefinition of fundamental database types by default in new roles? This would be an application of the principle of secure defaults. That functionality could even be phased out eventually, as I can't imagine that it's needed much if at all. Usually when one claims a "class of vulnerabilities", this is something that can't be fixed in a language or technology, and that becomes the responsibility of developers. I find it strange to claim a "new class of vulnerability" when it's something peculiar to Oracle that can likely be fixed by Oracle itself so it's more like an Oracle bug. This sounds perhaps worthy of a CVE entry (a vulnerability in Oracle) but not a CWE entry (a class of vulnerabilities). I agree that doing validation at multiple layers can be beneficial, and that it is required when trust boundaries are crossed, but the importance of the find seems a little exaggerat ed. Regards, Pascal Meunier Kenneth Van Wyk wrote: > Greetings SC-Lers, > > Things have been pretty quiet here on the SC-L list... > > I hope everyone saw David Litchfield's recent announcement of a new > category of SQL attacks. (Full paper available at > http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) > > He refers to this new category as "lateral SQL injection" attacks. It's > very different than conventional SQL injection attacks, as well as quite > a bit more limited. In the paper, he writes: > > "Now, whether this becomes "exploitable" in the "normal" sense, I doubt > it... but in very > specific and limited scenarios there may be scope for abuse, for example > in cursor > snarfing attacks - > http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf. > > In conclusion, even those functions and procedures that don?t take user > input can be > exploited if SYSDATE is used. The lesson here is always, always validate > and don?t let > this type of vulnerability get into your code. The second lesson is that > no longer should > DATE or NUMBER data types be considered as safe and not useful as > injection vectors: > as this paper has proved, they are. " > > > It's definitely an interesting read, and anyone doing SQL coding should > take a close look, IMHO. It's particularly interesting to see how he > alters the DATE and NUMBER data types so that they can hold SQL > injection data. Yet another demonstration of the importance of doing > good input validation -- preferably positive validation. As long as > you're doing input validation, I'd think there's probably no need to > back through your code and audit it for lateral SQL injection vectors. > > Anyone else have a take on this new attack method? (Note that I don't > normally encourage discussions of specific product vulnerabilities here, > but most certainly new categories of attacks--and their impacts on > secure coding practices--are quite welcome.) > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > SC-L Moderator > > KRvW Associates, LLC > http://www.KRvW.com > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ From coley at linus.mitre.org Tue Apr 29 12:10:48 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 29 Apr 2008 12:10:48 -0400 (EDT) Subject: [SC-L] Lateral SQL injection paper In-Reply-To: References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> <4816253E.5080503@manico.net> Message-ID: On Tue, 29 Apr 2008, Joe Teff wrote: > > If I use Parameterized queries w/ binding of all variables, I'm 100% > > immune to SQL Injection. > > Sure. You've protected one app and transferred risk to any other > process/app that uses the data. If they use that data to create dynamic > sql, then what? Let's call these "using apps" for clarity of the rest of this post. I think it's the fault of the "using apps" for not validating their own data. Here's a pathological and hopefully humorous example. Suppose you want to protect those "using apps" against all forms of attack. How can you protect every "using app" against SQL injection, XSS, *and* OS command injection? Protecting against XSS (say, by setting "<" to ">" and other things) suddenly creates an OS command injection scenario because "&" and ";" typically have special meaning in Unix system() calls. Quoting against SQL injection "\'" will probably fool some XSS protection mechanisms and/or insert quotes after they'd already been stripped. As a result, the only safe data would be alphanumeric without any spaces - after all, you want to protect your "user apps" against whitespace, because that's what's used to introduce new arguments. But wait - buffer overflows happen all the time with long alphanumeric strings, and Metasploit is chock full of alpha-only shellcode, so arbitrary code execution is still a major risk. So we'll have to trim the alphanumeric strings to... hmmm... one character long. But, a one-character string will probably be too short for some "using apps" and will trigger null pointer dereferences due to failed error checking. Worse, maybe there's a buffer underflow if the using app does some negative offset calculations assuming a minimum buffer size. And what if we're providing a numeric string that the using app might treat as an array index? So, anything that looks like an ID should be scrubbed to a safe value, say, 1, since presumably the programmer doesn't allocate 0-size arrays. But wait, a user ID of "1" is often used to identify the admin in a using apps, so this would be tantamount to giving everyone admin privileges! We shouldn't accept any numbers at all. And, we periodically see issues where an attacker can bypass a lowercase-only protection mechanism by using uppercase, so we'd best set the characters to all-upper or all-lower. So, maybe the best way to be sure we're protecting "using apps" is to send them no data at all (which will still trigger crashes in apps that assume they'll be hearing from someone eventually). Or, barring that, you pass along some meta-data that explicitly states what protections have or have not been applied to the data you're sending - along with an integrity check of your claims. Of course, some "using apps" won't check that integrity and will accept bad data from anywhere, not just you, so they'll be vulnerable again, despite your best intentions. The alternate approach is to pick and choose which vulns you'll protect using apps against. But then, if you've protected a using app against SQL injection, but it moves to a non-database model instead, you've just broken your legitimate functionality. So, you're stuck with modeling which using apps are using which technologies and might be subject to which vulns. You will also need a complete model of what the using app's behaviors are, and you'll need to keep different models for each different version and operating environment. This will become brittle and quickly unmaintainable, and eventually introduce unrelated security issues as a result of that brittleness. To my current way of thinking, the two main areas of responsibility are: - for the caller to make sure that the request/message is perfectly structured and delimited, and semantically correct for what the caller is asking the callee to do. The current browser URI handler vulnerabilities, and argument injection in general, are examples of violations of this responsibility. - for the caller, given any arbitrary message/request, to prove (or enforce) that it is well-formed, to make sure that the caller has the appropriate privileges to make that message/request in the first place, and to protect itself against SQL injection when interacting with a DB, against XSS when printing out to a web page, etc. I recognize that you might not have a choice with stovepipe or legacy applications, or in proxy/firewall code that resides between two components. I feel for anyone wrestling with those problems. But, "protect using apps against themselves" as general advice seems fraught with peril. - Steve From arian.evans at anachronic.com Tue Apr 29 14:24:12 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Tue, 29 Apr 2008 11:24:12 -0700 Subject: [SC-L] Lateral SQL injection paper In-Reply-To: References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> <4816253E.5080503@manico.net> Message-ID: So I'd like to pull this back to a few salient points. Weirdly, some folks seem quick to dismiss the paper with a didactic shot of "folks shouldn't code that way anyway" which has nothing to do with the subject. 1. I think everyone on SC-L gets the idea of strong patterns and implementations, and why parameterized SQL is a good thing, and why cached queries are also a good thing (for performance, at least, and security if by doing so you enforce avoidance of EXEC()) 2. David's paper is interesting, because out in the real world people do not, and sometimes cannot, follow ideal patterns, command patterns, and or implementations that are safe. (e.g. delegation of privilege on Windows accessing the DB for security inheritance vs. the negative impact to thread pooling and process safety -- it is a real tradeoff, and *never* made on the side of security) David's paper is interesting because out in the real world people still follow many borderline unsafe practices and understanding new attack vectors is essential to assessing risk, and understanding whether refactoring, or hofixing, vs. logging, filtering, or *ignoring* the code, is the right business choice to make. David's example is more CVE instance than CWE class. -- Steven, I like the grouping of your two main abstractions below; for purpose of discussion & education I like to put these together a little differently into Semantic and Syntax software security-defect buckets. I'm curious what your thoughts are (and take this offline if the response is too tangential) 1. Semantic -- I place message structure, delimiting, and all entailments of semantic conversation, including implications of use-case and business rules here, where the latter relate to enforcing specific semantic user/caller- dialogues with the application. I place callee requirement to enforce workflow, order, message structure, state and sequence, and *privilege* here. 2. Syntax -- at heart we have a data/function boundary problem, right? And most modern implementation level languages do not give us constructs to address/enforce this, so all our cluged workarounds, from stack canaries to crappy \ escaping in SQL to attempts to use of HTML named entities to encode output, fall into this grouping. I place in callee requirements everything to do with message encoding, canonicalization, buffer and case e.g.- all syntax issues, into this grouping. Now, arguably you could call a buffer or heap overflow semantic, if you argue it's privilege related, but I would say that is a result of language defects (or realities) and it still starts syntactically. Where would you put the recent URI-handler issues in this structure? Why did you specify privilege burden on the caller? I tend to leave out/ignore the caller responsiblities when I am thinking of software. This could be a bias of predominantly web-centric (and db client/server where I don't control the client) programming and design over the years. While it makes sense to enforce some syntax structure upon the caller, in general I tend to put all semantic responsibilities upon the callee, and even assume the callee should enforce some notion of syntax requirements upon the caller, and feed said back to caller. -- -- Arian J. Evans. I spend most of my money on motorcycles, mistresses, and martinis. The rest of it I squander. On Tue, Apr 29, 2008 at 9:10 AM, Steven M. Christey wrote: > > On Tue, 29 Apr 2008, Joe Teff wrote: > > > > If I use Parameterized queries w/ binding of all variables, I'm 100% > > > immune to SQL Injection. > > > > Sure. You've protected one app and transferred risk to any other > > process/app that uses the data. If they use that data to create dynamic > > sql, then what? > > Let's call these "using apps" for clarity of the rest of this post. > > I think it's the fault of the "using apps" for not validating their own > data. > > Here's a pathological and hopefully humorous example. > > Suppose you want to protect those "using apps" against all forms of > attack. > > How can you protect every "using app" against SQL injection, XSS, *and* OS > command injection? Protecting against XSS (say, by setting "<" to ">" > and other things) suddenly creates an OS command injection scenario > because "&" and ";" typically have special meaning in Unix system() calls. > Quoting against SQL injection "\'" will probably fool some XSS protection > mechanisms and/or insert quotes after they'd already been stripped. > > As a result, the only safe data would be alphanumeric without any spaces - > after all, you want to protect your "user apps" against whitespace, > because that's what's used to introduce new arguments. > > But wait - buffer overflows happen all the time with long alphanumeric > strings, and Metasploit is chock full of alpha-only shellcode, so > arbitrary code execution is still a major risk. So we'll have to trim the > alphanumeric strings to... hmmm... one character long. > > But, a one-character string will probably be too short for some "using > apps" and will trigger null pointer dereferences due to failed error > checking. Worse, maybe there's a buffer underflow if the using app does > some negative offset calculations assuming a minimum buffer size. > > And what if we're providing a numeric string that the using app might > treat as an array index? So, anything that looks like an ID should be > scrubbed to a safe value, say, 1, since presumably the programmer doesn't > allocate 0-size arrays. But wait, a user ID of "1" is often used to > identify the admin in a using apps, so this would be tantamount to giving > everyone admin privileges! We shouldn't accept any numbers at all. > > And, we periodically see issues where an attacker can bypass a > lowercase-only protection mechanism by using uppercase, so we'd best set > the characters to all-upper or all-lower. > > So, maybe the best way to be sure we're protecting "using apps" is to send > them no data at all (which will still trigger crashes in apps that assume > they'll be hearing from someone eventually). > > Or, barring that, you pass along some meta-data that explicitly states > what protections have or have not been applied to the data you're sending > - along with an integrity check of your claims. > > Of course, some "using apps" won't check that integrity and will accept > bad data from anywhere, not just you, so they'll be vulnerable again, > despite your best intentions. > > The alternate approach is to pick and choose which vulns you'll protect > using apps against. But then, if you've protected a using app against SQL > injection, but it moves to a non-database model instead, you've just > broken your legitimate functionality. So, you're stuck with modeling > which using apps are using which technologies and might be subject to > which vulns. You will also need a complete model of what the using app's > behaviors are, and you'll need to keep different models for each different > version and operating environment. This will become brittle and quickly > unmaintainable, and eventually introduce unrelated security issues as a > result of that brittleness. > > To my current way of thinking, the two main areas of responsibility are: > > - for the caller to make sure that the request/message is perfectly > structured and delimited, and semantically correct for what the caller is > asking the callee to do. The current browser URI handler vulnerabilities, > and argument injection in general, are examples of violations of this > responsibility. > > - for the caller, given any arbitrary message/request, to prove (or > enforce) that it is well-formed, to make sure that the caller has the > appropriate privileges to make that message/request in the first place, > and to protect itself against SQL injection when interacting with a DB, > against XSS when printing out to a web page, etc. > > > I recognize that you might not have a choice with stovepipe or legacy > applications, or in proxy/firewall code that resides between two > components. I feel for anyone wrestling with those problems. But, > "protect using apps against themselves" as general advice seems fraught > with peril. > > - Steve > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080429/1f4ed6a8/attachment-0001.html From Everhart at gce.com Tue Apr 29 20:04:48 2008 From: Everhart at gce.com (Mary and Glenn Everhart) Date: Tue, 29 Apr 2008 20:04:48 -0400 Subject: [SC-L] Lateral SQL injection paper In-Reply-To: References: <118B2F9B-72A4-4806-8A56-D2F48EA354B8@krvw.com> <4816253E.5080503@manico.net> Message-ID: <4817B7A0.1000106@gce.com> Let me suggest something a little differently: Perhaps when speaking of web app security, an already enormous area, it is not so useful to enlarge it still more, but "fools rush in...".. One way to look at web code (and many other kinds) is that we are sending strings to an interpreter and it does things. What makes security hard is that the underlying interpreter doesn't give us much (any?) help in figuring out what the set of functions/operations done are, so if we get some string together we are going to pass, which we want to do some set of things, and if it does some different set because it is an attacker, we don't have any easy way to find out or do anything. (This is easier to see with SQL or other languages where the string passing tends to be easier to identify.) Suppose the interpreter were made to count how many times major functions ran - stuff from its parse tree - and make some kind of hash or structure that encapsulated these counts (or even the functions only, counting just "done" or "not done"), and returned that the first time it was run, and gave a way to rerun the call a second time if this count were what was wanted? You'd need a way to train your app in what was wanted, or otherwise somehow figure out these hashes or structures without editing every time, and you'd need a way to get the underlying interpreter to check what was passed to it, compare the "legality" functions, and execute finally what was legal. (This can be viewed as an access control system if you like.) But might such a system not give a way to keep web apps (or others) from doing unexpected things? The next question might be: could a web page be constructed so that this kind of thing might be done, altering only logic at the server? If it can be, then, would it not make sense to think about building a server or servers with such properties available, so that one could write a web site that would tend only to behave in predictable ways? Or would such a thing so constrain what could be done that it is useless? It seems to me that the numerous attacks are such that removing them one at a time is a bit like using a hammer to wipe out a roach infestation, and some more generic approaches should be asked about. But what about it? Does anyone have some suggestions that might be generic and might be possible to implement a site at a time? Glenn C. Everhart Everhart at gce.com Arian J. Evans wrote: > So I'd like to pull this back to a few salient points. Weirdly, > some folks seem quick to dismiss the paper with a > didactic shot of "folks shouldn't code that way anyway" > which has nothing to do with the subject. > > 1. I think everyone on SC-L gets the idea of strong > patterns and implementations, and why parameterized > SQL is a good thing, and why cached queries are also > a good thing (for performance, at least, and security if > by doing so you enforce avoidance of EXEC()) > > 2. David's paper is interesting, because out in the real > world people do not, and sometimes cannot, follow > ideal patterns, command patterns, and or implementations > that are safe. (e.g. delegation of privilege on Windows > accessing the DB for security inheritance vs. the negative > impact to thread pooling and process safety -- it is > a real tradeoff, and *never* made on the side of security) > > David's paper is interesting because out in the real > world people still follow many borderline unsafe practices > and understanding new attack vectors is essential to > assessing risk, and understanding whether refactoring, > or hofixing, vs. logging, filtering, or *ignoring* the code, > is the right business choice to make. > > David's example is more CVE instance than CWE class. > > -- > > Steven, I like the grouping of your two main abstractions > below; for purpose of discussion & education I like to put > these together a little differently into Semantic and Syntax > software security-defect buckets. I'm curious what your > thoughts are (and take this offline if the response is too tangential) > > > 1. Semantic -- I place message structure, delimiting, > and all entailments of semantic conversation, including > implications of use-case and business rules here, where > the latter relate to enforcing specific semantic user/caller- > dialogues with the application. > > I place callee requirement to enforce workflow, order, > message structure, state and sequence, and *privilege* here. > > 2. Syntax -- at heart we have a data/function boundary > problem, right? And most modern implementation level > languages do not give us constructs to address/enforce > this, so all our cluged workarounds, from stack canaries > to crappy \ escaping in SQL to attempts to use of HTML > named entities to encode output, fall into this grouping. > > I place in callee requirements everything to do with > message encoding, canonicalization, buffer and > case e.g.- all syntax issues, into this grouping. > > Now, arguably you could call a buffer or heap overflow > semantic, if you argue it's privilege related, but I > would say that is a result of language defects (or > realities) and it still starts syntactically. > > Where would you put the recent URI-handler issues > in this structure? > > Why did you specify privilege burden on the caller? > > I tend to leave out/ignore the caller responsiblities > when I am thinking of software. This could be a > bias of predominantly web-centric (and db client/server > where I don't control the client) programming and > design over the years. > > While it makes sense to enforce some syntax > structure upon the caller, in general I tend to > put all semantic responsibilities upon the callee, > and even assume the callee should enforce > some notion of syntax requirements upon > the caller, and feed said back to caller. > > -- > -- > Arian J. Evans. > > I spend most of my money on motorcycles, mistresses, and martinis. The > rest of it I squander. > > > > On Tue, Apr 29, 2008 at 9:10 AM, Steven M. Christey > > wrote: > > > On Tue, 29 Apr 2008, Joe Teff wrote: > > > > If I use Parameterized queries w/ binding of all variables, > I'm 100% > > > immune to SQL Injection. > > > > Sure. You've protected one app and transferred risk to any other > > process/app that uses the data. If they use that data to create > dynamic > > sql, then what? > > Let's call these "using apps" for clarity of the rest of this post. > > I think it's the fault of the "using apps" for not validating > their own > data. > > Here's a pathological and hopefully humorous example. > > Suppose you want to protect those "using apps" against all forms of > attack. > > How can you protect every "using app" against SQL injection, XSS, > *and* OS > command injection? Protecting against XSS (say, by setting "<" to > ">" > and other things) suddenly creates an OS command injection scenario > because "&" and ";" typically have special meaning in Unix > system() calls. > Quoting against SQL injection "\'" will probably fool some XSS > protection > mechanisms and/or insert quotes after they'd already been stripped. > > As a result, the only safe data would be alphanumeric without any > spaces - > after all, you want to protect your "user apps" against whitespace, > because that's what's used to introduce new arguments. > > But wait - buffer overflows happen all the time with long alphanumeric > strings, and Metasploit is chock full of alpha-only shellcode, so > arbitrary code execution is still a major risk. So we'll have to > trim the > alphanumeric strings to... hmmm... one character long. > > But, a one-character string will probably be too short for some "using > apps" and will trigger null pointer dereferences due to failed error > checking. Worse, maybe there's a buffer underflow if the using > app does > some negative offset calculations assuming a minimum buffer size. > > And what if we're providing a numeric string that the using app might > treat as an array index? So, anything that looks like an ID should be > scrubbed to a safe value, say, 1, since presumably the programmer > doesn't > allocate 0-size arrays. But wait, a user ID of "1" is often used to > identify the admin in a using apps, so this would be tantamount to > giving > everyone admin privileges! We shouldn't accept any numbers at all. > > And, we periodically see issues where an attacker can bypass a > lowercase-only protection mechanism by using uppercase, so we'd > best set > the characters to all-upper or all-lower. > > So, maybe the best way to be sure we're protecting "using apps" is > to send > them no data at all (which will still trigger crashes in apps that > assume > they'll be hearing from someone eventually). > > Or, barring that, you pass along some meta-data that explicitly states > what protections have or have not been applied to the data you're > sending > - along with an integrity check of your claims. > > Of course, some "using apps" won't check that integrity and will > accept > bad data from anywhere, not just you, so they'll be vulnerable again, > despite your best intentions. > > The alternate approach is to pick and choose which vulns you'll > protect > using apps against. But then, if you've protected a using app > against SQL > injection, but it moves to a non-database model instead, you've just > broken your legitimate functionality. So, you're stuck with modeling > which using apps are using which technologies and might be subject to > which vulns. You will also need a complete model of what the > using app's > behaviors are, and you'll need to keep different models for each > different > version and operating environment. This will become brittle and > quickly > unmaintainable, and eventually introduce unrelated security issues > as a > result of that brittleness. > > To my current way of thinking, the two main areas of > responsibility are: > > - for the caller to make sure that the request/message is perfectly > structured and delimited, and semantically correct for what the > caller is > asking the callee to do. The current browser URI handler > vulnerabilities, > and argument injection in general, are examples of violations of this > responsibility. > > - for the caller, given any arbitrary message/request, to prove (or > enforce) that it is well-formed, to make sure that the caller has the > appropriate privileges to make that message/request in the first > place, > and to protect itself against SQL injection when interacting with > a DB, > against XSS when printing out to a web page, etc. > > > I recognize that you might not have a choice with stovepipe or legacy > applications, or in proxy/firewall code that resides between two > components. I feel for anyone wrestling with those problems. But, > "protect using apps against themselves" as general advice seems > fraught > with peril. > > - Steve > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From ken at krvw.com Thu May 1 09:13:44 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 1 May 2008 09:13:44 -0400 Subject: [SC-L] GCC and pointer overflows [LWN.net] Message-ID: <2BE54C13-65F1-4D3B-AA57-76F05CE251A8@krvw.com> FYI, here's an interesting article (and follow-on discussions) about a recent bug in the GCC compiler collection. http://lwn.net/Articles/278137/ The bug, which has been documented in a CERT advisory, affects C code in which, under some circumstances, buffer bounds checking can be optimized out to produce binaries that are susceptible to buffer overflows. The article includes a couple examples that really help illustrate the issue -- very interesting reading, IMHO. Of course, many/most SC-Lers will no doubt jump on this as another example of why C is such a dangerous language to write (secure) code in, and that's fine. But, I see the issue at least a little differently: a compiler making decisions for the programmer and producing executable code that does not accurately conform to what the programmer coded. We've all heard of security-related optimizing issues for years, right? Well, here's a prime example of one in action. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080501/b01ccf74/attachment.bin From rcs at cert.org Thu May 1 09:37:52 2008 From: rcs at cert.org (Robert C. Seacord) Date: Thu, 01 May 2008 09:37:52 -0400 Subject: [SC-L] GCC and pointer overflows [LWN.net] In-Reply-To: <2BE54C13-65F1-4D3B-AA57-76F05CE251A8@krvw.com> References: <2BE54C13-65F1-4D3B-AA57-76F05CE251A8@krvw.com> Message-ID: <4819C7B0.50205@cert.org> Ken, Comment below. > FYI, here's an interesting article (and follow-on discussions) about a > recent bug in the GCC compiler collection. > > http://lwn.net/Articles/278137/ > > The bug, which has been documented in a CERT advisory, affects C code > in which, under some circumstances, buffer bounds checking can be > optimized out to produce binaries that are susceptible to buffer > overflows. The article includes a couple examples that really help > illustrate the issue -- very interesting reading, IMHO. > > Of course, many/most SC-Lers will no doubt jump on this as another > example of why C is such a dangerous language to write (secure) code > in, and that's fine. But, I see the issue at least a little > differently: a compiler making decisions for the programmer and > producing executable code that does not accurately conform to what the > programmer coded. We've all heard of security-related optimizing > issues for years, right? Well, here's a prime example of one in action. To be fair to gcc, the code in question is "undefined behavior" which means that the C standard gives the compiler lease to deal with the code in any manner they wish. This means that they do not need to diagnose the problem, generate object code, or generate correct code. This is a problem with the C language--the onus is on the developer to write "conforming" applications. The reason we dinged gcc in this case was because versions of the compiler prior to v 4.2 did generate object code in this case that was consistent with the user model (e.g., that adding a pointer to a integer could result in wrapping). Version 4.2 silently changed this behavior without providing a flag or option to diagnose the issue. They have since modified their compiler to warn on this issue, and once this version of the compiler is released we will update the vul note to recommend this version of the compiler be used. We are looking at this as a prototype for similar vulnerability notes dealing with erroneous or unexpected behavior in tools that can lead to the introduction of vulnerabilities in software, so I would be interested in feedback as to if vulnerability notes of this sort are of value. rCs From mouse at Rodents.Montreal.QC.CA Thu May 1 10:37:08 2008 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Thu, 1 May 2008 10:37:08 -0400 (EDT) Subject: [SC-L] GCC and pointer overflows [LWN.net] In-Reply-To: <2BE54C13-65F1-4D3B-AA57-76F05CE251A8@krvw.com> References: <2BE54C13-65F1-4D3B-AA57-76F05CE251A8@krvw.com> Message-ID: <200805011445.KAA03347@Sparkle.Rodents.Montreal.QC.CA> > The bug, which has been documented in a CERT advisory, affects C code > in which, under some circumstances, buffer bounds checking can be > optimized out to produce binaries that are susceptible to buffer > overflows. [...] > Of course, many/most SC-Lers will no doubt jump on this as another > example of why C is such a dangerous language to write (secure) code > in, and that's fine. Actually, it isn't. It's a dangerous language to write sloppy, buggy code in. Go read the advisory - it's only severely broken tests that are affected. Such code has always been broken; the recent change just changes the behaviour produced by such broken code, and I have trouble getting worked up about it. > But, I see the issue at least a little differently: a compiler making > decisions for the programmer and producing executable code that does > not accurately conform to what the programmer coded. It accurately conforms to what the programmer coded, just not to what the programmer intended to code. The "problem" affects only code that depends on certain pointer computations whose behaviour has never been promised by C. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From Jeremy.Epstein at softwareag.com Thu May 1 13:00:34 2008 From: Jeremy.Epstein at softwareag.com (Epstein, Jeremy) Date: Thu, 1 May 2008 13:00:34 -0400 Subject: [SC-L] GCC and pointer overflows [LWN.net] In-Reply-To: <2BE54C13-65F1-4D3B-AA57-76F05CE251A8@krvw.com> Message-ID: Ken, a good example. For those of you who want to reach much further back, Paul Karger told me of a similar problem in the compiler (I don't remember the language) used for compiling the A1 VAX VMM kernel, that optimized out a check in the Mandatory Access Control enforcement, which separates information of different classifications (*). [For those not familiar with it, this was a provably secure kernel on which you could host multiple untrusted operating systems. Despite what some young-uns seem to think, VMs are not a new concept - they go back at least three decades that I know of, and possibly longer. The A1 VAX effort ended roughly 20-25 years ago, to give a timeframe for this particular compiler issue.] --Jeremy (*) At least that's what my memory tells me - if Paul is on this list, perhaps he can verify or correct. > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk > Sent: Thursday, May 01, 2008 9:14 AM > To: Secure Coding > Subject: [SC-L] GCC and pointer overflows [LWN.net] > > FYI, here's an interesting article (and follow-on > discussions) about a recent bug in the GCC compiler collection. > > http://lwn.net/Articles/278137/ > > The bug, which has been documented in a CERT advisory, > affects C code in which, under some circumstances, buffer > bounds checking can be optimized out to produce binaries that > are susceptible to buffer overflows. The article includes a > couple examples that really help illustrate the issue -- very > interesting reading, IMHO. > > Of course, many/most SC-Lers will no doubt jump on this as > another example of why C is such a dangerous language to > write (secure) code in, and that's fine. But, I see the > issue at least a little > differently: a compiler making decisions for the programmer > and producing executable code that does not accurately > conform to what the programmer coded. We've all heard of > security-related optimizing issues for years, right? Well, > here's a prime example of one in action. > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > > > > > From ljknews at mac.com Thu May 1 15:00:47 2008 From: ljknews at mac.com (ljknews) Date: Thu, 1 May 2008 15:00:47 -0400 Subject: [SC-L] GCC and pointer overflows [LWN.net] In-Reply-To: References: Message-ID: At 1:00 PM -0400 5/1/08, Epstein, Jeremy wrote: > Ken, a good example. For those of you who want to reach much further > back, Paul Karger told me of a similar problem in the compiler (I don't > remember the language) VAX Pascal, before VMS was on Alpha (and long before Itanium). > used for compiling the A1 VAX VMM kernel, that > optimized out a check in the Mandatory Access Control enforcement, which > separates information of different classifications (*). [For those not > familiar with it, this was a provably secure kernel on which you could > host multiple untrusted operating systems. Despite what some young-uns > seem to think, VMs are not a new concept - they go back at least three > decades that I know of, and possibly longer. The A1 VAX effort ended > roughly 20-25 years ago, to give a timeframe for this particular > compiler issue.] -- Larry Kilgallen From leichter_jerrold at emc.com Thu May 1 15:12:00 2008 From: leichter_jerrold at emc.com (Leichter, Jerry) Date: Thu, 1 May 2008 15:12:00 -0400 (EDT) Subject: [SC-L] GCC and pointer overflows [LWN.net] In-Reply-To: References: Message-ID: | Ken, a good example. For those of you who want to reach much further | back, Paul Karger told me of a similar problem in the compiler (I don't | remember the language) used for compiling the A1 VAX VMM kernel, that | optimized out a check in the Mandatory Access Control enforcement, which | separates information of different classifications (*). [For those not | familiar with it, this was a provably secure kernel on which you could | host multiple untrusted operating systems. Despite what some young-uns | seem to think, VMs are not a new concept - they go back at least three | decades that I know of, and possibly longer. The A1 VAX effort ended | roughly 20-25 years ago, to give a timeframe for this particular | compiler issue.] The VAX VMM effort died with the announcement of the Alpha, in late 1992 - though obviously the death was decided internally once the move to Alpha was decided, which would have been somewhat earlier. The origins of the VAX VMM effort date back to the early 80's. As best I can recall, the VAX VMM kernel was written almost entirely in PL/I. (Why? Because the main alternatives available at the time were assembler and C - way too open-ended for you to be able to make useful correctness assertions - and Pascal, which even in VMS's much extended version was too inflexible. There were almost certainly a few small assembler helper programs. Before you defend C, keep in mind that this is well pre-Standard, when the semantics was more or less defined by "do what pcc does" and type punning and various such tricks were accepted practice.) I know from other discussions with Paul that it was understood in the high assurance community at the time that, no matter what you knew about the compiler and no matter what proofs you had about the source code, you still needed to manually check the generated machine code. Expensive, but there was no safe alternative. So any such optimizations would have been caught. -- Jerry | --Jeremy | | (*) At least that's what my memory tells me - if Paul is on this list, | perhaps he can verify or correct. From ljknews at mac.com Thu May 1 16:01:48 2008 From: ljknews at mac.com (ljknews) Date: Thu, 1 May 2008 16:01:48 -0400 Subject: [SC-L] GCC and pointer overflows [LWN.net] In-Reply-To: References: Message-ID: At 3:12 PM -0400 5/1/08, Leichter, Jerry wrote: > The VAX VMM effort died with the announcement of the Alpha, in late 1992 > - though obviously the death was decided internally once the move to > Alpha was decided, which would have been somewhat earlier. The origins > of the VAX VMM effort date back to the early 80's. My understanding is that DEC pulled the plug on the VMM project (called SVS) during a successful field test when they discovered that while the NSA division that handled trusted computing was really gung ho about the project, none of the government units which might actually make purchases were interested in multilevel secure machines. Remember that the MicroVAX II was available at the time and from many perspectives (including that of taxpayers) it was a lot nicer to use separate machines for various security classifications. -- Larry Kilgallen From koved at us.ibm.com Sun May 4 22:09:06 2008 From: koved at us.ibm.com (Larry Koved) Date: Sun, 4 May 2008 22:09:06 -0400 Subject: [SC-L] Reminder: W2SP 2008: Web 2.0 Security and Privacy 2008 In-Reply-To: Message-ID: Reminder -- less than 3 week until the workshop! W2SP 2008: Web 2.0 Security and Privacy 2008 Thursday, May 22 The Claremont Resort, Oakland, California Sponsored by the 2008 IEEE Symposium on Security and Privacy The goal of this one day workshop is to bring together researchers and practitioners from academia and industry to focus on understanding Web 2.0 security and privacy issues, and establishing new collaborations in these areas. Registration: Workshop registration will only be available at the 2008 IEEE Symposium on Security and Privacy and 2008 IEEE Symposium on Security and Privacy conference web site, but not on the day of the workshop. 2008 workshop web site: http://seclab.cs.rice.edu/w2sp/2008/ 2007 workshop web site: http://seclab.cs.rice.edu/w2sp/2007/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080504/76a1c28f/attachment.html From gem at cigital.com Mon May 5 13:24:49 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 5 May 2008 13:24:49 -0400 Subject: [SC-L] Microsoft's message at RSA Message-ID: hi sc-l, Here's an article about Mundie's keynote at RSA. It's worth a read from a software security perspective. Somehow I ended up playing the foil in this article...go figure. http://reddevnews.com/features/article.aspx?editorialsid=2470 So what do you guys think? Is this end-to-end trusted computing stuff going to fly with developers? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From gunnar at arctecgroup.net Mon May 5 17:53:39 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Mon, 05 May 2008 16:53:39 -0500 Subject: [SC-L] MetriCon 3.0 Message-ID: <481F81E3.9070309@arctecgroup.net> Call for Participation MetriCon 3.0 Third Workshop on Security Metrics Tuesday, 29 July 2008, San Jose, California Overview Security metrics -- an idea whose time has come. No matter whether you read the technical or the business press, there is a desire for converting security from a world of adjectives to a world of numbers. The question is, of course, how exactly to do that. The advantage of starting early is, as ever, harder problems but a clearer field though it is very nearly too late to start early. MetriCon is where hard progress is made and harder problems brought forward. The MetriCon Workshops offer lively, practical discussion in the area of security metrics. It is a, if not the, forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop. Past events are detailed here [1] and here [2]; see, especially, the meeting Digests on those pages. MetriCon 3.0 will be a one-day event, Tuesday, July 29, 2008, in San Jose, California, USA. The Workshop begins first thing in the morning, meals are taken in the meeting room, and work/discussion extends into the evening. As this is a workshop, attendance is by invitation (and limited to 60 participants). Participants are expected to "come with findings," to "come with problems," or, better still, both. Participants should be willing to discuss what they have and need, i.e., to address the group in some fashion, formally or not. Preference will naturally be given to the authors of position papers/presentations who have actual work in progress. Presenters will each have a short 10-15 minutes to present his or her idea, followed by a another 10-15 minutes of discussion. If you would like to propose a panel or a group of related presentations on different approaches to the same problem, then please do so. Also consistent with a Workshop format, the Program Committee will be steered by what sorts of proposals come in response to this Call. Goals and Topics Our goal is to stimulate discussion of, and thinking about, security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all, with or without discussion on the day of the Workshop. Such position papers are expected to address security metrics in one of the following categories: Benchmarking of security technologies Empirical studies in specific subject matter areas Financial planning Long-term trend analysis and forecasts Metrics definitions that can be operationalized Security and risk modeling including calibrations Tools, technologies, tips, and tricks Visualization methods both for insight and lay audiences Data and analyses emerging from ongoing metrics efforts Other novel areas where security metrics may apply Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas. How to Participate Submit a short position paper or description of work done or ongoing. Your submission must be brief -- no longer than five (5) paragraphs or presentation slides. Author names and affiliations should appear first in or on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to metricon3 AT securitymetrics.org. These requests to participate are due no later than noon GMT, Monday, May 12, 2008 (a hard deadline). The Program Committee will invite both attendees and presenters. Participants of either sort will be notified of acceptance quickly -- by June 2, 2008. Presenters who want hardcopy materials to be distributed at the Workshop must provide originals of those materials to the Program Committee by July 21, 2008. All slides, position papers, and what-not will be made available to all participants at the Workshop. No formal academic proceedings are intended, but a digest of the meeting will be prepared and distributed to participants and the general public. (Digests for previous MetriCon meetings are on the past event pages mentioned above.) Plagiarism is dishonest, and the organizers of this Workshop will take appropriate action if dishonesty of this sort is found. Submission of recent, previously published work as well as simultaneous submissions to multiple venues is entirely acceptable, but only if you disclose this in your proposal. Location MetriCon 3.0 will be co-located with the 17th USENIX Security Symposium at the Fairmont Hotel in San Jose, California. Cost $225 all-inclusive of meeting space, materials preparation, and meals for the day. Important Dates Requests to participate: by May 12, 2008 Notification of acceptance: by June 2, 2008 Materials for distribution: by July 21, 2008 Workshop Organizers Dan Geer, Geer Risk Services, Chair Bob Blakley, The Burton Group Fred Cohen, Fred Cohen & Associates & California Sciences Institute Dan Conway, Indiana University Lloyd Ellam, Iceberg Networks Andrew Jaquith, The Yankee Group Elizabeth Nichols, PlexLogic Gunnar Peterson, Arctec Group Bryan Ware, Digital Sandbox Christine Whalley, Pfizer 1 http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0 2 http://securitymetrics.org/content/Wiki.jsp?page=Metricon2.0 From gunnar at arctecgroup.net Mon May 5 19:47:40 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Mon, 05 May 2008 18:47:40 -0500 Subject: [SC-L] Microsoft's message at RSA In-Reply-To: References: Message-ID: <481F9C9C.8000906@arctecgroup.net> Hi Gary, I think they are doing it, Cardspace is the key enabling technology to making it happen. Given how many enterprises are federation-enabled (and how simply the rest can be), the biggest missing piece right now is that we need an Identity Provider for the Internets. Of course this only helps to solve the access control problem, not the defensive programming problem, you can still shoot yourself in the foot with SAML and WS-* (Brian Chess and I gave a talk on this at RSA). But at least it will be nice to have the banks and brokerage houses stop having people type their username and passwords into web browsers, and then blaming the consumer when things go amiss. -gp Gary McGraw wrote: > hi sc-l, > > Here's an article about Mundie's keynote at RSA. It's worth a read from a software security perspective. Somehow I ended up playing the foil in this article...go figure. > > http://reddevnews.com/features/article.aspx?editorialsid=2470 > > So what do you guys think? Is this end-to-end trusted computing stuff going to fly with developers? > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From sbradcpa at pacbell.net Mon May 5 21:38:54 2008 From: sbradcpa at pacbell.net (Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] ) Date: Mon, 05 May 2008 18:38:54 -0700 Subject: [SC-L] Microsoft's message at RSA In-Reply-To: <481F9C9C.8000906@arctecgroup.net> References: <481F9C9C.8000906@arctecgroup.net> Message-ID: <481FB6AE.7090905@pacbell.net> http://media.omediaweb.com/rsa2008/mediaplayerVO.htm?speaker=1_4 And if you want to listen to it, there it is as well. Gunnar Peterson wrote: > Hi Gary, > > I think they are doing it, Cardspace is the key enabling technology to > making it happen. Given how many enterprises are federation-enabled (and > how simply the rest can be), the biggest missing piece right now is that > we need an Identity Provider for the Internets. > > Of course this only helps to solve the access control problem, not the > defensive programming problem, you can still shoot yourself in the foot > with SAML and WS-* (Brian Chess and I gave a talk on this at RSA). But > at least it will be nice to have the banks and brokerage houses stop > having people type their username and passwords into web browsers, and > then blaming the consumer when things go amiss. > > -gp > > Gary McGraw wrote: > >> hi sc-l, >> >> Here's an article about Mundie's keynote at RSA. It's worth a read from a software security perspective. Somehow I ended up playing the foil in this article...go figure. >> >> http://reddevnews.com/features/article.aspx?editorialsid=2470 >> >> So what do you guys think? Is this end-to-end trusted computing stuff going to fly with developers? >> >> gem >> >> company www.cigital.com >> podcast www.cigital.com/silverbullet >> blog www.cigital.com/justiceleague >> book www.swsec.com >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> >> >> > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From seba at deleersnyder.eu Tue May 6 01:16:50 2008 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Tue, 6 May 2008 07:16:50 +0200 Subject: [SC-L] Invitation - OWASP AppSec Europe May 19-22 2008 - Belgium Message-ID: <6qod7n$3kmmld@relay.skynet.be> Hi, 2 weeks left for the conference! We would like to invite you to the European OWASP Application Security Conference! After successful OWASP Conferences in the United States (San Jose), Europe (Milan), Asia (Taiwan) and Australia (Queensland), we are back in Belgium: 5 tutorials and 2 conference tracks in the historic center of Ghent on May 19-22 2008! More details and registration on http://www.owasp.org/index.php/AppSecEU08 The conference is stuffed with top notch presentations from industry recognized speakers and technical experts on the latest application security risks and trends. Conference (May 21-22) Keynotes * The Great Information Security Scrap Yard Challenge (Mark Curphey) * Software Security: State of the Practice 2008 (Gary McGraw) Topics * The OWASP ESAPI project - Dave Wichers * Trends in Web Hacking Incidents: What's hot for 2008 - Ofer Shezaf * Evaluation Criteria for Web Application Firewalls - Ivan Ristic * HTML5 security - Thomas Roessler * The OWASP Orizon Project internals - Paolo Perego * Remo presentation (Input Validation) - Christian Folini * Best Practices Guide: Web Application Firewalls (OWASP German chapter) - Alexander Meisel * Google-Hacking and Google-Shielding - Amichai Shulman * NTLM Relay Attacks - Eric Rachner * PHPIDS Monitoring attack surface activity - Mario Heiderich * Security in Agile Development - Dave Wichers * Security framework is not in the code - Sam Reghenzi * Exploiting Online Games - Gary McGraw * SHIELDS: metrics, tools and Internet services to improve security in application developments - Domenico Rotondi * Graph Analysis for WebApps: From Nodes to Edges - Simon Roses Femerling * The OWASP Education Project - Martin Knobloch * Dynamic Taint Propagation: Finding Vulnerabilities Without Attacking - Matias Madou * Threat Modeling for Application Designers & Architects - Shay Zalalichin * Scanstud: Evaluating static analysis tools - Martin Johns, * Office 2.0: Software as a Service, Security on the Sidelines? - John Heasman * How Data Privacy affects Applications and Databases - Dirk De Maeyer * The OWASP Anti-Samy project - Jason Li * Input validation: the Good, the Bad and the Ugly - Johan Peeters Refereed paper track * Refereed paper track keynote * Know Thyself! - Dieter Gollmann * Refereed paper track selections: * SWF and the Malware Tragedy - fukami and Ben Fuhrmannek * Building and Stopping Next Generation XSS Worms - Arshan Dabirsiaghi * Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing - Andrew Petukhov and Dmitry Kozlov * The Need for Fourth Generation Static Analysis Tools for Security: From Bugs to Flaws - Evgeny Lebanidze * Preventing SQL Injections in Online Applications: Study, Recommendations and Java Solution Prototype Based on the SQL DOM - Etienne Janot and Pavol Zavarsky * Watch What You Write: Preventing Cross-Site Scripting by Observing Program Output - Matias Madou, Edward Lee, Jacob West and Brian Chess New for AppSec Europe: there is an expo with technical vendor demos and a Capture the Flag event! Tutorials (May 19-20) * Building and Testing Secure Web Applications * Leading the Development of Secure Applications * Building Secure Rich Internet Applications * Web Services and XML Security * Open Source ModSecurity Training OWASP Dinner (May 21) At every conference we have an evening social event the first night. They are always fun and allow participants to have some unstructured time to mingle with the other attendees. This year's event will be a Flemish buffet with special Belgian beers at the Monasterium (near the conference location). Cocktail Party (May 20) In what is also becoming a tradition, there will be a cocktail party the night before the conference begins, sponsored by Breach Security. The free and open for all conference attendees event will be held at the Vintage Wine Bar at 6:30pm (near the conference location). We would appreciate it if you let us know if you are coming so we can be ready, please mail ofers at breach.com to confirm. The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. More details and registration on http://www.owasp.org/index.php/AppSecEU08 Hope to see you all in May! Conference Committee OWASP Conferences Chair: Dave Wichers - Aspect Security - dave.wichers 'at' owasp.org 2008 EU Planning Committee Chair: Sebastien Deleersnyder - Telindus - seba 'at' owasp.org Vendor Exhibition Chair: Pravir Chandra - Cigital - chandra 'at' cigital.com Capture the Flag Chair: Pieter Danhieux - Ernst & Young - pieter.danhieux 'at' be.ey.com Refereed Papers Chair: Lieven Desmet - KU Leuven - Lieven.Desmet 'at' cs.kuleuven.ac.be From karger at watson.ibm.com Tue May 6 15:49:27 2008 From: karger at watson.ibm.com (karger at watson.ibm.com) Date: Tue, 06 May 2008 15:49:27 -0400 Subject: [SC-L] GCC and pointer overflows In-Reply-To: Your message of Fri, 02 May 2008 12:00:01 EDT. Message-ID: <20080506194927.6AF7136E4CC@gsal-1.watson.ibm.com> It's taken me some time to draft a reply, for which I must apologize, but since Jeremy Epstein mentioned me by name, I must respond. This is actually responding to four messages from Jeremy Epstein, Larry Kilgallen, and Jerry Leichter. >From: "Epstein, Jeremy" >Subject: Re: [SC-L] GCC and pointer overflows [LWN.net] > >Ken, a good example. For those of you who want to reach much further >back, Paul Karger told me of a similar problem in the compiler (I don't >remember the language) used for compiling the A1 VAX VMM kernel, that >optimized out a check in the Mandatory Access Control enforcement, which >separates information of different classifications (*). [For those not >familiar with it, this was a provably secure kernel on which you could >host multiple untrusted operating systems. Despite what some young-uns >seem to think, VMs are not a new concept - they go back at least three >decades that I know of, and possibly longer. The A1 VAX effort ended >roughly 20-25 years ago, to give a timeframe for this particular >compiler issue.] I've discussed this anecdote with Jeremy, and unfortunately, I don't remember that particular optimization problem having happened on the A1 VAX VMM. It might have been on another system and confused with the VAX VMM. We did have a compiler optimization problem in zeroing shadow page tables when switching VMs. One line of PL/I code compiled into a horrendously slow loop. I had to re-write one line of code into about 10 lines of very cryptic code (plus a full page of comments, explaining it) to trick the compiler into generating the right block move instructions to do the job. I was trying to avoid an assembler subroutine, because the call/return overhead would have also been a problem here. Virtual machines do indeed go more than 30 years back. The earliest papers on virtual machines are these. The first paper is about CP/40, the direct ancestor of CP/67 which was the first commercially available VMM. CP/40 was done at the IBM Cambridge Scientific Center on a 360/40 with a custom virtual memory box. The second paper is about an even earlier virtual machine monitor done on a heavily modified IBM 7044X here at Watson Research. The 7044x was a 7044 with an added custom virtual memory box. The term "virtual machine" was coined by the 7044X people. 1. Lindquist, A.B., R.R. Seeber, and L.W. Comeau, A Time-Sharing System Using an Associative Memory. Proceedings of the IEEE, December 1966. 54(12): p. 1774-1779. 2. O'Neill, R.W. Experience using a time-shared multi-programming system with dynamic address relocation hardware. in Proceedings of the 1967 Spring Joint Computer Conference. 18-20 April 1967, Atlantic City, NJ: Vol. 30. Thompson Books. p. 611-621. >From: ljknews > >At 1:00 PM -0400 5/1/08, Epstein, Jeremy wrote: > >> Ken, a good example. For those of you who want to reach much further >> back, Paul Karger told me of a similar problem in the compiler (I don't >> remember the language) > >VAX Pascal, before VMS was on Alpha (and long before Itanium). > >-- >Larry Kilgallen > Actually, the language choice for the VAX VMM was more complex than that. When the project started the VAX PASCAL compiler version 1 was not suitable for systems programming use. As a result, we wrote the VMM prototype entirely in VAX PL/I. About the time that the project moved from a research prototype to a full product development, the VAX Pascal version 2 compiler became available, and that compiler produced much better code and had extensions needed for systems programming (such as conformant arrays). Since PASCAL had stronger typing than PL/I, we switched to PASCAL for all new code, planning to re-write the PL/I into PASCAL eventually. In retrospect, we should have just stayed with PL/I, because the re-write never happened. We briefly considered using C, but rejected it for two reasons. The first reason was all the well-known lack of safety issues, but the second reason was that the lack of compiler known lengths not only led to security issues, but ALSO led to performance problems. Although the VAX PL/I and C compilers used the same common code generator, the PL/I compiler generated better code, because the compiler knew more about the size of data structures and could do better optimization. >From: "Leichter, Jerry" >The VAX VMM effort died with the announcement of the Alpha, in late 1992 >- though obviously the death was decided internally once the move to >Alpha was decided, which would have been somewhat earlier. The origins >of the VAX VMM effort date back to the early 80's. These dates are not correct. The A1 VAX VMM effort started just after the 1981 Oakland conference, as a back of the napkin design in a Mexican restaurant in Palo Alto. The prototype was running on a VAX-11/730 in 1984. (That included changing the VAX instruction set to be virtualizable.) The product version went into highly successeful external field test in 1989. The product announcement was supposed to happen at the 1990 Oakland conference. The paper at the conference was disguised as a report of research results to avoid prematurely revealing the product. The product was cancelled, primarily due to internal corporate politics, on Feb 14th, 1990, which the development team promptly labeled the 2nd St. Valentine's Day massacre. As a result, the Oakland paper remained just a report of research results. The Alpha was not the cause of cancellation. Quite the contrary, we had specifically designed the Alpha to better support secure virtual machine monitors than could be possible on the VAX. Details are finally published here: 3. Karger, P.A., Performance and Security Lessons Learned from Virtualizing the Alpha Processor, in The 34th Annual International Symposium on Computer Architecture 9-13 June 2007, Association for Computing Machinery: San Diego, CA. p. 392-401. > >As best I can recall, the VAX VMM kernel was written almost entirely in >PL/I. (Why? Because the main alternatives available at the time were >assembler and C - way too open-ended for you to be able to make useful >correctness assertions - and Pascal, which even in VMS's much extended >version was too inflexible. There were almost certainly a few small >assembler helper programs. Before you defend C, keep in mind that this >is well pre-Standard, when the semantics was more or less defined by "do >what pcc does" and type punning and various such tricks were accepted >practice.) > As I discussed above, the VMM kernel was about 1/2 in PL/I and 1/2 in PASCAL V2. C was explicitly rejected for both security AND performance reasons. >I know from other discussions with Paul that it was understood in the >high assurance community at the time that, no matter what you knew about >the compiler and no matter what proofs you had about the source code, >you still needed to manually check the generated machine code. >Expensive, but there was no safe alternative. So any such optimizations >would have been caught. > > -- Jerry > >From: ljknews > >My understanding is that DEC pulled the plug on the VMM project >(called SVS) during a successful field test when they discovered >that while the NSA division that handled trusted computing was >really gung ho about the project, none of the government units >which might actually make purchases were interested in multilevel >secure machines. Remember that the MicroVAX II was available at >the time and from many perspectives (including that of taxpayers) >it was a lot nicer to use separate machines for various security >classifications. This is a secure coding mailing list, and not the place to discuss how to market security. I will just say that this was the excuse used for cancelling a product that actually had a very profitable market niche. The root causes of the cancellation were neither technical nor profitability. Lots of DoD organizations had (and still have) needs for sharing multiple levels of classified information, and separate MicroVAXes would not solve those problems. For that matter, neither would pure isolation kernels, such as MILS. See this paper for details: 4. Karger, P.A. Multi-Level Security Requirements for Hypervisors. in 21st Annual Computer Security Applications Conference. 2005, Tucson, AZ: IEEE Computer Society. p. 240-248. URL: http://www.acsa-admin.org/2005/papers/154.pdf Getting back to the original question of compilers missing security checks in the code, there was a case on Multics where the argument validation code didn't anticipate the possibility of the argument list containing pointers with the increment and tally option turned on. What that accomplished was that every time the pointer was used, it pointed to a different place. Knowing that the argument validator touched the pointer N times, I carefully set up the increment and tally such that N references were to locations that the user had proper write permission to (therefore passing validation) and the N+1st reference done by the actual code of the program (as opposed to the validator) pointed to something the user did NOT have write permission to, and the operating system thus implemented a function to patch any location of memory - more than enough to take over the whole system. This was on the GE-645 processor, where argument validation was done by software. The follow-on Honewell 6180 processor had hardware argument validation which would defeat this trick. - Paul From steingra at gmail.com Fri May 9 12:33:25 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Fri, 9 May 2008 09:33:25 -0700 Subject: [SC-L] Microsoft's message at RSA In-Reply-To: References: Message-ID: <490a979e0805090933kb207218l2d0a3ae9dc1714cb@mail.gmail.com> On Mon, May 5, 2008 at 10:24 AM, Gary McGraw wrote: > hi sc-l, > > Here's an article about Mundie's keynote at RSA. It's worth a read from a software security perspective. Somehow I ended up playing the foil in this article...go figure. > > http://reddevnews.com/features/article.aspx?editorialsid=2470 > > So what do you guys think? Is this end-to-end trusted computing stuff going to fly with developers? I think you're both right. I'm working on a longer writeup of the ideas on the end-to-end paper but I think you've captured part of the problem at the heart of things. We're going to have to trade some fundamental computing liberties to get the kind of security required to actually have trusted relationships via computers. Good or bad I don't want to comment on right now. If you've read "Code and other laws of cyberspace" by Lessig you'll see some of the same ideas albeit it from a more regulatory perspective than from a purely technical one. The updated "Code 2.0" book captures a lot of these same ideas. I think Charny is missing the mark ever so slightly when he says the security goals can be achieved without compromise on the part of privacy, or functionality. As Lessig clearly points out - the rules of the networks, computers, etc. aren't real rules in any sense. its not like they are physical laws, the rules are determined by code. This code, and the policy behind it, can change. I think the real question isn't whether this is going to fly with developers, its whether its going to fly with the public at large. Are people (and their proxies - Governments) going to finally demand a change in the the rules/game? -- Andy Steingruebl steingra at gmail.com From gem at cigital.com Fri May 9 18:42:44 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 9 May 2008 18:42:44 -0400 Subject: [SC-L] Microsoft's message at RSA In-Reply-To: <490a979e0805090933kb207218l2d0a3ae9dc1714cb@mail.gmail.com> Message-ID: Hi andy (and everybody), Indeed. I vote for personal computer liberty over guaranteed iron clad security any day. For amusing and shocking rants on this subject google up some classic Ross Anderson. Or heck, I'll do it for you: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html A related and more present worry I have is that Microsoft's messaging is going to morph on the security front from "software security" (good) to "software security features end-to-end yadda" (bad). I chatted with Steve Lipner about this at the DHS software assurance thing this week and he does not seem to share my concerns. Then again, he does worry about what the marketing people make up. In my view, we US citizens have learned the hard way over the last 8 years that security makes a great excuse to compromise integrity and personal liberty. I like the fact that Microsoft makes a big deal about software security and I hope they don't stop or lose focus and start somehow associating software security with "we own your computer and we'll do what's best for you". Radically yours, gem http://www.cigital.com/~gem On 5/9/08 12:33 PM, "Andy Steingruebl" wrote: On Mon, May 5, 2008 at 10:24 AM, Gary McGraw wrote: > hi sc-l, > > Here's an article about Mundie's keynote at RSA. It's worth a read from a software security perspective. Somehow I ended up playing the foil in this article...go figure. > > http://reddevnews.com/features/article.aspx?editorialsid=2470 > > So what do you guys think? Is this end-to-end trusted computing stuff going to fly with developers? I think you're both right. I'm working on a longer writeup of the ideas on the end-to-end paper but I think you've captured part of the problem at the heart of things. We're going to have to trade some fundamental computing liberties to get the kind of security required to actually have trusted relationships via computers. Good or bad I don't want to comment on right now. If you've read "Code and other laws of cyberspace" by Lessig you'll see some of the same ideas albeit it from a more regulatory perspective than from a purely technical one. The updated "Code 2.0" book captures a lot of these same ideas. I think Charny is missing the mark ever so slightly when he says the security goals can be achieved without compromise on the part of privacy, or functionality. As Lessig clearly points out - the rules of the networks, computers, etc. aren't real rules in any sense. its not like they are physical laws, the rules are determined by code. This code, and the policy behind it, can change. I think the real question isn't whether this is going to fly with developers, its whether its going to fly with the public at large. Are people (and their proxies - Governments) going to finally demand a change in the the rules/game? -- Andy Steingruebl steingra at gmail.com From steingra at gmail.com Fri May 9 19:43:58 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Fri, 9 May 2008 16:43:58 -0700 Subject: [SC-L] Microsoft's message at RSA In-Reply-To: References: <490a979e0805090933kb207218l2d0a3ae9dc1714cb@mail.gmail.com> Message-ID: <490a979e0805091643g3c38dd5ct57ba6ad4179ec69a@mail.gmail.com> On Fri, May 9, 2008 at 3:42 PM, Gary McGraw wrote: > Hi andy (and everybody), > > Indeed. I vote for personal computer liberty over guaranteed iron clad security any day. For amusing and shocking rants on this subject google up some classic Ross Anderson. Or heck, I'll do it for you: > http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html I've heard this point for years, and yet when we actually look at ways of solving the consistent problems of software security, we always come back to tamper-proof/restricted-rights as a pretty reasonable starting point. I don't know whether this mailing list is really the place for me to advocate about this, but every time we get into a situation where we talk about high reliability (electronic voting for example) people are all up in arms that we haven't followed pretty strict practices to make sure the machines don't get hacked, aren't hackable by even experts, etc. hardened hardware, trusted computing bases, etc. But, if you want to try and apply the same engineering principles to protecting an individual's assets such as their home computer, bank account credentials, etc. then you're trampling on their freedom. I don't really see how we can viably have both. Sure we're looking at all sorts of things like sandboxing and whatnot, but given multi-purpose computing and the conflicting goals of absolute freedom and defense against highly motivated attackers, we're going to have to make some choices aren't we? I don't disagree that all of these technologies can be misused. Most can. We've all read the Risks columns for years about ways to screw things up. At the same time individual computers don't exist in isolation. They are generally part of an ecosystem (the internet) and as such your polluting car causes my acid rain and lung cancer. Strict liability isn't the right solution to this sort of public policy problem, regulation is. That regulation and control can take many forms, some good, some bad. I don't see the problem getting fixed though without some substantial reworking of the ecosystem. Some degree of freedom may well be a casualty. Please don't think I'm actually supporting the general decrease in liberty overall. At the same time I'm pretty sure that traffic laws are a good idea, speed limits are a good idea, even though they restrict individual freedoms. In the computing space I'm ok allowing people to opt-out but only if in doing to they don't pose a manifest danger to others. Balancing the freedom vs. the restriction isn't easy of course, and I'm not suggesting it is. I'm merely suggesting that all of the research we've ever done in the area doesn't point to our current model (relying on users to make choices about what software to use) promising. How to make this happen without it turning into a debacle is of course the tricky part. -- Andy Steingruebl steingra at gmail.com From gunnar at arctecgroup.net Fri May 9 22:13:18 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 09 May 2008 21:13:18 -0500 Subject: [SC-L] Microsoft's message at RSA In-Reply-To: <490a979e0805091643g3c38dd5ct57ba6ad4179ec69a@mail.gmail.com> References: <490a979e0805090933kb207218l2d0a3ae9dc1714cb@mail.gmail.com> <490a979e0805091643g3c38dd5ct57ba6ad4179ec69a@mail.gmail.com> Message-ID: <482504BE.2050603@arctecgroup.net> Hi Andy, Great post. I especially like the part about making choices. Having users type passwords into websites that "protect" all their assets pretty clearly isn't working. Cardspace is pretty clearly a massive improvement. That said, I don't think the choice is between perfect liberty and perfect security, but more what Dan Geer suggested: "We digerati have given the world fast, free, open transmission to anyone from anyone, and we've handed them a general-purpose device with so many layers of complexity that there is no one who understands it all. Because ?you're on your own? won't fly politically, something has to change. Since you don't have to block transmission in order to surveil it, and since general-purpose capabilities in computers are lost on the vast majority of those who use them, the beneficiaries of protection will likely consider surveillance and appliances to be an improvement over risk and complexity. From where they sit, this is true and normal. While the readers of Queue may well appreciate that driving is much more real with a centrifugal advance and a stick shift, try and sell that to the mass market. The general-purpose computer must die or we must put everything under surveillance. Either option is ugly, but ?all of the above? would be lights-out for people like me, people like you, people like us. We're playing for keeps now." http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=436 I hope that cheers everyone up. -gp Andy Steingruebl wrote: > On Fri, May 9, 2008 at 3:42 PM, Gary McGraw wrote: >> Hi andy (and everybody), >> >> Indeed. I vote for personal computer liberty over guaranteed iron clad security any day. For amusing and shocking rants on this subject google up some classic Ross Anderson. Or heck, I'll do it for you: >> http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html > > I've heard this point for years, and yet when we actually look at ways > of solving the consistent problems of software security, we always > come back to tamper-proof/restricted-rights as a pretty reasonable > starting point. > > I don't know whether this mailing list is really the place for me to > advocate about this, but every time we get into a situation where we > talk about high reliability (electronic voting for example) people > are all up in arms that we haven't followed pretty strict practices to > make sure the machines don't get hacked, aren't hackable by even > experts, etc. hardened hardware, trusted computing bases, etc. > > But, if you want to try and apply the same engineering principles to > protecting an individual's assets such as their home computer, bank > account credentials, etc. then you're trampling on their freedom. > > I don't really see how we can viably have both. Sure we're looking at > all sorts of things like sandboxing and whatnot, but given > multi-purpose computing and the conflicting goals of absolute freedom > and defense against highly motivated attackers, we're going to have to > make some choices aren't we? > > I don't disagree that all of these technologies can be misused. Most > can. We've all read the Risks columns for years about ways to screw > things up. > > At the same time individual computers don't exist in isolation. They > are generally part of an ecosystem (the internet) and as such your > polluting car causes my acid rain and lung cancer. Strict liability > isn't the right solution to this sort of public policy problem, > regulation is. That regulation and control can take many forms, some > good, some bad. > > I don't see the problem getting fixed though without some substantial > reworking of the ecosystem. Some degree of freedom may well be a > casualty. > > Please don't think I'm actually supporting the general decrease in > liberty overall. At the same time I'm pretty sure that traffic laws > are a good idea, speed limits are a good idea, even though they > restrict individual freedoms. In the computing space I'm ok > allowing people to opt-out but only if in doing to they don't pose a > manifest danger to others. Balancing the freedom vs. the restriction > isn't easy of course, and I'm not suggesting it is. I'm merely > suggesting that all of the research we've ever done in the area > doesn't point to our current model (relying on users to make choices > about what software to use) promising. > > How to make this happen without it turning into a debacle is of course > the tricky part. > From dwheeler at ida.org Tue May 13 16:51:25 2008 From: dwheeler at ida.org (David A. Wheeler) Date: Tue, 13 May 2008 16:51:25 -0400 Subject: [SC-L] No general-purpose computer, or everything under surveillance? In-Reply-To: References: Message-ID: <4829FF4D.1070709@ida.org> Dan Geer said: "The general-purpose computer must die or we must put everything under surveillance. Either option is ugly, but 'all of the above' would be lights-out for people like me, people like you, people like us. We're playing for keeps now." http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=436 I completely disagree with the way that people will likely interpret this quote. We do NOT need to throw away our general-purpose computers, nor do we need to submit to Orwellian total population surveillance (by governments or by corporations). What particularly worries me is that some large companies would benefit from approaches that eliminated competition in the name of security. "You have to standardize on product X, and lock things down so that no nasty alternative products are executed!". Yet that is a primary part of the problem. In our current world, many people believe they CANNOT pick a more secure product, because it's not compatible with what "everyone else is using". At least in some cases, people WILL pick a product because it has better security (see the rise of Firefox, and how it finally caused Microsoft to wake up and start fixing Internet Explorer)... but look how hard it has been for a freely-available program, implementing mostly-documented standards, to compete. If you interpret the definition of these terms of "general purpose" and "surveillance" differently, i.e., "limit applications to least privilege, and locally monitor their behavior", then I'd agree. But this is another way of saying "we need to implement least privilege and local monitoring", which are well-established security principles. And it's already happening, e.g.: * Development is already moving away from general-purpose tools. Most desktop and server software development should NOT be done in C or C++; they're too low-level and provide inadequate protection against mistakes. Instead, they should voluntarily use languages that aren't QUITE as general-purpose, because they automatically prevent many mistakes from turning into security problems (e.g., through automatic memory management). People are already moving towards such languages; we need to back in more assurance into them, but the opportunity is there. * Deployment is already moving away from general-purpose privileges. SELinux lets people define very fine-grained privileges, so that a program does NOT have arbitrary rights. OLPC goes even further; its security model is remarkable and worth learning from. * Observing behavior (and making decisions based on them) is ALREADY what some systems and network systems do. But the difference is who is in final control. In the end, the users of computers should be in final control, not their makers, or we have given up essential liberty. We can develop systems which provide suites of more specialized privileges to particular functions, without giving up essential liberty. We have a long way to go in actually DOING this, but the opportunity is there. I do not think we need to give up our liberty just to "obtain" some security. Benjamin Franklin already explained what happens to such people. --- David A. Wheeler From steingra at gmail.com Tue May 13 18:52:58 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Tue, 13 May 2008 15:52:58 -0700 Subject: [SC-L] No general-purpose computer, or everything under surveillance? In-Reply-To: <4829FF4D.1070709@ida.org> References: <4829FF4D.1070709@ida.org> Message-ID: <490a979e0805131552v2f4d11efo249e3430bb0a37a9@mail.gmail.com> On Tue, May 13, 2008 at 1:51 PM, David A. Wheeler wrote: > > If you interpret the definition of these terms of "general purpose" and > "surveillance" differently, i.e., "limit applications to least > privilege, and locally monitor their behavior", then I'd agree. But > this is another way of saying "we need to implement least privilege and > local monitoring", which are well-established security principles. And > it's already happening, e.g.: That's fine in principle. Have we ever seen a usable system based on these principles that user's didn't reject/hate? Look at the general press and people's perceptions of the security of Leopard v. Vista. We can complain all we want to about UAC and perhaps the constant "nagging" but as Apple's commercials so clearly pointed out people hate their computer explicitly and publicly trying to keep them safe. > * Deployment is already moving away from general-purpose privileges. > SELinux lets people define very fine-grained privileges, so that a > program does NOT have arbitrary rights. OLPC goes even further; its > security model is remarkable and worth learning from. That's great, but all of these schemes rely on: - Expert users to configure a policy for new software - Each piece of software to ship with a correct least-privilege configuration (how do we get the malware authors to do this?) - A user who doesn't choose to override the default security settings so they can see the dancing hamsters > * Observing behavior (and making decisions based on them) is ALREADY > what some systems and network systems do. Same here. We're still light years away from being able to do this in practice. We can't tell that the new financial management software you just downloaded is "supposed" to ask for your bank password, and that the game you just downloaded shouldn't. And user's aren't generally informed enough to make these kinds of decisions either, especially given the user interface we typically give them. Don't forget all of the wonderful fun we've had over the years getting people to not open executables sent via email, not to visit sites with a self-signed SSL certificate, to check for the lock icon in their browser, to make sure that their wireless settings don't allow them to connect to random wireless access points, etc........ > But the difference is who is in final control. In the end, the users of > computers should be in final control, not their makers, or we have given > up essential liberty. I don't think you're fundamentally wrong in that I'm not (and I can't speak for others) in favor of removing the controls completely. But, we ought to be shipping systems whose fundamental defaults are easier to use, more secure, and really hard to override. Compare IE6/FF2 to IE7/FF3 on this front. Sure you can still visit the site with the self-signed certificate, and you can still visit a site that they've categorized as a phishing site. But it isn't quite as easy as it used to be, and I'd say that's a good thing. If you own a tablesaw it comes with a blade guard. Its probably a good idea that it does. If you really want to you can remove it and I don't really feel the need to stop you. Unless I'm paying for your insurance that is. Your car also comes with pollution controls. These pollution controls often inhibit your max speed, acceleration, etc. They are really hard to, or impossible to disable. They also make our environment cleaner. Which is the right analogy for the personal computer? -- Andy Steingruebl steingra at gmail.com From gunnar at arctecgroup.net Tue May 13 21:17:06 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 13 May 2008 20:17:06 -0500 Subject: [SC-L] No general-purpose computer, or everything under surveillance? In-Reply-To: <4829FF4D.1070709@ida.org> References: <4829FF4D.1070709@ida.org> Message-ID: <482A3D92.4010108@arctecgroup.net> > But the difference is who is in final control. In the end, the users of > computers should be in final control, not their makers, or we have given > up essential liberty. We can develop systems which provide suites of > more specialized privileges to particular functions, without giving up > essential liberty. We have a long way to go in actually DOING this, but > the opportunity is there. > I believe the point of Dan Geer's paper is not that these are desired outcomes so much as realistic outcomes. If you cannot provide effective security (and we're not) and people are relying more and more on computers for real world things (and they are), then someone else (who is not a geek) is going to come in and more or less arbitrarily assign risk and responsibility to parties. For example (quoting Dan Geer's paper): "We've done this before?Regulation Z of the Truth in Lending Act of 1968 says that the most a consumer can lose from misuse of a credit card is $50. The consumer can be an idiot, but can't lose more than $50. Consumers are, in fact, not encouraged to self-protect by such a limit?quite the opposite (and $50 in 1968 would be $275 today). No, if there is to be a preemption, the intelligence it requires will be based on a duty of surveillance that is assigned to various ?deep pockets.? The countermeasures, in other words, are not risk-sensitive to where the risk naturally lies but risk-sensitive to where it is assigned. Look out side effects, here we come." Something like Regulation Z may not come to pass in information security, but if I were a betting man, I think its a more likely outcome in the real world than a combination of principle of least privilege + perfect code + 4 billion highly trained users; none of which I have seen. -gp From gem at cigital.com Thu May 15 15:33:46 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 15 May 2008 15:33:46 -0400 Subject: [SC-L] Silver Bullet 26: Adam Shostack Message-ID: hi sc-l, Silver Bullet episode 26 just went live: http://www.cigital.com/silverbullet/show-026/ This episode has the best sound quality we've achieved to date. (Sorry about episode 25 sound problems. Dell has been banished from the loop!) Adam and I have a particularly interesting conversation that has lots of relevance to software security practitioners. Someone requested a "more technical" show. Hopefully this will do it! We talk about some of the major changes that computer security has undergone, resulting in what Adam calls the "New School of Information Security." In other news, Silver Bullet has been syndicated by informIT which will hopefully help spread the word about software security further: http://www.informit.com/podcasts/channel.aspx?c=fd0a73d8-2c32-4674-ba7c-86ae3bf46486 As always, your feedback via sc-l or the website is greatly appreciated. Thanks as always to IEEE Security & Privacy magazine for co-sponsoring Silver Bullet (this time we actually discuss the magazine during the show, which will be self-referentially cool when they publish the interview). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Mon May 19 12:29:47 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 19 May 2008 12:29:47 -0400 Subject: [SC-L] informIT: web 3.0 security Message-ID: hi sc-l, I started thinking about web 3.0 (sometimes called the "semantic web") around RSA to prep for a video shoot that the CNBC was doing. Brian Sletten helped bring me up to speed in a series of conversations about what's going on technically. Not much is available yet on the security front. I aim to fix that. Anyway, the result of that thinking is this month's article in my [in]security column: http://www.informit.com/articles/article.aspx?p=1217101 As part of the switch from darkreading to informIT, informIT is also syndicating Silver Bullet, which can be found on their website here: http://www.informit.com/silverbullet Note that the preferred Silver Bullet website remains www.cigital.com/silverbullet What's your opinion about web 3.0 security? Is it too early to care? Are we already behind? I'm off to Ghent for OWASP Europe to give a keynote about the state of the practice. Perhaps I will see some of you there. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Thu May 22 22:17:01 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 22 May 2008 22:17:01 -0400 Subject: [SC-L] Coverity to Buy Codefast Message-ID: FYI, a bit of M&A activity going on in the software security (product) space: http://www.eweek.com/c/a/Application-Development/Coverity-to-Buy-Codefast/ Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080522/281c153e/attachment.bin From gem at cigital.com Thu May 29 22:16:11 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 29 May 2008 22:16:11 -0400 Subject: [SC-L] Silver Bullet (transcripts) Message-ID: hi sc-l, As some of you may know, selected Silver Bullet episodes are published in IEEE Security & privacy magazine as the "interview" column. We recently placed the entire set of available transcripts on the Silver Bullet web page as pdf files. As an example, USA Today reporter Jon Swartz's interview is featured in the May/June issue and can be found here: http://www.cigital.com/silverbullet/shows/silverbullet-025-jswartz.pdf Also available are transcripts of Silver Bullet interviews with: Ed Amoroso, Cigital's Principal Consultants, Mikko Hypponen, Spaf, Annie Anton, Ross Anderson, Becky Bace, Dorothy Denning, John Stewart, Ed Felten, Marcus Ranum, and Avi Rubin. Thanks as always for listening to Silver Bullet. Don't forget to suggest possible victims, er I mean experts who you would like to hear from. Silver Bullet is co-sponsored by Cigital and IEEE Security & Privacy magazine and is syndicated by informIT. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Wed Jun 4 17:09:12 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 4 Jun 2008 17:09:12 -0400 Subject: [SC-L] DistriNet Research Group Message-ID: <779480FC-56DB-4EBC-885B-DEF51544971A@krvw.com> FYI, interesting announcement out of KU Leuven in Belgium and the SANS institute: http://distrinet.cs.kuleuven.be/news/2008/2008-05-09%20SANSandDistriNetUnite.jsp Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080604/63116de2/attachment.bin From jgrembi at gmail.com Thu Jun 5 23:08:08 2008 From: jgrembi at gmail.com (Jason Grembi) Date: Thu, 5 Jun 2008 23:08:08 -0400 Subject: [SC-L] new book Message-ID: <930b20350806052008u40e6d1e8yf1ac472a65817c37@mail.gmail.com> Ken, I wanted to announce my book to you and your subscribers. The book "Building A Secure Software Construction: A Security Programmer's Guide" is written for college students (undergraduate or community) as a guide of how to create a development process that focuses on both quality and security principles and techniques. My motivation for such a book was twofold: 1- I felt that the security books out on the market target experienced software developers rather than college students who have limited experience with coding. 2- I tried to provide enough Instructor Resources for the instructors such as test bank questions for Black Board, power point slides, and teaching tidbits. As acknowledged in my book, you and Gary McGraw have been instrumental in this field with bringing security out into the forefront. I appreciate the work you two are doing, such as these mailing lists and the Silver Bullet podcasts that allow me to provide additional resources to the students. Here is the link if you want to check it out: http://www.amazon.com/Secure-Software-Construction-Security-Programmers/dp/1418065471 Thanks again, Jason Grembi -- THE INFORMATION CONTAINED IN THIS MESSAGE AND ANY ATTACHMENT MAY BE PRIVILEGED, CONFIDENTIAL, PROPRIETARY OR OTHERWISE PROTECTED FROM DISCLOSURE. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080605/0e874902/attachment.html From gem at cigital.com Mon Jun 9 15:48:29 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 9 Jun 2008 15:48:29 -0400 Subject: [SC-L] Search Security video Message-ID: hi sc-l, At RSA this year, I did a quick video interview with Dennis Fisher an old friend who is now the lead editor of Search Security. The resulting video is here: http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1316612,00.html Here are the questions I answered during the interview (along with some bonus pointers that I'll include in this posting). As you can see, we mostly talked about software security * Let's talk about where things stand with the state of software security in the industry today. Are you optimistic? * I've heard a lot of people say that solving the software security problem is going to cost a lot of time and money in the development process. Is that true? See this informIT article: http://www.informit.com/articles/article.aspx?p=1189519 * I know there's a lot of training that goes on in the professional world in terms of software security for developers, but is that happening more in colleges and universities right now compared to five years ago? See this IT Architect article: http://www.cigital.com/papers/download/0602sec.training.pdf * What about the commercial software vendors. How much progress are they making on this problem? * Are there one or two problems that really worry you in software security right now? See this IEEE S&P article: http://www.cigital.com/papers/download/attack-trends-EOG.pdf If you like this video, please let the Search Security people know so they feel compelled to do more. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleage book www.swsec.com From gem at cigital.com Thu Jun 12 11:33:55 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 12 Jun 2008 11:33:55 -0400 Subject: [SC-L] informIT: DMCA Message-ID: hi sc-l, I was just the guest on an episode of the Network Security podcast (you can find that here http://www.mckeay.net/2008/06/10/network-security-podcast-episode-107/ ). As part of the podcast we discussed many aspects of software security. We also discussed some recent research spearheaded by Yoshi Kohno at the University of Washington, the first scientific study of some of the monitoring systems used to enforce the DMCA on peer-to-peer networks. In this month's informIT column, I explore the idea of what happens when flimsy data are used to accuse someone of breaking the law: http://www.informit.com/articles/article.aspx?p=1223765 As always, your feedback is hugely appreciated. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Mon Jun 16 08:27:55 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 16 Jun 2008 08:27:55 -0400 Subject: [SC-L] Security Bonuses for Vista Programmers Message-ID: <6EBB48DB-1E7E-4E98-A7AA-CA2DE6F734C5@krvw.com> FYI, interesting eWeek article on some of Vista's security features that are provided to developers. (I misinterpreted the article's title a bit, but it quickly becomes clear in the article. At first, I thought it was about giving $$ bonuses to vista programmers -- it reminded me of an old Dilbert where the company was offering cash bonuses for finding bugs, and Wally was "coding himself a minivan"... :-) Anyway, don't let that stop you from reading this interesting article. http://www.eweek.com/c/a/Security/Security-Bonuses-For-Vista-Programmers/ Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080616/f7d9ae33/attachment.bin From James.McGovern at thehartford.com Mon Jun 16 16:28:00 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 16 Jun 2008 16:28:00 -0400 Subject: [SC-L] OWASP: The Application Security Desk Reference Message-ID: <9C557D8C6864CA438EF362318A3DF6D5010736BE@AD1HFDEXC306.ad1.prod> OWASP needs your help with a new important project. We're creating the OWASP Application Security Desk Reference (ASDR) to capture and organize all the foundational knowledge in application security. Like the Physicians' Desk Reference for doctors, this book is a well-organized reference work that anyone working in application security will want on their desk. The OWASP ASDR covers application security principles, threat agents, attacks, vulnerabilities, controls, technical impacts, and business impacts. A 900-page alpha draft is available for your review. We need your help to get a final version created by August 25, 2008! Here is a link to the draft: http://www.lulu.com/content/2538516 ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080616/cde2dfe6/attachment.html From gem at cigital.com Wed Jun 18 11:38:39 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 18 Jun 2008 11:38:39 -0400 Subject: [SC-L] Silver Bullet: Gunnar Peterson Message-ID: hi sc-l, I'm sitting on my porch this morning talking with Ken about the book he and Mark Graff are working on for the software security series. Ken says hi (we'll see if he approves this posting). You guys all know Gunnar Peterson who not only has an active blog that often covers software security, but who also practices software security on a daily basis as a consultant. He is the victim of silver bullet episode 27: http://www.cigital.com/silverbullet/show-027/ Our entire conversation is about software security this time. As usual, your feedback is welcome. gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Thu Jun 19 11:51:40 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 19 Jun 2008 11:51:40 -0400 Subject: [SC-L] Any SC-Lers going to FIRST in Vancouver next week? Message-ID: Subject says it all. Any of you going to be at the FIRST conference? If you are and want to hook up for a chat--perhaps over a beer--then drop me a note. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080619/2d954c0c/attachment.bin From brian at fortifysoftware.com Wed Jun 25 22:27:09 2008 From: brian at fortifysoftware.com (Brian Chess) Date: Wed, 25 Jun 2008 19:27:09 -0700 Subject: [SC-L] International Symposium on Engineering Secure Software and Systems (ESSoS) In-Reply-To: Message-ID: CALL FOR PAPERS =============== International Symposium on Engineering Secure Software and Systems (ESSoS) February 04-06, 2009 Leuven, Belgium http://distrinet.cs.kuleuven.be/events/essos2009/ CONTEXT AND MOTIVATION Trustworthy, secure software is a core ingredient of the modern world. Unfortunately, most software developed today runs on a network exposing it to a hostile environment. The Internet can allow vulnerabilities in software to be exploited from anywhere in the world. High-quality security building blocks (e.g., cryptographic components) are necessary, but insufficient to address this. Indeed, the construction of secure software is challenging because of the complexity of applications, the growing security requirements, and the multitude of software technologies and attack vectors. Clearly, a strong need exists for engineering techniques for secure software and systems that scale well and that demonstrably improve the software's security properties. GOAL AND SETUP The goal of this symposium, which will be the first in a series of events, is to bring together researchers and practitioners to advance the states of the art and practice in secure software engineering. Being one of the few conference-level events dedicated to this topic, it explicitly aims to bridge the software engineering and security engineering communities, and promote cross-fertilization. The symposium will feature two days of technical programme as well as one day of tutorials. The technical programme includes an experience track for which the submission of highly informative case studies describing (un)successful secure software project experiences and lessons learned is explicitly encouraged. TOPICS The Symposium seeks submissions on topics related to its goals. This includes a diversity of topics including (but not limited to): - scalable techniques for threat modeling and analysis of vulnerabilities - specification and management of security requirements and policies - security architecture and design for software and systems - model checking for security - specification formalisms for security artifacts - verification techniques for security properties - systematic support for security best practices - security testing - security assurance cases - programming paradigms, models and DLS's for security - program rewriting techniques - processes for the development of secure software and systems - security-oriented software reconfiguration and evolution - security measurement - automated development - trade-off between security and other non-functional requirements - support for assurance, certification and accreditation SUBMISSION AND FORMAT The proceedings of the symposium will be published as a Springer-Verlag volume in the Lecture Notes in Computer Science Series (http://www.springer.com/lncs). Submitted papers must present original, non-published work of high quality that has not been submitted for potential publication in parallel. Submitted papers should follow the formatting instructions of the Springer LNCS Style, and should include maximally 15 pages for research papers and 10 pages for industrial papers (figures and appendices included). Proposals for tutorials are highly welcome as well. Further guidelines will appear on the website of the symposium. IMPORTANT DATES Abstract submission: September 8, 2008 Paper submission: September 15, 2008 Author notification: November 5, 2008 Camera-ready: November 24, 2008 Tutorial submission: October 24, 2008 Tutorial notification: November 21, 2008 STEERING COMMITTEE Jorge Cuellar (Siemens AG) Wouter Joosen (Katholieke Universiteit Leuven) Fabio Massacci (Universit` di Trento) Gary McGraw (Cigital) Bashar Nuseibeh (The Open University) Samuel Redwine (James Madison University) ORGANIZING COMMITTEE General chair: Bart De Win (Katholieke Universiteit Leuven) Program co-chairs: Fabio Massacci (Universit` di Trento) and Samuel Redwine (James Madison University) Publication chair: Nicola Zannone (University of Toronto) Tutorial chair: Riccardo Scandariato (Katholieke Universiteit Leuven) PROGRAM COMMITTEE (preliminary) Matt Bishop, University of California (Davis) - USA Brian Chess, Fortify Software - USA Richard Clayton, Cambridge University - UK Christian Collberg, University of Arizona - USA Bart De Win, Katholieke Universiteit Leuven - BE Juergen Doser, ETH - CH Eduardo Fernandez-Medina, University of Castilla-La Mancha - ES Dieter Gollmann, University of Hamburg - DE Michael Howard, Microsoft - USA Cynthia Irvine, Naval Postgradual School - USA Jan Jurjens, Open University - UK Volkmar Lotz, SAP Labs - FR Antonio Mana, University of Malaga - ES Robert Martin, MITRE - USA Fabio Massacci, Universit` di Trento - IT Mira Mezini, Darmstadt University - DE Mattia Monga, Milan University - IT Andy Ozment, DoD - USA Gunther Pernul, Universitat Regensburg - DE Domenico Presenza, Engineering - IT Samuel Redwine, James Madison University - USA Riccardo Scandariato, Katholieke Universiteit Leuven - BE Ketil Stolen, Sintef - NO Eric Vetillard, Trusted Logic - FR Jon Whittle, Lancaster University - UK Mohammad Zulkernine, Queens University - AU From tomb at owasp.org Fri Jun 27 08:54:26 2008 From: tomb at owasp.org (Tom Brennan) Date: Fri, 27 Jun 2008 08:54:26 -0400 Subject: [SC-L] Code Testing Tools Could Be Acquisition Targets in '08 Message-ID: <206B3CE75AE0449D9770774450ADFEC8@prolpt01> That is not a bad thing ;) ---------------------------------------------------------------------------- ------------------------ Management, Developers, Security Professionals - can only result in one thing.. better security. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 From ken at krvw.com Mon Jun 30 09:44:14 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 30 Jun 2008 09:44:14 -0400 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance Message-ID: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear often.) http://www.internetnews.com/ec-news/article.php/3755916 In talking with my customers over the past several months, I always find it interesting that the vast majority would sooner have root canal than submit their source code to anyone for external review. I'm betting PCI 6.6 has been a boon for the web application firewall (WAF) world. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080630/0fe2278f/attachment.bin From gunnar at arctecgroup.net Mon Jun 30 10:17:34 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Mon, 30 Jun 2008 09:17:34 -0500 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance In-Reply-To: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> Message-ID: <4868EAFE.80907@arctecgroup.net> for the vast majority of the profession - slamming the magic pizza box in a rack is more preferable than talking to developers. in many cases the biggest barrier to getting better security in companies is the so-called information security group. it has very little to do with technology, its a people problem. -gp Kenneth Van Wyk wrote: > Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear > often.) > > http://www.internetnews.com/ec-news/article.php/3755916 > > In talking with my customers over the past several months, I always find > it interesting that the vast majority would sooner have root canal than > submit their source code to anyone for external review. I'm betting PCI > 6.6 has been a boon for the web application firewall (WAF) world. > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.com > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ From ljknews at mac.com Mon Jun 30 10:45:56 2008 From: ljknews at mac.com (ljknews) Date: Mon, 30 Jun 2008 10:45:56 -0400 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance In-Reply-To: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> Message-ID: At 9:44 AM -0400 6/30/08, Kenneth Van Wyk wrote: > Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't > hear often.) > > http://www.internetnews.com/ec-news/article.php/3755916 > > In talking with my customers over the past several months, I always > find it interesting that the vast majority would sooner have root > canal than submit their source code to anyone for external review. > I'm betting PCI 6.6 has been a boon for the web application firewall > (WAF) world. The "Note:" at the end of PCI DSS (v1.1) 6.6 talks about "this method" but typographically seems to apply to both bullets. Does anyone know what the authors had in mind ? -- Larry Kilgallen From jleffler at us.ibm.com Mon Jun 30 12:32:28 2008 From: jleffler at us.ibm.com (Jonathan Leffler) Date: Mon, 30 Jun 2008 10:32:28 -0600 Subject: [SC-L] Root Canal Treatment vs Source Code Review In-Reply-To: References: Message-ID: Under the subject "InternetNews Realtime IT News - Merchants Cope With PCI Compliance", Kenneth Van Wyk wrote: [...] In talking with my customers over the past several months, I always find it interesting that the vast majority would sooner have root canal than submit their source code to anyone for external review. [...] There's a simple reason for that reluctance - most people are painfully aware that their software won't stand the scrutiny that an external review would entail. -- Jonathan Leffler (jleffler at us.ibm.com) STSM, Informix Database Engineering, IBM Information Management 4400 N First St, San Jose, CA 95134-1257 Tel: +1 408-956-2436 Tieline: 475-2436 "I don't suffer from insanity; I enjoy every minute of it!" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4441 bytes Desc: S/MIME Cryptographic Signature Url : http://krvw.com/pipermail/sc-l/attachments/20080630/41546f6e/attachment.bin From daswani at cs.stanford.edu Mon Jun 30 12:46:34 2008 From: daswani at cs.stanford.edu (Neil Daswani) Date: Mon, 30 Jun 2008 09:46:34 -0700 Subject: [SC-L] July 23: Stanford Emerging Threats and Defenses Symposium Message-ID: The Stanford Center for Professional Development Advanced Security Certification Program Presents The *Emerging Threats and Defenses Symposium* Featuring Talks By Mary Ann Davidson Chief Security Officer of Oracle "Perspectives on Security" and Jeremiah Grossman Chief Technology Officer of WhiteHat Security "Hacks Happen" 5:00pm - 7:30pm Wednesday, July 23, 2008 Skilling Auditorium , 494 Lomita Mall, Stanford University Refreshments & Hors D'oeuvres will be served. Please register by July 15 at http://scpd.stanford.edu/scpd/courses/proed/compSecCampus/keynoteReg1.asp (This event is FREE to the public. Registration is highly encouraged to guarantee your spot as we expect that space will be limited.) *Biography: Mary Ann Davidson, Chief Security Officer, Oracle Corporation* Mary Ann Davidson is the Chief Security Officer at Oracle Corporation, responsible for Oracle product security, as well as security evaluations, assessments and incident handling. She represents Oracle on the Board of Directors of the Information Technology Information Security Analysis Center (IT-ISAC), is a member of the Global Chief Security Officer Council and the editorial advisory board of SC Magazine. She was recently named one of Information Security's top five "Women of Vision" and is 2004 Fed100 award recipient from Federal Computer Week. She has served on the Defense Science Board and has recently been named to the Center for Strategic and International Studies Cyber Commission. Ms. Davidson has a B.S.M.E. from the University of Virginia and a M.B.A. from the Wharton School of the University of Pennsylvania. She has also served as a commissioned officer in the U.S. Navy Civil Engineer Corps, during which she was awarded the Navy Achievement Medal. *Biography: Jeremiah Grossman, Chief Technology Officer, WhiteHat Security* Jeremiah Grossman is the founder and CTO of WhiteHat Security, considered a world-renowned expert in Web security, co-founder of the Web Application Security Consortium, and named to InfoWorld's Top 25 CTOs for 2007. Mr. Grossman is a frequent speaker at industry events including the BlackHat Briefings, RSA, ISACA, CSI, HiTB, OWASP, Vanguard, ISSA, Defcon, and a number of large universities. He has authored dozens of articles and white papers; is credited with the discovery of many cutting-edge attack and defensive techniques; and is a co-author of XSS Attacks. Mr. Grossman is frequently quoted in major media publications such as InfoWorld, USA Today, PCWorld, Dark Reading, SC Magazine, SecurityFocus, CNet, SC Magazine, CSO, and InformationWeek. Prior to WhiteHat he was an information security officer at Yahoo! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080630/800fb890/attachment.html From cwysopal at Veracode.com Mon Jun 30 12:51:11 2008 From: cwysopal at Veracode.com (Chris Wysopal) Date: Mon, 30 Jun 2008 12:51:11 -0400 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCICompliance In-Reply-To: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> Message-ID: <79348E23E9D34F4F8032010B2913D72B0123BF87@NexusCore.Veracode.local> Ken, Customers not wanting to part with source code is one of the reasons, at Veracode, we decided to take our static binary analysis technology to market as SaaS. You get the benefit of both automation, as with static source code analysis, and an external assessment, yet you don't have to part with your source code. So that we can deliver the same analysis accuracy as source code static analysis (among other reasons) we require our customers to submit symbols along with the compiled binaries. It is true that there is some intellectual property included in the symbols but it doesn't elicit the same level of protective response which has people opting for the root canal over sending source code externally. Our solution allows organizations to meet the external code review requirements without having external parties inspect their source code. -Chris -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Monday, June 30, 2008 9:44 AM To: Secure Coding Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCICompliance Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear often.) http://www.internetnews.com/ec-news/article.php/3755916 In talking with my customers over the past several months, I always find it interesting that the vast majority would sooner have root canal than submit their source code to anyone for external review. I'm betting PCI 6.6 has been a boon for the web application firewall (WAF) world. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com From mkgavin at hotmail.com Mon Jun 30 17:40:27 2008 From: mkgavin at hotmail.com (Michael Gavin) Date: Mon, 30 Jun 2008 17:40:27 -0400 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance In-Reply-To: <4868EAFE.80907@arctecgroup.net> References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> <4868EAFE.80907@arctecgroup.net> Message-ID: I too was wondering how much of a boon 6.6 would be to the WAF vendors and/or the companies that do security code reviews. That is, until 4/22, when the PCI SSC issued a press release (https://www.pcisecuritystandards.org/pdfs/04-22-08.pdf) announcing an information supplement clarifying requirement 6.6 (https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf). Clearly, completing security code reviews on all of those web applications and/or protecting them with those expensive "magic pizza boxes," which, last time that I checked (almost 2 years ago now) were running about $35K to start, wasn't going to happen any time soon. The good news from that "information supplement" is that the PCI Security Standards Council defined what they mean by an application firewall and specified what it is supposed to do; the less good news is that they specified 4 alternative methods for satisfying the code review option: 1. manual security code review, 2. automated security code review, 3. manual web application vulnerability scan, and 4. automated web application vulnerability scan. While I think automation of code reviews and vulnerability scans is essential, I also believe that none of the automated tools are yet sufficient (completeness-wise) without some additional manual effort. So, unfortunately for the WAF vendors, people can just use a static source code analysis tool or a web application vulnerability scanner instead of purchasing and deploying a WAF. Michael > Date: Mon, 30 Jun 2008 09:17:34 -0500 > From: gunnar at arctecgroup.net > To: ken at krvw.com > CC: SC-L at securecoding.org > Subject: Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance > > for the vast majority of the profession - slamming the magic pizza box in a rack > is more preferable than talking to developers. in many cases the biggest barrier > to getting better security in companies is the so-called information security > group. it has very little to do with technology, its a people problem. > > -gp > > Kenneth Van Wyk wrote: > > Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear > > often.) > > > > http://www.internetnews.com/ec-news/article.php/3755916 > > > > In talking with my customers over the past several months, I always find > > it interesting that the vast majority would sooner have root canal than > > submit their source code to anyone for external review. I'm betting PCI > > 6.6 has been a boon for the web application firewall (WAF) world. > > > > > > Cheers, > > > > Ken > > > > ----- > > Kenneth R. van Wyk > > SC-L Moderator > > KRvW Associates, LLC > > http://www.KRvW.com > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Secure Coding mailing list (SC-L) SC-L at securecoding.org > > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > > List charter available at - http://www.securecoding.org/list/charter.php > > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > > as a free, non-commercial service to the software security community. > > _______________________________________________ > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ _________________________________________________________________ The i?m Talkathon starts 6/24/08.? For now, give amongst yourselves. http://www.imtalkathon.com?source=TXT_EML_WLH_LearnMore_GiveAmongst -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080630/e5a5ec8f/attachment-0001.html From arian.evans at anachronic.com Mon Jun 30 19:32:16 2008 From: arian.evans at anachronic.com (Arian J. Evans) Date: Mon, 30 Jun 2008 16:32:16 -0700 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance In-Reply-To: <4868EAFE.80907@arctecgroup.net> References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> <4868EAFE.80907@arctecgroup.net> Message-ID: Gunnar -- agreed. And for all the "fake security" in the name of PCI going on right now out there -- let's also keep in mind that it is completely valid and legitimate to attempt to operationalize software security. We scoff because to date it hasn't been done well (at all). That is just as much a technology as people problem. I know WAFS can be used fairly effectively. The recent SQL Injection bots, and folks who survived them through attack- vector filtering, are good examples of increased survivability through use of this technology. I suspect there's a backlash coming to the magic-pizza-box WAF vendors. The "magic elf inside" auto protection just does not work in most enterprise scenarios. Tangential to PCI -- the self-proclaimed top vendor in the PCI WAF space with "super-auto-learning" is losing several top accounts I've confirmed, from VARs and customers directly. Including customers on their "case studies" page. The customers ditching the "auto-learning" WAF are still using a WAF. They are just replacing it with a different kind of WAF. The two approaches I see being investigated as part of a WAF 2.0 strategy are: (a) virtual patching e.g.- only protecting things known to be weak, and (b) Fortify's code-shim "WAF" approach. Disclaimer: I work on a solution of type (a). Agreed on the people problem. There's a technology problem here too, though. And it's not a small one. Many of us throw out the baby with the bathwater due to the technology problem and the insane vendor marketing around it we've been dealing with for years. When many of our technology solutions still don't do what they say they have been able to do for 4 or 5 years, maybe it's time to start blaming some new people. -- -- Arian J. Evans. Software. Security. Stuff. On Mon, Jun 30, 2008 at 7:17 AM, Gunnar Peterson wrote: > for the vast majority of the profession - slamming the magic pizza box in a rack > is more preferable than talking to developers. in many cases the biggest barrier > to getting better security in companies is the so-called information security > group. it has very little to do with technology, its a people problem. > > -gp > > Kenneth Van Wyk wrote: >> Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear >> often.) >> >> http://www.internetnews.com/ec-news/article.php/3755916 >> >> In talking with my customers over the past several months, I always find >> it interesting that the vast majority would sooner have root canal than >> submit their source code to anyone for external review. I'm betting PCI >> 6.6 has been a boon for the web application firewall (WAF) world. >> >> >> Cheers, >> >> Ken >> >> ----- >> Kenneth R. van Wyk >> SC-L Moderator >> KRvW Associates, LLC >> http://www.KRvW.com >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >> as a free, non-commercial service to the software security community. >> _______________________________________________ > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From stephencraig.evans at gmail.com Mon Jun 30 21:02:01 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Tue, 1 Jul 2008 09:02:01 +0800 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance In-Reply-To: References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> <4868EAFE.80907@arctecgroup.net> Message-ID: <930fd0230806301802w1d28c3dfw65f0ec89fce472f1@mail.gmail.com> Hi Michael, > So, unfortunately for the WAF vendors, people can just use a static source > code analysis tool or a web application vulnerability scanner instead of > purchasing and deploying a WAF. I don't know much about PCI 6.6 (yet), but don't the organizations have to mitigate the vulnerabilities found? (fix, bear or transfer risk, use a different security control..) Surely one just doesn't have to just run the tool... I am guessing that WAFs can mitigate a considerable amount of these vulnerabilities. Automated tools suck at finding business logic flaws which just so happens to be a WAF's supposed weakness, too. So to me it seems to be a perfect marriage: automated tools that can only find bugs and WAFs that can only fix bugs :-) Stephen On Tue, Jul 1, 2008 at 5:40 AM, Michael Gavin wrote: > I too was wondering how much of a boon 6.6 would be to the WAF vendors > and/or the companies that do security code reviews. That is, until 4/22, > when the PCI SSC issued a press release > (https://www.pcisecuritystandards.org/pdfs/04-22-08.pdf) announcing an > information supplement clarifying requirement 6.6 > (https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf). > > Clearly, completing security code reviews on all of those web applications > and/or protecting them with those expensive "magic pizza boxes," which, > last time that I checked (almost 2 years ago now) were running about $35K to > start, wasn't going to happen any time soon. > > The good news from that "information supplement" is that the PCI Security > Standards Council defined what they mean by an application firewall and > specified what it is supposed to do; the less good news is that they > specified 4 alternative methods for satisfying the code review option: 1. > manual security code review, 2. automated security code review, 3. manual > web application vulnerability scan, and 4. automated web application > vulnerability scan. While I think automation of code reviews and > vulnerability scans is essential, I also believe that none of the automated > tools are yet sufficient (completeness-wise) without some additional manual > effort. > > So, unfortunately for the WAF vendors, people can just use a static source > code analysis tool or a web application vulnerability scanner instead of > purchasing and deploying a WAF. > > Michael > >> Date: Mon, 30 Jun 2008 09:17:34 -0500 >> From: gunnar at arctecgroup.net >> To: ken at krvw.com >> CC: SC-L at securecoding.org >> Subject: Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With >> PCI Compliance >> >> for the vast majority of the profession - slamming the magic pizza box in >> a rack >> is more preferable than talking to developers. in many cases the biggest >> barrier >> to getting better security in companies is the so-called information >> security >> group. it has very little to do with technology, its a people problem. >> >> -gp >> >> Kenneth Van Wyk wrote: >> > Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear >> > often.) >> > >> > http://www.internetnews.com/ec-news/article.php/3755916 >> > >> > In talking with my customers over the past several months, I always find >> > it interesting that the vast majority would sooner have root canal than >> > submit their source code to anyone for external review. I'm betting PCI >> > 6.6 has been a boon for the web application firewall (WAF) world. >> > >> > >> > Cheers, >> > >> > Ken >> > >> > ----- >> > Kenneth R. van Wyk >> > SC-L Moderator >> > KRvW Associates, LLC >> > http://www.KRvW.com >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Secure Coding mailing list (SC-L) SC-L at securecoding.org >> > List information, subscriptions, etc - >> > http://krvw.com/mailman/listinfo/sc-l >> > List charter available at - http://www.securecoding.org/list/charter.php >> > SC-L is hosted and moderated by KRvW Associates, LLC >> > (http://www.KRvW.com) >> > as a free, non-commercial service to the software security community. >> > _______________________________________________ >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - >> http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >> as a free, non-commercial service to the software security community. >> _______________________________________________ > > ________________________________ > The i'm Talkathon starts 6/24/08. For now, give amongst yourselves. Learn > More > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From Everhart at gce.com Mon Jun 30 22:43:37 2008 From: Everhart at gce.com (Mary and Glenn Everhart) Date: Mon, 30 Jun 2008 22:43:37 -0400 Subject: [SC-L] Root Canal Treatment vs Source Code Review In-Reply-To: References: Message-ID: <486999D9.5020606@gce.com> Jonathan Leffler wrote: > Under the subject "InternetNews Realtime IT News - Merchants Cope With PCI > Compliance", Kenneth Van Wyk wrote: > [...] In talking with my customers over the past several months, I always > find it interesting that the vast majority would sooner have root canal > than submit their source code to anyone for external review. [...] > > There's a simple reason for that reluctance - most people are painfully > aware that their software won't stand the scrutiny that an external review > would entail. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > There is another reason I have seen quite often: you can't readily ask the designer of the code what it does when he is dead, or when he has left the company (esp. if he works for a competitor). In many such situations I see code that gets touched at all with great fear and trembling, because people are not certain they can build it all from sources. Eventually that gets replaced, but in some cases that may be long delayed. I've used a few tools to analyze code, and noticed that mostly they don't really know how trustworthy external information is (or even, for sure, what is external). Result is much hand winnowing needed. Still they seem to take less looking than learning an entire code base. I still favor trying to characterize what functions are supposed to be invoked by calls to routines and trying to characterize this for each call....giving rise to a hopefully small number of permitted patterns for any call location. Obviously this is much easier to do for interpreters like SQL than HTML, but the approach may do better against future attacks than other approaches. Glenn Everhart From ljknews at mac.com Tue Jul 1 10:22:21 2008 From: ljknews at mac.com (ljknews) Date: Tue, 01 Jul 2008 10:22:21 -0400 Subject: [SC-L] Root Canal Treatment vs Source Code Review In-Reply-To: <486999D9.5020606@gce.com> References: <486999D9.5020606@gce.com> Message-ID: At 10:43 PM -0400 6/30/08, Mary and Glenn Everhart wrote: > There is another reason I have seen quite often: you can't readily ask > the designer of > the code what it does when he is dead, or when he has left the company > (esp. if he works for a competitor). When I participated (as author) in formal inspection there were as many defects found (and fixed) in the comments as in the code. And most people think my comments are better than average. I have "left the company" but still have some access to see what defects they have found since. -- Larry Kilgallen From mkgavin at hotmail.com Tue Jul 1 18:13:39 2008 From: mkgavin at hotmail.com (Michael Gavin) Date: Tue, 1 Jul 2008 18:13:39 -0400 Subject: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance In-Reply-To: <930fd0230806301802w1d28c3dfw65f0ec89fce472f1@mail.gmail.com> References: <7A54FC3B-2923-485E-B745-F575940259B0@krvw.com> <4868EAFE.80907@arctecgroup.net> <930fd0230806301802w1d28c3dfw65f0ec89fce472f1@mail.gmail.com> Message-ID: Hi Stephen, Yes, organizations must resolve the issues discovered by the automated tools, at least to the extent that the tool no longer complains. While implementing both options of requirement 6.6 is recommended, it is not required by PCI DSS. Instead of doing what you propose, I suspect most companies will use an automated tool, deal with the underlying issues in their codebase, and run the tool again; but not do that plus buy and deploy a WAF as well. Michael> Date: Tue, 1 Jul 2008 09:02:01 +0800> From: stephencraig.evans at gmail.com> To: mkgavin at hotmail.com> Subject: Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance> CC: gunnar at arctecgroup.net; ken at krvw.com; sc-l at securecoding.org> > Hi Michael,> > > So, unfortunately for the WAF vendors, people can just use a static source> > code analysis tool or a web application vulnerability scanner instead of> > purchasing and deploying a WAF.> > I don't know much about PCI 6.6 (yet), but don't the organizations> have to mitigate the vulnerabilities found? (fix, bear or transfer> risk, use a different security control..) Surely one just doesn't have> to just run the tool... I am guessing that WAFs can mitigate a> considerable amount of these vulnerabilities. Automated tools suck at> finding business logic flaws which just so happens to be a WAF's> supposed weakness, too.> > So to me it seems to be a perfect marriage: automated tools that can> only find bugs and WAFs that can only fix bugs :-)> > Stephen> > On Tue, Jul 1, 2008 at 5:40 AM, Michael Gavin wrote:> > I too was wondering how much of a boon 6.6 would be to the WAF vendors> > and/or the companies that do security code reviews. That is, until 4/22,> > when the PCI SSC issued a press release> > (https://www.pcisecuritystandards.org/pdfs/04-22-08.pdf) announcing an> > information supplement clarifying requirement 6.6> > (https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf).> >> > Clearly, completing security code reviews on all of those web applications> > and/or protecting them with those expensive "magic pizza boxes," which,> > last time that I checked (almost 2 years ago now) were running about $35K to> > start, wasn't going to happen any time soon.> >> > The good news from that "information supplement" is that the PCI Security> > Standards Council defined what they mean by an application firewall and> > specified what it is supposed to do; the less good news is that they> > specified 4 alternative methods for satisfying the code review option: 1.> > manual security code review, 2. automated security code review, 3. manual> > web application vulnerability scan, and 4. automated web application> > vulnerability scan. While I think automation of code reviews and> > vulnerability scans is essential, I also believe that none of the automated> > tools are yet sufficient (completeness-wise) without some additional manual> > effort.> >> > So, unfortunately for the WAF vendors, people can just use a static source> > code analysis tool or a web application vulnerability scanner instead of> > purchasing and deploying a WAF.> >> > Michael> >> >> Date: Mon, 30 Jun 2008 09:17:34 -0500> >> From: gunnar at arctecgroup.net> >> To: ken at krvw.com> >> CC: SC-L at securecoding.org> >> Subject: Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With> >> PCI Compliance> >>> >> for the vast majority of the profession - slamming the magic pizza box in> >> a rack> >> is more preferable than talking to developers. in many cases the biggest> >> barrier> >> to getting better security in companies is the so-called information> >> security> >> group. it has very little to do with technology, its a people problem.> >>> >> -gp> >>> >> Kenneth Van Wyk wrote:> >> > Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear> >> > often.)> >> >> >> > http://www.internetnews.com/ec-news/article.php/3755916> >> >> >> > In talking with my customers over the past several months, I always find> >> > it interesting that the vast majority would sooner have root canal than> >> > submit their source code to anyone for external review. I'm betting PCI> >> > 6.6 has been a boon for the web application firewall (WAF) world.> >> >> >> >> >> > Cheers,> >> >> >> > Ken> >> >> >> > -----> >> > Kenneth R. van Wyk> >> > SC-L Moderator> >> > KRvW Associates, LLC> >> > http://www.KRvW.com> >> >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------> >> >> >> > _______________________________________________> >> > Secure Coding mailing list (SC-L) SC-L at securecoding.org> >> > List information, subscriptions, etc -> >> > http://krvw.com/mailman/listinfo/sc-l> >> > List charter available at - http://www.securecoding.org/list/charter.php> >> > SC-L is hosted and moderated by KRvW Associates, LLC> >> > (http://www.KRvW.com)> >> > as a free, non-commercial service to the software security community.> >> > _______________________________________________> >> _______________________________________________> >> Secure Coding mailing list (SC-L) SC-L at securecoding.org> >> List information, subscriptions, etc -> >> http://krvw.com/mailman/listinfo/sc-l> >> List charter available at - http://www.securecoding.org/list/charter.php> >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)> >> as a free, non-commercial service to the software security community.> >> _______________________________________________> >> > ________________________________> > The i'm Talkathon starts 6/24/08. For now, give amongst yourselves. Learn> > More> > _______________________________________________> > Secure Coding mailing list (SC-L) SC-L at securecoding.org> > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l> > List charter available at - http://www.securecoding.org/list/charter.php> > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)> > as a free, non-commercial service to the software security community.> > _______________________________________________> >> > _________________________________________________________________ It?s a talkathon ? but it?s not just talk. http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080701/f86ae165/attachment.html From ken at krvw.com Thu Jul 3 11:39:35 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 3 Jul 2008 11:39:35 -0400 Subject: [SC-L] Google opens RatProxy security code - SC Magazine US Message-ID: FYI, there's a new web app proxy testing tool out there, RatProxy. I saw it announced a couple days ago and here's another story on it: http://www.scmagazineus.com/Google-opens-RatProxy-security-code/article/112074/ Anyone here tried it out yet? How is it any different than WebScarab or Paros Proxy? Worth keeping in one's web app testing arsenal? Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080703/bd16fbcb/attachment.bin From gem at cigital.com Thu Jul 10 14:48:14 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 10 Jul 2008 14:48:14 -0400 Subject: [SC-L] online game security Message-ID: hi sc-l, Those of you who read Exploiting Online Games know why I believe online games are a harbinger of software security issues to come. IEEE S&P magazine will publish a special issue on online game security next year. You can find the CFP here: http://www.cigital.com/online-game-security-CFP.pdf Please post this CFP and share it as widely as possible. We're hoping for a strong special issue. gem company www.cigital.com podcast www.cigital.com/silverbullet (just interviewed ches this morning) blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Tue Jul 15 11:57:22 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 15 Jul 2008 11:57:22 -0400 Subject: [SC-L] Animations for training Message-ID: hi sc-l, Markus Schumacher of Virtual Forge (a German firm specializing in software security and SAP) has created a set of animations to help train technical people about common Web attacks. Cigital is now hosting some of the videos (which you may find useful in your work). You can find pointers on the Justice League blog: http://www.cigital.com/justiceleague/2008/07/15/more-on-comics-and-security/ Hope you find the animations useful. gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com From gem at cigital.com Tue Jul 15 15:47:16 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 15 Jul 2008 15:47:16 -0400 Subject: [SC-L] Silver Bullet: ches Message-ID: hi sc-l, Bill Cheswick is the Silver Bullet victim for episode 28. ches and I had plenty of fun discussing many aspects of security, including his opinion that we haven't made much progress in software security! Interesting. Have a listen and please feel free to hop on the website and post a comment: http://www.cigital.com/silverbullet/show-028/ gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Thu Jul 17 13:31:29 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 17 Jul 2008 13:31:29 -0400 Subject: [SC-L] application assessment factories Message-ID: hi sc-l, One of the problems we've faced more than once in our work at Cigital is mis-use of good metrics. A great example of a very useful metric that can be misused is cost per bug (or cost per defect if you are also interested in flaws). We've seen CIO-level managers comparing pen testing to code review with a static analysis tool in terms of this metric---something that can be entirely misleading. In order to combat that problem, we've been instantiating application assessment factories with our customers. I briefly describe the concept (which was invented by John Steven) in my InformIT column this month. Check it out: http://www.informit.com/articles/article.aspx?p=1231818 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From jeremy.j.epstein at gmail.com Sat Jul 19 16:28:20 2008 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Sat, 19 Jul 2008 16:28:20 -0400 Subject: [SC-L] Goodbye to faulty software? Message-ID: Saw this article: http://cordis.europa.eu/ictresults/popup.cfm?section=news&tpl=article&ID=89864&AutoPrint=True, and was wondering if anyone on this list knows anything about the project or Dr Bengt Nordstr?m at Chalmers University in G?teborg Sweden. Sounds to me like they're reinventing all the old formal methods / provable code stuff - but perhaps I'm wrong. Thoughts? --Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080719/01f78953/attachment.html From ken at krvw.com Mon Jul 21 13:34:21 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 21 Jul 2008 13:34:21 -0400 Subject: [SC-L] Administrivia Message-ID: <34402C1D-CCFF-4E00-BCC5-F394E7307B28@krvw.com> Greetings SC-L folks, A couple things re the mailing list... - It's been a couple months since I asked for your opinions regarding accepting sponsorships here on SC-L. Although the opinions I received were almost entirely in favor or neutral -- all but one -- I haven't decided to pull that trigger in any case. I do appreciate your inputs, as always, however. - I'd also like to clarify a posting policy here. The list gets, from time to time, conference announcements, CfPs, and such. I want to be explicit here that I fully encourage that, and would like to take it one step further. Training events that are open to the public may also be announced here, once per event. This includes commercial events. As always, ASCII text is preferred, and no HTML please. But I feel this policy is in line with what I see on other groups. Full disclosure: my own company does do occasional public training events from time to time and I'd like to be able to let folks know about it here. Again, one posting per event announcement. Your opinions, as always, are appreciated. Feel free to contact me on- or off-list about either of these policies. My goal here remains to keep the list a free and open forum for us to discuss matters related to software security. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080721/9258491e/attachment.bin From tomb at owasp.org Mon Jul 21 15:09:59 2008 From: tomb at owasp.org (Tom Brennan) Date: Mon, 21 Jul 2008 15:09:59 -0400 Subject: [SC-L] Application Security Conference In-Reply-To: <34402C1D-CCFF-4E00-BCC5-F394E7307B28@krvw.com> References: <34402C1D-CCFF-4E00-BCC5-F394E7307B28@krvw.com> Message-ID: <9EDC687CA2E040499BDE9E656DD3EABC@prolpt01> The OWASP 2008 Application Security Conference is September 24th & 25th 2008 in New York City. (Less than 60 days away) With over 50 APPSEC speakers, 6 training classes and a Capture the Flag event. This event is the largest web application security focused conference anywhere, don't miss it! Event agenda and registration : http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference *NOTE* We have already had reports of some hotels being "booked solid", secure your ticket and book your travel ASAP and join OWASP to take a bite out of the "Big Apple". Sincerely, Tom Brennan - Board Member OWASP Foundation http://www.linkedin.com/in/tombrennan O: 973-795-1046 x112 W: www.owasp.org -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Monday, July 21, 2008 1:34 PM To: Secure Coding Subject: [SC-L] Administrivia Greetings SC-L folks, A couple things re the mailing list... - It's been a couple months since I asked for your opinions regarding accepting sponsorships here on SC-L. Although the opinions I received were almost entirely in favor or neutral -- all but one -- I haven't decided to pull that trigger in any case. I do appreciate your inputs, as always, however. - I'd also like to clarify a posting policy here. The list gets, from time to time, conference announcements, CfPs, and such. I want to be explicit here that I fully encourage that, and would like to take it one step further. Training events that are open to the public may also be announced here, once per event. This includes commercial events. As always, ASCII text is preferred, and no HTML please. But I feel this policy is in line with what I see on other groups. Full disclosure: my own company does do occasional public training events from time to time and I'd like to be able to let folks know about it here. Again, one posting per event announcement. Your opinions, as always, are appreciated. Feel free to contact me on- or off-list about either of these policies. My goal here remains to keep the list a free and open forum for us to discuss matters related to software security. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com From gem at cigital.com Wed Jul 23 11:21:21 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 23 Jul 2008 11:21:21 -0400 Subject: [SC-L] SB transcript: Shostack Message-ID: hi sc-l, For those of you who liked the Shostack episode of Silver Bullet, the transcript was posted today and will soon appear in IEEE Security & Privacy magazine. http://www.cigital.com/silverbullet/shows/silverbullet-026-ashostack.pdf gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Thu Jul 31 15:50:52 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 31 Jul 2008 15:50:52 -0400 Subject: [SC-L] New podcast: Techtarget Message-ID: hi sc-l, Techtarget just launched a podcast series (if you can call one podcast a series!) hosted by Dennis Fisher. Dennis conned me into being the first victim. We spent the entire episode talking about software security. http://securitywireweekly.blogs.techtarget.com/2008/07/31/the-state-of-software-security/ As an extra bonus, the podcast uses one of my songs from my band as its theme song. w00t! gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From goertzel_karen at bah.com Wed Aug 6 11:31:46 2008 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 6 Aug 2008 11:31:46 -0400 Subject: [SC-L] Interesting academic job announcement In-Reply-To: References: Message-ID: <184D5FFC5203644FB4F8864B0EE445B40290298D@MCLNEXVS06.resource.ds.bah.com> I stumbled across this and thought it was worth sharing in case there's anyone out there looking for an academic position in Europe: Two PhD Positions in Secure Software and Languages Department of Computer Science Katholieke Universiteit Leuven, Belgium Applications are invited for two PhD positions within the DistriNet Research Group at the Katholieke Universiteit Leuven, Belgium. The research will be conducted under the supervision of David Clarke. * Research topics: These positions are devoted to research on secure software and languages, including, but not limited to: * modelling highly adaptable trustworthy systems * types and models for software families * logic and type systems for security; ownership types; pluggable types * programming languages for secure software * Profile & skills - Clear interest in and knowledge of the subject, based on education, work or research experience - Masters in Computer Science or Informatics - Team player; capability to work in an international research team - Proficiency in English and excellent communication skills, both oral and written - Prior knowledge in the areas of type systems, security, programming languages and/or formal methods is an advantage. * About DistriNet The "Distributed systems and computer Networks?" (DistriNet) research group was founded in 1984 as part of the Department of Computer Science at the K.U.Leuven. DistriNet's research focus and scope is twofold: distributed software? and secure software. The group works on a wide range of topics including computer networks, middleware, internet architectures, network and software security, embedded systems and multi-agent systems. DistriNet's research is generally application driven and often conducted in collaboration with industry partners. Currently DistriNet counts 60 members (8 professors, 12 post-docs and 45 junior researchers) and participates in about 30 national and international research projects. The annual budget amounts to approximately 5MEuro. More information on projects and publications can be found on the DistriNet web pages: http://distrinet.cs.kuleuven.be/ * About Leuven Lively Leuven is a picturesque and upbeat Flemish city, just 25km from Brussels, and within 3 hours of major European centres such as Antwerp, Amsterdam, London and Paris. Leuven is shaped by its healthy student population - some 25,000 of them - more than a quarter of the town's population. * Further Information and Application Procedure Requests for further information and other informal enquiries can be sent to: Dr. David Clarke David.Clarke at cs.kuleuven.be Those interested in the position are asked to send e-mail to the address given above. Full Details of the application process are available upon request, but an application will include: 1. A cover letter stating the applicant's interest in the project. 2. A full curriculum vitae, including an abstract of the applicant's master's thesis and the name of their supervisor. 3. Letters of recommendation or references from at least two scientific staff members. (Letters of recommendation should either be included along with the application, or should arrive separately promptly.) 4. A completed application for postgraduate study at the K.U.Leuven. Applications and instructions are available at http://www.kuleuven.be/phd/ Applications will be considered until the position is filled, but those received on or before 15 August 2008 will have priority. The PhD positions are for 4 years. The start date is negotiable, 1 October 2008 at the earliest. From gem at cigital.com Tue Aug 12 12:33:37 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 12 Aug 2008 12:33:37 -0400 Subject: [SC-L] software security growing (informIT) Message-ID: hi sc-l, In April 2007, I published a darkreading article on the size of the software security space with some analysis of what was happening. It took me a bit longer to gather the numbers this year, but I finally got what I needed and published an informIT article yesterday explaining how software security is growing: http://www.informit.com/articles/article.aspx?p=1237978 I am encouraged that the field continues to thrive even in the face of the recession we're in. Even more encouraging is the evolution in the space in the right direction. Towards white box analysis pf all software and out of the small but important sub-domain of Web apps. And towards full lifecycle SDLC based programs incorporating the Touchpoints. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleage book www.swsec.com From tomb at owasp.org Wed Aug 13 23:30:21 2008 From: tomb at owasp.org (Tom Brennan) Date: Wed, 13 Aug 2008 23:30:21 -0400 Subject: [SC-L] Conference Announcement In-Reply-To: <34402C1D-CCFF-4E00-BCC5-F394E7307B28@krvw.com> References: <34402C1D-CCFF-4E00-BCC5-F394E7307B28@krvw.com> Message-ID: <5BF590ADAF064323BC7B8E3A777BC18E@prolpt01> Final conference announcement for the OWASP APPSEC 2008, USA NYC event http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Take a look - it's the largest appsec focused event in the world, yes bigger than blackhat as we're just appsec! From ht at computerdefense.org Mon Aug 18 13:52:56 2008 From: ht at computerdefense.org (Tyler Reguly) Date: Mon, 18 Aug 2008 13:52:56 -0400 Subject: [SC-L] Denial of Service Survey Message-ID: <1f313f070808181052w4f9df14ald2033a3b7765ab76@mail.gmail.com> Hey All, I'm usually more of a lurker, but since I'm attempting to gather some statistics, I thought I'd make use of the mailing lists I read. I'm dong a survey on Denial of Service and people's perception related to it and I'd love if anyone had time to complete the survey tied to it Also, I realize that this is a development mailing list more than a security mailing list, however that's what I'm looking for in this case. I'm really interested in developer responses to this. So feel free to pass it along to other developers. http://computerdefense.org/tinc?key=qHVCmALG&formname=dosSurvey Thanks, Tyler Reguly ComputerDefense.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080818/f4f78a15/attachment.html From gem at cigital.com Mon Aug 18 11:43:01 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 18 Aug 2008 11:43:01 -0400 Subject: [SC-L] Silver Bullet 29: Dennis Fisher Message-ID: hi sc-l, The current episode of Silver Bullet was just released today. http://www.cigital.com/silverbullet/show-029/ In this episode, I chat with Dennis Fisher who has been covering security for many many years. I've known Dennis for a long time, and he has always been very good at his job. We talk plenty about software security in this episode. Interesting (to me anyway), was Dennis's statement that software security is playing a growing and important role in the entire computer security space. Of course, we all think that on this list, but we're biased. It's nice to have an outside perspective concur. In my view, the numbers back that up as I stated in my informIT column (lots of numbers in here for those of you interested in how big companies actually are): http://www.informit.com/articles/article.aspx?p=1237978 As usual, your feedback is welcome and greatly appreciated. Shouts to silver bullet co-sponsor IEEE Security & Privacy magazine. gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Fri Aug 22 14:43:46 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 22 Aug 2008 14:43:46 -0400 Subject: [SC-L] Survey Message-ID: hi sc-l, BankInfoSecurity is running a survey on software security that some of you may be interested in participating in. Try it yourself here: http://www.bankinfosecurity.com/surveys.php?surveyID=1 I just ran through the survey. All told it only takes a couple of minutes. I found the questions and the possible answers to choose from interesting. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ljknews at mac.com Sat Aug 23 13:02:45 2008 From: ljknews at mac.com (ljknews) Date: Sat, 23 Aug 2008 13:02:45 -0400 Subject: [SC-L] Survey In-Reply-To: References: Message-ID: At 2:43 PM -0400 8/22/08, Gary McGraw wrote: > BankInfoSecurity is running a survey on software security that some of you may be interested in participating in. Try it yourself here: > > http://www.bankinfosecurity.com/surveys.php?surveyID=1 Hmmm. http://validator.w3.org says there are 973 errors on that page. -- Larry Kilgallen From gem at cigital.com Sun Aug 24 10:57:23 2008 From: gem at cigital.com (Gary McGraw) Date: Sun, 24 Aug 2008 10:57:23 -0400 Subject: [SC-L] Survey Message-ID: <41945506397C0C4886A8C5BFF089B5CA354B2A34B0@va-mailhub.cigital.com> Most excellent. Somebody should pass that on to them. I think I will! gem ----- Original Message ----- From: sc-l-bounces at securecoding.org To: Secure Mailing List Sent: Sat Aug 23 13:02:45 2008 Subject: Re: [SC-L] Survey At 2:43 PM -0400 8/22/08, Gary McGraw wrote: > BankInfoSecurity is running a survey on software security that some of you may be interested in participating in. Try it yourself here: > > http://www.bankinfosecurity.com/surveys.php?surveyID=1 Hmmm. http://validator.w3.org says there are 973 errors on that page. -- Larry Kilgallen _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From Paco at cigital.com Sun Aug 24 11:11:16 2008 From: Paco at cigital.com (Paco Hope) Date: Sun, 24 Aug 2008 11:11:16 -0400 Subject: [SC-L] Survey In-Reply-To: References: Message-ID: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> Clearly the survey's content is only of interest if the HTML validates. On Aug 24, 2008, at 9:47 AM, "ljknews" wrote: > At 2:43 PM -0400 8/22/08, Gary McGraw wrote: > >> BankInfoSecurity is running a survey on software security that some >> of you may be interested in participating in. Try it yourself here: >> >> http://www.bankinfosecurity.com/surveys.php?surveyID=1 > > Hmmm. http://validator.w3.org says there are 973 errors on that page. > -- > Larry Kilgallen > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ From ljknews at mac.com Sun Aug 24 12:14:16 2008 From: ljknews at mac.com (ljknews) Date: Sun, 24 Aug 2008 12:14:16 -0400 Subject: [SC-L] Survey In-Reply-To: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> Message-ID: At 11:11 AM -0400 8/24/08, Paco Hope wrote: > Clearly the survey's content is only of interest if the HTML validates. The publisher of the web page is not in the security business, they are in the publishing business. But how can I respect their publishing expertise if they fail a simple automatic test. And how can their target audience of security folk, who depend strongly on following standards respect the knowledge of a publisher who does not follow publishing standards. > On Aug 24, 2008, at 9:47 AM, "ljknews" wrote: > >> At 2:43 PM -0400 8/22/08, Gary McGraw wrote: >> >>> BankInfoSecurity is running a survey on software security that some >>> of you may be interested in participating in. Try it yourself here: >>> >>> http://www.bankinfosecurity.com/surveys.php?surveyID=1 >> >> Hmmm. http://validator.w3.org says there are 973 errors on that page. -- Larry Kilgallen From jim at manico.net Sun Aug 24 19:05:42 2008 From: jim at manico.net (Jim Manico) Date: Sun, 24 Aug 2008 13:05:42 -1000 Subject: [SC-L] Survey In-Reply-To: References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> Message-ID: <48B1E946.3060503@manico.net> There are plenty of sites that are perfectly x/html valid that are completely insecure. There are plenty of sites that follow perfect w3c and other standards that are completely insecure. There are plenty of sites that are top-tier security vendors that, at least in the past, have been insecure. - Jim > At 11:11 AM -0400 8/24/08, Paco Hope wrote: > > >> Clearly the survey's content is only of interest if the HTML validates. >> > > The publisher of the web page is not in the security business, > they are in the publishing business. But how can I respect > their publishing expertise if they fail a simple automatic > test. > > And how can their target audience of security folk, who depend > strongly on following standards respect the knowledge of a > publisher who does not follow publishing standards. > > >> On Aug 24, 2008, at 9:47 AM, "ljknews" wrote: >> >> >>> At 2:43 PM -0400 8/22/08, Gary McGraw wrote: >>> >>> >>>> BankInfoSecurity is running a survey on software security that some >>>> of you may be interested in participating in. Try it yourself here: >>>> >>>> http://www.bankinfosecurity.com/surveys.php?surveyID=1 >>>> >>> Hmmm. http://validator.w3.org says there are 973 errors on that page. >>> -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com --------------------------------------------------------------- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080824/f36f31a3/attachment.html From ljknews at mac.com Sun Aug 24 19:22:28 2008 From: ljknews at mac.com (ljknews) Date: Sun, 24 Aug 2008 19:22:28 -0400 Subject: [SC-L] Survey In-Reply-To: <20080824192126.133528abydpsacc6@webmail.nist.gov> References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <20080824192126.133528abydpsacc6@webmail.nist.gov> Message-ID: At 7:21 PM -0400 8/24/08, rgaucher at nist.gov wrote: >> The publisher of the web page is not in the security business, >> they are in the publishing business. But how can I respect >> their publishing expertise if they fail a simple automatic >> test. > > Well, I guess that most of web developers are not validating with > tools such as w3 validators, but more interesting, validating with > different browsers... My experience is that browsers succeed on standards-compliant pages. Standard compliance should be the first test. If it subsequently fails on a particular browser, it is a browser defect which may or may not be of interest to the publisher. -- Larry Kilgallen From romain.gaucher at nist.gov Tue Aug 26 09:32:55 2008 From: romain.gaucher at nist.gov (Romain Gaucher) Date: Tue, 26 Aug 2008 09:32:55 -0400 Subject: [SC-L] Survey In-Reply-To: References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <20080824192126.133528abydpsacc6@webmail.nist.gov> Message-ID: <48B40607.5060707@nist.gov> ljknews wrote: > My experience is that browsers succeed on standards-compliant > pages. Standard compliance should be the first test. If it > subsequently fails on a particular browser, it is a browser > defect which may or may not be of interest to the publisher. Agreed that, talking only about HTML, browsers are okay with standard page. But nowadays, pages are not only HTML, but CSS, JavaScript, etc. Then the validators are not useful: a CSS will most likely have different rendering even if it's w3 compliant. Then, talking about publishers, of course they care about particular bugs of browsers, and that's why web interface are tough to do! You need to have a good/almost-consistent rendering on different browsers... no matter if they have bugs or not. --Romain http://rgaucher.info From stephencraig.evans at gmail.com Tue Aug 26 10:41:51 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Tue, 26 Aug 2008 22:41:51 +0800 Subject: [SC-L] Survey In-Reply-To: <48B1E946.3060503@manico.net> References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <48B1E946.3060503@manico.net> Message-ID: <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> Hi Jim, " There are plenty of sites that are perfectly x/html valid that are completely insecure." Well, perhaps too many people have been listening to this drumbeat: "In fact, a non-developer: such as someone in marketing who uses Dreamweaver, could also do almost as much as a normal WAF by saving their content as valid XHTML. This would buy the organization basic application security functionality, which is what WAF also attempts to do." http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/ I rest my case. Stephen On Mon, Aug 25, 2008 at 7:05 AM, Jim Manico wrote: > There are plenty of sites that are perfectly x/html valid that are > completely insecure. > > There are plenty of sites that follow perfect w3c and other standards that > are completely insecure. > > There are plenty of sites that are top-tier security vendors that, at least > in the past, have been insecure. > > - Jim > > At 11:11 AM -0400 8/24/08, Paco Hope wrote: > > > > Clearly the survey's content is only of interest if the HTML validates. > > > The publisher of the web page is not in the security business, > they are in the publishing business. But how can I respect > their publishing expertise if they fail a simple automatic > test. > > And how can their target audience of security folk, who depend > strongly on following standards respect the knowledge of a > publisher who does not follow publishing standards. > > > > On Aug 24, 2008, at 9:47 AM, "ljknews" wrote: > > > > At 2:43 PM -0400 8/22/08, Gary McGraw wrote: > > > > BankInfoSecurity is running a survey on software security that some > of you may be interested in participating in. Try it yourself here: > http://www.bankinfosecurity.com/surveys.php?surveyID=1 > > Hmmm. http://validator.w3.org says there are 973 errors on that page. > > > > > -- > Jim Manico, Senior Application Security Engineerjim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the sourcehttp://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY.http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080826/168c4d3f/attachment.html From jim at manico.net Tue Aug 26 15:12:01 2008 From: jim at manico.net (Jim Manico) Date: Tue, 26 Aug 2008 09:12:01 -1000 Subject: [SC-L] Survey In-Reply-To: <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <48B1E946.3060503@manico.net> <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> Message-ID: <48B45581.5040607@manico.net> How does xHTML help stop access control vulnerabilities? Authorization issues? CSRF problems? And who is to say that an attacker cannot still do server side injection (sql injection, ldap injection) or timing attacks? I'm just getting started. xHTML is only one tiny piece of the outbound encoding problem. Hey, while we are at it - who is to say that someone mounting a MITM attack could not modify/corrupt data and still be (woo ho) xHTML valid? - Jim > > Hi Jim, > > " There are plenty of sites that are perfectly x/html valid that are > completely insecure." > > Well, perhaps too many people have been listening to this drumbeat: > "In fact, a non-developer: such as someone in marketing who uses > Dreamweaver, could also do almost as much as a normal WAF by saving > their content as valid XHTML. This would buy the organization basic > application security functionality, which is what WAF also attempts to > do." > > http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/ > > I rest my case. > Stephen > > On Mon, Aug 25, 2008 at 7:05 AM, Jim Manico > wrote: > > There are plenty of sites that are perfectly x/html valid that are > completely insecure. > > There are plenty of sites that follow perfect w3c and other > standards that are completely insecure. > > There are plenty of sites that are top-tier security vendors that, > at least in the past, have been insecure. > > - Jim > > >> At 11:11 AM -0400 8/24/08, Paco Hope wrote: >> >> >>> Clearly the survey's content is only of interest if the HTML validates. >>> >> The publisher of the web page is not in the security business, >> they are in the publishing business. But how can I respect >> their publishing expertise if they fail a simple automatic >> test. >> >> And how can their target audience of security folk, who depend >> strongly on following standards respect the knowledge of a >> publisher who does not follow publishing standards. >> >> >>> On Aug 24, 2008, at 9:47 AM, "ljknews" wrote: >>> >>> >>>> At 2:43 PM -0400 8/22/08, Gary McGraw wrote: >>>> >>>> >>>>> BankInfoSecurity is running a survey on software security that some >>>>> of you may be interested in participating in. Try it yourself here: >>>>> >>>>> http://www.bankinfosecurity.com/surveys.php?surveyID=1 >>>>> >>>> Hmmm. http://validator.w3.org says there are 973 errors on that page. >>>> > > > -- > Jim Manico, Senior Application Security Engineer > jim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the source > http://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY. > http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com --------------------------------------------------------------- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080826/58fc08c1/attachment.html From ljknews at mac.com Tue Aug 26 16:03:39 2008 From: ljknews at mac.com (ljknews) Date: Tue, 26 Aug 2008 16:03:39 -0400 Subject: [SC-L] Survey In-Reply-To: <48B45581.5040607@manico.net> References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <48B1E946.3060503@manico.net> <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> <48B45581.5040607@manico.net> Message-ID: At 9:12 AM -1000 8/26/08, Jim Manico wrote: > How does xHTML help stop access control vulnerabilities? > Authorization issues? CSRF problems? It is indicative of the caliber of the people who built the site. My immediate interest is that validation combats browser crashes. I am not interested in dealing with people who cannot get the simple things right. -- Larry Kilgallen From Paco at cigital.com Tue Aug 26 16:49:21 2008 From: Paco at cigital.com (Paco Hope) Date: Tue, 26 Aug 2008 16:49:21 -0400 Subject: [SC-L] Survey In-Reply-To: Message-ID: On 8/26/08 3:03 PM, "ljknews" wrote: I am not interested in dealing with people who cannot get the simple things right. Right. Because we all know that the HTML, xHTML, DHTML, CSS, and the related standards are really simple. Nothing to it. Writing valid HTML in our applications is a snap. And when management says "so, why are we a week late getting the application into production?" they'll be pleased to hear that it was to make sure the HTML on all 300 screens validated. Nevermind that the app was satisfying its users and business owners when it didn't validate. It's important to make the validation programs happy, not the users or the business. As it is, web applications are shoved out the door with insufficient attention paid to their functional capabilities. Then there's the insufficient attention paid to their security capabilities. Standards compliance is orthogonal to all that. I'd rather have a functional and sufficiently secure web site that was non-compliant than one that was compliant but lacking in functionality or security. Either way, I think Gary's point in putting the survey out on this list was to see if we were interested in the survey. It's a shame we've gone off on a tangent about the value of validating HTML. Paco -- Paco Hope, CISSP Technical Manager, Cigital, Inc http://www.cigital.com/ * +1.703.585.7868 Software Confidence. Achieved. From jim at manico.net Tue Aug 26 17:06:21 2008 From: jim at manico.net (Jim Manico) Date: Tue, 26 Aug 2008 11:06:21 -1000 Subject: [SC-L] Survey In-Reply-To: References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <48B1E946.3060503@manico.net> <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> <48B45581.5040607@manico.net> Message-ID: <48B4704D.3090304@manico.net> Making a very complex Ajax rich-client web applications perfectly xHTML valid is not easy. Most of the enterprise world goes way beyond simple flat file xHTML. Add in (the real reality of) highly database-drive dynamically generated javascript/ajax heavy pages, and I continue to conjecture that perfect xHTML is not only not that important but very difficult to accomplish. Or at least it's not "simple" as you state below. Heck, who is to say that you can't accomplish XSS or other client-side attacks and still be xHTML compliant? I think you would go a lot further in securing your apps if you got programmers to html entity encode output data, actually do access control right, encode data on the server side to prevent injection attacks, etc. Sure the WAF world would like xHTML - but we do not live in a perfect world. Most sites are not xHTML compliant in the enterprise. - Jim > At 9:12 AM -1000 8/26/08, Jim Manico wrote: > > >> How does xHTML help stop access control vulnerabilities? >> Authorization issues? CSRF problems? >> > > It is indicative of the caliber of the people who built > the site. > > My immediate interest is that validation combats browser crashes. > > I am not interested in dealing with people who cannot get > the simple things right. > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com --------------------------------------------------------------- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080826/4a400937/attachment.html From ken at krvw.com Tue Aug 26 18:18:10 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 26 Aug 2008 18:18:10 -0400 Subject: [SC-L] Survey thread killer Message-ID: <249A7B20-52C6-4600-B0B2-129FA9C78281@krvw.com> Hi SC-Lers, With these last 2 messages, let's kill off the survey thread, please. I allowed it to continue on--probably longer than I should have-- because there seemed to be valid and interesting points being made on both sides of the debate. But that seems to have run its course, so let's please let it die out. Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20080826/4c192420/attachment.bin From gunnar at arctecgroup.net Wed Aug 27 07:59:19 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Wed, 27 Aug 2008 06:59:19 -0500 Subject: [SC-L] Building Secure Web Applications Training in Minneapolis Message-ID: <48B54197.5040102@arctecgroup.net> Ken van Wyk and I are teaching Building Secure Web Applications in Java/J2EE in Minneapolis, September 30 - October 2. The summary is below, if you would like more info please let me know. More details to follow. Building Secure Web Applications in Java/J2EE Course Description This course teaches the students how to develop secure applications from the web front end through the middle tier and data and integration layers for today?s complex internetworked environment. Students will receive a deep and thorough understanding of the most prevalent and dangerous security defects in today?s applications, and what to do about them. Additionally, they will learn practical and actionable guidelines on how to remediate against these common defects in Java/J2EE and Web Services frameworks and how to test for them in their own applications. This class starts with a description of the security problems faced by today's software developer, as well as a detailed description of the Open Web Application Security Project?s (OWASP) ?Top 10? security defects. These defects are studied in instructor-lead sessions as well as in hands-on lab exercises in which each student learns how to actually exploit the defects to ?break into? a real web application. (The labs are performed in safe test environments.) Remediation techniques and strategies are then studied for each defect. Practical guidelines on how to integrate secure development practices into the software development process are then presented and discussed. Bring the concepts and hands on learning together, the class uses a case study to show how to design and architect security services for a real world application. Intended Audience The ideal student for this tutorial is a hands-on web application developer or architect who is looking for a fundamental understanding of today's best practices in secure software development. From cfp at ruxcon.org.au Tue Sep 2 01:14:34 2008 From: cfp at ruxcon.org.au (cfp at ruxcon.org.au) Date: Tue, 2 Sep 2008 05:14:34 +0000 (UTC) Subject: [SC-L] RUXCON 2008 Final Call For Papers Message-ID: <20080902051434.80E4636F0D5@mail.ruxcon.org.au> RUXCON 2008 FINAL CALL FOR PAPERS Ruxcon would like to announce the final call for papers for the fifth annual Ruxcon conference. This year the conference will take place over the weekend of 29th to the 30th of November. As with previous years, Ruxcon will be held at the University of Technology, Sydney, Australia. The deadline for submissions is the 15th of November. * What is Ruxcon? Ruxcon strives to be Australia's most technical and interesting computer security conference. We're back for the fifth year and intend on bringing you another high quality conference. The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst expanding their knowledge of security. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from unpublished research to required reading for the public security community. For more information, please visit http://www.ruxcon.org.au * Presentation Information Presentations are set to run for 50 minutes, and will be of a formal nature, with slides and a speech. * Presentation Submissions Ruxcon would like to invite people who are interested in security to submit a presentation. Topics of interest include, but are not limited to: o Code analysis o Exploitation techniques o Network scanning and analysis o Cryptography o Malware Analysis o Reverse engineering o Forensics and Anti-forensics o Social engineering o Web application security o Database security o Legal aspects of computer security and surrounding issues o Law enforcement activities o Telecommunications security (mobile, GSM, VOIP, etc.) Submissions should thoroughly outline your desired presentation subject. Accompanying your submission should be the slides you intend to use or a detailed paper explaining your subject. If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations @ ruxcon dot org dot au The deadline for submissions is the 15th of November. If approved we will additionally require: i. A brief personal biography (between 2-5 paragraphs in length), including: skill set, experience, and credentials. ii. A description on your presentation or workshop (between 2-5 paragraphs in length). * Contact Details Presentation Submissions: presentations @ ruxcon dot org dot au General Enquiries: staff @ ruxcon dot org dot au From gem at cigital.com Wed Sep 17 16:31:55 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 17 Sep 2008 16:31:55 -0400 Subject: [SC-L] SD West CFP Message-ID: hi sc-l, Some number of years ago I started giving talks at SD West in order to up the level of exposure that software security gets at actual development conferences. After a few years of that, I helped to rejigger the entire security track to be about software security. These days the track is thriving and it is well attended. The time has come to solicit talks for SD West 2009. I hope that some of you will consider proposing a talk (hint, I am the guy who puts the track together and I like real software security types). Here's a link: https://www.cmpevents.com/SDw9/a.asp?option=N&V=3 The deadline for submissions is October 10, 2008. Boilerplate from the organizers... Dr. Dobb's SD West Conference & Expo offers a comprehensive mix of software development training delivered by the industry's most respected faculty. SD West is dedicated to highlighting the newest technologies as well as presenting a core curriculum of development fundamentals. Conference details: March 9-13, 2009 Santa Clara Convention Center Santa Clara, California Conference sessions must focus on independent education. Sessions containing any product or sales pitch will not be accepted. If you have any questions regarding the call for papers, please contact Amber Ankerholz: aankerholz at think-services.com.
gem From gem at cigital.com Wed Sep 17 14:01:05 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 17 Sep 2008 14:01:05 -0400 Subject: [SC-L] News flurry: informIT, Java Rules, and Microsoft's SDL Pro network Message-ID: hi sc-l, It's a busy week for announcements of some things that have been brewing at Cigital for a while. The first and most relevant to sc-l is a set of Fortify rules that we released today. We've been building and using custom rules for many of the code scanning tools for a while now, and we're psyched to share a bunch of the non-proprietary ones with the community via open source. You can get the Cigital Java Security Rulepack 1.0 here: http://www.cigital.com/securitypack/ Briefly, the rules enhance Fortify's coverage of Java and include specialized rules about J2EE, Struts, Java Crypto, and some other things. You can actually look at the rules (and tweak them if you want). We've found that custom rules significantly enhance uptake of static analysis tools in large dev shops, especially when rules are customized for the shop itself. My latest informIT column is about getting past the bug parade and focusing some attention on flaws. Custom rules help by moving up the bug hierarchy towards flaws (but can't replace practices like threat modeling and Architectural Risk Analysis). You can read all about that here: http://www.informit.com/articles/article.aspx?p=1248057 Finally, Microsoft announced their new SDL Pro Network of nine companies prepared to roll out the SDL more widely. As the largest provider of software security services on this tiny planet, we're happy to be involved in that. For more on that, see Justice League: http://www.cigital.com/justiceleague/2008/09/16/strengthening-software-security-through-collaboration/ As always, we're interested in your feedback. Like the rules? Think hawking the SDL is good? Care about flaws as much as the bugs everyone is always going on about?? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From roman.hustad at yahoo.com Wed Sep 17 13:12:43 2008 From: roman.hustad at yahoo.com (Roman H.) Date: Wed, 17 Sep 2008 10:12:43 -0700 (PDT) Subject: [SC-L] Free CBT: PCI DSS for Developers Message-ID: <980204.74423.qm@web32408.mail.mud.yahoo.com> Hi SC-L, We put out a little freebie here that you might find useful in your dev shop if you are subject to PCI. Feedback is welcome: Foundstone Professional Services, a Division of McAfee, has recently released a free 2-hour computer based training entitled "PCI DSS v1.1 Compliance for Developers." This hype-free CBT focuses on the PCI DSS requirements and sub-requirements that are most relevant to software developers and offers developer-to-developer technical advice to help achieve compliance. Software security best practices are also stressed throughout the presentation. This is not an advertisement for McAfee products or Foundstone services, just solid information that will help your development teams create more secure software. You can obtain the CBT at this link: https://www.foundstone.com/us/resources/downloads/pci_compliance_developers.zip The 38MB download requires Flash and is SCORM-compliant so you can easily integrate it into your existing e-Learning system. If you want a higher-quality version please let me know off-list. Disclosure: I work for Foundstone. Regards, Roman Hustad From gem at cigital.com Wed Sep 24 15:13:30 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 24 Sep 2008 15:13:30 -0400 Subject: [SC-L] Silver Bullet transcript Cheswick Message-ID: hi sc-l, A couple of episodes ago, Silver Bullet interviewed Bill Cheswick: http://www.cigital.com/silverbullet/show-028/ A transcript of our conversation was just printed in IEEE Security & Privacy magazine. You can find a pdf version of the transcript here: http://www.cigital.com/silverbullet/shows/silverbullet-028-bcheswick.pdf In other Silver Bullet news, I just recorded an episode with Ken (our fearless moderator) which we're hoping to release soon! As always, thanks for listening. gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Thu Sep 25 16:12:43 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 25 Sep 2008 16:12:43 -0400 Subject: [SC-L] informIT feed Message-ID: hi sc-l, As many of you know, I have been writing a security column since October 2004. I started with Network Magazine, and stayed with CMP through the launch of darkreading.com. In April, I moved the column to informIT. All of the columns can be found here: http://www.cigital.com/~gem/writings/ Many of my columns end up being about issues in software security. In particular, the articles I pasted below (all free) may be of interest to sc-l subscribers. Note that some of them are appropriate for business leadership. To make things easy going forward, I just set up an RSS feed set up for my writings. You can subscribe to that here: http://www.cigital.com/papers/rss/mcgraw/ gem Is Application Security Training Worth the Money? [2/06] http://www.cigital.com/papers/download/0602sec.training.pdf Want Turns to Need (software security market size 2006) [4/07] http://www.darkreading.com/document.asp?doc_id=122253 JSON, Ajax & Web 2.0 [6/07] http://www.darkreading.com/document.asp?doc_id=125931 Software Security Strategies (4 ways to start an enterprise program) [1/08] http://www.darkreading.com/document.asp?doc_id=142829 Paying for Secure Software (using total cost of ownership for software projects) [4/08] http://www.informit.com/articles/article.aspx?p=1189519 Application Assessment as a Factory [7/08] http://www.informit.com/articles/article.aspx?p=1231818 Software Security Demand Rising (software security market size 2007) [8/08] http://www.informit.com/articles/article.aspx?p=1237978 Getting Past the Bug Parade (the importance of addressing architecture) [9/08] http://www.informit.com/articles/article.aspx?p=1248057 From gem at cigital.com Fri Sep 26 18:24:44 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 26 Sep 2008 18:24:44 -0400 Subject: [SC-L] Silver Bullet: Ken van Wyk Message-ID: <41945506397C0C4886A8C5BFF089B5CA354B2A3A47@va-mailhub.cigital.com> Hi sc-l, I'm very pleased to announce that our fearless moderator Ken is the victim of silver bullet episode 30. http://www.cigital.com/silverbullet/show-030/ We spent much of the conversation discussing software security. And there's a shout out to sc-l. gem From an0n.s3c at gmail.com Sat Sep 27 15:57:40 2008 From: an0n.s3c at gmail.com (anon sec) Date: Sat, 27 Sep 2008 15:57:40 -0400 Subject: [SC-L] Secure Coding Standards Message-ID: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> I am looking for a comprehensive set of secure coding standards to implement into my dev organization. These standards should cover Java, Web, and C/C++ as well as guidelines for using features like encryption, authentication, SSO, SSL, etc. I am open to both publicly available standards as well as commercially available standards. So far, I found 1. www.securecoding.cert.org - thanks to Robert C. Seacord, http://krvw.com/pipermail/sc-l/2008/001401.html 2. http://java.sun.com/security/seccodeguide.html 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards 4. DHS Build Security In (kind of) - https://buildsecurityin.us-cert.gov/daisy/bsi/home.html 5. SANS Software Security Institute - http://www.sans-ssi.org/ 6. CERT Top 10 Secure Coding Practices - https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ I would greatly appreciate any pointers to other links or to companies who have developed and sell these standards. Thanks in advance. An0n S3c. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080927/32e870cd/attachment.html From urgunb at hotmail.com Sun Sep 28 10:23:26 2008 From: urgunb at hotmail.com (Bedirhan Urgun) Date: Sun, 28 Sep 2008 10:23:26 -0400 Subject: [SC-L] Secure Coding Standards In-Reply-To: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> Message-ID: The ones I know of from the OWASP (may not be called "standard", not sure); http://www.owasp.org/index.php/Category:OWASP_Guide_Project (a little bit old, new version pending)http://www.owasp.org/index.php/OWASP_Backend_Security_Project (an owasp SoC '08 project, not finished yet but seems rather comprehensive) http://www.owasp.org/index.php/Category:Countermeasure (sporadic) cheers,Bedirhan Urgunhttp://www.webguvenligi.orghttp://www.owasp.org/index.php/Turkey Date: Sat, 27 Sep 2008 15:57:40 -0400From: an0n.s3c at gmail.comTo: sc-l at securecoding.orgSubject: [SC-L] Secure Coding Standards I am looking for a comprehensive set of secure coding standards to implement into my dev organization. These standards should cover Java, Web, and C/C++ as well as guidelines for using features like encryption, authentication, SSO, SSL, etc. I am open to both publicly available standards as well as commercially available standards. So far, I found www.securecoding.cert.org - thanks to Robert C. Seacord, http://krvw.com/pipermail/sc-l/2008/001401.html http://java.sun.com/security/seccodeguide.html http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards DHS Build Security In (kind of) - https://buildsecurityin.us-cert.gov/daisy/bsi/home.html SANS Software Security Institute - http://www.sans-ssi.org/ CERT Top 10 Secure Coding Practices - https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ I would greatly appreciate any pointers to other links or to companies who have developed and sell these standards. Thanks in advance. An0n S3c. _________________________________________________________________ Get more out of the Web. Learn 10 hidden secrets of Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080928/b2034e05/attachment.html From an0n.s3c at gmail.com Sun Sep 28 11:34:24 2008 From: an0n.s3c at gmail.com (anon sec) Date: Sun, 28 Sep 2008 11:34:24 -0400 Subject: [SC-L] Secure Coding Standards In-Reply-To: References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> Message-ID: <9ca73af10809280834l56275b45lcf9c0511e882ff6c@mail.gmail.com> Thanks. The OWASP Developer Guide Version 3 looks promising. Thanks again An0n S3c http://an0ns3c.blogspot.com On Sun, Sep 28, 2008 at 10:23 AM, Bedirhan Urgun wrote: > > The ones I know of from the OWASP (may not be called "standard", not sure); > > http://www.owasp.org/index.php/Category:OWASP_Guide_Project (a little bit > old, new version pending) > http://www.owasp.org/index.php/OWASP_Backend_Security_Project (an owasp > SoC '08 project, not finished yet but seems rather comprehensive) > http://www.owasp.org/index.php/Category:Countermeasure (sporadic) > > cheers, > Bedirhan Urgun > http://www.webguvenligi.org > http://www.owasp.org/index.php/Turkey > > > ------------------------------ > > Date: Sat, 27 Sep 2008 15:57:40 -0400 > From: an0n.s3c at gmail.com > To: sc-l at securecoding.org > Subject: [SC-L] Secure Coding Standards > > > > I am looking for a comprehensive set of secure coding standards to > implement into my dev organization. These standards should cover Java, Web, > and C/C++ as well as guidelines for using features like encryption, > authentication, SSO, SSL, etc. I am open to both publicly available > standards as well as commercially available standards. So far, I found > > 1. www.securecoding.cert.org - thanks to Robert C. Seacord, > http://krvw.com/pipermail/sc-l/2008/001401.html > 2. http://java.sun.com/security/seccodeguide.html > 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > 4. DHS Build Security In (kind of) - > https://buildsecurityin.us-cert.gov/daisy/bsi/home.html > 5. SANS Software Security Institute - http://www.sans-ssi.org/ > 6. CERT Top 10 Secure Coding Practices - > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ > > I would greatly appreciate any pointers to other links or to companies who > have developed and sell these standards. > > Thanks in advance. > > An0n S3c. > > > ------------------------------ > Get more out of the Web. Learn 10 hidden secrets of Windows Live. Learn > Now > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080928/3091898a/attachment.html From jim at manico.net Sun Sep 28 13:22:00 2008 From: jim at manico.net (Jim Manico) Date: Sun, 28 Sep 2008 07:22:00 -1000 Subject: [SC-L] Secure Coding Standards In-Reply-To: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> Message-ID: <48DFBD38.80106@manico.net> My thoughts... You standards really need more context - the standards for Java thick client vs Java server/web code would be rather different, for example. Make sure your guide gives recomendations specific to the context of the application type. On that note, other thoughts.... * Robert Seacord's guide is one of the best guides to secure coding in the C++ world but does not address web based or non C++ programming. a) I would also read Ken's book on this topic - great stuff. b) Microsoft books on their trustworthy computing initiative for the .NET world are very well written. * The SANS's courses and certs are really network/infrastructure centric and are not that helpful for the software engineer * The Sun link is way to general - nothing specific to really help the programmer write secure code. * 4-7 are way to general. In the web world, OWASP is by far the best. See: http://www.owasp.org/index.php/Category:OWASP_Guide_Project - Jim > I am looking for a comprehensive set of secure coding standards to > implement into my dev organization. These standards should cover Java, > Web, and C/C++ as well as guidelines for using features like > encryption, authentication, SSO, SSL, etc. I am open to both publicly > available standards as well as commercially available standards. So > far, I found > > 1. www.securecoding.cert.org - > thanks to Robert C. Seacord, > http://krvw.com/pipermail/sc-l/2008/001401.html > 2. http://java.sun.com/security/seccodeguide.html > 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > 4. DHS Build Security In (kind of) - > https://buildsecurityin.us-cert.gov/daisy/bsi/home.html > 5. SANS Software Security Institute - http://www.sans-ssi.org/ > 6. CERT Top 10 Secure Coding Practices - > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ > > I would greatly appreciate any pointers to other links or to > companies who have developed and sell these standards. > > Thanks in advance. > > An0n S3c. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com --------------------------------------------------------------- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080928/7b429ab2/attachment.html From jim at manico.net Sun Sep 28 13:45:39 2008 From: jim at manico.net (Jim Manico) Date: Sun, 28 Sep 2008 07:45:39 -1000 Subject: [SC-L] Secure Coding Standards In-Reply-To: <48DFBD38.80106@manico.net> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> <48DFBD38.80106@manico.net> Message-ID: <48DFC2C3.4000104@manico.net> Andrew van der Stock is also approaching this issue from a high level at http://www.greebo.net/2008/09/24/coding-standard/ His list looks rather complete. - Jim > My thoughts... > > You standards really need more context - the standards for Java thick > client vs Java server/web code would be rather different, for example. > Make sure your guide gives recomendations specific to the context of > the application type. > > On that note, other thoughts.... > > * Robert Seacord's guide is one of the best guides to secure coding in > the C++ world but does not address web based or non C++ programming. > a) I would also read Ken's book on this topic - great stuff. > b) Microsoft books on their trustworthy computing initiative for > the .NET world are very well written. > * The SANS's courses and certs are really network/infrastructure > centric and are not that helpful for the software engineer > * The Sun link is way to general - nothing specific to really help the > programmer write secure code. > * 4-7 are way to general. > > In the web world, OWASP is by far the best. See: > http://www.owasp.org/index.php/Category:OWASP_Guide_Project > > - Jim >> I am looking for a comprehensive set of secure coding standards to >> implement into my dev organization. These standards should cover >> Java, Web, and C/C++ as well as guidelines for using features like >> encryption, authentication, SSO, SSL, etc. I am open to both publicly >> available standards as well as commercially available standards. So >> far, I found >> >> 1. www.securecoding.cert.org - >> thanks to Robert C. Seacord, >> http://krvw.com/pipermail/sc-l/2008/001401.html >> 2. http://java.sun.com/security/seccodeguide.html >> 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards >> 4. DHS Build Security In (kind of) - >> https://buildsecurityin.us-cert.gov/daisy/bsi/home.html >> 5. SANS Software Security Institute - http://www.sans-ssi.org/ >> 6. CERT Top 10 Secure Coding Practices - >> https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices >> 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ >> >> I would greatly appreciate any pointers to other links or to >> companies who have developed and sell these standards. >> >> Thanks in advance. >> >> An0n S3c. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> > > > -- > Jim Manico, Senior Application Security Engineer > jim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the source > http://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY. > http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com --------------------------------------------------------------- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080928/04efff39/attachment.html From James.McGovern at thehartford.com Mon Sep 29 10:09:44 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 29 Sep 2008 10:09:44 -0400 Subject: [SC-L] Silver Bullet In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA354B2A3A47@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA354B2A3A47@va-mailhub.cigital.com> Message-ID: <9C557D8C6864CA438EF362318A3DF6D5025EF385@AD1HFDEXC306.ad1.prod> Wouldn't it be interesting if upcoming Silver Bullets featured CIOs and Enterprise Architects of Fortune enterprises? The perspectives regarding secure coding are complimentary yet different... ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* From an0n.s3c at gmail.com Sun Sep 28 20:35:58 2008 From: an0n.s3c at gmail.com (anon sec) Date: Sun, 28 Sep 2008 20:35:58 -0400 Subject: [SC-L] Secure Coding Standards In-Reply-To: <48DFC2C3.4000104@manico.net> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> <48DFBD38.80106@manico.net> <48DFC2C3.4000104@manico.net> Message-ID: <9ca73af10809281735r6e7bd4e7jb471af50df14f76d@mail.gmail.com> Jim Thanks. I will add that to the list. An0n S3c On Sun, Sep 28, 2008 at 1:45 PM, Jim Manico wrote: > Andrew van der Stock is also approaching this issue from a high level at > > http://www.greebo.net/2008/09/24/coding-standard/ > > His list looks rather complete. > > - Jim > > > My thoughts... > > You standards really need more context - the standards for Java thick > client vs Java server/web code would be rather different, for example. Make > sure your guide gives recomendations specific to the context of the > application type. > > On that note, other thoughts.... > > * Robert Seacord's guide is one of the best guides to secure coding in the > C++ world but does not address web based or non C++ programming. > a) I would also read Ken's book on this topic - great stuff. > b) Microsoft books on their trustworthy computing initiative for the > .NET world are very well written. > * The SANS's courses and certs are really network/infrastructure centric > and are not that helpful for the software engineer > * The Sun link is way to general - nothing specific to really help the > programmer write secure code. > * 4-7 are way to general. > > In the web world, OWASP is by far the best. See: > http://www.owasp.org/index.php/Category:OWASP_Guide_Project > > - Jim > > I am looking for a comprehensive set of secure coding standards to > implement into my dev organization. These standards should cover Java, Web, > and C/C++ as well as guidelines for using features like encryption, > authentication, SSO, SSL, etc. I am open to both publicly available > standards as well as commercially available standards. So far, I found > > 1. www.securecoding.cert.org - thanks to Robert C. Seacord, > http://krvw.com/pipermail/sc-l/2008/001401.html > 2. http://java.sun.com/security/seccodeguide.html > 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > 4. DHS Build Security In (kind of) - > https://buildsecurityin.us-cert.gov/daisy/bsi/home.html > 5. SANS Software Security Institute - http://www.sans-ssi.org/ > 6. CERT Top 10 Secure Coding Practices - > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ > > I would greatly appreciate any pointers to other links or to companies who > have developed and sell these standards. > > Thanks in advance. > > An0n S3c. > > > > ------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > > > -- > Jim Manico, Senior Application Security Engineerjim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the sourcehttp://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY.http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > > > > > -- > Jim Manico, Senior Application Security Engineerjim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the sourcehttp://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY.http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080928/eeb25abf/attachment.html From colin.cassidy at ge.com Mon Sep 29 04:42:59 2008 From: colin.cassidy at ge.com (Cassidy, Colin (GE Infra, Energy)) Date: Mon, 29 Sep 2008 10:42:59 +0200 Subject: [SC-L] Secure Coding Standards References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> Message-ID: <02AD898DD517E04DAB130CBE5825841217DFF87D@BFTMLVEM01.e2k.ad.ge.com> Hi, Something you may want to consider is how you plan on rolling this out within your organisation, where I work we have a strong culture of using and following coding standards and guidelines, so rolling out secure coding guidelines was not that difficult. That said we started small with a few key points to consider - buffer overflows - input validation - integer overflow - variable initialisation - memory management - race conditions - error handling / logging - functions to avoid Then we ran an introductory training course to quickly run through these points. The focus on the training was not to tout secure coding as something new, but that secure coding was better quality code, and that everyone's job is to write the best quality code that they can. It really helps if any "bad" examples you use are taken from your existing code base :) Plan on updating your guidelines, we are now looking at updating our guidelines and following up with new training. Our guidelines are heavily C focussed, but we are moving more to C# which changes things quite dramatically, and we are looking to roll out these guidelines to other development teams so we also need to look at their practices and f adjust the guidelines accordingly. Also, depending on your organisations code review practices, look at providing guidance in what to look for if you are performing a secure code review. Hope this helps, CJC _____ From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of anon sec Sent: 27 September 2008 20:58 To: sc-l at securecoding.org Subject: [SC-L] Secure Coding Standards I am looking for a comprehensive set of secure coding standards to implement into my dev organization. These standards should cover Java, Web, and C/C++ as well as guidelines for using features like encryption, authentication, SSO, SSL, etc. I am open to both publicly available standards as well as commercially available standards. So far, I found 1. www.securecoding.cert.org - thanks to Robert C. Seacord, http://krvw.com/pipermail/sc-l/2008/001401.html 2. http://java.sun.com/security/seccodeguide.html 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards 4. DHS Build Security In (kind of) - https://buildsecurityin.us-cert.gov/daisy/bsi/home.html 5. SANS Software Security Institute - http://www.sans-ssi.org/ 6. CERT Top 10 Secure Coding Practices - https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secu re+Coding+Practices 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ I would greatly appreciate any pointers to other links or to companies who have developed and sell these standards. Thanks in advance. An0n S3c. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20080929/d39038ab/attachment.html From rcs at cert.org Mon Sep 29 10:14:43 2008 From: rcs at cert.org (Robert C. Seacord) Date: Mon, 29 Sep 2008 10:14:43 -0400 Subject: [SC-L] Secure Coding Standards In-Reply-To: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> Message-ID: <48E0E2D3.6090100@cert.org> An0n S3c, i see you have already found our site, but i should probably take this opportunity to provide a couple of updates. first of all, CERT has released the Java Secure Coding Standard in addition to existing secure coding standards for the C and C++ programming languages. CERT invites the Java community to participate in this effort by reviewing content in the Java space at https://www.securecoding.cert.org/confluence/display/java/CERT+Java+Secure+Coding+Standard and providing comments. second, The CERT C Secure Coding Standard is being published by Addison-Wesley and has already gone to the printer (it should be available in October). this book is the first official release of the standard and has the advantage over the wiki version that we are not changing it all the time, so you can actually implement it. 8^) anyway, you can read more (and preorder!) the book version here: http://www.amazon.com/Secure-Coding-Standard-Software-Engineering/dp/0321563212 another idea is to look a little further from strictly security related coding standards. another good C++ standard is JSF++ http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc. you may also want to look at the various MISRA standards. thanks, rCs > I am looking for a comprehensive set of secure coding standards to > implement into my dev organization. These standards should cover Java, > Web, and C/C++ as well as guidelines for using features like > encryption, authentication, SSO, SSL, etc. I am open to both publicly > available standards as well as commercially available standards. So > far, I found > > 1. www.securecoding.cert.org - > thanks to Robert C. Seacord, > http://krvw.com/pipermail/sc-l/2008/001401.html > 2. http://java.sun.com/security/seccodeguide.html > 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > 4. DHS Build Security In (kind of) - > https://buildsecurityin.us-cert.gov/daisy/bsi/home.html > 5. SANS Software Security Institute - http://www.sans-ssi.org/ > 6. CERT Top 10 Secure Coding Practices - > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ > > I would greatly appreciate any pointers to other links or to > companies who have developed and sell these standards. > > Thanks in advance. > > An0n S3c. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 From rklists at gmail.com Mon Sep 29 12:14:49 2008 From: rklists at gmail.com (Rohit Lists) Date: Mon, 29 Sep 2008 12:14:49 -0400 Subject: [SC-L] Secure Coding Standards In-Reply-To: <48DFBD38.80106@manico.net> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> <48DFBD38.80106@manico.net> Message-ID: Most of the SANS classes are network/infrastructure related, but some of them are made specifically for secure coding in a particular language. I'm an instructor and courseware developer for Security 541, the secure coding in Java / JEE class (http://www.sans.org/ns2008/description.php?tid=1937). To Jim's point, the guidelines will vary by the application type although there are a set of topics that apply to most developers (e.g. numeric overflow, synchronization, error handling, etc.). Whatever you do end up using make sure that your specific type of application is included. Cheers, -- Rohit Sethi Security Compass http://www.securitycompass.com On Sun, Sep 28, 2008 at 1:22 PM, Jim Manico wrote: > My thoughts... > > You standards really need more context - the standards for Java thick client > vs Java server/web code would be rather different, for example. Make sure > your guide gives recomendations specific to the context of the application > type. > > On that note, other thoughts.... > > * Robert Seacord's guide is one of the best guides to secure coding in the > C++ world but does not address web based or non C++ programming. > a) I would also read Ken's book on this topic - great stuff. > b) Microsoft books on their trustworthy computing initiative for the > .NET world are very well written. > * The SANS's courses and certs are really network/infrastructure centric and > are not that helpful for the software engineer > * The Sun link is way to general - nothing specific to really help the > programmer write secure code. > * 4-7 are way to general. > > In the web world, OWASP is by far the best. See: > http://www.owasp.org/index.php/Category:OWASP_Guide_Project > > - Jim > > I am looking for a comprehensive set of secure coding standards to implement > into my dev organization. These standards should cover Java, Web, and C/C++ > as well as guidelines for using features like encryption, authentication, > SSO, SSL, etc. I am open to both publicly available standards as well as > commercially available standards. So far, I found > > www.securecoding.cert.org - thanks to Robert C. Seacord, > http://krvw.com/pipermail/sc-l/2008/001401.html > http://java.sun.com/security/seccodeguide.html > http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > DHS Build Security In (kind of) - > https://buildsecurityin.us-cert.gov/daisy/bsi/home.html > SANS Software Security Institute - http://www.sans-ssi.org/ > CERT Top 10 Secure Coding Practices - > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ > > I would greatly appreciate any pointers to other links or to companies who > have developed and sell these standards. > > Thanks in advance. > > An0n S3c. > > > > ________________________________ > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > -- > Jim Manico, Senior Application Security Engineer > jim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the source > http://www.aspectsecurity.com > > --------------------------------------------------------------- > Management, Developers, Security Professionals ... > ... can only result in one thing. BETTER SECURITY. > http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference > Sept 22nd-25th 2008 > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From gem at cigital.com Mon Sep 29 12:20:31 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 29 Sep 2008 12:20:31 -0400 Subject: [SC-L] Silver Bullet In-Reply-To: <9C557D8C6864CA438EF362318A3DF6D5025EF385@AD1HFDEXC306.ad1.prod> Message-ID: Good idea James. If you take a look at the list of victims, you'll see a mix of academics, gurus, and CSOs. My next victim (Matt Bishop) is already slated. After that I will see what I can do to get a CIO for November. BTW, if anyone has suggestions along those lines, I'm all ears. I would particularly like to get more women on the podcast. gem On 9/29/08 10:09 AM, "McGovern, James F (HTSC, IT)" wrote: Wouldn't it be interesting if upcoming Silver Bullets featured CIOs and Enterprise Architects of Fortune enterprises? The perspectives regarding secure coding are complimentary yet different... ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From ramartin at mitre.org Mon Sep 29 13:28:21 2008 From: ramartin at mitre.org (Robert Martin) Date: Mon, 29 Sep 2008 13:28:21 -0400 Subject: [SC-L] Secure Coding Standards In-Reply-To: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> References: <9ca73af10809271257j1b54097cydc20732783560408@mail.gmail.com> Message-ID: <48E11035.6010800@mitre.org> As a compliment to coding standards you may want to consider using the Common Weakness Enumeration (CWE) as a target list of coding, design and implementation issues you are trying to minimize through use of those coding standards. Using the CWEs can also help you to drive and correlate your test program into a cross checking of the issues you care about to assure yourself that they were actually addressed by your development standards. Many of the testing approaches, whether they be from manual reviews, penetration testing/black box testing, or from white box testing/code assessments are easily correlated with CWEs either because the vendors are already tagging their finding with CWEs or because your testers can easily match their testing to the CWEs that their testing uncover. Several large commercial development vendors are using CWE as a framework for targeting and tracking their application security reviews both as a way of articulating their goals about which kinds of issues they want to address as well as a way to document and track their progress. Many of the coding standards efforts you listed, as well as the OWASP efforts, have already mapped (or are in the process of mapping) their coding standards/guidance to the CWEs that the individual rules address. Regards, Bob anon sec wrote: > I am looking for a comprehensive set of secure coding standards to implement > into my dev organization. These standards should cover Java, Web, and C/C++ > as well as guidelines for using features like encryption, authentication, > SSO, SSL, etc. I am open to both publicly available standards as well as > commercially available standards. So far, I found > > 1. www.securecoding.cert.org - thanks to Robert C. Seacord, > http://krvw.com/pipermail/sc-l/2008/001401.html > 2. http://java.sun.com/security/seccodeguide.html > 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > 4. DHS Build Security In (kind of) - > https://buildsecurityin.us-cert.gov/daisy/bsi/home.html > 5. SANS Software Security Institute - http://www.sans-ssi.org/ > 6. CERT Top 10 Secure Coding Practices - > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ > > I would greatly appreciate any pointers to other links or to companies who > have developed and sell these standards. > > Thanks in advance. > > An0n S3c. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ From gunnar at arctecgroup.net Mon Sep 29 14:52:40 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Mon, 29 Sep 2008 13:52:40 -0500 Subject: [SC-L] Silver Bullet In-Reply-To: References: Message-ID: <48E123F8.5040309@arctecgroup.net> I strongly agree with James' ask. Its nice to hear from gurus, but we need to hear about real world tradeoffs too. Sausage making aint pretty (ask Hank and Ben), but its the real world and I for one am always fascinated with what choices organizations make and why. I am also very excited to hear from Matt Bishop who is at or near the top of the guru heap for my money. Keep up the good work -gp Gary McGraw wrote: > Good idea James. If you take a look at the list of victims, you'll see a mix of academics, gurus, and CSOs. My next victim (Matt Bishop) is already slated. After that I will see what I can do to get a CIO for November. > > BTW, if anyone has suggestions along those lines, I'm all ears. I would particularly like to get more women on the podcast. > > gem > > > On 9/29/08 10:09 AM, "McGovern, James F (HTSC, IT)" wrote: > > Wouldn't it be interesting if upcoming Silver Bullets featured CIOs and > Enterprise Architects of Fortune enterprises? The perspectives regarding > secure coding are complimentary yet different... > > > ************************************************************************* > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ************************************************************************* > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From James.McGovern at thehartford.com Mon Sep 29 15:08:55 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 29 Sep 2008 15:08:55 -0400 Subject: [SC-L] Silver Bullet In-Reply-To: References: <9C557D8C6864CA438EF362318A3DF6D5025EF385@AD1HFDEXC306.ad1.prod> Message-ID: <9C557D8C6864CA438EF362318A3DF6D5025EF4F1@AD1HFDEXC306.ad1.prod> Women to include are: Diana Kelley of SecurityCurve Chenxi Wang of Forrester Window Synder of Mozilla Mary Ann Davidson of Oracle -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Monday, September 29, 2008 12:21 PM To: McGovern, James F (HTSC, IT); SecureMailing List Subject: Re: [SC-L] Silver Bullet Good idea James. If you take a look at the list of victims, you'll see a mix of academics, gurus, and CSOs. My next victim (Matt Bishop) is already slated. After that I will see what I can do to get a CIO for November. BTW, if anyone has suggestions along those lines, I'm all ears. I would particularly like to get more women on the podcast. gem ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* From gem at cigital.com Mon Sep 29 15:14:00 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 29 Sep 2008 15:14:00 -0400 Subject: [SC-L] Silver Bullet In-Reply-To: <48E123F8.5040309@arctecgroup.net> Message-ID: Thanks Gunnar. I'm scheming schemes that you guys may like...hold that thought! gem On 9/29/08 2:52 PM, "Gunnar Peterson" wrote: I strongly agree with James' ask. Its nice to hear from gurus, but we need to hear about real world tradeoffs too. Sausage making aint pretty (ask Hank and Ben), but its the real world and I for one am always fascinated with what choices organizations make and why. I am also very excited to hear from Matt Bishop who is at or near the top of the guru heap for my money. Keep up the good work -gp Gary McGraw wrote: > Good idea James. If you take a look at the list of victims, you'll see a mix of academics, gurus, and CSOs. My next victim (Matt Bishop) is already slated. After that I will see what I can do to get a CIO for November. > > BTW, if anyone has suggestions along those lines, I'm all ears. I would particularly like to get more women on the podcast. > > gem > > > On 9/29/08 10:09 AM, "McGovern, James F (HTSC, IT)" wrote: > > Wouldn't it be interesting if upcoming Silver Bullets featured CIOs and > Enterprise Architects of Fortune enterprises? The perspectives regarding > secure coding are complimentary yet different... > > > ************************************************************************* > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ************************************************************************* > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From gem at cigital.com Mon Sep 29 18:17:36 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 29 Sep 2008 18:17:36 -0400 Subject: [SC-L] Silver Bullet Message-ID: <41945506397C0C4886A8C5BFF089B5CA354B2A3AB3@va-mailhub.cigital.com> Mary ann has already been a victim. Do analysts count as practitioners?? gem ----- Original Message ----- From: sc-l-bounces at securecoding.org To: SecureMailing List Sent: Mon Sep 29 15:08:55 2008 Subject: Re: [SC-L] Silver Bullet Women to include are: Diana Kelley of SecurityCurve Chenxi Wang of Forrester Window Synder of Mozilla Mary Ann Davidson of Oracle -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Monday, September 29, 2008 12:21 PM To: McGovern, James F (HTSC, IT); SecureMailing List Subject: Re: [SC-L] Silver Bullet Good idea James. If you take a look at the list of victims, you'll see a mix of academics, gurus, and CSOs. My next victim (Matt Bishop) is already slated. After that I will see what I can do to get a CIO for November. BTW, if anyone has suggestions along those lines, I'm all ears. I would particularly like to get more women on the podcast. gem ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From ken at krvw.com Wed Oct 8 05:47:51 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 8 Oct 2008 05:47:51 -0400 Subject: [SC-L] AdaCore - Home > GNAT Pro > The Tokeneer Project Message-ID: http://www.adacore.com/home/gnatpro/tokeneer/ Excerpt: "Project Summary In order to demonstrate that developing highly secure systems to the level of rigor required by the higher assurance levels of the Common Criteria is possible, the NSA (National Security Agency) asked Praxis High Integrity Systems to undertake a research project to develop part of an existing secure system (the Tokeneer System) in accordance with Praxis? Correctness by Construction development process. This development and research work has now been made available by the NSA to the software development and security communities in an effort to prove that it is possible to develop secure systems rigorously in a cost effective manner." Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081008/c7d7582c/attachment.bin From SMigues at cigital.com Wed Oct 8 20:40:33 2008 From: SMigues at cigital.com (Sammy Migues) Date: Wed, 8 Oct 2008 20:40:33 -0400 Subject: [SC-L] Human Elements of Security Survey Message-ID: <41945506397C0C4886A8C5BFF089B5CA356ED95AB0@va-mailhub.cigital.com> Hello everyone, Cigital and Safelight Security Advisors are conducting a survey to understand the practices organizations are using to deal with some of the human elements surrounding software security risk. We'd sincerely appreciate participation by this audience and invite you to take that survey by October 28th at: https://www.surveymonkey.com/s.aspx?sm=ksU2a8N56_2fJNir5961VPUA_3d_3d. JavaScript is required on SurveyMonkey. All respondents who provide sufficient contact information will receive a complimentary copy of the anonymized, summary best practices report based on the survey findings and a chance to win one of 3 Apple iPod touch devices. Thank you for your participation. Sincerely, Michael Maziarz Safelight Security Advisors mmaziarz at securityadvisors.com Sammy Migues Cigital smigues at cigital.com From ljknews at mac.com Thu Oct 9 12:04:00 2008 From: ljknews at mac.com (ljknews) Date: Thu, 09 Oct 2008 12:04:00 -0400 Subject: [SC-L] Human Elements of Security Survey In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA356ED95AB0@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA356ED95AB0@va-mailhub.cigital.com> Message-ID: At 8:40 PM -0400 10/8/08, Sammy Migues wrote: > JavaScript is required on SurveyMonkey. Thank you for the warning. It is amazing the number of people who presume that security people are willing to go to a website enabling cookies or JavaScript or worse. Of course it is also amazing the number of web sites that silently fail in some bizarre fashion if reached by a secured browser. -- Larry Kilgallen From seba at deleersnyder.eu Tue Oct 14 16:05:47 2008 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Tue, 14 Oct 2008 22:05:47 +0200 Subject: [SC-L] Fwd: Join us in Portugal for the biggest concentration of OWASP training so far! In-Reply-To: References: Message-ID: Hi, OWASP is bringing together the world's best application security experts to teach you on OWASP tools, methodologies and how to build secure web software. The OWASP creators of tools will bring you up to speed on how to disect, test, improve and construct secure software. Join us in Portugal for the biggest concentrationof OWASP training so far. Scheduled training sessions: - 1 WebAppSec for Managers and Executives - The Road Less Travelled - 2 The Art and Science of Threat Modeling Web Applications - 3 Web server/services hardening using SELinux - 4 Secure Programming with Java - 5 OWASP Top 10 - What Developers Should Know on Web Application Security - 6 Classic ASP Security using OWASP tools - 7 Web Application Assessments - 8 Hacking Owasp Orizon Project v1.0 - 9 Securing WebGoat with ModSecurity - 10 How to Win AppSec Hacking Contests and Deploy Better Web Applications - 11 Uncovering WebScarab's Secret Treasures - 12 Advanced Web Application Security Testing - 13 Building Secure Web 2.0 Applications - 14 Building Secure Web Services - 15 Building Secure Web Applications with OWASP's Enterprise Security API (ESAPI) - 16 Ajax Security - 17 Flash Player Security - 18 Auditing Flash Applications - 19 Testing Guide Trainin g Timing: November 3+4 Details and registration at http://www.owasp.org/index.php/OWASP_EU_Summit_2008 regards Seba -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081014/df69305d/attachment.html From ken at krvw.com Wed Oct 15 08:31:36 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 15 Oct 2008 08:31:36 -0400 Subject: [SC-L] (fwd) informIT: A Software Security Framework Message-ID: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com> [Posted on behalf of Gary McGraw, who is without comms right now but wanted this to go out today. KRvW] hi sc-l, Brian Chess and I have been working hard on a software security framework that we are using in a scientific study of many of the top software security initiatives. Our plan of action is to interview the people running the top ten large-scale software security initiatives over the next few weeks and then build a maturity model with the resulting data. That's right, we're actually using real data from real software security programs. Brian and I co-authored my informIT column this month, which just so happens to be about the software security framework. Please check it out, we're interested to know what you think! http://www.informit.com/articles/article.aspx?p=1271382 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081015/e0bfbc03/attachment.bin From James.McGovern at thehartford.com Wed Oct 15 13:58:32 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Wed, 15 Oct 2008 13:58:32 -0400 Subject: [SC-L] (fwd) informIT: A Software Security Framework In-Reply-To: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com> References: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com> Message-ID: <9C557D8C6864CA438EF362318A3DF6D5027930B4@AD1HFDEXC306.ad1.prod> The framework that Pravir put together is pretty good. Brian and I did have a conversation awhile back regarding donating it to OWASP for continuation. I plan on making our firm one of the public case studies once they contribute. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Wednesday, October 15, 2008 8:32 AM To: Secure Coding Subject: [SC-L] (fwd) informIT: A Software Security Framework [Posted on behalf of Gary McGraw, who is without comms right now but wanted this to go out today. KRvW] hi sc-l, Brian Chess and I have been working hard on a software security framework that we are using in a scientific study of many of the top software security initiatives. Our plan of action is to interview the people running the top ten large-scale software security initiatives over the next few weeks and then build a maturity model with the resulting data. That's right, we're actually using real data from real software security programs. Brian and I co-authored my informIT column this month, which just so happens to be about the software security framework. Please check it out, we're interested to know what you think! http://www.informit.com/articles/article.aspx?p=1271382 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* From gem at cigital.com Wed Oct 15 18:39:29 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 15 Oct 2008 18:39:29 -0400 Subject: [SC-L] (fwd) informIT: A Software Security Framework Message-ID: <41945506397C0C4886A8C5BFF089B5CA356EDCBEA9@va-mailhub.cigital.com> Super. Glad to hear that. We made some adjustments to pub's draft, but he definitely got the ball rolling. See what you think of our adjustments. gem http;//www.cigital.com/~gem ----- Original Message ----- From: sc-l-bounces at securecoding.org To: SecureMailing List Sent: Wed Oct 15 13:58:32 2008 Subject: Re: [SC-L] (fwd) informIT: A Software Security Framework The framework that Pravir put together is pretty good. Brian and I did have a conversation awhile back regarding donating it to OWASP for continuation. I plan on making our firm one of the public case studies once they contribute. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Wednesday, October 15, 2008 8:32 AM To: Secure Coding Subject: [SC-L] (fwd) informIT: A Software Security Framework [Posted on behalf of Gary McGraw, who is without comms right now but wanted this to go out today. KRvW] hi sc-l, Brian Chess and I have been working hard on a software security framework that we are using in a scientific study of many of the top software security initiatives. Our plan of action is to interview the people running the top ten large-scale software security initiatives over the next few weeks and then build a maturity model with the resulting data. That's right, we're actually using real data from real software security programs. Brian and I co-authored my informIT column this month, which just so happens to be about the software security framework. Please check it out, we're interested to know what you think! http://www.informit.com/articles/article.aspx?p=1271382 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From ken at krvw.com Thu Oct 16 08:22:20 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 16 Oct 2008 08:22:20 -0400 Subject: [SC-L] (fwd) informIT: A Software Security Framework In-Reply-To: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com> References: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com> Message-ID: <6B666DEF-30D7-4FF0-A319-1108EBA4C2BF@krvw.com> Greetings SC-L, I thought I'd chime in on this, as it very closely relates to my current book project. On Oct 15, 2008, at 8:31 AM, Gary McGraw (via Kenneth Van Wyk) wrote: > Brian Chess and I have been working hard on a software security > framework that we are using in a scientific study of many of the top > software security initiatives. Great work, guys. In some areas, I think it's probably overly simplistic, as some of the practices span more than one domain. (Notably, penetration testing can and should be part of a security testing regimen as well as a deployment testing regimen, IMHO.) But it's a great starting point for going out and gathering real world data on what's being done in the field. More importantly, it's useful at defining what practices should be assessed for a maturity model. > Our plan of action is to interview the people running the top ten > large-scale software security initiatives over the next few weeks > and then build a maturity model with the resulting data. Our discipline stands to gain significantly from having a maturity model in place, if for no other reason than to help dev organizations set goals and objectives in their software security efforts. Pravir et al at OWASP have done a great job at getting one started over there. I also love the idea of using real world data as an initial set of measurements for each maturity level, especially for early version(s) of a maturity model. I think that goes a long way to helping development organizations realistically know what to aspire to--and how to get there--for each maturity level. In time, however, I'd sure like to see the maturity model advance beyond that and set the bars higher than "just" what's currently being done in practice, and define what *should* be done. That said, starting with a solid framework of practices to measure for each maturity level is the right way to do things. IMHO, it'll probably be a few years before these efforts bear significant fruit in terms of advancing what is being practiced in the field, but we've got to start somewhere. Kudos. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081016/e1f2767e/attachment.bin From rcs at cert.org Sun Oct 19 20:38:46 2008 From: rcs at cert.org (Robert Seacord) Date: Sun, 19 Oct 2008 20:38:46 -0400 Subject: [SC-L] The CERT C Secure Coding Standard In-Reply-To: <6B666DEF-30D7-4FF0-A319-1108EBA4C2BF@krvw.com> References: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com> <6B666DEF-30D7-4FF0-A319-1108EBA4C2BF@krvw.com> Message-ID: The CERT C Secure Coding Standard has been published by Addison-Wesley. More information is available at: http://www.informit.com/store/product.aspx?isbn=0321563212 Thanks to all the "lurkers" on SC-L who helped us develop and review the content. Thanks, rCs From dave.wichers at aspectsecurity.com Mon Oct 27 20:14:41 2008 From: dave.wichers at aspectsecurity.com (Dave Wichers) Date: Mon, 27 Oct 2008 21:14:41 -0400 Subject: [SC-L] FINAL NOTICE: OWASP Portugal EU Summit In-Reply-To: References: <1503BB2E-593D-43BC-933F-4117173CCB64@krvw.com><6B666DEF-30D7-4FF0-A319-1108EBA4C2BF@krvw.com> Message-ID: It's almost here....one of the most important events in OWASP history, the 2008 Summit! http://www.owasp.org/index.php/OWASP_EU_Summit_2008 OWASP Summit EU 2008 is a worldwide gathering of OWASP leaders and key industry players to present and discuss the latest OWASP tools and documentation projects. The summit will host multiple Working Sessions designed to improve collaboration, achieve specific objectives and decide roadmaps for OWASP projects, chapters and for the OWASP community itself. Containing both technical and business tracks, the Summit is the perfect place to learn what resources OWASP has available for use today. Following and expanding the tradition started at OWASP conferences, the Summit will also host the largest offering of training courses, covering multiple OWASP specific and Web Application Security Topics OWASP Summit Working Sessions http://www.owasp.org/index.php/OWASP_EU_Summit_2008 Portugal, 4rd - 5th Nov 2008 OWASP is bringing together its Leaders with the world's best application security experts to meet at the OWASP Summit in order to work on targeted Working Sessions. Everyone who attends is invited to join, share opinions, and make the difference. All outcomes produced during the working session will be presented during the Summit's conference and discussed at a special OWASP Board meeting where the board will vote on the proposed Initiatives, Statements or Decisions. OWASP Training Classes Portugal, 3rd-5th Nov 2008 http://www.owasp.org/index.php/OWASP_EU_Summit_2008_Training OWASP is providing an unprecedented 19 classes to choose from. Each instructor is a subject matter expert and industry leader. OWASP Summit Conference http://www.owasp.org/index.php/OWASP_EU_Summit_2008 Portugal, 6th - 7th Nov 2008 (Thu & Fri) OWASP Summit Conference is a two-day immersion into OWASP projects and initiatives. The world's finest security professionals will present their latest application security research. In addition, project leaders and reviewers will be presenting OWASP Summer of Code 08 results and new challenges brought up during 2-day Working Sessions. There are 4 technical tracks and one special Business Track (aimed at managers and decision-makers). The objective is to present the attendees with a global view of the enormous resources available today at OWASP. Business Track: Business-focused sessions covering application security, strategic OWASP projects and how to get involved. Technical Track 1: Secure Design & Defensive Strategies: tools and modules to use and improve application security Technical Track 2: OWASP Internals: projects and initiatives that make application security more visible Technical Track 3: Cutting Edge Tools: new and innovative tools designed to test , detect and prevent web application security issues Technical Track 4: Security Guidance and Knowledge: documentation, books and references to keep people informed about application security The Conference finishes with an open OWASP Board Meeting, where the audience is invited to participate and contribute on topics presented during the previous days.. Don't miss this opportunity to participate in our industry's most energetic and productive weeklong event. All information on travel, class schedule, accommodations, working groups, and conference tracks can be found at http://www.owasp.org/index.php/OWASP_EU_Summit_2008 I look forward to seeing everyone in Portugal! Please contact Kate Hartmann if you have any questions regarding registration. Kate.hartmann at owasp.org http://guest.cvent.com/i.aspx?4W,M3,35818773-e14b-4d8e-8db8-5e14a6285a3d Kate Hartmann OWASP Operations Director 9175 Guilford Road Suite 300 Columbia, MD 21046 301-575-0189 (office) 301-275-9403 (mobile) kate.hartmann at owasp.org From gem at cigital.com Mon Oct 27 13:58:21 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 27 Oct 2008 14:58:21 -0400 Subject: [SC-L] cat out of bag: article to be published in Computer in dec Message-ID: hi sc-l, Here is a pointer to an article that will appear in the December issue of Computer magazine. It's an introduction to code review with a static analysis tool for the "How things work" department. Should be useful for people just getting started thinking about code review automation. http://www.cigital.com/papers/download/dec08-static-software-gem.pdf Feel free to pass this around as you see fit. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From jleffler at us.ibm.com Thu Oct 30 12:09:00 2008 From: jleffler at us.ibm.com (Jonathan Leffler) Date: Thu, 30 Oct 2008 11:09:00 -0600 Subject: [SC-L] Cat out of the bag? In-Reply-To: References: Message-ID: Gary McGraw wrote: >Here is a pointer to an article... I'm getting 404 errors? I backed up the chain of directories in the URL and the link is broken on the page: http://www.cigital.com/papers/ http://www.cigital.com/papers/download/dec08-static-software-gem.pdf (I also get the digest - I apologize if this has been beaten to death on the non-digest list.) -- Jonathan Leffler (jleffler at us.ibm.com) STSM, Informix Database Engineering, IBM Information Management 4400 N First St, San Jose, CA 95134-1257 Tel: +1 408-956-2436 Tieline: 475-2436 "I don't suffer from insanity; I enjoy every minute of it!" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4441 bytes Desc: S/MIME Cryptographic Signature Url : http://krvw.com/pipermail/sc-l/attachments/20081030/ccf287e1/attachment.bin From gem at cigital.com Thu Oct 30 13:34:53 2008 From: gem at cigital.com (Gary McGraw) Date: Thu, 30 Oct 2008 14:34:53 -0400 Subject: [SC-L] Cat out of the bag? Message-ID: <41945506397C0C4886A8C5BFF089B5CA356EDCC168@va-mailhub.cigital.com> This has been fixed. We just moved our web server and launched a redesigned website. The paper url fell through the cracks. My apologies. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ----- Original Message ----- From: sc-l-bounces at securecoding.org To: sc-l at securecoding.org Sent: Thu Oct 30 13:09:00 2008 Subject: Re: [SC-L] Cat out of the bag? Gary McGraw wrote: >Here is a pointer to an article... I'm getting 404 errors? I backed up the chain of directories in the URL and the link is broken on the page: http://www.cigital.com/papers/ http://www.cigital.com/papers/download/dec08-static-software-gem.pdf (I also get the digest - I apologize if this has been beaten to death on the non-digest list.) -- Jonathan Leffler (jleffler at us.ibm.com) STSM, Informix Database Engineering, IBM Information Management 4400 N First St, San Jose, CA 95134-1257 Tel: +1 408-956-2436 Tieline: 475-2436 "I don't suffer from insanity; I enjoy every minute of it!" From ljknews at mac.com Thu Oct 30 13:27:08 2008 From: ljknews at mac.com (ljknews) Date: Thu, 30 Oct 2008 14:27:08 -0400 Subject: [SC-L] Cat out of the bag? In-Reply-To: References: Message-ID: At 11:09 AM -0600 10/30/08, Jonathan Leffler wrote: > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary=-------z22511_boundary_sign > > Gary McGraw wrote: >>Here is a pointer to an article... > > I'm getting 404 errors? I backed up the chain of directories in the URL > and the link is broken on the page: > > http://www.cigital.com/papers/ http://validator.w3.org shows that page has 25 HTML errors. -- Larry Kilgallen From gunnar at arctecgroup.net Thu Oct 30 14:39:54 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Thu, 30 Oct 2008 14:39:54 -0500 Subject: [SC-L] Cat out of the bag? In-Reply-To: References: Message-ID: <1DF7F763-42B9-45F4-8D41-B6A1E54ED3E2@arctecgroup.net> > > http://validator.w3.org shows that page has 25 HTML errors. > fwiw, mac.com has 28 errors and 1 warning -gunnar p.s. my domain has 42 otoh i wrote the whole "design" from scratch in vi From dinis at ddplus.net Tue Nov 4 22:30:11 2008 From: dinis at ddplus.net (Dinis Cruz) Date: Wed, 5 Nov 2008 03:30:11 +0000 Subject: [SC-L] OWASP EU Summit Portugal 08: join us via WebEx on today's presentations! In-Reply-To: <701fd6b60811041927v318b61cdj39921b6c987f13fe@mail.gmail.com> References: <60235a7b0811041917h2974adadm5549ecb36681820d@mail.gmail.com> <701fd6b60811041927v318b61cdj39921b6c987f13fe@mail.gmail.com> Message-ID: <701fd6b60811041930i30550f16x315c783e9bba05c@mail.gmail.com> *UPDATED SUMMIT INFORMATION: Day 2 Wednesday *( https://www.owasp.org/index.php/OWASP_EU_Summit_2008) The summit is current under way in Portugal and today's agenda (Wednesday) can be downloaded from here(the full agenda is here ) Today we will have the presentation of: - * 11x OWASP Summer of Code 2008 completed projects and Key OWASP projects: * - OWASP Positive Security (track 1) - OWASP Access Control Rules Tester Project (track 2) - OWASP Education (track 1) - OWASP Application Security Tool Benchmarking Environment and Site Generator Refresh Project (track 2) - OWASP Internationalization Guidelines (track 1) - OWASP AppSensor (track 2) - PASSWD: Metrics and Vulnerabilities (track 1) - OWASP Backend Security Project (track 2) - OWASP Open Review Project (track 1) - OWASP Teachable Static Analysis Workbench (track 2) - *8x Working Sessions: * - Education Project (track 1) - Web Application Framework Security - Testing Guide (track 2) - OWASP Censorship - Code Review Guide (track 2) - EU Funding for OWASP Projects - OWASP Certification (track 1) - Software Assurance Maturity Model Webex details: All Wednesday presentations will be made available via a live WebEx (which everybody is invited to attend) OWASP Summit - Wednesday - Track 1 Meeting Number: 686 766 683 Meeting Password: owasp1 *To join the online meeting* 1. Go to https://ouncelabs.webex.com/ouncelabs/j.php?ED=110133807&UID=0&PW=eec26b2d5a5a514a145d 2. Enter your name and email address. 3. Enter the meeting password: owasp1 4. Click "Join Now". *To join the teleconference only* Call-in toll-free number (US/Canada): 866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 OWASP Summit - Wednesday - Track 2 Meeting Number: 685 231 361 Meeting Password: owasp1 *To join the online meeting* 1. Go to https://ouncelabs.webex.com/ouncelabs/j.php?ED=110133817&UID=0&PW=c4900b1b0a001155 2. Enter your name and email address. 3. Enter the meeting password: owasp1 4. Click "Join Now". *To join the teleconference only* Call-in toll-free number (US/Canada): 866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 Thanks to OunceLabs for kindly providing the WebEx facilities. ----- If you have any problems connecting to the WebEx session, please contact Kate Hartman (kate.hartmann at owasp.org) See you there, Dinis Cruz & Paulo Coimbra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081105/fc7612c9/attachment.html From list-spam at secureconsulting.net Tue Nov 4 15:01:22 2008 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 04 Nov 2008 15:01:22 -0500 Subject: [SC-L] Wysopal says tipping point reached... Message-ID: <4910AA12.4060206@secureconsulting.net> An interesting read. Not much to really argue with, I don't think. http://www.veracode.com/blog/2008/11/we%e2%80%99ve-reached-the-application-security-tipping-point/ -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] "Anticipate the difficult by managing the easy." Lao Tzu From coley at linus.mitre.org Thu Nov 6 01:32:21 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 6 Nov 2008 01:32:21 -0500 (EST) Subject: [SC-L] Wysopal says tipping point reached... In-Reply-To: <4910AA12.4060206@secureconsulting.net> References: <4910AA12.4060206@secureconsulting.net> Message-ID: On Tue, 4 Nov 2008, Benjamin Tomhave wrote: > An interesting read. Not much to really argue with, I don't think. > http://www.veracode.com/blog/2008/11/we%e2%80%99ve-reached-the-application-security-tipping-point/ Agree. But, just to bolster (if it's relevant) I'll expand on my comment to that blog post: While we have not done a similar analysis in CVE, I believe that ISS' statistics are valid based on what we are seeing. Further, for the OS software vendors, the types of vulnerabilities are often unusual (e.g. use-after-free, missing initialization) or very difficult to find and exploit. This suggests a significant difference between the level of security at the OS level versus the application level. Generally speaking, of course. (See the 2006 CVE vulnerability trends for further proof of differences between OS and application stats; yes, we'll be updating those stats for 2007/2008). - Steve P.S. the Veracode blog post generated 6 W3C validation errors, so it's more authoritative than some other web pages. Sorry if this joke doesn't register with people, I forget which mailing list people will find this postscript semi-hilarious/semi-cynical in. From ken at krvw.com Tue Nov 11 04:25:50 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 11 Nov 2008 10:25:50 +0100 Subject: [SC-L] Educational web site "hack this" announced Message-ID: <5268B539-8C32-4E3F-A2D4-D67F82ABAB4E@krvw.com> Greetings SC-Lers, FYI, I just learned of an educational web site called "Hack This" (http://www.hackthis.co.uk/ ) that sounds interesting to me. I haven't tried it yet, but I'm sure I will soon. From their description, it sounds a bit like an on-line version of OWASP's WebGoat -- which is IMHO one of the most powerful learning tools I've ever encountered. Hack This describes themselves as follows: "Hackthis, an innovative, educational and entertaining new website where you can learn the tricks and tips of website security. This well designed and well executed concept has proven to be a huge success and will only advance further. Attracting audiences to promote the importance of keeping your website secure, Hackthis is educating the internet for a more safer and secure tomorrow. Whilst education is commonly considered boring, Hackthis teaches you by putting you in the place of the hacker, exploiting websites to gain access to information required to advance to the next level. If that's not enough Hackthis also includes a great, friendly support and community forum where you can get help with problems, meet new people and help others with their problems. We highly recommend this site for website developers to ensure your site is safe and secure. Also, if you're bored, hacking is a great way to pass the time! Remember, Hackthis is completely legal and 100% awesome!" Has anyone here tried it out? Any opinions, good bad or otherwise? Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081111/b0d51a79/attachment.bin From peter.werner at gmail.com Wed Nov 12 19:21:52 2008 From: peter.werner at gmail.com (Pete Werner) Date: Thu, 13 Nov 2008 11:21:52 +1100 Subject: [SC-L] Language agnostic secure coding guidelines/standards? Message-ID: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> Hi all I've been tasked with developing a secure coding standard for my employer. This will be a policy tool used to get developers to fix issues in their code after an audit, and also hopefully be of use to developers as they work to ensure they are compliant. The kicker is it needs to cover things ranging from cobol running on a mainframe, in house network monitoring software in c and perl through to web and desktop applications in java or .net. I've been doing some searching to see if there is anything similar online, but everything i've found is mostly focussed on web applications or language/platform specific. Does anyone know of something that may be what I'm looking for? It's basically going to be a checklist where every item will be something that can be audited, and the things that aren't relevant to a given application can be ignored. The broad sections I have so far are: Input/Output handling Session Control and Management Memory allocation and Management Authentication Management Authorisation Management Data Protection Logging and Auditing Application Errors and Exceptions Thanks in advance Pete From James.McGovern at thehartford.com Thu Nov 13 09:33:49 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Thu, 13 Nov 2008 09:33:49 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> References: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> Message-ID: <9C557D8C6864CA438EF362318A3DF6D502CC2ABF@AD1HFDEXC306.ad1.prod> Awhile back, I got asked the same question and realized that at some level the question is flawed. Many large enterprises have standards documents that sit on the shelf and the need to create more didn't feel right. Instead, we feel to the posture that we should inverse the problem and instead find a tool that automates the code review process (aka static analysis) where we can not only measure compliance to the standard but get the standards off the shelf. In terms of products, check out Ounce Labs, Coverity, Klocwork, etc. Most will have coverage for C, Java, .NET, etc. The challenge with some of the other languages you have is that pretty much no one in the security community has ever spent much time analyzing the weaknesses in COBOL. There is some stuff out there, but it is light when compared to Java... -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Pete Werner Sent: Wednesday, November 12, 2008 7:22 PM To: Secure Coding Subject: [SC-L] Language agnostic secure coding guidelines/standards? Hi all I've been tasked with developing a secure coding standard for my employer. This will be a policy tool used to get developers to fix issues in their code after an audit, and also hopefully be of use to developers as they work to ensure they are compliant. The kicker is it needs to cover things ranging from cobol running on a mainframe, in house network monitoring software in c and perl through to web and desktop applications in java or .net. I've been doing some searching to see if there is anything similar online, but everything i've found is mostly focussed on web applications or language/platform specific. Does anyone know of something that may be what I'm looking for? It's basically going to be a checklist where every item will be something that can be audited, and the things that aren't relevant to a given application can be ignored. The broad sections I have so far are: Input/Output handling Session Control and Management Memory allocation and Management Authentication Management Authorisation Management Data Protection Logging and Auditing Application Errors and Exceptions Thanks in advance Pete ________________ ************************************************************ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************ From securecoding at nxtg.net Thu Nov 13 09:27:12 2008 From: securecoding at nxtg.net (AF) Date: Thu, 13 Nov 2008 14:27:12 -0000 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> References: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> Message-ID: <49011A39.7000305@nxtg.net> Pete Werner wrote: > Hi all > I've been tasked with developing a secure coding standard for my > employer. This will be a policy tool used to get developers to fix > issues in their code after an audit, and also hopefully be of use to > developers as they work to ensure they are compliant. The kicker is it > needs to cover things ranging from cobol running on a mainframe, in > house network monitoring software in c and perl through to web and > desktop applications in java or .net. > I've been doing some searching to see if there is anything similar > online, but everything i've found is mostly focussed on web > applications or language/platform specific. Does anyone know of > something that may be what I'm looking for? > It's basically going to be a checklist where every item will be > something that can be audited, and the things that aren't relevant to > a given application can be ignored. The broad sections I have so far > are: > Input/Output handling > Session Control and Management > Memory allocation and Management > Authentication Management > Authorisation Management > Data Protection > Logging and Auditing > Application Errors and Exceptions > Thanks in advance > Pete > Hi Pete, You are right when it comes to being agnostic, many checklists and guides found on the web are webapp-oriented. The security frames, however, mostly remain the same for software, whether it is web-based or desktop-based, such as: - authentication - authorisation - data validation - session management - logging - error handling - cryptography - ... The proposition is that you might consider the OWASP's "code review" or "testing" guides checkpoints (more than 60 controls are included) and derive their "architecture-agnostic" counterpart. You can then add the remaining frames, less found on webapp-security guidances, such as memory management or multithreading, from other sources. This strategy would (I hope) help you build a first version of your corporate secure coding guideline in a checklist form. I hope it helps... regards, A ps: http://www.owasp.org/, the guides links are shown in the upper right quick access projects links From vanderaj at owasp.org Thu Nov 13 10:49:01 2008 From: vanderaj at owasp.org (Andrew van der Stock) Date: Thu, 13 Nov 2008 10:49:01 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> References: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> Message-ID: The OWASP materials are fairly language neutral. The closest document to your current requirements is the Developer Guide. I am also developing a coding standard for Owasp with a likely deliverable date next year. I am looking for volunteers to help with it, so if you want a document that exactly meets your needs ... Please join us! Thanks, Andrew On Nov 12, 2008, at 19:21, "Pete Werner" wrote: > Hi all > > I've been tasked with developing a secure coding standard for my > employer. This will be a policy tool used to get developers to fix > issues in their code after an audit, and also hopefully be of use to > developers as they work to ensure they are compliant. The kicker is it > needs to cover things ranging from cobol running on a mainframe, in > house network monitoring software in c and perl through to web and > desktop applications in java or .net. > > I've been doing some searching to see if there is anything similar > online, but everything i've found is mostly focussed on web > applications or language/platform specific. Does anyone know of > something that may be what I'm looking for? > > It's basically going to be a checklist where every item will be > something that can be audited, and the things that aren't relevant to > a given application can be ignored. The broad sections I have so far > are: > > Input/Output handling > Session Control and Management > Memory allocation and Management > Authentication Management > Authorisation Management > Data Protection > Logging and Auditing > Application Errors and Exceptions > > Thanks in advance > Pete > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ From jsteven at cigital.com Thu Nov 13 17:51:34 2008 From: jsteven at cigital.com (John Steven) Date: Thu, 13 Nov 2008 17:51:34 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: References: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com>, Message-ID: <41945506397C0C4886A8C5BFF089B5CA359915D487@va-mailhub.cigital.com> All, James McGovern hits the core issue with his post, though I'm not sure how many organizations are self-aware enough to realize it. In practice, his philosophical quandary plays out through a few key questions. Do I: 1) Write technology-specific best-practices or security policy? 2) Couch my standards as "do not" or "do"? 3) Cull best practices from what people do, or set a bar and drive people towards compliance? 4) Spend money on training, or a tool roll-out? See: http://risiko.cigital.com/justiceleague/2007/05/25/a-mini-architecture-for-security-guidance/ http://risiko.cigital.com/justiceleague/2007/05/21/how-to-write-good-security-guidance/ http://risiko.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/ Though old, these posts still seem to help. More recently, this argument has most frequently taken the form of "language specific guidance or agnostic security guidance?". this has begun to play out in Andrew's post quoted below. Though there's tremendous value in agnostic guidance (especially because it applies well to languages for which specific guidance or tool support doesn't yet exist, and because it withstands time's test slightly better). But, what OWASP has documented is a false victory for the proponents of agnostic guidance--citing its language independence. It, like any decent guidance, IS technology-specific, just not on any particular language. It's closely coupled to both the current web-technology stack as well as a penetration-testing approach (though, frankly that is fine). Move outside of either and you're going to find the guidance wanting. Saying the OWASP guidance is better than language-specific guidance is like getting caught in the rabbit hole of Java's "single language compiled to a virtual machine that runs anywhere" vs. .NETs "many languages compiled to a single format that runs one place." High-minded thought about whether or not one should proceed from the top down (from a strong but impractical to apply) governance initiative or from the bottom-up from a base of core scanning capabilities afforded by a security tool has won me little progress. it's frustrating and I give up. We needed a breakthrough, and we've gotten it: As a result, we've built a tool chain that allows us/our clients to rapidly implement automated checks whether they have a static analysis tool, rely on penetration testing, or desire to implement their security testing as part of a broader QA effort. The 'rub' is that we've stayed technology-specific (to the Java EE platform)--so all the appropriate limitations apply... but recently we were able to deploy the static analysis piece of this puzzle (which we call our Assessment Factory) and automate 55% of a corporation's (rather extensive) security standards for that stack in 12mhrs. That's ridiculous (in a good way). So, in my mind, the key is to get specific and do it quickly. Deciding whether or not to get language or technology-stack specific is a red-herring argument. The question should be: are you going to implement your automation with dynamic testing tools, static analysis tools, or say, a requirements management tool such as Archer. If you're going the dynamic route, focus on technology-specific guidance. Download the OWASP security testing guide. Conduct a gap analysis on the guide: what can you automate with your existing test harness? If you don't have a harness, download Selenium. Once the gap analysis is done: get to work automating iteratively. If you're going the static route: focus on language-specific guidance. Begin customizing your tool to find vulnerable constructs in your architectural idiom, and to detect non-compliance to your corporate standards/policy. It's really not as bad as it can seem. You just have to remember you won't achieve 100% coverage in the first month. Though, any seasoned QA professional will tell you--expecting to is ludicrous. ---- John Steven Senior Director; Advanced Technology Consulting Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 Blog: http://www.cigital.com/justiceleague Papers: http://www.cigital.com/papers/jsteven http://www.cigital.com Software Confidence. Achieved. ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Andrew van der Stock The OWASP materials are fairly language neutral. The closest document to your current requirements is the Developer Guide. I am also developing a coding standard for Owasp with a likely deliverable date next year. I am looking for volunteers to help with it, so if you want a document that exactly meets your needs ... Please join us! On Nov 12, 2008, at 19:21, "Pete Werner" wrote: > Hi all > > I've been tasked with developing a secure coding standard for my > employer. This will be a policy tool used to get developers to fix > issues in their code after an audit, and also hopefully be of use to > developers as they work to ensure they are compliant. The kicker is it > needs to cover things ranging from cobol running on a mainframe, in > house network monitoring software in c and perl through to web and > desktop applications in java or .net. > > I've been doing some searching to see if there is anything similar > online, but everything i've found is mostly focussed on web > applications or language/platform specific. Does anyone know of > something that may be what I'm looking for? > > It's basically going to be a checklist where every item will be > something that can be audited, and the things that aren't relevant to > a given application can be ignored. The broad sections I have so far > are: > > Input/Output handling > Session Control and Management > Memory allocation and Management > Authentication Management > Authorisation Management > Data Protection > Logging and Auditing > Application Errors and Exceptions > > Thanks in advance > Pete > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From dwheeler at ida.org Fri Nov 14 10:35:26 2008 From: dwheeler at ida.org (David A. Wheeler) Date: Fri, 14 Nov 2008 10:35:26 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: References: Message-ID: <491D9ABE.2090907@ida.org> Pete Werner: > I've been tasked with developing a secure coding standard for my > employer..... everything i've found is mostly focussed on web > applications or language/platform specific. Does anyone know of > something that may be what I'm looking for? It's not exactly what you're looking for, but you can take a peek at my book, which is on-line: http://www.dwheeler.com/secure-programs/ It's language agnostic, it provides guidelines for secure coding, and it applies to both web apps & non-web-apps. It _does_ focus on the Unix/Linux platform, as it was intended to... but at this point the majority of it is actually platform-agnostic. It is _NOT_ a checklist, though. Instead of focusing on a checklist for humans, I would suggest using a static analysis tool to implement as much of a "checklist" as possible. Then any checklist you create should only include things that CANNOT be easily automated (e.g., "no default password"). However: TRAIN THE DEVELOPERS FIRST. Use my book, another book, whatever, but TRAIN them. In my experience, just handing a checklist or static analysis tool to developers is ineffective; a security-clueless developer will often not understand what the checklist/tool is saying, or "fix" it in a way that doesn't solve the problem. In contrast, having your developers understand security will mean that even WITHOUT a checklist/tool, they'll produce much better software... and then checklists & tools can actually be helpful. Since today's "average developer" has no clue about security, you MUST train them... you can't assume they start that way. For a funny example where just handing someone a static analysis tool didn't do any good, see: http://www.dwheeler.com/flawfinder/#fool-with-tool In this case, RealNetworks used a static analysis tool (flawfinder), but instead of fixing the vulnerabilities flawfinder found, they just inserted directives to tell flawfinder to stop reporting the vulnerabilities. Of course, this didn't actually FIX the vulnerabilities...! And my thanks to RealNetworks for coming clean about their mistake; I'm sure they're neither the first NOR last, and we can learn from them. --- David A. Wheeler From rcs at cert.org Fri Nov 14 10:53:39 2008 From: rcs at cert.org (Robert Seacord) Date: Fri, 14 Nov 2008 10:53:39 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> References: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> Message-ID: Pete, I think your best bet is the work being done by ISO/IEC JTC 1/SC 22/ WG 23 Programming Language Vulnerabilities. The website for this work is http://www.aitcnet.org/isai/. The latest Editor's draft of PDTR 24772, prepared by John Benito, is N0138 which can be found here: http://www.aitcnet.org/isai/_Mtg_10/_Mtg_9/22-OWGV-N-0138/n0138.pdf This document provides language independent guidance, with language specific annexes. I think this comes closes to what you are looking for. CERT has/is developing language specific standards for C, C++, and Java and are available online at www.securecoding.cert.org. There is also a static version of the C standard which has been published by Addison-Wesley http://www.informit.com/store/product.aspx?isbn=0321563212 if you prefer your standards fixed instead of continually evolving. ;^) Our Java Secure Coding standard is being developed collaboratively with Sun Microsystems. Eventually, I'll probably get an announcement out to that effect. Thanks, rCs -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Pete Werner Sent: Wednesday, November 12, 2008 7:22 PM To: Secure Coding Subject: [SC-L] Language agnostic secure coding guidelines/standards? Hi all I've been tasked with developing a secure coding standard for my employer. This will be a policy tool used to get developers to fix issues in their code after an audit, and also hopefully be of use to developers as they work to ensure they are compliant. The kicker is it needs to cover things ranging from cobol running on a mainframe, in house network monitoring software in c and perl through to web and desktop applications in java or .net. I've been doing some searching to see if there is anything similar online, but everything i've found is mostly focussed on web applications or language/platform specific. Does anyone know of something that may be what I'm looking for? It's basically going to be a checklist where every item will be something that can be audited, and the things that aren't relevant to a given application can be ignored. The broad sections I have so far are: Input/Output handling Session Control and Management Memory allocation and Management Authentication Management Authorisation Management Data Protection Logging and Auditing Application Errors and Exceptions Thanks in advance Pete _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From gem at cigital.com Fri Nov 14 11:24:19 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 14 Nov 2008 11:24:19 -0500 Subject: [SC-L] Silver Bullet and informIT: Jeremiah Grossman Message-ID: hi sc-l, Episode 32 of the Silver Bullet Security Podcast went live last night. This episode features a chat with Web security guru Jeremiah Grossman. Among other things, we talk about the relationship between Web app security and software security: http://www.cigital.com/silverbullet/ Jeremiah and I cross paths out there on the evangelism circuit pretty often and it was nice to catch up with him. Near the end of our conversation, we raised the idea of whether all Web security problems have analogs in the software security space and what that might mean. After thinking more about that issue, I made it the subject of this month's informIT column: http://www.informit.com/articles/article.aspx?p=1309290 Please let me know what you think about the role that Web application security plays in software security today (and whether you think we focus the right amount of attention, too much, or too little). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From coley at linus.mitre.org Mon Nov 17 16:49:56 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 17 Nov 2008 16:49:56 -0500 (EST) Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: References: <6378f48a0811121621h1e869e17rf2f48f27aeed2d52@mail.gmail.com> Message-ID: The CWE Research view (CWE-1000) is language-neutral at its higher-level nodes, and decomposes in some areas into language-specific constructs. Early experience suggests that this view is not necessarily developer-friendly, however, because it's not organized around the types of concepts that developers typically think in. http://cwe.mitre.org/data/definitions/1000.html (click the Graph tab on the top right of the page to see the breakdown) Obviously the CWE is a badness-ometer-pedia but suggests some areas that your guidelines would hopefully address. - Steve From gem at cigital.com Wed Nov 19 16:00:06 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 19 Nov 2008 16:00:06 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: Message-ID: badness-ometer-pedia! most excellent descriptive phrase. You guys should change the official name! Incidentally, one of the best uses data like these can be put to is training. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/17/08 4:49 PM, "Steven M. Christey" wrote: The CWE Research view (CWE-1000) is language-neutral at its higher-level nodes, and decomposes in some areas into language-specific constructs. Early experience suggests that this view is not necessarily developer-friendly, however, because it's not organized around the types of concepts that developers typically think in. http://cwe.mitre.org/data/definitions/1000.html (click the Graph tab on the top right of the page to see the breakdown) Obviously the CWE is a badness-ometer-pedia but suggests some areas that your guidelines would hopefully address. - Steve _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From peter.werner at gmail.com Fri Nov 21 01:39:47 2008 From: peter.werner at gmail.com (Pete Werner) Date: Fri, 21 Nov 2008 17:39:47 +1100 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: References: Message-ID: <6378f48a0811202239k2148580k675c4b903502642b@mail.gmail.com> Hi All Thank you for your replies, they have been very useful and will certainly help identifying things that need to appear in the standard. We're trying to make the standard something that is easily auditable, and have decided to further split items into two categories, those that should checked in development and those that should appear in the project documentation (e.g. things like definitions of log integrity/confidentiality requirements etc). I'm also happy to say that within our organisation we already have secure coding training available for developers, support channels for developers with queries, language specific guidance, automated tools that can be used to detect software flaws as well as an internal auditing and pentesting function. Needless to say it's been a big effort to get all this in place. The policy is an important piece of the puzzle which will hopefully help ensure the training and tools are utilised by developers. These things are all great, but from an organisational perspective one of the most important things for us is the ongoing risk management of identified issues. We have a lot of applications in various stages of development and production, and a lot of developers. Tracking known issues, remediation timelines, and who is responsible for what is also a very big part of it, especially in larger organisations. Again I'm happy to say we have an internally developed system for doing this. Rather than just giving myself a gold star on a mailing list, I would say to the vendors here interoperability is a big thing for us, as no one product does it all to the level we require (and it's unlikely they ever will). We are far more likely to buy things that play nicely with what we have already, and so far, most of the tools we use do. Gold stars all round. Anyway, thanks again for all the information. Cheers, Pete On Thu, Nov 20, 2008 at 8:00 AM, Gary McGraw wrote: > badness-ometer-pedia! most excellent descriptive phrase. You guys should change the official name! > > Incidentally, one of the best uses data like these can be put to is training. > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > > On 11/17/08 4:49 PM, "Steven M. Christey" wrote: > > > > The CWE Research view (CWE-1000) is language-neutral at its higher-level > nodes, and decomposes in some areas into language-specific constructs. > Early experience suggests that this view is not necessarily > developer-friendly, however, because it's not organized around the types > of concepts that developers typically think in. > > http://cwe.mitre.org/data/definitions/1000.html > > (click the Graph tab on the top right of the page to see the breakdown) > > Obviously the CWE is a badness-ometer-pedia but suggests some areas that > your guidelines would hopefully address. > > - Steve > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From dave.wichers at aspectsecurity.com Fri Nov 21 08:55:44 2008 From: dave.wichers at aspectsecurity.com (Dave Wichers) Date: Fri, 21 Nov 2008 08:55:44 -0500 Subject: [SC-L] Language agnostic secure coding guidelines/standards? In-Reply-To: <6378f48a0811202239k2148580k675c4b903502642b@mail.gmail.com> References: <6378f48a0811202239k2148580k675c4b903502642b@mail.gmail.com> Message-ID: I'd like to mention that OWASP is about to release a Beta version of its Application Security Verification Standard (ASVS) - Web Application Edition. This standard (which is language agnostic) provides a checklist of security requirements that web applications should meet and it is organized into increasing levels of difficulty based on the techniques you use to assess the application. The first level is based on what automated code analysis and external scanning tools can find. The second level is based on what human verifiers can find (who may use automated tools to assist them) doing code analysis and/or application penetration testing. There is also a third and fourth level that add additional requirements in the areas of architecture review, threat modeling, and the avoidance of malicious code. I would think that this document would serve as a great reference to pull from in order to gather a set of language independent secure coding guidelines since this is essentially the list of application security best practices that OWASP believes web applications need to meet in order to provide a baseline level of security. These requirements clearly don't include every security issue a web application may need to address but it defines the foundational requirements that we believe every application should meet. An Alpha version of this standard is already publicly available at: http://www.owasp.org/index.php/ASVS And the Beta release is close to completion and should come out sometime this December. I have cc'd Mike Boberski who is the project lead for this OWASP Summer of Code 2008 project. You can contact either of us (as well as Jeff Williams) if you have any questions about this new OWASP Standard as the three of us are the primary authors of this document. -Dave -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Pete Werner Sent: Friday, November 21, 2008 1:40 AM To: Secure Coding Subject: Re: [SC-L] Language agnostic secure coding guidelines/standards? Hi All Thank you for your replies, they have been very useful and will certainly help identifying things that need to appear in the standard. We're trying to make the standard something that is easily auditable, and have decided to further split items into two categories, those that should checked in development and those that should appear in the project documentation (e.g. things like definitions of log integrity/confidentiality requirements etc). I'm also happy to say that within our organisation we already have secure coding training available for developers, support channels for developers with queries, language specific guidance, automated tools that can be used to detect software flaws as well as an internal auditing and pentesting function. Needless to say it's been a big effort to get all this in place. The policy is an important piece of the puzzle which will hopefully help ensure the training and tools are utilised by developers. These things are all great, but from an organisational perspective one of the most important things for us is the ongoing risk management of identified issues. We have a lot of applications in various stages of development and production, and a lot of developers. Tracking known issues, remediation timelines, and who is responsible for what is also a very big part of it, especially in larger organisations. Again I'm happy to say we have an internally developed system for doing this. Rather than just giving myself a gold star on a mailing list, I would say to the vendors here interoperability is a big thing for us, as no one product does it all to the level we require (and it's unlikely they ever will). We are far more likely to buy things that play nicely with what we have already, and so far, most of the tools we use do. Gold stars all round. Anyway, thanks again for all the information. Cheers, Pete On Thu, Nov 20, 2008 at 8:00 AM, Gary McGraw wrote: > badness-ometer-pedia! most excellent descriptive phrase. You guys should change the official name! > > Incidentally, one of the best uses data like these can be put to is training. > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > > On 11/17/08 4:49 PM, "Steven M. Christey" wrote: > > > > The CWE Research view (CWE-1000) is language-neutral at its higher-level > nodes, and decomposes in some areas into language-specific constructs. > Early experience suggests that this view is not necessarily > developer-friendly, however, because it's not organized around the types > of concepts that developers typically think in. > > http://cwe.mitre.org/data/definitions/1000.html > > (click the Graph tab on the top right of the page to see the breakdown) > > Obviously the CWE is a badness-ometer-pedia but suggests some areas that > your guidelines would hopefully address. > > - Steve > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From rgaucher at cigital.com Sat Nov 22 17:24:32 2008 From: rgaucher at cigital.com (Romain Gaucher) Date: Sat, 22 Nov 2008 17:24:32 -0500 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security Message-ID: <853A02533F8C88439F2331EB19385384403A2F3B30@va-mailhub.cigital.com> All, The NSA has just unclassified a 300 pages document about .NET 2.0 security http://www.nsa.gov/snac/app/I731-008R-2006.pdf I think it can be interesting resource, --Romain Romain Gaucher Security Consultant Cigital, http://www.cigital.com Software Confidence. Achieved. From dinis at ddplus.net Mon Nov 24 06:33:59 2008 From: dinis at ddplus.net (Dinis Cruz) Date: Mon, 24 Nov 2008 11:33:59 +0000 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <853A02533F8C88439F2331EB19385384403A2F3B30@va-mailhub.cigital.com> References: <853A02533F8C88439F2331EB19385384403A2F3B30@va-mailhub.cigital.com> Message-ID: <701fd6b60811240333o5db3644fsfb2dbe3bfe9f6266@mail.gmail.com> So does this mean that the NSA is recommending .NET applications to be develop so that they can be executed in partially trusted environments? (i.e. not in full trust?) Last time I check just about everybody was developing Full Trust .NET applications (did this change in the last year?) Don't get me wrong, this is a great document if one is interested in writing applications that use CAS (Code Access Security), I would love for this to be widely used. But all great recommendations, like for example: "... Recommendation: Only grant the File IO access permissions Read, Write, or Append to code that is trusted not to allow unauthorized access to file system resources. Grant File IO access to the most restrictive set of files and folders possible. Do not grant File IO access to file system roots or other broadly specified resources simply because they contain a few scattered files of interest. ...", page 17 "... Recommendation: In following with least privilege, grant the Data Protection permission to the most restrictive set of permissions possible....", page 26 "... Recommendation: The Socket Access permission should only be granted to highly trusted code or code that originates from the local network (evidenced by a strong name withservices....", page 28 "... Recommendation: The Allow Calls to Unmanaged Assemblies permission should be granted only to code that is trusted to execute with the same privileges as the user's account under which the code is running. ...", page 48 only mean anything on partially-trusted environment (i.e. non-full trust applications). Dinis Cruz On Sat, Nov 22, 2008 at 10:24 PM, Romain Gaucher wrote: > All, > The NSA has just unclassified a 300 pages document about .NET 2.0 security > http://www.nsa.gov/snac/app/I731-008R-2006.pdf > > I think it can be interesting resource, > > --Romain > > Romain Gaucher > Security Consultant > Cigital, http://www.cigital.com > Software Confidence. Achieved. > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081124/35367981/attachment.html From mlyman-cissp at comcast.net Mon Nov 24 12:31:09 2008 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Mon, 24 Nov 2008 11:31:09 -0600 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <701fd6b60811240333o5db3644fsfb2dbe3bfe9f6266@mail.gmail.com> References: <853A02533F8C88439F2331EB19385384403A2F3B30@va-mailhub.cigital.com> <701fd6b60811240333o5db3644fsfb2dbe3bfe9f6266@mail.gmail.com> Message-ID: <492AE4DD.9070702@comcast.net> Dinis Cruz wrote: > Don't get me wrong, this is a great document if one is interested in > writing applications that use CAS (Code Access Security), I would love > for this to be widely used. When we recommended recommending CAS during a review of the U.S. Defense Information System Agency's new Application Security and Development Security Technical Implementation Guide earlier this year we were met with what amounted to blank stares. (At least it seemed like that since it was a phone conference.) Some on the call understood it and agreed with the recommendation but those hosting the call and doing the writing didn't seem to grasp it. It may be a while before we see too many adopting this or requiring it for a while. -- Mike Lyman mlyman at west-point.org From gem at cigital.com Mon Nov 24 17:34:18 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 24 Nov 2008 17:34:18 -0500 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <492AE4DD.9070702@comcast.net> Message-ID: Sadly this non-adoption of privileged/managed code (filled with blank stares) has been the case ever since the Java security days a decade ago. One of the main challenges is that developers have a hard time thinking about the principle of least privilege and its implications regarding the capabilities they should request. Dinis is brave to set such thinking as a target. I've settled (after ten years) with getting developers just to utter the word "security." All together now..."security". gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/24/08 12:31 PM, "Mike Lyman" wrote: Dinis Cruz wrote: > Don't get me wrong, this is a great document if one is interested in > writing applications that use CAS (Code Access Security), I would love > for this to be widely used. When we recommended recommending CAS during a review of the U.S. Defense Information System Agency's new Application Security and Development Security Technical Implementation Guide earlier this year we were met with what amounted to blank stares. (At least it seemed like that since it was a phone conference.) Some on the call understood it and agreed with the recommendation but those hosting the call and doing the writing didn't seem to grasp it. It may be a while before we see too many adopting this or requiring it for a while. -- Mike Lyman mlyman at west-point.org _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From gunnar at arctecgroup.net Tue Nov 25 09:18:18 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 25 Nov 2008 08:18:18 -0600 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: References: Message-ID: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> maybe the problem with least privilege is that it requires that developers: 1. define the entire universe of subjects and objects 2. define all possible access rights 3. define all possible relationships 4. apply all settings 5. figure out how to keep 1-4 in synch all the time do all of this before you start writing code and oh and there are basically no tools that smooth the adoption of the above. i don't think us software security people are helping anybody out in 2008 by doing ritual incantations of a paper from the mid 70s that may or may not apply to modern computing and anyhow is riddled with ideas that have never been implemented in any large scale systems compare these two statements Statement 1. Saltzer and Schroeder: "f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle." Statement 2. David Gelernter's Manifesto: "28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a "passive" instead of "active" view of information management that is fundamentally wrong for computers. 29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers ? and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be. 30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays the idea of giving a name to every file on your computer is ridiculous." Conclusion(gp): Least Privilege is the point where the practical matter of applying Saltzer and Schroeder's principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes. http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html Remember the 1990s when there were all these search engines that required you tag up all the content and put it in hierarchical directories and so on? Well what happened? Google came along and ate their lunch. When the problem is information overload, telling everyone to go out and label everything is not gonna work. -gunnar On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: > Sadly this non-adoption of privileged/managed code (filled with > blank stares) has been the case ever since the Java security days a > decade ago. One of the main challenges is that developers have a > hard time thinking about the principle of least privilege and its > implications regarding the capabilities they should request. Dinis > is brave to set such thinking as a target. I've settled (after ten > years) with getting developers just to utter the word "security." > > All together now..."security". > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > > On 11/24/08 12:31 PM, "Mike Lyman" wrote: > > Dinis Cruz wrote: >> Don't get me wrong, this is a great document if one is interested in >> writing applications that use CAS (Code Access Security), I would >> love >> for this to be widely used. > > When we recommended recommending CAS during a review of the U.S. > Defense > Information System Agency's new Application Security and Development > Security Technical Implementation Guide earlier this year we were met > with what amounted to blank stares. (At least it seemed like that > since > it was a phone conference.) Some on the call understood it and agreed > with the recommendation but those hosting the call and doing the > writing > didn't seem to grasp it. It may be a while before we see too many > adopting this or requiring it for a while. > -- > > Mike Lyman > mlyman at west-point.org > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ > From stephencraig.evans at gmail.com Tue Nov 25 11:30:37 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Wed, 26 Nov 2008 00:30:37 +0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> Message-ID: <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> HI, "maybe the problem with least privilege is that it requires that developers:..." IMHO, your US/UK ivory towers don't exist in other parts of the world. Developers have no say in what they do. Nor, do they care about software security and why should they care? So, at least, change your nomenclature and not say "developers". It offends me because you are putting the onus of knowing about software security on the wrong people. Cheers, Stephen On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson wrote: > maybe the problem with least privilege is that it requires that > developers: > > 1. define the entire universe of subjects and objects > 2. define all possible access rights > 3. define all possible relationships > 4. apply all settings > 5. figure out how to keep 1-4 in synch all the time > > do all of this before you start writing code and oh and there are > basically no tools that smooth the adoption of the above. > > i don't think us software security people are helping anybody out in > 2008 by doing ritual incantations of a paper from the mid 70s that may > or may not apply to modern computing and anyhow is riddled with ideas > that have never been implemented in any large scale systems > > compare these two statements > > Statement 1. Saltzer and Schroeder: > "f) Least privilege: Every program and every user of the system should > operate using the least set of privileges necessary to complete the > job. Primarily, this principle limits the damage that can result from > an accident or error. It also reduces the number of potential > interactions among privileged programs to the minimum for correct > operation, so that unintentional, unwanted, or improper uses of > privilege are less likely to occur. Thus, if a question arises related > to misuse of a privilege, the number of programs that must be audited > is minimized. Put another way, if a mechanism can provide "firewalls," > the principle of least privilege provides a rationale for where to > install the firewalls. The military security rule of "need-to-know" is > an example of this principle." > > Statement 2. David Gelernter's Manifesto: > "28. Metaphors have a profound effect on computing: the file-cabinet > metaphor traps us in a "passive" instead of "active" view of > information management that is fundamentally wrong for computers. > > 29. The rigid file and directory system you are stuck with on your Mac > or PC was designed by programmers for programmers ? and is still a > good system for programmers. It is no good for non-programmers. It > never was, and was never intended to be. > > 30. If you have three pet dogs, give them names. If you have 10,000 > head of cattle, don't bother. Nowadays the idea of giving a name to > every file on your computer is ridiculous." > > Conclusion(gp): Least Privilege is the point where the practical > matter of applying Saltzer and Schroeder's principles breaks down in > modern systems. Its a deployment issue, and a matter of insufficient > models and modes. > > http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html > > Remember the 1990s when there were all these search engines that > required you tag up all the content and put it in hierarchical > directories and so on? Well what happened? Google came along and ate > their lunch. When the problem is information overload, telling > everyone to go out and label everything is not gonna work. > > -gunnar > > > > On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: > >> Sadly this non-adoption of privileged/managed code (filled with >> blank stares) has been the case ever since the Java security days a >> decade ago. One of the main challenges is that developers have a >> hard time thinking about the principle of least privilege and its >> implications regarding the capabilities they should request. Dinis >> is brave to set such thinking as a target. I've settled (after ten >> years) with getting developers just to utter the word "security." >> >> All together now..."security". >> >> gem >> >> company www.cigital.com >> podcast www.cigital.com/silverbullet >> blog www.cigital.com/justiceleague >> book www.swsec.com >> >> >> On 11/24/08 12:31 PM, "Mike Lyman" wrote: >> >> Dinis Cruz wrote: >>> Don't get me wrong, this is a great document if one is interested in >>> writing applications that use CAS (Code Access Security), I would >>> love >>> for this to be widely used. >> >> When we recommended recommending CAS during a review of the U.S. >> Defense >> Information System Agency's new Application Security and Development >> Security Technical Implementation Guide earlier this year we were met >> with what amounted to blank stares. (At least it seemed like that >> since >> it was a phone conference.) Some on the call understood it and agreed >> with the recommendation but those hosting the call and doing the >> writing >> didn't seem to grasp it. It may be a while before we see too many >> adopting this or requiring it for a while. >> -- >> >> Mike Lyman >> mlyman at west-point.org >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com >> ) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com >> ) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From gunnar at arctecgroup.net Tue Nov 25 11:48:09 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 25 Nov 2008 10:48:09 -0600 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> Message-ID: Sorry I didn't realize "developers" is an offensive ivory tower in other parts of the world, in my world its a compliment. -gunnar On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: > HI, > > "maybe the problem with least privilege is that it requires that > developers:..." > > IMHO, your US/UK ivory towers don't exist in other parts of the world. > Developers have no say in what they do. Nor, do they care about > software security and why should they care? > > So, at least, change your nomenclature and not say "developers". It > offends me because you are putting the onus of knowing about software > security on the wrong people. > > Cheers, > Stephen > > On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson > wrote: >> maybe the problem with least privilege is that it requires that >> developers: >> >> 1. define the entire universe of subjects and objects >> 2. define all possible access rights >> 3. define all possible relationships >> 4. apply all settings >> 5. figure out how to keep 1-4 in synch all the time >> >> do all of this before you start writing code and oh and there are >> basically no tools that smooth the adoption of the above. >> >> i don't think us software security people are helping anybody out in >> 2008 by doing ritual incantations of a paper from the mid 70s that >> may >> or may not apply to modern computing and anyhow is riddled with ideas >> that have never been implemented in any large scale systems >> >> compare these two statements >> >> Statement 1. Saltzer and Schroeder: >> "f) Least privilege: Every program and every user of the system >> should >> operate using the least set of privileges necessary to complete the >> job. Primarily, this principle limits the damage that can result from >> an accident or error. It also reduces the number of potential >> interactions among privileged programs to the minimum for correct >> operation, so that unintentional, unwanted, or improper uses of >> privilege are less likely to occur. Thus, if a question arises >> related >> to misuse of a privilege, the number of programs that must be audited >> is minimized. Put another way, if a mechanism can provide >> "firewalls," >> the principle of least privilege provides a rationale for where to >> install the firewalls. The military security rule of "need-to-know" >> is >> an example of this principle." >> >> Statement 2. David Gelernter's Manifesto: >> "28. Metaphors have a profound effect on computing: the file-cabinet >> metaphor traps us in a "passive" instead of "active" view of >> information management that is fundamentally wrong for computers. >> >> 29. The rigid file and directory system you are stuck with on your >> Mac >> or PC was designed by programmers for programmers ? and is still a >> good system for programmers. It is no good for non-programmers. It >> never was, and was never intended to be. >> >> 30. If you have three pet dogs, give them names. If you have 10,000 >> head of cattle, don't bother. Nowadays the idea of giving a name to >> every file on your computer is ridiculous." >> >> Conclusion(gp): Least Privilege is the point where the practical >> matter of applying Saltzer and Schroeder's principles breaks down in >> modern systems. Its a deployment issue, and a matter of insufficient >> models and modes. >> >> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >> >> Remember the 1990s when there were all these search engines that >> required you tag up all the content and put it in hierarchical >> directories and so on? Well what happened? Google came along and ate >> their lunch. When the problem is information overload, telling >> everyone to go out and label everything is not gonna work. >> >> -gunnar >> >> >> >> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >> >>> Sadly this non-adoption of privileged/managed code (filled with >>> blank stares) has been the case ever since the Java security days a >>> decade ago. One of the main challenges is that developers have a >>> hard time thinking about the principle of least privilege and its >>> implications regarding the capabilities they should request. Dinis >>> is brave to set such thinking as a target. I've settled (after ten >>> years) with getting developers just to utter the word "security." >>> >>> All together now..."security". >>> >>> gem >>> >>> company www.cigital.com >>> podcast www.cigital.com/silverbullet >>> blog www.cigital.com/justiceleague >>> book www.swsec.com >>> >>> >>> On 11/24/08 12:31 PM, "Mike Lyman" wrote: >>> >>> Dinis Cruz wrote: >>>> Don't get me wrong, this is a great document if one is interested >>>> in >>>> writing applications that use CAS (Code Access Security), I would >>>> love >>>> for this to be widely used. >>> >>> When we recommended recommending CAS during a review of the U.S. >>> Defense >>> Information System Agency's new Application Security and Development >>> Security Technical Implementation Guide earlier this year we were >>> met >>> with what amounted to blank stares. (At least it seemed like that >>> since >>> it was a phone conference.) Some on the call understood it and >>> agreed >>> with the recommendation but those hosting the call and doing the >>> writing >>> didn't seem to grasp it. It may be a while before we see too many >>> adopting this or requiring it for a while. >>> -- >>> >>> Mike Lyman >>> mlyman at west-point.org >>> >>> _______________________________________________ >>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >>> List charter available at - http://www.securecoding.org/list/charter.php >>> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com >>> ) >>> as a free, non-commercial service to the software security >>> community. >>> _______________________________________________ >>> >>> >>> _______________________________________________ >>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >>> List charter available at - http://www.securecoding.org/list/charter.php >>> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com >>> ) >>> as a free, non-commercial service to the software security >>> community. >>> _______________________________________________ >>> >> >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com >> ) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> > From stephencraig.evans at gmail.com Tue Nov 25 12:01:00 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Wed, 26 Nov 2008 01:01:00 +0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> Message-ID: <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> Gunnar, Developers have no power. You should be talking to the decision makers. As an example, to instill the importance of software security, I talk to decision makers: project managers, architects, CTOs (admittedly, this is a blurred line - lots of folks call themselves architects). If I go to talk about software security to developers, I know from experience that I am probably wasting my time. Even if they do care, they have no effect overall. Your target and blame is wrong; that's all that I am saying. Stephen On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson wrote: > Sorry I didn't realize "developers" is an offensive ivory tower in other > parts of the world, in my world its a compliment. > > -gunnar > > On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: > >> HI, >> >> "maybe the problem with least privilege is that it requires that >> developers:..." >> >> IMHO, your US/UK ivory towers don't exist in other parts of the world. >> Developers have no say in what they do. Nor, do they care about >> software security and why should they care? >> >> So, at least, change your nomenclature and not say "developers". It >> offends me because you are putting the onus of knowing about software >> security on the wrong people. >> >> Cheers, >> Stephen >> >> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >> wrote: >>> >>> maybe the problem with least privilege is that it requires that >>> developers: >>> >>> 1. define the entire universe of subjects and objects >>> 2. define all possible access rights >>> 3. define all possible relationships >>> 4. apply all settings >>> 5. figure out how to keep 1-4 in synch all the time >>> >>> do all of this before you start writing code and oh and there are >>> basically no tools that smooth the adoption of the above. >>> >>> i don't think us software security people are helping anybody out in >>> 2008 by doing ritual incantations of a paper from the mid 70s that may >>> or may not apply to modern computing and anyhow is riddled with ideas >>> that have never been implemented in any large scale systems >>> >>> compare these two statements >>> >>> Statement 1. Saltzer and Schroeder: >>> "f) Least privilege: Every program and every user of the system should >>> operate using the least set of privileges necessary to complete the >>> job. Primarily, this principle limits the damage that can result from >>> an accident or error. It also reduces the number of potential >>> interactions among privileged programs to the minimum for correct >>> operation, so that unintentional, unwanted, or improper uses of >>> privilege are less likely to occur. Thus, if a question arises related >>> to misuse of a privilege, the number of programs that must be audited >>> is minimized. Put another way, if a mechanism can provide "firewalls," >>> the principle of least privilege provides a rationale for where to >>> install the firewalls. The military security rule of "need-to-know" is >>> an example of this principle." >>> >>> Statement 2. David Gelernter's Manifesto: >>> "28. Metaphors have a profound effect on computing: the file-cabinet >>> metaphor traps us in a "passive" instead of "active" view of >>> information management that is fundamentally wrong for computers. >>> >>> 29. The rigid file and directory system you are stuck with on your Mac >>> or PC was designed by programmers for programmers ? and is still a >>> good system for programmers. It is no good for non-programmers. It >>> never was, and was never intended to be. >>> >>> 30. If you have three pet dogs, give them names. If you have 10,000 >>> head of cattle, don't bother. Nowadays the idea of giving a name to >>> every file on your computer is ridiculous." >>> >>> Conclusion(gp): Least Privilege is the point where the practical >>> matter of applying Saltzer and Schroeder's principles breaks down in >>> modern systems. Its a deployment issue, and a matter of insufficient >>> models and modes. >>> >>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>> >>> Remember the 1990s when there were all these search engines that >>> required you tag up all the content and put it in hierarchical >>> directories and so on? Well what happened? Google came along and ate >>> their lunch. When the problem is information overload, telling >>> everyone to go out and label everything is not gonna work. >>> >>> -gunnar >>> >>> >>> >>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>> >>>> Sadly this non-adoption of privileged/managed code (filled with >>>> blank stares) has been the case ever since the Java security days a >>>> decade ago. One of the main challenges is that developers have a >>>> hard time thinking about the principle of least privilege and its >>>> implications regarding the capabilities they should request. Dinis >>>> is brave to set such thinking as a target. I've settled (after ten >>>> years) with getting developers just to utter the word "security." >>>> >>>> All together now..."security". >>>> >>>> gem >>>> >>>> company www.cigital.com >>>> podcast www.cigital.com/silverbullet >>>> blog www.cigital.com/justiceleague >>>> book www.swsec.com >>>> >>>> >>>> On 11/24/08 12:31 PM, "Mike Lyman" wrote: >>>> >>>> Dinis Cruz wrote: >>>>> >>>>> Don't get me wrong, this is a great document if one is interested in >>>>> writing applications that use CAS (Code Access Security), I would >>>>> love >>>>> for this to be widely used. >>>> >>>> When we recommended recommending CAS during a review of the U.S. >>>> Defense >>>> Information System Agency's new Application Security and Development >>>> Security Technical Implementation Guide earlier this year we were met >>>> with what amounted to blank stares. (At least it seemed like that >>>> since >>>> it was a phone conference.) Some on the call understood it and agreed >>>> with the recommendation but those hosting the call and doing the >>>> writing >>>> didn't seem to grasp it. It may be a while before we see too many >>>> adopting this or requiring it for a while. >>>> -- >>>> >>>> Mike Lyman >>>> mlyman at west-point.org >>>> >>>> _______________________________________________ >>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>> List information, subscriptions, etc - >>>> http://krvw.com/mailman/listinfo/sc-l >>>> List charter available at - http://www.securecoding.org/list/charter.php >>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>> (http://www.KRvW.com >>>> ) >>>> as a free, non-commercial service to the software security community. >>>> _______________________________________________ >>>> >>>> >>>> _______________________________________________ >>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>> List information, subscriptions, etc - >>>> http://krvw.com/mailman/listinfo/sc-l >>>> List charter available at - http://www.securecoding.org/list/charter.php >>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>> (http://www.KRvW.com >>>> ) >>>> as a free, non-commercial service to the software security community. >>>> _______________________________________________ >>>> >>> >>> >>> _______________________________________________ >>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>> List information, subscriptions, etc - >>> http://krvw.com/mailman/listinfo/sc-l >>> List charter available at - http://www.securecoding.org/list/charter.php >>> SC-L is hosted and moderated by KRvW Associates, LLC >>> (http://www.KRvW.com) >>> as a free, non-commercial service to the software security community. >>> _______________________________________________ >>> >> > > From ken at krvw.com Tue Nov 25 11:42:37 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 25 Nov 2008 11:42:37 -0500 Subject: [SC-L] Opportunity at DTCC Message-ID: <44EC7E33-84A7-4896-BE00-062CF47BE25C@krvw.com> Greetings SC-L, I've been asked to allow a job posting here on SC-L. It certainly doesn't violate anything I've written in the group's charter (http://www.securecoding.org/list/charter.php ), but then again, we've generally not used SC-L for job listings. And then again++, with the economy such as it is, perhaps this sort of thing is a good community service. So, below is the job listing I was asked to post. If anyone here on SC-L has strong feelings for or against future job postings here, please let me know. I'm always happy to take your opinions into consideration! Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com =========================== The Depository Trust and Clearing Corporation (DTCC) is the premier global financial institution responsible for clearing and settling many types of financial transactions between banks and brokerage firms for the United States and many foreign markets. These include stock, bond, fixed income, government, mortgage, and insurance transactions. DTCC has an exciting position in Application Security based in Tampa, Florida. The position is responsible for leading a highly successful and innovative Application Security Program across the DTCC enterprise. This includes driving security in our SDLC, as well as ensuring products and services procured are also built with security in mind. The successful candidate will find the challenges of our leading edge environment, to be very stimulating. We are looking for a candidate that has knowledge of SDLC's, Java, C++, and secure coding practices. The successful candidate will be able to interface and speak to programmers in our Development organization about secure programming, as well as be able to present to senior leadership including the CIO, CTO, and CDO. The successful candidate will also understand the value of KPIs to determine what new controls might be needed, and to lead the implementation of these. In addition to the technical skills above, thought leadership, communication , and relationship management skills are critical qualities of the successful candidate. Qualified candidates should contact Mike Longo, Director (HR) at mlongo at dtcc.com. ========================== -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081125/b7648502/attachment-0001.bin From mrockman at acm.org Tue Nov 25 12:26:02 2008 From: mrockman at acm.org (Mark Rockman) Date: Tue, 25 Nov 2008 12:26:02 -0500 Subject: [SC-L] Software Assist to Find Least Privilege Message-ID: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> It be difficult to determine a priori the settings for all the access control lists and other security parameters that one must establish for CAS to work. Perhaps a software assist would work according to the following scenario. Run the program in the environment in which it will actually be used. Assume minimal permissions. Each time the program would fail due to violation of some permission, notate the event and plow on. Assuming this is repeated for every use case, the resulting reports would be a very good guide to how CAS settings should be established for production. Of course, everytime the program is changed in any way, the process would have to be repeated. MARK ROCKMAN MDRSESCO LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081125/b19e09cb/attachment.html From stephencraig.evans at gmail.com Tue Nov 25 12:28:34 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Wed, 26 Nov 2008 01:28:34 +0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> Message-ID: <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> It's a real cop-out for you guys, as titans in the industry, to go after developers. I'm disappointed in both of you. And Gary, you said "One of the main challenges is that developers have a hard time thinking about the principle of least privilege ". Developers are NEVER asked to think about the principle of least privilege. Or your world of software security must be very very very different from mine (and I think my world at least equals yours but by about 2 billion people more, which might be irrelevant now but a little more relevant in the future :-) With the greatest, deepest respect to both of you, Stephen On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans wrote: > Gunnar, > > Developers have no power. You should be talking to the decision makers. > > As an example, to instill the importance of software security, I talk > to decision makers: project managers, architects, CTOs (admittedly, > this is a blurred line - lots of folks call themselves architects). If > I go to talk about software security to developers, I know from > experience that I am probably wasting my time. Even if they do care, > they have no effect overall. > > Your target and blame is wrong; that's all that I am saying. > > Stephen > > On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson > wrote: >> Sorry I didn't realize "developers" is an offensive ivory tower in other >> parts of the world, in my world its a compliment. >> >> -gunnar >> >> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >> >>> HI, >>> >>> "maybe the problem with least privilege is that it requires that >>> developers:..." >>> >>> IMHO, your US/UK ivory towers don't exist in other parts of the world. >>> Developers have no say in what they do. Nor, do they care about >>> software security and why should they care? >>> >>> So, at least, change your nomenclature and not say "developers". It >>> offends me because you are putting the onus of knowing about software >>> security on the wrong people. >>> >>> Cheers, >>> Stephen >>> >>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>> wrote: >>>> >>>> maybe the problem with least privilege is that it requires that >>>> developers: >>>> >>>> 1. define the entire universe of subjects and objects >>>> 2. define all possible access rights >>>> 3. define all possible relationships >>>> 4. apply all settings >>>> 5. figure out how to keep 1-4 in synch all the time >>>> >>>> do all of this before you start writing code and oh and there are >>>> basically no tools that smooth the adoption of the above. >>>> >>>> i don't think us software security people are helping anybody out in >>>> 2008 by doing ritual incantations of a paper from the mid 70s that may >>>> or may not apply to modern computing and anyhow is riddled with ideas >>>> that have never been implemented in any large scale systems >>>> >>>> compare these two statements >>>> >>>> Statement 1. Saltzer and Schroeder: >>>> "f) Least privilege: Every program and every user of the system should >>>> operate using the least set of privileges necessary to complete the >>>> job. Primarily, this principle limits the damage that can result from >>>> an accident or error. It also reduces the number of potential >>>> interactions among privileged programs to the minimum for correct >>>> operation, so that unintentional, unwanted, or improper uses of >>>> privilege are less likely to occur. Thus, if a question arises related >>>> to misuse of a privilege, the number of programs that must be audited >>>> is minimized. Put another way, if a mechanism can provide "firewalls," >>>> the principle of least privilege provides a rationale for where to >>>> install the firewalls. The military security rule of "need-to-know" is >>>> an example of this principle." >>>> >>>> Statement 2. David Gelernter's Manifesto: >>>> "28. Metaphors have a profound effect on computing: the file-cabinet >>>> metaphor traps us in a "passive" instead of "active" view of >>>> information management that is fundamentally wrong for computers. >>>> >>>> 29. The rigid file and directory system you are stuck with on your Mac >>>> or PC was designed by programmers for programmers ? and is still a >>>> good system for programmers. It is no good for non-programmers. It >>>> never was, and was never intended to be. >>>> >>>> 30. If you have three pet dogs, give them names. If you have 10,000 >>>> head of cattle, don't bother. Nowadays the idea of giving a name to >>>> every file on your computer is ridiculous." >>>> >>>> Conclusion(gp): Least Privilege is the point where the practical >>>> matter of applying Saltzer and Schroeder's principles breaks down in >>>> modern systems. Its a deployment issue, and a matter of insufficient >>>> models and modes. >>>> >>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>> >>>> Remember the 1990s when there were all these search engines that >>>> required you tag up all the content and put it in hierarchical >>>> directories and so on? Well what happened? Google came along and ate >>>> their lunch. When the problem is information overload, telling >>>> everyone to go out and label everything is not gonna work. >>>> >>>> -gunnar >>>> >>>> >>>> >>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>> >>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>> blank stares) has been the case ever since the Java security days a >>>>> decade ago. One of the main challenges is that developers have a >>>>> hard time thinking about the principle of least privilege and its >>>>> implications regarding the capabilities they should request. Dinis >>>>> is brave to set such thinking as a target. I've settled (after ten >>>>> years) with getting developers just to utter the word "security." >>>>> >>>>> All together now..."security". >>>>> >>>>> gem >>>>> >>>>> company www.cigital.com >>>>> podcast www.cigital.com/silverbullet >>>>> blog www.cigital.com/justiceleague >>>>> book www.swsec.com >>>>> >>>>> >>>>> On 11/24/08 12:31 PM, "Mike Lyman" wrote: >>>>> >>>>> Dinis Cruz wrote: >>>>>> >>>>>> Don't get me wrong, this is a great document if one is interested in >>>>>> writing applications that use CAS (Code Access Security), I would >>>>>> love >>>>>> for this to be widely used. >>>>> >>>>> When we recommended recommending CAS during a review of the U.S. >>>>> Defense >>>>> Information System Agency's new Application Security and Development >>>>> Security Technical Implementation Guide earlier this year we were met >>>>> with what amounted to blank stares. (At least it seemed like that >>>>> since >>>>> it was a phone conference.) Some on the call understood it and agreed >>>>> with the recommendation but those hosting the call and doing the >>>>> writing >>>>> didn't seem to grasp it. It may be a while before we see too many >>>>> adopting this or requiring it for a while. >>>>> -- >>>>> >>>>> Mike Lyman >>>>> mlyman at west-point.org >>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com >>>>> ) >>>>> as a free, non-commercial service to the software security community. >>>>> _______________________________________________ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com >>>>> ) >>>>> as a free, non-commercial service to the software security community. >>>>> _______________________________________________ >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>> List information, subscriptions, etc - >>>> http://krvw.com/mailman/listinfo/sc-l >>>> List charter available at - http://www.securecoding.org/list/charter.php >>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>> (http://www.KRvW.com) >>>> as a free, non-commercial service to the software security community. >>>> _______________________________________________ >>>> >>> >> >> > From neumann at csl.sri.com Tue Nov 25 12:31:09 2008 From: neumann at csl.sri.com (Peter G. Neumann) Date: Tue, 25 Nov 2008 9:31:09 PST Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: Your message of Sat, 22 Nov 2008 17:24:32 -0500 Message-ID: And don't forget the Paul Karger paper from Oakland, which applies access controls to executables and effectively provides implementations for Saltzer-Schroeder's least privilege and more: @InProceedings{Karger87, Key="Karger", Author="P.A. Karger", Title="Limiting the Damage Potential of Discretionary {T}rojan Horses", BookTitle="Proceedings of the 1987 Symposium on Security and Privacy", Organization="IEEE Computer Society", Address="Oakland, California", Year="1987", Month="April", pages="32--37"} From gem at cigital.com Tue Nov 25 12:35:33 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 25 Nov 2008 12:35:33 -0500 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> Message-ID: Hi Stephen, I don't think I belong in the dog house with gunnar on this one (though if I have to share the dog house gunnar would be a decent compatriot). Please re-read my post and you will see that I "gave up" on the Dinis quest though I have lots of respect for what Dinis wants to accomplish. That said, I do believe in educating and training developers about software security. I also strongly agree with you that a software security initiative must involve management and technology leaders and not degenerate into "secure coding." These days my writings are aimed at leadership...see http://www.cigital.com/~gem/writings/ Just at the moment I am working hard on a maturity model for software security based on 9 top initiatives. Sammy Migues, Brian Chess, and I have uncovered some very amazing things in our "anthropology experiment" so far. We'll probably be set to share them by the end of the year. Anyway, sorry not to propagate the flame war without even donning an asbestos suit, but what can I say? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/25/08 12:28 PM, "Stephen Craig Evans" wrote: It's a real cop-out for you guys, as titans in the industry, to go after developers. I'm disappointed in both of you. And Gary, you said "One of the main challenges is that developers have a hard time thinking about the principle of least privilege ". Developers are NEVER asked to think about the principle of least privilege. Or your world of software security must be very very very different from mine (and I think my world at least equals yours but by about 2 billion people more, which might be irrelevant now but a little more relevant in the future :-) With the greatest, deepest respect to both of you, Stephen On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans wrote: > Gunnar, > > Developers have no power. You should be talking to the decision makers. > > As an example, to instill the importance of software security, I talk > to decision makers: project managers, architects, CTOs (admittedly, > this is a blurred line - lots of folks call themselves architects). If > I go to talk about software security to developers, I know from > experience that I am probably wasting my time. Even if they do care, > they have no effect overall. > > Your target and blame is wrong; that's all that I am saying. > > Stephen > > On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson > wrote: >> Sorry I didn't realize "developers" is an offensive ivory tower in other >> parts of the world, in my world its a compliment. >> >> -gunnar >> >> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >> >>> HI, >>> >>> "maybe the problem with least privilege is that it requires that >>> developers:..." >>> >>> IMHO, your US/UK ivory towers don't exist in other parts of the world. >>> Developers have no say in what they do. Nor, do they care about >>> software security and why should they care? >>> >>> So, at least, change your nomenclature and not say "developers". It >>> offends me because you are putting the onus of knowing about software >>> security on the wrong people. >>> >>> Cheers, >>> Stephen >>> >>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>> wrote: >>>> >>>> maybe the problem with least privilege is that it requires that >>>> developers: >>>> >>>> 1. define the entire universe of subjects and objects >>>> 2. define all possible access rights >>>> 3. define all possible relationships >>>> 4. apply all settings >>>> 5. figure out how to keep 1-4 in synch all the time >>>> >>>> do all of this before you start writing code and oh and there are >>>> basically no tools that smooth the adoption of the above. >>>> >>>> i don't think us software security people are helping anybody out in >>>> 2008 by doing ritual incantations of a paper from the mid 70s that may >>>> or may not apply to modern computing and anyhow is riddled with ideas >>>> that have never been implemented in any large scale systems >>>> >>>> compare these two statements >>>> >>>> Statement 1. Saltzer and Schroeder: >>>> "f) Least privilege: Every program and every user of the system should >>>> operate using the least set of privileges necessary to complete the >>>> job. Primarily, this principle limits the damage that can result from >>>> an accident or error. It also reduces the number of potential >>>> interactions among privileged programs to the minimum for correct >>>> operation, so that unintentional, unwanted, or improper uses of >>>> privilege are less likely to occur. Thus, if a question arises related >>>> to misuse of a privilege, the number of programs that must be audited >>>> is minimized. Put another way, if a mechanism can provide "firewalls," >>>> the principle of least privilege provides a rationale for where to >>>> install the firewalls. The military security rule of "need-to-know" is >>>> an example of this principle." >>>> >>>> Statement 2. David Gelernter's Manifesto: >>>> "28. Metaphors have a profound effect on computing: the file-cabinet >>>> metaphor traps us in a "passive" instead of "active" view of >>>> information management that is fundamentally wrong for computers. >>>> >>>> 29. The rigid file and directory system you are stuck with on your Mac >>>> or PC was designed by programmers for programmers - and is still a >>>> good system for programmers. It is no good for non-programmers. It >>>> never was, and was never intended to be. >>>> >>>> 30. If you have three pet dogs, give them names. If you have 10,000 >>>> head of cattle, don't bother. Nowadays the idea of giving a name to >>>> every file on your computer is ridiculous." >>>> >>>> Conclusion(gp): Least Privilege is the point where the practical >>>> matter of applying Saltzer and Schroeder's principles breaks down in >>>> modern systems. Its a deployment issue, and a matter of insufficient >>>> models and modes. >>>> >>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>> >>>> Remember the 1990s when there were all these search engines that >>>> required you tag up all the content and put it in hierarchical >>>> directories and so on? Well what happened? Google came along and ate >>>> their lunch. When the problem is information overload, telling >>>> everyone to go out and label everything is not gonna work. >>>> >>>> -gunnar >>>> >>>> >>>> >>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>> >>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>> blank stares) has been the case ever since the Java security days a >>>>> decade ago. One of the main challenges is that developers have a >>>>> hard time thinking about the principle of least privilege and its >>>>> implications regarding the capabilities they should request. Dinis >>>>> is brave to set such thinking as a target. I've settled (after ten >>>>> years) with getting developers just to utter the word "security." >>>>> >>>>> All together now..."security". >>>>> >>>>> gem >>>>> >>>>> company www.cigital.com >>>>> podcast www.cigital.com/silverbullet >>>>> blog www.cigital.com/justiceleague >>>>> book www.swsec.com >>>>> >>>>> >>>>> On 11/24/08 12:31 PM, "Mike Lyman" wrote: >>>>> >>>>> Dinis Cruz wrote: >>>>>> >>>>>> Don't get me wrong, this is a great document if one is interested in >>>>>> writing applications that use CAS (Code Access Security), I would >>>>>> love >>>>>> for this to be widely used. >>>>> >>>>> When we recommended recommending CAS during a review of the U.S. >>>>> Defense >>>>> Information System Agency's new Application Security and Development >>>>> Security Technical Implementation Guide earlier this year we were met >>>>> with what amounted to blank stares. (At least it seemed like that >>>>> since >>>>> it was a phone conference.) Some on the call understood it and agreed >>>>> with the recommendation but those hosting the call and doing the >>>>> writing >>>>> didn't seem to grasp it. It may be a while before we see too many >>>>> adopting this or requiring it for a while. >>>>> -- >>>>> >>>>> Mike Lyman >>>>> mlyman at west-point.org >>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com >>>>> ) >>>>> as a free, non-commercial service to the software security community. >>>>> _______________________________________________ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com >>>>> ) >>>>> as a free, non-commercial service to the software security community. >>>>> _______________________________________________ >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>> List information, subscriptions, etc - >>>> http://krvw.com/mailman/listinfo/sc-l >>>> List charter available at - http://www.securecoding.org/list/charter.php >>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>> (http://www.KRvW.com) >>>> as a free, non-commercial service to the software security community. >>>> _______________________________________________ >>>> >>> >> >> > From gunnar at arctecgroup.net Tue Nov 25 12:48:34 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 25 Nov 2008 11:48:34 -0600 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> Message-ID: look, i am a consultant. i work in lots of different companies. lots of different projects. i don't see these distinctions in black and white. sometimes the cto and managers are best positioned to help companies develop more secure software, sometimes architects, sometimes auditors, and many many times in my experience developers are best positioned. but i really, truly do not care who does it. my only goal is more effective security mechanisms and some pragmatic roadmap to get there. we are in the infancy of this industry (think automotive safety circa 1942, all seat belts and brakes), we are in no position to turn away help from anyone who can help. every company and every project is different, if your organization is set up so that developers are not empowered, but managers and CTOs are then by all means work with them. but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the "too hard" pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. -gunnar On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: > It's a real cop-out for you guys, as titans in the industry, to go > after developers. I'm disappointed in both of you. And Gary, you said > "One of the main challenges is that developers have a hard time > thinking about the principle of least privilege ". > > Developers are NEVER asked to think about the principle of least > privilege. Or your world of software security must be very very very > different from mine (and I think my world at least equals yours but > by about 2 billion people more, which might be irrelevant now but a > little more relevant in the future :-) > > With the greatest, deepest respect to both of you, > Stephen > > On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans > wrote: >> Gunnar, >> >> Developers have no power. You should be talking to the decision >> makers. >> >> As an example, to instill the importance of software security, I talk >> to decision makers: project managers, architects, CTOs (admittedly, >> this is a blurred line - lots of folks call themselves architects). >> If >> I go to talk about software security to developers, I know from >> experience that I am probably wasting my time. Even if they do care, >> they have no effect overall. >> >> Your target and blame is wrong; that's all that I am saying. >> >> Stephen >> >> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >> wrote: >>> Sorry I didn't realize "developers" is an offensive ivory tower in >>> other >>> parts of the world, in my world its a compliment. >>> >>> -gunnar >>> >>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>> >>>> HI, >>>> >>>> "maybe the problem with least privilege is that it requires that >>>> developers:..." >>>> >>>> IMHO, your US/UK ivory towers don't exist in other parts of the >>>> world. >>>> Developers have no say in what they do. Nor, do they care about >>>> software security and why should they care? >>>> >>>> So, at least, change your nomenclature and not say "developers". It >>>> offends me because you are putting the onus of knowing about >>>> software >>>> security on the wrong people. >>>> >>>> Cheers, >>>> Stephen >>>> >>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>> wrote: >>>>> >>>>> maybe the problem with least privilege is that it requires that >>>>> developers: >>>>> >>>>> 1. define the entire universe of subjects and objects >>>>> 2. define all possible access rights >>>>> 3. define all possible relationships >>>>> 4. apply all settings >>>>> 5. figure out how to keep 1-4 in synch all the time >>>>> >>>>> do all of this before you start writing code and oh and there are >>>>> basically no tools that smooth the adoption of the above. >>>>> >>>>> i don't think us software security people are helping anybody >>>>> out in >>>>> 2008 by doing ritual incantations of a paper from the mid 70s >>>>> that may >>>>> or may not apply to modern computing and anyhow is riddled with >>>>> ideas >>>>> that have never been implemented in any large scale systems >>>>> >>>>> compare these two statements >>>>> >>>>> Statement 1. Saltzer and Schroeder: >>>>> "f) Least privilege: Every program and every user of the system >>>>> should >>>>> operate using the least set of privileges necessary to complete >>>>> the >>>>> job. Primarily, this principle limits the damage that can result >>>>> from >>>>> an accident or error. It also reduces the number of potential >>>>> interactions among privileged programs to the minimum for correct >>>>> operation, so that unintentional, unwanted, or improper uses of >>>>> privilege are less likely to occur. Thus, if a question arises >>>>> related >>>>> to misuse of a privilege, the number of programs that must be >>>>> audited >>>>> is minimized. Put another way, if a mechanism can provide >>>>> "firewalls," >>>>> the principle of least privilege provides a rationale for where to >>>>> install the firewalls. The military security rule of "need-to- >>>>> know" is >>>>> an example of this principle." >>>>> >>>>> Statement 2. David Gelernter's Manifesto: >>>>> "28. Metaphors have a profound effect on computing: the file- >>>>> cabinet >>>>> metaphor traps us in a "passive" instead of "active" view of >>>>> information management that is fundamentally wrong for computers. >>>>> >>>>> 29. The rigid file and directory system you are stuck with on >>>>> your Mac >>>>> or PC was designed by programmers for programmers ? and is still a >>>>> good system for programmers. It is no good for non-programmers. It >>>>> never was, and was never intended to be. >>>>> >>>>> 30. If you have three pet dogs, give them names. If you have >>>>> 10,000 >>>>> head of cattle, don't bother. Nowadays the idea of giving a name >>>>> to >>>>> every file on your computer is ridiculous." >>>>> >>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>> matter of applying Saltzer and Schroeder's principles breaks >>>>> down in >>>>> modern systems. Its a deployment issue, and a matter of >>>>> insufficient >>>>> models and modes. >>>>> >>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>>> >>>>> Remember the 1990s when there were all these search engines that >>>>> required you tag up all the content and put it in hierarchical >>>>> directories and so on? Well what happened? Google came along and >>>>> ate >>>>> their lunch. When the problem is information overload, telling >>>>> everyone to go out and label everything is not gonna work. >>>>> >>>>> -gunnar >>>>> >>>>> >>>>> >>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>> >>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>> blank stares) has been the case ever since the Java security >>>>>> days a >>>>>> decade ago. One of the main challenges is that developers have a >>>>>> hard time thinking about the principle of least privilege and its >>>>>> implications regarding the capabilities they should request. >>>>>> Dinis >>>>>> is brave to set such thinking as a target. I've settled (after >>>>>> ten >>>>>> years) with getting developers just to utter the word "security." >>>>>> >>>>>> All together now..."security". >>>>>> >>>>>> gem >>>>>> >>>>>> company www.cigital.com >>>>>> podcast www.cigital.com/silverbullet >>>>>> blog www.cigital.com/justiceleague >>>>>> book www.swsec.com >>>>>> >>>>>> >>>>>> On 11/24/08 12:31 PM, "Mike Lyman" >>>>>> wrote: >>>>>> >>>>>> Dinis Cruz wrote: >>>>>>> >>>>>>> Don't get me wrong, this is a great document if one is >>>>>>> interested in >>>>>>> writing applications that use CAS (Code Access Security), I >>>>>>> would >>>>>>> love >>>>>>> for this to be widely used. >>>>>> >>>>>> When we recommended recommending CAS during a review of the U.S. >>>>>> Defense >>>>>> Information System Agency's new Application Security and >>>>>> Development >>>>>> Security Technical Implementation Guide earlier this year we >>>>>> were met >>>>>> with what amounted to blank stares. (At least it seemed like that >>>>>> since >>>>>> it was a phone conference.) Some on the call understood it and >>>>>> agreed >>>>>> with the recommendation but those hosting the call and doing the >>>>>> writing >>>>>> didn't seem to grasp it. It may be a while before we see too many >>>>>> adopting this or requiring it for a while. >>>>>> -- >>>>>> >>>>>> Mike Lyman >>>>>> mlyman at west-point.org >>>>>> >>>>>> _______________________________________________ >>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>> List information, subscriptions, etc - >>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>> (http://www.KRvW.com >>>>>> ) >>>>>> as a free, non-commercial service to the software security >>>>>> community. >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>> List information, subscriptions, etc - >>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>> (http://www.KRvW.com >>>>>> ) >>>>>> as a free, non-commercial service to the software security >>>>>> community. >>>>>> _______________________________________________ >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com) >>>>> as a free, non-commercial service to the software security >>>>> community. >>>>> _______________________________________________ >>>>> >>>> >>> >>> >> > From John.Wilander at omegapoint.se Tue Nov 25 12:47:36 2008 From: John.Wilander at omegapoint.se (John Wilander) Date: Tue, 25 Nov 2008 18:47:36 +0100 Subject: [SC-L] The problem with (Java's) Security Policy (Was: Unclassified NSA document on .NET 2.0 Framework Security) In-Reply-To: Message-ID: Hi all! I agree with Gunnar on this one. 2008-11-25 18.00, Gunnar Peterson wrote: > maybe the problem with least privilege is that it requires that > developers: > > 1. define the entire universe of subjects and objects > 2. define all possible access rights > 3. define all possible relationships > 4. apply all settings > 5. figure out how to keep 1-4 in synch all the time > > do all of this before you start writing code and oh and there are > basically no tools that smooth the adoption of the above. > > i don't think us software security people are helping anybody out in > 2008 by doing ritual incantations of a paper from the mid 70s that may > or may not apply to modern computing and anyhow is riddled with ideas > that have never been implemented in any large scale systems To the best of my knowledge the security policy framework for Java is more or less unused. Why? Because it's designed for static, once-in-a-lifetime releases of software. Writing the policy manually is infeasible so you need to ... 1. Instrument the code to output what permissions it needs. Typically with a custom SecurityManager that logs all checkPermission() calls. See the paper reference at the end of this email for more info. 2. Drive the application with your testbed to actually get the policy output. Your test cases won't cover all application code so you'll surely miss policy statements. Threading will be a headache here - you need to propagate the security context to all running threads so they all output their needed permissions. 3. Then you need to filter out what policy statements actually come from your application and not from your application server. That's quite easy based on the package names. 4. The next step is to collapse the resulting gigantic policy to something readable, e.g. merging individual file permissions to cover whole folders. A lot of parsing and ad hoc rules applied here. You have to write the collapsing code yourself. Not too nice. 5. Now you need to _review_ the generated policy so that it's compliant with the desired permissions of the application. Any suspicious policy statements will need to be investigated. This is a good driver for code review but that's another question. Code changes because of unwanted permissions means starting all over. 6. Then you merge it with the policy file for the application server. There is one, huh? 7. You dig into the application server documentation to sort out policy deployment. 9. System and acceptance testing. You might notice that the server's own policy doesn't work (server refuses to start). Why? It hasn't been maintained since nobody uses it. Good luck on updating that one. Here the missed policy statements from 2 hopefully will be found as security exceptions. Update testbed and re-iterate the whole process. 10. Time to ship. Off you go! 11. Darn! We need to patch a few things and release version 1.3.1. Guys, we need to start all over again with the policy. Anyone up for it? If I'm totally wrong please tell me what to do. I'd really like to deploy maintainable security policies. Mark Petrovic has written some good things on this issue (http://www.onjava.com/pub/a/onjava/2007/01/03/discovering-java-security-req uirements.html). Regards, John Wilander -- John Wilander, Security Architect www.omegapoint.se From coley at linus.mitre.org Tue Nov 25 12:56:58 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 25 Nov 2008 12:56:58 -0500 (EST) Subject: [SC-L] Software Assist to Find Least Privilege In-Reply-To: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> References: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> Message-ID: On Tue, 25 Nov 2008, Mark Rockman wrote: > Assuming this is repeated for every use case, the resulting > reports would be a very good guide to how CAS settings should be > established for production. Of course, everytime the program is changed > in any way, the process would have to be repeated. Better - and absoutely unachievable any time soon - would be for the application itself to more explicitly state what its requirements of the OS are, and what its intended behaviors are. Kind of like SELinux but simpler. More easily said than done, but until we develop richer models for representing what an application's legitimate behaviors are, then automated detection of these types of issues are likely to be difficult. - Steve From ljknews at mac.com Tue Nov 25 13:00:33 2008 From: ljknews at mac.com (ljknews) Date: Tue, 25 Nov 2008 14:00:33 -0400 Subject: [SC-L] Software Assist to Find Least Privilege In-Reply-To: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> References: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> Message-ID: At 12:26 PM -0500 11/25/08, Mark Rockman wrote: > It be difficult to determine a priori the settings for all the access >control lists and other security parameters that one must establish for >CAS to work. Perhaps a software assist would work according to the >following scenario. Run the program in the environment in which it will >actually be used. Assume minimal permissions. Each time the program >would fail due to violation of some permission, notate the event and plow >on. Assuming this is repeated for every use case, the resulting reports >would be a very good guide to how CAS settings should be established for >production. Of course, everytime the program is changed in any way, the >process would have to be repeated. The approach my company recommends is intended to minimize any possible impact on existing operations (we deal exclusively with existing installations). 1) Enable auditing for use of privilege. 2) Wait for a period of normal operation (time period depends on the nature of the business). 3) Remove privileges from any user who never used a particular privilege. Of course that must be accompanied by an aggressive policy of requiring justification of every assignment of privilege to an individual. In many cases, permissions have been given for an individual to modify particular data when in fact they should only be authorized to do that when using a particular program. Tightening that up uses a mechanism whose name will vary depending on the operating system in use, but it is bound to require modification and security analysis of applications. The context in which we are recommending this is typically where external security requirements are suddenly raised, e.g. 800-53a, PCI DSS, 8500.2. -- Larry Kilgallen From gem at cigital.com Tue Nov 25 13:10:17 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 25 Nov 2008 13:10:17 -0500 Subject: [SC-L] Software Assist to Find Least Privilege In-Reply-To: Message-ID: It seems we've come full circle, because what you are describing is managed code (or privileged code depending on your Java vs .NET vocabulary). In full on managed code, the code describes what it needs and the machine decides whether that coheres with local policy. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/25/08 12:56 PM, "Steven M. Christey" wrote: On Tue, 25 Nov 2008, Mark Rockman wrote: > Assuming this is repeated for every use case, the resulting > reports would be a very good guide to how CAS settings should be > established for production. Of course, everytime the program is changed > in any way, the process would have to be repeated. Better - and absoutely unachievable any time soon - would be for the application itself to more explicitly state what its requirements of the OS are, and what its intended behaviors are. Kind of like SELinux but simpler. More easily said than done, but until we develop richer models for representing what an application's legitimate behaviors are, then automated detection of these types of issues are likely to be difficult. - Steve _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From sbradcpa at pacbell.net Tue Nov 25 13:03:22 2008 From: sbradcpa at pacbell.net (Susan Bradley, CPA ) Date: Tue, 25 Nov 2008 10:03:22 -0800 Subject: [SC-L] Software Assist to Find Least Privilege In-Reply-To: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> References: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> Message-ID: <492C3DEA.9080708@pacbell.net> Aaron Margosis' "Non-Admin" WebLog : LUA Buglight 2.0, second preview: http://blogs.msdn.com/aaron_margosis/archive/2008/11/06/lua-buglight-2-0-second-preview.aspx Mark Rockman wrote: > It be difficult to determine /a priori/ the settings for all the > access control lists and other security parameters that one must > establish for CAS to work. Perhaps a software assist would work > according to the following scenario. Run the program in the > environment in which it will actually be used. Assume minimal > permissions. Each time the program would fail due to violation of > some permission, notate the event and plow on. Assuming this is > repeated for every use case, the resulting reports would be a very > good guide to how CAS settings should be established for production. > Of course, everytime the program is changed in any way, the process > would have to be repeated. > > MARK ROCKMAN > MDRSESCO LLC > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From sbradcpa at pacbell.net Tue Nov 25 12:58:12 2008 From: sbradcpa at pacbell.net (Susan Bradley, CPA ) Date: Tue, 25 Nov 2008 09:58:12 -0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> Message-ID: <492C3CB4.7040403@pacbell.net> Why shouldn't they be asked to think about it? Especially now. I do. I install Vista and find out how many of my apps don't like it. Go grab a copy of Luabuglight and watch Aaron Margosis' stuff. Why should I as an Admin have to care about this stuff after Developers that don't care about it code software? Okay yeah so the management has to have the religion of it but if developers at their core do not care then IMHO I as a consumer of code need to ensure that they do. You can't add it on afterwards, so if the developers doing the coding do not care because ultimately management does not, we still have a fundamental problem in the software industry. Dana Epp's ramblings at the Sanctuary: Introduction to Microsoft's SDL Threat Modeling Tool: http://silverstr.ufies.org/blog/archives/001060.html He's a developer and he cares. And he definitely cares about least priv and ensure that his code doesn't ask anything that it shouldn't. Stephen Craig Evans wrote: > It's a real cop-out for you guys, as titans in the industry, to go > after developers. I'm disappointed in both of you. And Gary, you said > "One of the main challenges is that developers have a hard time > thinking about the principle of least privilege ". > > Developers are NEVER asked to think about the principle of least > privilege. Or your world of software security must be very very very > different from mine (and I think my world at least equals yours but > by about 2 billion people more, which might be irrelevant now but a > little more relevant in the future :-) > > With the greatest, deepest respect to both of you, > Stephen > > On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans > wrote: > >> Gunnar, >> >> Developers have no power. You should be talking to the decision makers. >> >> As an example, to instill the importance of software security, I talk >> to decision makers: project managers, architects, CTOs (admittedly, >> this is a blurred line - lots of folks call themselves architects). If >> I go to talk about software security to developers, I know from >> experience that I am probably wasting my time. Even if they do care, >> they have no effect overall. >> >> Your target and blame is wrong; that's all that I am saying. >> >> Stephen >> >> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >> wrote: >> >>> Sorry I didn't realize "developers" is an offensive ivory tower in other >>> parts of the world, in my world its a compliment. >>> >>> -gunnar >>> >>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>> >>> >>>> HI, >>>> >>>> "maybe the problem with least privilege is that it requires that >>>> developers:..." >>>> >>>> IMHO, your US/UK ivory towers don't exist in other parts of the world. >>>> Developers have no say in what they do. Nor, do they care about >>>> software security and why should they care? >>>> >>>> So, at least, change your nomenclature and not say "developers". It >>>> offends me because you are putting the onus of knowing about software >>>> security on the wrong people. >>>> >>>> Cheers, >>>> Stephen >>>> >>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>> wrote: >>>> >>>>> maybe the problem with least privilege is that it requires that >>>>> developers: >>>>> >>>>> 1. define the entire universe of subjects and objects >>>>> 2. define all possible access rights >>>>> 3. define all possible relationships >>>>> 4. apply all settings >>>>> 5. figure out how to keep 1-4 in synch all the time >>>>> >>>>> do all of this before you start writing code and oh and there are >>>>> basically no tools that smooth the adoption of the above. >>>>> >>>>> i don't think us software security people are helping anybody out in >>>>> 2008 by doing ritual incantations of a paper from the mid 70s that may >>>>> or may not apply to modern computing and anyhow is riddled with ideas >>>>> that have never been implemented in any large scale systems >>>>> >>>>> compare these two statements >>>>> >>>>> Statement 1. Saltzer and Schroeder: >>>>> "f) Least privilege: Every program and every user of the system should >>>>> operate using the least set of privileges necessary to complete the >>>>> job. Primarily, this principle limits the damage that can result from >>>>> an accident or error. It also reduces the number of potential >>>>> interactions among privileged programs to the minimum for correct >>>>> operation, so that unintentional, unwanted, or improper uses of >>>>> privilege are less likely to occur. Thus, if a question arises related >>>>> to misuse of a privilege, the number of programs that must be audited >>>>> is minimized. Put another way, if a mechanism can provide "firewalls," >>>>> the principle of least privilege provides a rationale for where to >>>>> install the firewalls. The military security rule of "need-to-know" is >>>>> an example of this principle." >>>>> >>>>> Statement 2. David Gelernter's Manifesto: >>>>> "28. Metaphors have a profound effect on computing: the file-cabinet >>>>> metaphor traps us in a "passive" instead of "active" view of >>>>> information management that is fundamentally wrong for computers. >>>>> >>>>> 29. The rigid file and directory system you are stuck with on your Mac >>>>> or PC was designed by programmers for programmers ? and is still a >>>>> good system for programmers. It is no good for non-programmers. It >>>>> never was, and was never intended to be. >>>>> >>>>> 30. If you have three pet dogs, give them names. If you have 10,000 >>>>> head of cattle, don't bother. Nowadays the idea of giving a name to >>>>> every file on your computer is ridiculous." >>>>> >>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>> matter of applying Saltzer and Schroeder's principles breaks down in >>>>> modern systems. Its a deployment issue, and a matter of insufficient >>>>> models and modes. >>>>> >>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>>> >>>>> Remember the 1990s when there were all these search engines that >>>>> required you tag up all the content and put it in hierarchical >>>>> directories and so on? Well what happened? Google came along and ate >>>>> their lunch. When the problem is information overload, telling >>>>> everyone to go out and label everything is not gonna work. >>>>> >>>>> -gunnar >>>>> >>>>> >>>>> >>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>> >>>>> >>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>> blank stares) has been the case ever since the Java security days a >>>>>> decade ago. One of the main challenges is that developers have a >>>>>> hard time thinking about the principle of least privilege and its >>>>>> implications regarding the capabilities they should request. Dinis >>>>>> is brave to set such thinking as a target. I've settled (after ten >>>>>> years) with getting developers just to utter the word "security." >>>>>> >>>>>> All together now..."security". >>>>>> >>>>>> gem >>>>>> >>>>>> company www.cigital.com >>>>>> podcast www.cigital.com/silverbullet >>>>>> blog www.cigital.com/justiceleague >>>>>> book www.swsec.com >>>>>> >>>>>> >>>>>> On 11/24/08 12:31 PM, "Mike Lyman" wrote: >>>>>> >>>>>> Dinis Cruz wrote: >>>>>> >>>>>>> Don't get me wrong, this is a great document if one is interested in >>>>>>> writing applications that use CAS (Code Access Security), I would >>>>>>> love >>>>>>> for this to be widely used. >>>>>>> >>>>>> When we recommended recommending CAS during a review of the U.S. >>>>>> Defense >>>>>> Information System Agency's new Application Security and Development >>>>>> Security Technical Implementation Guide earlier this year we were met >>>>>> with what amounted to blank stares. (At least it seemed like that >>>>>> since >>>>>> it was a phone conference.) Some on the call understood it and agreed >>>>>> with the recommendation but those hosting the call and doing the >>>>>> writing >>>>>> didn't seem to grasp it. It may be a while before we see too many >>>>>> adopting this or requiring it for a while. >>>>>> -- >>>>>> >>>>>> Mike Lyman >>>>>> mlyman at west-point.org >>>>>> >>>>>> _______________________________________________ >>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>> List information, subscriptions, etc - >>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>> (http://www.KRvW.com >>>>>> ) >>>>>> as a free, non-commercial service to the software security community. >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>> List information, subscriptions, etc - >>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>> (http://www.KRvW.com >>>>>> ) >>>>>> as a free, non-commercial service to the software security community. >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com) >>>>> as a free, non-commercial service to the software security community. >>>>> _______________________________________________ >>>>> >>>>> >>> > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From gunnar at arctecgroup.net Tue Nov 25 13:24:22 2008 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 25 Nov 2008 12:24:22 -0600 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811251007o68d64c93wa064261b6bfd1790@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> <930fd0230811251007o68d64c93wa064261b6bfd1790@mail.gmail.com> Message-ID: <1DA1808C-395A-4259-89DF-A31599D5F415@arctecgroup.net> stephen i spend at least half my time working directly with developers. for some reason i have not communicated as well as i should to you, what i am saying is that the job is too hard for developers *because* the security industry has let them down by sending them on a fool's errand of least privilege. the problem or target in your words IS with security people NOT developers. they have other problems just not an endless quixotic quest for least privilege. i am not repeat not throwing developers under the bus in this argument. i am ready, willing and possibly able to be proven wrong on this point and maybe there is a cost effective way to deploy least privilege in the real world just want to make sure that i communicate my argument. -gunnar (who is now letting go) On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: > I can't let this go. > > Gary, you are self-professed working with financial institutions and > high-end customers. > > Gunnar, you are the same, at least what I gather from your Silver > Bullet podcast when talking about the difference between SOA (top > down) and Web 2.0 (bottom up). > > No flame war intended, but a healthy discussion should be in order. > > So please don't talk about "developers" as targets. They/we are the > lowest on the totem pole. Direct your arrows at the people that you > deal with. Plain and simple. > > Cheers, > Stephen > > On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson > wrote: >> look, i am a consultant. i work in lots of different companies. >> lots of >> different projects. i don't see these distinctions in black and >> white. >> sometimes the cto and managers are best positioned to help >> companies develop >> more secure software, sometimes architects, sometimes auditors, and >> many >> many times in my experience developers are best positioned. >> >> but i really, truly do not care who does it. my only goal is more >> effective >> security mechanisms and some pragmatic roadmap to get there. we are >> in the >> infancy of this industry (think automotive safety circa 1942, all >> seat belts >> and brakes), we are in no position to turn away help from anyone >> who can >> help. every company and every project is different, if your >> organization is >> set up so that developers are not empowered, but managers and CTOs >> are then >> by all means work with them. >> >> but actually the main point of my post and the one i would like to >> hear >> people's thoughts on - is to say that attempting to apply principle >> of least >> privilege in the real world often leads to drilling dry wells. i am >> not >> blaming any group in particular i am saying i think it is in the >> "too hard" >> pile for now and we as software security people should not be >> advocating for >> it until or unless we can find cost effective ways to implement it. >> >> -gunnar >> >> On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: >> >>> It's a real cop-out for you guys, as titans in the industry, to go >>> after developers. I'm disappointed in both of you. And Gary, you >>> said >>> "One of the main challenges is that developers have a hard time >>> thinking about the principle of least privilege ". >>> >>> Developers are NEVER asked to think about the principle of least >>> privilege. Or your world of software security must be very very very >>> different from mine (and I think my world at least equals yours >>> but >>> by about 2 billion people more, which might be irrelevant now but a >>> little more relevant in the future :-) >>> >>> With the greatest, deepest respect to both of you, >>> Stephen >>> >>> On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans >>> wrote: >>>> >>>> Gunnar, >>>> >>>> Developers have no power. You should be talking to the decision >>>> makers. >>>> >>>> As an example, to instill the importance of software security, I >>>> talk >>>> to decision makers: project managers, architects, CTOs (admittedly, >>>> this is a blurred line - lots of folks call themselves >>>> architects). If >>>> I go to talk about software security to developers, I know from >>>> experience that I am probably wasting my time. Even if they do >>>> care, >>>> they have no effect overall. >>>> >>>> Your target and blame is wrong; that's all that I am saying. >>>> >>>> Stephen >>>> >>>> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >>>> wrote: >>>>> >>>>> Sorry I didn't realize "developers" is an offensive ivory tower >>>>> in other >>>>> parts of the world, in my world its a compliment. >>>>> >>>>> -gunnar >>>>> >>>>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>>>> >>>>>> HI, >>>>>> >>>>>> "maybe the problem with least privilege is that it requires that >>>>>> developers:..." >>>>>> >>>>>> IMHO, your US/UK ivory towers don't exist in other parts of the >>>>>> world. >>>>>> Developers have no say in what they do. Nor, do they care about >>>>>> software security and why should they care? >>>>>> >>>>>> So, at least, change your nomenclature and not say >>>>>> "developers". It >>>>>> offends me because you are putting the onus of knowing about >>>>>> software >>>>>> security on the wrong people. >>>>>> >>>>>> Cheers, >>>>>> Stephen >>>>>> >>>>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>>>> wrote: >>>>>>> >>>>>>> maybe the problem with least privilege is that it requires that >>>>>>> developers: >>>>>>> >>>>>>> 1. define the entire universe of subjects and objects >>>>>>> 2. define all possible access rights >>>>>>> 3. define all possible relationships >>>>>>> 4. apply all settings >>>>>>> 5. figure out how to keep 1-4 in synch all the time >>>>>>> >>>>>>> do all of this before you start writing code and oh and there >>>>>>> are >>>>>>> basically no tools that smooth the adoption of the above. >>>>>>> >>>>>>> i don't think us software security people are helping anybody >>>>>>> out in >>>>>>> 2008 by doing ritual incantations of a paper from the mid 70s >>>>>>> that may >>>>>>> or may not apply to modern computing and anyhow is riddled >>>>>>> with ideas >>>>>>> that have never been implemented in any large scale systems >>>>>>> >>>>>>> compare these two statements >>>>>>> >>>>>>> Statement 1. Saltzer and Schroeder: >>>>>>> "f) Least privilege: Every program and every user of the >>>>>>> system should >>>>>>> operate using the least set of privileges necessary to >>>>>>> complete the >>>>>>> job. Primarily, this principle limits the damage that can >>>>>>> result from >>>>>>> an accident or error. It also reduces the number of potential >>>>>>> interactions among privileged programs to the minimum for >>>>>>> correct >>>>>>> operation, so that unintentional, unwanted, or improper uses of >>>>>>> privilege are less likely to occur. Thus, if a question arises >>>>>>> related >>>>>>> to misuse of a privilege, the number of programs that must be >>>>>>> audited >>>>>>> is minimized. Put another way, if a mechanism can provide >>>>>>> "firewalls," >>>>>>> the principle of least privilege provides a rationale for >>>>>>> where to >>>>>>> install the firewalls. The military security rule of "need-to- >>>>>>> know" is >>>>>>> an example of this principle." >>>>>>> >>>>>>> Statement 2. David Gelernter's Manifesto: >>>>>>> "28. Metaphors have a profound effect on computing: the file- >>>>>>> cabinet >>>>>>> metaphor traps us in a "passive" instead of "active" view of >>>>>>> information management that is fundamentally wrong for >>>>>>> computers. >>>>>>> >>>>>>> 29. The rigid file and directory system you are stuck with on >>>>>>> your Mac >>>>>>> or PC was designed by programmers for programmers ? and is >>>>>>> still a >>>>>>> good system for programmers. It is no good for non- >>>>>>> programmers. It >>>>>>> never was, and was never intended to be. >>>>>>> >>>>>>> 30. If you have three pet dogs, give them names. If you have >>>>>>> 10,000 >>>>>>> head of cattle, don't bother. Nowadays the idea of giving a >>>>>>> name to >>>>>>> every file on your computer is ridiculous." >>>>>>> >>>>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>>>> matter of applying Saltzer and Schroeder's principles breaks >>>>>>> down in >>>>>>> modern systems. Its a deployment issue, and a matter of >>>>>>> insufficient >>>>>>> models and modes. >>>>>>> >>>>>>> >>>>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>>>>> >>>>>>> Remember the 1990s when there were all these search engines that >>>>>>> required you tag up all the content and put it in hierarchical >>>>>>> directories and so on? Well what happened? Google came along >>>>>>> and ate >>>>>>> their lunch. When the problem is information overload, telling >>>>>>> everyone to go out and label everything is not gonna work. >>>>>>> >>>>>>> -gunnar >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>>>> >>>>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>>>> blank stares) has been the case ever since the Java security >>>>>>>> days a >>>>>>>> decade ago. One of the main challenges is that developers >>>>>>>> have a >>>>>>>> hard time thinking about the principle of least privilege and >>>>>>>> its >>>>>>>> implications regarding the capabilities they should request. >>>>>>>> Dinis >>>>>>>> is brave to set such thinking as a target. I've settled >>>>>>>> (after ten >>>>>>>> years) with getting developers just to utter the word >>>>>>>> "security." >>>>>>>> >>>>>>>> All together now..."security". >>>>>>>> >>>>>>>> gem >>>>>>>> >>>>>>>> company www.cigital.com >>>>>>>> podcast www.cigital.com/silverbullet >>>>>>>> blog www.cigital.com/justiceleague >>>>>>>> book www.swsec.com >>>>>>>> >>>>>>>> >>>>>>>> On 11/24/08 12:31 PM, "Mike Lyman" >>>>>>>> wrote: >>>>>>>> >>>>>>>> Dinis Cruz wrote: >>>>>>>>> >>>>>>>>> Don't get me wrong, this is a great document if one is >>>>>>>>> interested in >>>>>>>>> writing applications that use CAS (Code Access Security), I >>>>>>>>> would >>>>>>>>> love >>>>>>>>> for this to be widely used. >>>>>>>> >>>>>>>> When we recommended recommending CAS during a review of the >>>>>>>> U.S. >>>>>>>> Defense >>>>>>>> Information System Agency's new Application Security and >>>>>>>> Development >>>>>>>> Security Technical Implementation Guide earlier this year we >>>>>>>> were met >>>>>>>> with what amounted to blank stares. (At least it seemed like >>>>>>>> that >>>>>>>> since >>>>>>>> it was a phone conference.) Some on the call understood it >>>>>>>> and agreed >>>>>>>> with the recommendation but those hosting the call and doing >>>>>>>> the >>>>>>>> writing >>>>>>>> didn't seem to grasp it. It may be a while before we see too >>>>>>>> many >>>>>>>> adopting this or requiring it for a while. >>>>>>>> -- >>>>>>>> >>>>>>>> Mike Lyman >>>>>>>> mlyman at west-point.org >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>> List information, subscriptions, etc - >>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>> List charter available at - >>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>> (http://www.KRvW.com >>>>>>>> ) >>>>>>>> as a free, non-commercial service to the software security >>>>>>>> community. >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>> List information, subscriptions, etc - >>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>> List charter available at - >>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>> (http://www.KRvW.com >>>>>>>> ) >>>>>>>> as a free, non-commercial service to the software security >>>>>>>> community. >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>> List information, subscriptions, etc - >>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>> List charter available at - >>>>>>> http://www.securecoding.org/list/charter.php >>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>> (http://www.KRvW.com) >>>>>>> as a free, non-commercial service to the software security >>>>>>> community. >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > From rklists at gmail.com Tue Nov 25 13:30:24 2008 From: rklists at gmail.com (Rohit Lists) Date: Tue, 25 Nov 2008 13:30:24 -0500 Subject: [SC-L] The problem with (Java's) Security Policy (Was: Unclassified NSA document on .NET 2.0 Framework Security) In-Reply-To: References: Message-ID: Has anyone had experience using Sword4J to determine permissions? http://www.alphaworks.ibm.com/tech/sword4j >From the site: "The Authorization Analysis functionality determines which authorizations are needed in order to run Java code when a SecurityManager is enabled. The Privilege Code Analysis functionality identifies which portions of code could be made privileged." On Tue, Nov 25, 2008 at 12:47 PM, John Wilander wrote: > Hi all! > > I agree with Gunnar on this one. > > 2008-11-25 18.00, Gunnar Peterson wrote: > >> maybe the problem with least privilege is that it requires that >> developers: >> >> 1. define the entire universe of subjects and objects >> 2. define all possible access rights >> 3. define all possible relationships >> 4. apply all settings >> 5. figure out how to keep 1-4 in synch all the time >> >> do all of this before you start writing code and oh and there are >> basically no tools that smooth the adoption of the above. >> >> i don't think us software security people are helping anybody out in >> 2008 by doing ritual incantations of a paper from the mid 70s that may >> or may not apply to modern computing and anyhow is riddled with ideas >> that have never been implemented in any large scale systems > > To the best of my knowledge the security policy framework for Java is more > or less unused. Why? Because it's designed for static, once-in-a-lifetime > releases of software. > > Writing the policy manually is infeasible so you need to ... > > 1. Instrument the code to output what permissions it needs. Typically with a > custom SecurityManager that logs all checkPermission() calls. See the paper > reference at the end of this email for more info. > > 2. Drive the application with your testbed to actually get the policy > output. Your test cases won't cover all application code so you'll surely > miss policy statements. Threading will be a headache here - you need to > propagate the security context to all running threads so they all output > their needed permissions. > > 3. Then you need to filter out what policy statements actually come from > your application and not from your application server. That's quite easy > based on the package names. > > 4. The next step is to collapse the resulting gigantic policy to something > readable, e.g. merging individual file permissions to cover whole folders. A > lot of parsing and ad hoc rules applied here. You have to write the > collapsing code yourself. Not too nice. > > 5. Now you need to _review_ the generated policy so that it's compliant with > the desired permissions of the application. Any suspicious policy statements > will need to be investigated. This is a good driver for code review but > that's another question. Code changes because of unwanted permissions means > starting all over. > > 6. Then you merge it with the policy file for the application server. There > is one, huh? > > 7. You dig into the application server documentation to sort out policy > deployment. > > 9. System and acceptance testing. You might notice that the server's own > policy doesn't work (server refuses to start). Why? It hasn't been > maintained since nobody uses it. Good luck on updating that one. Here the > missed policy statements from 2 hopefully will be found as security > exceptions. Update testbed and re-iterate the whole process. > > 10. Time to ship. Off you go! > > 11. Darn! We need to patch a few things and release version 1.3.1. Guys, we > need to start all over again with the policy. Anyone up for it? > > > If I'm totally wrong please tell me what to do. I'd really like to deploy > maintainable security policies. Mark Petrovic has written some good things > on this issue > (http://www.onjava.com/pub/a/onjava/2007/01/03/discovering-java-security-req > uirements.html). > > Regards, John Wilander > > -- > John Wilander, Security Architect > www.omegapoint.se > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Rohit Sethi Security Compass http://www.securitycompass.com From steingra at gmail.com Tue Nov 25 13:57:14 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Tue, 25 Nov 2008 10:57:14 -0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> Message-ID: <490a979e0811251057x100055fey1e9c67e2daa0bbdc@mail.gmail.com> On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson wrote: > > but actually the main point of my post and the one i would like to > hear people's thoughts on - is to say that attempting to apply > principle of least privilege in the real world often leads to drilling > dry wells. i am not blaming any group in particular i am saying i > think it is in the "too hard" pile for now and we as software security > people should not be advocating for it until or unless we can find > cost effective ways to implement it. > > I'd love to hear someone from Microsoft talk about the creation of default ready for shipping service security profiles for Server-2008. Windows has lots of services and lots of privileges that can be configured. Every paper I've generally seen on the subject is about reverse engineering least privileges by reducing them, checking whether the software still functions, looking for access violations, and then increasing the privileges until things start working. A lot like this Calvin and Hobbes comic: CALVIN: How do they know the load limit on bridges, Dad? DAD: They drive bigger and bigger trucks over the bridge until it breaks. Then they weigh the last truck and rebuild the bridge. This is what we do with least privilege, but without ever knowing whether we've really gotten the least privileges, or not. Hell, in a modern operating system how the hell do you figure this out anyway? - Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081125/b06b91e3/attachment.html From Brian.A.Shea at bankofamerica.com Tue Nov 25 14:07:07 2008 From: Brian.A.Shea at bankofamerica.com (Shea, Brian A) Date: Tue, 25 Nov 2008 11:07:07 -0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> Message-ID: Security is a tradeoff game between risk and cost in my experience. So the "least privilege" question comes down to practical matters like knowing the execution environment, knowing the requirements of the tasks being executed, and knowing where those intersect with the ability of the user or application security context to provide or request those rights. If I'm executing with high privilege on only one box vs being run on 10000 am I providing least privilege? If I am running at scale with limited rights covering all use cases vs with minimum rights and require user prompts or action to gain elevation when a rare use case requires it am I least privilege? The answer in my experience has not been a black and white, binary decision, but rather a trade off where the risk to the environment / data is evaluated against the cost to provide higher security, or the cost of added user interaction / inconvenience. In this way the definition of "least privilege" is comparable to one a judge once gave for pornography; "I'll know it when I see it". Put a different way, least privilege can ONLY be applied when you know all of the details of a specific instance of a system, and not across all instances of a system. Sort of like the Heisenberg Uncertainly Principle for Computer Security. I can either know exactly what least privilege is for a specific system/use case or I can talk about "least privilege" abstractly about all systems, but not both with appreciable accuracy. Re: devs vs CTOs vs Program / project managers The "power" is shared across these areas, and sometimes poorly. The dev can't be solely responsible since they would need a very complete requirement set to hold that bag, yet we rarely get those requirements in the degree of detail we'd need. However the dev SHOULD also know about common security issues and techniques, and ensure they avoid them, even if it means pushing back on some requirements to achieve the security needed or if they are not specified in the requirements. The QA / Testing team should be able to test for requirements and security issues enough to verify that the target state for functionality and security are both met to acceptable levels. Application security is a team sport. If we try to pin the responsibility on any one group or person we leave out aspects that they don't typically control (some small apps or process might be exceptions, but large apps I'd guess this to be true). -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson Sent: Tuesday, November 25, 2008 9:49 AM To: Stephen Craig Evans Cc: Secure Mailing List Subject: Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security look, i am a consultant. i work in lots of different companies. lots of different projects. i don't see these distinctions in black and white. sometimes the cto and managers are best positioned to help companies develop more secure software, sometimes architects, sometimes auditors, and many many times in my experience developers are best positioned. but i really, truly do not care who does it. my only goal is more effective security mechanisms and some pragmatic roadmap to get there. we are in the infancy of this industry (think automotive safety circa 1942, all seat belts and brakes), we are in no position to turn away help from anyone who can help. every company and every project is different, if your organization is set up so that developers are not empowered, but managers and CTOs are then by all means work with them. but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the "too hard" pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. -gunnar On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: > It's a real cop-out for you guys, as titans in the industry, to go > after developers. I'm disappointed in both of you. And Gary, you said > "One of the main challenges is that developers have a hard time > thinking about the principle of least privilege ". > > Developers are NEVER asked to think about the principle of least > privilege. Or your world of software security must be very very very > different from mine (and I think my world at least equals yours but > by about 2 billion people more, which might be irrelevant now but a > little more relevant in the future :-) > > With the greatest, deepest respect to both of you, > Stephen > > On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans > wrote: >> Gunnar, >> >> Developers have no power. You should be talking to the decision >> makers. >> >> As an example, to instill the importance of software security, I talk >> to decision makers: project managers, architects, CTOs (admittedly, >> this is a blurred line - lots of folks call themselves architects). >> If >> I go to talk about software security to developers, I know from >> experience that I am probably wasting my time. Even if they do care, >> they have no effect overall. >> >> Your target and blame is wrong; that's all that I am saying. >> >> Stephen >> >> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >> wrote: >>> Sorry I didn't realize "developers" is an offensive ivory tower in >>> other >>> parts of the world, in my world its a compliment. >>> >>> -gunnar >>> >>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>> >>>> HI, >>>> >>>> "maybe the problem with least privilege is that it requires that >>>> developers:..." >>>> >>>> IMHO, your US/UK ivory towers don't exist in other parts of the >>>> world. >>>> Developers have no say in what they do. Nor, do they care about >>>> software security and why should they care? >>>> >>>> So, at least, change your nomenclature and not say "developers". It >>>> offends me because you are putting the onus of knowing about >>>> software >>>> security on the wrong people. >>>> >>>> Cheers, >>>> Stephen >>>> >>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>> wrote: >>>>> >>>>> maybe the problem with least privilege is that it requires that >>>>> developers: >>>>> >>>>> 1. define the entire universe of subjects and objects >>>>> 2. define all possible access rights >>>>> 3. define all possible relationships >>>>> 4. apply all settings >>>>> 5. figure out how to keep 1-4 in synch all the time >>>>> >>>>> do all of this before you start writing code and oh and there are >>>>> basically no tools that smooth the adoption of the above. >>>>> >>>>> i don't think us software security people are helping anybody >>>>> out in >>>>> 2008 by doing ritual incantations of a paper from the mid 70s >>>>> that may >>>>> or may not apply to modern computing and anyhow is riddled with >>>>> ideas >>>>> that have never been implemented in any large scale systems >>>>> >>>>> compare these two statements >>>>> >>>>> Statement 1. Saltzer and Schroeder: >>>>> "f) Least privilege: Every program and every user of the system >>>>> should >>>>> operate using the least set of privileges necessary to complete >>>>> the >>>>> job. Primarily, this principle limits the damage that can result >>>>> from >>>>> an accident or error. It also reduces the number of potential >>>>> interactions among privileged programs to the minimum for correct >>>>> operation, so that unintentional, unwanted, or improper uses of >>>>> privilege are less likely to occur. Thus, if a question arises >>>>> related >>>>> to misuse of a privilege, the number of programs that must be >>>>> audited >>>>> is minimized. Put another way, if a mechanism can provide >>>>> "firewalls," >>>>> the principle of least privilege provides a rationale for where to >>>>> install the firewalls. The military security rule of "need-to- >>>>> know" is >>>>> an example of this principle." >>>>> >>>>> Statement 2. David Gelernter's Manifesto: >>>>> "28. Metaphors have a profound effect on computing: the file- >>>>> cabinet >>>>> metaphor traps us in a "passive" instead of "active" view of >>>>> information management that is fundamentally wrong for computers. >>>>> >>>>> 29. The rigid file and directory system you are stuck with on >>>>> your Mac >>>>> or PC was designed by programmers for programmers - and is still a >>>>> good system for programmers. It is no good for non-programmers. It >>>>> never was, and was never intended to be. >>>>> >>>>> 30. If you have three pet dogs, give them names. If you have >>>>> 10,000 >>>>> head of cattle, don't bother. Nowadays the idea of giving a name >>>>> to >>>>> every file on your computer is ridiculous." >>>>> >>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>> matter of applying Saltzer and Schroeder's principles breaks >>>>> down in >>>>> modern systems. Its a deployment issue, and a matter of >>>>> insufficient >>>>> models and modes. >>>>> >>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.htm l >>>>> >>>>> Remember the 1990s when there were all these search engines that >>>>> required you tag up all the content and put it in hierarchical >>>>> directories and so on? Well what happened? Google came along and >>>>> ate >>>>> their lunch. When the problem is information overload, telling >>>>> everyone to go out and label everything is not gonna work. >>>>> >>>>> -gunnar >>>>> >>>>> >>>>> >>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>> >>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>> blank stares) has been the case ever since the Java security >>>>>> days a >>>>>> decade ago. One of the main challenges is that developers have a >>>>>> hard time thinking about the principle of least privilege and its >>>>>> implications regarding the capabilities they should request. >>>>>> Dinis >>>>>> is brave to set such thinking as a target. I've settled (after >>>>>> ten >>>>>> years) with getting developers just to utter the word "security." >>>>>> >>>>>> All together now..."security". >>>>>> >>>>>> gem >>>>>> >>>>>> company www.cigital.com >>>>>> podcast www.cigital.com/silverbullet >>>>>> blog www.cigital.com/justiceleague >>>>>> book www.swsec.com >>>>>> >>>>>> >>>>>> On 11/24/08 12:31 PM, "Mike Lyman" >>>>>> wrote: >>>>>> >>>>>> Dinis Cruz wrote: >>>>>>> >>>>>>> Don't get me wrong, this is a great document if one is >>>>>>> interested in >>>>>>> writing applications that use CAS (Code Access Security), I >>>>>>> would >>>>>>> love >>>>>>> for this to be widely used. >>>>>> >>>>>> When we recommended recommending CAS during a review of the U.S. >>>>>> Defense >>>>>> Information System Agency's new Application Security and >>>>>> Development >>>>>> Security Technical Implementation Guide earlier this year we >>>>>> were met >>>>>> with what amounted to blank stares. (At least it seemed like that >>>>>> since >>>>>> it was a phone conference.) Some on the call understood it and >>>>>> agreed >>>>>> with the recommendation but those hosting the call and doing the >>>>>> writing >>>>>> didn't seem to grasp it. It may be a while before we see too many >>>>>> adopting this or requiring it for a while. >>>>>> -- >>>>>> >>>>>> Mike Lyman >>>>>> mlyman at west-point.org >>>>>> >>>>>> _______________________________________________ >>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>> List information, subscriptions, etc - >>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>> (http://www.KRvW.com >>>>>> ) >>>>>> as a free, non-commercial service to the software security >>>>>> community. >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>> List information, subscriptions, etc - >>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>> (http://www.KRvW.com >>>>>> ) >>>>>> as a free, non-commercial service to the software security >>>>>> community. >>>>>> _______________________________________________ >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>> List information, subscriptions, etc - >>>>> http://krvw.com/mailman/listinfo/sc-l >>>>> List charter available at - http://www.securecoding.org/list/charter.php >>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>> (http://www.KRvW.com) >>>>> as a free, non-commercial service to the software security >>>>> community. >>>>> _______________________________________________ >>>>> >>>> >>> >>> >> > _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ From ljknews at mac.com Tue Nov 25 16:44:14 2008 From: ljknews at mac.com (ljknews) Date: Tue, 25 Nov 2008 17:44:14 -0400 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <490a979e0811251057x100055fey1e9c67e2daa0bbdc@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> <490a979e0811251057x100055fey1e9c67e2daa0bbdc@mail.gmail.com> Message-ID: At 10:57 AM -0800 11/25/08, Andy Steingruebl wrote: > On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson ><gunnar at arctecgroup.net> wrote: > > > but actually the main point of my post and the one i would like to > hear people's thoughts on - is to say that attempting to apply > principle of least privilege in the real world often leads to drilling > dry wells. i am not blaming any group in particular i am saying i > think it is in the "too hard" pile for now and we as software security > people should not be advocating for it until or unless we can find > cost effective ways to implement it. Certainly it is not a dry well. For the operating system I deal with, application programmers _consistently_ ignore the facility provided for fine-grained access to files and leave users with coarse-grained access as their only recourse. Of course I am not talking about .NET 2.0, as others have not restricted their comments to that either. -- Larry Kilgallen From peter.werner at gmail.com Tue Nov 25 16:51:44 2008 From: peter.werner at gmail.com (Pete Werner) Date: Wed, 26 Nov 2008 08:51:44 +1100 Subject: [SC-L] Software Assist to Find Least Privilege In-Reply-To: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> References: <037F34EDBE4D4AB5B3E0D7A22C39373C@mdrsesco.com> Message-ID: <6378f48a0811251351y3aed44a2vbf1287ebebd615db@mail.gmail.com> I've always thought systrace was nifty http://www.citi.umich.edu/u/provos/systrace/ It's on a different level than .net/java, but I don't see why something like that couldn't be built in to the CLR. As to developers vs management, unless there is high level support for security, developers are always going to struggle justifying time spent on these things. They are usually under a lot of pressure to get things out the door so the company can start making a buck. In my experience higher levels respond to 2 things, customer demand and regulators. Customers are being more vocal about security, and regulators are slowly waking up. Regulators can be scary though. Self regulation would be best but its unlikely higher ups will sign off on self regulation because its just going to cost them more time and money, and the reality is most corporates do not see software security as part of their core business. On Wed, Nov 26, 2008 at 4:26 AM, Mark Rockman wrote: > It be difficult to determine a priori the settings for all the access > control lists and other security parameters that one must establish for CAS > to work. Perhaps a software assist would work according to the following > scenario. Run the program in the environment in which it will actually be > used. Assume minimal permissions. Each time the program would fail due to > violation of some permission, notate the event and plow on. Assuming this > is repeated for every use case, the resulting reports would be a very good > guide to how CAS settings should be established for production. Of course, > everytime the program is changed in any way, the process would have to be > repeated. > > MARK ROCKMAN > MDRSESCO LLC > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From dana at vulscan.com Wed Nov 26 00:05:35 2008 From: dana at vulscan.com (Dana Epp) Date: Tue, 25 Nov 2008 21:05:35 -0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> Message-ID: <212df5cd0811252105y3cce1752v790e0cdc78a1eb72@mail.gmail.com> With all due respect, I think this is where the process of secure coding fails. I think it stems from poor education, but its compounded by an arrogant cop out that developers have no power. Your view is not alone. I hear it a lot. And I think its an easy out. I agree with you that buy in for designing secure code must come from the top down. It has to start at the senior management level and work its way down the line. However, there are certain day-to-day actions that a developer completely has control over. With tight deadlines and lack of resources its easy to sacrifice good principles and practices to get code out. No one denies that. But there are certain things developers CAN and SHOULD be doing. They should be thinking more defensively about their code. If you consider the criticality of many design flaws of today, a lot of it can be controlled by better understanding how the data traverses the systems, and more importantly how to address it as it crosses trust boundaries. By understanding this, its easier to see the entry points that matter most that an adversary may use, and allows the developer to decide how to deal with the code as it fails. This has very little to do with management. This is the difference between strategic and tactical decisions on project development. A developer doesn't need to ask his boss if he can or should use exception handling correctly. To validate all untrusted user input. To check return codes when calling functions. Sadly... in this day and age... most developers don't even do that correctly. And thats a simple example of this entire problem. Until we stop blaming others and take responsibility in the code we write, things won't change. As Gary mentioned... there is an attitude from many developers that they can abdocate responsibility in what they are doing. Its hard to get them to even SAY security. Never mind actually making an effort to do something about it. I appreciate your opinion that you need to approach and work with the decision makes. You are absolutely correct. That's a strategic component of writing secure code. However the tactical approach to actually DO IT fall on developers. It shouldn't BE a special process. It should be part of their day-to-day thinking, attitude and function in their field of work. Guess where this all starts? By educating the developer. Which is why we squarely need to reflect on them to tactically do it. -- Regards, Dana Epp Microsoft Security MVP On Tue, Nov 25, 2008 at 9:01 AM, Stephen Craig Evans < stephencraig.evans at gmail.com> wrote: > Gunnar, > > Developers have no power. You should be talking to the decision makers. > > As an example, to instill the importance of software security, I talk > to decision makers: project managers, architects, CTOs (admittedly, > this is a blurred line - lots of folks call themselves architects). If > I go to talk about software security to developers, I know from > experience that I am probably wasting my time. Even if they do care, > they have no effect overall. > > Your target and blame is wrong; that's all that I am saying. > > Stephen > > On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson > wrote: > > Sorry I didn't realize "developers" is an offensive ivory tower in other > > parts of the world, in my world its a compliment. > > > > -gunnar > > > > On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: > > > >> HI, > >> > >> "maybe the problem with least privilege is that it requires that > >> developers:..." > >> > >> IMHO, your US/UK ivory towers don't exist in other parts of the world. > >> Developers have no say in what they do. Nor, do they care about > >> software security and why should they care? > >> > >> So, at least, change your nomenclature and not say "developers". It > >> offends me because you are putting the onus of knowing about software > >> security on the wrong people. > >> > >> Cheers, > >> Stephen > >> > >> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson > >> wrote: > >>> > >>> maybe the problem with least privilege is that it requires that > >>> developers: > >>> > >>> 1. define the entire universe of subjects and objects > >>> 2. define all possible access rights > >>> 3. define all possible relationships > >>> 4. apply all settings > >>> 5. figure out how to keep 1-4 in synch all the time > >>> > >>> do all of this before you start writing code and oh and there are > >>> basically no tools that smooth the adoption of the above. > >>> > >>> i don't think us software security people are helping anybody out in > >>> 2008 by doing ritual incantations of a paper from the mid 70s that may > >>> or may not apply to modern computing and anyhow is riddled with ideas > >>> that have never been implemented in any large scale systems > >>> > >>> compare these two statements > >>> > >>> Statement 1. Saltzer and Schroeder: > >>> "f) Least privilege: Every program and every user of the system should > >>> operate using the least set of privileges necessary to complete the > >>> job. Primarily, this principle limits the damage that can result from > >>> an accident or error. It also reduces the number of potential > >>> interactions among privileged programs to the minimum for correct > >>> operation, so that unintentional, unwanted, or improper uses of > >>> privilege are less likely to occur. Thus, if a question arises related > >>> to misuse of a privilege, the number of programs that must be audited > >>> is minimized. Put another way, if a mechanism can provide "firewalls," > >>> the principle of least privilege provides a rationale for where to > >>> install the firewalls. The military security rule of "need-to-know" is > >>> an example of this principle." > >>> > >>> Statement 2. David Gelernter's Manifesto: > >>> "28. Metaphors have a profound effect on computing: the file-cabinet > >>> metaphor traps us in a "passive" instead of "active" view of > >>> information management that is fundamentally wrong for computers. > >>> > >>> 29. The rigid file and directory system you are stuck with on your Mac > >>> or PC was designed by programmers for programmers ? and is still a > >>> good system for programmers. It is no good for non-programmers. It > >>> never was, and was never intended to be. > >>> > >>> 30. If you have three pet dogs, give them names. If you have 10,000 > >>> head of cattle, don't bother. Nowadays the idea of giving a name to > >>> every file on your computer is ridiculous." > >>> > >>> Conclusion(gp): Least Privilege is the point where the practical > >>> matter of applying Saltzer and Schroeder's principles breaks down in > >>> modern systems. Its a deployment issue, and a matter of insufficient > >>> models and modes. > >>> > >>> > http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html > >>> > >>> Remember the 1990s when there were all these search engines that > >>> required you tag up all the content and put it in hierarchical > >>> directories and so on? Well what happened? Google came along and ate > >>> their lunch. When the problem is information overload, telling > >>> everyone to go out and label everything is not gonna work. > >>> > >>> -gunnar > >>> > >>> > >>> > >>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: > >>> > >>>> Sadly this non-adoption of privileged/managed code (filled with > >>>> blank stares) has been the case ever since the Java security days a > >>>> decade ago. One of the main challenges is that developers have a > >>>> hard time thinking about the principle of least privilege and its > >>>> implications regarding the capabilities they should request. Dinis > >>>> is brave to set such thinking as a target. I've settled (after ten > >>>> years) with getting developers just to utter the word "security." > >>>> > >>>> All together now..."security". > >>>> > >>>> gem > >>>> > >>>> company www.cigital.com > >>>> podcast www.cigital.com/silverbullet > >>>> blog www.cigital.com/justiceleague > >>>> book www.swsec.com > >>>> > >>>> > >>>> On 11/24/08 12:31 PM, "Mike Lyman" wrote: > >>>> > >>>> Dinis Cruz wrote: > >>>>> > >>>>> Don't get me wrong, this is a great document if one is interested in > >>>>> writing applications that use CAS (Code Access Security), I would > >>>>> love > >>>>> for this to be widely used. > >>>> > >>>> When we recommended recommending CAS during a review of the U.S. > >>>> Defense > >>>> Information System Agency's new Application Security and Development > >>>> Security Technical Implementation Guide earlier this year we were met > >>>> with what amounted to blank stares. (At least it seemed like that > >>>> since > >>>> it was a phone conference.) Some on the call understood it and agreed > >>>> with the recommendation but those hosting the call and doing the > >>>> writing > >>>> didn't seem to grasp it. It may be a while before we see too many > >>>> adopting this or requiring it for a while. > >>>> -- > >>>> > >>>> Mike Lyman > >>>> mlyman at west-point.org > >>>> > >>>> _______________________________________________ > >>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org > >>>> List information, subscriptions, etc - > >>>> http://krvw.com/mailman/listinfo/sc-l > >>>> List charter available at - > http://www.securecoding.org/list/charter.php > >>>> SC-L is hosted and moderated by KRvW Associates, LLC > >>>> (http://www.KRvW.com > >>>> ) > >>>> as a free, non-commercial service to the software security community. > >>>> _______________________________________________ > >>>> > >>>> > >>>> _______________________________________________ > >>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org > >>>> List information, subscriptions, etc - > >>>> http://krvw.com/mailman/listinfo/sc-l > >>>> List charter available at - > http://www.securecoding.org/list/charter.php > >>>> SC-L is hosted and moderated by KRvW Associates, LLC > >>>> (http://www.KRvW.com > >>>> ) > >>>> as a free, non-commercial service to the software security community. > >>>> _______________________________________________ > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Secure Coding mailing list (SC-L) SC-L at securecoding.org > >>> List information, subscriptions, etc - > >>> http://krvw.com/mailman/listinfo/sc-l > >>> List charter available at - > http://www.securecoding.org/list/charter.php > >>> SC-L is hosted and moderated by KRvW Associates, LLC > >>> (http://www.KRvW.com ) > >>> as a free, non-commercial service to the software security community. > >>> _______________________________________________ > >>> > >> > > > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081125/59cc4719/attachment-0001.html From stephencraig.evans at gmail.com Wed Nov 26 03:05:41 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Wed, 26 Nov 2008 16:05:41 +0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <1DA1808C-395A-4259-89DF-A31599D5F415@arctecgroup.net> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> <930fd0230811251007o68d64c93wa064261b6bfd1790@mail.gmail.com> <1DA1808C-395A-4259-89DF-A31599D5F415@arctecgroup.net> Message-ID: <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> Hi Gunnar, I apologize to everybody if I have come across as being harsh. >From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her "lose face". The responsibility of secure software is not at the developer level in most cases, which is why I've spoken at regional IASA events (www.iasahome.org), with overwhelming positive responses, and will continue to try to reach the decision makers (as an OWASP representative) because trying to engage developers directly at this point in time at the maturity level of software security in APAC is not the most effective way to go about it. I'm sure, though, that at financial institutions they get it, but almost all of my clients are government and media/communications companies. Also, sorry to everybody for taking this thread off-topic. Stephen On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson wrote: > stephen > > i spend at least half my time working directly with developers. > > for some reason i have not communicated as well as i should to you, what i > am saying is that the job is too hard for developers *because* the security > industry has let them down by sending them on a fool's errand of least > privilege. > > the problem or target in your words IS with security people NOT developers. > they have other problems just not an endless quixotic quest for least > privilege. i am not repeat not throwing developers under the bus in this > argument. > > i am ready, willing and possibly able to be proven wrong on this point and > maybe there is a cost effective way to deploy least privilege in the real > world just want to make sure that i communicate my argument. > > -gunnar > (who is now letting go) > > On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: > >> I can't let this go. >> >> Gary, you are self-professed working with financial institutions and >> high-end customers. >> >> Gunnar, you are the same, at least what I gather from your Silver >> Bullet podcast when talking about the difference between SOA (top >> down) and Web 2.0 (bottom up). >> >> No flame war intended, but a healthy discussion should be in order. >> >> So please don't talk about "developers" as targets. They/we are the >> lowest on the totem pole. Direct your arrows at the people that you >> deal with. Plain and simple. >> >> Cheers, >> Stephen >> >> On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson >> wrote: >>> >>> look, i am a consultant. i work in lots of different companies. lots of >>> different projects. i don't see these distinctions in black and white. >>> sometimes the cto and managers are best positioned to help companies >>> develop >>> more secure software, sometimes architects, sometimes auditors, and many >>> many times in my experience developers are best positioned. >>> >>> but i really, truly do not care who does it. my only goal is more >>> effective >>> security mechanisms and some pragmatic roadmap to get there. we are in >>> the >>> infancy of this industry (think automotive safety circa 1942, all seat >>> belts >>> and brakes), we are in no position to turn away help from anyone who can >>> help. every company and every project is different, if your organization >>> is >>> set up so that developers are not empowered, but managers and CTOs are >>> then >>> by all means work with them. >>> >>> but actually the main point of my post and the one i would like to hear >>> people's thoughts on - is to say that attempting to apply principle of >>> least >>> privilege in the real world often leads to drilling dry wells. i am not >>> blaming any group in particular i am saying i think it is in the "too >>> hard" >>> pile for now and we as software security people should not be advocating >>> for >>> it until or unless we can find cost effective ways to implement it. >>> >>> -gunnar >>> >>> On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: >>> >>>> It's a real cop-out for you guys, as titans in the industry, to go >>>> after developers. I'm disappointed in both of you. And Gary, you said >>>> "One of the main challenges is that developers have a hard time >>>> thinking about the principle of least privilege ". >>>> >>>> Developers are NEVER asked to think about the principle of least >>>> privilege. Or your world of software security must be very very very >>>> different from mine (and I think my world at least equals yours but >>>> by about 2 billion people more, which might be irrelevant now but a >>>> little more relevant in the future :-) >>>> >>>> With the greatest, deepest respect to both of you, >>>> Stephen >>>> >>>> On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans >>>> wrote: >>>>> >>>>> Gunnar, >>>>> >>>>> Developers have no power. You should be talking to the decision makers. >>>>> >>>>> As an example, to instill the importance of software security, I talk >>>>> to decision makers: project managers, architects, CTOs (admittedly, >>>>> this is a blurred line - lots of folks call themselves architects). If >>>>> I go to talk about software security to developers, I know from >>>>> experience that I am probably wasting my time. Even if they do care, >>>>> they have no effect overall. >>>>> >>>>> Your target and blame is wrong; that's all that I am saying. >>>>> >>>>> Stephen >>>>> >>>>> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >>>>> wrote: >>>>>> >>>>>> Sorry I didn't realize "developers" is an offensive ivory tower in >>>>>> other >>>>>> parts of the world, in my world its a compliment. >>>>>> >>>>>> -gunnar >>>>>> >>>>>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>>>>> >>>>>>> HI, >>>>>>> >>>>>>> "maybe the problem with least privilege is that it requires that >>>>>>> developers:..." >>>>>>> >>>>>>> IMHO, your US/UK ivory towers don't exist in other parts of the >>>>>>> world. >>>>>>> Developers have no say in what they do. Nor, do they care about >>>>>>> software security and why should they care? >>>>>>> >>>>>>> So, at least, change your nomenclature and not say "developers". It >>>>>>> offends me because you are putting the onus of knowing about software >>>>>>> security on the wrong people. >>>>>>> >>>>>>> Cheers, >>>>>>> Stephen >>>>>>> >>>>>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>>>>> wrote: >>>>>>>> >>>>>>>> maybe the problem with least privilege is that it requires that >>>>>>>> developers: >>>>>>>> >>>>>>>> 1. define the entire universe of subjects and objects >>>>>>>> 2. define all possible access rights >>>>>>>> 3. define all possible relationships >>>>>>>> 4. apply all settings >>>>>>>> 5. figure out how to keep 1-4 in synch all the time >>>>>>>> >>>>>>>> do all of this before you start writing code and oh and there are >>>>>>>> basically no tools that smooth the adoption of the above. >>>>>>>> >>>>>>>> i don't think us software security people are helping anybody out in >>>>>>>> 2008 by doing ritual incantations of a paper from the mid 70s that >>>>>>>> may >>>>>>>> or may not apply to modern computing and anyhow is riddled with >>>>>>>> ideas >>>>>>>> that have never been implemented in any large scale systems >>>>>>>> >>>>>>>> compare these two statements >>>>>>>> >>>>>>>> Statement 1. Saltzer and Schroeder: >>>>>>>> "f) Least privilege: Every program and every user of the system >>>>>>>> should >>>>>>>> operate using the least set of privileges necessary to complete the >>>>>>>> job. Primarily, this principle limits the damage that can result >>>>>>>> from >>>>>>>> an accident or error. It also reduces the number of potential >>>>>>>> interactions among privileged programs to the minimum for correct >>>>>>>> operation, so that unintentional, unwanted, or improper uses of >>>>>>>> privilege are less likely to occur. Thus, if a question arises >>>>>>>> related >>>>>>>> to misuse of a privilege, the number of programs that must be >>>>>>>> audited >>>>>>>> is minimized. Put another way, if a mechanism can provide >>>>>>>> "firewalls," >>>>>>>> the principle of least privilege provides a rationale for where to >>>>>>>> install the firewalls. The military security rule of "need-to-know" >>>>>>>> is >>>>>>>> an example of this principle." >>>>>>>> >>>>>>>> Statement 2. David Gelernter's Manifesto: >>>>>>>> "28. Metaphors have a profound effect on computing: the file-cabinet >>>>>>>> metaphor traps us in a "passive" instead of "active" view of >>>>>>>> information management that is fundamentally wrong for computers. >>>>>>>> >>>>>>>> 29. The rigid file and directory system you are stuck with on your >>>>>>>> Mac >>>>>>>> or PC was designed by programmers for programmers ? and is still a >>>>>>>> good system for programmers. It is no good for non-programmers. It >>>>>>>> never was, and was never intended to be. >>>>>>>> >>>>>>>> 30. If you have three pet dogs, give them names. If you have 10,000 >>>>>>>> head of cattle, don't bother. Nowadays the idea of giving a name to >>>>>>>> every file on your computer is ridiculous." >>>>>>>> >>>>>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>>>>> matter of applying Saltzer and Schroeder's principles breaks down in >>>>>>>> modern systems. Its a deployment issue, and a matter of insufficient >>>>>>>> models and modes. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>>>>>> >>>>>>>> Remember the 1990s when there were all these search engines that >>>>>>>> required you tag up all the content and put it in hierarchical >>>>>>>> directories and so on? Well what happened? Google came along and ate >>>>>>>> their lunch. When the problem is information overload, telling >>>>>>>> everyone to go out and label everything is not gonna work. >>>>>>>> >>>>>>>> -gunnar >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>>>>> >>>>>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>>>>> blank stares) has been the case ever since the Java security days a >>>>>>>>> decade ago. One of the main challenges is that developers have a >>>>>>>>> hard time thinking about the principle of least privilege and its >>>>>>>>> implications regarding the capabilities they should request. Dinis >>>>>>>>> is brave to set such thinking as a target. I've settled (after ten >>>>>>>>> years) with getting developers just to utter the word "security." >>>>>>>>> >>>>>>>>> All together now..."security". >>>>>>>>> >>>>>>>>> gem >>>>>>>>> >>>>>>>>> company www.cigital.com >>>>>>>>> podcast www.cigital.com/silverbullet >>>>>>>>> blog www.cigital.com/justiceleague >>>>>>>>> book www.swsec.com >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/24/08 12:31 PM, "Mike Lyman" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Dinis Cruz wrote: >>>>>>>>>> >>>>>>>>>> Don't get me wrong, this is a great document if one is interested >>>>>>>>>> in >>>>>>>>>> writing applications that use CAS (Code Access Security), I would >>>>>>>>>> love >>>>>>>>>> for this to be widely used. >>>>>>>>> >>>>>>>>> When we recommended recommending CAS during a review of the U.S. >>>>>>>>> Defense >>>>>>>>> Information System Agency's new Application Security and >>>>>>>>> Development >>>>>>>>> Security Technical Implementation Guide earlier this year we were >>>>>>>>> met >>>>>>>>> with what amounted to blank stares. (At least it seemed like that >>>>>>>>> since >>>>>>>>> it was a phone conference.) Some on the call understood it and >>>>>>>>> agreed >>>>>>>>> with the recommendation but those hosting the call and doing the >>>>>>>>> writing >>>>>>>>> didn't seem to grasp it. It may be a while before we see too many >>>>>>>>> adopting this or requiring it for a while. >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Mike Lyman >>>>>>>>> mlyman at west-point.org >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>> List information, subscriptions, etc - >>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>> List charter available at - >>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>> (http://www.KRvW.com >>>>>>>>> ) >>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>> community. >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>> List information, subscriptions, etc - >>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>> List charter available at - >>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>> (http://www.KRvW.com >>>>>>>>> ) >>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>> community. >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>> List information, subscriptions, etc - >>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>> List charter available at - >>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>> (http://www.KRvW.com) >>>>>>>> as a free, non-commercial service to the software security >>>>>>>> community. >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From ljknews at mac.com Wed Nov 26 08:33:07 2008 From: ljknews at mac.com (ljknews) Date: Wed, 26 Nov 2008 09:33:07 -0400 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: References: Message-ID: At 9:32 PM -0800 11/25/08, Brian Chess wrote: > Larry, I'm not sure I get your meaning. You say you don't think it's a >dry well, but then you say programmers ignore the privilege management >facilities at their disposal. I mean they ignore it until security overseers (800.53a, PCI DSS, 8500.2 evaluators) come by and force them to fix it. > At 10:57 AM -0800 11/25/08, Andy Steingruebl wrote: >> On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson >><<gunnar at arctecgroup.net>mailto:gunnar at arctecgroup.net>gunnar at arctecgroup.net> >>wrote: >> >> >> but actually the main point of my post and the one i would like to >> hear people's thoughts on - is to say that attempting to apply >> principle of least privilege in the real world often leads to drilling >> dry wells. i am not blaming any group in particular i am saying i >> think it is in the "too hard" pile for now and we as software security >> people should not be advocating for it until or unless we can find >> cost effective ways to implement it. > > Certainly it is not a dry well. For the operating system I deal > with, application programmers _consistently_ ignore the facility > provided for fine-grained access to files and leave users with > coarse-grained access as their only recourse. So attempting to apply it is not a dry well and not too hard - just typically done as a retrofit due to political rather than techical circumstance. I had a friend who was working on software where multi-million dollar accounts failed to balance correctly. That defect got considerable management attention. The same _could_ be done for security. -- Larry Kilgallen From gem at cigital.com Wed Nov 26 09:19:19 2008 From: gem at cigital.com (Gary McGraw) Date: Wed, 26 Nov 2008 09:19:19 -0500 Subject: [SC-L] Regional differences in software security In-Reply-To: <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> Message-ID: Hi Stephen (et al), I think this idea of regional differences is worth exploring a bit. In my work at cigital I have come to believe that there is a difference in approach between the east coast of the US and the west coast. The east coast led by financial services firms in NY and Boston has moved well past the "bug parade" and "penetration testing" to a more strategic approach to the problem. These firms approach software security as a people, process, technology problem that involves cultural change. They have made some impressive progress (about which more in late December). It's true that regulation plays a big role in moving the general approach forward, starting with SOX up through the FFIEC and OCC guidance. By contrast, many (but not all) ISVs on the west coast are still relying on penetration testing to check the software security box. That's because the prevailing attitude out west seems to be something like "software security is important, but our code is WAY better than that example code you're waving around." Pen testing may be a necessity to disavow people of this belief. Incidentally, the west coast approach is currently much more about code, code, code and less about business risk, training, architecture, white box testing and the like. That said, the west coast approach seems to be tracking the east coast with a lag of 12-18 months. So all told this is good news for the field. Just so you know, I am aware of 22 large scale programs underway, 9 of which we're closely studying in the Maturity Model effort. I am interested to hear your impressions of AsiaPAC and software security. Thanks for cluing us in. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/26/08 3:05 AM, "Stephen Craig Evans" wrote: Hi Gunnar, I apologize to everybody if I have come across as being harsh. >From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her "lose face". The responsibility of secure software is not at the developer level in most cases, which is why I've spoken at regional IASA events (www.iasahome.org), with overwhelming positive responses, and will continue to try to reach the decision makers (as an OWASP representative) because trying to engage developers directly at this point in time at the maturity level of software security in APAC is not the most effective way to go about it. I'm sure, though, that at financial institutions they get it, but almost all of my clients are government and media/communications companies. Also, sorry to everybody for taking this thread off-topic. Stephen On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson wrote: > stephen > > i spend at least half my time working directly with developers. > > for some reason i have not communicated as well as i should to you, what i > am saying is that the job is too hard for developers *because* the security > industry has let them down by sending them on a fool's errand of least > privilege. > > the problem or target in your words IS with security people NOT developers. > they have other problems just not an endless quixotic quest for least > privilege. i am not repeat not throwing developers under the bus in this > argument. > > i am ready, willing and possibly able to be proven wrong on this point and > maybe there is a cost effective way to deploy least privilege in the real > world just want to make sure that i communicate my argument. > > -gunnar > (who is now letting go) > > On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: > >> I can't let this go. >> >> Gary, you are self-professed working with financial institutions and >> high-end customers. >> >> Gunnar, you are the same, at least what I gather from your Silver >> Bullet podcast when talking about the difference between SOA (top >> down) and Web 2.0 (bottom up). >> >> No flame war intended, but a healthy discussion should be in order. >> >> So please don't talk about "developers" as targets. They/we are the >> lowest on the totem pole. Direct your arrows at the people that you >> deal with. Plain and simple. >> >> Cheers, >> Stephen >> >> On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson >> wrote: >>> >>> look, i am a consultant. i work in lots of different companies. lots of >>> different projects. i don't see these distinctions in black and white. >>> sometimes the cto and managers are best positioned to help companies >>> develop >>> more secure software, sometimes architects, sometimes auditors, and many >>> many times in my experience developers are best positioned. >>> >>> but i really, truly do not care who does it. my only goal is more >>> effective >>> security mechanisms and some pragmatic roadmap to get there. we are in >>> the >>> infancy of this industry (think automotive safety circa 1942, all seat >>> belts >>> and brakes), we are in no position to turn away help from anyone who can >>> help. every company and every project is different, if your organization >>> is >>> set up so that developers are not empowered, but managers and CTOs are >>> then >>> by all means work with them. >>> >>> but actually the main point of my post and the one i would like to hear >>> people's thoughts on - is to say that attempting to apply principle of >>> least >>> privilege in the real world often leads to drilling dry wells. i am not >>> blaming any group in particular i am saying i think it is in the "too >>> hard" >>> pile for now and we as software security people should not be advocating >>> for >>> it until or unless we can find cost effective ways to implement it. >>> >>> -gunnar >>> >>> On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: >>> >>>> It's a real cop-out for you guys, as titans in the industry, to go >>>> after developers. I'm disappointed in both of you. And Gary, you said >>>> "One of the main challenges is that developers have a hard time >>>> thinking about the principle of least privilege ". >>>> >>>> Developers are NEVER asked to think about the principle of least >>>> privilege. Or your world of software security must be very very very >>>> different from mine (and I think my world at least equals yours but >>>> by about 2 billion people more, which might be irrelevant now but a >>>> little more relevant in the future :-) >>>> >>>> With the greatest, deepest respect to both of you, >>>> Stephen >>>> >>>> On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans >>>> wrote: >>>>> >>>>> Gunnar, >>>>> >>>>> Developers have no power. You should be talking to the decision makers. >>>>> >>>>> As an example, to instill the importance of software security, I talk >>>>> to decision makers: project managers, architects, CTOs (admittedly, >>>>> this is a blurred line - lots of folks call themselves architects). If >>>>> I go to talk about software security to developers, I know from >>>>> experience that I am probably wasting my time. Even if they do care, >>>>> they have no effect overall. >>>>> >>>>> Your target and blame is wrong; that's all that I am saying. >>>>> >>>>> Stephen >>>>> >>>>> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >>>>> wrote: >>>>>> >>>>>> Sorry I didn't realize "developers" is an offensive ivory tower in >>>>>> other >>>>>> parts of the world, in my world its a compliment. >>>>>> >>>>>> -gunnar >>>>>> >>>>>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>>>>> >>>>>>> HI, >>>>>>> >>>>>>> "maybe the problem with least privilege is that it requires that >>>>>>> developers:..." >>>>>>> >>>>>>> IMHO, your US/UK ivory towers don't exist in other parts of the >>>>>>> world. >>>>>>> Developers have no say in what they do. Nor, do they care about >>>>>>> software security and why should they care? >>>>>>> >>>>>>> So, at least, change your nomenclature and not say "developers". It >>>>>>> offends me because you are putting the onus of knowing about software >>>>>>> security on the wrong people. >>>>>>> >>>>>>> Cheers, >>>>>>> Stephen >>>>>>> >>>>>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>>>>> wrote: >>>>>>>> >>>>>>>> maybe the problem with least privilege is that it requires that >>>>>>>> developers: >>>>>>>> >>>>>>>> 1. define the entire universe of subjects and objects >>>>>>>> 2. define all possible access rights >>>>>>>> 3. define all possible relationships >>>>>>>> 4. apply all settings >>>>>>>> 5. figure out how to keep 1-4 in synch all the time >>>>>>>> >>>>>>>> do all of this before you start writing code and oh and there are >>>>>>>> basically no tools that smooth the adoption of the above. >>>>>>>> >>>>>>>> i don't think us software security people are helping anybody out in >>>>>>>> 2008 by doing ritual incantations of a paper from the mid 70s that >>>>>>>> may >>>>>>>> or may not apply to modern computing and anyhow is riddled with >>>>>>>> ideas >>>>>>>> that have never been implemented in any large scale systems >>>>>>>> >>>>>>>> compare these two statements >>>>>>>> >>>>>>>> Statement 1. Saltzer and Schroeder: >>>>>>>> "f) Least privilege: Every program and every user of the system >>>>>>>> should >>>>>>>> operate using the least set of privileges necessary to complete the >>>>>>>> job. Primarily, this principle limits the damage that can result >>>>>>>> from >>>>>>>> an accident or error. It also reduces the number of potential >>>>>>>> interactions among privileged programs to the minimum for correct >>>>>>>> operation, so that unintentional, unwanted, or improper uses of >>>>>>>> privilege are less likely to occur. Thus, if a question arises >>>>>>>> related >>>>>>>> to misuse of a privilege, the number of programs that must be >>>>>>>> audited >>>>>>>> is minimized. Put another way, if a mechanism can provide >>>>>>>> "firewalls," >>>>>>>> the principle of least privilege provides a rationale for where to >>>>>>>> install the firewalls. The military security rule of "need-to-know" >>>>>>>> is >>>>>>>> an example of this principle." >>>>>>>> >>>>>>>> Statement 2. David Gelernter's Manifesto: >>>>>>>> "28. Metaphors have a profound effect on computing: the file-cabinet >>>>>>>> metaphor traps us in a "passive" instead of "active" view of >>>>>>>> information management that is fundamentally wrong for computers. >>>>>>>> >>>>>>>> 29. The rigid file and directory system you are stuck with on your >>>>>>>> Mac >>>>>>>> or PC was designed by programmers for programmers - and is still a >>>>>>>> good system for programmers. It is no good for non-programmers. It >>>>>>>> never was, and was never intended to be. >>>>>>>> >>>>>>>> 30. If you have three pet dogs, give them names. If you have 10,000 >>>>>>>> head of cattle, don't bother. Nowadays the idea of giving a name to >>>>>>>> every file on your computer is ridiculous." >>>>>>>> >>>>>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>>>>> matter of applying Saltzer and Schroeder's principles breaks down in >>>>>>>> modern systems. Its a deployment issue, and a matter of insufficient >>>>>>>> models and modes. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>>>>>> >>>>>>>> Remember the 1990s when there were all these search engines that >>>>>>>> required you tag up all the content and put it in hierarchical >>>>>>>> directories and so on? Well what happened? Google came along and ate >>>>>>>> their lunch. When the problem is information overload, telling >>>>>>>> everyone to go out and label everything is not gonna work. >>>>>>>> >>>>>>>> -gunnar >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>>>>> >>>>>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>>>>> blank stares) has been the case ever since the Java security days a >>>>>>>>> decade ago. One of the main challenges is that developers have a >>>>>>>>> hard time thinking about the principle of least privilege and its >>>>>>>>> implications regarding the capabilities they should request. Dinis >>>>>>>>> is brave to set such thinking as a target. I've settled (after ten >>>>>>>>> years) with getting developers just to utter the word "security." >>>>>>>>> >>>>>>>>> All together now..."security". >>>>>>>>> >>>>>>>>> gem >>>>>>>>> >>>>>>>>> company www.cigital.com >>>>>>>>> podcast www.cigital.com/silverbullet >>>>>>>>> blog www.cigital.com/justiceleague >>>>>>>>> book www.swsec.com >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/24/08 12:31 PM, "Mike Lyman" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Dinis Cruz wrote: >>>>>>>>>> >>>>>>>>>> Don't get me wrong, this is a great document if one is interested >>>>>>>>>> in >>>>>>>>>> writing applications that use CAS (Code Access Security), I would >>>>>>>>>> love >>>>>>>>>> for this to be widely used. >>>>>>>>> >>>>>>>>> When we recommended recommending CAS during a review of the U.S. >>>>>>>>> Defense >>>>>>>>> Information System Agency's new Application Security and >>>>>>>>> Development >>>>>>>>> Security Technical Implementation Guide earlier this year we were >>>>>>>>> met >>>>>>>>> with what amounted to blank stares. (At least it seemed like that >>>>>>>>> since >>>>>>>>> it was a phone conference.) Some on the call understood it and >>>>>>>>> agreed >>>>>>>>> with the recommendation but those hosting the call and doing the >>>>>>>>> writing >>>>>>>>> didn't seem to grasp it. It may be a while before we see too many >>>>>>>>> adopting this or requiring it for a while. >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Mike Lyman >>>>>>>>> mlyman at west-point.org >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>> List information, subscriptions, etc - >>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>> List charter available at - >>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>> (http://www.KRvW.com >>>>>>>>> ) >>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>> community. >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>> List information, subscriptions, etc - >>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>> List charter available at - >>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>> (http://www.KRvW.com >>>>>>>>> ) >>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>> community. >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>> List information, subscriptions, etc - >>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>> List charter available at - >>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>> (http://www.KRvW.com) >>>>>>>> as a free, non-commercial service to the software security >>>>>>>> community. >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From ken at krvw.com Wed Nov 26 09:45:57 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 26 Nov 2008 09:45:57 -0500 Subject: [SC-L] Regional differences in software security In-Reply-To: References: Message-ID: On Nov 26, 2008, at 9:19 AM, Gary McGraw wrote: > I think this idea of regional differences is worth exploring a bit. > In my work at cigital I have come to believe that there is a > difference in approach between the east coast of the US and the west > coast. I completely agree here. Stephen raises a fascinating point. I don't know what I did {right|wrong}, but the vast majority of my clients are in Europe or Southeast Asia right now. (I'm a dual EU/US citizen, which perhaps helps.) Apart from all the air miles, I've seen vast differences that seem--at least on the surface via casual observation--to have a regional component. Contrasting US East, West, EU, and Asia, there are big differences in such areas as: - Software process. I see more process-heavy dev in US East and Europe, with far less of it in US West and Asia, for instance. - Security teams. I see a pretty solid line between IT security and software dev teams in US East and Asia, with lines being more blurred in US West and EU. This seems to be central to Stephen's point, if I understand correctly. And it's a good point to consider. - Security testing. ... The list goes on. Unfortunately, all I have are casual observations, but the "climate differences" seem palpable to me. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081126/c762de84/attachment.bin From sbradcpa at pacbell.net Wed Nov 26 09:59:33 2008 From: sbradcpa at pacbell.net (Susan Bradley) Date: Wed, 26 Nov 2008 06:59:33 -0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net> <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> <930fd0230811251007o68d64c93wa064261b6bfd1790@mail.gmail.com> <1DA1808C-395A-4259-89DF-A31599D5F415@arctecgroup.net> <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> Message-ID: <492D6455.2010606@pacbell.net> There is a lot of USA firm coding done outside our shores. Thus the attitude you are reporting impacts the software I am buying both for my desktop as well as the upcoming cloud applications. This is the part that concerns me. As a consumer of code when it's in my possession I am then able to do what I can to augment the security of it. When it's in the cloud, I'm depending on the vendor of the cloud to have thought about security . We need to get to the place where you can come back in a few years and say that the culture has changed. IMHO don't apologize. It shows that we still need to get consumers/buyers of code to care that Developers are taught to care. We have work to do. Stephen Craig Evans wrote: > Hi Gunnar, > > I apologize to everybody if I have come across as being harsh. > > >From my 8 years of experience of living in Asia and being actively > involved as a developer and working with developers (at Microsoft as > its first .NET Regional Developer Evangelist in 2001 to recently at > Symantec as the first Secure Application Services consultant for > APAC), IMO there's a big gap between the maturity of software security > here vs. Europe vs. West Coast USA vs. East Coast USA. > > The culture is different and even in the situation that a software > developer cared and wanted to implement software security, in many > countries they could get in a lot of trouble for upstaging their boss > and making him or her "lose face". > > The responsibility of secure software is not at the developer level in > most cases, which is why I've spoken at regional IASA events > (www.iasahome.org), with overwhelming positive responses, and will > continue to try to reach the decision makers (as an OWASP > representative) because trying to engage developers directly at this > point in time at the maturity level of software security in APAC is > not the most effective way to go about it. I'm sure, though, that at > financial institutions they get it, but almost all of my clients are > government and media/communications companies. > > Also, sorry to everybody for taking this thread off-topic. > > Stephen > > On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson wrote: > >> stephen >> >> i spend at least half my time working directly with developers. >> >> for some reason i have not communicated as well as i should to you, what i >> am saying is that the job is too hard for developers *because* the security >> industry has let them down by sending them on a fool's errand of least >> privilege. >> >> the problem or target in your words IS with security people NOT developers. >> they have other problems just not an endless quixotic quest for least >> privilege. i am not repeat not throwing developers under the bus in this >> argument. >> >> i am ready, willing and possibly able to be proven wrong on this point and >> maybe there is a cost effective way to deploy least privilege in the real >> world just want to make sure that i communicate my argument. >> >> -gunnar >> (who is now letting go) >> >> On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: >> >> >>> I can't let this go. >>> >>> Gary, you are self-professed working with financial institutions and >>> high-end customers. >>> >>> Gunnar, you are the same, at least what I gather from your Silver >>> Bullet podcast when talking about the difference between SOA (top >>> down) and Web 2.0 (bottom up). >>> >>> No flame war intended, but a healthy discussion should be in order. >>> >>> So please don't talk about "developers" as targets. They/we are the >>> lowest on the totem pole. Direct your arrows at the people that you >>> deal with. Plain and simple. >>> >>> Cheers, >>> Stephen >>> >>> On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson >>> wrote: >>> >>>> look, i am a consultant. i work in lots of different companies. lots of >>>> different projects. i don't see these distinctions in black and white. >>>> sometimes the cto and managers are best positioned to help companies >>>> develop >>>> more secure software, sometimes architects, sometimes auditors, and many >>>> many times in my experience developers are best positioned. >>>> >>>> but i really, truly do not care who does it. my only goal is more >>>> effective >>>> security mechanisms and some pragmatic roadmap to get there. we are in >>>> the >>>> infancy of this industry (think automotive safety circa 1942, all seat >>>> belts >>>> and brakes), we are in no position to turn away help from anyone who can >>>> help. every company and every project is different, if your organization >>>> is >>>> set up so that developers are not empowered, but managers and CTOs are >>>> then >>>> by all means work with them. >>>> >>>> but actually the main point of my post and the one i would like to hear >>>> people's thoughts on - is to say that attempting to apply principle of >>>> least >>>> privilege in the real world often leads to drilling dry wells. i am not >>>> blaming any group in particular i am saying i think it is in the "too >>>> hard" >>>> pile for now and we as software security people should not be advocating >>>> for >>>> it until or unless we can find cost effective ways to implement it. >>>> >>>> -gunnar >>>> >>>> On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: >>>> >>>> >>>>> It's a real cop-out for you guys, as titans in the industry, to go >>>>> after developers. I'm disappointed in both of you. And Gary, you said >>>>> "One of the main challenges is that developers have a hard time >>>>> thinking about the principle of least privilege ". >>>>> >>>>> Developers are NEVER asked to think about the principle of least >>>>> privilege. Or your world of software security must be very very very >>>>> different from mine (and I think my world at least equals yours but >>>>> by about 2 billion people more, which might be irrelevant now but a >>>>> little more relevant in the future :-) >>>>> >>>>> With the greatest, deepest respect to both of you, >>>>> Stephen >>>>> >>>>> On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans >>>>> wrote: >>>>> >>>>>> Gunnar, >>>>>> >>>>>> Developers have no power. You should be talking to the decision makers. >>>>>> >>>>>> As an example, to instill the importance of software security, I talk >>>>>> to decision makers: project managers, architects, CTOs (admittedly, >>>>>> this is a blurred line - lots of folks call themselves architects). If >>>>>> I go to talk about software security to developers, I know from >>>>>> experience that I am probably wasting my time. Even if they do care, >>>>>> they have no effect overall. >>>>>> >>>>>> Your target and blame is wrong; that's all that I am saying. >>>>>> >>>>>> Stephen >>>>>> >>>>>> On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson >>>>>> wrote: >>>>>> >>>>>>> Sorry I didn't realize "developers" is an offensive ivory tower in >>>>>>> other >>>>>>> parts of the world, in my world its a compliment. >>>>>>> >>>>>>> -gunnar >>>>>>> >>>>>>> On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: >>>>>>> >>>>>>> >>>>>>>> HI, >>>>>>>> >>>>>>>> "maybe the problem with least privilege is that it requires that >>>>>>>> developers:..." >>>>>>>> >>>>>>>> IMHO, your US/UK ivory towers don't exist in other parts of the >>>>>>>> world. >>>>>>>> Developers have no say in what they do. Nor, do they care about >>>>>>>> software security and why should they care? >>>>>>>> >>>>>>>> So, at least, change your nomenclature and not say "developers". It >>>>>>>> offends me because you are putting the onus of knowing about software >>>>>>>> security on the wrong people. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Stephen >>>>>>>> >>>>>>>> On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> maybe the problem with least privilege is that it requires that >>>>>>>>> developers: >>>>>>>>> >>>>>>>>> 1. define the entire universe of subjects and objects >>>>>>>>> 2. define all possible access rights >>>>>>>>> 3. define all possible relationships >>>>>>>>> 4. apply all settings >>>>>>>>> 5. figure out how to keep 1-4 in synch all the time >>>>>>>>> >>>>>>>>> do all of this before you start writing code and oh and there are >>>>>>>>> basically no tools that smooth the adoption of the above. >>>>>>>>> >>>>>>>>> i don't think us software security people are helping anybody out in >>>>>>>>> 2008 by doing ritual incantations of a paper from the mid 70s that >>>>>>>>> may >>>>>>>>> or may not apply to modern computing and anyhow is riddled with >>>>>>>>> ideas >>>>>>>>> that have never been implemented in any large scale systems >>>>>>>>> >>>>>>>>> compare these two statements >>>>>>>>> >>>>>>>>> Statement 1. Saltzer and Schroeder: >>>>>>>>> "f) Least privilege: Every program and every user of the system >>>>>>>>> should >>>>>>>>> operate using the least set of privileges necessary to complete the >>>>>>>>> job. Primarily, this principle limits the damage that can result >>>>>>>>> from >>>>>>>>> an accident or error. It also reduces the number of potential >>>>>>>>> interactions among privileged programs to the minimum for correct >>>>>>>>> operation, so that unintentional, unwanted, or improper uses of >>>>>>>>> privilege are less likely to occur. Thus, if a question arises >>>>>>>>> related >>>>>>>>> to misuse of a privilege, the number of programs that must be >>>>>>>>> audited >>>>>>>>> is minimized. Put another way, if a mechanism can provide >>>>>>>>> "firewalls," >>>>>>>>> the principle of least privilege provides a rationale for where to >>>>>>>>> install the firewalls. The military security rule of "need-to-know" >>>>>>>>> is >>>>>>>>> an example of this principle." >>>>>>>>> >>>>>>>>> Statement 2. David Gelernter's Manifesto: >>>>>>>>> "28. Metaphors have a profound effect on computing: the file-cabinet >>>>>>>>> metaphor traps us in a "passive" instead of "active" view of >>>>>>>>> information management that is fundamentally wrong for computers. >>>>>>>>> >>>>>>>>> 29. The rigid file and directory system you are stuck with on your >>>>>>>>> Mac >>>>>>>>> or PC was designed by programmers for programmers ? and is still a >>>>>>>>> good system for programmers. It is no good for non-programmers. It >>>>>>>>> never was, and was never intended to be. >>>>>>>>> >>>>>>>>> 30. If you have three pet dogs, give them names. If you have 10,000 >>>>>>>>> head of cattle, don't bother. Nowadays the idea of giving a name to >>>>>>>>> every file on your computer is ridiculous." >>>>>>>>> >>>>>>>>> Conclusion(gp): Least Privilege is the point where the practical >>>>>>>>> matter of applying Saltzer and Schroeder's principles breaks down in >>>>>>>>> modern systems. Its a deployment issue, and a matter of insufficient >>>>>>>>> models and modes. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html >>>>>>>>> >>>>>>>>> Remember the 1990s when there were all these search engines that >>>>>>>>> required you tag up all the content and put it in hierarchical >>>>>>>>> directories and so on? Well what happened? Google came along and ate >>>>>>>>> their lunch. When the problem is information overload, telling >>>>>>>>> everyone to go out and label everything is not gonna work. >>>>>>>>> >>>>>>>>> -gunnar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Sadly this non-adoption of privileged/managed code (filled with >>>>>>>>>> blank stares) has been the case ever since the Java security days a >>>>>>>>>> decade ago. One of the main challenges is that developers have a >>>>>>>>>> hard time thinking about the principle of least privilege and its >>>>>>>>>> implications regarding the capabilities they should request. Dinis >>>>>>>>>> is brave to set such thinking as a target. I've settled (after ten >>>>>>>>>> years) with getting developers just to utter the word "security." >>>>>>>>>> >>>>>>>>>> All together now..."security". >>>>>>>>>> >>>>>>>>>> gem >>>>>>>>>> >>>>>>>>>> company www.cigital.com >>>>>>>>>> podcast www.cigital.com/silverbullet >>>>>>>>>> blog www.cigital.com/justiceleague >>>>>>>>>> book www.swsec.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/24/08 12:31 PM, "Mike Lyman" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Dinis Cruz wrote: >>>>>>>>>> >>>>>>>>>>> Don't get me wrong, this is a great document if one is interested >>>>>>>>>>> in >>>>>>>>>>> writing applications that use CAS (Code Access Security), I would >>>>>>>>>>> love >>>>>>>>>>> for this to be widely used. >>>>>>>>>>> >>>>>>>>>> When we recommended recommending CAS during a review of the U.S. >>>>>>>>>> Defense >>>>>>>>>> Information System Agency's new Application Security and >>>>>>>>>> Development >>>>>>>>>> Security Technical Implementation Guide earlier this year we were >>>>>>>>>> met >>>>>>>>>> with what amounted to blank stares. (At least it seemed like that >>>>>>>>>> since >>>>>>>>>> it was a phone conference.) Some on the call understood it and >>>>>>>>>> agreed >>>>>>>>>> with the recommendation but those hosting the call and doing the >>>>>>>>>> writing >>>>>>>>>> didn't seem to grasp it. It may be a while before we see too many >>>>>>>>>> adopting this or requiring it for a while. >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Mike Lyman >>>>>>>>>> mlyman at west-point.org >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>>> List information, subscriptions, etc - >>>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>>> List charter available at - >>>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>>> (http://www.KRvW.com >>>>>>>>>> ) >>>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>>> community. >>>>>>>>>> _______________________________________________ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>>> List information, subscriptions, etc - >>>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>>> List charter available at - >>>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>>> (http://www.KRvW.com >>>>>>>>>> ) >>>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>>> community. >>>>>>>>>> _______________________________________________ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org >>>>>>>>> List information, subscriptions, etc - >>>>>>>>> http://krvw.com/mailman/listinfo/sc-l >>>>>>>>> List charter available at - >>>>>>>>> http://www.securecoding.org/list/charter.php >>>>>>>>> SC-L is hosted and moderated by KRvW Associates, LLC >>>>>>>>> (http://www.KRvW.com) >>>>>>>>> as a free, non-commercial service to the software security >>>>>>>>> community. >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From leichter_jerrold at emc.com Wed Nov 26 13:43:35 2008 From: leichter_jerrold at emc.com (Jerry Leichter) Date: Wed, 26 Nov 2008 13:43:35 -0500 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> References: <70C6D6BC-FAA8-4988-8587-B30A77968CAF@arctecgroup.net><930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com><930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com><930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com><930fd0230811251007o68d64c93wa064261b6bfd1790@mail.gmail.com><1DA1808C-395A-4259-89DF-A31599D5F415@arctecgroup.net> <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> Message-ID: <2FDF9FBE-595B-45E2-9E85-305CDCCE02AF@emc.com> On Nov 26, 2008, at 3:05 AM, Stephen Craig Evans wrote: > Hi Gunnar, > > I apologize to everybody if I have come across as being harsh. > > >From my 8 years of experience of living in Asia and being actively > involved as a developer and working with developers (at Microsoft as > its first .NET Regional Developer Evangelist in 2001 to recently at > Symantec as the first Secure Application Services consultant for > APAC), IMO there's a big gap between the maturity of software security > here vs. Europe vs. West Coast USA vs. East Coast USA. > > The culture is different and even in the situation that a software > developer cared and wanted to implement software security, in many > countries they could get in a lot of trouble for upstaging their boss > and making him or her "lose face". > > The responsibility of secure software is not at the developer level in > most cases.... > This has really important implications, and is worthy of thought and discussion. On the one hand, *right now*, it justifies the complaints about outsourcing: That you really can't trust software produced in Asia. On the other hand, the (relative) command-and-control nature of development in Asia means that, should management there decide that security is an important issue - and since given the nature of their business, they are very sensitive to customer demand, that would mean that their customers tell them unambiguously that it's what they'll be judged on *and actually act that way* - Asian outsourcers are likely to be much more effective at getting their organizations to focus on secure practices than we are here in the more free-wheeling West. -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081126/86e87825/attachment.html From stephencraig.evans at gmail.com Wed Nov 26 21:24:36 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Thu, 27 Nov 2008 10:24:36 +0800 Subject: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security In-Reply-To: <2FDF9FBE-595B-45E2-9E85-305CDCCE02AF@emc.com> References: <930fd0230811250830j7c3fc8a5jeaf44a37d0db5bb3@mail.gmail.com> <930fd0230811250901s893ad32vd8e0a37a76aa15aa@mail.gmail.com> <930fd0230811250928k5d223cd4qd8904b29107366e3@mail.gmail.com> <930fd0230811251007o68d64c93wa064261b6bfd1790@mail.gmail.com> <1DA1808C-395A-4259-89DF-A31599D5F415@arctecgroup.net> <930fd0230811260005w24e0ef3brab1c1c6d87830ad2@mail.gmail.com> <2FDF9FBE-595B-45E2-9E85-305CDCCE02AF@emc.com> Message-ID: <930fd0230811261824r171e29c2r732931780ed06367@mail.gmail.com> Whenever I speak with a customer or any software decision makers, I implore them, before buying another vendor's software, or hiring/contracting a 3rd party development firm, to ask a couple of simple questions: "What do you do for software security?", and "Can you send me some documents about your software security practices?". >From my experience, that will stop at least 95% of them in their tracks. There are lots of country-specific 5 to 30 person software shops located in the major Asian business centers. But even if, say, IBM is the main contractor to a client of mine, those questions can still be asked of IBM, and it's their responsibility to get the answers from the small software shop (and my client will have the documentation as a "trust but verify" check for later use). Stephen On 11/27/08, Jerry Leichter wrote: > > On Nov 26, 2008, at 3:05 AM, Stephen Craig Evans wrote: > > > > Hi Gunnar, > > I apologize to everybody if I have come across as being harsh. > > >From my 8 years of experience of living in Asia and being actively > involved as a developer and working with developers (at Microsoft as > its first .NET Regional Developer Evangelist in 2001 to recently at > Symantec as the first Secure Application Services consultant for > APAC), IMO there's a big gap between the maturity of software security > here vs. Europe vs. West Coast USA vs. East Coast USA. > > The culture is different and even in the situation that a software > developer cared and wanted to implement software security, in many > countries they could get in a lot of trouble for upstaging their boss > and making him or her "lose face". > > The responsibility of secure software is not at the developer level in > most cases....This has really important implications, and is worthy of > thought and discussion. > > On the one hand, *right now*, it justifies the complaints about outsourcing: > That you really can't trust software produced in Asia. On the other hand, > the (relative) command-and-control nature of development in Asia means that, > should management there decide that security is an important issue - and > since given the nature of their business, they are very sensitive to > customer demand, that would mean that their customers tell them > unambiguously that it's what they'll be judged on *and actually act that > way* - Asian outsourcers are likely to be much more effective at getting > their organizations to focus on secure practices than we are here in the > more free-wheeling West. > > > -- Jerry > > > From stephencraig.evans at gmail.com Thu Nov 27 02:23:13 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Thu, 27 Nov 2008 15:23:13 +0800 Subject: [SC-L] Regional differences in software security In-Reply-To: References: Message-ID: <930fd0230811262323t69697d70r4a48d5c4be0bafe4@mail.gmail.com> I'll preface what I'm going to say with: - I don't work in the financial vertical or government defense, but from conversations with colleagues, I think that they get it (they have to) - My sphere of experience excludes Australia, India, and Japan: - Oz has on average a high skill set of s/w engineers, so I don't see why that would be different for s/w security. - From discussions with friends/ex-employees who are from India, because of such a high turnover in the s/w factories, a coder is given a day's to a week's worth of code to produce at one time, so if they leave then they can be replaced without much loss. This was a few years ago and I don't know the level of s/w security introduced since then, but for sure I highly doubt that developers have any say in what they can write. - Colleagues and friends who live in Japan say that the level of s/w security is just as bad as the rest of Asia, which was surprising to me. I think, though, that in Japan, there is a strong culture of not upstaging the boss so maybe that explains it. So, my sphere of experience extends from Beijing to Jakarta and all points in between... (to paraphrase ZZ Top :-) I would say the level is barely the "beginning of the beginning". There are no compliance laws except for PCI-DSS. There are no breach disclosure laws. There are often huge silos between the security guys and the development team, both organizationally and politically. Quite a few times I've seen the responsibility of software security dumped on the network team with the orders of "make everything secure". And often: (a) the web site was outsourced years ago and the company is no longer in business; (b) the 3rd party software vendor is not going to fix its software or attempt to make it secure in the near future (and there's nothing in the SLA that says they have to; (c) the development team does exist but either change processes take 3 to 6 months to get anything done, or (d) the network manager has to go to political war to get something done. >From all of the above, a magic elixir for a network security team can be a web application firewall. They can drop a box in and they don't need anybody else's permission. This is what happened on a very recent project (I was helping the client prepare for a PCI audit), and because of my Summer of Code OWASP project, Securing WebGoat using ModSecurity, I was able to help their team write custom ModSec rulesets; and from that they learned something about security (of course it should have been the s/w people who learned something about it). And, you don't know how many times I've been approached to do pentests for large corporations' web sites that handle sensitive customer data - and their budget is $6500 to $10,000 USD. Sorry, I'm greedy, but I can't risk my reputation by doing a less than half-assed job. On the bright side, I've had a couple of application pentest projects - the head of the development team was responsible for it (maybe that's the key) - and they went great. The developers & architects didn't know anything about software security, but each manager assembled the entire dev team and network/sys admins for a half day for me to present my findings and educate them on what they needed to do; to explain the origin, the prevention/solution, etc. Those are real fun and it's so cool seeing the looks on people's faces when it clicks and they get it. Stephen On Wed, Nov 26, 2008 at 10:45 PM, Kenneth Van Wyk wrote: > On Nov 26, 2008, at 9:19 AM, Gary McGraw wrote: >> >> I think this idea of regional differences is worth exploring a bit. In my >> work at cigital I have come to believe that there is a difference in >> approach between the east coast of the US and the west coast. > > I completely agree here. Stephen raises a fascinating point. > > I don't know what I did {right|wrong}, but the vast majority of my clients > are in Europe or Southeast Asia right now. (I'm a dual EU/US citizen, which > perhaps helps.) Apart from all the air miles, I've seen vast differences > that seem--at least on the surface via casual observation--to have a > regional component. Contrasting US East, West, EU, and Asia, there are big > differences in such areas as: > > - Software process. I see more process-heavy dev in US East and Europe, > with far less of it in US West and Asia, for instance. > > - Security teams. I see a pretty solid line between IT security and > software dev teams in US East and Asia, with lines being more blurred in US > West and EU. This seems to be central to Stephen's point, if I understand > correctly. And it's a good point to consider. > > - Security testing. ... > > The list goes on. Unfortunately, all I have are casual observations, but > the "climate differences" seem palpable to me. > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > > > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From mrockman at acm.org Wed Nov 26 21:03:56 2008 From: mrockman at acm.org (Mark Rockman) Date: Wed, 26 Nov 2008 21:03:56 -0500 Subject: [SC-L] How Can You Tell It Is Written Securely? Message-ID: OK. So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it cannot misbehave. How can you tell that what they deliver is truly locked down? Will you wait until it gets hacked? What simple yet thorough inspection process is there that'll do the job? Doesn't exist, does it? MARK ROCKMAN MDRSESCO LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081126/78bf8409/attachment.html From stephencraig.evans at gmail.com Thu Nov 27 10:07:03 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Thu, 27 Nov 2008 23:07:03 +0800 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: <930fd0230811270707r40b46ee1s345e367e8d142c35@mail.gmail.com> "... and demand that they deliver code that is so locked down that it cannot misbehave". Your premise is so incorrect that I advise that if you are truly interested in answering your questions (as opposed to a purely academic or other exercise), then you should hire a security specialist to help you out, or use google search :-) Cheers, Stephen On Thu, Nov 27, 2008 at 10:03 AM, Mark Rockman wrote: > OK. So you decide to outsource your programming assignment to Asia and > demand that they deliver code that is so locked down that it cannot > misbehave. How can you tell that what they deliver is truly locked down? > Will you wait until it gets hacked? What simple yet thorough inspection > process is there that'll do the job? Doesn't exist, does it? > > > MARK ROCKMAN > MDRSESCO LLC > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From dana at vulscan.com Thu Nov 27 11:32:08 2008 From: dana at vulscan.com (Dana Epp) Date: Thu, 27 Nov 2008 08:32:08 -0800 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: <212df5cd0811270832p51086db8qb83a8e771a19d0c7@mail.gmail.com> Code auditing. Untrusted code cannot be deemed safe. If you plan to outsource your development you must have implicit trust with that firm, or you need internal assets that have the ability to complete the audits separately. There is no magic wand here. But the same risk can be said to exist with inhouse development. We all have heard of employees writing timebombs or backdoors in their code. No difference here. You are just transferring the risk. If you want to trust the code, you need a process in place where you seperate code development from code review. In this way, you need a minimum of two members of the dev team that wish to do harm in your codebase before the risk elevates. Of course, the auditor better know what the hell he or she is doing. Otherwise, stuff will still get through. -- Regards, Dana Epp Microsoft Security MVP On Wed, Nov 26, 2008 at 6:03 PM, Mark Rockman wrote: > OK. So you decide to outsource your programming assignment to Asia and > demand that they deliver code that is so locked down that it cannot > misbehave. How can you tell that what they deliver is truly locked down? > Will you wait until it gets hacked? What simple yet thorough inspection > process is there that'll do the job? Doesn't exist, does it? > > > MARK ROCKMAN > MDRSESCO LLC > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From jim at manico.net Thu Nov 27 16:38:23 2008 From: jim at manico.net (Jim Manico) Date: Thu, 27 Nov 2008 11:38:23 -1000 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: <492F134F.4040709@manico.net> > OK. So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it cannot misbehave. How can you tell that what they deliver is truly locked down? Will you wait until it gets hacked? What simple yet thorough inspection process is there that'll do the job? Doesn't exist, does it? This most important thing you can do is provide very specific security requirements as part of your vendor contract BEFORE you hire a vendor - and the process of building these security requirements might call for bringing in a security consultant if you do not have the expertise in-shop. Requirements that allow a vendor to actually provide security are line items like (assuming its a web app): "Provide input validation for every piece of user data. Do so by mapping every unique piece of user data to a regular expression that is placed inside a configuration file." "Provide CSRF protection by creating and enforcing a form nonce for every user session" After you build this list for your company, it should provide you with a core list of security requirements that you can add to any PO. - Jim > > > MARK ROCKMAN > MDRSESCO LLC > ------------------------------------------------------------------------ > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081127/acd2fe6a/attachment.html From stephencraig.evans at gmail.com Sat Nov 29 05:28:54 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Sat, 29 Nov 2008 18:28:54 +0800 Subject: [SC-L] Introducing my OWASP Summer of Code project, "Securing WebGoat using ModSecurity" Message-ID: <930fd0230811290228o1bf10708s7a917e973977a156@mail.gmail.com> Hi, I did an OWASP Summer of Code 2008 project, "Securing WebGoat using ModSecurity" (actually, it expanded into a Fall of Code project too :-) First, the project should have been named "Protecting WebGoat using ModSecurity" but by the time I figured it out, it was too late to change the title. The goal of the project was to fix as many of the WebGoat vulnerabilities as possible using ModSecurity without changing any of the source code, and I ended up either with solutions or suggestions of solutions - prevention or detection - for 46 of the possible 47 WebGoat sub-lessons. IMO, some interesting parts of it: - The combination of using Lua script on the WAF (back end) and Javascript injection (into the response body) on the front end allows for a complete programming environment (keep in mind that ModSecurity cannot alter the content of HTTP requests or responses, but can prepend and append Javascript to the response) - Using Lua and Javascript injection to mitigate business logic flaws - Using Javascript injection to mitigate 3rd-party attacker kinds of attacks, and enhance the end user experience when ModSecurity has to block a request or response - The documentation is sorta of a primer for ModSecurity (quite a bit of interest in this project has been from infosec people who want to learn more about ModSecurity and WAFs in general) - Included are insightful, invaluable reviewer comments from the project reviewers (Ivan Ristic, Ryan Barnett, and Christian Folini) that you won't find any place else I've put the finishing touches on the project wiki (as far as new content goes) so I thought I would introduce the project here. The project main page: https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project The project wiki: https://www.owasp.org/index.php/OWASP_Securing_WebGoat_using_ModSecurity_Project Appendix D contains a Word file - 134 pages - of the wiki (as of Nov 25); it might be easier to refer to it rather than navigating around inside the wiki. Plus, I put up a ppt prezo from the recent OWASP EU Summit in Portugal, and all future fixes and enhancements to the current ModSecurity solution rulesets will be placed there also. I have been getting some private emails of people actually starting to use the project stuff, so it's time to redirect that to the mailing list. To subscribe: https://lists.owasp.org/mailman/listinfo/owasp-webgoat-using-modsecurity Archives: https://lists.owasp.org/pipermail/owasp-webgoat-using-modsecurity/ I call WAFs, code review, and penetration testing the 3 pillars of the application security portion of PCI-DSS, and I believe that adding a WAF to the toolbox - and being able to write custom rule sets - not only can benefit the client but also can be a career-enhancer (I've already used it on one project). Of course, the percentage of the project that is theoretical/research vs. the percentage that is practical and has real-world value is subject to debate. Anybody wanting to throw some flames are very welcome - I have some pretty thick skin (which started to thicken as a casualty of the classic OS/2-Windows flame wars of the early '90's). I touch on this in the project documentation so I only ask that one reads it first before flaming away :-) Thanks for your attention, Stephen Cheers, Stephen From stephencraig.evans at gmail.com Sat Nov 29 05:56:46 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Sat, 29 Nov 2008 18:56:46 +0800 Subject: [SC-L] Silver Bullet and informIT: Jeremiah Grossman In-Reply-To: References: Message-ID: <930fd0230811290256s32def689qe99002a89fb9a23d@mail.gmail.com> Hi Gary, I think you were on the right path describing software security and illustrating the difference between software security and web app security (even though I don't think it was intentional) when you talked about Pervasive Computing in a BankInfoSecurity podcast (starting at 5 min 10 sec). It should have been obvious to me before, but from that I also picked up on the distinction between applications that need to connect vs. web apps that connect between the client and the application itself. For those interested, the podcast is here: http://www.bankinfosecurity.com/podcasts.php?podcastID=6 (registration required) Stephen On Sat, Nov 15, 2008 at 12:24 AM, Gary McGraw wrote: > hi sc-l, > > Episode 32 of the Silver Bullet Security Podcast went live last night. This episode features a chat with Web security guru Jeremiah Grossman. Among other things, we talk about the relationship between Web app security and software security: > http://www.cigital.com/silverbullet/ > > Jeremiah and I cross paths out there on the evangelism circuit pretty often and it was nice to catch up with him. > > Near the end of our conversation, we raised the idea of whether all Web security problems have analogs in the software security space and what that might mean. After thinking more about that issue, I made it the subject of this month's informIT column: > http://www.informit.com/articles/article.aspx?p=1309290 > > Please let me know what you think about the role that Web application security plays in software security today (and whether you think we focus the right amount of attention, too much, or too little). > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > From jim at manico.net Sat Nov 29 16:08:43 2008 From: jim at manico.net (Jim Manico) Date: Sat, 29 Nov 2008 11:08:43 -1000 Subject: [SC-L] Introducing my OWASP Summer of Code project, "Securing WebGoat using ModSecurity" In-Reply-To: <930fd0230811290228o1bf10708s7a917e973977a156@mail.gmail.com> References: <930fd0230811290228o1bf10708s7a917e973977a156@mail.gmail.com> Message-ID: <4931AF5B.6010905@manico.net> Stephen, Very interesting project. May I ask - how did you solve some of the Access Control labs in webgoat? Some of those access control labs were data-contextual: ie, only certain users had delete access against certain pieces of data. The way students are supposed to solve this data contextual access control lab is to modify the database query in webgoat so the query itself does an access control check to see if the current user can execute delete against this specific object. The only way a WAF could solve that problem would be to either get access to the production database so it could understand the access control rules; or include some of the database data and logic logic inside of your WAF rule. Really curious as to what you did, Jim > Hi, > > I did an OWASP Summer of Code 2008 project, "Securing WebGoat using > ModSecurity" (actually, it expanded into a Fall of Code project too > :-) > > First, the project should have been named "Protecting WebGoat using > ModSecurity" but by the time I figured it out, it was too late to > change the title. > > The goal of the project was to fix as many of the WebGoat > vulnerabilities as possible using ModSecurity without changing any of > the source code, and I ended up either with solutions or suggestions > of solutions - prevention or detection - for 46 of the possible 47 > WebGoat sub-lessons. > > IMO, some interesting parts of it: > - The combination of using Lua script on the WAF (back end) and > Javascript injection (into the response body) on the front end allows > for a complete programming environment (keep in mind that ModSecurity > cannot alter the content of HTTP requests or responses, but can > prepend and append Javascript to the response) > - Using Lua and Javascript injection to mitigate business logic flaws > - Using Javascript injection to mitigate 3rd-party attacker kinds of > attacks, and enhance the end user experience when ModSecurity has to > block a request or response > - The documentation is sorta of a primer for ModSecurity (quite a bit > of interest in this project has been from infosec people who want to > learn more about ModSecurity and WAFs in general) > - Included are insightful, invaluable reviewer comments from the > project reviewers (Ivan Ristic, Ryan Barnett, and Christian Folini) > that you won't find any place else > > I've put the finishing touches on the project wiki (as far as new > content goes) so I thought I would introduce the project here. > > The project main page: > https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project > > The project wiki: > https://www.owasp.org/index.php/OWASP_Securing_WebGoat_using_ModSecurity_Project > > Appendix D contains a Word file - 134 pages - of the wiki (as of Nov > 25); it might be easier to refer to it rather than navigating around > inside the wiki. Plus, I put up a ppt prezo from the recent OWASP EU > Summit in Portugal, and all future fixes and enhancements to the > current ModSecurity solution rulesets will be placed there also. > > I have been getting some private emails of people actually starting to > use the project stuff, so it's time to redirect that to the mailing > list. > > To subscribe: https://lists.owasp.org/mailman/listinfo/owasp-webgoat-using-modsecurity > Archives: https://lists.owasp.org/pipermail/owasp-webgoat-using-modsecurity/ > > I call WAFs, code review, and penetration testing the 3 pillars of the > application security portion of PCI-DSS, and I believe that adding a > WAF to the toolbox - and being able to write custom rule sets - not > only can benefit the client but also can be a career-enhancer (I've > already used it on one project). > > Of course, the percentage of the project that is theoretical/research > vs. the percentage that is practical and has real-world value is > subject to debate. Anybody wanting to throw some flames are very > welcome - I have some pretty thick skin (which started to thicken as a > casualty of the classic OS/2-Windows flame wars of the early '90's). I > touch on this in the project documentation so I only ask that one > reads it first before flaming away :-) > > Thanks for your attention, > Stephen > > > Cheers, > Stephen > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com From stephencraig.evans at gmail.com Sat Nov 29 23:39:55 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Sun, 30 Nov 2008 12:39:55 +0800 Subject: [SC-L] Introducing my OWASP Summer of Code project, "Securing WebGoat using ModSecurity" In-Reply-To: <4931AF5B.6010905@manico.net> References: <930fd0230811290228o1bf10708s7a917e973977a156@mail.gmail.com> <4931AF5B.6010905@manico.net> Message-ID: <930fd0230811292039r4d1c2a03pf95280a7684cf34a@mail.gmail.com> Hi Jim, First, I have to point out - which I do in the documentation - that it wasn't possible to solve every WebGoat lesson for real-world implementation (e.g. session management, concurrent file access, a million users :-). That would take somebody 2 to 3 years to do. So some lesson solutions addressed specifically that particular WebGoat vulnerability (which I call 'quick-and-dirty'); some solutions were generic that could be used in other similar situations (e.g. blacklisting for XSS & injection attacks); some were solved by drilling deep because it was a new concept and an interesting area of research; some were quick-and-dirty fixes but supported by excellent solutions from a reviewer; some I ran out of time but offered a solution; and one was not fixable and I explained why. About the Access Control lessons, 2 were quick-and-dirty fixes, one accompanied by an excellent reviewer comment and a better solution. I believe you are referring a 3rd one, '2 Access Control Flaws -> 2.3 LAB: Role Based Access Control'. Read about it at: https://www.owasp.org/index.php/OWASP_ModSecurity_Securing_WebGoat_Section4_Sublesson_02.3 Basically, I suggest roughly to implement the WebGoat solution - which is to add to the source code a method called 'isAuthorized' - instead in Lua script in ModSecurity (the pieces to do so are implemented in other lessons). Lua can do SQL and can access the file system, so either the access control matrix has to be implemented separately (it can be fronted with a Web app for administrating and can be written in any language) or if possible might be able to hook into an existing access control matrix. I give a suggestion for file formats for this particular lesson's access control matrix. Keep in mind that you have the full flexibility of the Lua programming language at your disposal. So, upon receiving an HTTP request, ModSec checks the role of the user and then determines if that role can access the requested resource. If yes, then it goes through. If no, then it is blocked. Of course, the implementation is not trivial, but if you can't touch the code and the situation requires a solution, then this offers another option. Stephen On Sun, Nov 30, 2008 at 5:08 AM, Jim Manico wrote: > Stephen, > > Very interesting project. > > May I ask - how did you solve some of the Access Control labs in > webgoat? Some of those access control labs were data-contextual: ie, > only certain users had delete access against certain pieces of data. The > way students are supposed to solve this data contextual access control > lab is to modify the database query in webgoat so the query itself does > an access control check to see if the current user can execute delete > against this specific object. > > The only way a WAF could solve that problem would be to either get > access to the production database so it could understand the access > control rules; or include some of the database data and logic logic > inside of your WAF rule. > > Really curious as to what you did, > Jim >> Hi, >> >> I did an OWASP Summer of Code 2008 project, "Securing WebGoat using >> ModSecurity" (actually, it expanded into a Fall of Code project too >> :-) >> >> First, the project should have been named "Protecting WebGoat using >> ModSecurity" but by the time I figured it out, it was too late to >> change the title. >> >> The goal of the project was to fix as many of the WebGoat >> vulnerabilities as possible using ModSecurity without changing any of >> the source code, and I ended up either with solutions or suggestions >> of solutions - prevention or detection - for 46 of the possible 47 >> WebGoat sub-lessons. >> >> IMO, some interesting parts of it: >> - The combination of using Lua script on the WAF (back end) and >> Javascript injection (into the response body) on the front end allows >> for a complete programming environment (keep in mind that ModSecurity >> cannot alter the content of HTTP requests or responses, but can >> prepend and append Javascript to the response) >> - Using Lua and Javascript injection to mitigate business logic flaws >> - Using Javascript injection to mitigate 3rd-party attacker kinds of >> attacks, and enhance the end user experience when ModSecurity has to >> block a request or response >> - The documentation is sorta of a primer for ModSecurity (quite a bit >> of interest in this project has been from infosec people who want to >> learn more about ModSecurity and WAFs in general) >> - Included are insightful, invaluable reviewer comments from the >> project reviewers (Ivan Ristic, Ryan Barnett, and Christian Folini) >> that you won't find any place else >> >> I've put the finishing touches on the project wiki (as far as new >> content goes) so I thought I would introduce the project here. >> >> The project main page: >> https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project >> >> The project wiki: >> https://www.owasp.org/index.php/OWASP_Securing_WebGoat_using_ModSecurity_Project >> >> Appendix D contains a Word file - 134 pages - of the wiki (as of Nov >> 25); it might be easier to refer to it rather than navigating around >> inside the wiki. Plus, I put up a ppt prezo from the recent OWASP EU >> Summit in Portugal, and all future fixes and enhancements to the >> current ModSecurity solution rulesets will be placed there also. >> >> I have been getting some private emails of people actually starting to >> use the project stuff, so it's time to redirect that to the mailing >> list. >> >> To subscribe: https://lists.owasp.org/mailman/listinfo/owasp-webgoat-using-modsecurity >> Archives: https://lists.owasp.org/pipermail/owasp-webgoat-using-modsecurity/ >> >> I call WAFs, code review, and penetration testing the 3 pillars of the >> application security portion of PCI-DSS, and I believe that adding a >> WAF to the toolbox - and being able to write custom rule sets - not >> only can benefit the client but also can be a career-enhancer (I've >> already used it on one project). >> >> Of course, the percentage of the project that is theoretical/research >> vs. the percentage that is practical and has real-world value is >> subject to debate. Anybody wanting to throw some flames are very >> welcome - I have some pretty thick skin (which started to thicken as a >> casualty of the classic OS/2-Windows flame wars of the early '90's). I >> touch on this in the project documentation so I only ask that one >> reads it first before flaming away :-) >> >> Thanks for your attention, >> Stephen >> >> >> Cheers, >> Stephen >> _______________________________________________ >> Secure Coding mailing list (SC-L) SC-L at securecoding.org >> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l >> List charter available at - http://www.securecoding.org/list/charter.php >> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) >> as a free, non-commercial service to the software security community. >> _______________________________________________ >> > > > -- > Jim Manico, Senior Application Security Engineer > jim.manico at aspectsecurity.com | jim at manico.net > (301) 604-4882 (work) > (808) 652-3805 (cell) > > Aspect Security? > Securing your applications at the source > http://www.aspectsecurity.com > > From James.McGovern at thehartford.com Sun Nov 30 12:44:58 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Sun, 30 Nov 2008 12:44:58 -0500 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: <492F134F.4040709@manico.net> References: <492F134F.4040709@manico.net> Message-ID: <9C557D8C6864CA438EF362318A3DF6D502E7F9AB@AD1HFDEXC306.ad1.prod> Enumerating all of the potential weaknesses in software as a requirement to be put into a contract is somewhat problematic on several levels. I guess you can take something like CWE as a starting point and filter down the headers to thinks that only apply to your particular implementation. A better approach would be to filter providers based on security before you even get to the contract stage. For example, ask if they would be willing to procure a copy of a static analysis tool from a vendor such as Ounce Labs, Coverity, etc and then check on the backside to see how many seats they have purchased (e.g. reference check). You can also use as a "proxy" the level of participation by inquiring how deeply and frequently do they participate in local user groups such as OWASP. If they have folks that speak at OWASP events, then they are probably much more security conscious than those who don't. If they don't speak but do attend, that is also better than simply getting the person on the asian vendors side simply telling you whatever is required to close the deal. ________________________________ From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico Sent: Thursday, November 27, 2008 4:38 PM To: Mark Rockman Cc: Secure Mailing List Subject: Re: [SC-L] How Can You Tell It Is Written Securely? > OK. So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it cannot misbehave. How can you tell that what they deliver is truly locked down? Will you wait until it gets hacked? What simple yet thorough inspection process is there that'll do the job? Doesn't exist, does it? This most important thing you can do is provide very specific security requirements as part of your vendor contract BEFORE you hire a vendor - and the process of building these security requirements might call for bringing in a security consultant if you do not have the expertise in-shop. Requirements that allow a vendor to actually provide security are line items like (assuming its a web app): "Provide input validation for every piece of user data. Do so by mapping every unique piece of user data to a regular expression that is placed inside a configuration file." "Provide CSRF protection by creating and enforcing a form nonce for every user session" After you build this list for your company, it should provide you with a core list of security requirements that you can add to any PO. - Jim MARK ROCKMAN MDRSESCO LLC ________________________________ _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security(tm) Securing your applications at the source http://www.aspectsecurity.com ************************************************************ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081130/041be4b0/attachment.html From herman.stevens at astyran.be Mon Dec 1 09:59:58 2008 From: herman.stevens at astyran.be (Herman Stevens) Date: Mon, 1 Dec 2008 15:59:58 +0100 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? Message-ID: Hello Jim, I tend to disagree with your statement that security requirements should be part of contractual agreements or added to a purchase order. In the Real World (? ?) this does not work. Once signed, contracts are never looked at again, unless the shit hits the fan and someone must be blamed for something that went wrong. Development teams (which is a lot broader than the term developers) _never_ read contracts or look at purchase orders. In itself, security statements in a paper nobody reads but the corporate lawyers will not make any application more secure. Lawyers will go over contracts and purchase orders and I shudder to what will happen if they disagree on a technical term in your ?security requirements?. Please define (in legal terms) ??configuration file?, ?user data?, ?regular expression?, ?form nonce? ?. ??Note that none of the business people responsible for the ?security? of the application/business process will understand anything of this, although they are ultimately responsible ? IMHO all this (detailed technical requirements in contracts) is part of the security theater and does not aid in making applications more secure (whatever that term ? ?secure? - means), it just aids in creating auditor checklists that can be completed by junior auditors that don?t know anything about application development. Or let the process control people create a CMM dashboard with a green light. The most you can expect from a contract is very high level statements, and once they are high-level, will they aid in the objective o have secure software? In my experience, once a contract is signed, the development team will create the functional requirements (or whatever this document is called in their methodology), and this document will result in a functional specification document, that requires sign-off by the customer before one line of code is written (don?t get me started on ?agile? development). If it is not in this specification, it will not be part of the code nor the tests afterwards nor the acceptance tests of the customers. The most important thing to notice here is that the trick to make the application more ?secure? (or at least abide to what people call here ?secure development best practices? ? who decides what is ?best practice? anyway...) is to have the security requirements part of the standard documentation used in their methodology. ?Train the person who creates the requirements document to rewrite statements as ?click ?a- to do something? in ?click ?a- to do something and ignore all other inputs?. There is of course a lot more to this, but this email is already getting too long. ? Recommendation: Do not create a separate ?security requirements? document because it will not be used (real life example: ?yes there is always a statement in our functional requirements that we must include the requirements of the security policy/requirements document but we never look at those documents, because we are already developing for many years so we should be OK ??. Important remark: most security people will tell that you must do ?security testing? but completely fail to understand how bigger development shops work. All tests are created from the functional specification document! Need better input validation? Rewrite the functional specs! Note that there are a lot of standard methodologies to create tests from a functional spec document ? all unknown to most security people - and that many big development shops completely outsource this part of the development process. Note that the above in itself is not enough, some other design/architecture/implementation/test ?controls? (I hate this word) are necessary. But start with the basics: secure development starts with having a good writer ? not a coder, tester, architect, designer - ?with a common knowledge of security for your functional requirements/specification document. Do not 'add' a security layer on top of something, but 'include' security. Please note that all opinions are my own and that I?m not aware of any independent ? and unbiased - studies that proof or disproof anything in mine or your email. ? Unfortunately the Information Security Profession has not reached the maturity to look and study what really matters in an objective way. So you are stuck with my biased opinion for now. But this opinion is based on a career as developer, security consultant, auditor and security manager so I hope it gives valuable insights or start a discussion so I can learn, maybe change my insights and better serve my customers. ? Sincerely, Herman Stevens Herman.Stevens at astyran.be http://www.astyran.be From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico Sent: donderdag 27 november 2008 22:38 To: Mark Rockman Cc: Secure Mailing List Subject: Re: [SC-L] How Can You Tell It Is Written Securely? >? OK.? So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it?cannot misbehave.? How can you tell that what they deliver is truly locked down?? Will you wait until it gets hacked?? What simple yet thorough inspection process is there that'll do the job?? Doesn't exist, does it? This most important thing you can do is provide very specific security requirements as part of your vendor contract BEFORE you hire a vendor - and the process of building these security requirements might call for bringing in a security consultant if you do not have the expertise in-shop. Requirements that allow a vendor to actually provide security are line items like (assuming its a web app): "Provide input validation for every piece of user data. Do so by mapping every unique piece of user data? to a regular expression that is placed inside a configuration file." "Provide CSRF protection by creating and enforcing a form nonce for every user session" After you build this list for your company, it should provide you with a core list of security requirements that you can add to any PO. - Jim From stephencraig.evans at gmail.com Mon Dec 1 09:50:14 2008 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Mon, 1 Dec 2008 22:50:14 +0800 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: <930fd0230812010650q355919eckc89131515ce6c7a9@mail.gmail.com> Hi Mark, What I have seen is that the organization develops security standards/guidelines and secure coding guidelines tailored to the org. If the org is big enough to have its own security team, then they do it; if not, then they hire consultants to do it. It's not too difficult to find out amongst the consultants who has the experience and who doesn't. Those standards and guidelines are updated either every year or two, or before the next big project. External consultant(s) - not the internal security team within the organization (if it exists) - then does audits at milestones of the project implemented by the outsourcing organization and reports on the conformance to the guidelines and standards, and anything else that might have been left out (which then results in updated standards and guidelines). For non-conformant issues, the 3 groups get together and decide what to do about it. If a direct solution is not possible, often other security controls can be tweaked or enhanced to make that particular risk acceptable or eliminated. This type of system has clear separation of duties. Stephen On Thu, Nov 27, 2008 at 10:03 AM, Mark Rockman wrote: > OK. So you decide to outsource your programming assignment to Asia and > demand that they deliver code that is so locked down that it cannot > misbehave. How can you tell that what they deliver is truly locked down? > Will you wait until it gets hacked? What simple yet thorough inspection > process is there that'll do the job? Doesn't exist, does it? > > > MARK ROCKMAN > MDRSESCO LLC > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > > From marcinw86 at gmail.com Mon Dec 1 11:06:23 2008 From: marcinw86 at gmail.com (Marcin Wielgoszewski) Date: Mon, 1 Dec 2008 11:06:23 -0500 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: Steven, There are more than several managers of application security programs for F-100 companies that have written security requirements into their SLA's with outsourced development firms. One example uses application penetration testing and vulnerability assessment findings to enforce SLA requirements. Some companies employ an entire team of people to perform both whitebox and blackbox testing in addition to external/3rd-party assessments. And as you later state, security requirements should be written into the functional requirements, and not handed off in its own category or as some appendix document. -Marcin tssci-security.com On Mon, Dec 1, 2008 at 9:59 AM, Herman Stevens wrote: > I tend to disagree with your statement that security requirements should be part of contractual agreements or added to a purchase order. In the Real World (? ?) this does not work. Once signed, contracts are never looked at again, unless the shit hits the fan and someone must be blamed for something that went wrong. Development teams (which is a lot broader than the term developers) _never_ read contracts or look at purchase orders. > From herman.stevens at astyran.be Mon Dec 1 13:54:51 2008 From: herman.stevens at astyran.be (Herman Stevens) Date: Mon, 1 Dec 2008 19:54:51 +0100 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: Hello Marcin, I agree with your statement that many companies have some requirements in their SLA's with outsourced development firms. However, if these are really F-100 businesses they usually have all non-core processes out-sourced (because a Big4 company told them that would reduce costs), the relationship management with the outsourced companies is also out-sourced (probably to the same Big4). This means after a few years all knowledge has left the company and if a Request For Proposal needs to be written (e.g. for a new application supporting their core business functions) this is outsourced again to the same Big4 since the company itself does not even have the required knowledge to write its own RFPs ... I really doubt that anything that goes in that RFP (and ultimately in the contracts) will have any _real_ security value. Using penetration tests and vulnerability requirements might be part of the acceptance process, but I do not call these tests _security_ requirements. They are acceptance requirements ... The original request asked for how can someone determine if an application is written in a secure manner. My reasoning is that this is the wrong question (the application must _be_ secure and for this there is no direct link with coding practices). And even if one can proof the application is written in a secure manner, this will not be enough to be secure (e.g. about 99% of all security relevant features are nowadays in the configuration, the customer will never issue a change request for a new java library of javascript library yet in many of my penetration tests I 'break' the application because of old libs, ...). I do not think that penetration tests and vulnerability assessments are a 'proof' that an application is written securely. I've seen many applications that were written horrendously but were very secure (in the sense that they abided to all security-relevant business requirements) and I have seen many applications written using the 'best practices' in coding and developed with very mature processes that could be hacked in minutes. So, are there any studies that proof that a company that performs some tests (e.g. pen-tests) or include security requirements in the contracts ultimately is better off than a company that does not do what we consider 'best practices'? And if we don't have that proof, shouldn't we be very prudent in what we advise to our customers? Please note that my company sells security related software and performs vulnerability assessments, so I'm not saying that these are useless (:)), but maybe there are better methods than penetrate & patch or enforcing very heavy processes on innocent development teams... So, this is question to this list: Are we on the right track? Is application security really improving? Do we measure the correct things and in the correct way? My point of view is that only certain vulnerabilities are less common than in the early days just because of more mature frameworks, but not due to better processes or after the fact testing. Does this mean all efforts were vain? Or did the threat landscape change? And yes, there are many vendor driven statistics floating around but they really cannot be considered unbiased ... Lots of questions, maybe not all relevant for the Secure Coding list, but Secure Coding should have an final objective. Or not? Herman herman.stevens at astyran.be -----Original Message----- From: Marcin Wielgoszewski [mailto:marcinw86 at gmail.com] Sent: maandag 1 december 2008 17:06 To: Herman Stevens Cc: SC-L at securecoding.org Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? Steven, There are more than several managers of application security programs for F-100 companies that have written security requirements into their SLA's with outsourced development firms. One example uses application penetration testing and vulnerability assessment findings to enforce SLA requirements. Some companies employ an entire team of people to perform both whitebox and blackbox testing in addition to external/3rd-party assessments. And as you later state, security requirements should be written into the functional requirements, and not handed off in its own category or as some appendix document. -Marcin tssci-security.com From ljknews at mac.com Thu Nov 27 07:11:15 2008 From: ljknews at mac.com (ljknews) Date: Thu, 27 Nov 2008 07:11:15 -0500 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: At 9:03 PM -0500 11/26/08, Mark Rockman wrote: > OK. So you decide to outsource your programming assignment to Asia and >demand that they deliver code that is so locked down that it cannot >misbehave. How can you tell that what they deliver is truly locked down? >Will you wait until it gets hacked? What simple yet thorough inspection >process is there that'll do the job? Doesn't exist, does it? Certainly it exists. Rerun the verification of the formal proof, as used in the Tokeneer project I mentioned earlier. Of course a formal proof only proves that software conforms to a specification, so unless you have a specification you have nothing, and that is what a lot of software is lacking. -- Larry Kilgallen From James.McGovern at thehartford.com Mon Dec 1 14:49:21 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 1 Dec 2008 14:49:21 -0500 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? In-Reply-To: References: Message-ID: <9C557D8C6864CA438EF362318A3DF6D502E7FBB5@AD1HFDEXC306.ad1.prod> Asking about security in terms of an RFP is a big joke and reminds me of tactics I used in sixth grade when I used to figure out creative ways of answering a question by turning the question into an answer. One has to acknowledge that RFPs are not authoratative and are usually completed by sales teams who don't have adequate detail. So, instead of focusing on comprehensive documentation, you need to be agile and think more about working software. I believe that penetration tests are sadly too late in the process in order to be meaningful and only have value in scenarios where you can mandate that the presses be stopped and that they fix immediately before you give them a single penny. Avoid the contract stuff as well as you can't really put meaningful things into agreements. You have to acknowledge that if I were successful in putting say a clause into our next EMC agreement requiring all document management software to support XACML and be OWASP Top Ten free, do you think that a developer on the other end would even have a chance to read it and address going forward? Way too many degrees of separation between those who write contracts and those who implement software. Again, I think you need to measure developers and their participation in groups such as OWASP since it is observable and measurable without requiring a lot of effort. It is not a guarantee but can be a predictor... -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Herman Stevens Sent: Monday, December 01, 2008 1:55 PM To: Marcin Wielgoszewski Cc: SC-L at securecoding.org Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? Hello Marcin, I agree with your statement that many companies have some requirements in their SLA's with outsourced development firms. However, if these are really F-100 businesses they usually have all non-core processes out-sourced (because a Big4 company told them that would reduce costs), the relationship management with the outsourced companies is also out-sourced (probably to the same Big4). This means after a few years all knowledge has left the company and if a Request For Proposal needs to be written (e.g. for a new application supporting their core business functions) this is outsourced again to the same Big4 since the company itself does not even have the required knowledge to write its own RFPs .. I really doubt that anything that goes in that RFP (and ultimately in the contracts) will have any _real_ security value. Using penetration tests and vulnerability requirements might be part of the acceptance process, but I do not call these tests _security_ requirements. They are acceptance requirements ... The original request asked for how can someone determine if an application is written in a secure manner. My reasoning is that this is the wrong question (the application must _be_ secure and for this there is no direct link with coding practices). And even if one can proof the application is written in a secure manner, this will not be enough to be secure (e.g. about 99% of all security relevant features are nowadays in the configuration, the customer will never issue a change request for a new java library of javascript library yet in many of my penetration tests I 'break' the application because of old libs, ...). I do not think that penetration tests and vulnerability assessments are a 'proof' that an application is written securely. I've seen many applications that were written horrendously but were very secure (in the sense that they abided to all security-relevant business requirements) and I have seen many applications written using the 'best practices' in coding and developed with very mature processes that could be hacked in minutes. So, are there any studies that proof that a company that performs some tests (e.g. pen-tests) or include security requirements in the contracts ultimately is better off than a company that does not do what we consider 'best practices'? And if we don't have that proof, shouldn't we be very prudent in what we advise to our customers? Please note that my company sells security related software and performs vulnerability assessments, so I'm not saying that these are useless (:)), but maybe there are better methods than penetrate & patch or enforcing very heavy processes on innocent development teams... So, this is question to this list: Are we on the right track? Is application security really improving? Do we measure the correct things and in the correct way? My point of view is that only certain vulnerabilities are less common than in the early days just because of more mature frameworks, but not due to better processes or after the fact testing. Does this mean all efforts were vain? Or did the threat landscape change? And yes, there are many vendor driven statistics floating around but they really cannot be considered unbiased ... Lots of questions, maybe not all relevant for the Secure Coding list, but Secure Coding should have an final objective. Or not? Herman herman.stevens at astyran.be ************************************************************ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************ From jim at manico.net Mon Dec 1 16:44:09 2008 From: jim at manico.net (Jim Manico) Date: Mon, 01 Dec 2008 11:44:09 -1000 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? In-Reply-To: <9C557D8C6864CA438EF362318A3DF6D502E7FBB5@AD1HFDEXC306.ad1.prod> References: <9C557D8C6864CA438EF362318A3DF6D502E7FBB5@AD1HFDEXC306.ad1.prod> Message-ID: <49345AA9.1000609@manico.net> I think adding clear security requirements at the contractual level is *fundamental and necessary* when yes? yesworking with vendors who are writing software for you. Don't we talk about software security as being just another integrated part of writing software, not as an external activity? I'm not talking about foolish general requirements like "Be OWASP top 10 free" that does not help anyone. I'm talking about clear, somewhat undebatable requirements like: 1) Add in CSRF protection by using a form nonce 2) Make every field maps to a unique regular expression. Ensure that this regular expression exists in a properties file so it can be configured without needing to recompile code. 3) Ensure that every piece of user-driven data is encoded via HTML Entity Encoding before it is displayed to any user. 4) Use only prepared statements and binding of variables when selecting from a database Etc. Sure, we want our vendors to be security educated (good luck finding them these days). But really, we need to get the job done. We need to hire vendors. It's likely that software development vendors are not super security educated since software security is so new. We need to communicate contractual requirements anyways and those agreements do indeed matter. Our best bet is to add in clear functional security requirements to our contractual agreements if we have any hope of them being built in in a cost effective manner. - Jim > Asking about security in terms of an RFP is a big joke and reminds me > of tactics I used in sixth grade when I used to figure out creative ways > of answering a question by turning the question into an answer. One has > to acknowledge that RFPs are not authoratative and are usually completed > by sales teams who don't have adequate detail. > > So, instead of focusing on comprehensive documentation, you need to be > agile and think more about working software. I believe that penetration > tests are sadly too late in the process in order to be meaningful and > only have value in scenarios where you can mandate that the presses be > stopped and that they fix immediately before you give them a single > penny. > > Avoid the contract stuff as well as you can't really put meaningful > things into agreements. You have to acknowledge that if I were > successful in putting say a clause into our next EMC agreement requiring > all document management software to support XACML and be OWASP Top Ten > free, do you think that a developer on the other end would even have a > chance to read it and address going forward? Way too many degrees of > separation between those who write contracts and those who implement > software. > > Again, I think you need to measure developers and their participation in > groups such as OWASP since it is observable and measurable without > requiring a lot of effort. It is not a guarantee but can be a > predictor... > > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Herman Stevens > Sent: Monday, December 01, 2008 1:55 PM > To: Marcin Wielgoszewski > Cc: SC-L at securecoding.org > Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? > > Hello Marcin, > > I agree with your statement that many companies have some requirements > in their SLA's with outsourced development firms. However, if these are > really F-100 businesses they usually have all non-core processes > out-sourced (because a Big4 company told them that would reduce costs), > the relationship management with the outsourced companies is also > out-sourced (probably to the same Big4). This means after a few years > all knowledge has left the company and if a Request For Proposal needs > to be written (e.g. for a new application supporting their core business > functions) this is outsourced again to the same Big4 since the company > itself does not even have the required knowledge to write its own RFPs > .. > > I really doubt that anything that goes in that RFP (and ultimately in > the contracts) will have any _real_ security value. > > Using penetration tests and vulnerability requirements might be part of > the acceptance process, but I do not call these tests _security_ > requirements. They are acceptance requirements ... > > The original request asked for how can someone determine if an > application is written in a secure manner. My reasoning is that this is > the wrong question (the application must _be_ secure and for this there > is no direct link with coding practices). And even if one can proof the > application is written in a secure manner, this will not be enough to be > secure (e.g. about 99% of all security relevant features are nowadays in > the configuration, the customer will never issue a change request for a > new java library of javascript library yet in many of my penetration > tests I 'break' the application because of old libs, ...). > > I do not think that penetration tests and vulnerability assessments are > a 'proof' that an application is written securely. I've seen many > applications that were written horrendously but were very secure (in the > sense that they abided to all security-relevant business requirements) > and I have seen many applications written using the 'best practices' in > coding and developed with very mature processes that could be hacked in > minutes. > > So, are there any studies that proof that a company that performs some > tests (e.g. pen-tests) or include security requirements in the contracts > ultimately is better off than a company that does not do what we > consider 'best practices'? And if we don't have that proof, shouldn't we > be very prudent in what we advise to our customers? > > Please note that my company sells security related software and performs > vulnerability assessments, so I'm not saying that these are useless > (:)), but maybe there are better methods than penetrate & patch or > enforcing very heavy processes on innocent development teams... So, this > is question to this list: Are we on the right track? Is application > security really improving? Do we measure the correct things and in the > correct way? My point of view is that only certain vulnerabilities are > less common than in the early days just because of more mature > frameworks, but not due to better processes or after the fact testing. > Does this mean all efforts were vain? Or did the threat landscape > change? And yes, there are many vendor driven statistics floating around > but they really cannot be considered unbiased ... Lots of questions, > maybe not all relevant for the Secure Coding list, but Secure Coding > should have an final objective. Or not? > > Herman > herman.stevens at astyran.be > ************************************************************ > This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. > ************************************************************ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security? Securing your applications at the source http://www.aspectsecurity.com From James.McGovern at thehartford.com Mon Dec 1 17:01:43 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 1 Dec 2008 17:01:43 -0500 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? In-Reply-To: <49345AA9.1000609@manico.net> References: <9C557D8C6864CA438EF362318A3DF6D502E7FBB5@AD1HFDEXC306.ad1.prod> <49345AA9.1000609@manico.net> Message-ID: <9C557D8C6864CA438EF362318A3DF6D50303B30F@AD1HFDEXC306.ad1.prod> I am of the belief that the examples you provided are more requirements for your own staff. For example, shouldn't your business analysts define regular expressions and include them as functional requirements where the firm simply calls them? If you want regex's externalized into properties files, shouldn't this be more about specifying acceptance criteria for the overall design vs waiting to measure it against code. For number three, you would have to think about such a clause as it is an out if performance isn't met. If you work for a large enterprise, I would think that number 4 would be encompassed into asking them to align with consistent DB access practices where you hand them your coding standards. It is different to have coding standards and having clauses that ask others to adhere to them vs embedding coding type requirements into the contracts themselves. -----Original Message----- From: Jim Manico [mailto:jim at manico.net] Sent: Monday, December 01, 2008 4:44 PM To: McGovern, James F (HTSC, IT) Cc: SC-L at securecoding.org Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? I think adding clear security requirements at the contractual level is *fundamental and necessary* when yes? yesworking with vendors who are writing software for you. Don't we talk about software security as being just another integrated part of writing software, not as an external activity? I'm not talking about foolish general requirements like "Be OWASP top 10 free" that does not help anyone. I'm talking about clear, somewhat undebatable requirements like: 1) Add in CSRF protection by using a form nonce 2) Make every field maps to a unique regular expression. Ensure that this regular expression exists in a properties file so it can be configured without needing to recompile code. 3) Ensure that every piece of user-driven data is encoded via HTML Entity Encoding before it is displayed to any user. 4) Use only prepared statements and binding of variables when selecting from a database Etc. Sure, we want our vendors to be security educated (good luck finding them these days). But really, we need to get the job done. We need to hire vendors. It's likely that software development vendors are not super security educated since software security is so new. We need to communicate contractual requirements anyways and those agreements do indeed matter. Our best bet is to add in clear functional security requirements to our contractual agreements if we have any hope of them being built in in a cost effective manner. - Jim > Asking about security in terms of an RFP is a big joke and reminds me > of tactics I used in sixth grade when I used to figure out creative > ways of answering a question by turning the question into an answer. > One has to acknowledge that RFPs are not authoratative and are usually > completed by sales teams who don't have adequate detail. > > So, instead of focusing on comprehensive documentation, you need to be > agile and think more about working software. I believe that > penetration tests are sadly too late in the process in order to be > meaningful and only have value in scenarios where you can mandate that > the presses be stopped and that they fix immediately before you give > them a single penny. > > Avoid the contract stuff as well as you can't really put meaningful > things into agreements. You have to acknowledge that if I were > successful in putting say a clause into our next EMC agreement > requiring all document management software to support XACML and be > OWASP Top Ten free, do you think that a developer on the other end > would even have a chance to read it and address going forward? Way too > many degrees of separation between those who write contracts and those > who implement software. > > Again, I think you need to measure developers and their participation > in groups such as OWASP since it is observable and measurable without > requiring a lot of effort. It is not a guarantee but can be a > predictor... > > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Herman Stevens > Sent: Monday, December 01, 2008 1:55 PM > To: Marcin Wielgoszewski > Cc: SC-L at securecoding.org > Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? > > Hello Marcin, > > I agree with your statement that many companies have some requirements > in their SLA's with outsourced development firms. However, if these > are really F-100 businesses they usually have all non-core processes > out-sourced (because a Big4 company told them that would reduce > costs), the relationship management with the outsourced companies is > also out-sourced (probably to the same Big4). This means after a few > years all knowledge has left the company and if a Request For Proposal > needs to be written (e.g. for a new application supporting their core > business > functions) this is outsourced again to the same Big4 since the company > itself does not even have the required knowledge to write its own RFPs > .. > > I really doubt that anything that goes in that RFP (and ultimately in > the contracts) will have any _real_ security value. > > Using penetration tests and vulnerability requirements might be part > of the acceptance process, but I do not call these tests _security_ > requirements. They are acceptance requirements ... > > The original request asked for how can someone determine if an > application is written in a secure manner. My reasoning is that this > is the wrong question (the application must _be_ secure and for this > there is no direct link with coding practices). And even if one can > proof the application is written in a secure manner, this will not be > enough to be secure (e.g. about 99% of all security relevant features > are nowadays in the configuration, the customer will never issue a > change request for a new java library of javascript library yet in > many of my penetration tests I 'break' the application because of old libs, ...). > > I do not think that penetration tests and vulnerability assessments > are a 'proof' that an application is written securely. I've seen many > applications that were written horrendously but were very secure (in > the sense that they abided to all security-relevant business > requirements) and I have seen many applications written using the > 'best practices' in coding and developed with very mature processes > that could be hacked in minutes. > > So, are there any studies that proof that a company that performs some > tests (e.g. pen-tests) or include security requirements in the > contracts ultimately is better off than a company that does not do > what we consider 'best practices'? And if we don't have that proof, > shouldn't we be very prudent in what we advise to our customers? > > Please note that my company sells security related software and > performs vulnerability assessments, so I'm not saying that these are > useless (:)), but maybe there are better methods than penetrate & > patch or enforcing very heavy processes on innocent development > teams... So, this is question to this list: Are we on the right track? > Is application security really improving? Do we measure the correct > things and in the correct way? My point of view is that only certain > vulnerabilities are less common than in the early days just because of > more mature frameworks, but not due to better processes or after the fact testing. > Does this mean all efforts were vain? Or did the threat landscape > change? And yes, there are many vendor driven statistics floating > around but they really cannot be considered unbiased ... Lots of > questions, maybe not all relevant for the Secure Coding list, but > Secure Coding should have an final objective. Or not? > > Herman > herman.stevens at astyran.be > ************************************************************ > This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. > ************************************************************ > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org List > information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) as a free, non-commercial service to the software security community. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer jim.manico at aspectsecurity.com | jim at manico.net (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security(tm) Securing your applications at the source http://www.aspectsecurity.com ************************************************************ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************ From James.McGovern at thehartford.com Mon Dec 1 17:08:49 2008 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 1 Dec 2008 17:08:49 -0500 Subject: [SC-L] FW: How Can You Tell It Is Written Securely? In-Reply-To: <49345AA9.1000609@manico.net> References: <9C557D8C6864CA438EF362318A3DF6D502E7FBB5@AD1HFDEXC306.ad1.prod> <49345AA9.1000609@manico.net> Message-ID: <9C557D8C6864CA438EF362318A3DF6D50303B312@AD1HFDEXC306.ad1.prod> Some other thoughts that I haven't heard others mention? 1. OK, if you find that they didn't meet all the security requirements, will your business customers still want you to put it into production anyway? If the answer is yes, do you still want them to support it? How do we quantify who is responsible if a breach happens and you gave them a waiver. 2. security clauses have a side effect in contracts that others need to noodle. If you have a clause that can only be measured over a longer timespan, it tickers with revenue recognition. So, how long do you want folks to certify that things are secure. 3. I like secure coding as much as the next guy and checking for CSRF is a good thing. How about noodling requirements around logging such that if they didn't get it right upfront that you at least have something forensically useful for after the fact? 4. While we are all developers, do you think there is merit in addressing roles of vendors especially non-development? For example, is it valuable to have them have on staff a security architect with lots of credentials that is separate from the development lifecycle (distinct from being totally ivory tower or hands-off)? 5. How much more are folks willing to pay to build security in? This kinda doesn't align with going offshore to get cheapest resource. It is in their best interest to be an impediment to this goal and you need to define things in a more friendly manner. Coming out of the gate by throwing others under the bus probably will not get you what you desire (of course, it is a tactic I use way too much) ************************************************************ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************ From vanderaj at owasp.org Tue Dec 2 13:47:40 2008 From: vanderaj at owasp.org (Andrew van der Stock) Date: Tue, 2 Dec 2008 13:47:40 -0500 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: <9C557D8C6864CA438EF362318A3DF6D502E7F9AB@AD1HFDEXC306.ad1.prod> References: <492F134F.4040709@manico.net> <9C557D8C6864CA438EF362318A3DF6D502E7F9AB@AD1HFDEXC306.ad1.prod> Message-ID: <7C2BE8B9-21F2-42CF-A749-C54B47A8CC5A@owasp.org> Hi James, You're absolutely correct - trying to come up with countermeasures for 730+ issues is crazy. It's much better to have valid controls for the minimum number of things that must be done right, and if they are, then hey presto, attacks using one or more of those 730+ vulnerability classifications either do not work, do no to little damage, and may be even trigger an intrusion escalation procedure. I have never seen the point of most of the security attack "research" going on up to this point: knowing about attacks in software ("hey ISV, you've got a security 0 day here! Look at me! Look at me! I'm more important than the guys who write this stuff! No look at me, I'm so cool!"). Such venal self promotion does not protect that software. Secure apps can only come about about the other way around, and only if the architects and devs know what they have to do. That's why I've been on the front end of the development process for a long time. To that end, I've been working on the OWASP Secure Coding Standard for a little while now. It'll be the 16 or so categories of things you MUST, SHOULD and MAY do well to write secure software depending on a risk assessment of your apps data asset classification and processes. I'm designing it to be scalable from single developer self assessed open source projects through to major project teams, and plus, I'm making very few things "MUST" and ensuring the outcome can be detected in multiple ways. The end result should a technically more secure system that avoids most of the 730+ CWE issues by doing as little work as possible, but what work is done is effective. The Coding Standard will be the Standards portion of the piece ("thou shalt..."), whereas the Developer Guide will be more "This is how you do X well". Both will reflect the forthcoming OWASP Application Security Verification Standard (ASVS), which links into Dana's post about auditing code for evidence of security. So essentially: 1. Coding Standard -> Things you have to do, should be an annex to the contract 2. Developer Guide -> How to do the things noted in the Coding Standard, which the architects and developers can refer to over the sprints and milestones. Not enforceable per se - it's more of a dictionary of "the right way to do it" 3. ASVS -> How to verify that the code or app you've received is compliant with #1, and should be an annex to the contract as well, so it can be formally verified using automated and manual testing techniques both by the developer and the receiver of the software. thanks, Andrew On Nov 30, 2008, at 12:44 PM, McGovern, James F (HTSC, IT) wrote: > Enumerating all of the potential weaknesses in software as a > requirement to be put into a contract is somewhat problematic on > several levels. I guess you can take something like CWE as a > starting point and filter down the headers to thinks that only apply > to your particular implementation. A better approach would be to > filter providers based on security before you even get to the > contract stage. For example, ask if they would be willing to procure > a copy of a static analysis tool from a vendor such as Ounce Labs, > Coverity, etc and then check on the backside to see how many seats > they have purchased (e.g. reference check). > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2458 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081202/cdfcd2b7/attachment.bin From ljknews at mac.com Tue Dec 2 14:35:34 2008 From: ljknews at mac.com (ljknews) Date: Tue, 02 Dec 2008 14:35:34 -0500 Subject: [SC-L] How Can You Tell It Is Written Securely? In-Reply-To: <7C2BE8B9-21F2-42CF-A749-C54B47A8CC5A@owasp.org> References: <492F134F.4040709@manico.net> <9C557D8C6864CA438EF362318A3DF6D502E7F9AB@AD1HFDEXC306.ad1.prod> <7C2BE8B9-21F2-42CF-A749-C54B47A8CC5A@owasp.org> Message-ID: At 1:47 PM -0500 12/2/08, Andrew van der Stock wrote: > Content-Type: multipart/signed; boundary=Apple-Mail-3-828357388; micalg=sha1; > protocol="application/pkcs7-signature" > > Hi James, > > You're absolutely correct - trying to come up with countermeasures for > 730+ issues is crazy. It's much better to have valid controls for the > minimum number of things that must be done right, and if they are, > then hey presto, attacks using one or more of those 730+ vulnerability > classifications either do not work, do no to little damage, and may be > even trigger an intrusion escalation procedure. Some of the very important control requirements for 800-53, 8500.2 and PCI DSS have to do with Auditing. Even if some irregularity is caused by malfunctioning software rather than by malicious behavior, having auditing enabled is crucial to figuring out what _is_ going on. -- Larry Kilgallen From gem at cigital.com Fri Dec 5 15:31:59 2008 From: gem at cigital.com (Gary McGraw) Date: Fri, 5 Dec 2008 15:31:59 -0500 Subject: [SC-L] Book: Web Security Testing Cookbook Message-ID: <41945506397C0C4886A8C5BFF089B5CA359912EADA@va-mailhub.cigital.com> Hi sc-l, Paco Hope and Ben Walther just wrote a book on hands-on web security testing focused on tool use. I wrote the foreword for the book and posted it to Justice League: http://www.cigital.com/justiceleague/2008/12/05/new-book-web-security-testing-cookbook/ Yeah I know...web, web, web. Well, what you gonna do?! gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com From goertzel_karen at bah.com Fri Dec 5 15:45:10 2008 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 5 Dec 2008 15:45:10 -0500 Subject: [SC-L] Enhancing the Development Life Cycle to Produce Secure Software Message-ID: <184D5FFC5203644FB4F8864B0EE445B401F4A710@MCLNEXVS06.resource.ds.bah.com> The Department of Homeland Security Software Assurance Program's "Enhancing the Development Life Cycle to Produce Secure Software" (which supercedes their previous guidance document on secure software development, "Security in the Software Life Cycle") can be downloaded - after free online registration - from the DoD Data and Analysis Center for Software's website at: https://www.thedacs.com/techs/enhanced_life_cycles/ -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081205/4bf8f897/attachment.html From ken at krvw.com Thu Dec 11 05:42:27 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 11 Dec 2008 05:42:27 -0500 Subject: [SC-L] Fwd: ESSoS'09: Call for Participation References: <200812091422.15553.bart.dewin@cs.kuleuven.be> Message-ID: <831C9D38-5EDD-4C34-AA1C-C3B8F053C91B@krvw.com> FYI, see Call for Participation below. Cheers, Ken van Wyk Begin forwarded message: > From: Bart De Win > Date: December 9, 2008 8:22:14 AM EST > To: bart.dewin at cs.kuleuven.be > Subject: ESSoS'09: Call for Participation > > CALL FOR PARTICIPATION > > International Symposium on > Engineering Secure Software and Systems (ESSoS'09) > In collaboration with ACM SIGSAC/SIGSOFT and IEEE TCSE > > http://distrinet.cs.kuleuven.be/events/essos2009/ > February 04-06, 2009 Leuven, Belgium > > You are cordially invited to attend ESSoS, a conference-level event > that > provides a unique research and practitioners' view on the state of > the art > in secure software engineering. There are many good reasons for you to > participate (and ditto arguments to convince your supervisor or > boss). The > program includes invited talks by two renowned researchers, as well as > technical papers on a variety of topics ranging from program > transformation to testing and assurance. Being the first edition in a > future series, this is the time to join this growing community, meet > new > people and interact with peers. As an industry representative, you > might > be especially interested in the tutorials, which address current > challenges and best practices in secure software construction. And > last > but not least, the symposium takes place in Leuven, a very enjoyable > and > historic city with a strong tradition in beer brewing. > > The program consists of three days, one day of tutorials and two > days of > technical program, including among others: > * Invited talks: > - Elaborating Security Requirements by Analysis of Malicious > Anti-Models > (Axel van Lamsweerde, Universit? Catholique de Louvain) > - Automating Software Testing Using Program Analysis > (Wolfram Schulte, Microsoft Research) > > * Tutorials: > - Security by Construction > (Rod Champan, Praxis) > - Risk Management in Practice: Model Based Security Risk Analysis > with > the CORAS Method > (Heidi Dahl and Mass Lund, SINTEF) > - Inside the Biggest of the OWASP Top-10 Issues > (Kenneth R. van Wyk, KRvW Associates) > - Security: Philosophy, Patterns and Practices > (Munawar Hafiz, University of Illinois at Urbana-Champaign) > > * Technical program: > - a list of accepted papers is available at > http://distrinet.cs.kuleuven.be/events/essos2009/papers > > EARLY REGISTRATION DEADLINE: January 6, 2009 > > We're looking forward to meeting you all there ! > > Bart De Win (General Chair) > Fabio Massacci and Samuel Redwine (PC co-Chairs) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081211/cafc434c/attachment.bin From rcs at cert.org Mon Dec 15 13:42:49 2008 From: rcs at cert.org (Robert Seacord) Date: Mon, 15 Dec 2008 13:42:49 -0500 Subject: [SC-L] Robert Seacord on the CERT C Secure Coding Standard In-Reply-To: <9C557D8C6864CA438EF362318A3DF6D5025EF385@AD1HFDEXC306.ad1.prod> References: <41945506397C0C4886A8C5BFF089B5CA354B2A3A47@va-mailhub.cigital.com> <9C557D8C6864CA438EF362318A3DF6D5025EF385@AD1HFDEXC306.ad1.prod> Message-ID: informIT published an interview with me written by David Chisnall: http://www.informit.com/articles/article.aspx?p=1315064 David asked some interesting questions about security and the future of the C programming language. rCs From thesp0nge at gmail.com Tue Dec 16 04:03:54 2008 From: thesp0nge at gmail.com (Paolo Perego) Date: Tue, 16 Dec 2008 10:03:54 +0100 Subject: [SC-L] Project announce: The OWASP Source Code Flaws Top 10 Message-ID: Hello leaders, I'm really happy to announce a new documentation project I started today. Our Top 10 most critical web app vulnerabilities is the standard de facto when trying to summarize findings when you assess a web application. And it is great. Looking at source code assessment (or code review, or static analysis, or whatever the name you want to use :-)), nothing like this exists. Gary McGraw introduced the 7 kingdoms as taxonomy. I started looking at this great job extending it to meet Owasp Top 10 like template. I also used categories that I found useful to gather security code review findings in. That's why I started this Top 10 project. The goal is to provide something useful in Owasp Code Review Guide while trying to organize security issues and the second goal is to use it as Owasp Orizon default library cookbooks in order to have a "fil rouge" from Code review guide and the implementing tool. The Source code flaws Top 10 will be that fil rouge. I really hope that everyone interested will subscribe to mailing list and give some contributions to this document I'd like to release as beta quality project in the next AppSec Europe 2009 in Cracow. Link: http://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project Roadmap: http://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project_Roadmap Mailinglist subscription page: https://lists.owasp.org/mailman/listinfo/owasp-source-code-flaws-top-10 Regards thesp0nge -- "stay hungry, stay foolish" OWASP Orizon project, http://orizon.sourceforge.net "enjoy your code review experience" From gem at cigital.com Tue Dec 16 13:25:03 2008 From: gem at cigital.com (Gary McGraw) Date: Tue, 16 Dec 2008 13:25:03 -0500 Subject: [SC-L] top 10 software security surprises Message-ID: hi sc-l, Using the software security framework introduced in October (A Software Security Framework: Working Towards a Realistic Maturity Model ), we interviewed nine executives running top software security programs in order to gather real data from real programs. Our goal is to create a maturity model based on these data, and we're busy working on that (stay tuned here for more). However, in the course of analyzing the data we gathered, we unearthed some surprises that we share in this month's informIT article: http://www.informit.com/articles/article.aspx?p=1315431 My bet is that some of the findings will come as a surprise to sc-l readers as well. Check the article out. Merry New Year to you all. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From chandra at list.org Tue Dec 16 18:57:55 2008 From: chandra at list.org (Pravir Chandra) Date: Tue, 16 Dec 2008 15:57:55 -0800 Subject: [SC-L] top 10 software security surprises In-Reply-To: References: Message-ID: Hey All. On the topic of maturity models, in Gary's first article he mentioned a draft model I created. Since I've mostly been discussing it in OWASP circles, I wanted to point out the Software Assurance Maturity Model (SAMM) project at http://www.opensamm.org I kicked off that work based on a few years experience running with CLASP and with help from the guys at Fortify. Currently, there's a BETA release ( http://www.opensamm.org/downloads/SAMM-BETA-0.8.1.pdf), but a new revision should be available by the end of year. That next revision will reflect feedback from individual reviewers, output from OWASP working sessions, and much of the real-world feedback that Gary talks about below. I'm always interested to hear comments/questions/flames, so please feel free to download it and send any feedback. Thanks! p. On Tue, Dec 16, 2008 at 10:25 AM, Gary McGraw wrote: > hi sc-l, > > Using the software security framework introduced in October (A Software > Security Framework: Working Towards a Realistic Maturity Model < > http://www.informit.com/articles/article.aspx?p=1271382>), we interviewed > nine executives running top software security programs in order to gather > real data from real programs. Our goal is to create a maturity model based > on these data, and we're busy working on that (stay tuned here for more). > However, in the course of analyzing the data we gathered, we unearthed some > surprises that we share in this month's informIT article: > > http://www.informit.com/articles/article.aspx?p=1315431 > > My bet is that some of the findings will come as a surprise to sc-l readers > as well. Check the article out. > > Merry New Year to you all. > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > blog www.cigital.com/justiceleague > book www.swsec.com > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081216/e5e7c584/attachment.html From ken at krvw.com Wed Dec 17 14:48:37 2008 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 17 Dec 2008 14:48:37 -0500 Subject: [SC-L] top 10 software security surprises In-Reply-To: References: Message-ID: <1BCADEF6-B062-41BF-A6C3-E3EF023F7E11@krvw.com> On Dec 16, 2008, at 1:25 PM, Gary McGraw wrote: > Using the software security framework introduced in October (A > Software Security Framework: Working Towards a Realistic Maturity > Model ), we > interviewed nine executives running top software security programs > in order to gather real data from real programs. Wow, this is great stuff. Kudos to Gary, Sammy, and Brian. I have a couple comments/observations on some of your conclusions: - You obviously wrote the top-10 list in C, since it went from 9 to 0. :-) - "Not only are there are no magic software security metrics, bad metrics actually hurt." This is an excellent point. I think it's also worth noting that it's important to carefully consider what metrics make sense for an organization _as early as possible_ in the life of their software security efforts. Trying to retro-engineer some metrics into a program after the fact is not a fun thing. - "Secure-by-default frameworks can be very helpful, especially if they are presented as middleware classes (but watch out for an over focus on security "stuff"). " Yes yes yes! I've found significantly more "traction" to prescriptive guidance vs. a "don't do this" list of bad practices. Plus, it inherently supports a mindset of positive validation instead of negative. It's important to look for common mistakes, but if you really want your devs to follow, give them clear coding guidelines with annotated descriptions of how to follow them. Efforts like OWASP's ESAPI are indeed a great starting point here for plugging in things like strong positive input validation and such. - "Web application firewalls are not in wide use, especially not as Web application firewalls. " I can't say I'm much surprised by this one. Even with PCI-DSS driving people to WAFs (or do external independent code reviews), I just don't often see them often. But you go on to say, "But even these two didn't use them to block application attacks; they used them to monitor Web applications and gather data about attacks."--but you don't come back to this point. One serious benefit to WAFs can be enhancing the ability to do monitoring, especially of legacy apps. Adding one network choke point WAF can quickly add an app-level monitoring capability that few organizations considered when rolling the apps out in the first place. - "Though software security often seems to fit an audit role rather naturally, many successful programs evangelize (and provide software security resources) rather than audit even in regulated industries" This one too is very encouraging to see. - "Architecture analysis is just as hard as we thought, and maybe harder." And this one is very discouraging. I've seen good results in doing architectural risk analyses, but the ones that produce useful results tend to be the more ad hoc ones -- and NOT the ones that follow rigorous processes. - "All nine programs we talked to have in-house training curricula, and training is considered the most important software security practice in the two most mature software security initiatives we interviewed. " That explains the quarter-million miles in my United account this year alone. :-) Ugh. - "Though all of the organizations we talked to do some kind of penetration testing, the role of penetration testing in all nine practices is diminishing over time. " Hallelujah! Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081217/d45996ab/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081217/d45996ab/attachment.bin From ivan.ristic at gmail.com Wed Dec 17 16:07:02 2008 From: ivan.ristic at gmail.com (Ivan Ristic) Date: Wed, 17 Dec 2008 21:07:02 +0000 Subject: [SC-L] top 10 software security surprises In-Reply-To: <1BCADEF6-B062-41BF-A6C3-E3EF023F7E11@krvw.com> References: <1BCADEF6-B062-41BF-A6C3-E3EF023F7E11@krvw.com> Message-ID: <1f9222b70812171307rc99de64xfc8310802bf06bf8@mail.gmail.com> On Wed, Dec 17, 2008 at 7:48 PM, Kenneth Van Wyk wrote: > On Dec 16, 2008, at 1:25 PM, Gary McGraw wrote: > > Using the software security framework introduced in October (A Software > Security Framework: Working Towards a Realistic Maturity Model > ), we interviewed > nine executives running top software security programs in order to gather > real data from real programs. > > [snip] > > - "Web application firewalls are not in wide use, especially not as Web > application firewalls. " I can't say I'm much surprised by this one. Even > with PCI-DSS driving people to WAFs (or do external independent code > reviews), I just don't often see them often. But you go on to say, "But > even these two didn't use them to block application attacks; they used them > to monitor Web applications and gather data about attacks."--but you don't > come back to this point. One serious benefit to WAFs can be enhancing the > ability to do monitoring, especially of legacy apps. Adding one network > choke point WAF can quickly add an app-level monitoring capability that few > organizations considered when rolling the apps out in the first place. I couldn't agree more. There is a very strong perception that WAFs must be configured to block, and that they are useless if they aren't. Blocking, however, is only one of the use cases. They are: 1. HTTP Intrusion Detection and Prevention: same as IDS/IPS, but for HTTP. 2. Virtual patching, to fix the problems you know you have and give you time. 3. Learning, to gather information about your applications and help you make sense of them. 4. Logging, for batch and back-in-time analysis. If you are interested in this topic you may find my presentation, Evaluation Criteria for Web Application Firewalls (http://www.owasp.org/images/f/f4/AppSecEU08_Evaluation_Criteria_for_Web_Application_Firewalls.pdf) useful. -- Ivan Ristic From brian at fortify.com Wed Dec 17 16:49:14 2008 From: brian at fortify.com (Brian Chess) Date: Wed, 17 Dec 2008 13:49:14 -0800 Subject: [SC-L] top 10 software security surprises In-Reply-To: <1BCADEF6-B062-41BF-A6C3-E3EF023F7E11@krvw.com> Message-ID: Thanks Ken. For me this has been an incredibly eye-opening project. It can be hard for people to distinguish between ideas that merely look good on paper and ideas that are actually in widespread use. Once we?ve cleaned up the data and gotten approval from the organizations we canvassed, we think there?ll be plenty of ways to apply what we?ve learned. The project Pravir mentioned is one. Brian [Ed. This was from Brian at fortify.com, but was dropped by the Mailman server since it's set to ignore emails from non-subscribed addresses (spam...). Issue was resolved re Brian's email address.] On 12/17/08 11:48 AM, "Ken van Wyk" wrote: > On Dec 16, 2008, at 1:25 PM, Gary McGraw wrote: >> Using the software security framework introduced in October (A >> Software Security Framework: Working Towards a Realistic Maturity >> Model ), >> we interviewed nine executives running top software security >> programs in order to gather real data from real programs. > > Wow, this is great stuff. Kudos to Gary, Sammy, and Brian. > > I have a couple comments/observations on some of your conclusions: > > - You obviously wrote the top-10 list in C, since it went from 9 to > 0. :-) > > - "Not only are there are no magic software security metrics, bad > metrics actually hurt." This is an excellent point. I think it's > also worth noting that it's important to carefully consider what > metrics make sense for an organization _as early as possible_ in the > life of their software security efforts. Trying to retro-engineer > some metrics into a program after the fact is not a fun thing. > > - "Secure-by-default frameworks can be very helpful, especially if > they are presented as middleware classes (but watch out for an over > focus on security "stuff"). " Yes yes yes! I've found > significantly more "traction" to prescriptive guidance vs. a "don't > do this" list of bad practices. Plus, it inherently supports a > mindset of positive validation instead of negative. It's important > to look for common mistakes, but if you really want your devs to > follow, give them clear coding guidelines with annotated > descriptions of how to follow them. Efforts like OWASP's ESAPI are > indeed a great starting point here for plugging in things like > strong positive input validation and such. > > - "Web application firewalls are not in wide use, especially not as > Web application firewalls. " I can't say I'm much surprised by this > one. Even with PCI-DSS driving people to WAFs (or do external > independent code reviews), I just don't often see them often. But > you go on to say, "But even these two didn't use them to block > application attacks; they used them to monitor Web applications and > gather data about attacks."--but you don't come back to this point. > One serious benefit to WAFs can be enhancing the ability to do > monitoring, especially of legacy apps. Adding one network choke > point WAF can quickly add an app-level monitoring capability that > few organizations considered when rolling the apps out in the first > place. > > - "Though software security often seems to fit an audit role rather > naturally, many successful programs evangelize (and provide software > security resources) rather than audit even in regulated industries" > This one too is very encouraging to see. > > - "Architecture analysis is just as hard as we thought, and maybe > harder." And this one is very discouraging. I've seen good results > in doing architectural risk analyses, but the ones that produce > useful results tend to be the more ad hoc ones -- and NOT the ones > that follow rigorous processes. > > - "All nine programs we talked to have in-house training curricula, > and training is considered the most important software security > practice in the two most mature software security initiatives we > interviewed. " That explains the quarter-million miles in my United > account this year alone. :-) Ugh. > > - "Though all of the organizations we talked to do some kind of > penetration testing, the role of penetration testing in all nine > practices is diminishing over time. " Hallelujah! > > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.com > > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com > ) > as a free, non-commercial service to the software security community. > _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20081217/13c3c5be/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20081217/13c3c5be/attachment-0001.bin From coley at linus.mitre.org Wed Dec 17 18:29:10 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 17 Dec 2008 18:29:10 -0500 (EST) Subject: [SC-L] CWE/SANS Top 25 Most Dangerous Programming Errors Message-ID: Since this is the week of the top-lists related to secure coding, I thought I'd notify the SC-L people about a new collaboration between SANS and MITRE. We are creating a Top 25 list of the worst programming errors, targeted largely at developers, software managers, and CIOs. The list is not as high-level as the OWASP Top Ten, and not focused just on web applications; it attempts to provide actionable details to programmers with an informal tone. Some SC-L subscribers are already aware of it and have provided feedback. The initial announcement was in late November; see http://www.sans.org/resources/top25/ So far, we have reached out to and received input from major software vendors, security tool vendors, consultants, the OWASP ESAPI group, and others in industry, academia, and government. We have one or two more rounds of review before the Top 25 list is published in early January. I'd been meaning to contact this list, but it slipped my mind until the latest flurry of activity. If you want to participate, feel free to contact me and Bob Martin (ramartin at mitre.org) directly. Thanks, Steve From gem at cigital.com Mon Dec 22 13:13:15 2008 From: gem at cigital.com (Gary McGraw) Date: Mon, 22 Dec 2008 13:13:15 -0500 Subject: [SC-L] Silver Bullet: Laurie Williams Message-ID: hi sc-l, The 33rd episode of Silver Bullet went live today. My victim this month is Laurie Williams, professor at NCSU. Laurie is a star in the Agile software community. We discuss Agile and software security during the interview. We also talk about some excellent metrics-related research that one of Laurie's students is doing. http://www.cigital.com/silverbullet/show-033/ I wish you all a Merry New Year! gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com