From seba at deleersnyder.eu Sat Jan 3 07:11:49 2009 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Sat, 3 Jan 2009 13:11:49 +0100 Subject: [SC-L] Fwd: CALL FOR PRESENTATIONS - OWASP AppSec Europe 2009 Poland In-Reply-To: References: Message-ID: Hi, May 13th?14th 2009, OWASP will hold its annual European Application Security conference in wonderfull Krak?w, Poland. The Conference consists of two days of training sessions on May 11th?12th, followed by a two-day conference with 2 different tracks. In 2008, we attracted great European and international speakers in Belgium, and we hope to achieve the same again in 2009. This year we organise the conference together with OWASP Poland and Confidence2009 , a conference in the same venue on May 15th-16th. We are seeking presentations on any of the following topics: - Web Services and Application Security - Common Application related Threats and Risks - Business Risks with Application Security - Vulnerability Research in Application Security - Web Application Penetration Testing - OWASP Tools and Projects - Secure Coding Practices - Technology specific presentations on security such as AJAX, XML, etc. - Anything else relating to OWASP and Application Security. The call for presentations is out. The official closing date for receiving a synopsis of the presentation is February 1th, 2009, with announcements on selected candidates to be provided the second week of February 2009. Complete presentations will need to be submitted by the 1th of May 2009. A call for refereed research papers will also be published in the coming weeks. The selected papers will also be presented at the conference. This year, as per last year, any presenter will receive a free invitation to the conference. If required, OWASP can cover some of the travel costs associated with coming to the conference. Please submit your presentation topics to seba at owasp.org. The conference page will be updated regularly: AppSecEU09 Regards Seba 2009 EU Planning Committee Chair seba at owasp.org +32.478.504.117 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090103/88054275/attachment.html From yo at secappdev.org Sun Jan 4 08:51:45 2009 From: yo at secappdev.org (Johan Peeters) Date: Sun, 4 Jan 2009 14:51:45 +0100 Subject: [SC-L] SecAppDev 2009 Message-ID: <25b6e5cf0901040551q16f1dffdh710911d71a0cd03d@mail.gmail.com> secappdev.org is excited to announce SecAppDev 2009, an intensive one-week course in secure application development. secappdev.org is a non-profit organization dedicated to improving security awareness and skills in the developer community. The course is a joint project with K.U. Leuven and Solvay Brussels School of Economics and Management. SecAppDev 2009 follows the widely acclaimed courses in 2005, 2006, 2007 and 2008, attended by an international audience from a broad range of industries including financial services, telecom, consumer electronics and media. In order to offer an effective learning environment, we limit the number of participants. This allows for optimal interaction between participants and faculty. The course is taught by leading experts including - Dr. Gary McGraw, the Cigital CTO, inspired speaker and prolific author. - Prof. Dr. Daniel Bernstein whose Internet applications have impeccable security credentials. - Prof. dr. ir. Bart Preneel who heads COSIC, the renowned crypto lab. - Ken van Wyk, well-known author and lecturer as well as the moderator of the SC-L. The course takes place from March 2nd to March 6th in the Groot Begijnhof in Leuven, Belgium, a UNESCO World Heritage site. Registration is on a first-come, first-served basis. Early Bird registration offers a 25% discount on the course fee and ends on January 15th. Public servants can attend the course at a 50% discount. More information on the web site, http://secappdev.org. Wishing you a safe, happy and secure 2009, Yo -- Johan Peeters Program Director http://secappdev.org From gem at cigital.com Tue Jan 6 17:28:54 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 6 Jan 2009 17:28:54 -0500 Subject: [SC-L] New Podcast: Reality Check Security Podcast goes live Message-ID: hi sc-l, A number of Silver Bullet listeners and sc-l subscribers have asked me to interview "more practitioners" over the last three years. Instead of changing the mission of Silver Bullet, we decided to create a new podcast and focus it exclusively on practical software security. That means balancing out the hope for a silver bullet with a reality check! (Check out the logo...I think you'll like it.) Reality Check will be a monthly podcast just like Silver Bullet. Releases of the two sister 'casts will alternate and appear every two weeks or so. Reality Check targets experienced leaders working to solve software security problems in large organizations every day. We use a standard script to guide each conversation with questions about history, methodology, best practice, and measurement. We plan to interview leaders of mature software security programs and leaders of programs just getting started. Who better to start with than Steve Lipner? http://www.cigital.com/realitycheck/ As usual, I am very much interested in your feedback. Do you like the questions? Who do you want me to interview? Merry New Year everybody! And special shouts to Ryan Macmichael who engineers all aspects of Reality Check and Silver Bullet. gem company www.cigital.com podcast ww.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From seba at deleersnyder.eu Fri Jan 9 17:40:57 2009 From: seba at deleersnyder.eu (Sebastien Deleersnyder) Date: Fri, 9 Jan 2009 23:40:57 +0100 Subject: [SC-L] CALL FOR TRAINING PROVIDERS - OWASP AppSec Europe 2009 Poland In-Reply-To: References: Message-ID: CALL FOR TRAINING PROVIDERS - OWASP AppSec Europe 2009 Poland. The Call For Presentations send out earlier can be found on the OWASP web site here . May 13th?14th 2009, OWASP will hold its annual European Application Security conference in wonderfull Krak?w, Poland. The Conference consists of two days of training sessions on May 11th?12th, followed by a two-day conference with 2 different tracks. In 2008, we attracted great European and international speakers and trainers in Belgium, and we hope to achieve the same again in 2009. This year we organise the conference together with OWASP Poland and Confidence2009, a conference in the same venue on May 15th-16th. We are seeking people and organisations that want to provide training courses on any of the following topics: - Business Risks with Application Security. - Starting and Managing Secure Development Lifecycle Programs. - Web Services-, XML- and Application Security. - Application Threat Modeling. - Hands-on Source Code Review. - Web Application Security Testing. - OWASP Tools and Projects. - Secure Coding Practices (J2EE/.NET). - Technology specific presentations on security such as AJAX, XML, etc. - Anything else relating to OWASP and Application Security. The following conditions apply for people or organisations that want to provide training at the conference: - Training provider should provide class syllabus / training materials. - Proceeds will be split 75/25 (OWASP/Trainer) for the training class. The 75% for OWASP goes towards: - Classroom Rental, Conference Logistics/Registration, and Food. - OWASP Grants for Research Projects. - Each classroom has a maximum capacity of 30 people, minimum of 12 people signed up before class is considered operational. - Price per attendee: 2-Day Class ?910 / 1-Day Class ?455. - Provider branded training materials to increase your exposure. - Students are to bring their own laptops. - Classes are to be focused around Application Security as mentioned above. - Training provider must be an OWASP Member. The call for trainings is out. The official closing date for receiving a synopsis of the training is February 1, 2009, with announcements on selected candidates to be provided the second week of February 2009. Complete training material will need to be submitted by May 1, 2009. Training proposals should consist of the following information: 1. Trainer contact info (country of origin and residence-mail, postal address, phone, E-mail). 2. Employer and/or affiliations. 3. Training synopsis, proposed training title, and a one paragraph description. 4. Brief biography, list of publications and papers. 5. Any significant presentation and educational experience/background. 6. Reason why this material is innovative or significant or an important training for the OWASP conference. 7. Please list any other publications or conferences where this material has been or will be published/submitted. 8. Will you perform hands-on labs / slides or both? 9. Provide a list of items/software needed for the training. 10. Optionally, any samples of prepared material or outlines ready. We would appreciate your proposal using the provided EU09 training proposal template . If you do not support the Word format, please include the plain text version of this information in your email. Please submit your proposals to seba at owasp.org. The conference page will be updated regularly: AppSecEU09 Please forward to all interested practitioners and colleagues. Thank you, Regards, Seba 2009 EU Planning Committee Chair seba at owasp.org +32.478.504.117 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090109/8219fdba/attachment.html From ken at krvw.com Mon Jan 12 14:30:09 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 12 Jan 2009 14:30:09 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors Message-ID: <8540EBF6-3F30-47EF-B2D8-B83C20BA9D7A@krvw.com> FYI, a top 25 programming errors list from the folks at SANS has been released. See the following for details: http://www.sans.org/top25errors/ 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/20090112/bfac394c/attachment.bin From tomb at owasp.org Mon Jan 12 17:39:09 2009 From: tomb at owasp.org (Tom Brennan - OWASP) Date: Mon, 12 Jan 2009 17:39:09 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors In-Reply-To: <8540EBF6-3F30-47EF-B2D8-B83C20BA9D7A@krvw.com> References: <8540EBF6-3F30-47EF-B2D8-B83C20BA9D7A@krvw.com> Message-ID: CVE - http://cve.mitre.org/ known problems known systems CWE - http://cwe.mitre.org/ classes of problems unknown systems http://cwe.mitre.org/top25/ Will business start to talk CWE as they already talk CVE? Discussion/Debate/Thoughts Tom Brennan -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Monday, January 12, 2009 2:30 PM To: Secure Coding Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors FYI, a top 25 programming errors list from the folks at SANS has been released. See the following for details: http://www.sans.org/top25errors/ Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com From coley at linus.mitre.org Mon Jan 12 19:01:52 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 12 Jan 2009 19:01:52 -0500 (EST) Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 Message-ID: All, I'm the editor of the Top 25 list. Thanks to Ken and others on SC-L who provided some amazing feedback before its publication. I hope we were able to address most of your concerns and am sorry that we couldn't address all of them. Note that MITRE's site for the Top 25 is more technically detailed and has lots of supporting documents than the SANS site, which is really a jumping-off point. See http://cwe.mitre.org/top25/. Also, a process document and changelog is on that site. Here are some topics that arose during the construction of the Top 25. I thought these might make some interesting points of debate or discussion on this list: 1) The inclusion of output encoding (CWE-116) in conjunction with input validation (CWE-20) generated a lot of mixed reviews. Part of it seems to come down to different ways of looking at the same problem. For example, is SQL injection strictly an input validation vulnerability, or output sanitization/validation/encoding or whatever you want to call it? In a database, the name "O'Reilly" may pass your input validation step, but you need to properly quote it before sending messages to the database. And the actual database platform itself has no domain model to "validate" whether the incoming query is consistent with business logic. My personal thinking, which seems reflected by many web application people, is that many injection issues are related to encoding at their core, and the role of input validation is more defense-in-depth (WITH RESPECT TO INJECTION ONLY). Yet smart people insist that it's still input validation, even when presented with the example I gave. So So what's the perspective difference that's causing the disconnect? 2) Countless mitigations were suggested by contributors on top of some of the ones already in the CWE entries (admittedly some of them weak). Fortunately, we had time (for some definition of "time" that sometimes excluded a personal life) to update many of the core CWE entries. Many mitigations had limitations, either in terms of impacts on usability, whether they could be applied at all in some circumstances, or if they were sufficiently effective. The variety of customized mitigations is staggering, which to me suggests that more framework/methodology definition is needed. 3) Contributors advocated selecting list items based on how often the weakness appears in software (prevalence) and how severe the consequences are when the weakness leads to a vulnerable condition (severity). Many people advocated using real-world data to make the determination for prevalence. Problem: there's no real-world data available! CVE vulnerability data is insufficient - they concentrate on the vulnerability side ("XSS") instead of the weakness side ("e.g. use of the wrong encoding at the wrong time"). If people have real-world, weakness-focused data, then they aren't telling. 4) Some questions with respect to the assignment of severity scores led me to attempt to build a threat model and to try to more formally define other supporting fields like ease of detection, in light of the "skilled, determined attacker." I don't think this model was sufficiently vetted, and I'm sure people will have concerns with how it's been defined (including "your threat model is really just talking about a threat agent.") HOWEVER, I don't know of any other prioritized list that has tried to define some threat model to help with prioritization. I would love to see this kind of investigation continue in other efforts. (An acronym called CWSS comes to mind...) 5) The threat model, as roughly implied by how most people were "voting" for which items to include on the Top 25, treated availability as slightly less important than integrity and confidentiality. Thus CWE-400 (Resource Consumption) had the dubious distinction of being number 26. (CWE-400 and other also-rans are in the "On the Cusp" section of MITRE's Top 25 site). Clearly, availability may be more important in some environments e.g. critical infrastructure or e-commerce. The unsurprising implications are that no single threat model will work for different types of organizations when composing a general list like the Top 25. Thus it has a sort of fudge factor that helps make it generally applicable to organizations with varying threat environments, within some degree of tolerance. It seems like a fundamental problem with a list of that sort. 6) Many expert reviewers will notice the varying abstraction levels and overlapping concepts in the list. There are various explanations for this as summarized in the change logs and FAQ. My main point in bringing this up was, a lot of people want things to be at a fixed level of abstraction and mutually exclusive, but I don't think it's feasible given our current understanding of security issues. The CWE Research View (CWE-1000) tries to achieve mutual exclusivity, but are still working on it. One of the things I think the CWE project has brought to the table overall is the semi-formal modeling of how weaknesses are inter-related, in the form of chains and composites [1]. In short, it's difficult to have a mutually exclusive list because every kind of bug can trigger every other kind of bug! (example: buffer overflow could overwrite an adjacent numeric variable that leads to a calculation error, or vice versa). 7) Today, Chris Wysopal announced that Veracode had 61% coverage for the Top 25, and maybe they could boost that up to 75%. The gap is probably related to design-level issues. Chris noted that human analysis will always be required for the things that tools can't find, so software development teams need to find other approaches to fill the gap. I think this has interesting implications for future research and prioritization. 8) Terminology and definitions varied widely, which is probably a surprise to noone. This posed some problems in writing the document, and it's a general challenge for us in CWE and, I believe, a general challenge for the software community. 9) The OWASP Top Ten became a tool for PCI to easily establish minimum requirements for web applications, without PCI having to get into gory technical details. This was contrary to OWASP's original intentions for the Top Ten as an educational tool. SANS and MITRE both definitely have "technical clarification of expectations for assurance" as a goal, but the implications are a little unclear if this turns into "compliance." Nonetheless, I see it as an important tool for non-software-security experts to ask for security in terms that are amenable to some form of measurement. I grant that many of these issues may not be surprises to SC-L, but I thought they were interesting. - Steve [1] http://cwe.mitre.org/data/reports/chains_and_composites.html From vanderaj at owasp.org Mon Jan 12 19:12:14 2009 From: vanderaj at owasp.org (vanderaj vanderaj) Date: Mon, 12 Jan 2009 19:12:14 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors In-Reply-To: References: <8540EBF6-3F30-47EF-B2D8-B83C20BA9D7A@krvw.com> Message-ID: <914836430901121612q1915eef1rb0c38787bad1bda4@mail.gmail.com> Tom, >From the business' point of view, they really don't care if widget X has weaknesses, they want to know how to make money by buying and using widget X. They assume X is safe by default, even though it's not. They've been doing fast and crappy for so long, and made heaps of money from it, that it's a hard sell in many places to do the safer thing until the horse has bolted. The only examples where folks buy widget X over widget Y is those folks in operational risk who have to make a financial allowance for a probable risk difference between X and Y. For example, if one satellite launch system blows up one time every four launches, and another blows up one time every eight launches, you'd go with the second or you'd have to budget for the likelihood of having to replace your satellite a bit more with the first one. In our industry, we have still yet to make a compelling, measurable and thus believable case that there's a TCO benefit from buying more expensive, but safer software. Most folks believe all software is safe, despite the fact that it is not. Until that time, CWE and similar *weakness* patterns are a derivative of the actual cost of ownership, and not the actual benefits. That's why I've gone gung ho into "build it right the first time" mode. I doubt we'll get the accurate metrics required for proof that safer software is cheaper (over time), so it's best that we simply get safer software - period. That's why I will be working with the frameworks and code repositories rather than the 0day crowd. In my view, there is zero value in vulnerability disclosure, discussion, or discovery. It's like shooting fish in a barrel. thanks, Andrew > Will business start to talk CWE as they already talk CVE? > > Discussion/Debate/Thoughts > > Tom Brennan > From gem at cigital.com Tue Jan 13 16:49:55 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 13 Jan 2009 16:49:55 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors In-Reply-To: <914836430901121612q1915eef1rb0c38787bad1bda4@mail.gmail.com> Message-ID: hi sc-l, There are some important good things about top ten lists that are worthy of mention. The notion of knowing your enemy is essential in security (as it is in warfare), and top ten lists can help get software people started thinking about attacks, attackers, and the vulnerabilities they go after. These days almost any attention paid to the problem is good attention, and the fact that the the tech press is paying attention to software security at all is a good thing. Top ten lists help in that respect. But, I am really worried about these kinds of lists and I wrote up my worries in an article that was just posted: Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work http://www.informit.com/articles/article.aspx?p=1322398 I thought you might get a kick out of it. gem http://www.cigital.com/~gem From coley at linus.mitre.org Tue Jan 13 17:59:42 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 13 Jan 2009 17:59:42 -0500 (EST) Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors In-Reply-To: References: Message-ID: On Tue, 13 Jan 2009, Gary McGraw wrote: > I thought you might get a kick out of it. I did! :-) Always good to have debates. >Executives don't care about technical bugs No, but they do what PCI says they have to (i.e. listen to the OWASP Top Ten). They do care about the bottom line. They hate buying software and finding out how crappy it is afterward. The Siemens example comes to mind. It was mind-boggling to me to hear that they were forced to pay 150% of the original cost just to get the software they bought in a secure form. http://www.networkworld.com/news/2009/011209-software-security-effort.html?page=2 >Too much focus on bugs. The Top 25 has 4 or 5 items that are clearly design-related, maybe more if you think that improper input validation is related to design, and still more if you count all the "external control" items which may be implementation or design depending on who's talking and what the programmer's responsibilities are. The Top 25 even has a couple classic Saltzer-and-Schroeder examples in there (rephrased to avoid the incredible confusion and misinterpretation that has gone on with the original S&S). >Vulnerability lists help auditors more than developers. Agree - except the Top 25 has anywhere from 3 to 10 specific mitigations/preventions for each CWE. And whether we like it or not, auditors help to drive change. Maybe not the optimal change, but they drive change. Also - when the developers' software managers are told by their marketers that they could lose many, then the managers will figure out how to get the developers to improve. Long-term thinking here - I know, that's not allowed for this industry. >One person's top bug is another person's yawner. Absolutely, a point I brought up in the other post I made to SC-L on some interesting challenges. >Using bug parade lists for training leads to awareness but does not >educate. Yep - which is why we want universities to get cracking, and if the Top 25 helps to prod them on, then so be it. >Bug lists change with the prevailing technology winds. Yep - which is why the official name of the Top Ten begins with "2009". We'll do this again next year. >Top ten lists mix levels. Also brought up in my last email as a problem for the industry in general. Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them? I could classify most of the Top 25 in multiple categories. Should "poor output encoding" be put under the Input validation kingdom? Sounds kind of like using the "Start" button in Windows to shut down ;-) Should "cleartext transmission" be put under Environment? or Security Features? Again, we *all* have this problem. >Automated tools can find bugs . let them. Yes, and a lesson of the Top 25 (that we all already know) is that when people start to apply it, they'll see how a tool won't be a silver bullet. Also covered in my last email... >When it comes to testing, security requirements are more important than >vulnerability lists. Which is cover a teeny bit in the other email I sent. Also, New York State has put up draft text that mentions the Top 25 as part of a condition for acquisition. Is that enough? Hardly. But things like the Black/Williams "software facts label" aren't mature either, and Dept. of Homeland Security probably has a couple years to go before their work on assurance cases begins to take shape. >Ten is not enough. Neither is 25. Number 26 (another design issue) is also mentioned in the other email I posted. I'm of the mindset that the Top 25 is, short-term, an awareness tool for developers and for customers. In the longer term, maybe it will be a little blip on the road to actionable software assurance. Given that approximately 1000 people have created delicious bookmarks for it, and I've alread seen comments from a couple developers "hey, we should go check this out" - then we are already seeing some success. Gary, it might seem ironic since I am leading the most comprehensive bug parade out there in CWE, but I agree with you that just following the bug parade is not enough. The Top 25 is a means to an end, and not the end itself. Only time will tell, though. - Steve From Greg.Beeley at LightSys.org Tue Jan 13 19:41:34 2009 From: Greg.Beeley at LightSys.org (Greg Beeley) Date: Tue, 13 Jan 2009 16:41:34 -0800 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: References: Message-ID: <496D34BE.1050508@LightSys.org> Steve I agree with you on this one. Both input validation and output encoding are countermeasures to the same basic problem -- that some of the parts of your string of data may get treated as control structures instead of just as data. For the purpose of this email I'm using a definition of "input validation" as sanitizing/restricting data at its entry to a program, and "encoding" as the generation of any string in any format other than straight binary-safe data. (obviously in many cases you will have a more complex architecture with individual modules/classes also doing their own "input validation" too). Having both countermeasures in place is a belt-and-suspenders perspective which is healthy. However, input validation is primarily tied to business requirements (what characters are required in the data field), and output encoding is tied to a technical knowledge of the output format being used (whether HTML, SQL, a shell command, CSV data, text for an eval() call, a UTF-8 string, etc.). The only upside to relying primarily on input validation is that it gives a sort of "perimeter protection", a firewall of sorts to the data coming in that tends to protect all of the code "behind the firewall". But it necessarily is not likely to be a very "smart" firewall. One big problem to relying primarily on input validation is that input validation can be very far structurally removed from the point that causes the trouble -- the injection/encoding point. In fact, the programmer doing the input processing may have no knowledge of how the data may be encoded later, and in fact the encodings needed may change with time as well. Proper output encoding puts the countermeasure in the same place as the knowledge of the output format, and puts the responsibility where the expertise is. It also makes the code much easier to audit, as you can tell easily that the encoding process isn't vulnerable without having to trace the route of every single encoded data item through the code and back up to its entry point into the program (of course for thorough auditing you'd do that anyhow but for purposes other than just that one encoding point). A second big problem - as mentioned - is that input validation relies on business requirements -- and you can't guarantee that the business requirements won't require you to permit "troublesome" characters in the data field, as in the example you gave. - Greg Steven M. Christey wrote: > For example, is SQL injection strictly an input validation > vulnerability, or output sanitization/validation/encoding or whatever > you want to call it? In a database, the name "O'Reilly" may pass your > input validation step, but you need to properly quote it before sending > messages to the database. And the actual database platform itself has > no domain model to "validate" whether the incoming query is consistent > with business logic. My personal thinking, which seems reflected by > many web application people, is that many injection issues are related > to encoding at their core, and the role of input validation is more > defense-in-depth (WITH RESPECT TO INJECTION ONLY). Yet smart people > insist that it's still input validation, even when presented with the > example I gave. So So what's the perspective difference that's causing > the disconnect? From rklists at gmail.com Tue Jan 13 21:51:09 2009 From: rklists at gmail.com (Rohit Lists) Date: Tue, 13 Jan 2009 21:51:09 -0500 Subject: [SC-L] Mitigating XSS in existing JEE apps with AOP - Proof of Concept Message-ID: Hi all, As some of you may know I've spent some time researching how to apply Aspect Oriented Programming (AOP) to web application security. I haven't been able to spend as much time on the topic as I'd like, but I was able to come up with a proof of concept for Java EE applications. I created an HTML encoding aspect using AspectJ that automatically encodes all dangerous data within a Servlet or JSPs prior to printing to stream. The net result is a tool that should effectively stop the vast majority of XSS attacks on many existing Java EE apps with only a few lines of code. Although I still need to test thoroughly, with the proof of concept I was able to secure WebGoat from nearly all server-side XSS with about 16 unique lines of code in one file. I was also able to protect Daffodil CRM from thousands of XSS vulns with about 3 unique lines of code in one file. Now the catch(es): -The proof of concept hasn't undergone any rigorous testing. Moreover, I don't have done any performance testing. -The proof of concept won't currently work with tag libraries but we will be able to extend it to automatically HTML encode data in JSTL and other common tag libraires. -The proof of concept only performs HTML encoding, it does not perform JavaScript or HTML Attribute encoding -The library will only ever protect against Java EE server-side code, it will never protect against client-side DOM-based XSS or XSS where HTML encoding is an insufficient protection Right now I'm looking for help from people who can critique the design for holes, test the proof of concept, etc prior to releasing the tool to the public in an open source library. If you're interested in this or would simply like to know more, please ping me. I haven't set the AOP Security library up as a project in a code repository yet but I intend to do so after I've had a few other people look over the proof of concept. Thanks, Rohit -- Rohit Sethi Security Compass http://www.securitycompass.com From cwysopal at Veracode.com Tue Jan 13 23:08:50 2009 From: cwysopal at Veracode.com (Chris Wysopal) Date: Tue, 13 Jan 2009 23:08:50 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors In-Reply-To: References: <914836430901121612q1915eef1rb0c38787bad1bda4@mail.gmail.com> Message-ID: <79348E23E9D34F4F8032010B2913D72B0207BB96@NexusCore.Veracode.local> The only attention software security seems to get in the mainstream press beyond the bug or attack of the day is from top X lists. That alone makes them worthwhile. They definitely steer the conversation in the right direction. I think everyone involved in creating and promoting top X lists believes they are a conversation starter and not an end game for software security. We just have to make sure the rest of software security follows. -Chris -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Tuesday, January 13, 2009 4:50 PM To: Secure Code Mailing List Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors hi sc-l, There are some important good things about top ten lists that are worthy of mention. The notion of knowing your enemy is essential in security (as it is in warfare), and top ten lists can help get software people started thinking about attacks, attackers, and the vulnerabilities they go after. These days almost any attention paid to the problem is good attention, and the fact that the the tech press is paying attention to software security at all is a good thing. Top ten lists help in that respect. But, I am really worried about these kinds of lists and I wrote up my worries in an article that was just posted: Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work http://www.informit.com/articles/article.aspx?p=1322398 I thought you might get a kick out of it. gem http://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. _______________________________________________ From yo at secappdev.org Wed Jan 14 02:08:00 2009 From: yo at secappdev.org (Johan Peeters) Date: Wed, 14 Jan 2009 08:08:00 +0100 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <496D34BE.1050508@LightSys.org> References: <496D34BE.1050508@LightSys.org> Message-ID: <25b6e5cf0901132308j5fe4e6a7u241a161b2d497801@mail.gmail.com> > Steve I agree with you on this one. Both input validation and output encoding > are countermeasures to the same basic problem -- that some of the parts of > your string of data may get treated as control structures instead of just as > data. For the purpose of this email I'm using a definition of "input while I am being persuaded that you can use input validation and output encoding interchangeably as countermeasures for *some* problems documented here, there is another important dimension: enforcement of business rules. In this domain, I do not see an alternative to input validation. kr, Yo -- Johan Peeters http://johanpeeters.com From gem at cigital.com Wed Jan 14 10:20:29 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 14 Jan 2009 10:20:29 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors In-Reply-To: Message-ID: Hi Steve, Thanks for your thoughtful response. I do think the top-25 project moved things in the right direction (in particular with the idea of mitigations), but I still have worries. BTW, sorry for the delay responding, I had band practice last night for my "Hot Club Millwood" (Django/Grappeli covers) concert Friday. BTW, I do hope everyone will read the original article in order to see the paragraphs explaining the sentences that Steve snipped here. Some particular responses to steve's concerns: gem> Executives don't care about technical bugs s> No, but they do what PCI says they have to (i.e. listen to the OWASP Top s> Ten). They do care about the bottom line. They hate buying software and s> finding out how crappy it is afterward. Unfortunately security by compliance seems to be more of a problem than it is a justification for top ten lists. In my view, PCI does not lead to secure software. gem> Too much focus on bugs. s> The Top 25 has 4 or 5 items that are clearly design-related I acknowledge movement in the right direct here. Question for sc-l...do we need a "top ten flaws" list? gem> Using bug parade lists for training leads to awareness but does not educate. s> Yep - which is why we want universities to get cracking, and if the Top 25 s> helps to prod them on, then so be it. Good lord I hope that the CS curriculum does not embrace the bug parade. I would rather have a crop of kids who know how C *actually works*, what a stack is, and how computers function! Education prepares people for training...it does not supercede it. Sadly, I have little faith that software security will work its way into the university curriculum in a meaningful way (and will be ecstatically psyched to be completely wrong). gem> Top ten lists mix levels. s> Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them? Good question. You tell me! Hopefully it's better than the OWASP 10! Once again, I think we need to ponder the difference between a taxonomy and a top-N list. gem> Automated tools can find bugs---let them. s> Yes, and a lesson of the Top 25 (that we all already know) is that when s> people start to apply it, they'll see how a tool won't be a silver bullet. A tool is so much superior to a list that I simply have say..huh?! gem> When it comes to testing, security requirements are more important than vulnerability lists. s> New York State has put up draft text that mentions the Top 25 as s> part of a condition for acquisition. In my view this is not a helpful development. gem> Ten is not enough. s> I'm of the mindset that the Top 25 is, short-term, an awareness tool for s> developers and for customers. Agreed. I like it for that reason. s>In the longer term, maybe it will be a little blip on the road to actionable software assurance. This is my concern. s> The Top 25 is a means to an end, and not the end itself. Also agreed. 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 Jan 14 12:08:32 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 14 Jan 2009 12:08:32 -0500 Subject: [SC-L] InternetNews Realtime IT News - New York Plans Application Security Program Message-ID: <780FFF25-A739-4F6C-AE93-A96B460FBF0F@krvw.com> Now here's an interesting development in the software security space. Seems that New York State is going to start requiring contracted application developers to conform with a minimum set of practices (as covered in the SANS "Application Security Procurement Language", http://www.sans.org/appseccontract/) . http://www.internetnews.com/dev-news/article.php/3796091 IMHO, putting things like this into contract language is a good thing. Even if the SANS list isn't the right one for everyone, it's a starting point. 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/20090114/19ca2980/attachment.bin From gem at cigital.com Wed Jan 14 14:17:36 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 14 Jan 2009 14:17:36 -0500 Subject: [SC-L] Silver Bullet 34: Bill Brenner Message-ID: hi sc-l, Ever wonder what it's like to cover security from a media perspective? Bill Brenner (once at TechTarget and now Sr Ed at CSOonline and CSO magazine) is my victim in the 34th Silver Bullet. http://www.cigital.com/silverbullet/show-034/ A bit less on software security this time, but plenty of data on getting executives to listen. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/Justiceleague book www.swsec.com From gem at cigital.com Wed Jan 14 14:30:03 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 14 Jan 2009 14:30:03 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors In-Reply-To: <79348E23E9D34F4F8032010B2913D72B0207BB96@NexusCore.Veracode.local> Message-ID: Hi Chris, You certainly have a point. There are occasional stories on software security that are not disaster coverage or top ten's, but not enough (sample from this set: http://www.cigital.com/~gem/press/). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 1/13/09 11:08 PM, "Chris Wysopal" wrote: The only attention software security seems to get in the mainstream press beyond the bug or attack of the day is from top X lists. That alone makes them worthwhile. They definitely steer the conversation in the right direction. I think everyone involved in creating and promoting top X lists believes they are a conversation starter and not an end game for software security. We just have to make sure the rest of software security follows. -Chris -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Tuesday, January 13, 2009 4:50 PM To: Secure Code Mailing List Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors hi sc-l, There are some important good things about top ten lists that are worthy of mention. The notion of knowing your enemy is essential in security (as it is in warfare), and top ten lists can help get software people started thinking about attacks, attackers, and the vulnerabilities they go after. These days almost any attention paid to the problem is good attention, and the fact that the the tech press is paying attention to software security at all is a good thing. Top ten lists help in that respect. But, I am really worried about these kinds of lists and I wrote up my worries in an article that was just posted: Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work http://www.informit.com/articles/article.aspx?p=1322398 I thought you might get a kick out of it. gem http://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. _______________________________________________ From coley at linus.mitre.org Wed Jan 14 14:45:03 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 14 Jan 2009 14:45:03 -0500 (EST) Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors In-Reply-To: References: Message-ID: To all, I'll ask a more strategic question - assuming we're agreed that the Top 25 is a non-optimal means to an end, what can the software security community do better to raise awareness and see real-world change? Gary and others who've broken into mainstream media - what aspects of your message resonate with the everyday people, and what doesn't? I personally feel that we need to do a better job of educating the general consumer, not just the ones who hire consultants. On Wed, 14 Jan 2009, Gary McGraw wrote: > gem> Using bug parade lists for training leads to awareness but does not educate. > s> Yep - which is why we want universities to get cracking, and if the Top 25 > s> helps to prod them on, then so be it. > > Good lord I hope that the CS curriculum does not embrace the bug parade. I think what I meant was, if there is more awareness that "hey, security is a problem and this Top 25 thing can help fix it, and the authors are saying that education needs to catch up" - then that may develop into indirect pressure on universities to make changes. > Sadly, I have little faith that software security will work its way into > the university curriculum in a meaningful way (and will be ecstatically > psyched to be completely wrong). I'm not going to say I'm overly optimistic either, maybe it's too much wishful thinking on my end. One ray of hope is that a lot of the press has reflected our statements that security is not part of the curriculum at most universities. Much of the press has also reflected the apparently-surprising fact that lots of hacking is possible because programmers make errors with security consequences. > gem> Top ten lists mix levels. > s> Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them? > > Good question. You tell me! I can't at this point - though I know it's not a clean mix. > gem> Automated tools can find bugs---let them. > s> Yes, and a lesson of the Top 25 (that we all already know) is that when > s> people start to apply it, they'll see how a tool won't be a silver bullet. > > A tool is so much superior to a list that I simply have say..huh?! Sorry, I should have been more specific. 1) to oversimplify, tools don't find design flaws, so people who rely exclusively on tools for Top 25 compliance will realize that they're not a silver bullet. Or if they don't, maybe their auditors will. 2) tools generate so many results that it's hard to prioritize which bugs to fix first. Top 25 will provide consumers with one cut at that. > gem> When it comes to testing, security requirements are more important > than vulnerability lists. > > s> New York State has put up draft text that mentions the Top 25 as > s> part of a condition for acquisition. > > In my view this is not a helpful development. I encourage people to look at the New York State contract text. The Top 25 is a relatively small part of it. In that context, I'm viewing it as "something of substance [having been reviewed by diverse people] that's better than nothing." Have people on this list written or used contract language that translates (somehow) into real software security? If the Top 25 isn't the right answer, then what is? - Steve From fw at deneb.enyo.de Wed Jan 14 14:55:38 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 14 Jan 2009 20:55:38 +0100 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: (Steven M. Christey's message of "Mon, 12 Jan 2009 19:01:52 -0500 (EST)") References: Message-ID: <874p011x39.fsf@mid.deneb.enyo.de> * Steven M. Christey: > Yet smart people insist that it's still input validation, even > when presented with the example I gave. So So what's the > perspective difference that's causing the disconnect? Some technologies are designed as if to discourage proper output encoding. Most templating engines (native PHP, Perl variable interpolation, JSP, Template::Toolkit, StringTemplate) discard the distinction between literal strings in the template, and substitution variables. In many cases, there's little support for composing reusable, parameterized templates from other templates, and you have to fall back to the host language and plain string concatenation instead to create such abstractions. This means that it appears rather costly to do proper output encoding, especially in legacy systems. And input encoding looks very easy to do (at least until you discover more and more potential input paths). But I suspect that the culture of input validation is partly responsible for the difficulty of addressing cross-site scripting issues. 8-( (There's also a rather nasty potential explanation: input validation sells web firewalls and related services, output encoding does not.) From fw at deneb.enyo.de Wed Jan 14 14:57:45 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 14 Jan 2009 20:57:45 +0100 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <25b6e5cf0901132308j5fe4e6a7u241a161b2d497801@mail.gmail.com> (Johan Peeters's message of "Wed, 14 Jan 2009 08:08:00 +0100") References: <496D34BE.1050508@LightSys.org> <25b6e5cf0901132308j5fe4e6a7u241a161b2d497801@mail.gmail.com> Message-ID: <87zlhtzmme.fsf@mid.deneb.enyo.de> * Johan Peeters: > while I am being persuaded that you can use input validation and > output encoding interchangeably Interchangeably? Hardly. > as countermeasures for *some* problems documented here, there is > another important dimension: enforcement of business rules. In this > domain, I do not see an alternative to input validation. What is a business rule? Something like "If the customer has changed the shipment address from a previous order, we must re-request his or her credit card details"? How would you implement *that* using input validation? From yo at secappdev.org Wed Jan 14 15:16:50 2009 From: yo at secappdev.org (Johan Peeters) Date: Wed, 14 Jan 2009 21:16:50 +0100 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <87zlhtzmme.fsf@mid.deneb.enyo.de> References: <496D34BE.1050508@LightSys.org> <25b6e5cf0901132308j5fe4e6a7u241a161b2d497801@mail.gmail.com> <87zlhtzmme.fsf@mid.deneb.enyo.de> Message-ID: <25b6e5cf0901141216l3958a857rd60b659c044f4639@mail.gmail.com> > What is a business rule? Something like "If the customer has changed > the shipment address from a previous order, we must re-request his or > her credit card details"? How would you implement *that* using input > validation? > The example I often use is 'equity can only be used as debt collateral, if it has a rating' :-) Before setting to work on your example, Florian, I would rephrase it as 'the date of entry of the shipment address must not be after the date of entry of credit card details'. I would then consider this an input validation problem. kr, Yo -- Johan Peeters http://johanpeeters.com From coley at linus.mitre.org Wed Jan 14 15:27:11 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 14 Jan 2009 15:27:11 -0500 (EST) Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <496D34BE.1050508@LightSys.org> References: <496D34BE.1050508@LightSys.org> Message-ID: On Tue, 13 Jan 2009, Greg Beeley wrote: > Steve I agree with you on this one. Both input validation and output > encoding are countermeasures to the same basic problem -- that some of > the parts of your string of data may get treated as control structures > instead of just as data. Note that I'm only talking about this in light of injection-related issues. Input validation is an important countermeasure for buffer overflows, for example, whereas output encoding isn't. (Unless you want to take the approach that things like strncpy() or safe string libraries are really related to controlling "output" when you process strings from an input buffer to an output buffer, and shellcode is a means of "injection"...) > For the purpose of this email I'm using a definition of "input > validation" as sanitizing/restricting data at its entry to a program, > and "encoding" as the generation of any string in any format other than > straight binary-safe data. This touches on something that I've been a little concerned about, which is the variety of definitions that people have for the same word. We struggle with that in CWE - which is why "output encoding/escaping" is in the CWE name instead of, say, sanitization or validation. I don't think there's necessarily a solution [face it, we're not all going to adopt the same terminology willingly], but it's a problem. - Steve From ivan.ristic at gmail.com Wed Jan 14 17:02:09 2009 From: ivan.ristic at gmail.com (Ivan Ristic) Date: Wed, 14 Jan 2009 22:02:09 +0000 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <496D34BE.1050508@LightSys.org> References: <496D34BE.1050508@LightSys.org> Message-ID: <1f9222b70901141402s22571ab2m4eb18e1c7a3a7a72@mail.gmail.com> On Wed, Jan 14, 2009 at 12:41 AM, Greg Beeley wrote: > Steve I agree with you on this one. Both input validation and output encoding > are countermeasures to the same basic problem... I'd like to offer a different view for your consideration, which is that input validation and output encoding actually don't have anything to do with security. Those techniques are essential software building blocks. While it is true that omission to use these techniques often causes security issues, that only means such programs are insecure in addition to being defective. I think that it's inherently wrong to associate input validation and output encoding with security. Fix the defects and the security issues will go away. On the other hand, if you only fix the security issues you may be left with a number of defects on your hands. Input validation layers should focus on accepting only valid data (per business requirements), while code that transmits data across system boundaries should focus on using the exchange and communication protocols correctly. Actually, now that I think about it more, I think we are struggling with the term input validation because the term has been overloaded. In the one sense, we are talking about validating user input, which mostly needs to concern itself with adhering to business requirements. This meaning is not very important for security, but the other one, validating data before something is done with it, is. If you take a web application for example, you would ideally verify that all user submitted data adheres to your business requirements. -- Ivan Ristic From stephen at twisteddelight.org Wed Jan 14 17:18:56 2009 From: stephen at twisteddelight.org (Stephen de Vries) Date: Wed, 14 Jan 2009 23:18:56 +0100 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors In-Reply-To: References: Message-ID: On Jan 14, 2009, at 8:45 PM, Steven M. Christey wrote: > > To all, I'll ask a more strategic question - assuming we're agreed > that > the Top 25 is a non-optimal means to an end, what can the software > security community do better to raise awareness and see real-world > change? From a Web Security point of view, have a look at the OWASP ASVS project: http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Abstract: "Whereas the OWASP Top Ten is a tool that provides web application security awareness, the OWASP Application Security Verification Standard (ASVS) is a commercially-workable open standard that defines ranges in coverage and levels of rigor that can be used to perform application security verifications ... The primary aim of the OWASP ASVS Project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing application security verification using a commercially- workable open standard. This standard can be used to establish a level of confidence in the security of web applications." regards, Stephen From gem at cigital.com Wed Jan 14 21:26:41 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 14 Jan 2009 21:26:41 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors In-Reply-To: Message-ID: Brian Chess, Sammy Migues and I continue to pound out the software assurance maturity model. Expect more on that soon. Working with a large real-world data set has really been amazing. For those of you just getting wind of this, see: http://www.informit.com/articles/article.aspx?p=1271382 http://www.informit.com/articles/article.aspx?p=1315431 No BS, just reality. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 1/14/09 5:18 PM, "Stephen de Vries" wrote: On Jan 14, 2009, at 8:45 PM, Steven M. Christey wrote: > > To all, I'll ask a more strategic question - assuming we're agreed > that > the Top 25 is a non-optimal means to an end, what can the software > security community do better to raise awareness and see real-world > change? From a Web Security point of view, have a look at the OWASP ASVS project: http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Abstract: "Whereas the OWASP Top Ten is a tool that provides web application security awareness, the OWASP Application Security Verification Standard (ASVS) is a commercially-workable open standard that defines ranges in coverage and levels of rigor that can be used to perform application security verifications ... The primary aim of the OWASP ASVS Project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing application security verification using a commercially- workable open standard. This standard can be used to establish a level of confidence in the security of web applications." regards, 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. _______________________________________________ From brian at fortify.com Thu Jan 15 00:25:45 2009 From: brian at fortify.com (Brian Chess) Date: Wed, 14 Jan 2009 21:25:45 -0800 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <1f9222b70901141402s22571ab2m4eb18e1c7a3a7a72@mail.gmail.com> Message-ID: > In the one sense, we are talking about validating user input, which > mostly needs to concern itself with adhering to business requirements. > This meaning is not very important for security, but the other one, > validating data before something is done with it, is. Yes, two forms of validation are required. If you hang around with the compliers crowd for too long, you?ll call them syntax validation and semantic validation. Syntax: ?the input must be an integer? Semantics: ?the input must identify an account held in your name.? It?s often possible and even desirable to perform syntax checking not long after a program accepts its input. You can bottleneck a program and make sure all input runs through a syntax validation layer. Not so with semantic checks. In many cases they are so closely related to the program logic that ripping them out and creating an ?semantic validation layer? would essentially double the length of the program and create a maintenance nightmare. So which form of input validation is security input validation? Both! In most cases you can?t afford to skip either one. Bad or absent syntax checks lead generic kinds of problems like SQL injection. Bad or absent semantic checks lead to problems that are often more specific to the application at hand. There?s a lot to say about input validation. Jacob West and I wrote devoted a full chapter to it in Secure Programming with Static Analysis (http://www.amazon.com/dp/0321424778), but we found that the material refused to stay in its cage?input validation got a lot of airtime when we talked about the Web, when we talked about privileged programs, and then again when we got around to the litany of common errors in C/C++ programs. Brian On 1/14/09 2:02 PM, "Ivan Ristic" wrote: > On Wed, Jan 14, 2009 at 12:41 AM, Greg Beeley > wrote: >> > Steve I agree with you on this one. Both input validation and output >> encoding >> > are countermeasures to the same basic problem... > > I'd like to offer a different view for your consideration, which is > that input validation and output encoding actually don't have anything > to do with security. Those techniques are essential software building > blocks. While it is true that omission to use these techniques often > causes security issues, that only means such programs are insecure in > addition to being defective. I think that it's inherently wrong to > associate input validation and output encoding with security. Fix the > defects and the security issues will go away. On the other hand, if > you only fix the security issues you may be left with a number of > defects on your hands. > > Input validation layers should focus on accepting only valid data (per > business requirements), while code that transmits data across system > boundaries should focus on using the exchange and communication > protocols correctly. > > Actually, now that I think about it more, I think we are struggling > with the term input validation because the term has been overloaded. > In the one sense, we are talking about validating user input, which > mostly needs to concern itself with adhering to business requirements. > This meaning is not very important for security, but the other one, > validating data before something is done with it, is. If you take a > web application for example, you would ideally verify that all user > submitted data adheres to your business requirements. > > -- > Ivan Ristic > _______________________________________________ > 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/20090114/59953dd8/attachment.html From jim at manico.net Wed Jan 14 22:54:55 2009 From: jim at manico.net (Jim Manico) Date: Wed, 14 Jan 2009 17:54:55 -1000 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <1f9222b70901141402s22571ab2m4eb18e1c7a3a7a72@mail.gmail.com> References: <496D34BE.1050508@LightSys.org> <1f9222b70901141402s22571ab2m4eb18e1c7a3a7a72@mail.gmail.com> Message-ID: <496EB38F.3020008@manico.net> > I'd like to offer a different view for your consideration, which is that /*input validation and output encoding actually don't have anything to do with security*/. Those techniques are essential software building. I'm really confused with this statement - and almost feel it's dangerous. Encoding, especially, is the cornerstone of building secure web applications. In particular, _encoding data within the correct context of usage_ is the basis for defending against approximately 2/3 of all classes of web vulnerabilities - XSS and SQLi in particular. Sure, bad or no encoding is definitely a bug - but it's also impossible to build a "secure" web application without proper use of encoding. So to say that "output encoding actually don't have anything to do with security" seems like a fairly radically incorrect statement. Sure, we should split up encoding into multiple categories - but I still think it's the cornerstone to secure programming practices. Libraries like ESAPI make such tasks very easy, too. However, I agree that Validation is overhyped. Input validation is really relevant to (web) security if you ever accept HTML from a user (ala validation tools like AntiSamy). You also need to solve malicious file upload attacks (if you support that feature) with input validation. Of course there are different considerations for the think client world when it comes to this topic. So, in short: Encoding and Validation are software building blocks -> that are fundamental for (especially web) software to defend against injection attacks (at least) -> therefore making validation and coding have something to do with security - Jim > blocks. While it is true that omission to use these techniques often > causes security issues, that only means such programs are insecure in > addition to being defective. I think that it's inherently wrong to > associate input validation and output encoding with security. Fix the > defects and the security issues will go away. On the other hand, if > you only fix the security issues you may be left with a number of > defects on your hands. > > Input validation layers should focus on accepting only valid data (per > business requirements), while code that transmits data across system > boundaries should focus on using the exchange and communication > protocols correctly. > > Actually, now that I think about it more, I think we are struggling > with the term input validation because the term has been overloaded. > In the one sense, we are talking about validating user input, which > mostly needs to concern itself with adhering to business requirements. > This meaning is not very important for security, but the other one, > validating data before something is done with it, is. If you take a > web application for example, you would ideally verify that all user > submitted data adheres to your business requirements. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090114/88cfd851/attachment.html From stephen at twisteddelight.org Thu Jan 15 03:35:15 2009 From: stephen at twisteddelight.org (Stephen de Vries) Date: Thu, 15 Jan 2009 09:35:15 +0100 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors In-Reply-To: References: Message-ID: On Jan 15, 2009, at 3:26 AM, Gary McGraw wrote: > Brian Chess, Sammy Migues and I continue to pound out the software > assurance maturity model. Expect more on that soon. Working with > a large real-world data set has really been amazing. > > For those of you just getting wind of this, see: > http://www.informit.com/articles/article.aspx?p=1271382 > http://www.informit.com/articles/article.aspx?p=1315431 Interesting articles, and they really whet the appetite for more of your maturity model. Can we expect a public/open release? Stephen > > > > On 1/14/09 5:18 PM, "Stephen de Vries" > wrote: > > > > On Jan 14, 2009, at 8:45 PM, Steven M. Christey wrote: >> >> To all, I'll ask a more strategic question - assuming we're agreed >> that >> the Top 25 is a non-optimal means to an end, what can the software >> security community do better to raise awareness and see real-world >> change? > > From a Web Security point of view, have a look at the OWASP ASVS > project: http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project > > Abstract: > "Whereas the OWASP Top Ten is a tool that provides web application > security awareness, the OWASP Application Security Verification > Standard (ASVS) is a commercially-workable open standard that defines > ranges in coverage and levels of rigor that can be used to perform > application security verifications > ... > The primary aim of the OWASP ASVS Project is to normalize the range in > the coverage and level of rigor available in the market when it comes > to performing application security verification using a commercially- > workable open standard. This standard can be used to establish a level > of confidence in the security of web applications." > > > regards, > 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. > _______________________________________________ > From ivan.ristic at gmail.com Thu Jan 15 04:21:35 2009 From: ivan.ristic at gmail.com (Ivan Ristic) Date: Thu, 15 Jan 2009 09:21:35 +0000 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: References: <1f9222b70901141402s22571ab2m4eb18e1c7a3a7a72@mail.gmail.com> Message-ID: <1f9222b70901150121h1b639bclfccac6081044e343@mail.gmail.com> On Thu, Jan 15, 2009 at 5:25 AM, Brian Chess wrote: > ... > > There's a lot to say about input validation. Jacob West and I wrote devoted > a full chapter to it in Secure Programming with Static Analysis > (http://www.amazon.com/dp/0321424778), but we found that the material > refused to stay in its cage?input validation got a lot of airtime when we > talked about the Web, when we talked about privileged programs, and then > again when we got around to the litany of common errors in C/C++ programs. True, but do you have a chapter dedicated to output encoding? I don't mind talking about input validation for as long we spend sufficient time discussing output encoding. The problem is that most people don't. Furthermore, a significant problem is that our terminology is incorrect and misleading. I prefer to use the terms data validation and data transformation to replace input validation and output encoding, respectively. Most people will perceive the words input and output as user-centric, ignoring what goes on within software and ignoring the processes that occur without a direct user action. Once you take these misleading words out, you can focus on component boundaries (rather than on the user-software interaction), and start making sure that data is both transformed and validated whenever it crosses component boundaries. Allow me to quote the first paragraph from the chapter you mentioned: *The most important defensive measure developers can take is to thoroughly validate the input their software receives. Input Validation and Representation is Kingdom #1 because unchecked or improperly checked input is the source of some of the worst vulnerabilities around, including buffer overflow, SQL injection, and a whole host of others. * Now allow me to change the wording slightly: *The most important defensive measure developers can take is to carefully handle the data their software processes. Data validation and transformationis Kingdom #1 because improperly checked or improperly transformed data is the source of the some of the worst vulnerabilities around, including buffer overflow, SQL injection, and a whole host of others. * Similarly, I think the sentence that follows: *Ask your local software security guru to name the single most important thing that developers can do to write secure code, and nine out of ten will tell you, "Never trust input."* Works better as: *Ask your local software security guru to name the single most important thing that developers can do to write secure code, and nine out of ten will tell you, "Never trust data." * Now it's easier to see how "Never trust data" actually translates to "Always validate and transform data". -- Ivan Ristic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090115/271742c9/attachment.html From gem at cigital.com Thu Jan 15 08:11:18 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 15 Jan 2009 08:11:18 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors Message-ID: <41945506397C0C4886A8C5BFF089B5CA35F48F8DC5@va-mailhub.cigital.com> We will release the model in Q1 for sure. When a draft is complete, we intend to go over it with the nine companies who participated in the study, show them where they stand, and have a joint review period. After that we'll make a plan for bringing the model public. This is hard work and for me it has been very rewarding. gem http://www.cigital.com/~gem ----- Original Message ----- From: Stephen de Vries To: Gary McGraw Cc: Secure Code Mailing List Sent: Thu Jan 15 03:35:15 2009 Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors On Jan 15, 2009, at 3:26 AM, Gary McGraw wrote: > Brian Chess, Sammy Migues and I continue to pound out the software > assurance maturity model. Expect more on that soon. Working with > a large real-world data set has really been amazing. > > For those of you just getting wind of this, see: > http://www.informit.com/articles/article.aspx?p=1271382 > http://www.informit.com/articles/article.aspx?p=1315431 Interesting articles, and they really whet the appetite for more of your maturity model. Can we expect a public/open release? Stephen > > > > On 1/14/09 5:18 PM, "Stephen de Vries" > wrote: > > > > On Jan 14, 2009, at 8:45 PM, Steven M. Christey wrote: >> >> To all, I'll ask a more strategic question - assuming we're agreed >> that >> the Top 25 is a non-optimal means to an end, what can the software >> security community do better to raise awareness and see real-world >> change? > > From a Web Security point of view, have a look at the OWASP ASVS > project: http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project > > Abstract: > "Whereas the OWASP Top Ten is a tool that provides web application > security awareness, the OWASP Application Security Verification > Standard (ASVS) is a commercially-workable open standard that defines > ranges in coverage and levels of rigor that can be used to perform > application security verifications > ... > The primary aim of the OWASP ASVS Project is to normalize the range in > the coverage and level of rigor available in the market when it comes > to performing application security verification using a commercially- > workable open standard. This standard can be used to establish a level > of confidence in the security of web applications." > > > regards, > 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. > _______________________________________________ > From shouvik at electrosoft-inc.com Thu Jan 15 09:08:45 2009 From: shouvik at electrosoft-inc.com (Shouvik Bardhan) Date: Thu, 15 Jan 2009 09:08:45 -0500 Subject: [SC-L] SANS List etc.. Message-ID: <01B7755C706445F7AFE014E2289962D3@esi.com> Guys, I am new to the App Security area so Stupid Comments Alert firstly. Many thanks for the insights that I get from the discussions on this board. I have been doing design/development for nearly 25 years now and it is interesting and frightening, how I hardly ever actively think (thought) while coding about Security - I know, I know !! So a few questions and comment from a newbie in the field a) Why is the meaning of input validation/output encoding so passionately contested? Is the subject not well understood? Are the remedies not well known? Is there a need to define the validation/protection in a more formal manner? b) I kind of like the OWASP T10, OWASP ASVS, OWASP Testing guide and now the SANS25. To me the App Security is a new field for many of us and if some smart folks get together and create "Things to consider" type of lists - isn't it a good thing? When DHS tells me to keep 7 days of water/food, flash lights/batteries and a transistor radio - I think "well, this may or may not be enough but fairly smart people have come up with a list and I better take a note of that" c) I am trying to understand why Gary said that teaching secure programming at University Level is not a good idea. Maybe not as a CS102 and CS202 class - there guys just need to be able to understand to write code. But why is it not a good idea to teach secure programming in a MS curriculum? Thanks again. -Shouvik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090115/432f3c87/attachment.html From gem at cigital.com Thu Jan 15 09:53:43 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 15 Jan 2009 09:53:43 -0500 Subject: [SC-L] SANS List etc.. In-Reply-To: <01B7755C706445F7AFE014E2289962D3@esi.com> Message-ID: Welcome Shouvik, I'll address your third point. I am ALL FOR teaching software security at the university level (and have been actively working with universities for over a decade). I just don't think it is realistic to try to push the problem off on universities and hope that they will solve it. As I have said, I would love to be proven wrong regarding my opinion on whether adding software security to a curriculum us realistic. For more on this, see page 98 of "Software Security" . I do hope that academic programs will not focus on the bug parade approach, however. Building a course around the OWASP top ten or the CWE/SANS top 25 would be rather silly. I would rather see vulns like this covered in every programming course and a software security course focused on the touchpoints (especially code review and architectural risk analysis). One thing emphasized by outstanding software security initiatives (think Microsoft) is that teaching developers and architects how to do things right is far superior to an after the fact analysis approach driven by audit and regulations. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 1/15/09 9:08 AM, "Shouvik Bardhan" wrote: Guys, I am new to the App Security area so Stupid Comments Alert firstly. Many thanks for the insights that I get from the discussions on this board. I have been doing design/development for nearly 25 years now and it is interesting and frightening, how I hardly ever actively think (thought) while coding about Security - I know, I know !! So a few questions and comment from a newbie in the field a) Why is the meaning of input validation/output encoding so passionately contested? Is the subject not well understood? Are the remedies not well known? Is there a need to define the validation/protection in a more formal manner? b) I kind of like the OWASP T10, OWASP ASVS, OWASP Testing guide and now the SANS25. To me the App Security is a new field for many of us and if some smart folks get together and create "Things to consider" type of lists - isn't it a good thing? When DHS tells me to keep 7 days of water/food, flash lights/batteries and a transistor radio - I think "well, this may or may not be enough but fairly smart people have come up with a list and I better take a note of that" c) I am trying to understand why Gary said that teaching secure programming at University Level is not a good idea. Maybe not as a CS102 and CS202 class - there guys just need to be able to understand to write code. But why is it not a good idea to teach secure programming in a MS curriculum? Thanks again. -Shouvik From joe at joeteff.com Thu Jan 15 13:05:45 2009 From: joe at joeteff.com (Joe Teff) Date: Thu, 15 Jan 2009 12:05:45 -0600 Subject: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 In-Reply-To: <496D34BE.1050508@LightSys.org> References: <496D34BE.1050508@LightSys.org> Message-ID: We are still struggling on simple definitions. I frequently hear names like "lack of input filtering" and "csrf" referred to as vulnerabilities when in reality one is an attack vector and the other an attack. You (correctly in my opinion) refer to input validation and encoding as countermeasures. Though I cringe a little with your definition of input as it sounds a little too user-centric. Input can come from any untrusted source which is not limited to a direct person. I find it amazing how encoded data or bound variables are used to stuff data into a datastore and then that same data is considered trusted when being re-used even by the same application. I do agree with your notion that input validation is frequently insufficient as it is often necessary to include problematic characters or combinations of characters to satisfy the business requirements. jt -----Original Message----- From: Greg Beeley To: SC-L at securecoding.org Cc: "Steven M. Christey" Date: Tue, 13 Jan 2009 16:41:34 -0800 Subject: Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 Steve I agree with you on this one. Both input validation and output encoding are countermeasures to the same basic problem -- that some of the parts of your string of data may get treated as control structures instead of just as data. For the purpose of this email I'm using a definition of "input validation" as sanitizing/restricting data at its entry to a program, and "encoding" as the generation of any string in any format other than straight binary-safe data. (obviously in many cases you will have a more complex architecture with individual modules/classes also doing their own "input validation" too). Having both countermeasures in place is a belt-and-suspenders perspective which is healthy. However, input validation is primarily tied to business requirements (what characters are required in the data field), and output encoding is tied to a technical knowledge of the output format being used (whether HTML, SQL, a shell command, CSV data, text for an eval() call, a UTF-8 string, etc.). The only upside to relying primarily on input validation is that it gives a sort of "perimeter protection", a firewall of sorts to the data coming in that tends to protect all of the code "behind the firewall". But it necessarily is not likely to be a very "smart" firewall. One big problem to relying primarily on input validation is that input validation can be very far structurally removed from the point that causes the trouble -- the injection/encoding point. In fact, the programmer doing the input processing may have no knowledge of how the data may be encoded later, and in fact the encodings needed may change with time as well. Proper output encoding puts the countermeasure in the same place as the knowledge of the output format, and puts the responsibility where the expertise is. It also makes the code much easier to audit, as you can tell easily that the encoding process isn't vulnerable without having to trace the route of every single encoded data item through the code and back up to its entry point into the program (of course for thorough auditing you'd do that anyhow but for purposes other than just that one encoding point). A second big problem - as mentioned - is that input validation relies on business requirements -- and you can't guarantee that the business requirements won't require you to permit "troublesome" characters in the data field, as in the example you gave. - Greg Steven M. Christey wrote: > For example, is SQL injection strictly an input validation > vulnerability, or output sanitization/validation/encoding or whatever > you want to call it? In a database, the name "O'Reilly" may pass your > input validation step, but you need to properly quote it before sending > messages to the database. And the actual database platform itself has > no domain model to "validate" whether the incoming query is consistent > with business logic. My personal thinking, which seems reflected by > many web application people, is that many injection issues are related > to encoding at their core, and the role of input validation is more > defense-in-depth (WITH RESPECT TO INJECTION ONLY). Yet smart people > insist that it's still input validation, even when presented with the > example I gave. So So what's the perspective difference that's causing > the disconnect? _______________________________________________ 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/20090115/04f93b3b/attachment.html From bishop at cs.ucdavis.edu Thu Jan 15 14:50:04 2009 From: bishop at cs.ucdavis.edu (Matt Bishop) Date: Thu, 15 Jan 2009 11:50:04 -0800 Subject: [SC-L] SANS List etc.. In-Reply-To: References: Message-ID: <0D3232D6-04F6-4A45-8B17-069C2D7E56A4@cs.ucdavis.edu> As an academic who does teach this stuff whenever they let me in a classroom ... > I'll address your third point. I am ALL FOR teaching software > security at the university level (and have been actively working > with universities for over a decade). I just don't think it is > realistic to try to push the problem off on universities and hope > that they will solve it. WHOLEHEARTEDLY AGREE!!!!! Companies, purchasers, etc. have to help. The old saw of "working together" is, I believe, actually true. I have about 50 other cliches here that I could add, but I'll not bore you with them. > As I have said, I would love to be proven wrong regarding my opinion > on whether adding software security to a curriculum us realistic. > For more on this, see page 98 of "Software Security" >. Hey, that's cool -- I forgot about the page. Thanks for the plug! At any rate, I do think it's realistic to add software security to the curriculum, but I think it's horribly *un*realistic to think that taking a class in it will solve the problems (and requiring students to take a class in it won't change that). You have to practice it, just like you have to practice writing. > I do hope that academic programs will not focus on the bug parade > approach, however. Building a course around the OWASP top ten or > the CWE/SANS top 25 would be rather silly. I would rather see vulns > like this covered in every programming course and a software > security course focused on the touchpoints (especially code review > and architectural risk analysis). I'd emphasize *why* these problems occur, and use the Top 25 list to explain what happens when you don't follow the principles. You can then show how to apply the principles to prevent (or at least limit) these problems. That will cut down on problems before code review. And then you teach code review. You need to teach both how to do it right and how to catch problems when it is not done right, because I don't know anyone who *always* does it right. Perfection may be the goal, but it's not the reality. > One thing emphasized by outstanding software security initiatives > (think Microsoft) is that teaching developers and architects how to > do things right is far superior to an after the fact analysis > approach driven by audit and regulations. A very academically sound approach :-) Matt From gem at cigital.com Thu Jan 15 14:57:13 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 15 Jan 2009 14:57:13 -0500 Subject: [SC-L] SANS List etc.. In-Reply-To: <0D3232D6-04F6-4A45-8B17-069C2D7E56A4@cs.ucdavis.edu> Message-ID: Dr. Bishop, I bow to you. sc-l cohorts, don't forget that Matt was a Silver Bullet victim pretty recently. Listen here: http://www.cigital.com/silverbullet/show-031/ gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 1/15/09 2:50 PM, "Matt Bishop" wrote: As an academic who does teach this stuff whenever they let me in a classroom ... > I'll address your third point. I am ALL FOR teaching software > security at the university level (and have been actively working > with universities for over a decade). I just don't think it is > realistic to try to push the problem off on universities and hope > that they will solve it. WHOLEHEARTEDLY AGREE!!!!! Companies, purchasers, etc. have to help. The old saw of "working together" is, I believe, actually true. I have about 50 other cliches here that I could add, but I'll not bore you with them. > As I have said, I would love to be proven wrong regarding my opinion > on whether adding software security to a curriculum us realistic. > For more on this, see page 98 of "Software Security" >. Hey, that's cool -- I forgot about the page. Thanks for the plug! At any rate, I do think it's realistic to add software security to the curriculum, but I think it's horribly *un*realistic to think that taking a class in it will solve the problems (and requiring students to take a class in it won't change that). You have to practice it, just like you have to practice writing. > I do hope that academic programs will not focus on the bug parade > approach, however. Building a course around the OWASP top ten or > the CWE/SANS top 25 would be rather silly. I would rather see vulns > like this covered in every programming course and a software > security course focused on the touchpoints (especially code review > and architectural risk analysis). I'd emphasize *why* these problems occur, and use the Top 25 list to explain what happens when you don't follow the principles. You can then show how to apply the principles to prevent (or at least limit) these problems. That will cut down on problems before code review. And then you teach code review. You need to teach both how to do it right and how to catch problems when it is not done right, because I don't know anyone who *always* does it right. Perfection may be the goal, but it's not the reality. > One thing emphasized by outstanding software security initiatives > (think Microsoft) is that teaching developers and architects how to > do things right is far superior to an after the fact analysis > approach driven by audit and regulations. A very academically sound approach :-) Matt From jgrembi at gmail.com Thu Jan 15 15:47:35 2009 From: jgrembi at gmail.com (Jason Grembi) Date: Thu, 15 Jan 2009 15:47:35 -0500 Subject: [SC-L] Contents of SC-L digest.. Message-ID: <930b20350901151247h36d68ea2uc8381345d3e402b2@mail.gmail.com> I just wanted to chime in with my two cents on the top N list. I have witnessed (and developed) secure programs that were built to defend attacks identified in secure requirements (i.e. data validation and data transformation) But the one vulnerability that keeps popping up is weak authentication. Most business apps rely (and can only afford) one the most basic use of authentication; username and passwords. I would like to see the basic the use of one tier authentication on a Bug Parade list. It is by design a weak link and I think the business community needs to understand that a stronger authentication policy is just as important as data validation. I agree with GEM when he wrote that Executives don't care about technical bugs; but a Bug Parade lists does help highlight the usual list of suspects that need to be dealt with. Thus it justifies the additional spending on secure design and development. 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/20090115/32ccf510/attachment.html From chandra at list.org Thu Jan 15 16:40:12 2009 From: chandra at list.org (Pravir Chandra) Date: Thu, 15 Jan 2009 13:40:12 -0800 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors In-Reply-To: References: Message-ID: On Thu, Jan 15, 2009 at 12:35 AM, Stephen de Vries wrote: > Interesting articles, and they really whet the appetite for more of > your maturity model. Can we expect a public/open release? Since you made mention of the maturity model, I'll toss in my shameless plug for the SAMM project (Software Assurance Maturity Model). For now, only a Beta is available, but it was heavily debated and refined at the OWASP Summit in November and a new revision is imminent (within the month). In the mean time, check out the Beta at: http://www.opensamm.org/downloads/SAMM-BETA-0.8.1.pdf As soon as the next version is ready, we'll be launching it as an OWASP project to serve as a new revision to the CLASP project, if you're familiar with that. I've also been talking to a number of vendors (both product and services) about supporting the SAMM project and things are looking positive so far. I encourage anyone with data, ideas, or motivation to ping me and get involved. p. -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From gem at cigital.com Thu Jan 15 19:55:49 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 15 Jan 2009 19:55:49 -0500 Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors Message-ID: <41945506397C0C4886A8C5BFF089B5CA35F48F8DEE@va-mailhub.cigital.com> Hi all, I do want to clarify that these models are not the same thing. gem http://www.cigital.com/~gem ----- Original Message ----- From: sc-l-bounces at securecoding.org To: Stephen de Vries Cc: Secure Code Mailing List Sent: Thu Jan 15 16:40:12 2009 Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors On Thu, Jan 15, 2009 at 12:35 AM, Stephen de Vries wrote: > Interesting articles, and they really whet the appetite for more of > your maturity model. Can we expect a public/open release? Since you made mention of the maturity model, I'll toss in my shameless plug for the SAMM project (Software Assurance Maturity Model). For now, only a Beta is available, but it was heavily debated and refined at the OWASP Summit in November and a new revision is imminent (within the month). In the mean time, check out the Beta at: http://www.opensamm.org/downloads/SAMM-BETA-0.8.1.pdf As soon as the next version is ready, we'll be launching it as an OWASP project to serve as a new revision to the CLASP project, if you're familiar with that. I've also been talking to a number of vendors (both product and services) about supporting the SAMM project and things are looking positive so far. I encourage anyone with data, ideas, or motivation to ping me and get involved. p. -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ 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 Jan 16 22:39:29 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Fri, 16 Jan 2009 19:39:29 -0800 Subject: [SC-L] SANS/CWE Top 25: "The New Standard" for Webappsec Message-ID: Hello all. Xposting to SCL and WASC: Following-up to my commentary on the WASC list about the SANS/CWE "Top 25".... I have repeatedly confirmed that the SANS/CWE Top 25 is being actively used, and growing in use, as a "Standard". I understand the spirit of intent and that the makers are not accountable for how it is used, but we need to be realistic about how it is being implemented in the real world *now*. It is beginning to be used as a "standard" for: * what security defects to test software for * how to measure the security quality of software * how to build secure software * what to teach developers about coding securely I have confirmed this with: * peers * corporations * state governments * software security solutions vendors * customers We are already seeing RFPs for products and services, management and auditor created "internal" standards, and requests for training and reporting using the "SANS/ CWE Top 25" as a standard. There are three goals of this post: 1) to make very clear to all involved that what is being built with the "Top 25" list is a minimum standard of due care. 2) To suggest that this is (most likely) how it is primarily going to be used. (You brought the SANS/CIS club to the dance here...) 3) Suggest that future versions be re-focused on building actual minimum standards of due care for the demonstrated needs. The great thing that is coming out of this Top 25 experiment is to identify that awareness and hunger-level for material like this is very high. This is also showing us what people really want right now: People want a minimum standard of due care. It is obvious people want bite-sized digestible snippets to use as guidelines for making and measuring the security quality of our software. That is evidenced by how rapidly people have latched onto this new list. (one week + !) The SANS and Mitre brand have huge stock in the mainstream, non-appsec security community, much larger than OWASP and WASC, as is evidenced again by the attention this is getting throughout the infosec and audit communities. And summing up, directly from Alan Paller: http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1344962,00.html Conclusions: We need a minimum standard of due care Top N list. We really need THREE minimum standards of due care: 1) Top N issues/defects to test your software for 2) Top N principles to build secure software 3) Top N strategies to improve software security in your enterprise Webappsec folks should make webappsec versions, or else we will all wind up using the same ones for *everything*. We might want to divide/share efforts between organizations and cross-reference each other for maximum (positive) effect. We could likely leverage each others' work and try to unify our language across appsec communities. (Ideologies and pet naming systems are where these efforts always break down in our group.) I am avoiding the debate over the inherent problems with "Top N" and bug parade approaches in general. People are letting us know what they want and I think we should solve that need. ...or they will take whatever we give them for other purposes and use it to solve that need, partially, improperly, ineffectively. I will quite my bitching about the "Top 25" and focus on productively moving forward, now that it's clear my concerns are too late and it's already moving full-steam ahead as a standard. People do not know what to do. They have a serious problem that is starting to cause them to lose real sleep and real money, and they are looking to us for suggestions and guidance as to what to do. I concede that the Top 25 in this regard is better than nothing, but it's not really what people want or need right now (IMHO). (Note: I have not asked parties involved if I can quote them or quote facts of this being used as a standard. The volume of emails I am receiving providing examples of this make me think this is either a fad, or self-evident and you will all see plenty of examples of this very soon if you have not already. SANS has spoken and I think that is a pretty clear indication what is going on....) $0.02 USD, -- -- Arian Evans Anti-Gun/UN people: you should weep for Mumbai. Your actions leave defenseless dead. "Among the many misdeeds of the British rule in India, history will look upon the Act depriving a whole nation of arms, as the blackest." -- Mahatma Gandhi From koved at us.ibm.com Mon Jan 19 08:59:36 2009 From: koved at us.ibm.com (Larry Koved) Date: Mon, 19 Jan 2009 08:59:36 -0500 Subject: [SC-L] CFP: W2SP 2009: Web 2.0 Security and Privacy 2009 In-Reply-To: Message-ID: This may be of interest to readers of this mailing list. This is an announcement of the call for papers for the third in a series of successful workshops on topics related to security and privacy for Web 2.0. If you would, please pass this information on to your colleagues who may be interested in this workshop. Thanks. Larry Koved Co-Chair, W2SP http://w2spconf.com/2009/ __________________________________________________________________ Workshop Call for Papers W2SP 2009: Web 2.0 Security and Privacy 2009 Thursday, May 21 The Claremont Resort, Oakland, California 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. Enabled by a wave of new technology, these social and business interactions rely on composition of content and services from multiple sources, commonly called mash-ups, leading to systems with complex trust boundaries. This trend is likely to continue because individuals and businesses desire the efficiency and simplicity these technologies offer. Together with their virtues, these technologies raise issues about management of identities, reputation, privacy, anonymity, transient and long term relationships, and composition of function and content, both on the server and on the client (web browser). Although the underlying security and privacy issues are not new, the use of these technologies on a wide scale and by a broad audience raises new questions. This workshop is intended to discuss the limitations of current technologies and explore alternatives. The scope of W2SP 2009 includes, but is not limited to: - Trustworthy cloud-based services - Privacy and reputation in social networks - Usable security and privacy - Security for the mobile web - Identity management and psuedonymity - Advertisement and affiliate fraud - Provenance and governance - Security and privacy as a service - Web services/feeds/mashups - Security and privacy policies for composible content - Next-generation browser technology 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 chair or workshop committee. From the submissions, the program committee will strive to balance participation between academia and industry and across topics. Selected papers will appear on the workshop web site. Workshop Co-Chairs: Larry Koved (IBM Research) Dan S. Wallach (Rice University) Program Chair Adam Barth (UC Berkeley) Program Committee Ben Adida (Harvard University) Dirk Balfanz (Google) Adam Barth (UC Berkeley) Konstantin (Kosta) Beznosov Suresh Chari (IBM Research) Hao Chen (UC Davis) Douglas Crockford (Yahoo) Chris Karlof (UC Berkeley) Larry Koved (IBM Research) Shriram Krishnamurthi (Brown University) Collin Jackson (Stanford University) Rob Johnson (Stony Brook University) John C. Mitchell (Stanford University) Sean W. Smith (Dartmouth University) Helen Wang (Microsoft Research) Dan S. Wallach (Rice University) Important Dates Paper submission deadline: March 6, 2009, (11:59pm US-Eastern) Workshop acceptance notification date: March 31, 2009 Workshop date: Thursday, May 21, 2009 Workshop paper submission web site: To be announced. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090119/12976516/attachment.html From gem at cigital.com Mon Jan 19 10:19:47 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 19 Jan 2009 10:19:47 -0500 Subject: [SC-L] Silver Bullet: Gunnar Peterson (transcript posted) Message-ID: hi sc-l, As you know, Silver Bullet is co-sponsored by Cigital and IEEE Security & Privacy magazine. The magazine publishes about half of the episodes as the "Interview" department. I'm pleased to say that our own Gunnar Peterson's episode will appear in print in an upcoming issue. Here are two pointers to the original podcast and the transcript (which we posted yesterday): Episode 27: http://www.cigital.com/silverbullet/show-027/ Transcript: http://www.cigital.com/silverbullet/shows/silverbullet-027-gpeterson.pdf As always, your feedback is welcome! gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From stephencraig.evans at gmail.com Mon Jan 19 12:45:52 2009 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Tue, 20 Jan 2009 01:45:52 +0800 Subject: [SC-L] SANS/CWE Top 25: "The New Standard" for Webappsec In-Reply-To: References: Message-ID: <930fd0230901190945m4ddea64k93180b42afd92f7b@mail.gmail.com> Hi Arian, " SANS has spoken and I think that is a pretty clear indication what is going on....)" Have you been watching Wizard of Oz re-reruns again? This sentence sounds too much like "The Mighty Oz has spoken" :-) Cheers, Stephen On Sat, Jan 17, 2009 at 11:39 AM, Arian J. Evans wrote: > Hello all. Xposting to SCL and WASC: > > Following-up to my commentary on the > WASC list about the SANS/CWE "Top 25".... > > I have repeatedly confirmed that the SANS/CWE > Top 25 is being actively used, and growing in > use, as a "Standard". > > I understand the spirit of intent and that the > makers are not accountable for how it is used, > but we need to be realistic about how it is > being implemented in the real world *now*. > > It is beginning to be used as a "standard" for: > * what security defects to test software for > * how to measure the security quality of software > * how to build secure software > * what to teach developers about coding securely > > > I have confirmed this with: > * peers > * corporations > * state governments > * software security solutions vendors > * customers > > We are already seeing RFPs for products > and services, management and auditor > created "internal" standards, and requests > for training and reporting using the "SANS/ > CWE Top 25" as a standard. > > There are three goals of this post: > > 1) to make very clear to all involved that > what is being built with the "Top 25" list is > a minimum standard of due care. > > 2) To suggest that this is (most likely) how > it is primarily going to be used. > > (You brought the SANS/CIS club to the dance here...) > > 3) Suggest that future versions be re-focused > on building actual minimum standards of > due care for the demonstrated needs. > > The great thing that is coming out of this Top 25 > experiment is to identify that awareness and > hunger-level for material like this is very high. > > This is also showing us what people really want > right now: > > People want a minimum standard of due care. > > It is obvious people want bite-sized digestible > snippets to use as guidelines for making and > measuring the security quality of our software. > > That is evidenced by how rapidly people have > latched onto this new list. (one week + !) > > The SANS and Mitre brand have huge stock in > the mainstream, non-appsec security community, > much larger than OWASP and WASC, as is > evidenced again by the attention this is getting > throughout the infosec and audit communities. > > And summing up, directly from Alan Paller: > > > http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1344962,00.html > > > Conclusions: > > We need a minimum standard of due care Top N list. > > > We really need THREE minimum standards of due care: > > 1) Top N issues/defects to test your software for > 2) Top N principles to build secure software > 3) Top N strategies to improve software security in your enterprise > > Webappsec folks should make webappsec > versions, or else we will all wind up using > the same ones for *everything*. > > We might want to divide/share efforts between > organizations and cross-reference each other > for maximum (positive) effect. We could likely > leverage each others' work and try to unify > our language across appsec communities. > > (Ideologies and pet naming systems are where > these efforts always break down in our group.) > > > I am avoiding the debate over the inherent > problems with "Top N" and bug parade approaches > in general. People are letting us know what they > want and I think we should solve that need. > > ...or they will take whatever we give them for > other purposes and use it to solve that need, > partially, improperly, ineffectively. > > I will quite my bitching about the "Top 25" and > focus on productively moving forward, now that > it's clear my concerns are too late and it's > already moving full-steam ahead as a standard. > > People do not know what to do. They have > a serious problem that is starting to cause > them to lose real sleep and real money, and > they are looking to us for suggestions and > guidance as to what to do. > > I concede that the Top 25 in this regard is > better than nothing, but it's not really what > people want or need right now (IMHO). > > (Note: I have not asked parties involved > if I can quote them or quote facts of this > being used as a standard. The volume > of emails I am receiving providing examples > of this make me think this is either a fad, > or self-evident and you will all see plenty > of examples of this very soon if you > have not already. > > SANS has spoken and I think that is > a pretty clear indication what is going on....) > > $0.02 USD, > > -- > -- > Arian Evans > > Anti-Gun/UN people: you should weep for > Mumbai. Your actions leave defenseless dead. > > "Among the many misdeeds of the British > rule in India, history will look upon the Act > depriving a whole nation of arms, as the > blackest." -- Mahatma Gandhi > _______________________________________________ > 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/20090120/16e8f1cc/attachment-0001.html From arian.evans at anachronic.com Mon Jan 19 19:15:12 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Mon, 19 Jan 2009 16:15:12 -0800 Subject: [SC-L] SANS/CWE Top 25: "The New Standard" for Webappsec In-Reply-To: <930fd0230901190945m4ddea64k93180b42afd92f7b@mail.gmail.com> References: <930fd0230901190945m4ddea64k93180b42afd92f7b@mail.gmail.com> Message-ID: On Mon, Jan 19, 2009 at 9:45 AM, Stephen Craig Evans wrote: > > Hi Arian, > > " SANS has spoken and I think that is a pretty clear indication what is > going on....)" > > Have you been watching Wizard of Oz re-reruns again? This sentence sounds > too much like "The Mighty Oz has spoken" :-) I am from Kansas, Stephen. How did you know? On a serious note: I have tremendous respect for the SANS organizations' work and the value they provide to the infosec community. I believe they are one of the best barometers of what is going on out in day-to-day security-land. In addition they have significant clout with information security professionals ranging from technical & implementation engineers, to tactical security management and auditors, to strategic level CISOs and policy compliance folks. They have a lot more clout across the board with all of those folks for infosec in general than the combined communities of OWASP, WASC, Mitre, and the denizens of the SCL list. Translation: we should all watch closely and take cues from how SANS uses our software security publication output, be it Top N lists or standards or whatever. SANS and their many tentacles are market driven both with regards to private sector and government. They will react to needs and provide them, and have a clear idea what folks want. In this case what is wanted is CLEARLY a minimum standard of due care and SANS will use such a list accordingly, much as previous SANS Top N lists. What this means to the rest of us I pretty much covered in my last post. I have gotten a deluge of email in response to my posts to both SCL and WASC about SANS/CWE Top 25 from folks at organizations that have already had their bosses ask -- or even implement -- the CWE Top 25 as a standard of some type in their organization. Numerous customers I interact with are already asking me to cross-map the CWE/SANS Top 25 with existing web application security lists. (OWASP Top 10, WASC Threat Classification, etc.) My previous email lists the type of uses I am already seeing. First, the list should be "webified". That is probably the #1 interest in consumption of that data. There are a finite number of programmers working at Microsoft on their network stack in C++, and they are already way beyond this level. We're not putting out information for them. The majority of crappy software today is being built as web systems or embedded software. Two very different problem domains in terms of threat landscape and attack surface (though overlap in basic data handling principles). Then, again, you need three lists: + stuff to test for + patterns and practices to build secure + how to address software security in an enterprise The current Top 25 is kinda a bastard mix of all three of those, and solves none of them well. Sorry to stir people up, but this CWE list just created a headache and more work for me that I do not see improves upon anything I am already working on or providing. (Besides global attention -- proving again my assertion that folks are hungry for more) Thanks all, -- -- Arian Evans "I ask, sir, what is the militia? It is the whole people. To disarm the people is the best and most effectual way to enslave them."-- Patrick Henry From robert at webappsec.org Thu Jan 22 15:29:07 2009 From: robert at webappsec.org (robert at webappsec.org) Date: Thu, 22 Jan 2009 15:29:07 -0500 (EST) Subject: [SC-L] Security metrics on flaws detected during architectural review? Message-ID: <20090122202907.51874.qmail@cgisecurity.net> I've posted the following entry and I'm wondering what experiences people on this list have had. Security metrics on flaws detected during architectural review? http://www.cgisecurity.com/2009/01/security-metrics-on-flaws-detected-during-architectural-review.html Regards, - Robert Auger http://www.cgisecurity.com/ http://www.webappsec.org/ From gem at cigital.com Mon Jan 26 12:58:46 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 26 Jan 2009 12:58:46 -0500 Subject: [SC-L] OWASP interviews McGraw (oh my) Message-ID: hi sc-l, OWASP just posted an interview with me as part of their budding podcast series. It's nice to have the tables turned after doing all the Silver Bullet (and Reality Check) interviews! It's also nice to be able to answer some of the questions that OWASP types have about Cigital's approach to software security. Download the podcast here: https://www.owasp.org/index.php/Podcast_5 The OWASP interviewer is Jim Manico, and he did a great job. He was a little worried about some of the questions he asked. In fact, off the record he kept saying he was sorry and telling me that I did not have to address certain questions. Personally, I enjoyed the questions he asked immensely. Though some of his questions were loaded, I do hope that my answers may serve to clarify our position and eliminate OWASP concerns. Here are a few of the many more questions I address in the podcast: * Why do you insist on use of the term "software security" as opposed to "application security"? * What is static analysis good for and what is it no good for? * What is the exact relationship between Cigital and Fortify? * Why do you think your "top 19" is any better than the OWASP top 10 or the CWE top 25? (Special note, the 19 Sins work is Mike Howard's and John Viega's...I was not involved.) * Why does Cigital have a proprietary approach to IP? * What makes the Touchpoints any better than the SDL or CLASP? * What is your relationship with Allan Paller and SANS? * Who picked the "porn music" theme for Silver Bullet? As an extra bonus, the theme music for this episode is a song written and recorded by my band Where's Aubrey. Anyway, enjoy the podcast, and let me know what you think about my answers! gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Mon Jan 26 13:34:42 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 26 Jan 2009 13:34:42 -0500 Subject: [SC-L] OWASP interviews McGraw (oh my) In-Reply-To: References: Message-ID: <622C81E8-9E67-4C62-9838-C1FBA2F8A55E@krvw.com> On Jan 26, 2009, at 12:58 PM, Gary McGraw wrote: > OWASP just posted an interview with me as part of their budding > podcast series. Looking forward to it, thanks. I've been quite impressed with their first couple podcasts. Packed with useful info. After hearing the second one, I grabbed their LiveCD image, which I've found to be extremely useful. Just about anyone using the OWASP tools could benefit from the livecd, in my opinion. Just having a read-to-fly WebGoat/WebScarab is worth the effort all by itself. Great stuff! 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/20090126/9cf5ab65/attachment.bin From James.McGovern at thehartford.com Mon Jan 26 13:54:54 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 26 Jan 2009 13:54:54 -0500 Subject: [SC-L] OWASP interviews McGraw (oh my) In-Reply-To: References: Message-ID: <193C2C0486582D4B9917A217C4DA91E06C0728@AD1HFDEXC307.ad1.prod> Some questions that I would have asked: 1. The trend towards offshoring software development is increasing. When do you think customers will be able to have confidence in the ability of outsourcing vendors to develop secure software without it being considered a "special" service? 2. Do you think industry analysts and the media at large are doing a good enough job of helping raise awareness? What do you think magazines such as InformationWeek, CIO and Forbes should be doing that they aren't? 3. While you are an employee of Cigital, what other security firms do you think offer high quality consulting services in this space? 4. Many organizations no longer budget for "developer" tools. Do you think that static analysis will fail economically if funding for development has shifted away from developer activities? 5. What are the gaps that OWASP and other security-oriented communities aren't yet thinking about? 6. Name some examples of Fortune enterprises whom you think are thinking about software security correctly? 7. Microsoft is the industry whipping boy and if we acknowledge that customers may not want them to be more secure as core changes may break backward compatibility, is software security always doomed to mediocrity? 8. To become a competent software security professional, what do you think the ideal career path looks like? 9. What bloggers do you think can bring insight into understanding secure coding practices? 10. Any opinions on whether Sun, EMC, Oracle and CA are making adequate progress towards software security being built into their products? -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Monday, January 26, 2009 12:59 PM To: Secure Code Mailing List Subject: [SC-L] OWASP interviews McGraw (oh my) hi sc-l, OWASP just posted an interview with me as part of their budding podcast series. It's nice to have the tables turned after doing all the Silver Bullet (and Reality Check) interviews! It's also nice to be able to answer some of the questions that OWASP types have about Cigital's approach to software security. Download the podcast here: https://www.owasp.org/index.php/Podcast_5 The OWASP interviewer is Jim Manico, and he did a great job. He was a little worried about some of the questions he asked. In fact, off the record he kept saying he was sorry and telling me that I did not have to address certain questions. Personally, I enjoyed the questions he asked immensely. Though some of his questions were loaded, I do hope that my answers may serve to clarify our position and eliminate OWASP concerns. Here are a few of the many more questions I address in the podcast: * Why do you insist on use of the term "software security" as opposed to "application security"? * What is static analysis good for and what is it no good for? * What is the exact relationship between Cigital and Fortify? * Why do you think your "top 19" is any better than the OWASP top 10 or the CWE top 25? (Special note, the 19 Sins work is Mike Howard's and John Viega's...I was not involved.) * Why does Cigital have a proprietary approach to IP? * What makes the Touchpoints any better than the SDL or CLASP? * What is your relationship with Allan Paller and SANS? * Who picked the "porn music" theme for Silver Bullet? As an extra bonus, the theme music for this episode is a song written and recorded by my band Where's Aubrey. Anyway, enjoy the podcast, and let me know what you think about my answers! gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck 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. _______________________________________________ ************************************************************ 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 Jan 26 14:06:13 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 26 Jan 2009 14:06:13 -0500 Subject: [SC-L] OWASP interviews McGraw (oh my) In-Reply-To: <193C2C0486582D4B9917A217C4DA91E06C0728@AD1HFDEXC307.ad1.prod> Message-ID: Hi James, Those are great questions. You should do a podcast! In fact, maybe we should do a "reverse" Silver Bullet where you interview me. I'll have to see if that's something I can pull off. Lets talk about that off list. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com On 1/26/09 1:54 PM, "McGovern, James F (HTSC, IT)" wrote: Some questions that I would have asked: 1. The trend towards offshoring software development is increasing. When do you think customers will be able to have confidence in the ability of outsourcing vendors to develop secure software without it being considered a "special" service? 2. Do you think industry analysts and the media at large are doing a good enough job of helping raise awareness? What do you think magazines such as InformationWeek, CIO and Forbes should be doing that they aren't? 3. While you are an employee of Cigital, what other security firms do you think offer high quality consulting services in this space? 4. Many organizations no longer budget for "developer" tools. Do you think that static analysis will fail economically if funding for development has shifted away from developer activities? 5. What are the gaps that OWASP and other security-oriented communities aren't yet thinking about? 6. Name some examples of Fortune enterprises whom you think are thinking about software security correctly? 7. Microsoft is the industry whipping boy and if we acknowledge that customers may not want them to be more secure as core changes may break backward compatibility, is software security always doomed to mediocrity? 8. To become a competent software security professional, what do you think the ideal career path looks like? 9. What bloggers do you think can bring insight into understanding secure coding practices? 10. Any opinions on whether Sun, EMC, Oracle and CA are making adequate progress towards software security being built into their products? -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Monday, January 26, 2009 12:59 PM To: Secure Code Mailing List Subject: [SC-L] OWASP interviews McGraw (oh my) hi sc-l, OWASP just posted an interview with me as part of their budding podcast series. It's nice to have the tables turned after doing all the Silver Bullet (and Reality Check) interviews! It's also nice to be able to answer some of the questions that OWASP types have about Cigital's approach to software security. Download the podcast here: https://www.owasp.org/index.php/Podcast_5 The OWASP interviewer is Jim Manico, and he did a great job. He was a little worried about some of the questions he asked. In fact, off the record he kept saying he was sorry and telling me that I did not have to address certain questions. Personally, I enjoyed the questions he asked immensely. Though some of his questions were loaded, I do hope that my answers may serve to clarify our position and eliminate OWASP concerns. Here are a few of the many more questions I address in the podcast: * Why do you insist on use of the term "software security" as opposed to "application security"? * What is static analysis good for and what is it no good for? * What is the exact relationship between Cigital and Fortify? * Why do you think your "top 19" is any better than the OWASP top 10 or the CWE top 25? (Special note, the 19 Sins work is Mike Howard's and John Viega's...I was not involved.) * Why does Cigital have a proprietary approach to IP? * What makes the Touchpoints any better than the SDL or CLASP? * What is your relationship with Allan Paller and SANS? * Who picked the "porn music" theme for Silver Bullet? As an extra bonus, the theme music for this episode is a song written and recorded by my band Where's Aubrey. Anyway, enjoy the podcast, and let me know what you think about my answers! gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck 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. _______________________________________________ ************************************************************ 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 coley at linus.mitre.org Wed Jan 28 18:20:37 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 28 Jan 2009 18:20:37 -0500 (EST) Subject: [SC-L] SDL / Secure Coding and impact on CWE / Top 25 Message-ID: In the past year or so, I've been of a growing mindset that one of the hidden powers of CWE and other weakness/bug/vulnerability/attack taxonomies would be in evaluating secure coding practices: if you do X and Y, then what does that actually buy you, in terms of which vulnerabilities are fixed or mitigated? We capture some of that in CWE with CAPEC mappings for attacks. We've also mapped to the CERT C Secure Coding standard, as reflected in this CWE view: http://cwe.mitre.org/data/graphs/734.html (for the complete/detailed listing, click the "Slice" button on the upper right and sift through the Taxonomy Mappings). Or, check out the coverage graphs that show where the coding standard fits within the two main CWE hierarchical views: http://cwe.mitre.org/data/pdfs.html Now Microsoft has released a paper that shows how their SDL practices address the Top 25, like they did when the OWASP Top Ten came out. To me, this seems like a productive practice and a potential boon to consumers, *if* other vendors adopt similar practices. Are there ways that the software security community can further encourage this type of thing from vendors? Should we? Gary, do your worst ;-) http://blogs.msdn.com/sdl/archive/2009/01/27/sdl-and-the-cwe-sans-top-25.aspx - Steve From arian.evans at anachronic.com Wed Jan 28 21:42:46 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Wed, 28 Jan 2009 18:42:46 -0800 Subject: [SC-L] SDL / Secure Coding and impact on CWE / Top 25 In-Reply-To: References: Message-ID: I think that you are spot on, and people are sooner than later going to be demanding that, as a by-product of our shrinking economic reality. Take this example (not to stir up a semantic pissing match): "Insufficient Input Validation" I get it. I understand the importance of it. But it is not clear to a business owner or C level what that means to execute on. It is fairly ambiguous, especially in Web 2.0 world, what that really means. And often you find in the slippery slope between design and pattern issues, and implementation-level defects, that your fundamental data/function boundary problem is *not* best solved/enforced via input validation. In the case where the ideal solution to enforce a data/function boundary is parameterized sql, or encoded output (or a separate data/control channel), IV in this case simply functions as an attack surface reduction mechanism and the costs associated in defining and enforcing what may be loosely typed data by requirement, can be negligible at best. Obviously this is highly contextual and YMMV on that slippery slope between changing a fundamental design to fixing singular implementation errors. Architecture will play a huge key in figuring cost. But if I have to "pick one" in a "weak data access" scenario: 1) Stronger IV/data typing (before queries are built) 2) Parameterized SQL or abstracted data access layer 3) Principle of least privilege definition and strict CRUD enforcement (by objects accessing data) We would all like to know which has the most return. I think that will be tough though. I've found cases where some simple CRUD tweaking mitigated all negative impact to successful syntax attacks. And I've found cases where it did not help at all, or due to design, simply was not possible to make meaningful priv separations. How's that for a verbose "Yes"? Good questions. ciao -- Arian Evans "I ask, sir, what is the militia? It is the whole people. To disarm the people is the best and most effectual way to enslave them." -- Patrick Henry On Wed, Jan 28, 2009 at 3:20 PM, Steven M. Christey wrote: > > In the past year or so, I've been of a growing mindset that one of the > hidden powers of CWE and other weakness/bug/vulnerability/attack > taxonomies would be in evaluating secure coding practices: if you do X and > Y, then what does that actually buy you, in terms of which vulnerabilities > are fixed or mitigated? We capture some of that in CWE with CAPEC > mappings for attacks. > > We've also mapped to the CERT C Secure Coding standard, as reflected in > this CWE view: http://cwe.mitre.org/data/graphs/734.html (for the > complete/detailed listing, click the "Slice" button on the upper right and > sift through the Taxonomy Mappings). Or, check out the coverage graphs > that show where the coding standard fits within the two main CWE > hierarchical views: http://cwe.mitre.org/data/pdfs.html > > Now Microsoft has released a paper that shows how their SDL practices > address the Top 25, like they did when the OWASP Top Ten came out. To me, > this seems like a productive practice and a potential boon to consumers, > *if* other vendors adopt similar practices. Are there ways that the > software security community can further encourage this type of thing from > vendors? Should we? > > Gary, do your worst ;-) > > http://blogs.msdn.com/sdl/archive/2009/01/27/sdl-and-the-cwe-sans-top-25.aspx > > - 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 gem at cigital.com Mon Feb 2 16:05:06 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 2 Feb 2009 16:05:06 -0500 Subject: [SC-L] Reality Check: Jim Routh, DTCC Message-ID: hi sc-l, This morning we released the second episode of the Reality Check Podcast. This month's victim is Jim Routh, CISO of Depository Trust Clearing Corporation (DTCC). DTCC has a very advanced software security initiative that is well worth learning about. We talk about that in this interview. Have a listen! http://www.cigital.com/realitycheck/show-002 I'm also pleased to announce that CSO online has syndicated Reality Check and will be distributing the podcast to their CSO audience. You can find the first episode with Steve Lipner here: http://www.csoonline.com/podcast/478761/Show_An_Interview_With_Steve_Lipner And Jim's episode here: http://www.csoonline.com/podcast/478764/Show_An_Interview_with_Jim_Routh gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From robert at webappsec.org Mon Feb 2 21:15:33 2009 From: robert at webappsec.org (robert at webappsec.org) Date: Mon, 2 Feb 2009 21:15:33 -0500 (EST) Subject: [SC-L] The security industry needs to re-align its training expectations for QA Message-ID: <20090203021533.62407.qmail@cgisecurity.net> I've posted a rant on training security to QA people. The security industry needs to re-align its training expectations for QA http://www.cgisecurity.com/2009/02/the-security-industry-needs-to-realign-its-training-expectations-for-qa.html Regards, - Robert http://www.cgisecurity.com/ http://www.webappsec.org/ ---------------------------------------------------------------------------- Join WASC on IRC: irc.freenode.net #webappsec From ken at krvw.com Tue Feb 3 10:39:48 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 3 Feb 2009 10:39:48 -0500 Subject: [SC-L] Web Applications: Achilles' Heel Of Corporate Security -- Security -- InformationWeek Message-ID: <1526D74F-690D-4D0B-AC52-7ECFF377990C@krvw.com> No big surprises for SC-L readers, I'm sure, but it's still an interesting read: http://www.informationweek.com/news/security/vulnerabilities/showArticle.jhtml?articleID=213000162 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/20090203/016cf927/attachment.bin From Paco at cigital.com Wed Feb 4 14:17:49 2009 From: Paco at cigital.com (Paco Hope) Date: Wed, 4 Feb 2009 14:17:49 -0500 Subject: [SC-L] Security in QA is more than exploits Message-ID: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> All, I just read Robert's blog entry about "re-aligning training expectations for QA." (http://bit.ly/157Pc3) It has some useful points that both developers and so-called "security people" need to hear. I disagree with some implicit biases, however, and I think we need to get past some stereotypes that sneak out in the article. Bias #1, obviously, is the focus on the web. Despite its omnipresence, there is more non-web software than web software in the world, and non-web software does more important stuff than all the web software combined. The role of security in _software_ testing is vital, and the presence or absence of web technologies does not change that. Despite writing a recent book on Web Security Testing, I know my place in the universe. Quality assurance and software testing are disciplines far older than the web, and their mission is so much bigger than finding vulnerabilities. Bias #2 is vulnerabilities ?ber alles. By talking about weaving vulnerabilities into security test plans, we've overlooked the first place where security goes into the QA process: test strategy. Look at any of the prominent folks in QA (Jon Bach, Michael Bolton, Rex Black, Cem Kaner), the people I'm privileged to share podiums with at QA conferences like STAR West, STAR East, and Better Software, and you'll see that security is part of the overall risk-based testing strategy. Risk-based testing has been around for a really long time. Longer than the web. Before anyone talks about vulnerabilities to test for, we have to figure out what the business cares about and why. What could go wrong? Who cares? What would the impact be? Answers to those questions drive our testing strategy, and ultimately our test plans and test cases. Bias #3 is that idea that a bunch of web vulnerabilities are equivalent in impact to the business. That is, you just toss as many as you can into your test plan and test for as much as you can. This isn't how testing is prioritized. You don't organize testing based on which top X vulnerabilities are likely to affect your organization (as the blog suggests). Likelihood is one part of the puzzle. Business impact is the part that is missing. You prioritize security tests by risk severity?that marriage of likelihood and impact to the business. If I have a whole pile of very likely attacks that are all low or negligible impact, and I have a few moderately likely attacks that have high impact, I should prioritize my testing effort around the ones with greater impact to my business. Bias #4 is the treatment of testers like second class citizens. In the blog article, developers are "detail oriented" have a "deep understanding of flows." Constrast this with QA who merely understand "what is provided to them." They sound impotent, as if all they can do is what they're told. Software testing, despite whatever firsthand experience the author may have, is a mature discipline. It is older and more formalized than "security" as a discipline. Software testing is older than the Internet or the web. If software testing as a discipline has adopted security too slowly, given security's rise to the forefront in the marketplace, that might be a legitimate criticism. But I don't approve of the slandering QA by implying that they just take what's given them and execute it. QA is hard and there are some really bright minds working in that field. As someone who has been training in risk-based security testing for several years now, I totally agree with some points, but very much disagree with others. I agree that the "bug parade" (as we call it) of top X vulnerabilities to find is the wrong way to teach security testing. Risk management, though, has been a fundamental part of mainstream QA for a very long time. Likewise, risk management is the same technique that good "security people" use to prioritize their results. Risk management is certainly how the business is going to make decisions about which issues to remediate and when. Risk management is what ties this all together. If there's something that QA needs to learn that they're not already learning, it's the weaving of "security" into the risk management techniques they already know how to do. If testers fall short in their ability to apply risk management techniques, then they are falling short against the QA yardstick, there's nothing particularly security-related in this observation. If they are applying mature QA practices with modern risk management, but are not adequately addressing the software-induced business risks facing their stakeholders, then some security training might be in order. That security training should be built on the foundation of modern QA practice, including risk-based testing. So, in some ways we agree: speak the lingo of QA. But in other ways we disagree. I think the original article fails to give credit to the decades of substantial research and practice in QA. In other words, it's a lot more than speaking the language. It is standing on the shoulders of giants, not their toes. My $0.02. Paco From Dave.Wieneke at cunamutual.com Wed Feb 4 14:54:18 2009 From: Dave.Wieneke at cunamutual.com (Wieneke, David A.) Date: Wed, 4 Feb 2009 13:54:18 -0600 Subject: [SC-L] Security in QA is more than exploits In-Reply-To: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> References: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> Message-ID: <50333F9C830FD044B8C0CC10ADF9337E02C7CD06@CMPXBECP04.CMUTUAL.COM> "Before anyone talks about vulnerabilities to test for, we have to figure out what the business cares about and why. What could go wrong? Who cares? What would the impact be? Answers to those questions drive our testing strategy, and ultimately our test plans and test cases." We have to figure out what the __customer__ cares about and why. Often times, the business areas don't have a clue about their customers. The business areas throw web applications into the webiverse and hope someone will bite. What is going to keep customers? What is going to drive customers away? My 2 cents Dave David Wieneke, MSIT-IS, GSEC IT Security Engineer Security Operations and Administration CUNA Mutual Group Dave.Wieneke at Cunamutual.com -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Paco Hope Sent: Wednesday, February 04, 2009 1:18 PM To: SC-L at securecoding.org Subject: Re: [SC-L] Security in QA is more than exploits All, I just read Robert's blog entry about "re-aligning training expectations for QA." (http://bit.ly/157Pc3) It has some useful points that both developers and so-called "security people" need to hear. I disagree with some implicit biases, however, and I think we need to get past some stereotypes that sneak out in the article. Bias #1, obviously, is the focus on the web. Despite its omnipresence, there is more non-web software than web software in the world, and non-web software does more important stuff than all the web software combined. The role of security in _software_ testing is vital, and the presence or absence of web technologies does not change that. Despite writing a recent book on Web Security Testing, I know my place in the universe. Quality assurance and software testing are disciplines far older than the web, and their mission is so much bigger than finding vulnerabilities. Bias #2 is vulnerabilities ?ber alles. By talking about weaving vulnerabilities into security test plans, we've overlooked the first place where security goes into the QA process: test strategy. Look at any of the prominent folks in QA (Jon Bach, Michael Bolton, Rex Black, Cem Kaner), the people I'm privileged to share podiums with at QA conferences like STAR West, STAR East, and Better Software, and you'll see that security is part of the overall risk-based testing strategy. Risk-based testing has been around for a really long time. Longer than the web. Before anyone talks about vulnerabilities to test for, we have to figure out what the business cares about and why. What could go wrong? Who cares? What would the impact be? Answers to those questions drive our testing strategy, and ultimately our test plans and test cases. Bias #3 is that idea that a bunch of web vulnerabilities are equivalent in impact to the business. That is, you just toss as many as you can into your test plan and test for as much as you can. This isn't how testing is prioritized. You don't organize testing based on which top X vulnerabilities are likely to affect your organization (as the blog suggests). Likelihood is one part of the puzzle. Business impact is the part that is missing. You prioritize security tests by risk severity-that marriage of likelihood and impact to the business. If I have a whole pile of very likely attacks that are all low or negligible impact, and I have a few moderately likely attacks that have high impact, I should prioritize my testing effort around the ones with greater impact to my business. Bias #4 is the treatment of testers like second class citizens. In the blog article, developers are "detail oriented" have a "deep understanding of flows." Constrast this with QA who merely understand "what is provided to them." They sound impotent, as if all they can do is what they're told. Software testing, despite whatever firsthand experience the author may have, is a mature discipline. It is older and more formalized than "security" as a discipline. Software testing is older than the Internet or the web. If software testing as a discipline has adopted security too slowly, given security's rise to the forefront in the marketplace, that might be a legitimate criticism. But I don't approve of the slandering QA by implying that they just take what's given them and execute it. QA is hard and there are some really bright minds working in that field. As someone who has been training in risk-based security testing for several years now, I totally agree with some points, but very much disagree with others. I agree that the "bug parade" (as we call it) of top X vulnerabilities to find is the wrong way to teach security testing. Risk management, though, has been a fundamental part of mainstream QA for a very long time. Likewise, risk management is the same technique that good "security people" use to prioritize their results. Risk management is certainly how the business is going to make decisions about which issues to remediate and when. Risk management is what ties this all together. If there's something that QA needs to learn that they're not already learning, it's the weaving of "security" into the risk management techniques they already know how to do. If testers fall short in their ability to apply risk management techniques, then they are falling short against the QA yardstick, there's nothing particularly security-related in this observation. If they are applying mature QA practices with modern risk management, but are not adequately addressing the software-induced business risks facing their stakeholders, then some security training might be in order. That security training should be built on the foundation of modern QA practice, including risk-based testing. So, in some ways we agree: speak the lingo of QA. But in other ways we disagree. I think the original article fails to give credit to the decades of substantial research and practice in QA. In other words, it's a lot more than speaking the language. It is standing on the shoulders of giants, not their toes. My $0.02. Paco _______________________________________________ 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 Feb 4 16:56:19 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Wed, 4 Feb 2009 13:56:19 -0800 Subject: [SC-L] Security in QA is more than exploits In-Reply-To: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> References: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> Message-ID: <490a979e0902041356l1e524318w1714ec55178557b1@mail.gmail.com> On Wed, Feb 4, 2009 at 11:17 AM, Paco Hope wrote: > Before anyone talks about vulnerabilities to test for, we have to figure > out what the business cares about and why. What could go wrong? Who cares? > What would the impact be? Answers to those questions drive our testing > strategy, and ultimately our test plans and test cases. Paco, I don't really read what Robert wrote this way. I think what this general "risk management" approach misses is that certain things are always going to be defects, bugs, etc. Sure there are differences per-business and per-application. All bugs aren't created equal. But I think we lose something when we start saying "everything is relative." Each application, each business, each org needs a testing plan, strategy, and a definition of what they care about. At the same time there are going to be common types of tests that everyone performs. All Robert is pointing out is that if certain classes of vulnerabilities are important to you, then you want to have a common testing process for them. Bias #3 is that idea that a bunch of web vulnerabilities are equivalent in > impact to the business. That is, you just toss as many as you can into your > test plan and test for as much as you can. This isn't how testing is > prioritized. Again, I don't think he's saying this at all. Where I work every XSS is absolutely critical, and we get them fixed immediately. this might not be the case elsewhere. Some folks don't really worry about XSS that much. Because I can find differences though doesn't mean that everything is relative. Authentication bypass, SQL Injection, these types of things tend to rate HIGH/P1/Major for almost everyone, and I think. > > You don't organize testing based on which top X vulnerabilities are likely > to affect your organization (as the blog suggests). Likelihood is one part > of the puzzle. Business impact is the part that is missing. You prioritize > security tests by risk severity?that marriage of likelihood and impact to > the business. If I have a whole pile of very likely attacks that are all low > or negligible impact, and I have a few moderately likely attacks that have > high impact, I should prioritize my testing effort around the ones with > greater impact to my business. Again - fair enough. But at the same time you also prioritize around effort to test and avoid, right? Bias #4 is the treatment of testers like second class citizens. In the blog > article, developers are "detail oriented" have a "deep understanding of > flows." Constrast this with QA who merely understand "what is provided to > them." They sound impotent, as if all they can do is what they're told. > Software testing, despite whatever firsthand experience the author may have, > is a mature discipline. It is older and more formalized than "security" as a > discipline. Software testing is older than the Internet or the web. If > software testing as a discipline has adopted security too slowly, given > security's rise to the forefront in the marketplace, that might be a > legitimate criticism. But I don't approve of the slandering QA by implying > that they just take what's given them and execute it. QA is hard and there > are some really bright minds working in that field. I don't think Robert's comments were about the general field/discipline of QA. His commentary was more about the types of QA organizations he has come across. My own experience (albeit limited as well) has found a relative lack of highly skilled QA folks as well. There are people responsible for quality that are at the level you're talking about but I still bet they are more the exception than the rule. Most QA organizations are staffed with people writing relatively simple tests, running through positive functional testing, etc. I think the point here is that you have to tailor expectations to the organization you have. Much in the same way that if you have mostly junior programmers who are lucky to get their code to compile you're probably not going to have a lot of luck training them on formal proofs, rigorous design, etc. -- Andy Steingruebl steingra at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090204/9f6a2e0a/attachment.html From bugtraq at cgisecurity.net Wed Feb 4 21:17:39 2009 From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net) Date: Wed, 4 Feb 2009 21:17:39 -0500 (EST) Subject: [SC-L] Security in QA is more than exploits In-Reply-To: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> Message-ID: <20090205021739.45858.qmail@cgisecurity.net> For starters I believe you misinterpreted my comments on QA. I was in no way slamming their abilities. With this in mind comments below. > Before anyone talks about vulnerabilities to test for, we have to figure ou= > t what the business cares about and why. What could go wrong? Who cares? Wh= > at would the impact be? Answers to those questions drive our testing strate= > gy, and ultimately our test plans and test cases. We absolutely agree here. At the same time an externally exploitable sql injection needs to get fixed. The way qa/development is informed to its impact is through education likely via training. Not a single company with average hiring/skill requirements will have everybody (who needs to) know what sql injection is, and why it is bad. > Bias #3 is that idea that a bunch of web vulnerabilities are equivalent in = > impact to the business. That is, you just toss as many as you can into your= > test plan and test for as much as you can. This isn't how testing is prior= > itized. I said "A better approach in my opinion is to identify the top 10/25/x attacks/weaknesses/vulnerabilities that are likely to affect your own organization" These would be associated to customer or business impacts likely to affect you. Perhaps this could have been articulated better. > As someone who has been training in risk-based security testing for several= > years now, I totally agree with some points, but very much disagree with o= > thers. I agree that the "bug parade" (as we call it) of top X vulnerabiliti= > es to find is the wrong way to teach security testing. Risk management, tho= > ugh, has been a fundamental part of mainstream QA for a very long time. Lik= > ewise, risk management is the same technique that good "security people" us= > e to prioritize their results. Risk management is certainly how the busines= > s is going to make decisions about which issues to remediate and when. Risk= > management is what ties this all together. We agree. > If there's something that QA needs to learn that they're not already learni= > ng, it's the weaving of "security" into the risk management techniques they= > already know how to do. If testers fall short in their ability to apply ri= In your experience do you find average QA people doing risk management? In my experiences a Sr QA person/Team lead identifies what is going to be tested for a given release, and usually are the ones writing/tracking the test plans. > So, in some ways we agree: speak the lingo of QA. But in other ways we disa= > gree. I think the original article fails to give credit to the decades of s= > ubstantial research and practice in QA. In other words, it's a lot more tha= > n speaking the language. It is standing on the shoulders of giants, not the= > ir toes. Actually the main goal of the article is that information security people need to set appropriate expectations as to what QA cares about as their primary business function. They need to factor in that the majority of QA people don't care about security as a primary job function, and that if infosec wants them to care they had better be prepared - to speak their language and understand their needs - to customize and prioritize the security testing they may be doing instead of solely using generic top x lists > Paco Have a fantastic day Paco! Regards, - Robert From Paco at cigital.com Wed Feb 4 22:26:17 2009 From: Paco at cigital.com (Paco Hope) Date: Wed, 4 Feb 2009 22:26:17 -0500 Subject: [SC-L] Security in QA is more than exploits In-Reply-To: <20090205021739.45858.qmail@cgisecurity.net> References: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com>, <20090205021739.45858.qmail@cgisecurity.net> Message-ID: <853A02533F8C88439F2331EB19385384417F263DA6@va-mailhub.cigital.com> > For starters I believe you misinterpreted my comments on QA. I was in > no way slamming their abilities. With this in mind comments below. Sorry about that. I am sensitive to the bias. I went to a very small company once (10 people total) and as I looked around I saw offices with big LCDs (I assumed management) and cubicles with multi-core, multi-monitor setups (I assumed developers). Then I saw this old wooden table with 3 5-year-old HP desktops and a 15" tube monitor. I said to my host, the dev manager, "that's the QA workstation." He looked surprised and said it was. He asked how I knew. I said "because it's a piece of junk!" This plays out a lot in industry, both big and little. So I apologize if I misread and found bias where none was intended. I'm ever vigilant against it. > > Before anyone talks about vulnerabilities to test for, we have > > to figure out what the business cares about and why. What could > > go wrong? Who cares? What would the impact be? Answers to those > > questions drive our testing strategy, and ultimately our test plans > > and test cases. > > We absolutely agree here. At the same time an externally exploitable > sql injection needs to get fixed. Let me shock and appall people by saying "not necessarily." It is commonly believed that some bugs are so horrific that we can say, without considering the business context, "they must be fixed." 10 years ago we said this about buffer overflows. "If you find a buffer overflow, you *must* fix it immediately." Then we went into industry and found out that there were times where missing a market window was far more costly than releasing a known buffer overflow. Ditto for the most horrendous web vulnerability you can think of. I resist absolute statements like this. As Andy Steingruebl pointed out "you also prioritize around effort to test and avoid, right?" Of course. We all agree that the cost of the fix is weighed against the benefits of not fixing and an estimate of the impact of successful exploitation. And that's why it's always possible you'll find a bug that sounds horrible, but is released anyways. Andy also said "I think we lose something when we start saying 'everything is relative.'" I think we lose something more important if we try to impose abolutes: we lose the connection to the business. No business operates on absolutes and blind imperatives. Few, if any, profit-focused businesses dogmatically fix all remotely exploitable SQL injections. Every business looks pragmatically at these things. Fixing the bug might cause the release of the product to slip by 6 weeks or a major customer to buy a competitor's product this quarter instead of waiting for the release. It's always a judgment call by the business. Even if their goal and their track record is fixing 100% of sev 1 issues before release, you know that each sev 1 issue was considered in terms of its cost, impact, schedule delay and so on. > In your experience do you find average QA people doing risk > management? Not all of them. Actually our experiences parallel nicely. My point is that any weak QA practitioners we're seeing in the marketplace are not QA folks who are short on security training. We're seeing QA folks who are short on QA training. When I find QA folks who are up-to-date on the state-of-the-practice in modern QA, teaching them a little security is a lot easier. When we go to teach security to folks who are already behind in their basics, we're building a castle on shaky ground. > Actually the main goal of the article is that information security > people need to set appropriate expectations as to what QA cares about > as their primary business function. They need to factor in that the > majority of QA people don't care about security as a primary job > function, and that if infosec wants them to care they had better > be prepared to speak their language and understand their needs So I'll continue to violently agree with you. :) QA is a process of taking inputs in the form of requirements (use cases, stories, etc.) and producing evidence of correct behavior (in both expected and unexpected situations). If infosec wants to give QA something they can consume and use directly, security requirements would be a great artifact. They fit the QA workflow, render explicit the security expectations, and foster traceability and test case development. It is an outstanding idea for infosec guys to provide security test cases, or the framework for them, to QA. That beats the heck out of what they usually do. However, a bunch of test cases for XSS, CSRF, SQL injection and so on will not map easily to requirements or to the QA workflow. At what priority do they execute? When the business (inevitably) squeezes testing to try to claw back a day or two on the slipped schedule, can any of these security tests be left out? Why or why not? Without hanging them into the QA workflow with clear traceability, QA will struggle to prioritize them correctly and maintain them. Security requirements would make that priority and maintenance straightforward. At this point I'm not disagreeing with you, but taking your good approach and extending it a step farther. Cheers, Paco -- Paco Hope, CISSP - CSSLP Technical Manager, Cigital, Inc. http://www.cigital.com/ - +1.703.585.7868 Software Confidence. Achieved. From jim at manico.net Thu Feb 5 06:03:50 2009 From: jim at manico.net (Jim Manico) Date: Thu, 05 Feb 2009 01:03:50 -1000 Subject: [SC-L] OWASP Podcast #6 Message-ID: <498AC796.30903@manico.net> Hello SC-L I just pushed OWASP Podcast #6 live at http://www.owasp.org/index.php/Podcast_6 - an OWASP Roundtable with Brian Holyfield, Marcin Wielgoszewski, Andre Gironda and myself, Jim Manico. Our focus was WAF's. Thanks and I hope you enjoy, Jim Manico From steingra at gmail.com Thu Feb 5 09:39:09 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Thu, 5 Feb 2009 06:39:09 -0800 Subject: [SC-L] Security in QA is more than exploits In-Reply-To: <853A02533F8C88439F2331EB19385384417F263DA6@va-mailhub.cigital.com> References: <853A02533F8C88439F2331EB19385384417F263D9A@va-mailhub.cigital.com> <20090205021739.45858.qmail@cgisecurity.net> <853A02533F8C88439F2331EB19385384417F263DA6@va-mailhub.cigital.com> Message-ID: <490a979e0902050639l268e12d0h183dda82f53b8650@mail.gmail.com> On Wed, Feb 4, 2009 at 7:26 PM, Paco Hope wrote: > > Andy also said "I think we lose something when we start saying 'everything > is > relative.'" I think we lose something more important if we try to impose > abolutes: we lose the connection to the business. No business operates on > absolutes and blind imperatives. Few, if any, profit-focused businesses > dogmatically fix all remotely exploitable SQL injections. Every business > looks > pragmatically at these things. Fixing the bug might cause the release of > the > product to slip by 6 weeks or a major customer to buy a competitor's > product > this quarter instead of waiting for the release. It's always a judgment > call > by the business. Even if their goal and their track record is fixing 100% > of > sev 1 issues before release, you know that each sev 1 issue was considered > in > terms of its cost, impact, schedule delay and so on. The ppint here though is that repeatable processes do matter. Having a standard of what constitutes a given severity of bug standardized in a policy statement is a good thing. Sure that is hard as every application is different, but you need a starting place. And so while my standards don't say "XSS always equals P1" they do say "XSS that can be discovered in an external facing application" or even slightly more generically than that. So my bug priority matrix does talk about business impact because that is what matters, but I still have to give real world examples to folks who aren't expert security testers of how to handle a bug when they come across it. And we need to provide clear guidance in standards because every single bug shouldn't require an ad-hoc trage process. > > It is an outstanding idea for infosec guys to provide security test cases, > or > the framework for them, to QA. That beats the heck out of what they usually > do. However, a bunch of test cases for XSS, CSRF, SQL injection and so on > will > not map easily to requirements or to the QA workflow. At what priority do > they > execute? When the business (inevitably) squeezes testing to try to claw > back a > day or two on the slipped schedule, can any of these security tests be left > out? Why or why not? Without hanging them into the QA workflow with clear > traceability, QA will struggle to prioritize them correctly and maintain > them. > Security requirements would make that priority and maintenance > straightforward. At this point I'm not disagreeing with you, but taking > your good approach and extending it a step farther. I undertsand this, but handing security requirements to QA folks without a set of reeatable test cases for doing them isn't going to help much, in mos organizations. James Whittaker doesn't work for me :) . And if you're developing web applications you're probably going to have some set of standardized testing you do. You need to have a repository of test cases for certain things, and I think testing for certain type of attacks is probably a decent starting point. Sure you want QA to own those, but if you're worried about buffer overflows you've going to have a bunch of standard test cases, test scenarios, test data (long input strings, inputs with null bytes in them, etc) that you're going to reuse a bunch of times so that each tester isn't starting from scratch when they see the security requirments - "Application must handle input properly and not crash." I don't think we're far off here in what we're saying, but repeatability is key. Leaving the interface with QA at the level of security requriements in a functional spec isn't going to cut it. And, you're probably going to have some standardized set of security requirements for a whole swath of your applications that you might not want to repeat ad-naseum in every single product/feature spec. This is the place for standards, policies, and testing guidelines so that this becomes just part of the regular QA cycle. -- Andy Steingruebl steingra at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090205/23d139ca/attachment.html From robert at webappsec.org Mon Feb 9 16:15:25 2009 From: robert at webappsec.org (robert at webappsec.org) Date: Mon, 9 Feb 2009 16:15:25 -0500 (EST) Subject: [SC-L] Application Security Vendors Need Help With Reporting Message-ID: <20090209211525.87902.qmail@cgisecurity.net> Application Security Vendors Need Help With Reporting http://www.cgisecurity.com/2009/02/application-security-vendors-need-help-with-reporting.html Regards, - Robert http://www.cgisecurity.com/ http://www.webappsec.org/ From gem at cigital.com Tue Feb 10 07:48:03 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 10 Feb 2009 07:48:03 -0500 Subject: [SC-L] informIT: nine things everybody does Message-ID: hi sc-l, informIT just published my February column, once again co-authored by Brian Chess and Sammy Migues. This is the third in the series of articles about the maturity model. We have decided to call it the Building Security In Maturity Model (BSIMM). The latest article covers 13 of the 110 activities in the model. Of those 14, all nine of the organizations in our study did nine. The other 4 are done by most organizations (but not all nine), and were added to ensure coverage of the Software Security Framework. http://www.informit.com/articles/article.aspx?p=1326511 We will release the complete BSIMM model soon under a creative commons license. Stay tuned for that! gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From smurray1 at nycap.rr.com Fri Feb 13 10:49:19 2009 From: smurray1 at nycap.rr.com (smurray1) Date: Fri, 13 Feb 2009 10:49:19 -0500 Subject: [SC-L] Conditional Compile statements-- coding standards, and code review Message-ID: <4995967F.2090608@nycap.rr.com> I am reviewing a QA team's procedures for code review. I have an issue with conditional compile statements (#ifdef in the C world). My issue is that it is very difficult to have complete confidence that a piece of code inside the condition (the "controlled text") does indeed not get compiled and included in the final executable. The coding standards used by the organization are fairly rigorous, but there is no mention of prohibiting (or of even limiting) the used of conditional compile statements. They are typically used for debug purposes-- that is, debug messages that get generated when the code is compiled for debugging and then are omitted in the production builds. This is probably more of a correct code issue than a security issue, but there are most definitely security implications. I am curious to hear people's thoughts on this. Do most organizations prohibit (or at least limit) conditional compile statements? If not, how is the "controlled text" inside conditional compile statements handled by code reviewers? The QA procedures I am reviewing basically ignore them, since "They won't be in the production build", but I am very uncomfortable with that. There are many ways in C to define the macro that controls the conditional compile (with #define statements, with compiler flags, etc). It just seems very hard to verify that the ifdefs will work as planned in the final compile. Thanks!! Sean T Murray From rcs at cert.org Fri Feb 13 13:37:35 2009 From: rcs at cert.org (Robert Seacord) Date: Fri, 13 Feb 2009 13:37:35 -0500 Subject: [SC-L] Conditional Compile statements-- coding standards, and code review In-Reply-To: <4995967F.2090608@nycap.rr.com> References: <4995967F.2090608@nycap.rr.com> Message-ID: Sean, I think you would want to provide this guarantee through some sort of static assertion. For example, if you want to ensure that text controlled by FRED is not included in a release build, you could include an #error preprocessor directive as part of the controlled text that will generate an error message for a release build: #ifdef FRED # define MACRO(x) (x + 5) # ifdef NDEBUG # error "FRED defined in release build" # endif #endif The idea here is that NDEBUG would be defined for a release build. If FRED and NDEBUG were defined in the same build it would result in a fatal compile-time diagnostic. I'm not sure if there is a more elegant or widely deployed solution to this problem. rCs -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of smurray1 Sent: Friday, February 13, 2009 10:49 AM To: sc-l at securecoding.org Subject: [SC-L] Conditional Compile statements-- coding standards, and code review I am reviewing a QA team's procedures for code review. I have an issue with conditional compile statements (#ifdef in the C world). My issue is that it is very difficult to have complete confidence that a piece of code inside the condition (the "controlled text") does indeed not get compiled and included in the final executable. The coding standards used by the organization are fairly rigorous, but there is no mention of prohibiting (or of even limiting) the used of conditional compile statements. They are typically used for debug purposes-- that is, debug messages that get generated when the code is compiled for debugging and then are omitted in the production builds. This is probably more of a correct code issue than a security issue, but there are most definitely security implications. I am curious to hear people's thoughts on this. Do most organizations prohibit (or at least limit) conditional compile statements? If not, how is the "controlled text" inside conditional compile statements handled by code reviewers? The QA procedures I am reviewing basically ignore them, since "They won't be in the production build", but I am very uncomfortable with that. There are many ways in C to define the macro that controls the conditional compile (with #define statements, with compiler flags, etc). It just seems very hard to verify that the ifdefs will work as planned in the final compile. Thanks!! Sean T Murray _______________________________________________ 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 Jason.Bennett at thales-esecurity.com Mon Feb 16 04:46:05 2009 From: Jason.Bennett at thales-esecurity.com (Bennett, Jason) Date: Mon, 16 Feb 2009 09:46:05 -0000 Subject: [SC-L] Conditional Compile statements-- coding standards, and code review Message-ID: Robert/Sean, It's a good question and one that I've never seen a really good answer to! Robert your option certain works but I feel that it somewhat prone to error if deployed on a large source base. So for example if a developer actually uses: #ifdef FRED # define MACRO(x) (x + 5) #endif ... then it's quite possible that this is missed by the review team and there is of course no guarantee that all code is reviewed manual. There is also the problem that there may be more than a single target release build for different variants i.e. it's not just a binary choice of release or debug versions. To make a more 'fool proof' mechanism I believe that it's better to have a more controlled use of which pre-processor directives are allowed for conditional compilation and ensure their use is consistent -- this is particular true of debug information which I believe causes the most problems. Following this approach would allow you to perform automatic searches for directives that are not on a defined white list. A word of warning this isn't as easy as it seems once you start getting statements of the following type -- this just re-enforces the problem of conditional compilation: #if defined c1 && !(defined c2 || defined c3) ... #elif defined C4 ... #endif What would be really nice is to have an automatic tool that can check that for say build target A you can only have I, J and K defined but for not L and M -- using 3rd party code which is often designed to be ported to multiple targets sorting out what is actually used is not easy at all! Use should also looked at carefully to ensure that conditional compilation is only used where 'required'. So as an example do you really want all those call traces and information output used during development left in the code? In conclusion I believe that you should aim for as much automation as possible and also taking the problem out of the developer's hands. It's much easier to ensure that you've done something right once in your build system than expect every developer to do it right every time -- in my experience developers are happy to change what is in their 'local domain' but think about things a bit more carefully if they are making a change the can affect the entire development. Obviously these are just some ideas and I'm sure that there or other equally good solutions and as with all these things it does depend on what level of assurance you want otherwise you get the answer of don't allow conditional compilation! 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 dcrocker at eschertech.com Sun Feb 22 05:21:51 2009 From: dcrocker at eschertech.com (David Crocker) Date: Sun, 22 Feb 2009 10:21:51 -0000 Subject: [SC-L] Conditional Compile statements-- coding standards, and code review In-Reply-To: References: Message-ID: <3887DA0F294E4DBF8FD75C53410ED2A3@escheradmin> When my organization develops code in C++, we generally ban use of #ifdef and #if defined(X), but we otherwise allow use of #if. The reason is that if you mis-spell the identifier that follows #ifdef, the compiler can't warn you. For example, if you write #ifdef FRDE ... #endif when you meant #ifdef FRED, the compiler doesn't warn you, and the conditional may not be interpreted as was intended. Best regards David Crocker, Escher Technologies Ltd. http://www.eschertech.com -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Bennett, Jason Sent: 16 February 2009 09:46 To: 'sc-l at securecoding.org' Subject: Re: [SC-L] Conditional Compile statements-- coding standards,and code review Robert/Sean, It's a good question and one that I've never seen a really good answer to! Robert your option certain works but I feel that it somewhat prone to error if deployed on a large source base. So for example if a developer actually uses: #ifdef FRED # define MACRO(x) (x + 5) #endif ... then it's quite possible that this is missed by the review team and there is of course no guarantee that all code is reviewed manual. There is also the problem that there may be more than a single target release build for different variants i.e. it's not just a binary choice of release or debug versions. To make a more 'fool proof' mechanism I believe that it's better to have a more controlled use of which pre-processor directives are allowed for conditional compilation and ensure their use is consistent -- this is particular true of debug information which I believe causes the most problems. Following this approach would allow you to perform automatic searches for directives that are not on a defined white list. A word of warning this isn't as easy as it seems once you start getting statements of the following type -- this just re-enforces the problem of conditional compilation: #if defined c1 && !(defined c2 || defined c3) ... #elif defined C4 ... #endif What would be really nice is to have an automatic tool that can check that for say build target A you can only have I, J and K defined but for not L and M -- using 3rd party code which is often designed to be ported to multiple targets sorting out what is actually used is not easy at all! Use should also looked at carefully to ensure that conditional compilation is only used where 'required'. So as an example do you really want all those call traces and information output used during development left in the code? In conclusion I believe that you should aim for as much automation as possible and also taking the problem out of the developer's hands. It's much easier to ensure that you've done something right once in your build system than expect every developer to do it right every time -- in my experience developers are happy to change what is in their 'local domain' but think about things a bit more carefully if they are making a change the can affect the entire development. Obviously these are just some ideas and I'm sure that there or other equally good solutions and as with all these things it does depend on what level of assurance you want otherwise you get the answer of don't allow conditional compilation! 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". _______________________________________________ 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 Feb 23 18:06:41 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 23 Feb 2009 18:06:41 -0500 Subject: [SC-L] Silver Bullet 35: Daniel Suarez Message-ID: hi sc-l, I think you'll like this episode of Silver Bullet, which is a bit off the beaten path. In it, I interview Daniel Suarez, the author of a once self-published and now-optioned-for-a-movie techno-thriller "The Deamon." Daniel brought me a copy of his book this summer, just in time for "no fly July" when I also read "accelerando" and "halting state." There are some astounding ideas for distributed emergent attacks in here... Anyway, have a listen: http://www.cigital.com/silverbullet/show-035/ And then read the book. It's great. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From koved at us.ibm.com Mon Mar 2 16:57:45 2009 From: koved at us.ibm.com (Larry Koved) Date: Mon, 2 Mar 2009 16:57:45 -0500 Subject: [SC-L] CFP: W2SP 2009: Web 2.0 Security and Privacy 2009 - submission deadline is this Friday In-Reply-To: Message-ID: This may be of interest to readers of this mailing list. This is an announcement of the call for papers for the third in a series of successful workshops on topics related to security and privacy for Web 2.0. If you would, please pass this information on to your colleagues who may be interested in this workshop. The submission deadline is this Friday. Thanks. Larry Koved Co-Chair, W2SP --------------------------------------------------------- http://w2spconf.com/2009/ Workshop Call for Papers W2SP 2009: Web 2.0 Security and Privacy 2009 Thursday, May 21 The Claremont Resort, Oakland, California Previous W2SP Workshops: 2008, 2007 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. Enabled by a wave of new technology, these social and business interactions rely on composition of content and services from multiple sources, commonly called mash-ups, leading to systems with complex trust boundaries. This trend is likely to continue because individuals and businesses desire the efficiency and simplicity these technologies offer. Together with their virtues, these technologies raise issues about management of identities, reputation, privacy, anonymity, transient and long term relationships, and composition of function and content, both on the server and on the client (web browser). Although the underlying security and privacy issues are not new, the use of these technologies on a wide scale and by a broad audience raises new questions. This workshop is intended to discuss the limitations of current technologies and explore alternatives. The scope of W2SP 2009 includes, but is not limited to: -- Trustworthy cloud-based services -- Privacy and reputation in social networks -- Usable security and privacy -- Security for the mobile web -- Identity management and psuedonymity -- Advertisement and affiliate fraud -- Provenance and governance -- Security and privacy as a service -- Web services/feeds/mashups -- Security and privacy policies for composible content -- Next-generation browser technology 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 chair or workshop committee. From the submissions, the program committee will strive to balance participation between academia and industry and across topics. Selected papers will appear on the workshop web site. Workshop Co-Chairs - Larry Koved (IBM Research) - Dan S. Wallach (Rice University) Program Chair - Adam Barth (UC Berkeley) Program Committee - Ben Adida (Harvard University) - Dirk Balfanz (PARC) - Adam Barth (UC Berkeley) - Konstantin (Kosta) Beznosov - Suresh Chari (IBM Research) - Hao Chen (UC Davis) - Douglas Crockford (Yahoo) - Chris Karlof (UC Berkeley) - Larry Koved (IBM Research) - Shriram Krishnamurthi (Brown University) - Collin Jackson (Stanford University) - Rob Johnson (Stony Brook University) - John C. Mitchell (Stanford University) - Sean W. Smith (Dartmouth University) - Helen Wang (Microsoft Research) - Dan S. Wallach (Rice University) Important Dates Paper submission deadline: March 6, 2009, (11:59pm US-Eastern) Workshop acceptance notification date: March 31, 2009 Workshop date: Thursday, May 21, 2009 Workshop paper submission web site: http://w2spconf.com/2009/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090302/f7e0829a/attachment.html From gem at cigital.com Tue Mar 3 04:11:42 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 3 Mar 2009 04:11:42 -0500 Subject: [SC-L] Reality Check: EMC Eric Baize Message-ID: Greetings from Leuven sc-l, Our fearless leader Ken gave a nice presentation on software security methodologies yesterday at secappdev. I wonder what he says about the Touchpoints when I'm not in the room?! The third episode of Reality Check went live this morning. The episode features a conversation with Eric Baize who runs EMC's very impressive software security initiative. EMC is an example of an initiative following their own methodology by borrowing good ideas from SDL and also the Touchpoints. Lots of good stuff about software security practicalities: http://www.cigital.com/realitycheck/show-003/ Don't forget that Reality Check is syndicated by CSO Online (it's a good way to infect upper management with software security ideas). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Tue Mar 3 04:25:52 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 3 Mar 2009 10:25:52 +0100 Subject: [SC-L] Reality Check: EMC Eric Baize In-Reply-To: References: Message-ID: On Mar 3, 2009, at 10:11 AM, Gary McGraw wrote: > Our fearless leader Ken gave a nice presentation on software > security methodologies yesterday at secappdev. I wonder what he > says about the Touchpoints when I'm not in the room?! Thanks for the kind words. What I say about the Touchpoints, Microsoft's SDL, or OWASP's CLASP remains the same whether you're in the room or not. They all offer good points and bad points. I tend to favor a hybrid approach that works well for me, which is what I always recommend to my customers. More importantly, though, I am eager to update the message with what the companies who participated in the BSIMM are actually doing in practice. 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/20090303/93cdee93/attachment.bin From gem at cigital.com Tue Mar 3 04:47:44 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 3 Mar 2009 04:47:44 -0500 Subject: [SC-L] Reality Check: EMC Eric Baize In-Reply-To: Message-ID: The BSIMM data are coming soon to a website near you. Stay tuned to sc-l for an early look. In the meantime here are the three articles that set the stage, with another under way as you read this email: A Software Security Framework: Working Towards a Realistic Maturity Model (October 15, 2008) http://www.informit.com/articles/article.aspx?p=1271382 Software Security Top 10 Surprises (December 15, 2008) http://www.informit.com/articles/article.aspx?p=1315431 Nine Things Everybody Does: Software Security Activities from the BSIMM (February 9, 2009) http://www.informit.com/articles/article.aspx?p=1326511 gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com On 3/3/09 10:25 AM, "Kenneth van Wyk" wrote: On Mar 3, 2009, at 10:11 AM, Gary McGraw wrote: > Our fearless leader Ken gave a nice presentation on software > security methodologies yesterday at secappdev. I wonder what he > says about the Touchpoints when I'm not in the room?! Thanks for the kind words. What I say about the Touchpoints, Microsoft's SDL, or OWASP's CLASP remains the same whether you're in the room or not. They all offer good points and bad points. I tend to favor a hybrid approach that works well for me, which is what I always recommend to my customers. More importantly, though, I am eager to update the message with what the companies who participated in the BSIMM are actually doing in practice. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com From brian at fortify.com Tue Mar 3 08:35:33 2009 From: brian at fortify.com (Brian Chess) Date: Tue, 03 Mar 2009 05:35:33 -0800 Subject: [SC-L] Call for papers: Programming Languages and Analysis for Security (PLAS) Message-ID: ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security (PLAS 2009) Dublin, Ireland, June 15, 2009 Sponsored by ACM SIGPLAN Co-located with PLDI '09 Supported by IBM Research and Microsoft Research http://www.cs.stevens.edu/~naumann/plas2009.html Submission Deadline: April 3, 2009 Call for Papers PLAS aims to provide a forum for exploring and evaluating ideas on the use of programming language and program analysis techniques to improve the security of software systems. Strongly encouraged are proposals of new, speculative ideas; evaluations of new or known techniques in practical settings; and discussions of emerging threats and important problems. The scope of PLAS includes, but is not limited to: * Language-based techniques for security * Verification of security properties in software * Automated introduction and/or verification of security enforcement mechanisms * Program analysis techniques for discovering security vulnerabilities * Compiler-based security mechanisms, such as host-based intrusion detection and in-line reference monitors * Specifying and enforcing security policies for information flow and access control * Model-driven approaches to security * Applications, examples, and implementations of these security techniques in domains including web applications, embedded software, etc. Important Dates and Submission Guidelines * Submission due date: Friday, April 3, 2009 * Author notification: Friday, May 1, 2009 * Revised papers due: Monday, May 18, 2009 * Student travel grant applications due: Friday, May 29, 2009 * PLAS 2009 workshop: Monday, June 15, 2009 We invite papers of two kinds: (1) Technical papers about relatively mature work, for "long" presentations during the workshop, and (2) papers for "short" presentations about more preliminary work, position statements, or work that is more exploratory in nature. Short papers marked as "Informal Presentation" will have only their abstract published in the proceedings. All other papers will be included in the formal proceedings and must describe original work in compliance with the SIGPLAN republication policy. Page limits are 12 pages for long papers and 6 pages for short papers. Student Travel Grants Student attendees of PLAS can apply for a travel grant (in addition to any PLDI grants), thanks to the generous support of IBM Research and Microsoft Research. The application forms will be on the workshop web site. Program Committee * Aslan Askarov, Chalmers University of Technology, Sweden * Brian Chess, Fortify Software, USA * Stephen Chong, Harvard University, USA (co-chair) * ?lfar Erlingsson, Reykjav?k University, Iceland * Kevin W. Hamlen, University of Texas at Dallas, USA * Benjamin Livshits, Microsoft Research, USA * Pasquale Malacaria, Queen Mary University of London, UK * David Naumann, Stevens Institute of Technology, USA (co-chair) * Marco Pistoia, IBM Research, USA * Fran?ois Pottier, INRIA Paris-Rocquencourt, France * Tamara Rezk, INRIA Sophia Antipolis-M?diterran?e, France * Tachio Terauchi, Tohoku University, Japan * David Wagner, University of California, Berkeley, USA From jim at manico.net Wed Mar 4 15:25:09 2009 From: jim at manico.net (Jim Manico) Date: Wed, 4 Mar 2009 10:25:09 -1000 Subject: [SC-L] OWASP Podcast #10 with Ken van Wyk References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <48B1E946.3060503@manico.net> <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> <48B45581.5040607@manico.net> <48B4704D.3090304@manico.net> Message-ID: <447F9A14E5704EB789AACC2874724077@workhorse> I'm very pleased to announce to SC-L that OWASP Podcast #10 - an interview with Ken van Wyk - is live!! To listen to OWASP Podcast #10, you can download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes. Thanks Gentlemen! - Jim Manico OWASP Podcast Series Host -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090304/dbc7dedb/attachment.html From jim at manico.net Wed Mar 4 19:35:08 2009 From: jim at manico.net (Jim Manico) Date: Wed, 4 Mar 2009 14:35:08 -1000 Subject: [SC-L] OWASP Podcast #11 with Steve Christey and Bob Martin References: <82C078B9-E8B6-430F-A33E-D2F77B4F8432@cigital.com> <48B1E946.3060503@manico.net> <930fd0230808260741o32dc99c0g9790f3a097ce4c26@mail.gmail.com> <48B45581.5040607@manico.net> <48B4704D.3090304@manico.net> <447F9A14E5704EB789AACC2874724077@workhorse> Message-ID: SC-L, Please forgive me for hitting you up twice today! But I am pleased to announce to SC-L that OWASP Podcast #11 - an interview with Steve Christey and Bob Martin from MITRE is also live! =) To listen to OWASP Podcast #11, you can download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes. Thanks Gentlemen! - Jim Manico OWASP Podcast Series Host -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090304/a012d43e/attachment.html From gem at cigital.com Thu Mar 5 02:37:54 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 5 Mar 2009 02:37:54 -0500 Subject: [SC-L] BSIMM lives Message-ID: hi sc-l, The Building Security In Maturity Model (BSIMM) has been released and is available for your free download and use here: http://bsi-mm.com We are eager for your feedback and your participation in evolving and applying the model. The story broke last night in the Wall Street Journal: http://blogs.wsj.com/digits/2009/03/04/new-effort-hopes-to-improve-software-security/ Please help us spread the work about this free resource which we hope will help to transform software security from alchemy to science. gem (lead alchemist) company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From chandra at list.org Fri Mar 6 19:20:04 2009 From: chandra at list.org (Pravir Chandra) Date: Sat, 7 Mar 2009 00:20:04 +0000 Subject: [SC-L] Relationship between BSIMM and SAMM Message-ID: <482511045-1236385203-cardhu_decombobulator_blackberry.rim.net-690511798-@bxe1150.bisx.prod.on.blackberry> Hey Everyone. You've probably seen the posts I've made to sc-l about the Software Assurance Maturity Model (SAMM) and I'm sure you've seen the latest from Gary with the BSIMM. Lots of folks have pinged me over the last two days about the relationship between the two (short answer: they're different), so I blogged about it here: http://www.opensamm.org/2009/03/whats-up-with-the-other-model/ Thanks! p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From gem at cigital.com Tue Mar 10 13:02:17 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 10 Mar 2009 14:02:17 -0400 Subject: [SC-L] Gartner covers software security Message-ID: hi sc-l, I have not yet finished gathering 2008 numbers for the space (almost done), but it appears that we have collectively passed the golden $500M number. What happens next is that all of the analyst firms get involved and start telling people in the mid-market what to buy. The first Gartner magic quadrant for the source code analysis space came out a few weeks ago. Fortify bought a copy that you can download for free (if you use the link below, you don't even have to register for spam): http://www.fortify.com/servlet/downloads/public/GartnerMQ_StaticApplicationSecurityTesting.pdf Even more importantly, Gartner just published a blog entry that emphasizes the fact that tools alone will not solve the software security problem. Three cheers for sanity among the analysts! Thank you Neil. You can read that here: http://blogs.gartner.com/neil_macdonald/2009/03/07/application-security-a-tool-cannot-solve-what-fundamentally-is-a-process-problem/ We were gratified that Neil mentioned the BSIMM work, which is garnering plenty of attention. Download your copy of the BSIMM today at http://bsi-mm.com gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From SMigues at cigital.com Tue Mar 10 10:48:25 2009 From: SMigues at cigital.com (Sammy Migues) Date: Tue, 10 Mar 2009 11:48:25 -0400 Subject: [SC-L] Positive impact of an SSG Message-ID: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com> Hi all, I've received some private questions about the 110 activities in BSIMM (bsi-mm.com). Since we built the model directly from the data gathered, each activity is actually being done in one of the nine organizations interviewed. The question is whether there's any evidence the activities are actually effective as opposed to simply being done. Since we can't publish any private data, I'd like to point folks at this recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one of the nine organizations interviewed), is quoted as follows relative to the impact of software security group activities: http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html "One of Routh's big wins is inserting security controls early into software development lifecycle at the DTCC. Vulnerabilities are weeded out well before they appear in functional code that ends up in production and that has resulted in close to $2 million in productivity gains on a base of $150 million spend for development, Routh says. "Those gains are exclusively the result of having mature and effective controls within our system and software development lifecycle," Routh says. This is a three-year-old initiative that educates and certifies developers in all DTCC environments in security. Developers are also provided with the necessary code-scanning tools and consulting and services help to keep production code close to pristine." --Sammy. Sammy Migues Principal, Technology 703.404.5830 - http://www.cigital.com Software confidence. Achieved. smigues at cigital.com From chandra at list.org Tue Mar 10 17:31:06 2009 From: chandra at list.org (Pravir Chandra) Date: Tue, 10 Mar 2009 14:31:06 -0800 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com> Message-ID: Hey Sammy. How does that pertain to a software security group (SSG) per se? The details below seem to indicate that it was the controls over all that lead to the positive impact. My main point is that supporting an SSG isn't cost effective for 95% of the organizations out there that are building code. That's why in SAMM, we didn't mandate the structure of the organization and instead concentrated on the functions fulfilled by security guys (regardless of their placement in the org). p. On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues wrote: > Hi all, > > I've received some private questions about the 110 activities in BSIMM (bsi-mm.com). Since we built the model directly from the data gathered, each activity is actually being done in one of the nine organizations interviewed. The question is whether there's any evidence the activities are actually effective as opposed to simply being done. > > Since we can't publish any private data, I'd like to point folks at this recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one of the nine organizations interviewed), is quoted as follows relative to the impact of software security group activities: > > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > > "One of Routh's big wins is inserting security controls early into software development lifecycle at the DTCC. Vulnerabilities are weeded out well before they appear in functional code that ends up in production and that has resulted in close to $2 million in productivity gains on a base of $150 million spend for development, Routh says. > > "Those gains are exclusively the result of having mature and effective controls within our system and software development lifecycle," Routh says. This is a three-year-old initiative that educates and certifies developers in all DTCC environments in security. Developers are also provided with the necessary code-scanning tools and consulting and services help to keep production code close to pristine." > > --Sammy. > > Sammy Migues > Principal, Technology > 703.404.5830 - http://www.cigital.com > Software confidence. Achieved. > smigues at cigital.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 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From SMigues at cigital.com Tue Mar 10 22:15:39 2009 From: SMigues at cigital.com (Sammy Migues) Date: Tue, 10 Mar 2009 23:15:39 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: References: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com> Message-ID: <41945506397C0C4886A8C5BFF089B5CA39590CD1FC@va-mailhub.cigital.com> Hi Pravir, Yes, I agree completely: the data gathered in the BSIMM interviews seem to indicate that "the controls over all" led to what the interviewees saw as improvements in their capability to produce secure software. In the nine companies interviewed, those controls (BSIMM activities, I think) sprang from well established SSGs -- that is, a specific person or persons with the responsibility for ensuring lots (110, collectively) of activities actually get done. The BSIMM data to date from specific large organizations indicate that a little under 100:1 is the average ratio for dev/QA to SSG size. It'll be interesting to see how this changes when we get to interviewing smaller organizations and we see if and how they're actually getting it done. Personally, I don't believe I agree with your guess that 95% of organizations building code can't afford an SSG. I believe every organization that wants to succeed can afford to have someone in charge of success, but that's just my opinion and isn't relevant to BSIMM. Cheers, --Sammy. -----Original Message----- From: Pravir Chandra [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hey Sammy. How does that pertain to a software security group (SSG) per se? The details below seem to indicate that it was the controls over all that lead to the positive impact. My main point is that supporting an SSG isn't cost effective for 95% of the organizations out there that are building code. That's why in SAMM, we didn't mandate the structure of the organization and instead concentrated on the functions fulfilled by security guys (regardless of their placement in the org). p. On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues wrote: > Hi all, > > I've received some private questions about the 110 activities in BSIMM (bsi-mm.com). Since we built the model directly from the data gathered, each activity is actually being done in one of the nine organizations interviewed. The question is whether there's any evidence the activities are actually effective as opposed to simply being done. > > Since we can't publish any private data, I'd like to point folks at this recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one of the nine organizations interviewed), is quoted as follows relative to the impact of software security group activities: > > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > > "One of Routh's big wins is inserting security controls early into software development lifecycle at the DTCC. Vulnerabilities are weeded out well before they appear in functional code that ends up in production and that has resulted in close to $2 million in productivity gains on a base of $150 million spend for development, Routh says. > > "Those gains are exclusively the result of having mature and effective controls within our system and software development lifecycle," Routh says. This is a three-year-old initiative that educates and certifies developers in all DTCC environments in security. Developers are also provided with the necessary code-scanning tools and consulting and services help to keep production code close to pristine." > > --Sammy. > > Sammy Migues > Principal, Technology > 703.404.5830 - http://www.cigital.com > Software confidence. Achieved. > smigues at cigital.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 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From chandra at list.org Wed Mar 11 02:59:33 2009 From: chandra at list.org (Pravir Chandra) Date: Wed, 11 Mar 2009 07:59:33 +0000 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA39590CD1FC@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com><41945506397C0C4886A8C5BFF089B5CA39590CD1FC@va-mailhub.cigital.com> Message-ID: <772228312-1236758374-cardhu_decombobulator_blackberry.rim.net-1596997341-@bxe1150.bisx.prod.on.blackberry> Yes, I don't think its exclusive to your BSIMM interviews that you found when people put controls into place, they saw improvement. That's what I (and I'm sure many other consultanting firms) have been doing for years based upon previous models (CLASP, MS SDL, etc.). Nothing to do with BSIMM per se (actually, most of what DTCC started doing was based on CLASP), just that they added controls 'early into software development lifecycle' and saw benefit, which isn't surprising. That being said, the important part we're missing as 'software security guys' isn't the specification of all the possible things that an organization *could* do, but rather what a given organization *should* do based on good business decisions around risk management. And that's the crux of what BSIMM fails to do. By basing the current maturity model on the collected practices of 9 massive firms that spend the most on that problem, anyone (aside from firms in a similar situation to your 9) that attempts to apply it to their organization effectively throws risk management decisions out the window and commits to a much more costly solution than they could have created based on the knowledge of their own business needs since all the practices are based solely on the behaviors of the select few firms you interviewed. I'm not discounting the validity of the empirical data, I'm just positting that it isn't scientifically valid for solving the problem at hand. I'm interested to hear what you learn when you get to the small and medium sized businesses as well as firms using agile development models (something I particularly considered and accounted for with SAMM). Regardless of whether we agree on the percentage of orgs for which a dedicated SSG isn't cost effective, I'm sure we can agree that affording 'someone in charge of success' doesn't equate to a dedicated SSG. There's a myriad of ways that can be accomplished in any organizational structure. Thanks! p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Sammy Migues Date: Tue, 10 Mar 2009 23:15:39 To: sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hi Pravir, Yes, I agree completely: the data gathered in the BSIMM interviews seem to indicate that "the controls over all" led to what the interviewees saw as improvements in their capability to produce secure software. In the nine companies interviewed, those controls (BSIMM activities, I think) sprang from well established SSGs -- that is, a specific person or persons with the responsibility for ensuring lots (110, collectively) of activities actually get done. The BSIMM data to date from specific large organizations indicate that a little under 100:1 is the average ratio for dev/QA to SSG size. It'll be interesting to see how this changes when we get to interviewing smaller organizations and we see if and how they're actually getting it done. Personally, I don't believe I agree with your guess that 95% of organizations building code can't afford an SSG. I believe every organization that wants to succeed can afford to have someone in charge of success, but that's just my opinion and isn't relevant to BSIMM. Cheers, --Sammy. -----Original Message----- From: Pravir Chandra [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hey Sammy. How does that pertain to a software security group (SSG) per se? The details below seem to indicate that it was the controls over all that lead to the positive impact. My main point is that supporting an SSG isn't cost effective for 95% of the organizations out there that are building code. That's why in SAMM, we didn't mandate the structure of the organization and instead concentrated on the functions fulfilled by security guys (regardless of their placement in the org). p. On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues wrote: > Hi all, > > I've received some private questions about the 110 activities in BSIMM (bsi-mm.com). Since we built the model directly from the data gathered, each activity is actually being done in one of the nine organizations interviewed. The question is whether there's any evidence the activities are actually effective as opposed to simply being done. > > Since we can't publish any private data, I'd like to point folks at this recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one of the nine organizations interviewed), is quoted as follows relative to the impact of software security group activities: > > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > > "One of Routh's big wins is inserting security controls early into software development lifecycle at the DTCC. Vulnerabilities are weeded out well before they appear in functional code that ends up in production and that has resulted in close to $2 million in productivity gains on a base of $150 million spend for development, Routh says. > > "Those gains are exclusively the result of having mature and effective controls within our system and software development lifecycle," Routh says. This is a three-year-old initiative that educates and certifies developers in all DTCC environments in security. Developers are also provided with the necessary code-scanning tools and consulting and services help to keep production code close to pristine." > > --Sammy. > > Sammy Migues > Principal, Technology > 703.404.5830 - http://www.cigital.com > Software confidence. Achieved. > smigues at cigital.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 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ 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 SMigues at cigital.com Wed Mar 11 08:28:50 2009 From: SMigues at cigital.com (Sammy Migues) Date: Wed, 11 Mar 2009 09:28:50 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <772228312-1236758374-cardhu_decombobulator_blackberry.rim.net-1596997341-@bxe1150.bisx.prod.on.blackberry> References: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com><41945506397C0C4886A8C5BFF089B5CA39590CD1FC@va-mailhub.cigital.com> <772228312-1236758374-cardhu_decombobulator_blackberry.rim.net-1596997341-@bxe1150.bisx.prod.on.blackberry> Message-ID: <41945506397C0C4886A8C5BFF089B5CA39590CD223@va-mailhub.cigital.com> Hi Pravir, Thanks for clarifying what you're positing. I'm not sure how we could have been more clear in the BSIMM text accompanying the exposition of the collective activities about the need to take this information and work it into your own culture (i.e., do "risk management"). As a few examples: p. 3: "BSIMM is meant as a guide for building and evolving a software security initiative. As you will see when you familiarize yourself with the BSIMM activities, instilling software security into an organization takes careful planning and always involves broad organizational change. By clearly noting objectives and goals and by tracking practices with metrics tailored to your own initiative, you can methodically build software security in to your organization?s software development practices." p. 47: "Choosing which of the 110 BSIMM activities to adopt and in what order can be a challenge. We suggest creating a software security initiative strategy and plan by focusing on goals and objectives first and letting the activities select themselves. Creating a timeline for rollout is often very useful. Of course learning from experience is also a good strategy." p. 47: "Of the 110 possible activities in BSIMM, there are ten activities that all of the nine programs we studied carry out. Though we can?t directly conclude that these ten activities are necessary for all software security initiatives, we can say with confidence that these activities are commonly found in highly successful programs. This suggests that if you are working on an initiative of your own, you should consider these ten activities particularly carefully (not to mention the other 100)." p. 48: "The chart below shows how many of the nine organizations we studied have adopted various activities. Though you can use this as a rough ?weighting? of activities by prevalence, a software security initiative plan is best approached through goals and objectives." Your words (...BSIMM fails...) imply (to me) that you posit organizations attempting to use the collected wisdom in BSIMM will, inexplicably, look at it and say "Okay, we have to do all 110 of these things exactly as written, so let's get started" without regard to their local need. This is as opposed to, say, looking at it and thinking "Here's what nine companies have spent dozens of person-decades and millions of dollars learning about what works; let's see what we can glean from that." Uhmmmm, okay. Yes, previous models exist. Although it may have come up in conversation, we did not ask any of the nine something like "What model did you start with back in the beginning?" because it simply isn't relevant to what we're trying to accomplish (documenting what successful organizations are doing), just as "could" and "should" aren't relevant. We asked "What *are* you doing now?" and documented it so others could learn from it. --Sammy. -----Original Message----- From: Pravir Chandra [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Yes, I don't think its exclusive to your BSIMM interviews that you found when people put controls into place, they saw improvement. That's what I (and I'm sure many other consultanting firms) have been doing for years based upon previous models (CLASP, MS SDL, etc.). Nothing to do with BSIMM per se (actually, most of what DTCC started doing was based on CLASP), just that they added controls 'early into software development lifecycle' and saw benefit, which isn't surprising. That being said, the important part we're missing as 'software security guys' isn't the specification of all the possible things that an organization *could* do, but rather what a given organization *should* do based on good business decisions around risk management. And that's the crux of what BSIMM fails to do. By basing the current maturity model on the collected practices of 9 massive firms that spend the most on that problem, anyone (aside from firms in a similar situation to your 9) that attempts to apply it to their organization effectively throws risk management decisions out the window and commits to a much more costly solution than they could have created based on the knowledge of their own business needs since all the practices are based solely on the behaviors of the select few firms you interviewed. I'm not discounting the validity of the empirical data, I'm just positting that it isn't scientifically valid for solving the problem at hand. I'm interested to hear what you learn when you get to the small and medium sized businesses as well as firms using agile development models (something I particularly considered and accounted for with SAMM). Regardless of whether we agree on the percentage of orgs for which a dedicated SSG isn't cost effective, I'm sure we can agree that affording 'someone in charge of success' doesn't equate to a dedicated SSG. There's a myriad of ways that can be accomplished in any organizational structure. Thanks! p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Sammy Migues Date: Tue, 10 Mar 2009 23:15:39 To: sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hi Pravir, Yes, I agree completely: the data gathered in the BSIMM interviews seem to indicate that "the controls over all" led to what the interviewees saw as improvements in their capability to produce secure software. In the nine companies interviewed, those controls (BSIMM activities, I think) sprang from well established SSGs -- that is, a specific person or persons with the responsibility for ensuring lots (110, collectively) of activities actually get done. The BSIMM data to date from specific large organizations indicate that a little under 100:1 is the average ratio for dev/QA to SSG size. It'll be interesting to see how this changes when we get to interviewing smaller organizations and we see if and how they're actually getting it done. Personally, I don't believe I agree with your guess that 95% of organizations building code can't afford an SSG. I believe every organization that wants to succeed can afford to have someone in charge of success, but that's just my opinion and isn't relevant to BSIMM. Cheers, --Sammy. -----Original Message----- From: Pravir Chandra [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG Hey Sammy. How does that pertain to a software security group (SSG) per se? The details below seem to indicate that it was the controls over all that lead to the positive impact. My main point is that supporting an SSG isn't cost effective for 95% of the organizations out there that are building code. That's why in SAMM, we didn't mandate the structure of the organization and instead concentrated on the functions fulfilled by security guys (regardless of their placement in the org). p. On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues wrote: > Hi all, > > I've received some private questions about the 110 activities in BSIMM (bsi-mm.com). Since we built the model directly from the data gathered, each activity is actually being done in one of the nine organizations interviewed. The question is whether there's any evidence the activities are actually effective as opposed to simply being done. > > Since we can't publish any private data, I'd like to point folks at this recent article in Information Security Magazine. Jim Routh, CISO of DTCC (one of the nine organizations interviewed), is quoted as follows relative to the impact of software security group activities: > > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > > "One of Routh's big wins is inserting security controls early into software development lifecycle at the DTCC. Vulnerabilities are weeded out well before they appear in functional code that ends up in production and that has resulted in close to $2 million in productivity gains on a base of $150 million spend for development, Routh says. > > "Those gains are exclusively the result of having mature and effective controls within our system and software development lifecycle," Routh says. This is a three-year-old initiative that educates and certifies developers in all DTCC environments in security. Developers are also provided with the necessary code-scanning tools and consulting and services help to keep production code close to pristine." > > --Sammy. > > Sammy Migues > Principal, Technology > 703.404.5830 - http://www.cigital.com > Software confidence. Achieved. > smigues at cigital.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 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ 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 11 09:48:13 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 11 Mar 2009 10:48:13 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA39590CD223@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com><41945506397C0C4886A8C5BFF089B5CA39590CD1FC@va-mailhub.cigital.com> <772228312-1236758374-cardhu_decombobulator_blackberry.rim.net-1596997341-@bxe1150.bisx.prod.on.blackberry> <41945506397C0C4886A8C5BFF089B5CA39590CD223@va-mailhub.cigital.com> Message-ID: <49B7CF2D.7010709@secureconsulting.net> I think it's an interesting leap of faith. Statistically speaking, 9 is a very small sample size. Thus, the proposed model will be viewed skeptically until it is validated with a much larger and more diverse sample. Putting it another way, there's no way I can take this to a small or medium sized org and have them see immediate relevance, because their first reaction is going to be "those are 9 large orgs with lots of resources - we don't have that luxury." You quoted "we can say with confidence that these activities are commonly found in highly successful programs" - how do you define a "highly successful program"? What's the rule or metric? Is this a rule or metric that can be genericized easily to all development teams? My concern is exactly what you speculate about... organizations are going to look at this and either try to tackle everything (and fail) or decide there's too much to tackle (and quit). In my experience working with maturity models as a consultant, very few people actually understand the concept. Folks are far more tuned-in to a PCI-like prescriptive method. Ironically, the PCI folks say the same thing you did - that it's not meant to be prescriptive, that it's supposed to be based on risk management practices - yet look how it's used. Maybe you've addressed this, but it doesn't sound like it. I'd perhaps be better educated here if the web site wasn't down... ;) -ben Sammy Migues wrote: > Hi Pravir, > > Thanks for clarifying what you're positing. I'm not sure how we could > have been more clear in the BSIMM text accompanying the exposition of > the collective activities about the need to take this information and > work it into your own culture (i.e., do "risk management"). As a few > examples: > > p. 3: "BSIMM is meant as a guide for building and evolving a software > security initiative. As you will see when you familiarize yourself > with the BSIMM activities, instilling software security into an > organization takes careful planning and always involves broad > organizational change. By clearly noting objectives and goals and by > tracking practices with metrics tailored to your own initiative, you > can methodically build software security in to your organization?s > software development practices." > > p. 47: "Choosing which of the 110 BSIMM activities to adopt and in > what order can be a challenge. We suggest creating a software > security initiative strategy and plan by focusing on goals and > objectives first and letting the activities select themselves. > Creating a timeline for rollout is often very useful. Of course > learning from experience is also a good strategy." > > p. 47: "Of the 110 possible activities in BSIMM, there are ten > activities that all of the nine programs we studied carry out. Though > we can?t directly conclude that these ten activities are necessary > for all software security initiatives, we can say with confidence > that these activities are commonly found in highly successful > programs. This suggests that if you are working on an initiative of > your own, you should consider these ten activities particularly > carefully (not to mention the other 100)." > > p. 48: "The chart below shows how many of the nine organizations we > studied have adopted various activities. Though you can use this as a > rough ?weighting? of activities by prevalence, a software security > initiative plan is best approached through goals and objectives." > > Your words (...BSIMM fails...) imply (to me) that you posit > organizations attempting to use the collected wisdom in BSIMM will, > inexplicably, look at it and say "Okay, we have to do all 110 of > these things exactly as written, so let's get started" without regard > to their local need. This is as opposed to, say, looking at it and > thinking "Here's what nine companies have spent dozens of > person-decades and millions of dollars learning about what works; > let's see what we can glean from that." Uhmmmm, okay. > > Yes, previous models exist. Although it may have come up in > conversation, we did not ask any of the nine something like "What > model did you start with back in the beginning?" because it simply > isn't relevant to what we're trying to accomplish (documenting what > successful organizations are doing), just as "could" and "should" > aren't relevant. We asked "What *are* you doing now?" and documented > it so others could learn from it. > > --Sammy. > > -----Original Message----- From: Pravir Chandra > [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: > Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org > Subject: Re: [SC-L] Positive impact of an SSG > > Yes, I don't think its exclusive to your BSIMM interviews that you > found when people put controls into place, they saw improvement. > That's what I (and I'm sure many other consultanting firms) have been > doing for years based upon previous models (CLASP, MS SDL, etc.). > Nothing to do with BSIMM per se (actually, most of what DTCC started > doing was based on CLASP), just that they added controls 'early into > software development lifecycle' and saw benefit, which isn't > surprising. > > That being said, the important part we're missing as 'software > security guys' isn't the specification of all the possible things > that an organization *could* do, but rather what a given organization > *should* do based on good business decisions around risk management. > And that's the crux of what BSIMM fails to do. By basing the current > maturity model on the collected practices of 9 massive firms that > spend the most on that problem, anyone (aside from firms in a similar > situation to your 9) that attempts to apply it to their organization > effectively throws risk management decisions out the window and > commits to a much more costly solution than they could have created > based on the knowledge of their own business needs since all the > practices are based solely on the behaviors of the select few firms > you interviewed. I'm not discounting the validity of the empirical > data, I'm just positting that it isn't scientifically valid for > solving the problem at hand. > > I'm interested to hear what you learn when you get to the small and > medium sized businesses as well as firms using agile development > models (something I particularly considered and accounted for with > SAMM). > > Regardless of whether we agree on the percentage of orgs for which a > dedicated SSG isn't cost effective, I'm sure we can agree that > affording 'someone in charge of success' doesn't equate to a > dedicated SSG. There's a myriad of ways that can be accomplished in > any organizational structure. > > Thanks! > > p. > > ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir > Chandra chandralistorg PGP: CE60 > 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ > ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ > > -----Original Message----- From: Sammy Migues > > Date: Tue, 10 Mar 2009 23:15:39 To: > sc-l at securecoding.org Subject: Re: [SC-L] > Positive impact of an SSG > > > Hi Pravir, > > Yes, I agree completely: the data gathered in the BSIMM interviews > seem to indicate that "the controls over all" led to what the > interviewees saw as improvements in their capability to produce > secure software. > > In the nine companies interviewed, those controls (BSIMM activities, > I think) sprang from well established SSGs -- that is, a specific > person or persons with the responsibility for ensuring lots (110, > collectively) of activities actually get done. > > The BSIMM data to date from specific large organizations indicate > that a little under 100:1 is the average ratio for dev/QA to SSG > size. It'll be interesting to see how this changes when we get to > interviewing smaller organizations and we see if and how they're > actually getting it done. > > Personally, I don't believe I agree with your guess that 95% of > organizations building code can't afford an SSG. I believe every > organization that wants to succeed can afford to have someone in > charge of success, but that's just my opinion and isn't relevant to > BSIMM. > > Cheers, > > --Sammy. > > > -----Original Message----- From: Pravir Chandra > [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: > Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive > impact of an SSG > > Hey Sammy. > > How does that pertain to a software security group (SSG) per se? The > details below seem to indicate that it was the controls over all that > lead to the positive impact. > > My main point is that supporting an SSG isn't cost effective for 95% > of the organizations out there that are building code. That's why in > SAMM, we didn't mandate the structure of the organization and instead > concentrated on the functions fulfilled by security guys (regardless > of their placement in the org). > > p. > > On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues > wrote: >> Hi all, >> >> I've received some private questions about the 110 activities in >> BSIMM (bsi-mm.com). Since we built the model directly from the data >> gathered, each activity is actually being done in one of the nine >> organizations interviewed. The question is whether there's any >> evidence the activities are actually effective as opposed to simply >> being done. >> >> Since we can't publish any private data, I'd like to point folks at >> this recent article in Information Security Magazine. Jim Routh, >> CISO of DTCC (one of the nine organizations interviewed), is quoted >> as follows relative to the impact of software security group >> activities: >> >> http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html >> >> >> "One of Routh's big wins is inserting security controls early into >> software development lifecycle at the DTCC. Vulnerabilities are >> weeded out well before they appear in functional code that ends up >> in production and that has resulted in close to $2 million in >> productivity gains on a base of $150 million spend for development, >> Routh says. >> >> "Those gains are exclusively the result of having mature and >> effective controls within our system and software development >> lifecycle," Routh says. This is a three-year-old initiative that >> educates and certifies developers in all DTCC environments in >> security. Developers are also provided with the necessary >> code-scanning tools and consulting and services help to keep >> production code close to pristine." >> >> --Sammy. >> >> Sammy Migues Principal, Technology 703.404.5830 - >> http://www.cigital.com Software confidence. Achieved. >> smigues at cigital.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. >> _______________________________________________ >> > > > -- 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: ] "Don't you wish there were a knob on the TV to turn up the intelligence? There's one marked 'Brightness,' but it doesn't work." Gallagher From brian at fortify.com Wed Mar 11 10:48:31 2009 From: brian at fortify.com (Brian Chess) Date: Wed, 11 Mar 2009 11:48:31 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <49B7CF2D.7010709@secureconsulting.net> Message-ID: Ben! Thank you! When you talk about sample size, it gives me hope that we?re on the right track. We can either: 1) Use ideas that ?experts? theorize will work or 2) Gather empirical evidence to judge one idea against another. We in the security crowd often try to hide behind the need for secrecy, and that?s pushed us toward relying almost entirely on people who have nothing but rhetoric and personal reputation to stand on. BSIMM pretty well shows that, in 2009, we can do better. It?s a big step forward to collect data and then argue about what it means. I know it?s already made the rounds, but let?s have some XKCD to celebrate: http://xkcd.com/552/ I think your question about defining success is an important one. We were loose about it in this first round, and I hope it?s something we can tighten up in our follow-on work. Here?s my thinking as of today: software security is not the goal, it?s one of the many things an organization needs to do in order to meet it?s objectives. We need to look at how a software security initiative (or lack thereof) effects the organization?s ability to meet it?s objectives. This is going to be messy, but it?s either that or go back to making stuff up. BTW, I checked the BSIMM web site after I read your message. It worked for me. Try this? http://www.downforeveryoneorjustme.com/bsi-mm.com Brian On 3/11/09 10:48 AM, "Benjamin Tomhave" wrote: > I think it's an interesting leap of faith. Statistically speaking, 9 is > a very small sample size. Thus, the proposed model will be viewed > skeptically until it is validated with a much larger and more diverse > sample. Putting it another way, there's no way I can take this to a > small or medium sized org and have them see immediate relevance, because > their first reaction is going to be "those are 9 large orgs with lots of > resources - we don't have that luxury." > > You quoted "we can say with confidence that these activities are > commonly found in highly successful programs" - how do you define a > "highly successful program"? What's the rule or metric? Is this a rule > or metric that can be genericized easily to all development teams? > > My concern is exactly what you speculate about... organizations are > going to look at this and either try to tackle everything (and fail) or > decide there's too much to tackle (and quit). In my experience working > with maturity models as a consultant, very few people actually > understand the concept. Folks are far more tuned-in to a PCI-like > prescriptive method. Ironically, the PCI folks say the same thing you > did - that it's not meant to be prescriptive, that it's supposed to be > based on risk management practices - yet look how it's used. > > Maybe you've addressed this, but it doesn't sound like it. I'd perhaps > be better educated here if the web site wasn't down... ;) > > -ben > > Sammy Migues wrote: >> > Hi Pravir, >> > >> > Thanks for clarifying what you're positing. I'm not sure how we could >> > have been more clear in the BSIMM text accompanying the exposition of >> > the collective activities about the need to take this information and >> > work it into your own culture (i.e., do "risk management"). As a few >> > examples: >> > >> > p. 3: "BSIMM is meant as a guide for building and evolving a software >> > security initiative. As you will see when you familiarize yourself >> > with the BSIMM activities, instilling software security into an >> > organization takes careful planning and always involves broad >> > organizational change. By clearly noting objectives and goals and by >> > tracking practices with metrics tailored to your own initiative, you >> > can methodically build software security in to your organization?s >> > software development practices." >> > >> > p. 47: "Choosing which of the 110 BSIMM activities to adopt and in >> > what order can be a challenge. We suggest creating a software >> > security initiative strategy and plan by focusing on goals and >> > objectives first and letting the activities select themselves. >> > Creating a timeline for rollout is often very useful. Of course >> > learning from experience is also a good strategy." >> > >> > p. 47: "Of the 110 possible activities in BSIMM, there are ten >> > activities that all of the nine programs we studied carry out. Though >> > we can?t directly conclude that these ten activities are necessary >> > for all software security initiatives, we can say with confidence >> > that these activities are commonly found in highly successful >> > programs. This suggests that if you are working on an initiative of >> > your own, you should consider these ten activities particularly >> > carefully (not to mention the other 100)." >> > >> > p. 48: "The chart below shows how many of the nine organizations we >> > studied have adopted various activities. Though you can use this as a >> > rough ?weighting? of activities by prevalence, a software security >> > initiative plan is best approached through goals and objectives." >> > >> > Your words (...BSIMM fails...) imply (to me) that you posit >> > organizations attempting to use the collected wisdom in BSIMM will, >> > inexplicably, look at it and say "Okay, we have to do all 110 of >> > these things exactly as written, so let's get started" without regard >> > to their local need. This is as opposed to, say, looking at it and >> > thinking "Here's what nine companies have spent dozens of >> > person-decades and millions of dollars learning about what works; >> > let's see what we can glean from that." Uhmmmm, okay. >> > >> > Yes, previous models exist. Although it may have come up in >> > conversation, we did not ask any of the nine something like "What >> > model did you start with back in the beginning?" because it simply >> > isn't relevant to what we're trying to accomplish (documenting what >> > successful organizations are doing), just as "could" and "should" >> > aren't relevant. We asked "What *are* you doing now?" and documented >> > it so others could learn from it. >> > >> > --Sammy. >> > >> > -----Original Message----- From: Pravir Chandra >> > [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: >> > Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org >> > Subject: Re: [SC-L] Positive impact of an SSG >> > >> > Yes, I don't think its exclusive to your BSIMM interviews that you >> > found when people put controls into place, they saw improvement. >> > That's what I (and I'm sure many other consultanting firms) have been >> > doing for years based upon previous models (CLASP, MS SDL, etc.). >> > Nothing to do with BSIMM per se (actually, most of what DTCC started >> > doing was based on CLASP), just that they added controls 'early into >> > software development lifecycle' and saw benefit, which isn't >> > surprising. >> > >> > That being said, the important part we're missing as 'software >> > security guys' isn't the specification of all the possible things >> > that an organization *could* do, but rather what a given organization >> > *should* do based on good business decisions around risk management. >> > And that's the crux of what BSIMM fails to do. By basing the current >> > maturity model on the collected practices of 9 massive firms that >> > spend the most on that problem, anyone (aside from firms in a similar >> > situation to your 9) that attempts to apply it to their organization >> > effectively throws risk management decisions out the window and >> > commits to a much more costly solution than they could have created >> > based on the knowledge of their own business needs since all the >> > practices are based solely on the behaviors of the select few firms >> > you interviewed. I'm not discounting the validity of the empirical >> > data, I'm just positting that it isn't scientifically valid for >> > solving the problem at hand. >> > >> > I'm interested to hear what you learn when you get to the small and >> > medium sized businesses as well as firms using agile development >> > models (something I particularly considered and accounted for with >> > SAMM). >> > >> > Regardless of whether we agree on the percentage of orgs for which a >> > dedicated SSG isn't cost effective, I'm sure we can agree that >> > affording 'someone in charge of success' doesn't equate to a >> > dedicated SSG. There's a myriad of ways that can be accomplished in >> > any organizational structure. >> > >> > Thanks! >> > >> > p. >> > >> > ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir >> > Chandra chandralistorg PGP: CE60 >> > 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ >> > ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ >> > >> > -----Original Message----- From: Sammy Migues >> > >> > Date: Tue, 10 Mar 2009 23:15:39 To: >> > sc-l at securecoding.org Subject: Re: [SC-L] >> > Positive impact of an SSG >> > >> > >> > Hi Pravir, >> > >> > Yes, I agree completely: the data gathered in the BSIMM interviews >> > seem to indicate that "the controls over all" led to what the >> > interviewees saw as improvements in their capability to produce >> > secure software. >> > >> > In the nine companies interviewed, those controls (BSIMM activities, >> > I think) sprang from well established SSGs -- that is, a specific >> > person or persons with the responsibility for ensuring lots (110, >> > collectively) of activities actually get done. >> > >> > The BSIMM data to date from specific large organizations indicate >> > that a little under 100:1 is the average ratio for dev/QA to SSG >> > size. It'll be interesting to see how this changes when we get to >> > interviewing smaller organizations and we see if and how they're >> > actually getting it done. >> > >> > Personally, I don't believe I agree with your guess that 95% of >> > organizations building code can't afford an SSG. I believe every >> > organization that wants to succeed can afford to have someone in >> > charge of success, but that's just my opinion and isn't relevant to >> > BSIMM. >> > >> > Cheers, >> > >> > --Sammy. >> > >> > >> > -----Original Message----- From: Pravir Chandra >> > [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: >> > Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive >> > impact of an SSG >> > >> > Hey Sammy. >> > >> > How does that pertain to a software security group (SSG) per se? The >> > details below seem to indicate that it was the controls over all that >> > lead to the positive impact. >> > >> > My main point is that supporting an SSG isn't cost effective for 95% >> > of the organizations out there that are building code. That's why in >> > SAMM, we didn't mandate the structure of the organization and instead >> > concentrated on the functions fulfilled by security guys (regardless >> > of their placement in the org). >> > >> > p. >> > >> > On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues >> > wrote: >>> >> Hi all, >>> >> >>> >> I've received some private questions about the 110 activities in >>> >> BSIMM (bsi-mm.com). Since we built the model directly from the data >>> >> gathered, each activity is actually being done in one of the nine >>> >> organizations interviewed. The question is whether there's any >>> >> evidence the activities are actually effective as opposed to simply >>> >> being done. >>> >> >>> >> Since we can't publish any private data, I'd like to point folks at >>> >> this recent article in Information Security Magazine. Jim Routh, >>> >> CISO of DTCC (one of the nine organizations interviewed), is quoted >>> >> as follows relative to the impact of software security group >>> >> activities: >>> >> >>> >> >>> http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci13469 >>> 74,00.html >>> >> >>> >> >>> >> "One of Routh's big wins is inserting security controls early into >>> >> software development lifecycle at the DTCC. Vulnerabilities are >>> >> weeded out well before they appear in functional code that ends up >>> >> in production and that has resulted in close to $2 million in >>> >> productivity gains on a base of $150 million spend for development, >>> >> Routh says. >>> >> >>> >> "Those gains are exclusively the result of having mature and >>> >> effective controls within our system and software development >>> >> lifecycle," Routh says. This is a three-year-old initiative that >>> >> educates and certifies developers in all DTCC environments in >>> >> security. Developers are also provided with the necessary >>> >> code-scanning tools and consulting and services help to keep >>> >> production code close to pristine." >>> >> >>> >> --Sammy. >>> >> >>> >> Sammy Migues Principal, Technology 703.404.5830 - >>> >> http://www.cigital.com Software confidence. Achieved. >>> >> smigues at cigital.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. >>> >> _______________________________________________ >>> >> >> > >> > >> > > > -- > 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: ] > "Don't you wish there were a knob on the TV to turn up the intelligence? > There's one marked 'Brightness,' but it doesn't work." > Gallagher > _______________________________________________ > 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/20090311/8924dcb9/attachment-0001.html From chandra at list.org Wed Mar 11 11:08:11 2009 From: chandra at list.org (Pravir Chandra) Date: Wed, 11 Mar 2009 16:08:11 +0000 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <49B7CF2D.7010709@secureconsulting.net> References: <41945506397C0C4886A8C5BFF089B5CA39590CD0CA@va-mailhub.cigital.com><41945506397C0C4886A8C5BFF089B5CA39590CD1FC@va-mailhub.cigital.com> <772228312-1236758374-cardhu_decombobulator_blackberry.rim.net-1596997341-@bxe1150.bisx.prod.on.blackberry><41945506397C0C4886A8C5BFF089B5CA39590CD223@va-mailhub.cigital.com><49B7CF2D.7010709@secureconsulting.net> Message-ID: <1249138897-1236787703-cardhu_decombobulator_blackberry.rim.net-1036362411-@bxe1150.bisx.prod.on.blackberry> Ben: I agree with the points you make. I think you captured my point nicely. Sammy: I didn't intend to imply that I thought organizations would lose their minds and "inexplicably" try to do everything. I think you misunderstood my point which is: A useful maturity model must be prescriptive and BSIMM isn't since, as you quote, it doesn't answer the hard questions of what companies *should* be doing. So, I think its a useful study/catalog of what a sampling of big companies do for software security, but organizations at large won't be able to pick it up and run with it without serious outside help. p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Benjamin Tomhave Date: Wed, 11 Mar 2009 10:48:13 To: sc-l at securecoding.org Subject: Re: [SC-L] Positive impact of an SSG I think it's an interesting leap of faith. Statistically speaking, 9 is a very small sample size. Thus, the proposed model will be viewed skeptically until it is validated with a much larger and more diverse sample. Putting it another way, there's no way I can take this to a small or medium sized org and have them see immediate relevance, because their first reaction is going to be "those are 9 large orgs with lots of resources - we don't have that luxury." You quoted "we can say with confidence that these activities are commonly found in highly successful programs" - how do you define a "highly successful program"? What's the rule or metric? Is this a rule or metric that can be genericized easily to all development teams? My concern is exactly what you speculate about... organizations are going to look at this and either try to tackle everything (and fail) or decide there's too much to tackle (and quit). In my experience working with maturity models as a consultant, very few people actually understand the concept. Folks are far more tuned-in to a PCI-like prescriptive method. Ironically, the PCI folks say the same thing you did - that it's not meant to be prescriptive, that it's supposed to be based on risk management practices - yet look how it's used. Maybe you've addressed this, but it doesn't sound like it. I'd perhaps be better educated here if the web site wasn't down... ;) -ben Sammy Migues wrote: > Hi Pravir, > > Thanks for clarifying what you're positing. I'm not sure how we could > have been more clear in the BSIMM text accompanying the exposition of > the collective activities about the need to take this information and > work it into your own culture (i.e., do "risk management"). As a few > examples: > > p. 3: "BSIMM is meant as a guide for building and evolving a software > security initiative. As you will see when you familiarize yourself > with the BSIMM activities, instilling software security into an > organization takes careful planning and always involves broad > organizational change. By clearly noting objectives and goals and by > tracking practices with metrics tailored to your own initiative, you > can methodically build software security in to your organization?s > software development practices." > > p. 47: "Choosing which of the 110 BSIMM activities to adopt and in > what order can be a challenge. We suggest creating a software > security initiative strategy and plan by focusing on goals and > objectives first and letting the activities select themselves. > Creating a timeline for rollout is often very useful. Of course > learning from experience is also a good strategy." > > p. 47: "Of the 110 possible activities in BSIMM, there are ten > activities that all of the nine programs we studied carry out. Though > we can?t directly conclude that these ten activities are necessary > for all software security initiatives, we can say with confidence > that these activities are commonly found in highly successful > programs. This suggests that if you are working on an initiative of > your own, you should consider these ten activities particularly > carefully (not to mention the other 100)." > > p. 48: "The chart below shows how many of the nine organizations we > studied have adopted various activities. Though you can use this as a > rough ?weighting? of activities by prevalence, a software security > initiative plan is best approached through goals and objectives." > > Your words (...BSIMM fails...) imply (to me) that you posit > organizations attempting to use the collected wisdom in BSIMM will, > inexplicably, look at it and say "Okay, we have to do all 110 of > these things exactly as written, so let's get started" without regard > to their local need. This is as opposed to, say, looking at it and > thinking "Here's what nine companies have spent dozens of > person-decades and millions of dollars learning about what works; > let's see what we can glean from that." Uhmmmm, okay. > > Yes, previous models exist. Although it may have come up in > conversation, we did not ask any of the nine something like "What > model did you start with back in the beginning?" because it simply > isn't relevant to what we're trying to accomplish (documenting what > successful organizations are doing), just as "could" and "should" > aren't relevant. We asked "What *are* you doing now?" and documented > it so others could learn from it. > > --Sammy. > > -----Original Message----- From: Pravir Chandra > [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: > Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org > Subject: Re: [SC-L] Positive impact of an SSG > > Yes, I don't think its exclusive to your BSIMM interviews that you > found when people put controls into place, they saw improvement. > That's what I (and I'm sure many other consultanting firms) have been > doing for years based upon previous models (CLASP, MS SDL, etc.). > Nothing to do with BSIMM per se (actually, most of what DTCC started > doing was based on CLASP), just that they added controls 'early into > software development lifecycle' and saw benefit, which isn't > surprising. > > That being said, the important part we're missing as 'software > security guys' isn't the specification of all the possible things > that an organization *could* do, but rather what a given organization > *should* do based on good business decisions around risk management. > And that's the crux of what BSIMM fails to do. By basing the current > maturity model on the collected practices of 9 massive firms that > spend the most on that problem, anyone (aside from firms in a similar > situation to your 9) that attempts to apply it to their organization > effectively throws risk management decisions out the window and > commits to a much more costly solution than they could have created > based on the knowledge of their own business needs since all the > practices are based solely on the behaviors of the select few firms > you interviewed. I'm not discounting the validity of the empirical > data, I'm just positting that it isn't scientifically valid for > solving the problem at hand. > > I'm interested to hear what you learn when you get to the small and > medium sized businesses as well as firms using agile development > models (something I particularly considered and accounted for with > SAMM). > > Regardless of whether we agree on the percentage of orgs for which a > dedicated SSG isn't cost effective, I'm sure we can agree that > affording 'someone in charge of success' doesn't equate to a > dedicated SSG. There's a myriad of ways that can be accomplished in > any organizational structure. > > Thanks! > > p. > > ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir > Chandra chandralistorg PGP: CE60 > 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ > ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ > > -----Original Message----- From: Sammy Migues > > Date: Tue, 10 Mar 2009 23:15:39 To: > sc-l at securecoding.org Subject: Re: [SC-L] > Positive impact of an SSG > > > Hi Pravir, > > Yes, I agree completely: the data gathered in the BSIMM interviews > seem to indicate that "the controls over all" led to what the > interviewees saw as improvements in their capability to produce > secure software. > > In the nine companies interviewed, those controls (BSIMM activities, > I think) sprang from well established SSGs -- that is, a specific > person or persons with the responsibility for ensuring lots (110, > collectively) of activities actually get done. > > The BSIMM data to date from specific large organizations indicate > that a little under 100:1 is the average ratio for dev/QA to SSG > size. It'll be interesting to see how this changes when we get to > interviewing smaller organizations and we see if and how they're > actually getting it done. > > Personally, I don't believe I agree with your guess that 95% of > organizations building code can't afford an SSG. I believe every > organization that wants to succeed can afford to have someone in > charge of success, but that's just my opinion and isn't relevant to > BSIMM. > > Cheers, > > --Sammy. > > > -----Original Message----- From: Pravir Chandra > [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: > Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive > impact of an SSG > > Hey Sammy. > > How does that pertain to a software security group (SSG) per se? The > details below seem to indicate that it was the controls over all that > lead to the positive impact. > > My main point is that supporting an SSG isn't cost effective for 95% > of the organizations out there that are building code. That's why in > SAMM, we didn't mandate the structure of the organization and instead > concentrated on the functions fulfilled by security guys (regardless > of their placement in the org). > > p. > > On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues > wrote: >> Hi all, >> >> I've received some private questions about the 110 activities in >> BSIMM (bsi-mm.com). Since we built the model directly from the data >> gathered, each activity is actually being done in one of the nine >> organizations interviewed. The question is whether there's any >> evidence the activities are actually effective as opposed to simply >> being done. >> >> Since we can't publish any private data, I'd like to point folks at >> this recent article in Information Security Magazine. Jim Routh, >> CISO of DTCC (one of the nine organizations interviewed), is quoted >> as follows relative to the impact of software security group >> activities: >> >> http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html >> >> >> "One of Routh's big wins is inserting security controls early into >> software development lifecycle at the DTCC. Vulnerabilities are >> weeded out well before they appear in functional code that ends up >> in production and that has resulted in close to $2 million in >> productivity gains on a base of $150 million spend for development, >> Routh says. >> >> "Those gains are exclusively the result of having mature and >> effective controls within our system and software development >> lifecycle," Routh says. This is a three-year-old initiative that >> educates and certifies developers in all DTCC environments in >> security. Developers are also provided with the necessary >> code-scanning tools and consulting and services help to keep >> production code close to pristine." >> >> --Sammy. >> >> Sammy Migues Principal, Technology 703.404.5830 - >> http://www.cigital.com Software confidence. Achieved. >> smigues at cigital.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. >> _______________________________________________ >> > > > -- 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: ] "Don't you wish there were a knob on the TV to turn up the intelligence? There's one marked 'Brightness,' but it doesn't work." Gallagher _______________________________________________ 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 chandra at list.org Wed Mar 11 11:48:20 2009 From: chandra at list.org (Pravir Chandra) Date: Wed, 11 Mar 2009 08:48:20 -0800 Subject: [SC-L] Positive impact of an SSG In-Reply-To: References: <49B7CF2D.7010709@secureconsulting.net> Message-ID: Hey Brian. The method you describe below is only scientifically valid if you're dealing with a system in a steady state. Think back to 10 years ago. If the same approach you describe below was used then, would have declared a false victory ages ago and moved on to scratching our heads as to why this wonderfully empirical model hadn't captured all the methods we needed to solve the problem. Don't forget the whole reason why the 9 organizations you spoke with were doing *any* of those things was because experts used real experience with making improvements to specify what others should do. That's pretty much the way any system improves, I think. Perhaps I'm being overly critical, but your words seem to indicate contempt for what experts have actually done to improve this space when you use phrases like "people who have nothing but rhetoric and personal reputation" who "theorize" and "make stuff up". Sure, there are people in the space that fit that description at face value, but I suspect the majority that make real impacts actually use knowledge, real-life experience, and critical thinking to improve a system where no prior solutions are growing on the trees. As Einstein says, "We cannot solve our problems with the same thinking we used when we created them." All that being said, I think more data collection is useful in determining the state of the practice today. This is useful for us to set expectations and build a better plan for formulating future recommendations. But first, we just really need to (as Ben suggests) normalize the way in which the data is collected/measured and the sampling method, and all those other good things that experiments require. Thanks. p. On Wed, Mar 11, 2009 at 7:48 AM, Brian Chess wrote: > Ben! ?Thank you! ?When you talk about sample size, it gives me hope that > we?re on the right track. ?We can either: > > 1) Use ideas that ?experts? theorize will work > or > 2) Gather empirical evidence to judge one idea against another. > > We in the security crowd often try to hide behind the need for secrecy, and > that?s pushed us toward relying almost entirely on people who have nothing > but rhetoric and personal reputation to stand on. ?BSIMM pretty well shows > that, in 2009, we can do better. ?It?s a big step forward to collect data > and then argue about what it means. ?I know it?s already made the rounds, > but let?s have some XKCD to celebrate: > ????http://xkcd.com/552/ > > I think your question about defining success is an important one. ?We were > loose about it in this first round, and I hope it?s something we can tighten > up in our follow-on work. ?Here?s my thinking as of today: software security > is not the goal, it?s one of the many things an organization needs to do in > order to meet it?s objectives. ?We need to look at how a software security > initiative (or lack thereof) effects the organization?s ability to meet it?s > objectives. ?This is going to be messy, but it?s either that or go back to > making stuff up. > > BTW, I checked the BSIMM web site after I read your message. ?It worked for > me. ?Try this? > ????http://www.downforeveryoneorjustme.com/bsi-mm.com > > Brian > > On 3/11/09 10:48 AM, "Benjamin Tomhave" > wrote: > > I think it's an interesting leap of faith. Statistically speaking, 9 is > a very small sample size. Thus, the proposed model will be viewed > skeptically until it is validated with a much larger and more diverse > sample. Putting it another way, there's no way I can take this to a > small or medium sized org and have them see immediate relevance, because > their first reaction is going to be "those are 9 large orgs with lots of > resources - we don't have that luxury." > > You quoted "we can say with confidence that these activities are > commonly found in highly successful programs" - how do you define a > "highly successful program"? What's the rule or metric? Is this a rule > or metric that can be genericized easily to all development teams? > > My concern is exactly what you speculate about... organizations are > going to look at this and either try to tackle everything (and fail) or > decide there's too much to tackle (and quit). In my experience working > with maturity models as a consultant, very few people actually > understand the concept. Folks are far more tuned-in to a PCI-like > prescriptive method. Ironically, the PCI folks say the same thing you > did - that it's not meant to be prescriptive, that it's supposed to be > based on risk management practices - yet look how it's used. > > Maybe you've addressed this, but it doesn't sound like it. I'd perhaps > be better educated here if the web site wasn't down... ;) > > -ben > > Sammy Migues wrote: >> Hi Pravir, >> >> Thanks for clarifying what you're positing. I'm not sure how we could >> have been more clear in the BSIMM text accompanying the exposition of >> the collective activities about the need to take this information and >> work it into your own culture (i.e., do "risk management"). As a few >> examples: >> >> p. 3: "BSIMM is meant as a guide for building and evolving a software >> security initiative. As you will see when you familiarize yourself >> with the BSIMM activities, instilling software security into an >> organization takes careful planning and always involves broad >> organizational change. By clearly noting objectives and goals and by >> tracking practices with metrics tailored to your own initiative, you >> can methodically build software security in to your organization?s >> software development practices." >> >> p. 47: "Choosing which of the 110 BSIMM activities to adopt and in >> what order can be a challenge. We suggest creating a software >> security initiative strategy and plan by focusing on goals and >> objectives first and letting the activities select themselves. >> Creating a timeline for rollout is often very useful. Of course >> learning from experience is also a good strategy." >> >> p. 47: "Of the 110 possible activities in BSIMM, there are ten >> activities that all of the nine programs we studied carry out. Though >> we can?t directly conclude that these ten activities are necessary >> for all software security initiatives, we can say with confidence >> that these activities are commonly found in highly successful >> programs. This suggests that if you are working on an initiative of >> your own, you should consider these ten activities particularly >> carefully (not to mention the other 100)." >> >> p. 48: "The chart below shows how many of the nine organizations we >> studied have adopted various activities. Though you can use this as a >> rough ?weighting? of activities by prevalence, a software security >> initiative plan is best approached through goals and objectives." >> >> Your words (...BSIMM fails...) imply (to me) that you posit >> organizations attempting to use the collected wisdom in BSIMM will, >> inexplicably, look at it and say "Okay, we have to do all 110 of >> these things exactly as written, so let's get started" without regard >> to their local need. This is as opposed to, say, looking at it and >> thinking "Here's what nine companies have spent dozens of >> person-decades and millions of dollars learning about what works; >> let's see what we can glean from that." Uhmmmm, okay. >> >> Yes, previous models exist. Although it may have come up in >> conversation, we did not ask any of the nine something like "What >> model did you start with back in the beginning?" because it simply >> isn't relevant to what we're trying to accomplish (documenting what >> successful organizations are doing), just as "could" and "should" >> aren't relevant. We asked "What *are* you doing now?" and documented >> it so others could learn from it. >> >> --Sammy. >> >> -----Original Message----- From: Pravir Chandra >> [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: >> Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org >> Subject: Re: [SC-L] Positive impact of an SSG >> >> Yes, I don't think its exclusive to your BSIMM interviews that you >> found when people put controls into place, they saw improvement. >> That's what I (and I'm sure many other consultanting firms) have been >> doing for years based upon previous models (CLASP, MS SDL, etc.). >> Nothing to do with BSIMM per se (actually, most of what DTCC started >> doing was based on CLASP), just that they added controls 'early into >> software development lifecycle' and saw benefit, which isn't >> surprising. >> >> That being said, the important part we're missing as 'software >> security guys' isn't the specification of all the possible things >> that an organization *could* do, but rather what a given organization >> *should* do based on good business decisions around risk management. >> And that's the crux of what BSIMM fails to do. By basing the current >> maturity model on the collected practices of 9 massive firms that >> spend the most on that problem, anyone (aside from firms in a similar >> situation to your 9) that attempts to apply it to their organization >> effectively throws risk management decisions out the window and >> commits to a much more costly solution than they could have created >> based on the knowledge of their own business needs since all the >> practices are based solely on the behaviors of the select few firms >> you interviewed. I'm not discounting the validity of the empirical >> data, I'm just positting that it isn't scientifically valid for >> solving the problem at hand. >> >> I'm interested to hear what you learn when you get to the small and >> medium sized businesses as well as firms using agile development >> models (something I particularly considered and accounted for with >> SAMM). >> >> Regardless of whether we agree on the percentage of orgs for which a >> dedicated SSG isn't cost effective, I'm sure we can agree that >> affording 'someone in charge of success' doesn't equate to a >> dedicated SSG. There's a myriad of ways that can be accomplished in >> any organizational structure. >> >> Thanks! >> >> p. >> >> ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir >> Chandra ?????????????????????chandralistorg PGP: ???CE60 >> 0E10 9207 7290 06EB ??5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ >> ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ >> >> -----Original Message----- From: Sammy Migues >> >> Date: Tue, 10 Mar 2009 23:15:39 To: >> sc-l at securecoding.org Subject: Re: [SC-L] >> Positive impact of an SSG >> >> >> Hi Pravir, >> >> Yes, I agree completely: the data gathered in the BSIMM interviews >> seem to indicate that "the controls over all" led to what the >> interviewees saw as improvements in their capability to produce >> secure software. >> >> In the nine companies interviewed, those controls (BSIMM activities, >> I think) sprang from well established SSGs -- that is, a specific >> person or persons with the responsibility for ensuring lots (110, >> collectively) of activities actually get done. >> >> The BSIMM data to date from specific large organizations indicate >> that a little under 100:1 is the average ratio for dev/QA to SSG >> size. It'll be interesting to see how this changes when we get to >> interviewing smaller organizations and we see if and how they're >> actually getting it done. >> >> Personally, I don't believe I agree with your guess that 95% of >> organizations building code can't afford an SSG. I believe every >> organization that wants to succeed can afford to have someone in >> charge of success, but that's just my opinion and isn't relevant to >> BSIMM. >> >> Cheers, >> >> --Sammy. >> >> >> -----Original Message----- From: Pravir Chandra >> [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: >> Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive >> impact of an SSG >> >> Hey Sammy. >> >> How does that pertain to a software security group (SSG) per se? The >> details below seem to indicate that it was the controls over all that >> ?lead to the positive impact. >> >> My main point is that supporting an SSG isn't cost effective for 95% >> of the organizations out there that are building code. That's why in >> SAMM, we didn't mandate the structure of the organization and instead >> ?concentrated on the functions fulfilled by security guys (regardless >> ?of their placement in the org). >> >> p. >> >> On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues >> wrote: >>> Hi all, >>> >>> I've received some private questions about the 110 activities in >>> BSIMM (bsi-mm.com). Since we built the model directly from the data >>> gathered, each activity is actually being done in one of the nine >>> organizations interviewed. The question is whether there's any >>> evidence the activities are actually effective as opposed to simply >>> being done. >>> >>> Since we can't publish any private data, I'd like to point folks at >>> this recent article in Information Security Magazine. Jim Routh, >>> CISO of DTCC (one of the nine organizations interviewed), is quoted >>> as follows relative to the impact of software security group >>> activities: >>> >>> >>> http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html >>> >>> >>> "One of Routh's big wins is inserting security controls early into >>> software development lifecycle at the DTCC. Vulnerabilities are >>> weeded out well before they appear in functional code that ends up >>> in production and that has resulted in close to $2 million in >>> productivity gains on a base of $150 million spend for development, >>> Routh says. >>> >>> "Those gains are exclusively the result of having mature and >>> effective controls within our system and software development >>> lifecycle," Routh says. This is a three-year-old initiative that >>> educates and certifies developers in all DTCC environments in >>> security. Developers are also provided with the necessary >>> code-scanning tools and consulting and services help to keep >>> production code close to pristine." >>> >>> --Sammy. >>> >>> Sammy Migues Principal, Technology 703.404.5830 - >>> http://www.cigital.com Software confidence. Achieved. >>> smigues at cigital.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. >>> _______________________________________________ >>> >> >> >> > > -- > 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: ] > "Don't you wish there were a knob on the TV to turn up the intelligence? > There's one marked 'Brightness,' but it doesn't work." > Gallagher > _______________________________________________ > 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. > _______________________________________________ > > -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From list-spam at secureconsulting.net Wed Mar 11 12:32:17 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 11 Mar 2009 13:32:17 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: References: Message-ID: <49B7F5A1.5000506@secureconsulting.net> I think the celebration is a bit premature, for many of the reasons Pravir just covered. I think that perhaps the problem we're having here is that you've not really tested your results, nor have you iterated through a 2nd time to reevaluate the working theory. If you were approaching this scientifically, I think the process would look like this (http://en.wikipedia.org/wiki/Scientific_method): 1. Use your experience: Consider the problem and try to make sense of it. Look for previous explanations. If this is a new problem to you, then move to step 2. 2. Form a conjecture: When nothing else is yet known, try to state an explanation, to someone else, or to your notebook. 3. Deduce a prediction from that explanation: If you assume 2 is true, what consequences follow? 4. Test : Look for the opposite of each consequence in order to disprove 2. It is a logical error to seek 3 directly as proof of 2. This error is called affirming the consequent. I think what your missing, then, is at least step 4 as well as reiterating through the process again (and possibly Step 3). It's a bit abstract, perhaps, to rigidly apply the scientific method to this program, but I think it's instructive to consider how you might do this. BTW, your citation of the xkcd strip on causation vs correlation is actually instructive here. You've developed a model based on correlation without demonstrating causation at all. Not to get abstruse, but I don't see that your model is properly supported or validated. In the end, ironically, it seems to come down more to expert theories than empirical evidence. A handful of experts studied 9 organizations and correlated "highly successful" with "110 practices", but without properly defining success, without generalizing the model to all types of organizations (or without defining the scope), and without testing/validating the model. The good news is that you can now test the model. The bad news is that you ("you" being the collective behind BSI-MM) probably should have tested the model first before jumping straight to fanfare and hoopla. :) In the end, I'm sure that BSI-MM will be a fine model, though the questions will then be "can I implement it?" and "will it have sustainable value on its own?" If the value of the model rests on Cigital and Fortify pushing it into organizations by force (much as the Big N, ISACA, and ITGI have tried to do with CObIT and valIT), then I submit that it will encounter problems. It needs to be able to stand on its own, properly validated, with inherent value through logical implementation. Which perhaps begs a question: is BSI-MM intended as an implementation model to achieve better security in software development, or is it a measurement tool for evaluating the current security maturity of software development? A maturity model is typically used to measure maturity, which means that someone has to then come along and provide guidance on how to implement a program that can reach an optimal measurement. (and mayhaps this would be a good time to get together with Pravir to see if there's a way that you could both have winning game plans) BTW, when you get to the point of defining success, I would suggest looking at FAIR (since they lean toward quantitative vs qualitative risk assessment based on Bayesian statistics) as well as looking at the concept of "risk resiliency" advocated, in particular, by BT. fwiw. Anyway... On whether the site is up or not, I think DNS is hosed for the domain... I tried it from three locations (separate regions, separate providers) and got the same results: $ host bsi-mm.com Host bsi-mm.com not found: 3(NXDOMAIN) $ host bsi-mm.com ;; connection timed out; no servers could be reached freeproxy.us also times out... cheers, -ben Brian Chess wrote: > Ben! Thank you! When you talk about sample size, it gives me hope that > we?re on the right track. We can either: > > 1) Use ideas that ?experts? theorize will work > or > 2) Gather empirical evidence to judge one idea against another. > > We in the security crowd often try to hide behind the need for secrecy, > and that?s pushed us toward relying almost entirely on people who have > nothing but rhetoric and personal reputation to stand on. BSIMM pretty > well shows that, in 2009, we can do better. It?s a big step forward to > collect data and then argue about what it means. I know it?s already > made the rounds, but let?s have some XKCD to celebrate: > http://xkcd.com/552/ > > I think your question about defining success is an important one. We > were loose about it in this first round, and I hope it?s something we > can tighten up in our follow-on work. Here?s my thinking as of today: > software security is not the goal, it?s one of the many things an > organization needs to do in order to meet it?s objectives. We need to > look at how a software security initiative (or lack thereof) effects the > organization?s ability to meet it?s objectives. This is going to be > messy, but it?s either that or go back to making stuff up. > > BTW, I checked the BSIMM web site after I read your message. It worked > for me. Try this? > http://www.downforeveryoneorjustme.com/bsi-mm.com > > Brian > > On 3/11/09 10:48 AM, "Benjamin Tomhave" > wrote: > > I think it's an interesting leap of faith. Statistically speaking, 9 is > a very small sample size. Thus, the proposed model will be viewed > skeptically until it is validated with a much larger and more diverse > sample. Putting it another way, there's no way I can take this to a > small or medium sized org and have them see immediate relevance, because > their first reaction is going to be "those are 9 large orgs with lots of > resources - we don't have that luxury." > > You quoted "we can say with confidence that these activities are > commonly found in highly successful programs" - how do you define a > "highly successful program"? What's the rule or metric? Is this a rule > or metric that can be genericized easily to all development teams? > > My concern is exactly what you speculate about... organizations are > going to look at this and either try to tackle everything (and fail) or > decide there's too much to tackle (and quit). In my experience working > with maturity models as a consultant, very few people actually > understand the concept. Folks are far more tuned-in to a PCI-like > prescriptive method. Ironically, the PCI folks say the same thing you > did - that it's not meant to be prescriptive, that it's supposed to be > based on risk management practices - yet look how it's used. > > Maybe you've addressed this, but it doesn't sound like it. I'd perhaps > be better educated here if the web site wasn't down... ;) > > -ben > > Sammy Migues wrote: > > Hi Pravir, > > > > Thanks for clarifying what you're positing. I'm not sure how we could > > have been more clear in the BSIMM text accompanying the exposition of > > the collective activities about the need to take this information and > > work it into your own culture (i.e., do "risk management"). As a few > > examples: > > > > p. 3: "BSIMM is meant as a guide for building and evolving a software > > security initiative. As you will see when you familiarize yourself > > with the BSIMM activities, instilling software security into an > > organization takes careful planning and always involves broad > > organizational change. By clearly noting objectives and goals and by > > tracking practices with metrics tailored to your own initiative, you > > can methodically build software security in to your organization?s > > software development practices." > > > > p. 47: "Choosing which of the 110 BSIMM activities to adopt and in > > what order can be a challenge. We suggest creating a software > > security initiative strategy and plan by focusing on goals and > > objectives first and letting the activities select themselves. > > Creating a timeline for rollout is often very useful. Of course > > learning from experience is also a good strategy." > > > > p. 47: "Of the 110 possible activities in BSIMM, there are ten > > activities that all of the nine programs we studied carry out. Though > > we can?t directly conclude that these ten activities are necessary > > for all software security initiatives, we can say with confidence > > that these activities are commonly found in highly successful > > programs. This suggests that if you are working on an initiative of > > your own, you should consider these ten activities particularly > > carefully (not to mention the other 100)." > > > > p. 48: "The chart below shows how many of the nine organizations we > > studied have adopted various activities. Though you can use this as a > > rough ?weighting? of activities by prevalence, a software security > > initiative plan is best approached through goals and objectives." > > > > Your words (...BSIMM fails...) imply (to me) that you posit > > organizations attempting to use the collected wisdom in BSIMM will, > > inexplicably, look at it and say "Okay, we have to do all 110 of > > these things exactly as written, so let's get started" without regard > > to their local need. This is as opposed to, say, looking at it and > > thinking "Here's what nine companies have spent dozens of > > person-decades and millions of dollars learning about what works; > > let's see what we can glean from that." Uhmmmm, okay. > > > > Yes, previous models exist. Although it may have come up in > > conversation, we did not ask any of the nine something like "What > > model did you start with back in the beginning?" because it simply > > isn't relevant to what we're trying to accomplish (documenting what > > successful organizations are doing), just as "could" and "should" > > aren't relevant. We asked "What *are* you doing now?" and documented > > it so others could learn from it. > > > > --Sammy. > > > > -----Original Message----- From: Pravir Chandra > > [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: > > Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org > > Subject: Re: [SC-L] Positive impact of an SSG > > > > Yes, I don't think its exclusive to your BSIMM interviews that you > > found when people put controls into place, they saw improvement. > > That's what I (and I'm sure many other consultanting firms) have been > > doing for years based upon previous models (CLASP, MS SDL, etc.). > > Nothing to do with BSIMM per se (actually, most of what DTCC started > > doing was based on CLASP), just that they added controls 'early into > > software development lifecycle' and saw benefit, which isn't > > surprising. > > > > That being said, the important part we're missing as 'software > > security guys' isn't the specification of all the possible things > > that an organization *could* do, but rather what a given organization > > *should* do based on good business decisions around risk management. > > And that's the crux of what BSIMM fails to do. By basing the current > > maturity model on the collected practices of 9 massive firms that > > spend the most on that problem, anyone (aside from firms in a similar > > situation to your 9) that attempts to apply it to their organization > > effectively throws risk management decisions out the window and > > commits to a much more costly solution than they could have created > > based on the knowledge of their own business needs since all the > > practices are based solely on the behaviors of the select few firms > > you interviewed. I'm not discounting the validity of the empirical > > data, I'm just positting that it isn't scientifically valid for > > solving the problem at hand. > > > > I'm interested to hear what you learn when you get to the small and > > medium sized businesses as well as firms using agile development > > models (something I particularly considered and accounted for with > > SAMM). > > > > Regardless of whether we agree on the percentage of orgs for which a > > dedicated SSG isn't cost effective, I'm sure we can agree that > > affording 'someone in charge of success' doesn't equate to a > > dedicated SSG. There's a myriad of ways that can be accomplished in > > any organizational structure. > > > > Thanks! > > > > p. > > > > ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir > > Chandra chandralistorg PGP: CE60 > > 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ > > ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ > > > > -----Original Message----- From: Sammy Migues > > > > Date: Tue, 10 Mar 2009 23:15:39 To: > > sc-l at securecoding.org @securecoding.org> Subject: Re: [SC-L] > > Positive impact of an SSG > > > > > > Hi Pravir, > > > > Yes, I agree completely: the data gathered in the BSIMM interviews > > seem to indicate that "the controls over all" led to what the > > interviewees saw as improvements in their capability to produce > > secure software. > > > > In the nine companies interviewed, those controls (BSIMM activities, > > I think) sprang from well established SSGs -- that is, a specific > > person or persons with the responsibility for ensuring lots (110, > > collectively) of activities actually get done. > > > > The BSIMM data to date from specific large organizations indicate > > that a little under 100:1 is the average ratio for dev/QA to SSG > > size. It'll be interesting to see how this changes when we get to > > interviewing smaller organizations and we see if and how they're > > actually getting it done. > > > > Personally, I don't believe I agree with your guess that 95% of > > organizations building code can't afford an SSG. I believe every > > organization that wants to succeed can afford to have someone in > > charge of success, but that's just my opinion and isn't relevant to > > BSIMM. > > > > Cheers, > > > > --Sammy. > > > > > > -----Original Message----- From: Pravir Chandra > > [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: > > Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive > > impact of an SSG > > > > Hey Sammy. > > > > How does that pertain to a software security group (SSG) per se? The > > details below seem to indicate that it was the controls over all that > > lead to the positive impact. > > > > My main point is that supporting an SSG isn't cost effective for 95% > > of the organizations out there that are building code. That's why in > > SAMM, we didn't mandate the structure of the organization and instead > > concentrated on the functions fulfilled by security guys (regardless > > of their placement in the org). > > > > p. > > > > On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues > > wrote: > >> Hi all, > >> > >> I've received some private questions about the 110 activities in > >> BSIMM (bsi-mm.com). Since we built the model directly from the data > >> gathered, each activity is actually being done in one of the nine > >> organizations interviewed. The question is whether there's any > >> evidence the activities are actually effective as opposed to simply > >> being done. > >> > >> Since we can't publish any private data, I'd like to point folks at > >> this recent article in Information Security Magazine. Jim Routh, > >> CISO of DTCC (one of the nine organizations interviewed), is quoted > >> as follows relative to the impact of software security group > >> activities: > >> > >> > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > >> > >> > >> "One of Routh's big wins is inserting security controls early into > >> software development lifecycle at the DTCC. Vulnerabilities are > >> weeded out well before they appear in functional code that ends up > >> in production and that has resulted in close to $2 million in > >> productivity gains on a base of $150 million spend for development, > >> Routh says. > >> > >> "Those gains are exclusively the result of having mature and > >> effective controls within our system and software development > >> lifecycle," Routh says. This is a three-year-old initiative that > >> educates and certifies developers in all DTCC environments in > >> security. Developers are also provided with the necessary > >> code-scanning tools and consulting and services help to keep > >> production code close to pristine." > >> > >> --Sammy. > >> > >> Sammy Migues Principal, Technology 703.404.5830 - > >> http://www.cigital.com Software confidence. Achieved. > >> smigues at cigital.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. > >> _______________________________________________ > >> > > > > > > > > -- > 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: ] > "Don't you wish there were a knob on the TV to turn up the intelligence? > There's one marked 'Brightness,' but it doesn't work." > Gallagher > _______________________________________________ > 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. > _______________________________________________ > -- 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: ] "Why don't they make the whole plane out of that black box stuff." Steven Wright From brian at fortify.com Wed Mar 11 13:29:10 2009 From: brian at fortify.com (Brian Chess) Date: Wed, 11 Mar 2009 14:29:10 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: <49B7F5A1.5000506@secureconsulting.net> Message-ID: Ben, Pravir, Skepticism is healthy, but recognize that: 1) These criticisms would not be possible if we hadn?t explained how BSIMM was created and offered up the origins of the data. If we simply said ?here, we think this will probably work?, we could have created a much more elegant model, and it would have been easy to brush all of the ?how did you validate it?? questions under the rug with lines like ?Trust us, we?re the experts!? 2) We published our data set. If you don?t like the model we created, you can use our data to create your own. If you don?t think we came at this the right way, you can conduct a better experiment, publish your data, and demonstrate that ours is inferior. I hope that happens. It?s how progress occurs in many other disciplines. So then, is software security a solved problem? Of course not! There?s plenty left to be done, and the landscape will be different next year. We will have new dilemmas and we?ll be working under tighter tolerances. We will need a constant stream of new and unproven ideas to try out and report back on. So BSIMM isn?t game over, but in moving from ?no supporting evidence? to ?based on the data?, we?ve raised the bar. Ben, thanks for the DNS digging. Brian On 3/11/09 1:32 PM, "Benjamin Tomhave" wrote: > I think the celebration is a bit premature, for many of the reasons > Pravir just covered. I think that perhaps the problem we're having here > is that you've not really tested your results, nor have you iterated > through a 2nd time to reevaluate the working theory. If you were > approaching this scientifically, I think the process would look like > this (http://en.wikipedia.org/wiki/Scientific_method): > 1. Use your experience: Consider the problem and try to make sense > of it. Look for previous explanations. If this is a new problem to you, > then move to step 2. > 2. Form a conjecture: When nothing else is yet known, try to state > an explanation, to someone else, or to your notebook. > 3. Deduce a prediction from that explanation: If you assume 2 is > true, what consequences follow? > 4. Test : Look for the opposite of each consequence in order to > disprove 2. It is a logical error to seek 3 directly as proof of 2. This > error is called affirming the consequent. > > I think what your missing, then, is at least step 4 as well as > reiterating through the process again (and possibly Step 3). It's a bit > abstract, perhaps, to rigidly apply the scientific method to this > program, but I think it's instructive to consider how you might do this. > > BTW, your citation of the xkcd strip on causation vs correlation is > actually instructive here. You've developed a model based on correlation > without demonstrating causation at all. Not to get abstruse, but I don't > see that your model is properly supported or validated. In the end, > ironically, it seems to come down more to expert theories than empirical > evidence. A handful of experts studied 9 organizations and correlated > "highly successful" with "110 practices", but without properly defining > success, without generalizing the model to all types of organizations > (or without defining the scope), and without testing/validating the model. > > The good news is that you can now test the model. The bad news is that > you ("you" being the collective behind BSI-MM) probably should have > tested the model first before jumping straight to fanfare and hoopla. :) > > In the end, I'm sure that BSI-MM will be a fine model, though the > questions will then be "can I implement it?" and "will it have > sustainable value on its own?" If the value of the model rests on > Cigital and Fortify pushing it into organizations by force (much as the > Big N, ISACA, and ITGI have tried to do with CObIT and valIT), then I > submit that it will encounter problems. It needs to be able to stand on > its own, properly validated, with inherent value through logical > implementation. > > Which perhaps begs a question: is BSI-MM intended as an implementation > model to achieve better security in software development, or is it a > measurement tool for evaluating the current security maturity of > software development? A maturity model is typically used to measure > maturity, which means that someone has to then come along and provide > guidance on how to implement a program that can reach an optimal > measurement. (and mayhaps this would be a good time to get together with > Pravir to see if there's a way that you could both have winning game plans) > > BTW, when you get to the point of defining success, I would suggest > looking at FAIR (since they lean toward quantitative vs qualitative risk > assessment based on Bayesian statistics) as well as looking at the > concept of "risk resiliency" advocated, in particular, by BT. fwiw. > > Anyway... > > On whether the site is up or not, I think DNS is hosed for the domain... > I tried it from three locations (separate regions, separate providers) > and got the same results: > > $ host bsi-mm.com > Host bsi-mm.com not found: 3(NXDOMAIN) > > $ host bsi-mm.com > ;; connection timed out; no servers could be reached > > freeproxy.us also times out... > > cheers, > > -ben > > Brian Chess wrote: >> > Ben! Thank you! When you talk about sample size, it gives me hope that >> > we?re on the right track. We can either: >> > >> > 1) Use ideas that ?experts? theorize will work >> > or >> > 2) Gather empirical evidence to judge one idea against another. >> > >> > We in the security crowd often try to hide behind the need for secrecy, >> > and that?s pushed us toward relying almost entirely on people who have >> > nothing but rhetoric and personal reputation to stand on. BSIMM pretty >> > well shows that, in 2009, we can do better. It?s a big step forward to >> > collect data and then argue about what it means. I know it?s already >> > made the rounds, but let?s have some XKCD to celebrate: >> > http://xkcd.com/552/ >> > >> > I think your question about defining success is an important one. We >> > were loose about it in this first round, and I hope it?s something we >> > can tighten up in our follow-on work. Here?s my thinking as of today: >> > software security is not the goal, it?s one of the many things an >> > organization needs to do in order to meet it?s objectives. We need to >> > look at how a software security initiative (or lack thereof) effects the >> > organization?s ability to meet it?s objectives. This is going to be >> > messy, but it?s either that or go back to making stuff up. >> > >> > BTW, I checked the BSIMM web site after I read your message. It worked >> > for me. Try this? >> > http://www.downforeveryoneorjustme.com/bsi-mm.com >> > >> > Brian >> > >> > On 3/11/09 10:48 AM, "Benjamin Tomhave" >> > wrote: >> > >> > I think it's an interesting leap of faith. Statistically speaking, 9 is >> > a very small sample size. Thus, the proposed model will be viewed >> > skeptically until it is validated with a much larger and more diverse >> > sample. Putting it another way, there's no way I can take this to a >> > small or medium sized org and have them see immediate relevance, >> because >> > their first reaction is going to be "those are 9 large orgs with lots >> of >> > resources - we don't have that luxury." >> > >> > You quoted "we can say with confidence that these activities are >> > commonly found in highly successful programs" - how do you define a >> > "highly successful program"? What's the rule or metric? Is this a rule >> > or metric that can be genericized easily to all development teams? >> > >> > My concern is exactly what you speculate about... organizations are >> > going to look at this and either try to tackle everything (and fail) or >> > decide there's too much to tackle (and quit). In my experience working >> > with maturity models as a consultant, very few people actually >> > understand the concept. Folks are far more tuned-in to a PCI-like >> > prescriptive method. Ironically, the PCI folks say the same thing you >> > did - that it's not meant to be prescriptive, that it's supposed to be >> > based on risk management practices - yet look how it's used. >> > >> > Maybe you've addressed this, but it doesn't sound like it. I'd perhaps >> > be better educated here if the web site wasn't down... ;) >> > >> > -ben >> > >> > Sammy Migues wrote: >>> > > Hi Pravir, >>> > > >>> > > Thanks for clarifying what you're positing. I'm not sure how we could >>> > > have been more clear in the BSIMM text accompanying the exposition of >>> > > the collective activities about the need to take this information and >>> > > work it into your own culture (i.e., do "risk management"). As a few >>> > > examples: >>> > > >>> > > p. 3: "BSIMM is meant as a guide for building and evolving a >>> software >>> > > security initiative. As you will see when you familiarize yourself >>> > > with the BSIMM activities, instilling software security into an >>> > > organization takes careful planning and always involves broad >>> > > organizational change. By clearly noting objectives and goals and by >>> > > tracking practices with metrics tailored to your own initiative, you >>> > > can methodically build software security in to your organization?s >>> > > software development practices." >>> > > >>> > > p. 47: "Choosing which of the 110 BSIMM activities to adopt and in >>> > > what order can be a challenge. We suggest creating a software >>> > > security initiative strategy and plan by focusing on goals and >>> > > objectives first and letting the activities select themselves. >>> > > Creating a timeline for rollout is often very useful. Of course >>> > > learning from experience is also a good strategy." >>> > > >>> > > p. 47: "Of the 110 possible activities in BSIMM, there are ten >>> > > activities that all of the nine programs we studied carry out. Though >>> > > we can?t directly conclude that these ten activities are necessary >>> > > for all software security initiatives, we can say with confidence >>> > > that these activities are commonly found in highly successful >>> > > programs. This suggests that if you are working on an initiative of >>> > > your own, you should consider these ten activities particularly >>> > > carefully (not to mention the other 100)." >>> > > >>> > > p. 48: "The chart below shows how many of the nine organizations we >>> > > studied have adopted various activities. Though you can use this as a >>> > > rough ?weighting? of activities by prevalence, a software security >>> > > initiative plan is best approached through goals and objectives." >>> > > >>> > > Your words (...BSIMM fails...) imply (to me) that you posit >>> > > organizations attempting to use the collected wisdom in BSIMM will, >>> > > inexplicably, look at it and say "Okay, we have to do all 110 of >>> > > these things exactly as written, so let's get started" without regard >>> > > to their local need. This is as opposed to, say, looking at it and >>> > > thinking "Here's what nine companies have spent dozens of >>> > > person-decades and millions of dollars learning about what works; >>> > > let's see what we can glean from that." Uhmmmm, okay. >>> > > >>> > > Yes, previous models exist. Although it may have come up in >>> > > conversation, we did not ask any of the nine something like "What >>> > > model did you start with back in the beginning?" because it simply >>> > > isn't relevant to what we're trying to accomplish (documenting what >>> > > successful organizations are doing), just as "could" and "should" >>> > > aren't relevant. We asked "What *are* you doing now?" and documented >>> > > it so others could learn from it. >>> > > >>> > > --Sammy. >>> > > >>> > > -----Original Message----- From: Pravir Chandra >>> > > [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 4:00 AM To: >>> > > Sammy Migues; sc-l-bounces at securecoding.org; sc-l at securecoding.org >>> > > Subject: Re: [SC-L] Positive impact of an SSG >>> > > >>> > > Yes, I don't think its exclusive to your BSIMM interviews that you >>> > > found when people put controls into place, they saw improvement. >>> > > That's what I (and I'm sure many other consultanting firms) have been >>> > > doing for years based upon previous models (CLASP, MS SDL, etc.). >>> > > Nothing to do with BSIMM per se (actually, most of what DTCC started >>> > > doing was based on CLASP), just that they added controls 'early into >>> > > software development lifecycle' and saw benefit, which isn't >>> > > surprising. >>> > > >>> > > That being said, the important part we're missing as 'software >>> > > security guys' isn't the specification of all the possible things >>> > > that an organization *could* do, but rather what a given >>> organization >>> > > *should* do based on good business decisions around risk management. >>> > > And that's the crux of what BSIMM fails to do. By basing the current >>> > > maturity model on the collected practices of 9 massive firms that >>> > > spend the most on that problem, anyone (aside from firms in a similar >>> > > situation to your 9) that attempts to apply it to their organization >>> > > effectively throws risk management decisions out the window and >>> > > commits to a much more costly solution than they could have created >>> > > based on the knowledge of their own business needs since all the >>> > > practices are based solely on the behaviors of the select few firms >>> > > you interviewed. I'm not discounting the validity of the empirical >>> > > data, I'm just positting that it isn't scientifically valid for >>> > > solving the problem at hand. >>> > > >>> > > I'm interested to hear what you learn when you get to the small and >>> > > medium sized businesses as well as firms using agile development >>> > > models (something I particularly considered and accounted for with >>> > > SAMM). >>> > > >>> > > Regardless of whether we agree on the percentage of orgs for which a >>> > > dedicated SSG isn't cost effective, I'm sure we can agree that >>> > > affording 'someone in charge of success' doesn't equate to a >>> > > dedicated SSG. There's a myriad of ways that can be accomplished in >>> > > any organizational structure. >>> > > >>> > > Thanks! >>> > > >>> > > p. >>> > > >>> > > ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir >>> > > Chandra chandralistorg PGP: CE60 >>> > > 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ >>> > > ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ >>> > > >>> > > -----Original Message----- From: Sammy Migues >>> > > >>> > > Date: Tue, 10 Mar 2009 23:15:39 To: >>> > > sc-l at securecoding.org> > @securecoding.org> Subject: Re: [SC-L] >>> > > Positive impact of an SSG >>> > > >>> > > >>> > > Hi Pravir, >>> > > >>> > > Yes, I agree completely: the data gathered in the BSIMM interviews >>> > > seem to indicate that "the controls over all" led to what the >>> > > interviewees saw as improvements in their capability to produce >>> > > secure software. >>> > > >>> > > In the nine companies interviewed, those controls (BSIMM activities, >>> > > I think) sprang from well established SSGs -- that is, a specific >>> > > person or persons with the responsibility for ensuring lots (110, >>> > > collectively) of activities actually get done. >>> > > >>> > > The BSIMM data to date from specific large organizations indicate >>> > > that a little under 100:1 is the average ratio for dev/QA to SSG >>> > > size. It'll be interesting to see how this changes when we get to >>> > > interviewing smaller organizations and we see if and how they're >>> > > actually getting it done. >>> > > >>> > > Personally, I don't believe I agree with your guess that 95% of >>> > > organizations building code can't afford an SSG. I believe every >>> > > organization that wants to succeed can afford to have someone in >>> > > charge of success, but that's just my opinion and isn't relevant to >>> > > BSIMM. >>> > > >>> > > Cheers, >>> > > >>> > > --Sammy. >>> > > >>> > > >>> > > -----Original Message----- From: Pravir Chandra >>> > > [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 PM To: >>> > > Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] Positive >>> > > impact of an SSG >>> > > >>> > > Hey Sammy. >>> > > >>> > > How does that pertain to a software security group (SSG) per se? The >>> > > details below seem to indicate that it was the controls over all that >>> > > lead to the positive impact. >>> > > >>> > > My main point is that supporting an SSG isn't cost effective for 95% >>> > > of the organizations out there that are building code. That's why in >>> > > SAMM, we didn't mandate the structure of the organization and instead >>> > > concentrated on the functions fulfilled by security guys >>> (regardless >>> > > of their placement in the org). >>> > > >>> > > p. >>> > > >>> > > On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues >>> > > wrote: >>>> > >> Hi all, >>>> > >> >>>> > >> I've received some private questions about the 110 activities in >>>> > >> BSIMM (bsi-mm.com). Since we built the model directly from the data >>>> > >> gathered, each activity is actually being done in one of the nine >>>> > >> organizations interviewed. The question is whether there's any >>>> > >> evidence the activities are actually effective as opposed to simply >>>> > >> being done. >>>> > >> >>>> > >> Since we can't publish any private data, I'd like to point folks at >>>> > >> this recent article in Information Security Magazine. Jim Routh, >>>> > >> CISO of DTCC (one of the nine organizations interviewed), is quoted >>>> > >> as follows relative to the impact of software security group >>>> > >> activities: >>>> > >> >>>> > >> >> > >> http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci134697 >> 4,00.html >>>> > >> >>>> > >> >>>> > >> "One of Routh's big wins is inserting security controls early into >>>> > >> software development lifecycle at the DTCC. Vulnerabilities are >>>> > >> weeded out well before they appear in functional code that ends up >>>> > >> in production and that has resulted in close to $2 million in >>>> > >> productivity gains on a base of $150 million spend for >>>> development, >>>> > >> Routh says. >>>> > >> >>>> > >> "Those gains are exclusively the result of having mature and >>>> > >> effective controls within our system and software development >>>> > >> lifecycle," Routh says. This is a three-year-old initiative that >>>> > >> educates and certifies developers in all DTCC environments in >>>> > >> security. Developers are also provided with the necessary >>>> > >> code-scanning tools and consulting and services help to keep >>>> > >> production code close to pristine." >>>> > >> >>>> > >> --Sammy. >>>> > >> >>>> > >> Sammy Migues Principal, Technology 703.404.5830 - >>>> > >> http://www.cigital.com Software confidence. Achieved. >>>> > >> smigues at cigital.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. >>>> > >> _______________________________________________ >>>> > >> >>> > > >>> > > >>> > > >> > >> > -- >> > 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: ] >> > "Don't you wish there were a knob on the TV to turn up the >> intelligence? >> > There's one marked 'Brightness,' but it doesn't work." >> > Gallagher >> > _______________________________________________ >> > 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. >> > _______________________________________________ >> > > > -- > 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: ] > "Why don't they make the whole plane out of that black box stuff." > Steven Wright > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090311/856f3ffb/attachment-0001.html From list-spam at secureconsulting.net Wed Mar 11 16:11:47 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 11 Mar 2009 17:11:47 -0400 Subject: [SC-L] Positive impact of an SSG In-Reply-To: References: Message-ID: <49B82913.2030907@secureconsulting.net> I think something significant has been excluded from this thread on BSIMM, and that's the role of SSF. If I am to understand correctly, SSF implementation was the experiment, and BSIMM was the resultant model for assessing (measuring) the maturity of software security programs being developed with SSF. Is that a fair read? In the end, the same problem exists here: development of a model based on data does not a validated model make. By way of Bayesian thinking, you can definitely create a viable model based on a small sampling (FAIR is based on this principle). However, you still have to go back and /independently/ validate that model by exercising it outside of the original data set. Does BSIMM appear to be a viable model for assessing the maturity of SSF-based software security programs? Sure. Has BSIMM been independently validated using a similar data set? No. Is BSIMM inherently reliant on SSF? Methinks so. Does BSIMM make universal sense for measuring *any* software security program? Unclear, but is questionable. Is SSF a de fact standard for building a software security program? Unclear. Anyway... fun debate! I fully appreciate the new work here, and I think it holds promise. The release of the initial draft is probably cause for a small celebration by the creators. However, until the model has been validated with independent data and has been shown to be generically applicable, I think there is still reason to hold back the really good bubbly. ;) cheers, -ben Brian Chess wrote: > Ben, Pravir, > Skepticism is healthy, but recognize that: > > 1) These criticisms would not be possible if we hadn?t explained how > BSIMM was created and offered up the origins of the data. If we simply > said ?here, we think this will probably work?, we could have created a > much more elegant model, and it would have been easy to brush all of the > ?how did you validate it?? questions under the rug with lines like > ?Trust us, we?re the experts!? > > 2) We published our data set. If you don?t like the model we created, > you can use our data to create your own. If you don?t think we came at > this the right way, you can conduct a better experiment, publish your > data, and demonstrate that ours is inferior. I hope that happens. It?s > how progress occurs in many other disciplines. > > So then, is software security a solved problem? Of course not! There?s > plenty left to be done, and the landscape will be different next year. > We will have new dilemmas and we?ll be working under tighter > tolerances. We will need a constant stream of new and unproven ideas to > try out and report back on. So BSIMM isn?t game over, but in moving > from ?no supporting evidence? to ?based on the data?, we?ve raised the bar. > > Ben, thanks for the DNS digging. > > Brian > > On 3/11/09 1:32 PM, "Benjamin Tomhave" > wrote: > > I think the celebration is a bit premature, for many of the reasons > Pravir just covered. I think that perhaps the problem we're having here > is that you've not really tested your results, nor have you iterated > through a 2nd time to reevaluate the working theory. If you were > approaching this scientifically, I think the process would look like > this (http://en.wikipedia.org/wiki/Scientific_method): > 1. Use your experience: Consider the problem and try to make sense > of it. Look for previous explanations. If this is a new problem to you, > then move to step 2. > 2. Form a conjecture: When nothing else is yet known, try to state > an explanation, to someone else, or to your notebook. > 3. Deduce a prediction from that explanation: If you assume 2 is > true, what consequences follow? > 4. Test : Look for the opposite of each consequence in order to > disprove 2. It is a logical error to seek 3 directly as proof of 2. This > error is called affirming the consequent. > > I think what your missing, then, is at least step 4 as well as > reiterating through the process again (and possibly Step 3). It's a bit > abstract, perhaps, to rigidly apply the scientific method to this > program, but I think it's instructive to consider how you might do this. > > BTW, your citation of the xkcd strip on causation vs correlation is > actually instructive here. You've developed a model based on correlation > without demonstrating causation at all. Not to get abstruse, but I don't > see that your model is properly supported or validated. In the end, > ironically, it seems to come down more to expert theories than empirical > evidence. A handful of experts studied 9 organizations and correlated > "highly successful" with "110 practices", but without properly defining > success, without generalizing the model to all types of organizations > (or without defining the scope), and without testing/validating the > model. > > The good news is that you can now test the model. The bad news is that > you ("you" being the collective behind BSI-MM) probably should have > tested the model first before jumping straight to fanfare and hoopla. :) > > In the end, I'm sure that BSI-MM will be a fine model, though the > questions will then be "can I implement it?" and "will it have > sustainable value on its own?" If the value of the model rests on > Cigital and Fortify pushing it into organizations by force (much as the > Big N, ISACA, and ITGI have tried to do with CObIT and valIT), then I > submit that it will encounter problems. It needs to be able to stand on > its own, properly validated, with inherent value through logical > implementation. > > Which perhaps begs a question: is BSI-MM intended as an implementation > model to achieve better security in software development, or is it a > measurement tool for evaluating the current security maturity of > software development? A maturity model is typically used to measure > maturity, which means that someone has to then come along and provide > guidance on how to implement a program that can reach an optimal > measurement. (and mayhaps this would be a good time to get together with > Pravir to see if there's a way that you could both have winning game > plans) > > BTW, when you get to the point of defining success, I would suggest > looking at FAIR (since they lean toward quantitative vs qualitative risk > assessment based on Bayesian statistics) as well as looking at the > concept of "risk resiliency" advocated, in particular, by BT. fwiw. > > Anyway... > > On whether the site is up or not, I think DNS is hosed for the domain... > I tried it from three locations (separate regions, separate providers) > and got the same results: > > $ host bsi-mm.com > Host bsi-mm.com not found: 3(NXDOMAIN) > > $ host bsi-mm.com > ;; connection timed out; no servers could be reached > > freeproxy.us also times out... > > cheers, > > -ben > > Brian Chess wrote: > > Ben! Thank you! When you talk about sample size, it gives me hope > that > > we?re on the right track. We can either: > > > > 1) Use ideas that ?experts? theorize will work > > or > > 2) Gather empirical evidence to judge one idea against another. > > > > We in the security crowd often try to hide behind the need for secrecy, > > and that?s pushed us toward relying almost entirely on people who have > > nothing but rhetoric and personal reputation to stand on. BSIMM pretty > > well shows that, in 2009, we can do better. It?s a big step forward to > > collect data and then argue about what it means. I know it?s already > > made the rounds, but let?s have some XKCD to celebrate: > > http://xkcd.com/552/ > > > > I think your question about defining success is an important one. We > > were loose about it in this first round, and I hope it?s something we > > can tighten up in our follow-on work. Here?s my thinking as of today: > > software security is not the goal, it?s one of the many things an > > organization needs to do in order to meet it?s objectives. We need to > > look at how a software security initiative (or lack thereof) > effects the > > organization?s ability to meet it?s objectives. This is going to be > > messy, but it?s either that or go back to making stuff up. > > > > BTW, I checked the BSIMM web site after I read your message. It worked > > for me. Try this? > > http://www.downforeveryoneorjustme.com/bsi-mm.com > > > > Brian > > > > On 3/11/09 10:48 AM, "Benjamin Tomhave" > > > wrote: > > > > I think it's an interesting leap of faith. Statistically > speaking, 9 is > > a very small sample size. Thus, the proposed model will be viewed > > skeptically until it is validated with a much larger and more > diverse > > sample. Putting it another way, there's no way I can take this to a > > small or medium sized org and have them see immediate > relevance, because > > their first reaction is going to be "those are 9 large orgs > with lots of > > resources - we don't have that luxury." > > > > You quoted "we can say with confidence that these activities are > > commonly found in highly successful programs" - how do you define a > > "highly successful program"? What's the rule or metric? Is this > a rule > > or metric that can be genericized easily to all development teams? > > > > My concern is exactly what you speculate about... organizations are > > going to look at this and either try to tackle everything (and > fail) or > > decide there's too much to tackle (and quit). In my experience > working > > with maturity models as a consultant, very few people actually > > understand the concept. Folks are far more tuned-in to a PCI-like > > prescriptive method. Ironically, the PCI folks say the same > thing you > > did - that it's not meant to be prescriptive, that it's > supposed to be > > based on risk management practices - yet look how it's used. > > > > Maybe you've addressed this, but it doesn't sound like it. I'd > perhaps > > be better educated here if the web site wasn't down... ;) > > > > -ben > > > > Sammy Migues wrote: > > > Hi Pravir, > > > > > > Thanks for clarifying what you're positing. I'm not sure how > we could > > > have been more clear in the BSIMM text accompanying the > exposition of > > > the collective activities about the need to take this > information and > > > work it into your own culture (i.e., do "risk management"). > As a few > > > examples: > > > > > > p. 3: "BSIMM is meant as a guide for building and evolving a > software > > > security initiative. As you will see when you familiarize > yourself > > > with the BSIMM activities, instilling software security into an > > > organization takes careful planning and always involves broad > > > organizational change. By clearly noting objectives and goals > and by > > > tracking practices with metrics tailored to your own > initiative, you > > > can methodically build software security in to your > organization?s > > > software development practices." > > > > > > p. 47: "Choosing which of the 110 BSIMM activities to adopt > and in > > > what order can be a challenge. We suggest creating a software > > > security initiative strategy and plan by focusing on goals and > > > objectives first and letting the activities select themselves. > > > Creating a timeline for rollout is often very useful. Of course > > > learning from experience is also a good strategy." > > > > > > p. 47: "Of the 110 possible activities in BSIMM, there are ten > > > activities that all of the nine programs we studied carry > out. Though > > > we can?t directly conclude that these ten activities are > necessary > > > for all software security initiatives, we can say with confidence > > > that these activities are commonly found in highly successful > > > programs. This suggests that if you are working on an > initiative of > > > your own, you should consider these ten activities particularly > > > carefully (not to mention the other 100)." > > > > > > p. 48: "The chart below shows how many of the nine > organizations we > > > studied have adopted various activities. Though you can use > this as a > > > rough ?weighting? of activities by prevalence, a software > security > > > initiative plan is best approached through goals and objectives." > > > > > > Your words (...BSIMM fails...) imply (to me) that you posit > > > organizations attempting to use the collected wisdom in BSIMM > will, > > > inexplicably, look at it and say "Okay, we have to do all 110 of > > > these things exactly as written, so let's get started" > without regard > > > to their local need. This is as opposed to, say, looking at > it and > > > thinking "Here's what nine companies have spent dozens of > > > person-decades and millions of dollars learning about what works; > > > let's see what we can glean from that." Uhmmmm, okay. > > > > > > Yes, previous models exist. Although it may have come up in > > > conversation, we did not ask any of the nine something like "What > > > model did you start with back in the beginning?" because it > simply > > > isn't relevant to what we're trying to accomplish > (documenting what > > > successful organizations are doing), just as "could" and "should" > > > aren't relevant. We asked "What *are* you doing now?" and > documented > > > it so others could learn from it. > > > > > > --Sammy. > > > > > > -----Original Message----- From: Pravir Chandra > > > [mailto:chandra at list.org] Sent: Wednesday, March 11, 2009 > 4:00 AM To: > > > Sammy Migues; sc-l-bounces at securecoding.org; > sc-l at securecoding.org > > > Subject: Re: [SC-L] Positive impact of an SSG > > > > > > Yes, I don't think its exclusive to your BSIMM interviews > that you > > > found when people put controls into place, they saw improvement. > > > That's what I (and I'm sure many other consultanting firms) > have been > > > doing for years based upon previous models (CLASP, MS SDL, etc.). > > > Nothing to do with BSIMM per se (actually, most of what DTCC > started > > > doing was based on CLASP), just that they added controls > 'early into > > > software development lifecycle' and saw benefit, which isn't > > > surprising. > > > > > > That being said, the important part we're missing as 'software > > > security guys' isn't the specification of all the possible things > > > that an organization *could* do, but rather what a given > organization > > > *should* do based on good business decisions around risk > management. > > > And that's the crux of what BSIMM fails to do. By basing the > current > > > maturity model on the collected practices of 9 massive firms that > > > spend the most on that problem, anyone (aside from firms in a > similar > > > situation to your 9) that attempts to apply it to their > organization > > > effectively throws risk management decisions out the window and > > > commits to a much more costly solution than they could have > created > > > based on the knowledge of their own business needs since all the > > > practices are based solely on the behaviors of the select few > firms > > > you interviewed. I'm not discounting the validity of the > empirical > > > data, I'm just positting that it isn't scientifically valid for > > > solving the problem at hand. > > > > > > I'm interested to hear what you learn when you get to the > small and > > > medium sized businesses as well as firms using agile development > > > models (something I particularly considered and accounted for > with > > > SAMM). > > > > > > Regardless of whether we agree on the percentage of orgs for > which a > > > dedicated SSG isn't cost effective, I'm sure we can agree that > > > affording 'someone in charge of success' doesn't equate to a > > > dedicated SSG. There's a myriad of ways that can be > accomplished in > > > any organizational structure. > > > > > > Thanks! > > > > > > p. > > > > > > ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ > Pravir > > > Chandra chandralistorg PGP: CE60 > > > 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ > > > ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ > > > > > > -----Original Message----- From: Sammy Migues > > > > > > > Date: Tue, 10 Mar 2009 23:15:39 To: > > > sc-l at securecoding.org > > > >@securecoding.org> Subject: Re: [SC-L] > > > Positive impact of an SSG > > > > > > > > > Hi Pravir, > > > > > > Yes, I agree completely: the data gathered in the BSIMM > interviews > > > seem to indicate that "the controls over all" led to what the > > > interviewees saw as improvements in their capability to produce > > > secure software. > > > > > > In the nine companies interviewed, those controls (BSIMM > activities, > > > I think) sprang from well established SSGs -- that is, a specific > > > person or persons with the responsibility for ensuring lots (110, > > > collectively) of activities actually get done. > > > > > > The BSIMM data to date from specific large organizations indicate > > > that a little under 100:1 is the average ratio for dev/QA to SSG > > > size. It'll be interesting to see how this changes when we get to > > > interviewing smaller organizations and we see if and how they're > > > actually getting it done. > > > > > > Personally, I don't believe I agree with your guess that 95% of > > > organizations building code can't afford an SSG. I believe every > > > organization that wants to succeed can afford to have someone in > > > charge of success, but that's just my opinion and isn't > relevant to > > > BSIMM. > > > > > > Cheers, > > > > > > --Sammy. > > > > > > > > > -----Original Message----- From: Pravir Chandra > > > [mailto:chandra at list.org] Sent: Tuesday, March 10, 2009 6:31 > PM To: > > > Sammy Migues Cc: sc-l at securecoding.org Subject: Re: [SC-L] > Positive > > > impact of an SSG > > > > > > Hey Sammy. > > > > > > How does that pertain to a software security group (SSG) per > se? The > > > details below seem to indicate that it was the controls over > all that > > > lead to the positive impact. > > > > > > My main point is that supporting an SSG isn't cost effective > for 95% > > > of the organizations out there that are building code. That's > why in > > > SAMM, we didn't mandate the structure of the organization and > instead > > > concentrated on the functions fulfilled by security guys > (regardless > > > of their placement in the org). > > > > > > p. > > > > > > On Tue, Mar 10, 2009 at 7:48 AM, Sammy Migues > > > > wrote: > > >> Hi all, > > >> > > >> I've received some private questions about the 110 activities in > > >> BSIMM (bsi-mm.com). Since we built the model directly from > the data > > >> gathered, each activity is actually being done in one of the > nine > > >> organizations interviewed. The question is whether there's any > > >> evidence the activities are actually effective as opposed to > simply > > >> being done. > > >> > > >> Since we can't publish any private data, I'd like to point > folks at > > >> this recent article in Information Security Magazine. Jim Routh, > > >> CISO of DTCC (one of the nine organizations interviewed), is > quoted > > >> as follows relative to the impact of software security group > > >> activities: > > >> > > >> > > http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1346974,00.html > > >> > > >> > > >> "One of Routh's big wins is inserting security controls > early into > > >> software development lifecycle at the DTCC. Vulnerabilities are > > >> weeded out well before they appear in functional code that > ends up > > >> in production and that has resulted in close to $2 million in > > >> productivity gains on a base of $150 million spend for > development, > > >> Routh says. > > >> > > >> "Those gains are exclusively the result of having mature and > > >> effective controls within our system and software development > > >> lifecycle," Routh says. This is a three-year-old initiative that > > >> educates and certifies developers in all DTCC environments in > > >> security. Developers are also provided with the necessary > > >> code-scanning tools and consulting and services help to keep > > >> production code close to pristine." > > >> > > >> --Sammy. > > >> > > >> Sammy Migues Principal, Technology 703.404.5830 - > > >> http://www.cigital.com Software confidence. Achieved. > > >> smigues at cigital.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. > > >> _______________________________________________ > > >> > > > > > > > > > > > > > -- > > 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: ] > > "Don't you wish there were a knob on the TV to turn up the > intelligence? > > There's one marked 'Brightness,' but it doesn't work." > > Gallagher > > _______________________________________________ > > 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. > > _______________________________________________ > > > > -- > 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: ] > "Why don't they make the whole plane out of that black box stuff." > Steven Wright > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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. > _______________________________________________ -- 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: ] Osborn's Law: "Variables won't; constants aren't." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From ken at krvw.com Thu Mar 12 09:41:00 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 12 Mar 2009 07:41:00 -0700 Subject: [SC-L] Rigged podcasts can leak your iTunes username/password | Zero Day | ZDNet.com Message-ID: <6F433659-4AA0-4CEB-9C1D-F02DCD185864@krvw.com> Hello SC-Lers, I saw this blog and thought it may be of interest here: http://blogs.zdnet.com/security/?p=2861 According to the blog, there's a design issue (read: flaw) in iTunes that can allow a maliciously formed podcast to cause a user to get prompted for a username/password -- to iTunes itself. That dialog box can then be hijacked and the victim's credentials stolen. What made it interesting to me was a couple things: first, the cited advisory from Apple (http://support.apple.com/kb/HT3487) clearly says it's a design issue. Tells me we're not likely to see a real fix for a while, IMHO. Indeed, Apple's initial "fix" to this design issue is, "This update addresses the issue by clarifying the origin of the authentication request in the dialog." That doesn't sound like much of a fix at all, and I'd expect a lot of users will still fall for the dialog box ruse. Sigh... Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://krvw.com/pipermail/sc-l/attachments/20090312/04c1b8b1/attachment-0001.bin From jim at manico.net Thu Mar 12 10:05:40 2009 From: jim at manico.net (Jim Manico) Date: Thu, 12 Mar 2009 05:05:40 -1000 Subject: [SC-L] Rigged podcasts can leak your iTunes username/password |Zero Day | ZDNet.com References: <6F433659-4AA0-4CEB-9C1D-F02DCD185864@krvw.com> Message-ID: <6037147B70074C088C3594D133654972@workhorse> On the topics of Podcast, I'm very pleased to announce the release of the non-rigged live release of OWASP Podcast #12, an Interview with Ryan C. Barnet. Ryan Barnett talks about the OWASP ModSecurity core ruleset project and WAF technology in general. Ryan has such incredible experience in this space - I was really impressed with his dept - as well as his use of Football as metaphor! =) To listen to OWASP Podcast #11 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes! Aloha from OWASP Podcast HQ, Jim From gem at cigital.com Wed Mar 18 15:52:15 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 18 Mar 2009 16:52:15 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) Message-ID: hi sc-l, The BSIMM is a sizeable document, so digesting it all at once can be a challenge. My monthly informIT column this month explains the BSIMM in a much easier to digest, shorter form. The article is co-authored by Brian and Sammy. BSIMM: Confessions of an Alchemist http://www.informit.com/articles/article.aspx?p=1332285 We had a great time writing this one. Here is my favorite paragraph (in the science versus alchemy vein): "Both early phases of software security made use of any sort of argument or 'evidence' to bolster the software security message, and that was fine given the starting point. We had lots of examples, plenty of good intuition, and the best of intentions. But now the time has come to put away the bug parade boogeyman, the top 25 tea leaves, black box web app goat sacrifice, and the occult reading of pen testing entrails. The time for science is upon us." John Waters also wrote a nice piece on the BSIMM that appeared today: http://visualstudiomagazine.com/news/article.aspx?editorialsid=10689 To download the complete model, see http://bsi-mm.com gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Wed Mar 18 15:53:25 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 18 Mar 2009 16:53:25 -0400 Subject: [SC-L] Politics, cybersecurity, and software Message-ID: hi sc-l, In our discipline we have been known to complain about developers who take little interest in the business context their code will exist in. I believe we're guilty of the "same thing" when it comes to politics, the government, and cybersecurity. Every once in a while, one of "us" comes along and gets involved in cybersecurity in Washington (you go amit), but we don't seem to stick. The latest casualty happened this week. http://www.technewsworld.com/story/Political-Turf-Wars-Drive-Out-US-Cybersecurity-Chief-66431.html As I say in the article above, I'd like to see the Obama administration take a leadership role in cutting through the interagency politics associated with cybersecurity. There's been a real paradigm shift in commercial software security in the past 10 years, but the government has not made as much progress as companies like Microsoft, Google EMC, and some of the major banks have (think BSIMM). What we need is an epiphany along the lines of former Microsoft CEO Bill Gates' "trustworthy computing" memo of January 2002. That was a leadership moment, and we need that for the country now. We also need somebody smart and knowledgeable to be appointed to carry out those activities. Speak up software security types, we have an opportunity to make a difference. gem http://www.cigital.com/~gem From coley at linus.mitre.org Wed Mar 18 16:21:56 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 18 Mar 2009 17:21:56 -0400 (EDT) Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: References: Message-ID: On Wed, 18 Mar 2009, Gary McGraw wrote: > "Both early phases of software security made use of any sort of argument > or 'evidence' to bolster the software security message, and that was > fine given the starting point. We had lots of examples, plenty of good > intuition, and the best of intentions. But now the time has come to put > away the bug parade boogeyman, the top 25 tea leaves, black box web app > goat sacrifice, and the occult reading of pen testing entrails. The time > for science is upon us." Given your critique of Top-N lists and bug parades in this paragraph and elsewhere, why is a "top N bugs list" explicitly identified in BSIMM CR1.1, and partially applicable in places like T1.1, T2.1, SFD2.1, SR1.4, and CR2.1? - Steve From gem at cigital.com Wed Mar 18 16:25:55 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 18 Mar 2009 17:25:55 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: Message-ID: Hi Steve, Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. You and I have discussed this many times. The generic top 25 is unlikely to apply to any particular organization. The notion of using that as a driver for software purchasing is insane. On the other hand if organization X knows what THEIR top 10 bugs are, that has real value. See the examples under that practice. gem On 3/18/09 5:21 PM, "Steven M. Christey" wrote: On Wed, 18 Mar 2009, Gary McGraw wrote: > "Both early phases of software security made use of any sort of argument > or 'evidence' to bolster the software security message, and that was > fine given the starting point. We had lots of examples, plenty of good > intuition, and the best of intentions. But now the time has come to put > away the bug parade boogeyman, the top 25 tea leaves, black box web app > goat sacrifice, and the occult reading of pen testing entrails. The time > for science is upon us." Given your critique of Top-N lists and bug parades in this paragraph and elsewhere, why is a "top N bugs list" explicitly identified in BSIMM CR1.1, and partially applicable in places like T1.1, T2.1, SFD2.1, SR1.4, and CR2.1? - Steve From coley at linus.mitre.org Wed Mar 18 16:47:22 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 18 Mar 2009 17:47:22 -0400 (EDT) Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: References: Message-ID: On Wed, 18 Mar 2009, Gary McGraw wrote: > Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. > You and I have discussed this many times. The generic top 25 is > unlikely to apply to any particular organization. The notion of using > that as a driver for software purchasing is insane. On the other hand > if organization X knows what THEIR top 10 bugs are, that has real value. Got it, thanks. I guessed as much. Did you investigate whether the developers' personal top-N lists were consistent with what their customers cared about? How did the developers go about selecting them? By the way, last week in my OWASP Software Assurance Day talk on the Top 25, I had a slide on the role of top-N lists in BSIMM, where I attempted to say basically the same thing. This was after various slides that tried to emphasize how the current Top 25 is both incomplete and not necessarily fully relevant to a particular organization's needs. So while the message may have been diluted during initial publication, it's being refined somewhat. - Steve From gem at cigital.com Wed Mar 18 16:54:34 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 18 Mar 2009 17:54:34 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: Message-ID: Hi Steve, Many of the top N lists we encountered were developed through the consistent use of static analysis tools. After looking at millions of lines of code (sometimes constantly), a ***real*** top N list of bugs emerges for an organization. Eradicating number one is an obvious priority. Training can help. New number one...lather, rinse, repeat. Other times (like say in the one case where the study participant did not believe in static analysis for religious reasons) things are a bit more flip (and thus suffer from the "no data" problem I like to complain about). I do not recall a case when the top N lists were driven by customers. Sorry I missed your talk at the SWA forum. I'll chalk that one up to NoVa traffic. gem http://www.cigital.com/~gem On 3/18/09 5:47 PM, "Steven M. Christey" wrote: On Wed, 18 Mar 2009, Gary McGraw wrote: > Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. > You and I have discussed this many times. The generic top 25 is > unlikely to apply to any particular organization. The notion of using > that as a driver for software purchasing is insane. On the other hand > if organization X knows what THEIR top 10 bugs are, that has real value. Got it, thanks. I guessed as much. Did you investigate whether the developers' personal top-N lists were consistent with what their customers cared about? How did the developers go about selecting them? By the way, last week in my OWASP Software Assurance Day talk on the Top 25, I had a slide on the role of top-N lists in BSIMM, where I attempted to say basically the same thing. This was after various slides that tried to emphasize how the current Top 25 is both incomplete and not necessarily fully relevant to a particular organization's needs. So while the message may have been diluted during initial publication, it's being refined somewhat. - Steve From coley at linus.mitre.org Wed Mar 18 17:14:03 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 18 Mar 2009 18:14:03 -0400 (EDT) Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: References: Message-ID: On Wed, 18 Mar 2009, Gary McGraw wrote: > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. Interesting. Does this mean that their top N lists are less likely to include design flaws? (though they would be covered under various other BSIMM activities). > After looking at millions of lines of code (sometimes constantly), a > ***real*** top N list of bugs emerges for an organization. Eradicating > number one is an obvious priority. Training can help. New number > one...lather, rinse, repeat. I believe this is reflected in public CVE data. Take a look at the bugs that are being reported for, say, Microsoft or major Linux vendors or most any product with a long history, and their current number 1's are not the same as the number 1's of the past. - Steve From Kevin.Wall at qwest.com Wed Mar 18 17:14:00 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Wed, 18 Mar 2009 17:14:00 -0500 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: References: Message-ID: Gary McGraw wrote: > We had a great time writing this one. Here is my favorite > paragraph (in the science versus alchemy vein): > "Both early phases of software security made use of any sort > of argument or 'evidence' to bolster the software security > message, and that was fine given the starting point. We had > lots of examples, plenty of good intuition, and the best of > intentions. But now the time has come to put away the bug > parade boogeyman, the top 25 tea leaves, black box web app > goat sacrifice, and the occult reading of pen testing > entrails. The time for science is upon us." I might agree with your quote of "The time for science is upon us." if it were not for the fact that the rest of computer science / engineeering is far ahead of computer security (IMO), and they are *still* not anywhere near real "science", at least as practiced as a whole. (There probably are pockets here and there.) For the most part, based on what I see in industry, I'm not even sure we have reached the alchemy stage! (Compare where most organizations are still at with respect to SEI's CMM. The average is probably Level 2. Most organizations no longer even think of CMM as relevant.) My observation is that very few people in the IT profession--outside of academia at least--belong to neither ACM or IEEE-CS or any other professional organization that might challenge them. I question, on a professional level, how much we are going to progress as an industry when most in this profession seem to think that they do not need anything beyond the "Learn X in 24 Hours" type pablum. (Those are fine as far as they go, but if you think that's all that's required to make you proficient in X, you have surely missed the boat.) Please note, however, that I do not think this mentality is limited to those in the IT / CS professions. Rather, it is a pandemic of this age. Anyhow, I'll shut up now, since this will surely take us OT if I persist. -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 From gem at cigital.com Wed Mar 18 16:26:32 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 18 Mar 2009 17:26:32 -0400 Subject: [SC-L] Silver Bullet: McGovern interviews McGraw Message-ID: hi sc-l, For the third anniversary (!) edition of Silver Bullet, that is episode 36, we do something different. James McGovern, OWASP maven, and Enterprise Architect for The Hartford Financial Services Group, interviews me. You may recall that James responded to the OWASP podcast posting here with a set of question he would have asked. Well, that got me thinking, and here you have it. James in charge. We talk about many aspects of software security, including: * BSIMM * the UML cloud of utter nonsense * outsourced/offshore software and security * a geographic analysis of software security maturity * the analysts (Gartner/Forrester) * whether the IDE will take over source code analysis * RATS and ITS4 * OWASP, SANS, education, and web app myopia * Microsoft * Metrics for software security * why PCI is utterly useless http://www.cigital.com/silverbullet/show-036/ As always, your feedback on the podcast is welcome. gem http://www.cigital.com/~gem From jeremy.j.epstein at gmail.com Wed Mar 18 16:29:19 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Wed, 18 Mar 2009 17:29:19 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs Message-ID: Colleagues, I'm pleased to announce the creation of LAMN, the Legion Against Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it - this group is for you. You can join LAMN on LinkedIn by searching in the "groups" area. Unlike so many other certifications, LAMN doesn't charge fees, require outrageously overpriced exams, or demand check-the-box continuing education. Hope to see many people joining this group - and feel free to pass this along! --Jeremy P.S. After you join the group, you can proudly write your name , LAMN - which conveniently also stands for Letters After My Name. I can't recall who suggested the term to me, but would be happy to give credit if someone wants to step forward and claim credit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090318/0d25e899/attachment.html From Stephan.Neuhaus at disi.unitn.it Thu Mar 19 03:42:45 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Thu, 19 Mar 2009 09:42:45 +0100 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: References: Message-ID: <4B8A6961-9984-4070-B1AD-952105E6C4FB@disi.unitn.it> On Mar 18, 2009, at 23:14, Steven M. Christey wrote: > I believe this is reflected in public CVE data. Take a look at the > bugs > that are being reported for, say, Microsoft or major Linux vendors > or most > any product with a long history, and their current number 1's are > not the > same as the number 1's of the past. I am trying to get funding for a study that would address precisely this issue. Here is a write-up that I made for the Master students here at the University of Trento that explains in more detail what I'm trying to do; perhaps someone on this list is interested in collaborating: http://www.disi.unitn.it/~neuhaus/proposals/Security-Trends.pdf Best, Stephan From jsteven at cigital.com Thu Mar 19 07:46:17 2009 From: jsteven at cigital.com (John Steven) Date: Thu, 19 Mar 2009 08:46:17 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: Message-ID: Steve, You saw my talk at the OWASP assurance day. There was a brief diversion about the number of "business logic" problems and "design flaws" (coarsely lumped together in my chart). That 'weight' should indicate that-at least in the subset of clients I deal with-flaws aren't getting short-shrift. http://www.owasp.org/images/9/9e/Maturing_Assessment_through_SA.ppt (for those who didn't see it) You may also want to look at my OWASP NoVA chapter presentation on "why" we believe Top N lists are bad... It's not so much a rant as it is a set of limitations in ONLY taking at Top N approach, and a set of constructive steps forward to improve one's practices: http://www.owasp.org/images/d/df/Moving_Beyond_Top_N_Lists.ppt.zip I cover how one should cause their own organization-specific Top N list to emerge and how to manage it once it does. ---- 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. On 3/18/09 6:14 PM, "Steven M. Christey" wrote: On Wed, 18 Mar 2009, Gary McGraw wrote: > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. Interesting. Does this mean that their top N lists are less likely to include design flaws? (though they would be covered under various other BSIMM activities). > After looking at millions of lines of code (sometimes constantly), a > ***real*** top N list of bugs emerges for an organization. Eradicating > number one is an obvious priority. Training can help. New number > one...lather, rinse, repeat. I believe this is reflected in public CVE data. Take a look at the bugs that are being reported for, say, Microsoft or major Linux vendors or most any product with a long history, and their current number 1's are not the same as the number 1's of the past. From gem at cigital.com Thu Mar 19 07:50:10 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 19 Mar 2009 08:50:10 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: Message-ID: Hi Steve, Sorry for falling off the thread last night. Waiting for the posts to clear was not a great idea. The top N lists we observed among the 9 were BUG lists only. So that means that in general at least half of the defects were not being identified on the "most wanted" list using that BSIMM set of activities. You are correct to point out that the "Architecture Analysis" practice has other activities meant to ferret out those sorts of flaws. I asked my guys to work on a flaws collection a while ago, but I have not seen anything yet. Canuck? There is an important difference between your CVE data which is based on externally observed bugs (imposed on vendors by security types mostly) and internal bug data determined using static analysis or internal testing. I would be very interested to know whether Microsoft and the CVE consider the same bug #1 on internal versus external rating systems. The difference is in the term "reported for" versus "discovered internally during SDL activity". gem http://www.cigital.com/~gem On 3/18/09 6:14 PM, "Steven M. Christey" wrote: On Wed, 18 Mar 2009, Gary McGraw wrote: > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. Interesting. Does this mean that their top N lists are less likely to include design flaws? (though they would be covered under various other BSIMM activities). > After looking at millions of lines of code (sometimes constantly), a > ***real*** top N list of bugs emerges for an organization. Eradicating > number one is an obvious priority. Training can help. New number > one...lather, rinse, repeat. I believe this is reflected in public CVE data. Take a look at the bugs that are being reported for, say, Microsoft or major Linux vendors or most any product with a long history, and their current number 1's are not the same as the number 1's of the past. - Steve From gem at cigital.com Thu Mar 19 07:58:48 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 19 Mar 2009 08:58:48 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: Message-ID: Hi Kevin, Any discipline with the word "science" in its name probably isn't. I have a dual PhD in two of those fields (computer science and cognitive science), so I ought to know. I mostly agree with your assessment of many industry coders and IT people (most of whom do NOT have a background in computer science). When someone is asked to whip up a solution to an NP-Hard problem and doesn't know not to work on that (or to approach it heuristically) , we have some real issues. There are a boatload of developers who have no computer science theory under their belts, and that is a real problem. And don't even get me started on security people! Fortunately all is not lost and there are many great people sharing knowledge as widely as possible too. I can assure you that during my term as one of the Governors of the Computer Society (the largest IEEE society), we spent plenty of cycles fretting about how to reverse the trend you noted. Not much progress was made. Note that Silver Bullet often interviews scientists, and is co-sponsored by IEEE Security & Privacy magazine. I am optimistic that we can keep things on an even scientific footing in software security if we proceed carefully and don't jump on shiny bandwagons as they careen over the cliff. The time for science is upon us. gem http://www.cigital.com/~gem On 3/18/09 6:14 PM, "Wall, Kevin" wrote: Gary McGraw wrote: > We had a great time writing this one. Here is my favorite > paragraph (in the science versus alchemy vein): > "Both early phases of software security made use of any sort > of argument or 'evidence' to bolster the software security > message, and that was fine given the starting point. We had > lots of examples, plenty of good intuition, and the best of > intentions. But now the time has come to put away the bug > parade boogeyman, the top 25 tea leaves, black box web app > goat sacrifice, and the occult reading of pen testing > entrails. The time for science is upon us." I might agree with your quote of "The time for science is upon us." if it were not for the fact that the rest of computer science / engineeering is far ahead of computer security (IMO), and they are *still* not anywhere near real "science", at least as practiced as a whole. (There probably are pockets here and there.) For the most part, based on what I see in industry, I'm not even sure we have reached the alchemy stage! (Compare where most organizations are still at with respect to SEI's CMM. The average is probably Level 2. Most organizations no longer even think of CMM as relevant.) My observation is that very few people in the IT profession--outside of academia at least--belong to neither ACM or IEEE-CS or any other professional organization that might challenge them. I question, on a professional level, how much we are going to progress as an industry when most in this profession seem to think that they do not need anything beyond the "Learn X in 24 Hours" type pablum. (Those are fine as far as they go, but if you think that's all that's required to make you proficient in X, you have surely missed the boat.) Please note, however, that I do not think this mentality is limited to those in the IT / CS professions. Rather, it is a pandemic of this age. Anyhow, I'll shut up now, since this will surely take us OT if I persist. -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 From secureCoding2dave at davearonson.com Thu Mar 19 09:14:14 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Thu, 19 Mar 2009 10:14:14 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: References: Message-ID: <3f4922c70903190714o73c14f1cgedb505b52b76d0ca@mail.gmail.com> Jeremy Epstein wrote: > I'm pleased to announce the creation of LAMN, the Legion Against Meaningless > certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO - and > you're proud of it - this group is for you. Heh. I'm going to be giving a speech today in which I mention "PMPs, CISSPs, MCSEs, MDs, JDs, DDSes, and other assorted CAS -- that's Certified Alphabet Soup". -Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From list-spam at secureconsulting.net Thu Mar 19 10:14:46 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Thu, 19 Mar 2009 11:14:46 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: References: Message-ID: <49C26166.9050100@secureconsulting.net> gee whiz, what if you have letters after your name that aren't meaningless certifications (like MS or PhD)? :) also, what if you have meaningless cert letters after your name, but only because of peer pressure? are we still allowed to join? :) Jeremy Epstein wrote: > Colleagues, > > I'm pleased to announce the creation of LAMN, the Legion Against > Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or > EIEIO - and you're proud of it - this group is for you. > > You can join LAMN on LinkedIn by searching in the "groups" area. Unlike > so many other certifications, LAMN doesn't charge fees, require > outrageously overpriced exams, or demand check-the-box continuing education. > > Hope to see many people joining this group - and feel free to pass this > along! > --Jeremy > > P.S. After you join the group, you can proudly write your name Doe>, LAMN - which conveniently also stands for Letters After My Name. > I can't recall who suggested the term to me, but would be happy to give > credit if someone wants to step forward and claim credit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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. > _______________________________________________ -- 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: ] "Dusting is a good example of the futility of trying to put things right. As soon as you dust, the fact of your next dusting has already been established." George Carlin From jeremy.j.epstein at gmail.com Thu Mar 19 10:20:08 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Thu, 19 Mar 2009 11:20:08 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: <49C26166.9050100@secureconsulting.net> References: <49C26166.9050100@secureconsulting.net> Message-ID: On Thu, Mar 19, 2009 at 11:14 AM, Benjamin Tomhave < list-spam at secureconsulting.net> wrote: > gee whiz, what if you have letters after your name that aren't > meaningless certifications (like MS or PhD)? :) > Paragraph 13.4 subsection (B)(iv) of the LAMN bylaws allows earned degrees, but only if you had to take at least one really boneheaded class. You get to define boneheaded. > also, what if you have meaningless cert letters after your name, but > only because of peer pressure? are we still allowed to join? :) > That's between you and the deity or non-deity of your choice :-) --Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090319/47595f91/attachment-0001.html From gem at cigital.com Thu Mar 19 10:27:57 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 19 Mar 2009 11:27:57 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: <4B8A6961-9984-4070-B1AD-952105E6C4FB@disi.unitn.it> Message-ID: Hi Stephan, In my view, it would be even better to study the difference in external bug emphasis (as driven by full disclosure and the CVE) and internal bug emphasis (as driven by an organization's own top N list). Once again, this is a difference in emphasis you might put as "reactive" versus "proactive." I think we all agree a proactive solution to software security is most effective from a cost perspective. We also know from experience that external pressure is sometimes necessary to cause change. To put a slightly finer point on it, I wonder whether the "scatter" you can observe outside of the black box looks completely different than the in-the-box view. In this case, an organizations codebase and dev shop is "the box" and the external bug reports are outside. I have a feeling that is it. Trento has a special place in my heart as I lived there from 8/93-8/94 and worked at IRST. Say hi to Cognola for me. gem http://www.cigital.com/~gem On 3/19/09 4:42 AM, "Stephan Neuhaus" wrote: On Mar 18, 2009, at 23:14, Steven M. Christey wrote: > I believe this is reflected in public CVE data. Take a look at the > bugs > that are being reported for, say, Microsoft or major Linux vendors > or most > any product with a long history, and their current number 1's are > not the > same as the number 1's of the past. I am trying to get funding for a study that would address precisely this issue. Here is a write-up that I made for the Master students here at the University of Trento that explains in more detail what I'm trying to do; perhaps someone on this list is interested in collaborating: http://www.disi.unitn.it/~neuhaus/proposals/Security-Trends.pdf Best, Stephan From Stephan.Neuhaus at disi.unitn.it Thu Mar 19 10:53:00 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Thu, 19 Mar 2009 16:53:00 +0100 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: References: Message-ID: <814EA552-792A-4CDC-B6B7-028CEDCF3C9E@disi.unitn.it> Hi Gary, On Mar 19, 2009, at 16:27, Gary McGraw wrote: > Hi Stephan, > > In my view, it would be even better to study the difference in > external bug emphasis (as driven by full disclosure and the CVE) and > internal bug emphasis (as driven by an organization's own top N list). That is a brilliant idea, but how do I get "internal bug emphasis"? The companies in question won't hand over their data just like that. Perhaps a little prodding from someone who is well known and trusted could help here, Mr McGraw, Sir. :-) (Actually, I might get at Microsoft data, if I can make the right pitch.) > To put a slightly finer point on it, I wonder whether the "scatter" > you can observe outside of the black box looks completely different > than the in-the-box view. In this case, an organizations codebase > and dev shop is "the box" and the external bug reports are outside. > I have a feeling that is it. Oh that's a very interesting question. As I said, it's a brilliant idea, and I'd love to see this carried out. > Trento has a special place in my heart as I lived there from > 8/93-8/94 and worked at IRST. That is very cool! Also, you are lucky that you worked at IRST then, because the CS department is constructing a new building that will completely ruin the view across the valley from IRST. I don't think they like us much over there :-) > Say hi to Cognola for me. Will do, even though I live in Povo myself.[1] Fun, Stephan [1] I was told by one of the professors that before the University came here, Povo was the place "where the weird mountain people live". That would hold double for the people who live across the Fersina, for example in Cognola :-) From gem at cigital.com Thu Mar 19 14:00:03 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 19 Mar 2009 15:00:03 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: <30F220C0C89E492E8DE0683BB09D9EB8@workhorse> Message-ID: Aloha Jim, I agree that security bugs should not necessarily take precedence over other bugs. Most of the initiatives that we observed cycled ALL security bugs into the standard bug tracking system (most of which rank bugs by some kind of severity rating). Many initiatives put more weight on security bugs...note the term "weight" not "drop everything and run around only working on security." See the CMVM practice activities for more. The BSIMM helps to measure and then evolve a software security initiative. The top N security bugs activity is one of an arsenal of tools built and used by the SSG to strategically guide the rest of their software security initiative. Making this a "top N bugs of any kind" list might make sense for some organizations, but is not something we would likely observe by studying the SSG and the software security initiative. Perhaps we suffer from the "looking for the keys under the streetlight" problem. gem On 3/19/09 2:31 PM, "Jim Manico" wrote: > The top N lists we observed among the 9 were BUG lists only. So that > means that in general at least half of the defects were not being > identified on the "most wanted" list using that BSIMM set of activities. This sounds very problematic to me. There are many standard software bugs that are much more critical to the enterprise than just security bugs. It seems foolhardy to do risk assessment on security bugs only - I think we need to bring the worlds of software development and security analysis together more. Divided we (continue to) fail. And Gary, this is not a critique of just your comment, but of WebAppSec at large. - Jim ----- Original Message ----- From: "Gary McGraw" To: "Steven M. Christey" Cc: "Sammy Migues" ; "Michael Cohen" ; "Dustin Sullivan" ; "Secure Code Mailing List" Sent: Thursday, March 19, 2009 2:50 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) > Hi Steve, > > Sorry for falling off the thread last night. Waiting for the posts to > clear was not a great idea. > > The top N lists we observed among the 9 were BUG lists only. So that > means that in general at least half of the defects were not being > identified on the "most wanted" list using that BSIMM set of activities. > You are correct to point out that the "Architecture Analysis" practice has > other activities meant to ferret out those sorts of flaws. > > I asked my guys to work on a flaws collection a while ago, but I have not > seen anything yet. Canuck? > > There is an important difference between your CVE data which is based on > externally observed bugs (imposed on vendors by security types mostly) and > internal bug data determined using static analysis or internal testing. I > would be very interested to know whether Microsoft and the CVE consider > the same bug #1 on internal versus external rating systems. The > difference is in the term "reported for" versus "discovered internally > during SDL activity". > > gem > > http://www.cigital.com/~gem > > > On 3/18/09 6:14 PM, "Steven M. Christey" wrote: > > > > On Wed, 18 Mar 2009, Gary McGraw wrote: > >> Many of the top N lists we encountered were developed through the >> consistent use of static analysis tools. > > Interesting. Does this mean that their top N lists are less likely to > include design flaws? (though they would be covered under various other > BSIMM activities). > >> After looking at millions of lines of code (sometimes constantly), a >> ***real*** top N list of bugs emerges for an organization. Eradicating >> number one is an obvious priority. Training can help. New number >> one...lather, rinse, repeat. > > I believe this is reflected in public CVE data. Take a look at the bugs > that are being reported for, say, Microsoft or major Linux vendors or most > any product with a long history, and their current number 1's are not the > same as the number 1's of the past. > > - 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 jim at manico.net Thu Mar 19 13:31:09 2009 From: jim at manico.net (Jim Manico) Date: Thu, 19 Mar 2009 08:31:09 -1000 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) References: Message-ID: <30F220C0C89E492E8DE0683BB09D9EB8@workhorse> > The top N lists we observed among the 9 were BUG lists only. So that > means that in general at least half of the defects were not being > identified on the "most wanted" list using that BSIMM set of activities. This sounds very problematic to me. There are many standard software bugs that are much more critical to the enterprise than just security bugs. It seems foolhardy to do risk assessment on security bugs only - I think we need to bring the worlds of software development and security analysis together more. Divided we (continue to) fail. And Gary, this is not a critique of just your comment, but of WebAppSec at large. - Jim ----- Original Message ----- From: "Gary McGraw" To: "Steven M. Christey" Cc: "Sammy Migues" ; "Michael Cohen" ; "Dustin Sullivan" ; "Secure Code Mailing List" Sent: Thursday, March 19, 2009 2:50 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) > Hi Steve, > > Sorry for falling off the thread last night. Waiting for the posts to > clear was not a great idea. > > The top N lists we observed among the 9 were BUG lists only. So that > means that in general at least half of the defects were not being > identified on the "most wanted" list using that BSIMM set of activities. > You are correct to point out that the "Architecture Analysis" practice has > other activities meant to ferret out those sorts of flaws. > > I asked my guys to work on a flaws collection a while ago, but I have not > seen anything yet. Canuck? > > There is an important difference between your CVE data which is based on > externally observed bugs (imposed on vendors by security types mostly) and > internal bug data determined using static analysis or internal testing. I > would be very interested to know whether Microsoft and the CVE consider > the same bug #1 on internal versus external rating systems. The > difference is in the term "reported for" versus "discovered internally > during SDL activity". > > gem > > http://www.cigital.com/~gem > > > On 3/18/09 6:14 PM, "Steven M. Christey" wrote: > > > > On Wed, 18 Mar 2009, Gary McGraw wrote: > >> Many of the top N lists we encountered were developed through the >> consistent use of static analysis tools. > > Interesting. Does this mean that their top N lists are less likely to > include design flaws? (though they would be covered under various other > BSIMM activities). > >> After looking at millions of lines of code (sometimes constantly), a >> ***real*** top N list of bugs emerges for an organization. Eradicating >> number one is an obvious priority. Training can help. New number >> one...lather, rinse, repeat. > > I believe this is reflected in public CVE data. Take a look at the bugs > that are being reported for, say, Microsoft or major Linux vendors or most > any product with a long history, and their current number 1's are not the > same as the number 1's of the past. > > - 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 jim at manico.net Thu Mar 19 13:58:44 2009 From: jim at manico.net (Jim Manico) Date: Thu, 19 Mar 2009 08:58:44 -1000 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) References: Message-ID: > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. After looking at millions of > lines of code (sometimes constantly), a ***real*** top N list of bugs > emerges for an organization. You mean a "real list of what a certain vendors static analysis tools find". If you think that list really measures the risk of an organizations software security posture - that might ne considered to be insane! =) - Jim ----- Original Message ----- From: "Gary McGraw" To: "Steven M. Christey" Cc: "Sammy Migues" ; "Dustin Sullivan" ; "Secure Code Mailing List" Sent: Wednesday, March 18, 2009 11:54 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) > Hi Steve, > > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. After looking at millions of > lines of code (sometimes constantly), a ***real*** top N list of bugs > emerges for an organization. Eradicating number one is an obvious > priority. Training can help. New number one...lather, rinse, repeat. > > Other times (like say in the one case where the study participant did not > believe in static analysis for religious reasons) things are a bit more > flip (and thus suffer from the "no data" problem I like to complain > about). I do not recall a case when the top N lists were driven by > customers. > > Sorry I missed your talk at the SWA forum. I'll chalk that one up to NoVa > traffic. > > gem > > http://www.cigital.com/~gem > > > On 3/18/09 5:47 PM, "Steven M. Christey" wrote: > > > > On Wed, 18 Mar 2009, Gary McGraw wrote: > >> Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. >> You and I have discussed this many times. The generic top 25 is >> unlikely to apply to any particular organization. The notion of using >> that as a driver for software purchasing is insane. On the other hand >> if organization X knows what THEIR top 10 bugs are, that has real value. > > Got it, thanks. I guessed as much. Did you investigate whether the > developers' personal top-N lists were consistent with what their customers > cared about? How did the developers go about selecting them? > > By the way, last week in my OWASP Software Assurance Day talk on the Top > 25, I had a slide on the role of top-N lists in BSIMM, where I attempted > to say basically the same thing. This was after various slides that tried > to emphasize how the current Top 25 is both incomplete and not necessarily > fully relevant to a particular organization's needs. So while the message > may have been diluted during initial publication, it's being refined > somewhat. > > - 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 gem at cigital.com Thu Mar 19 14:04:49 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 19 Mar 2009 15:04:49 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: Message-ID: Actually no. See: http://www.cigital.com/papers/download/j15bsi.pdf (John Steven, State of Application Assessment, IEEE S&P) I am not a tool guy, I am a software security guy. gem http://www.cigital.com/~gem On 3/19/09 2:58 PM, "Jim Manico" wrote: > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. After looking at millions of > lines of code (sometimes constantly), a ***real*** top N list of bugs > emerges for an organization. You mean a "real list of what a certain vendors static analysis tools find". If you think that list really measures the risk of an organizations software security posture - that might ne considered to be insane! =) - Jim ----- Original Message ----- From: "Gary McGraw" To: "Steven M. Christey" Cc: "Sammy Migues" ; "Dustin Sullivan" ; "Secure Code Mailing List" Sent: Wednesday, March 18, 2009 11:54 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) > Hi Steve, > > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. After looking at millions of > lines of code (sometimes constantly), a ***real*** top N list of bugs > emerges for an organization. Eradicating number one is an obvious > priority. Training can help. New number one...lather, rinse, repeat. > > Other times (like say in the one case where the study participant did not > believe in static analysis for religious reasons) things are a bit more > flip (and thus suffer from the "no data" problem I like to complain > about). I do not recall a case when the top N lists were driven by > customers. > > Sorry I missed your talk at the SWA forum. I'll chalk that one up to NoVa > traffic. > > gem > > http://www.cigital.com/~gem > > > On 3/18/09 5:47 PM, "Steven M. Christey" wrote: > > > > On Wed, 18 Mar 2009, Gary McGraw wrote: > >> Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. >> You and I have discussed this many times. The generic top 25 is >> unlikely to apply to any particular organization. The notion of using >> that as a driver for software purchasing is insane. On the other hand >> if organization X knows what THEIR top 10 bugs are, that has real value. > > Got it, thanks. I guessed as much. Did you investigate whether the > developers' personal top-N lists were consistent with what their customers > cared about? How did the developers go about selecting them? > > By the way, last week in my OWASP Software Assurance Day talk on the Top > 25, I had a slide on the role of top-N lists in BSIMM, where I attempted > to say basically the same thing. This was after various slides that tried > to emphasize how the current Top 25 is both incomplete and not necessarily > fully relevant to a particular organization's needs. So while the message > may have been diluted during initial publication, it's being refined > somewhat. > > - 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 jim at manico.net Thu Mar 19 14:11:28 2009 From: jim at manico.net (Jim Manico) Date: Thu, 19 Mar 2009 09:11:28 -1000 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) References: Message-ID: <6F7E441B43674F62AE366079F550157B@workhorse> That's a bit of dodging the question, I'd like to hear more. You comment below implied that it was your consistent use of vendor-based static analyis tool that allowed you to figure out top N list of bugs for a specific organization. "Leading with static analysis" as your primary analysis driver concearns me. Will you elaborate, please? - Jim ----- Original Message ----- From: "Gary McGraw" To: "Jim Manico" ; "Steven M. Christey" Cc: "Sammy Migues" ; "Dustin Sullivan" ; "Secure Code Mailing List" Sent: Thursday, March 19, 2009 9:04 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) Actually no. See: http://www.cigital.com/papers/download/j15bsi.pdf (John Steven, State of Application Assessment, IEEE S&P) I am not a tool guy, I am a software security guy. gem http://www.cigital.com/~gem On 3/19/09 2:58 PM, "Jim Manico" wrote: > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. After looking at millions of > lines of code (sometimes constantly), a ***real*** top N list of bugs > emerges for an organization. You mean a "real list of what a certain vendors static analysis tools find". If you think that list really measures the risk of an organizations software security posture - that might ne considered to be insane! =) - Jim ----- Original Message ----- From: "Gary McGraw" To: "Steven M. Christey" Cc: "Sammy Migues" ; "Dustin Sullivan" ; "Secure Code Mailing List" Sent: Wednesday, March 18, 2009 11:54 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) > Hi Steve, > > Many of the top N lists we encountered were developed through the > consistent use of static analysis tools. After looking at millions of > lines of code (sometimes constantly), a ***real*** top N list of bugs > emerges for an organization. Eradicating number one is an obvious > priority. Training can help. New number one...lather, rinse, repeat. > > Other times (like say in the one case where the study participant did not > believe in static analysis for religious reasons) things are a bit more > flip (and thus suffer from the "no data" problem I like to complain > about). I do not recall a case when the top N lists were driven by > customers. > > Sorry I missed your talk at the SWA forum. I'll chalk that one up to NoVa > traffic. > > gem > > http://www.cigital.com/~gem > > > On 3/18/09 5:47 PM, "Steven M. Christey" wrote: > > > > On Wed, 18 Mar 2009, Gary McGraw wrote: > >> Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. >> You and I have discussed this many times. The generic top 25 is >> unlikely to apply to any particular organization. The notion of using >> that as a driver for software purchasing is insane. On the other hand >> if organization X knows what THEIR top 10 bugs are, that has real value. > > Got it, thanks. I guessed as much. Did you investigate whether the > developers' personal top-N lists were consistent with what their customers > cared about? How did the developers go about selecting them? > > By the way, last week in my OWASP Software Assurance Day talk on the Top > 25, I had a slide on the role of top-N lists in BSIMM, where I attempted > to say basically the same thing. This was after various slides that tried > to emphasize how the current Top 25 is both incomplete and not necessarily > fully relevant to a particular organization's needs. So while the message > may have been diluted during initial publication, it's being refined > somewhat. > > - 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 Thu Mar 19 18:28:09 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Thu, 19 Mar 2009 19:28:09 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: References: Message-ID: <49C2D509.9030600@secureconsulting.net> Why are we differentiating between "software" and "security" bugs? It seems to me that all bugs are software bugs, and how quickly they're tackled is a matter of prioritizing the work based on severity, impact, and ease of resolution. It seems to me that, while it is problematic that security testing has been excluded historically, our goal should not be to establish yet another security-as-bolt-on state, but rather leapfrog to the desired end-state where QA testing includes security testing as well as functional testing. In fact, one could even argue that security testing IS functional testing, but anyway... If you're going to innovate, you must as well jump the curve*. -ben * see Kawasaki "Art of Innovation" http://blog.guykawasaki.com/2007/06/art_of_innovati.html Gary McGraw wrote: > Aloha Jim, > > I agree that security bugs should not necessarily take precedence > over other bugs. Most of the initiatives that we observed cycled ALL > security bugs into the standard bug tracking system (most of which > rank bugs by some kind of severity rating). Many initiatives put > more weight on security bugs...note the term "weight" not "drop > everything and run around only working on security." See the CMVM > practice activities for more. > > The BSIMM helps to measure and then evolve a software security > initiative. The top N security bugs activity is one of an arsenal of > tools built and used by the SSG to strategically guide the rest of > their software security initiative. Making this a "top N bugs of any > kind" list might make sense for some organizations, but is not > something we would likely observe by studying the SSG and the > software security initiative. Perhaps we suffer from the "looking > for the keys under the streetlight" problem. > > gem > > > On 3/19/09 2:31 PM, "Jim Manico" wrote: > >> The top N lists we observed among the 9 were BUG lists only. So >> that means that in general at least half of the defects were not >> being identified on the "most wanted" list using that BSIMM set of >> activities. > > This sounds very problematic to me. There are many standard software > bugs that are much more critical to the enterprise than just security > bugs. It seems foolhardy to do risk assessment on security bugs only > - I think we need to bring the worlds of software development and > security analysis together more. Divided we (continue to) fail. > > And Gary, this is not a critique of just your comment, but of > WebAppSec at large. > > - Jim > > > ----- Original Message ----- From: "Gary McGraw" > To: "Steven M. Christey" Cc: "Sammy Migues" > ; "Michael Cohen" ; "Dustin > Sullivan" ; "Secure Code Mailing List" > Sent: Thursday, March 19, 2009 2:50 AM > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security > Alchemist (informIT) > > >> Hi Steve, >> >> Sorry for falling off the thread last night. Waiting for the posts >> to clear was not a great idea. >> >> The top N lists we observed among the 9 were BUG lists only. So >> that means that in general at least half of the defects were not >> being identified on the "most wanted" list using that BSIMM set of >> activities. You are correct to point out that the "Architecture >> Analysis" practice has other activities meant to ferret out those >> sorts of flaws. >> >> I asked my guys to work on a flaws collection a while ago, but I >> have not seen anything yet. Canuck? >> >> There is an important difference between your CVE data which is >> based on externally observed bugs (imposed on vendors by security >> types mostly) and internal bug data determined using static >> analysis or internal testing. I would be very interested to know >> whether Microsoft and the CVE consider the same bug #1 on internal >> versus external rating systems. The difference is in the term >> "reported for" versus "discovered internally during SDL activity". >> >> gem >> >> http://www.cigital.com/~gem >> >> >> On 3/18/09 6:14 PM, "Steven M. Christey" >> wrote: >> >> >> >> On Wed, 18 Mar 2009, Gary McGraw wrote: >> >>> Many of the top N lists we encountered were developed through the >>> consistent use of static analysis tools. >> Interesting. Does this mean that their top N lists are less likely >> to include design flaws? (though they would be covered under >> various other BSIMM activities). >> >>> After looking at millions of lines of code (sometimes >>> constantly), a ***real*** top N list of bugs emerges for an >>> organization. Eradicating number one is an obvious priority. >>> Training can help. New number one...lather, rinse, repeat. >> I believe this is reflected in public CVE data. Take a look at the >> bugs that are being reported for, say, Microsoft or major Linux >> vendors or most any product with a long history, and their current >> number 1's are not the same as the number 1's of the past. >> >> - 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. > _______________________________________________ > > -- 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: ] "Concern for man and his fate must always form the chief interest of all technical endeavors. Never forget this in the midst of your diagrams and equations." Albert Einstein From Paco at cigital.com Thu Mar 19 10:36:45 2009 From: Paco at cigital.com (Paco Hope) Date: Thu, 19 Mar 2009 11:36:45 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: Message-ID: On 3/18/09 5:29 PM, "Jeremy Epstein" wrote: > If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it ...then I'd say you have an overly simplistic view of the world. Anyone who believes that a credential automatically conveys some magical knowledge that you didn't have before is just as overly-simplistic as someone who disparages all credentials equally. It just isn't a black and white world. Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ ? +1.703.585.7868 Software Confidence. Achieved. From goertzel_karen at bah.com Thu Mar 19 11:04:01 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Thu, 19 Mar 2009 12:04:01 -0400 Subject: [SC-L] Announcing LAMN: Legion Against MeaninglesscertificatioNs References: <3f4922c70903190714o73c14f1cgedb505b52b76d0ca@mail.gmail.com> Message-ID: <184D5FFC5203644FB4F8864B0EE445B401F4ABA3@MCLNEXVS06.resource.ds.bah.com> The one I've decided to forego is the new ISC(2) CSSLP. Anyone who believes alphabet soup says more about one's qualifications than one's resume and list of publications is not someone I particularly want to spend time convincing of my competence regardless. I am highly sceptical of those who take special training, study, or do anything extraordinary other than "on the job" to prepare for professional certification exams. To me these exams should demonstrate one's actual competence and knowledge gained doing work in the field being tested; they should not merely demonstrate one's abilities to cram for an exam. The reason I have the CISSP is that my job requires it. Besides, for me the level of effort to pass the exam was negligible. Had it not been - i.e., had nearly 10 years specifying and architecting cross domain solutions and high assurance operating systems, and doing risk analyses and COOPs NOT prepared me to pass the exam in just over two hours without any additional study - I really would have felt I had no business calling myself a professional in the field. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of SC-L Reader Dave Aronson Sent: Thu 19-Mar-09 10:14 To: Secure Coding Subject: Re: [SC-L] Announcing LAMN: Legion Against MeaninglesscertificatioNs Jeremy Epstein wrote: > I'm pleased to announce the creation of LAMN, the Legion Against Meaningless > certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO - and > you're proud of it - this group is for you. Heh. I'm going to be giving a speech today in which I mention "PMPs, CISSPs, MCSEs, MDs, JDs, DDSes, and other assorted CAS -- that's Certified Alphabet Soup". -Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web _______________________________________________ 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/20090319/f2ad39cd/attachment.html From tomb at owasp.org Thu Mar 19 11:18:01 2009 From: tomb at owasp.org (Tom Brennan - OWASP) Date: Thu, 19 Mar 2009 16:18:01 +0000 Subject: [SC-L] Announcing LAMN: Legion Against MeaninglesscertificatioNs In-Reply-To: <49C26166.9050100@secureconsulting.net> References: <49C26166.9050100@secureconsulting.net> Message-ID: <1667989489-1237479491-cardhu_decombobulator_blackberry.rim.net-575634504-@bxe1156.bisx.prod.on.blackberry> You get a 5 year of www.scanlesspci.com -----Original Message----- From: Benjamin Tomhave Date: Thu, 19 Mar 2009 11:14:46 To: Jeremy Epstein Cc: Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs gee whiz, what if you have letters after your name that aren't meaningless certifications (like MS or PhD)? :) also, what if you have meaningless cert letters after your name, but only because of peer pressure? are we still allowed to join? :) Jeremy Epstein wrote: > Colleagues, > > I'm pleased to announce the creation of LAMN, the Legion Against > Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or > EIEIO - and you're proud of it - this group is for you. > > You can join LAMN on LinkedIn by searching in the "groups" area. Unlike > so many other certifications, LAMN doesn't charge fees, require > outrageously overpriced exams, or demand check-the-box continuing education. > > Hope to see many people joining this group - and feel free to pass this > along! > --Jeremy > > P.S. After you join the group, you can proudly write your name Doe>, LAMN - which conveniently also stands for Letters After My Name. > I can't recall who suggested the term to me, but would be happy to give > credit if someone wants to step forward and claim credit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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. > _______________________________________________ -- 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: ] "Dusting is a good example of the futility of trying to put things right. As soon as you dust, the fact of your next dusting has already been established." George Carlin _______________________________________________ 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 kowsik at gmail.com Thu Mar 19 20:05:58 2009 From: kowsik at gmail.com (kowsik) Date: Thu, 19 Mar 2009 18:05:58 -0700 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: <49C2D509.9030600@secureconsulting.net> References: <49C2D509.9030600@secureconsulting.net> Message-ID: <7db9abd30903191805v61ab1fd3g26cc61045a7ec6af@mail.gmail.com> I have to post this blog in response. http://labs.mudynamics.com/2008/07/14/zen-and-the-art-of-fixing-p1-bugs Love the "security testing IS functional testing", BTW. K. --- http://www.pcapr.net On Thu, Mar 19, 2009 at 4:28 PM, Benjamin Tomhave wrote: > Why are we differentiating between "software" and "security" bugs? It > seems to me that all bugs are software bugs, and how quickly they're > tackled is a matter of prioritizing the work based on severity, impact, > and ease of resolution. It seems to me that, while it is problematic > that security testing has been excluded historically, our goal should > not be to establish yet another security-as-bolt-on state, but rather > leapfrog to the desired end-state where QA testing includes security > testing as well as functional testing. In fact, one could even argue > that security testing IS functional testing, but anyway... > > If you're going to innovate, you must as well jump the curve*. > > -ben > > * see Kawasaki "Art of Innovation" > http://blog.guykawasaki.com/2007/06/art_of_innovati.html > > Gary McGraw wrote: >> Aloha Jim, >> >> I agree that security bugs should not necessarily take precedence >> over other bugs. ?Most of the initiatives that we observed cycled ALL >> security bugs into the standard bug tracking system (most of which >> rank bugs by some kind of severity rating). ?Many initiatives put >> more weight on security bugs...note the term "weight" not "drop >> everything and run around only working on security." ?See the CMVM >> practice activities for more. >> >> The BSIMM helps to measure and then evolve a software security >> initiative. ?The top N security bugs activity is one of an arsenal of >> tools built and used by the SSG to strategically guide the rest of >> their software security initiative. ?Making this a "top N bugs of any >> kind" list might make sense for some organizations, but is not >> something we would likely observe by studying the SSG and the >> software security initiative. ?Perhaps we suffer from the "looking >> for the keys under the streetlight" problem. >> >> gem >> >> >> On 3/19/09 2:31 PM, "Jim Manico" wrote: >> >>> The top N lists we observed among the 9 were BUG lists only. ?So >>> that means that in general at least half of the defects were not >>> being identified on the "most wanted" list using that BSIMM set of >>> activities. >> >> This sounds very problematic to me. There are many standard software >> bugs that are much more critical to the enterprise than just security >> bugs. It seems foolhardy to do risk assessment on security bugs only >> - I think we need to bring the worlds of software development and >> security analysis together more. Divided we (continue to) fail. >> >> And Gary, this is not a critique of just your comment, but of >> WebAppSec at large. >> >> - Jim >> >> >> ----- Original Message ----- From: "Gary McGraw" >> To: "Steven M. Christey" Cc: "Sammy Migues" >> ; "Michael Cohen" ; "Dustin >> Sullivan" ; "Secure Code Mailing List" >> Sent: Thursday, March 19, 2009 2:50 AM >> Subject: Re: [SC-L] BSIMM: Confessions of a Software Security >> Alchemist (informIT) >> >> >>> Hi Steve, >>> >>> Sorry for falling off the thread last night. ?Waiting for the posts >>> to clear was not a great idea. >>> >>> The top N lists we observed among the 9 were BUG lists only. ?So >>> that means that in general at least half of the defects were not >>> being identified on the "most wanted" list using that BSIMM set of >>> activities. You are correct to point out that the "Architecture >>> Analysis" practice has other activities meant to ferret out those >>> sorts of flaws. >>> >>> I asked my guys to work on a flaws collection a while ago, but I >>> have not seen anything yet. ?Canuck? >>> >>> There is an important difference between your CVE data which is >>> based on externally observed bugs (imposed on vendors by security >>> types mostly) and internal bug data determined using static >>> analysis or internal testing. ?I would be very interested to know >>> whether Microsoft and the CVE consider the same bug #1 on internal >>> versus external rating systems. ?The difference is in the term >>> "reported for" versus "discovered internally during SDL activity". >>> >>> gem >>> >>> http://www.cigital.com/~gem >>> >>> >>> On 3/18/09 6:14 PM, "Steven M. Christey" >>> wrote: >>> >>> >>> >>> On Wed, 18 Mar 2009, Gary McGraw wrote: >>> >>>> Many of the top N lists we encountered were developed through the >>>> ?consistent use of static analysis tools. >>> Interesting. ?Does this mean that their top N lists are less likely >>> to include design flaws? ?(though they would be covered under >>> various other BSIMM activities). >>> >>>> After looking at millions of lines of code (sometimes >>>> constantly), a ***real*** top N list of bugs emerges for an >>>> organization. ?Eradicating number one is an obvious priority. >>>> Training can help. ?New number one...lather, rinse, repeat. >>> I believe this is reflected in public CVE data. ?Take a look at the >>> bugs that are being reported for, say, Microsoft or major Linux >>> vendors or most any product with a long history, and their current >>> number 1's are not the same as the number 1's of the past. >>> >>> - 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. >> _______________________________________________ >> >> > > -- > 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: ] > "Concern for man and his fate must always form the chief interest of all > technical endeavors. Never forget this in the midst of your diagrams and > equations." > Albert Einstein > _______________________________________________ > 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 secureCoding2dave at davearonson.com Fri Mar 20 08:59:55 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Fri, 20 Mar 2009 09:59:55 -0400 Subject: [SC-L] more relevant certifications Message-ID: <3f4922c70903200659t6f862db3o6a81f16d2e6ef562@mail.gmail.com> Paco Hope wrote: > just as overly-simplistic as > someone who disparages all credentials equally. On that note... my company (BAE Systems) has been pushing for people to become CISSPs, because in turn the main client (US gov) has been pushing for contractors to have a bunch of CISSPs on the projects. But, it seems as though that cert is very heavily loaded down with things that front-line grunts like me will NEVER use. I doubt I'll ever get to decide where a data center is located, let alone the entire building, nor what kind of fire detection/suppression or physical security systems it has, and I can probably forget about dictating HR policy as well. So, I was considering other certs, that seem much more relevant. The main relevant one I've heard of is the GSSP (GIAC Secure Software Programmer). 1) What do y'all think of that one? 2) It looked to me as though, other than perhaps from buying books, there is one and only one GSSP practice exam, and it can be taken only once. Am I wrong? Do you know of any others available for free, preferably to be taken online? 3) Have you heard of any other certs relevant for those of us who mainly design and implement computer-based systems, which will usually undergo security scrutiny, and usually have little to no say about all the other stuff around it? (Preferably not technology-specific, as opposed to for example a "Secure Java" or "Secure Web-Apps" cert.) Compare and contrast, as the teachers would say.... Thanks, Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From goertzel_karen at bah.com Fri Mar 20 09:06:46 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 20 Mar 2009 10:06:46 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) References: <49C2D509.9030600@secureconsulting.net> Message-ID: <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between "software" and "security" bugs? It seems to me that all bugs are software bugs, ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090320/25d2b12d/attachment.html From list-spam at secureconsulting.net Fri Mar 20 10:04:53 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Fri, 20 Mar 2009 11:04:53 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> References: <49C2D509.9030600@secureconsulting.net> <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> Message-ID: <49C3B095.1030002@secureconsulting.net> So, what you're saying is that "security bugs" are really design flaws, assuming a perfect implementation of the design. Ergo, security bug is at best a misnomer, and at worst a fatal deficiency in design acumen. :) -ben Goertzel, Karen [USA] wrote: > Except when they're hardware bugs. :) > > I think the differentiation is also meaningful in this regard: I can > specify software that does non-secure things. I can implement that > software 100% correctly. Ipso facto - no software bugs. But the fact > remains that the software doesn't validate input because I didn't > specify it to validate input, or it doesn't encrypt passwords because I > didn't specify it to do so. I built to spec; it just happened to be a > stupid spec. So the spec is flawed - but the implemented software > conforms to that stupid spec 100%, so by definition it not flawed. It > is, however, non-secure. > > -- > Karen Mercedes Goertzel, CISSP > Booz Allen Hamilton > 703.698.7454 > goertzel_karen at bah.com > > > > > -----Original Message----- > From: sc-l-bounces at securecoding.org on behalf of Benjamin Tomhave > Sent: Thu 19-Mar-09 19:28 > To: Secure Code Mailing List > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security > Alchemist(informIT) > > Why are we differentiating between "software" and "security" bugs? It > seems to me that all bugs are software bugs, ... > -- 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: ] Hartree's Law: "Whatever the state of a project, the time a project-leader will estimate for completion is constant." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From list-spam at secureconsulting.net Fri Mar 20 12:21:08 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Fri, 20 Mar 2009 13:21:08 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B401F4ABC3@MCLNEXVS06.resource.ds.bah.com> References: <49C2D509.9030600@secureconsulting.net> <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> <49C3B095.1030002@secureconsulting.net> <184D5FFC5203644FB4F8864B0EE445B401F4ABC3@MCLNEXVS06.resource.ds.bah.com> Message-ID: <49C3D084.8060808@secureconsulting.net> I would argue that the "security 'bugs'" you've described are in fact functional deficiencies in the implemented design. That is, the exploit of them has a direct impact on functional performance of the application, even if it's just a problem with error handling ("input validation"). I would further argue that treating security as a special case ends up doing us more harm than good. Doing so allows developers, designers, and the business to shrug it off as Somebody Else's Problem (SEP), instead of owning it themselves. The same goes for the requirements, design, etc. As an industry, we've developed segments of specialized knowledge, and then have the audacity to complain about it not being mainstream. It's time we picked one, and I would argue that mainstreaming these concepts will be far more effective than continuing as a specialized bolt-on discipline (which is not to say that specialized research should not occur, just that in "real life" the application of this knowledge should not be specialized, per se). *shrug* The only way I see to win the game is to change the rules and/or the game play itself. We must never forget that the security industry still relies (heavily) on many of the same concepts that protected us 15 years ago (i.e. signature-based scans and ACLs - AV+firewall). -ben Goertzel, Karen [USA] wrote: > No - that isn't really what I meant. There CAN be security "bugs" - > i.e., implementation errors with direct security implications, such > as a divide-by-zero error that allows a denial of service in a > security-critical component, thus exposing what is supposed to be > protected data. > > But there are also bad security decisions - these can be at the > requirements spec or design spec level. If they're at the > requirements spec level, they aren't "bugs" - they are either > omissions of good security or commissions of bad security. An > omission of good security is not encrypting a password. That isn't a > "bug" per se - unless it's a violation of policy. But if there's no > password encryption policy, then the failure to include a requirement > to encrypt passwords would not be a "bug" or a violation of any sort > (except a violation of common sense). It would still, however, result > in poor security. > > -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 > goertzel_karen at bah.com > > > > > -----Original Message----- From: Benjamin Tomhave > [mailto:list-spam at secureconsulting.net] Sent: Fri 20-Mar-09 11:04 To: > Goertzel, Karen [USA] Cc: Secure Code Mailing List Subject: Re: > [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) > > So, what you're saying is that "security bugs" are really design > flaws, assuming a perfect implementation of the design. Ergo, > security bug is at best a misnomer, and at worst a fatal deficiency > in design acumen. > > :) > > -ben > > Goertzel, Karen [USA] wrote: >> Except when they're hardware bugs. :) >> >> I think the differentiation is also meaningful in this regard: I >> can specify software that does non-secure things. I can implement >> that software 100% correctly. Ipso facto - no software bugs. But >> the fact remains that the software doesn't validate input because I >> didn't specify it to validate input, or it doesn't encrypt >> passwords because I didn't specify it to do so. I built to spec; it >> just happened to be a stupid spec. So the spec is flawed - but the >> implemented software conforms to that stupid spec 100%, so by >> definition it not flawed. It is, however, non-secure. >> >> -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 >> goertzel_karen at bah.com >> >> >> >> >> -----Original Message----- From: sc-l-bounces at securecoding.org on >> behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure >> Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a >> Software Security Alchemist(informIT) >> >> Why are we differentiating between "software" and "security" bugs? >> It seems to me that all bugs are software bugs, ... >> > -- 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: ] Hofstadter's Law: "A task always takes longer than you expect, even when you take into account Hofstadter's Law." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From goertzel_karen at bah.com Fri Mar 20 13:21:57 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 20 Mar 2009 14:21:57 -0400 Subject: [SC-L] more relevant certifications References: <3f4922c70903200659t6f862db3o6a81f16d2e6ef562@mail.gmail.com> Message-ID: <184D5FFC5203644FB4F8864B0EE445B401F4ABCD@MCLNEXVS06.resource.ds.bah.com> I would refer you to Section 7.2.2.2, Professional Certifications, starting on page 272 of "Software Security Assurance: A State-of-the-Art Report" which can be downloaded from: http://iac.dtic.mil/iatac/download/security.pdf The report was published in July 2007; there may be additional certifications that have become available since then. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of SC-L Reader Dave Aronson Sent: Fri 20-Mar-09 09:59 To: Secure Coding Subject: [SC-L] more relevant certifications Paco Hope wrote: > just as overly-simplistic as > someone who disparages all credentials equally. On that note... my company (BAE Systems) has been pushing for people to become CISSPs, because in turn the main client (US gov) has been pushing for contractors to have a bunch of CISSPs on the projects. But, it seems as though that cert is very heavily loaded down with things that front-line grunts like me will NEVER use. I doubt I'll ever get to decide where a data center is located, let alone the entire building, nor what kind of fire detection/suppression or physical security systems it has, and I can probably forget about dictating HR policy as well. So, I was considering other certs, that seem much more relevant. The main relevant one I've heard of is the GSSP (GIAC Secure Software Programmer). 1) What do y'all think of that one? 2) It looked to me as though, other than perhaps from buying books, there is one and only one GSSP practice exam, and it can be taken only once. Am I wrong? Do you know of any others available for free, preferably to be taken online? 3) Have you heard of any other certs relevant for those of us who mainly design and implement computer-based systems, which will usually undergo security scrutiny, and usually have little to no say about all the other stuff around it? (Preferably not technology-specific, as opposed to for example a "Secure Java" or "Secure Web-Apps" cert.) Compare and contrast, as the teachers would say.... Thanks, Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web _______________________________________________ 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/20090320/c5ed098e/attachment-0001.html From chandra at list.org Fri Mar 20 13:28:37 2009 From: chandra at list.org (Pravir Chandra) Date: Fri, 20 Mar 2009 18:28:37 +0000 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> Message-ID: <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> Well, it seems that there's an interesting nuance here. We don't really have a concrete definition for what software is (code, design, compiled bins, etc.). All of these things plus the subjective expectations from designers, users, and security folks tend to be the domain for how the term is used. Now on to 'bug'... Same thing applies. A missing feature can be called a bug just as well as a flawed line of code (or even a specified feature that does something undesirable). But, I'm of the mind that avoiding security problems in software comes down to specification and design. I know Gary likes to talk about security problems as bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful when trying to build secure software in general (however, it is helpful in convincing people that are bug-chasing to look elsewhere too). In fact, I'd be willing to be that for just about every software security problem we've dealt, I could give you a design/spec level solution that would prevent it in general (and make auditing and so forth incredibly streamlined). p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: "Goertzel, Karen [USA]" Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhave; Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) _______________________________________________ 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 20 13:35:01 2009 From: jsteven at cigital.com (John Steven) Date: Fri, 20 Mar 2009 14:35:01 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) In-Reply-To: <49C2D509.9030600@secureconsulting.net> Message-ID: Tom, Ben, All, I thought I'd offer more specifics in an attempt to clarify. I train people here to argue your position Ben: security vulnerabilities don't count unless they affect development. To this end, we've specifically had success with the following approaches: [Integrate Assessment Practices] [What?] Wrap the assessment activities (both tool-based and manual techniques) in a process that: * Normalizes findings under a common reporting vocabulary and demonstrates impact * Include SAST, DAST, scanning, manual, out-sourced, & ALL findings producers in this framework * Anchors findings in either a developmental root cause or other software artifact: * Use Case, reqs, design, spec, etc. * Builds adaptors so that bugs are automatically entered in tracking systems * Adaptors should include both tool-based and manual findings * Calculates impact with an agreed-upon mechanism that rates security risk with other factors: * Functional release criteria * Other non-security non-functional requirements [Realistic?] I believe so. Cigital's more junior consultants work on these very tasks, and they don't require an early-adopter to fund or agree to them. There's plenty of tooling out there to help with the adapters and plenty of presentations/papers on risk (http://www.riskanalys.is), normalizing findings ( http://cwe.mitre.org/.) , and assessment methodology (http://www.cigital.com/papers/download/j15bsi.pdf). [Panacea?] No. I've done research and consulting in functional testing. If you think security is powerless against development, try spending a few years in a tester's shoes! Functionality may be king for development and PMs, but I've found that functional testing has little to no power. While a lack of features may prevent software from going out the door, very rarely do I find that functional testing can implement an effective "go/no-go" gate from their seat in the org. That's why testing efforts seek muscle from their friend Security (and its distant cousins under quality "Load and Performance") to stop releases from going out the door. There's no reason NOT to integrate with testing efforts, reporting, and groups: we should. There's every reason security should adhere to the same interface everyone else does with developers (let them produce code and let them consume bugs)... I think the steps I outlined under 'what' bring us closer. I enjoyed Guy's book, but I don't think we need to (or can expect to) flip organizational precedent and behavior on its head to make progress. [Steering] The above scenario doesn't allow explicitly for two key input/outputs from the software security ecosystem: 1. Handling ultra-high-priority issues in real time 2. Adjusting and evolving to changing threat landscapes I've long suggested establishing a steering committee for this. [What?] Establish a steering committee on which a software security, dev, architecture, operations, and corporate risk sit. These folk should manage the risk-model, scoring, security standards that drive the assessment verification standard, and the definition of both short-term and longer-term mitigating strategies. I'd argue that you'd like Industry representation too. That organization could come in written form (like the Top N lists) or in the form of consulting or a panel. When incidents or firefights come into play, absolutely allow them to be handled out of band (albeit through a documented process), but! Not until they've been rated with the agreed-upon model. [Realistic?] Yes. I have several clients that use this structure. I speak with non-clients that do the same. Data gathering for scoring and prioritization is easy if you've done the steps in the previous section. The operations guys help you grade the pertinence of your efforts to what they're seeing 'in the wild' too. [Panacea?] Does a steering committee help you respond with agility to a high-priority threat in real time? Not explicitly. But, it does help if your organizational stakeholders already have a working relationship and a mutual respect. Also: I think one root cause of the underlying discomfort (or dislike) with people's perspectives on this thread has been: "OK, Fine Gary... you don't like Top N lists... So what do you do?" Well, in my mind... The above answers that question. [Assessment and Tools] Do I believe that the normalized findings will emerge only from static analysis (or any other kind of vulnerability detection tool)? Absolutely not. People who follow my writing know I expect dramatic(ally high and low) numbers to be associated with tools. Let's summarize my data. Organizations can expect: * Static analysis tools to account for 15-20% of their total findings, out of the box * An initial false positive rate as high as 75-99% from a static analysis tool, without tuning * Less than 09% code coverage (by even shallow coverage metrics) from pen-testing tools Qualitatively, I can tell you that I expect an overwhelming majority of static analysis results produced in an organization to come from customization of their adopted product. Simply: if you base your world view on only those things a tool (any tool) produces, you're world view is as narrow as a Neo-con's-and will prove about as ineffective. The same is true of those who narrow their scope to the OWASP Top-10 or the SANS Top 25. [Top N Redux] Some have left the impression that starting with a Top N list is of no use. Please don't think I'm in this camp. In my last two presentations I've indicated, "If you're starting from scratch these lists (or lists intrinsically baked into a tool's capabilities for detection) are a great place to start." and if you can't afford frequent industry interaction-use Top N lists as a proxy for it. They're valuable, but like anything, only to a point. For me, this discussion will remain circular until we think about it in terms of measured, iterative organizational improvement. Why? Because when an organization focuses on getting beyond a "Top N" list it will just create their own organization-specific "Top N" list :-) If they're smart though, they'll call it a dash board and vie for a promotion ;-) >From the other side? People building Top N lists know they're not a panacea, but also know that a lot of organizations simply can't stomach the kind of emotional investment that bsimm (and the ilk) come with. This leaves me with the following: [Conclusions] Top N lists are neither necessary nor sufficient for organization success Top N lists are necessary but not sufficient for industry success Maturity models are neither necessary nor sufficient for organizational success Maturity models are necessary but not sufficient for industry success Always avail yourself of what the industry produces; Never confine yourself to a single industry artifact dogmatically; Whatever you consume from industry, improve it by making it your own; Where-ever your are in your journey, continue to improve iteratively. [Related Perennial Rabbit Holes] (bonus) Bugs vs. Flaws: John Steven'06 - http://www.mail-archive.com/sc-l at securecoding.org/msg00888.html Security Vs. Quality: Cowan '02 - http://www.securityfocus.com/archive/98/304766 ---- 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. On 3/19/09 7:28 PM, "Benjamin Tomhave" wrote: Why are we differentiating between "software" and "security" bugs? It seems to me that all bugs are software bugs, and how quickly they're tackled is a matter of prioritizing the work based on severity, impact, and ease of resolution. It seems to me that, while it is problematic that security testing has been excluded historically, our goal should not be to establish yet another security-as-bolt-on state, but rather leapfrog to the desired end-state where QA testing includes security testing as well as functional testing. In fact, one could even argue that security testing IS functional testing, but anyway... If you're going to innovate, you must as well jump the curve*. -ben * see Kawasaki "Art of Innovation" http://blog.guykawasaki.com/2007/06/art_of_innovati.html Gary McGraw wrote: > Aloha Jim, > > I agree that security bugs should not necessarily take precedence > over other bugs. Most of the initiatives that we observed cycled ALL > security bugs into the standard bug tracking system (most of which > rank bugs by some kind of severity rating). Many initiatives put > more weight on security bugs...note the term "weight" not "drop > everything and run around only working on security." See the CMVM > practice activities for more. > > The BSIMM helps to measure and then evolve a software security > initiative. The top N security bugs activity is one of an arsenal of > tools built and used by the SSG to strategically guide the rest of > their software security initiative. Making this a "top N bugs of any > kind" list might make sense for some organizations, but is not > something we would likely observe by studying the SSG and the > software security initiative. Perhaps we suffer from the "looking > for the keys under the streetlight" problem. > > gem > > > On 3/19/09 2:31 PM, "Jim Manico" wrote: > >> The top N lists we observed among the 9 were BUG lists only. So >> that means that in general at least half of the defects were not >> being identified on the "most wanted" list using that BSIMM set of >> activities. > > This sounds very problematic to me. There are many standard software > bugs that are much more critical to the enterprise than just security > bugs. It seems foolhardy to do risk assessment on security bugs only > - I think we need to bring the worlds of software development and > security analysis together more. Divided we (continue to) fail. > > And Gary, this is not a critique of just your comment, but of > WebAppSec at large. > > - Jim > > > ----- Original Message ----- From: "Gary McGraw" > To: "Steven M. Christey" Cc: "Sammy Migues" > ; "Michael Cohen" ; "Dustin > Sullivan" ; "Secure Code Mailing List" > Sent: Thursday, March 19, 2009 2:50 AM > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security > Alchemist (informIT) > > >> Hi Steve, >> >> Sorry for falling off the thread last night. Waiting for the posts >> to clear was not a great idea. >> >> The top N lists we observed among the 9 were BUG lists only. So >> that means that in general at least half of the defects were not >> being identified on the "most wanted" list using that BSIMM set of >> activities. You are correct to point out that the "Architecture >> Analysis" practice has other activities meant to ferret out those >> sorts of flaws. >> >> I asked my guys to work on a flaws collection a while ago, but I >> have not seen anything yet. Canuck? >> >> There is an important difference between your CVE data which is >> based on externally observed bugs (imposed on vendors by security >> types mostly) and internal bug data determined using static >> analysis or internal testing. I would be very interested to know >> whether Microsoft and the CVE consider the same bug #1 on internal >> versus external rating systems. The difference is in the term >> "reported for" versus "discovered internally during SDL activity". >> >> gem >> >> http://www.cigital.com/~gem >> >> >> On 3/18/09 6:14 PM, "Steven M. Christey" >> wrote: >> >> >> >> On Wed, 18 Mar 2009, Gary McGraw wrote: >> >>> Many of the top N lists we encountered were developed through the >>> consistent use of static analysis tools. >> Interesting. Does this mean that their top N lists are less likely >> to include design flaws? (though they would be covered under >> various other BSIMM activities). >> >>> After looking at millions of lines of code (sometimes >>> constantly), a ***real*** top N list of bugs emerges for an >>> organization. Eradicating number one is an obvious priority. >>> Training can help. New number one...lather, rinse, repeat. >> I believe this is reflected in public CVE data. Take a look at the >> bugs that are being reported for, say, Microsoft or major Linux >> vendors or most any product with a long history, and their current >> number 1's are not the same as the number 1's of the past. >> >> - 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. > _______________________________________________ > > -- 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: ] "Concern for man and his fate must always form the chief interest of all technical endeavors. Never forget this in the midst of your diagrams and equations." Albert Einstein _______________________________________________ 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 secureCoding2dave at davearonson.com Fri Mar 20 13:59:08 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Fri, 20 Mar 2009 14:59:08 -0400 Subject: [SC-L] more relevant certifications In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B401F4ABCC@MCLNEXVS06.resource.ds.bah.com> References: <3f4922c70903200659t6f862db3o6a81f16d2e6ef562@mail.gmail.com> <184D5FFC5203644FB4F8864B0EE445B401F4ABCC@MCLNEXVS06.resource.ds.bah.com> Message-ID: <3f4922c70903201159q78a92fcci771ca76a7ebb4216@mail.gmail.com> Goertzel, Karen [USA] wrote: > I would refer you to Section 7.2.2.2, Professional Certifications, starting > on page 272 of "Software Security Assurance: A State-of-the-Art Report" > which can be downloaded from: > http://iac.dtic.mil/iatac/download/security.pdf Great, this will at least point me down some path. > Karen Mercedes Goertzel, CISSP ,,,and contributor and Coordinating Editor of the above report. :-) Thanks, Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From jim at manico.net Fri Mar 20 14:07:20 2009 From: jim at manico.net (Jim Manico) Date: Fri, 20 Mar 2009 09:07:20 -1000 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> References: <49C2D509.9030600@secureconsulting.net> <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> Message-ID: <655F2EC0-3BF7-4CF7-88D6-D1C143B3FCC4@manico.net> This is why I'm not fond if leading with a tool. I prefer to lead with architectural/design analysis and targeted manual review of high risk applications. Jim Manico jim at manico.net On Mar 20, 2009, at 4:06 AM, "Goertzel, Karen [USA]" wrote: > Except when they're hardware bugs. :) > > I think the differentiation is also meaningful in this regard: I can > specify software that does non-secure things. I can implement that > software 100% correctly. Ipso facto - no software bugs. But the fact > remains that the software doesn't validate input because I didn't > specify it to validate input, or it doesn't encrypt passwords > because I didn't specify it to do so. I built to spec; it just > happened to be a stupid spec. So the spec is flawed - but the > implemented software conforms to that stupid spec 100%, so by > definition it not flawed. It is, however, non-secure. > > -- > Karen Mercedes Goertzel, CISSP > Booz Allen Hamilton > 703.698.7454 > goertzel_karen at bah.com > > > > > -----Original Message----- > From: sc-l-bounces at securecoding.org on behalf of Benjamin Tomhave > Sent: Thu 19-Mar-09 19:28 > To: Secure Code Mailing List > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security > Alchemist(informIT) > > Why are we differentiating between "software" and "security" bugs? It > seems to me that all bugs are software bugs, ... > > _______________________________________________ > 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/20090320/d5e14ca6/attachment.html From tomb at owasp.org Fri Mar 20 15:37:36 2009 From: tomb at owasp.org (Tom Brennan - OWASP) Date: Fri, 20 Mar 2009 20:37:36 +0000 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: References: <49C2D509.9030600@secureconsulting.net> Message-ID: <1278681275-1237581458-cardhu_decombobulator_blackberry.rim.net-1371722829-@bxe1156.bisx.prod.on.blackberry> John Stevens for Cyber Czar! I have "Elect J.Stevens" bumper stickers printing, I retooled my Free Kevin sticker press. Well stated ;) have a great weekend! -----Original Message----- From: John Steven Date: Fri, 20 Mar 2009 14:35:01 To: Benjamin Tomhave; Secure Code MailingList Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) Tom, Ben, All, I thought I'd offer more specifics in an attempt to clarify. I train people here to argue your position Ben: security vulnerabilities don't count unless they affect development. To this end, we've specifically had success with the following approaches: [Integrate Assessment Practices] [What?] Wrap the assessment activities (both tool-based and manual techniques) in a process that: * Normalizes findings under a common reporting vocabulary and demonstrates impact * Include SAST, DAST, scanning, manual, out-sourced, & ALL findings producers in this framework * Anchors findings in either a developmental root cause or other software artifact: * Use Case, reqs, design, spec, etc. * Builds adaptors so that bugs are automatically entered in tracking systems * Adaptors should include both tool-based and manual findings * Calculates impact with an agreed-upon mechanism that rates security risk with other factors: * Functional release criteria * Other non-security non-functional requirements [Realistic?] I believe so. Cigital's more junior consultants work on these very tasks, and they don't require an early-adopter to fund or agree to them. There's plenty of tooling out there to help with the adapters and plenty of presentations/papers on risk (http://www.riskanalys.is), normalizing findings ( http://cwe.mitre.org/.) , and assessment methodology (http://www.cigital.com/papers/download/j15bsi.pdf). [Panacea?] No. I've done research and consulting in functional testing. If you think security is powerless against development, try spending a few years in a tester's shoes! Functionality may be king for development and PMs, but I've found that functional testing has little to no power. While a lack of features may prevent software from going out the door, very rarely do I find that functional testing can implement an effective "go/no-go" gate from their seat in the org. That's why testing efforts seek muscle from their friend Security (and its distant cousins under quality "Load and Performance") to stop releases from going out the door. There's no reason NOT to integrate with testing efforts, reporting, and groups: we should. There's every reason security should adhere to the same interface everyone else does with developers (let them produce code and let them consume bugs)... I think the steps I outlined under 'what' bring us closer. I enjoyed Guy's book, but I don't think we need to (or can expect to) flip organizational precedent and behavior on its head to make progress. [Steering] The above scenario doesn't allow explicitly for two key input/outputs from the software security ecosystem: 1. Handling ultra-high-priority issues in real time 2. Adjusting and evolving to changing threat landscapes I've long suggested establishing a steering committee for this. [What?] Establish a steering committee on which a software security, dev, architecture, operations, and corporate risk sit. These folk should manage the risk-model, scoring, security standards that drive the assessment verification standard, and the definition of both short-term and longer-term mitigating strategies. I'd argue that you'd like Industry representation too. That organization could come in written form (like the Top N lists) or in the form of consulting or a panel. When incidents or firefights come into play, absolutely allow them to be handled out of band (albeit through a documented process), but! Not until they've been rated with the agreed-upon model. [Realistic?] Yes. I have several clients that use this structure. I speak with non-clients that do the same. Data gathering for scoring and prioritization is easy if you've done the steps in the previous section. The operations guys help you grade the pertinence of your efforts to what they're seeing 'in the wild' too. [Panacea?] Does a steering committee help you respond with agility to a high-priority threat in real time? Not explicitly. But, it does help if your organizational stakeholders already have a working relationship and a mutual respect. Also: I think one root cause of the underlying discomfort (or dislike) with people's perspectives on this thread has been: "OK, Fine Gary... you don't like Top N lists... So what do you do?" Well, in my mind... The above answers that question. [Assessment and Tools] Do I believe that the normalized findings will emerge only from static analysis (or any other kind of vulnerability detection tool)? Absolutely not. People who follow my writing know I expect dramatic(ally high and low) numbers to be associated with tools. Let's summarize my data. Organizations can expect: * Static analysis tools to account for 15-20% of their total findings, out of the box * An initial false positive rate as high as 75-99% from a static analysis tool, without tuning * Less than 09% code coverage (by even shallow coverage metrics) from pen-testing tools Qualitatively, I can tell you that I expect an overwhelming majority of static analysis results produced in an organization to come from customization of their adopted product. Simply: if you base your world view on only those things a tool (any tool) produces, you're world view is as narrow as a Neo-con's-and will prove about as ineffective. The same is true of those who narrow their scope to the OWASP Top-10 or the SANS Top 25. [Top N Redux] Some have left the impression that starting with a Top N list is of no use. Please don't think I'm in this camp. In my last two presentations I've indicated, "If you're starting from scratch these lists (or lists intrinsically baked into a tool's capabilities for detection) are a great place to start." and if you can't afford frequent industry interaction-use Top N lists as a proxy for it. They're valuable, but like anything, only to a point. For me, this discussion will remain circular until we think about it in terms of measured, iterative organizational improvement. Why? Because when an organization focuses on getting beyond a "Top N" list it will just create their own organization-specific "Top N" list :-) If they're smart though, they'll call it a dash board and vie for a promotion ;-) >From the other side? People building Top N lists know they're not a panacea, but also know that a lot of organizations simply can't stomach the kind of emotional investment that bsimm (and the ilk) come with. This leaves me with the following: [Conclusions] Top N lists are neither necessary nor sufficient for organization success Top N lists are necessary but not sufficient for industry success Maturity models are neither necessary nor sufficient for organizational success Maturity models are necessary but not sufficient for industry success Always avail yourself of what the industry produces; Never confine yourself to a single industry artifact dogmatically; Whatever you consume from industry, improve it by making it your own; Where-ever your are in your journey, continue to improve iteratively. [Related Perennial Rabbit Holes] (bonus) Bugs vs. Flaws: John Steven'06 - http://www.mail-archive.com/sc-l at securecoding.org/msg00888.html Security Vs. Quality: Cowan '02 - http://www.securityfocus.com/archive/98/304766 ---- 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. On 3/19/09 7:28 PM, "Benjamin Tomhave" wrote: Why are we differentiating between "software" and "security" bugs? It seems to me that all bugs are software bugs, and how quickly they're tackled is a matter of prioritizing the work based on severity, impact, and ease of resolution. It seems to me that, while it is problematic that security testing has been excluded historically, our goal should not be to establish yet another security-as-bolt-on state, but rather leapfrog to the desired end-state where QA testing includes security testing as well as functional testing. In fact, one could even argue that security testing IS functional testing, but anyway... If you're going to innovate, you must as well jump the curve*. -ben * see Kawasaki "Art of Innovation" http://blog.guykawasaki.com/2007/06/art_of_innovati.html Gary McGraw wrote: > Aloha Jim, > > I agree that security bugs should not necessarily take precedence > over other bugs. Most of the initiatives that we observed cycled ALL > security bugs into the standard bug tracking system (most of which > rank bugs by some kind of severity rating). Many initiatives put > more weight on security bugs...note the term "weight" not "drop > everything and run around only working on security." See the CMVM > practice activities for more. > > The BSIMM helps to measure and then evolve a software security > initiative. The top N security bugs activity is one of an arsenal of > tools built and used by the SSG to strategically guide the rest of > their software security initiative. Making this a "top N bugs of any > kind" list might make sense for some organizations, but is not > something we would likely observe by studying the SSG and the > software security initiative. Perhaps we suffer from the "looking > for the keys under the streetlight" problem. > > gem > > > On 3/19/09 2:31 PM, "Jim Manico" wrote: > >> The top N lists we observed among the 9 were BUG lists only. So >> that means that in general at least half of the defects were not >> being identified on the "most wanted" list using that BSIMM set of >> activities. > > This sounds very problematic to me. There are many standard software > bugs that are much more critical to the enterprise than just security > bugs. It seems foolhardy to do risk assessment on security bugs only > - I think we need to bring the worlds of software development and > security analysis together more. Divided we (continue to) fail. > > And Gary, this is not a critique of just your comment, but of > WebAppSec at large. > > - Jim > > > ----- Original Message ----- From: "Gary McGraw" > To: "Steven M. Christey" Cc: "Sammy Migues" > ; "Michael Cohen" ; "Dustin > Sullivan" ; "Secure Code Mailing List" > Sent: Thursday, March 19, 2009 2:50 AM > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security > Alchemist (informIT) > > >> Hi Steve, >> >> Sorry for falling off the thread last night. Waiting for the posts >> to clear was not a great idea. >> >> The top N lists we observed among the 9 were BUG lists only. So >> that means that in general at least half of the defects were not >> being identified on the "most wanted" list using that BSIMM set of >> activities. You are correct to point out that the "Architecture >> Analysis" practice has other activities meant to ferret out those >> sorts of flaws. >> >> I asked my guys to work on a flaws collection a while ago, but I >> have not seen anything yet. Canuck? >> >> There is an important difference between your CVE data which is >> based on externally observed bugs (imposed on vendors by security >> types mostly) and internal bug data determined using static >> analysis or internal testing. I would be very interested to know >> whether Microsoft and the CVE consider the same bug #1 on internal >> versus external rating systems. The difference is in the term >> "reported for" versus "discovered internally during SDL activity". >> >> gem >> >> http://www.cigital.com/~gem >> >> >> On 3/18/09 6:14 PM, "Steven M. Christey" >> wrote: >> >> >> >> On Wed, 18 Mar 2009, Gary McGraw wrote: >> >>> Many of the top N lists we encountered were developed through the >>> consistent use of static analysis tools. >> Interesting. Does this mean that their top N lists are less likely >> to include design flaws? (though they would be covered under >> various other BSIMM activities). >> >>> After looking at millions of lines of code (sometimes >>> constantly), a ***real*** top N list of bugs emerges for an >>> organization. Eradicating number one is an obvious priority. >>> Training can help. New number one...lather, rinse, repeat. >> I believe this is reflected in public CVE data. Take a look at the >> bugs that are being reported for, say, Microsoft or major Linux >> vendors or most any product with a long history, and their current >> number 1's are not the same as the number 1's of the past. >> >> - 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. > _______________________________________________ > > -- 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: ] "Concern for man and his fate must always form the chief interest of all technical endeavors. Never forget this in the midst of your diagrams and equations." Albert Einstein _______________________________________________ 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 coley at linus.mitre.org Fri Mar 20 19:48:10 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 20 Mar 2009 20:48:10 -0400 (EDT) Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> Message-ID: On Fri, 20 Mar 2009, Pravir Chandra wrote: > In fact, I'd be willing to be that for just about every software > security problem we've dealt, I could give you a design/spec level > solution that would prevent it in general (and make auditing and so > forth incredibly streamlined). I don't think I disagree, and I've started getting interested in the design-level choices that make implementation bugs easier to make. (examples: HTML mixes data/control in the same stream and therefore you have XSS; OSes mix data/control within programs and thus buffer overflows in data can execute code; HTTP is stateless and URLs are transportable, thus you have CSRF; OSes allow the same file object to have multiple names, thus you have path traversal and symlink attacks; strcpy() and its ilk don't accept length parameters and are thus easy to abuse, and besides, C doesn't enforce boundaries for memory accesses; etc.) Seven Pernicious Kingdoms defined the "API Abuse" category, which I thought was a recognition of a pretty deep problem. We've expanded on it a bit in CWE, although there's lots of room for growth (see CWE-227 and its children under the CWE-1000 research view). Two areas that don't seem to immediately lend themselves to design/spec level solutions are (1) transitive trust and (2) interaction errors between multiple components that are all working correctly. I'd love to hear from people who've had to solve these problems in the real world. Based on what I see in CVE, it seems that the answer for item 2 is usually for one component to choose to conform to another's expectations, and that conforming component isn't always the one that "should" be changed. - Steve From gem at cigital.com Fri Mar 20 22:30:19 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 20 Mar 2009 23:30:19 -0400 Subject: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) In-Reply-To: <655F2EC0-3BF7-4CF7-88D6-D1C143B3FCC4@manico.net> Message-ID: hi all, my preference is to lead with an Architectural Risk Analysis (and has been since 1997). gem http://www.cigital.com/~gem On 3/20/09 3:07 PM, "Jim Manico" wrote: This is why I'm not fond if leading with a tool. I prefer to lead with architectural/design analysis and targeted manual review of high risk applications. Jim Manico jim at manico.net On Mar 20, 2009, at 4:06 AM, "Goertzel, Karen [USA]" wrote: Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between "software" and "security" bugs? It seems to me that all bugs are software bugs, ... _______________________________________________ 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 20 22:41:15 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 20 Mar 2009 23:41:15 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> Message-ID: hi pub, once long ago I spilt a bottle of wine with dan geer in Palo Alto to lament his dead disk drive. we decided the conference sucked anyway and proceeded to the Cowper. we argued for hours about whether a buffer overflow was a bug or a flaw. if you find one in a code pile (say, caused by a local variable on the stack and a gets call) , it is a bug. Or is it a flaw that the C stack grows in an incredibly stupid way? hmm. Necker defect. gem http;//www.cigital.com/~gem On 3/20/09 2:28 PM, "Pravir Chandra" wrote: Well, it seems that there's an interesting nuance here. We don't really have a concrete definition for what software is (code, design, compiled bins, etc.). All of these things plus the subjective expectations from designers, users, and security folks tend to be the domain for how the term is used. Now on to 'bug'... Same thing applies. A missing feature can be called a bug just as well as a flawed line of code (or even a specified feature that does something undesirable). But, I'm of the mind that avoiding security problems in software comes down to specification and design. I know Gary likes to talk about security problems as bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful when trying to build secure software in general (however, it is helpful in convincing people that are bug-chasing to look elsewhere too). In fact, I'd be willing to be that for just about every software security problem we've dealt, I could give you a design/spec level solution that would prevent it in general (and make auditing and so forth incredibly streamlined). p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: "Goertzel, Karen [USA]" Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhave; Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) _______________________________________________ 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 Fri Mar 20 23:06:01 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 20 Mar 2009 23:06:01 -0500 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> Message-ID: <8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> > > Two areas that don't seem to immediately lend themselves to design/ > spec > level solutions are (1) transitive trust and (2) interaction errors > between multiple components that are all working correctly. I'd > love to > hear from people who've had to solve these problems in the real world. > Based on what I see in CVE, it seems that the answer for item 2 is > usually > for one component to choose to conform to another's expectations, > and that > conforming component isn't always the one that "should" be changed. Those are both definitely apparent at design time. Paraphrasing Bob Blakley, applications are built on composition, but most security protocols are point to point and don't compose. So anyone who bothers to look at the end to end application will see massive gaps in the security protocols. The "fix" is likely a decision between a sts/federation/proxy pattern, and a way to link policy to mechanism. WS-SecurityPolicy provides one such way to do specify the policy side. -gunnar From joe at joeteff.com Sat Mar 21 01:38:53 2009 From: joe at joeteff.com (Joe Teff) Date: Sat, 21 Mar 2009 01:38:53 -0500 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: References: Message-ID: I notice certs like CISSP when hiring. It says the person has a basic understanding of all IS security areas. Nothing more. If someone can't pass the CISSP then I have to wonder why. -----Original Message----- From: Paco Hope To: "SC-L at securecoding.org" Date: Thu, 19 Mar 2009 11:36:45 -0400 Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs On 3/18/09 5:29 PM, "Jeremy Epstein" wrote: > If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it ...then I'd say you have an overly simplistic view of the world. Anyone who believes that a credential automatically conveys some magical knowledge that you didn't have before is just as overly-simplistic as someone who disparages all credentials equally. It just isn't a black and white world. Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ [http://www.cigital.com/] ? +1.703.585.7868 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 [http://krvw.com/mailman/listinfo/sc-l] List charter available at - http://www.securecoding.org/list/charter.php [http://www.securecoding.org/list/charter.php] SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com [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/20090321/9e373d47/attachment.html From ljknews at mac.com Sat Mar 21 08:11:05 2009 From: ljknews at mac.com (ljknews) Date: Sat, 21 Mar 2009 09:11:05 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: Message-ID: At 11:41 PM -0400 3/20/09, Gary McGraw wrote: > once long ago I spilt a bottle of wine with dan geer > we argued for hours about whether a buffer overflow was > a bug or a flaw. if you find one in a code pile (say, > caused by a local variable on the stack and a gets call) , > it is a bug. Or is it a flaw that the C stack grows in > an incredibly stupid way? That reasoning has a bit of not being able to see the forest for the trees. The root problem (and I do not care about the terminology) is that the C programming language promotes the use of uncounted strings. -- Larry Kilgallen From fw at deneb.enyo.de Sat Mar 21 12:32:59 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 21 Mar 2009 18:32:59 +0100 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: (Steven M. Christey's message of "Fri, 20 Mar 2009 20:48:10 -0400 (EDT)") References: <49C2D509.9030600@secureconsulting.net> <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> Message-ID: <87vdq2bx2s.fsf@mid.deneb.enyo.de> * Steven M. Christey: > Two areas that don't seem to immediately lend themselves to design/spec > level solutions are (1) transitive trust and (2) interaction errors > between multiple components that are all working correctly. I'd love to > hear from people who've had to solve these problems in the real world. > Based on what I see in CVE, it seems that the answer for item 2 is usually > for one component to choose to conform to another's expectations, and that > conforming component isn't always the one that "should" be changed. The really hard things under (2), like the Java/firewall issue, are not fixed at all. Subsequent designs may address it (Silverlight) or not (Flash, post-FTP firewall helpers). The + + + A T H 0 problem is in this cateogry, too. It seems to me that many of those things are, in some sense, layering violations, where one party attaches meaning to properties at a wholly different layer. For instance, the cluster of AS4_PATH issues (which we can't afford not fixing, I think) stems from the fact that BGP has both a message transport layer, and a message semantics layer (much like RFC 821 vs RFC 822). This view is not yet universally shared, though. From jim at manico.net Sat Mar 21 18:26:21 2009 From: jim at manico.net (Jim Manico) Date: Sat, 21 Mar 2009 13:26:21 -1000 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) References: <49C2D509.9030600@secureconsulting.net> <1278681275-1237581458-cardhu_decombobulator_blackberry.rim.net-1371722829-@bxe1156.bisx.prod.on.blackberry> Message-ID: <66E3B4EA94D84A469ED42817F796DF1C@workhorse> Hey John, I like where your head is at - great list. Regarding: > Builds adaptors so that bugs are automatically entered in tracking systems Does the industry have: 1) A standard schema for findings, root causes, vulnerabilities, etc, and the inter-relation of these key terms (and others?) 2) Standardized API's for allowing different risk systems for correlate this data? Or is it, right now, mostly proprietary glue? Curious... Also, how do you build adaptors so that manual processes are automatically entered in a tracking system? Are you just talking about content management ststems to make it easy to manual reviewers to enter data into rosk mangement software? Anyhow, I like where your head is at and it definately got me thinking. - Jim ----- Original Message ----- From: "Tom Brennan - OWASP" To: "John Steven" ; ; "Benjamin Tomhave" ; "Secure Code MailingList" Sent: Friday, March 20, 2009 10:37 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) > John Stevens for Cyber Czar! > > I have "Elect J.Stevens" bumper stickers printing, I retooled my Free > Kevin sticker press. > > Well stated ;) have a great weekend! > > -----Original Message----- > From: John Steven > > Date: Fri, 20 Mar 2009 14:35:01 > To: Benjamin Tomhave; Secure Code > MailingList > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist > (informIT) > > > Tom, Ben, All, > > I thought I'd offer more specifics in an attempt to clarify. I train > people here to argue your position Ben: security vulnerabilities don't > count unless they affect development. To this end, we've specifically > had success with the following approaches: > > [Integrate Assessment Practices] > [What?] > Wrap the assessment activities (both tool-based and manual techniques) in > a process that: > * Normalizes findings under a common reporting vocabulary and > demonstrates impact > * Include SAST, DAST, scanning, manual, out-sourced, & ALL findings > producers in this framework > * Anchors findings in either a developmental root cause or other > software artifact: > * Use Case, reqs, design, spec, etc. > * Builds adaptors so that bugs are automatically entered in tracking > systems > * Adaptors should include both tool-based and manual findings > * Calculates impact with an agreed-upon mechanism that rates security > risk with other factors: > * Functional release criteria > * Other non-security non-functional requirements > > [Realistic?] > I believe so. Cigital's more junior consultants work on these very tasks, > and they don't require an early-adopter to fund or agree to them. There's > plenty of tooling out there to help with the adapters and plenty of > presentations/papers on risk (http://www.riskanalys.is), normalizing > findings ( http://cwe.mitre.org/.) , and assessment methodology > (http://www.cigital.com/papers/download/j15bsi.pdf). > > [Panacea?] > No. I've done research and consulting in functional testing. If you think > security is powerless against development, try spending a few years in a > tester's shoes! Functionality may be king for development and PMs, but > I've found that functional testing has little to no power. While a lack of > features may prevent software from going out the door, very rarely do I > find that functional testing can implement an effective "go/no-go" gate > from their seat in the org. That's why testing efforts seek muscle from > their friend Security (and its distant cousins under quality "Load and > Performance") to stop releases from going out the door. > > There's no reason NOT to integrate with testing efforts, reporting, and > groups: we should. There's every reason security should adhere to the same > interface everyone else does with developers (let them produce code and > let them consume bugs)... I think the steps I outlined under 'what' bring > us closer. I enjoyed Guy's book, but I don't think we need to (or can > expect to) flip organizational precedent and behavior on its head to make > progress. > > [Steering] > The above scenario doesn't allow explicitly for two key input/outputs > from the software security ecosystem: > > > 1. Handling ultra-high-priority issues in real time > 2. Adjusting and evolving to changing threat landscapes > > I've long suggested establishing a steering committee for this. > > [What?] > Establish a steering committee on which a software security, dev, > architecture, operations, and corporate risk sit. These folk should manage > the risk-model, scoring, security standards that drive the assessment > verification standard, and the definition of both short-term and > longer-term mitigating strategies. I'd argue that you'd like Industry > representation too. That organization could come in written form (like the > Top N lists) or in the form of consulting or a panel. > > When incidents or firefights come into play, absolutely allow them to be > handled out of band (albeit through a documented process), but! Not until > they've been rated with the agreed-upon model. > > [Realistic?] > Yes. I have several clients that use this structure. I speak with > non-clients that do the same. Data gathering for scoring and > prioritization is easy if you've done the steps in the previous section. > The operations guys help you grade the pertinence of your efforts to what > they're seeing 'in the wild' too. > > [Panacea?] > Does a steering committee help you respond with agility to a high-priority > threat in real time? Not explicitly. But, it does help if your > organizational stakeholders already have a working relationship and a > mutual respect. Also: I think one root cause of the underlying discomfort > (or dislike) with people's perspectives on this thread has been: > > "OK, Fine Gary... you don't like Top N lists... So what do you do?" > > Well, in my mind... The above answers that question. > > [Assessment and Tools] > Do I believe that the normalized findings will emerge only from static > analysis (or any other kind of vulnerability detection tool)? Absolutely > not. People who follow my writing know I expect dramatic(ally high and > low) numbers to be associated with tools. Let's summarize my data. > Organizations can expect: > > > * Static analysis tools to account for 15-20% of their total findings, > out of the box > * An initial false positive rate as high as 75-99% from a static > analysis tool, without tuning > * Less than 09% code coverage (by even shallow coverage metrics) from > pen-testing tools > > Qualitatively, I can tell you that I expect an overwhelming majority of > static analysis results produced in an organization to come from > customization of their adopted product. > > Simply: if you base your world view on only those things a tool (any > tool) produces, you're world view is as narrow as a Neo-con's-and will > prove about as ineffective. The same is true of those who narrow their > scope to the OWASP Top-10 or the SANS Top 25. > > [Top N Redux] > Some have left the impression that starting with a Top N list is of no > use. Please don't think I'm in this camp. In my last two presentations > I've indicated, "If you're starting from scratch these lists (or lists > intrinsically baked into a tool's capabilities for detection) are a great > place to start." and if you can't afford frequent industry interaction-use > Top N lists as a proxy for it. They're valuable, but like anything, only > to a point. > > For me, this discussion will remain circular until we think about it in > terms of measured, iterative organizational improvement. Why? Because when > an organization focuses on getting beyond a "Top N" list it will just > create their own organization-specific "Top N" list :-) If they're smart > though, they'll call it a dash board and vie for a promotion ;-) > >>From the other side? People building Top N lists know they're not a >>panacea, but also know that a lot of organizations simply can't stomach >>the kind of emotional investment that bsimm (and the ilk) come with. > > This leaves me with the following: > > [Conclusions] > Top N lists are neither necessary nor sufficient for organization success > Top N lists are necessary but not sufficient for industry success > Maturity models are neither necessary nor sufficient for organizational > success > Maturity models are necessary but not sufficient for industry success > > Always avail yourself of what the industry produces; > Never confine yourself to a single industry artifact dogmatically; > Whatever you consume from industry, improve it by making it your own; > Where-ever your are in your journey, continue to improve iteratively. > > [Related Perennial Rabbit Holes] (bonus) > Bugs vs. Flaws: John Steven'06 - > http://www.mail-archive.com/sc-l at securecoding.org/msg00888.html > Security Vs. Quality: Cowan '02 - > http://www.securityfocus.com/archive/98/304766 > > ---- > 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. > > > On 3/19/09 7:28 PM, "Benjamin Tomhave" > wrote: > > Why are we differentiating between "software" and "security" bugs? It > seems to me that all bugs are software bugs, and how quickly they're > tackled is a matter of prioritizing the work based on severity, impact, > and ease of resolution. It seems to me that, while it is problematic > that security testing has been excluded historically, our goal should > not be to establish yet another security-as-bolt-on state, but rather > leapfrog to the desired end-state where QA testing includes security > testing as well as functional testing. In fact, one could even argue > that security testing IS functional testing, but anyway... > > If you're going to innovate, you must as well jump the curve*. > > -ben > > * see Kawasaki "Art of Innovation" > http://blog.guykawasaki.com/2007/06/art_of_innovati.html > > Gary McGraw wrote: >> Aloha Jim, >> >> I agree that security bugs should not necessarily take precedence >> over other bugs. Most of the initiatives that we observed cycled ALL >> security bugs into the standard bug tracking system (most of which >> rank bugs by some kind of severity rating). Many initiatives put >> more weight on security bugs...note the term "weight" not "drop >> everything and run around only working on security." See the CMVM >> practice activities for more. >> >> The BSIMM helps to measure and then evolve a software security >> initiative. The top N security bugs activity is one of an arsenal of >> tools built and used by the SSG to strategically guide the rest of >> their software security initiative. Making this a "top N bugs of any >> kind" list might make sense for some organizations, but is not >> something we would likely observe by studying the SSG and the >> software security initiative. Perhaps we suffer from the "looking >> for the keys under the streetlight" problem. >> >> gem >> >> >> On 3/19/09 2:31 PM, "Jim Manico" wrote: >> >>> The top N lists we observed among the 9 were BUG lists only. So >>> that means that in general at least half of the defects were not >>> being identified on the "most wanted" list using that BSIMM set of >>> activities. >> >> This sounds very problematic to me. There are many standard software >> bugs that are much more critical to the enterprise than just security >> bugs. It seems foolhardy to do risk assessment on security bugs only >> - I think we need to bring the worlds of software development and >> security analysis together more. Divided we (continue to) fail. >> >> And Gary, this is not a critique of just your comment, but of >> WebAppSec at large. >> >> - Jim >> >> >> ----- Original Message ----- From: "Gary McGraw" >> To: "Steven M. Christey" Cc: "Sammy Migues" >> ; "Michael Cohen" ; "Dustin >> Sullivan" ; "Secure Code Mailing List" >> Sent: Thursday, March 19, 2009 2:50 AM >> Subject: Re: [SC-L] BSIMM: Confessions of a Software Security >> Alchemist (informIT) >> >> >>> Hi Steve, >>> >>> Sorry for falling off the thread last night. Waiting for the posts >>> to clear was not a great idea. >>> >>> The top N lists we observed among the 9 were BUG lists only. So >>> that means that in general at least half of the defects were not >>> being identified on the "most wanted" list using that BSIMM set of >>> activities. You are correct to point out that the "Architecture >>> Analysis" practice has other activities meant to ferret out those >>> sorts of flaws. >>> >>> I asked my guys to work on a flaws collection a while ago, but I >>> have not seen anything yet. Canuck? >>> >>> There is an important difference between your CVE data which is >>> based on externally observed bugs (imposed on vendors by security >>> types mostly) and internal bug data determined using static >>> analysis or internal testing. I would be very interested to know >>> whether Microsoft and the CVE consider the same bug #1 on internal >>> versus external rating systems. The difference is in the term >>> "reported for" versus "discovered internally during SDL activity". >>> >>> gem >>> >>> http://www.cigital.com/~gem >>> >>> >>> On 3/18/09 6:14 PM, "Steven M. Christey" >>> wrote: >>> >>> >>> >>> On Wed, 18 Mar 2009, Gary McGraw wrote: >>> >>>> Many of the top N lists we encountered were developed through the >>>> consistent use of static analysis tools. >>> Interesting. Does this mean that their top N lists are less likely >>> to include design flaws? (though they would be covered under >>> various other BSIMM activities). >>> >>>> After looking at millions of lines of code (sometimes >>>> constantly), a ***real*** top N list of bugs emerges for an >>>> organization. Eradicating number one is an obvious priority. >>>> Training can help. New number one...lather, rinse, repeat. >>> I believe this is reflected in public CVE data. Take a look at the >>> bugs that are being reported for, say, Microsoft or major Linux >>> vendors or most any product with a long history, and their current >>> number 1's are not the same as the number 1's of the past. >>> >>> - 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. >> _______________________________________________ >> >> > > -- > 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: ] > "Concern for man and his fate must always form the chief interest of all > technical endeavors. Never forget this in the midst of your diagrams and > equations." > Albert Einstein > _______________________________________________ > 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 mparsons1980 at gmail.com Sat Mar 21 16:43:37 2009 From: mparsons1980 at gmail.com (Matt Parsons) Date: Sat, 21 Mar 2009 16:43:37 -0500 Subject: [SC-L] Questions asked on job interview for application security/penetration testing job Message-ID: <004e01c9aa6e$1866bb00$49343100$@com> Ladies and gentlemen, I was asked the following questions on a job phone interview and wondered what the proper answers were. I was told their answers after the interview. I was also told that the answers to these questions were one or two word words. In the beginning of next week I will post what they told me were the proper answers. Any references would be greatly appreciated. 1. What are the security functions of SSL? 2. What is a 0 by 90 bytes error. 3. What is a digital signature, Not what it is? 4. What is the problem of having a predictable sequence of bits in TCP/IP? 5. What is heap memory? 6. What is a system call? 7. what is two factor authentication? Thanks Matt Matt Parsons, CISSP Parsons Software Security Consulting, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090321/6b14ac27/attachment.html From mbrown at sans.org Sun Mar 22 08:08:51 2009 From: mbrown at sans.org (Mason Brown) Date: Sun, 22 Mar 2009 13:08:51 +0000 (UTC) Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: <8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com><1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> <8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> Message-ID: <5148989F3B174D17B5153CF14351C97D@BROWN3> Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a project for the Financial Services ISAC. There is a lot of knowledge on this list and I was hoping you might be willing to offer your thoughts. Below is the request from Jim. If you have thoughts or data and could share it, I'll be happy to collate and send back to the list or to anyone that requests. After he presents it to the FS-ISAC in May, the complete information will be made public. Important project if your organization uses contractors and outsourcers to design, build or deploy important applications. Jim Routh, CISO at Depository Trust and Clearing Corporation (and one of the top CISOs in implementing application security), leads a broad industry team identifying leading practices in improving supply chain resiliency -- specifically in the area of procurement for outsourcing software development and services. They have asked for your help in finding sources of information in the public domain and/or descriptions of a practice or control that you have used that actually mitigates one or more risks. If you have experience or knowledge of security controls and practices specific to the outsourcing of application development through service providers please send a note to Mason Brown at mbrown at sans.org. This can include things like sample contract language or URLs information/resources you have seen or used. We will provide a summary of the information to anyone who contributes or expresses and interest in seeing the results. *************************** Action Required: Give some thought to helpful information on security controls and practices specific to the outsourcing of application development work through service providers that will help improve the resiliency of the supply chain that may be in two categories: 1. Source information in the public domain with reference information on where to find it (eg: url) 2. Description of a practice/control along with a summary of the risks mitigated We are striving to create a summary of practices/controls for consideration for those organizations interested in significantly increasing their supply chain resiliency and mitigate the risk of sabotage of supply chain sources. This information along with the survey results will provide the information security professional with a source of information enabling him/her to determine the appropriate practices/controls for his/her organization. Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power From lists at ticm.com Sat Mar 21 06:32:46 2009 From: lists at ticm.com (Bret Watson) Date: Sat, 21 Mar 2009 20:32:46 +0900 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: References: Message-ID: <49c4d07d.11bd720a.0be8.ffffabea@mx.google.com> Which is why I list that I have _had_ a CISSP, but am currently non-financial.. It was too damn easy to pass and too damn hard to keep up with the CPE point entry... :) I was LAMN member #8 :) Best number :) Cheers Bret At 03:38 PM 21/03/2009, Joe Teff wrote: >I notice certs like CISSP when hiring. It says the person has a >basic understanding of all IS security areas. Nothing more. If >someone can't pass the CISSP then I have to wonder why. > >-----Original Message----- >From: Paco Hope >To: "SC-L at securecoding.org" >Date: Thu, 19 Mar 2009 11:36:45 -0400 >Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs > >On 3/18/09 5:29 PM, "Jeremy Epstein" wrote: > > > If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it > >...then I'd say you have an overly simplistic view of the world. > >Anyone who believes that a credential automatically conveys some magical >knowledge that you didn't have before is just as overly-simplistic as >someone who disparages all credentials equally. It just isn't a black and >white world. > >Paco >-- >Paco Hope, CISSP, CSSLP >Technical Manager, Cigital, Inc >http://www.cigital.com/ ? +1.703.585.7868 >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. >_______________________________________________ > >_______________________________________________ >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 Sat Mar 21 07:51:09 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Sat, 21 Mar 2009 08:51:09 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: References: Message-ID: <49C4E2BD.60907@secureconsulting.net> fwiw, I've interviewed my fair share of CISSPs who didn't have a basic understanding of infosec... with the boot camps these days, people don't "learn" anything... they cram for 1-2 wks, shoving everything into short-term rote memory, and then they take the test and promptly forget everything... this is especially true since the feds began mandating CISSPs for contractors... at least here in the DC metro, the pool of candidates has become extremely watered down over the last 5 or so years... Joe Teff wrote: > I notice certs like CISSP when hiring. It says the person has a basic > understanding of all IS security areas. Nothing more. If someone can't > pass the CISSP then I have to wonder why. > > -----Original Message----- > From: Paco Hope > To: "SC-L at securecoding.org" > Date: Thu, 19 Mar 2009 11:36:45 -0400 > Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless > certificatioNs > > On 3/18/09 5:29 PM, "Jeremy Epstein" wrote: > > > If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud > of it > > ...then I'd say you have an overly simplistic view of the world. > > Anyone who believes that a credential automatically conveys some magical > knowledge that you didn't have before is just as overly-simplistic as > someone who disparages all credentials equally. It just isn't a > black and > white world. > > Paco > -- > Paco Hope, CISSP, CSSLP > Technical Manager, Cigital, Inc > http://www.cigital.com/ ? +1.703.585.7868 > 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. > _______________________________________________ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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. > _______________________________________________ -- 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: ] "I think there should be something in science called the 'reindeer effect.' I don't know what it would be, but I think it'd be good to hear someone say, 'Gentlemen, what we have here is a terrifying example of the reindeer effect.'" Deep Thoughts by Jack Handy From jim at manico.net Sat Mar 21 17:43:59 2009 From: jim at manico.net (Jim Manico) Date: Sat, 21 Mar 2009 12:43:59 -1000 Subject: [SC-L] Announcing LAMN: Legion AgainstMeaningless certificatioNs References: Message-ID: <0FFAE225523A43DC867E5331C8784D63@workhorse> It really depends on what you are hiring for. If we are talking App/Software security - like Gary has said many times - I would rather hire a software guy and train them about security. Doing it the other way around is almost impossible. How can you really do software security if you are netsec expert with no experience writing real software? This is especially true if you are taking a more strategic approach to software security. And the opposite is true - hiring a coder to lock down a network probably isn't the best hiring choice! =) What really bothers me is that the CSSLP looks appsec operations focused - not developer SDLC focused (or so I've heard). The SANS cert for software security seems to drill a lot more into actual activities a developer should take in order write secure code and seems somewhat reasonable to me. I think a secure software architecture cert would round out current offerings well. ----- Original Message ----- From: Joe Teff To: SC-L at securecoding.org Sent: Friday, March 20, 2009 8:38 PM Subject: Re: [SC-L] Announcing LAMN: Legion AgainstMeaningless certificatioNs I notice certs like CISSP when hiring. It says the person has a basic understanding of all IS security areas. Nothing more. If someone can't pass the CISSP then I have to wonder why. -----Original Message----- From: Paco Hope To: "SC-L at securecoding.org" Date: Thu, 19 Mar 2009 11:36:45 -0400 Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs On 3/18/09 5:29 PM, "Jeremy Epstein" wrote: > If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it ...then I'd say you have an overly simplistic view of the world. Anyone who believes that a credential automatically conveys some magical knowledge that you didn't have before is just as overly-simplistic as someone who disparages all credentials equally. It just isn't a black and white world. Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ ? +1.703.585.7868 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. _______________________________________________ ------------------------------------------------------------------------------ _______________________________________________ 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/20090321/db00672c/attachment.html From gem at cigital.com Sun Mar 22 08:26:56 2009 From: gem at cigital.com (Gary McGraw) Date: Sun, 22 Mar 2009 09:26:56 -0400 Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: <5148989F3B174D17B5153CF14351C97D@BROWN3> Message-ID: hi sc-l, For what it's worth, I am involved in the project with jmr...as is Sammy Migues. jmr was our BSIMM participant from DTCC. Their software security initiative is most impressive. gem On 3/22/09 9:08 AM, "Mason Brown" wrote: Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a project for the Financial Services ISAC. There is a lot of knowledge on this list and I was hoping you might be willing to offer your thoughts. Below is the request from Jim. If you have thoughts or data and could share it, I'll be happy to collate and send back to the list or to anyone that requests. After he presents it to the FS-ISAC in May, the complete information will be made public. Important project if your organization uses contractors and outsourcers to design, build or deploy important applications. Jim Routh, CISO at Depository Trust and Clearing Corporation (and one of the top CISOs in implementing application security), leads a broad industry team identifying leading practices in improving supply chain resiliency -- specifically in the area of procurement for outsourcing software development and services. They have asked for your help in finding sources of information in the public domain and/or descriptions of a practice or control that you have used that actually mitigates one or more risks. If you have experience or knowledge of security controls and practices specific to the outsourcing of application development through service providers please send a note to Mason Brown at mbrown at sans.org. This can include things like sample contract language or URLs information/resources you have seen or used. We will provide a summary of the information to anyone who contributes or expresses and interest in seeing the results. *************************** Action Required: Give some thought to helpful information on security controls and practices specific to the outsourcing of application development work through service providers that will help improve the resiliency of the supply chain that may be in two categories: 1. Source information in the public domain with reference information on where to find it (eg: url) 2. Description of a practice/control along with a summary of the risks mitigated We are striving to create a summary of practices/controls for consideration for those organizations interested in significantly increasing their supply chain resiliency and mitigate the risk of sabotage of supply chain sources. This information along with the survey results will provide the information security professional with a source of information enabling him/her to determine the appropriate practices/controls for his/her organization. Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power _______________________________________________ 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 Sun Mar 22 18:05:47 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Sun, 22 Mar 2009 16:05:47 -0700 Subject: [SC-L] Questions asked on job interview for application security/penetration testing job In-Reply-To: <004e01c9aa6e$1866bb00$49343100$@com> References: <004e01c9aa6e$1866bb00$49343100$@com> Message-ID: On Sat, Mar 21, 2009 at 2:43 PM, Matt Parsons wrote: > I was asked the following questions on a job phone interview and wondered > what the proper answers were.?? I was told their answers after the > interview. I was also told that the answers to these questions were one or > two word words.? In the beginning of next week I will post what they told me > were the proper answers.?? Any references would be greatly appreciated. Looks simple enough. Were there tricks to it? Some companies play games with these type of interviews. (Google) I empathize with brevity. Usually when people ramble too long in interviews they don't know what they are talking about (and are extra nervous because of this). So what are the word answers? > 1.? What are the security functions of SSL? Transport layer security. Asymmetric public key, symmetric private key, blah blah > 2.? What is a 0 by 90 bytes error. Error? 0x90 is NOP. A bunch of them make a good sled. > 3.? What is a digital signature, Not what it is? Authentication > 4.? What is the problem of having a predictable sequence of bits in TCP/IP? Session Prediction (leads to etc. etc.) > 5.? What is heap memory? Pooled memory dynamically allocated, no fixed-life > 6.? What is a system call? Software call to underlying OS function ( FileOpen()) > 7.? what is two factor authentication? Two of something you have, know, or are -- Arian Evans "Let me issue and control a nation's money, and I care not who writes its laws" --Mayer Amchel Rothschild From mparsons1980 at gmail.com Sun Mar 22 14:46:13 2009 From: mparsons1980 at gmail.com (Matt Parsons) Date: Sun, 22 Mar 2009 14:46:13 -0500 Subject: [SC-L] Questions asked on job interview for application security/penetration testing job Message-ID: <007d01c9ab26$dc9e0420$95da0c60$@com> Here are the answers that I was given for the following questions by a non-technical recruiter. 1. What are the security functions of SSL? Encryption and authentication 2. What is a 0 by 90 bytes error. Buffer over flow. 3. What is a digital signature, Not what it is? The senders message is encrypted with a sender's private key and attached like a signature to an encrypted message to ensure that the person is who he claims to be. The recipient uses the sender's public key to decrypt the signature. 4. What is the problem of having a predictable sequence of bits in TCP/IP? TCP/IP session hijacking I also thought it was man in the middle attack. 5. What is heap memory? A heap memory pool is an internal memory pool created at start-up that tasks use to dynamically allocate memory as needed. 6. What is a system call? Call from the operating system. 7. what is two factor authentication? Use of something you know, something you have, something you are. Thanks Matt Parsons Matt Parsons, CISSP From: Matt Parsons [mailto:mparsons1980 at gmail.com] Sent: Saturday, March 21, 2009 4:44 PM To: 'Secure Code Mailing List' Subject: RE: Questions asked on job interview for application security/penetration testing job Ladies and gentlemen, I was asked the following questions on a job phone interview and wondered what the proper answers were. I was told their answers after the interview. I was also told that the answers to these questions were one or two word words. In the beginning of next week I will post what they told me were the proper answers. Any references would be greatly appreciated. 1. What are the security functions of SSL? 2. What is a 0 by 90 bytes error. 3. What is a digital signature, Not what it is? 4. What is the problem of having a predictable sequence of bits in TCP/IP? 5. What is heap memory? 6. What is a system call? 7. what is two factor authentication? Thanks Matt Matt Parsons, CISSP Parsons Software Security Consulting, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090322/562e3c15/attachment.html From ge at linuxbox.org Sun Mar 22 10:38:46 2009 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 22 Mar 2009 10:38:46 -0500 (CDT) Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: References: Message-ID: On Sun, 22 Mar 2009, Gary McGraw wrote: > hi sc-l, > > For what it's worth, I am involved in the project with jmr...as is Sammy Migues. jmr was our BSIMM participant from DTCC. Their software security initiative is most impressive. I don't know much TOO much about supply chain issues, but I have to admit that the lecture i heard on the subject by Marcus Sachs was highly interesting and opened my eyes. Blessed initiative. Gadi. > gem > > > On 3/22/09 9:08 AM, "Mason Brown" wrote: > > > Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a > project for the Financial Services ISAC. There is a lot of knowledge on > this list and I was hoping you might be willing to offer your thoughts. > Below is the request from Jim. If you have thoughts or data and could > share it, I'll be happy to collate and send back to the list or to anyone > that requests. After he presents it to the FS-ISAC in May, the complete > information will be made public. > > Important project if your organization uses contractors and outsourcers to > design, build or deploy important applications. Jim Routh, CISO at > Depository Trust and Clearing Corporation (and one of the top CISOs in > implementing application security), leads a broad industry team > identifying leading practices in improving supply chain resiliency -- > specifically in the area of procurement for outsourcing software > development and services. They have asked for your help in finding sources > of information in the public domain and/or descriptions of a practice or > control that you have used that actually mitigates one or > more risks. If you have experience or knowledge of security controls and > practices specific to the outsourcing of application development through > service providers please send a note to Mason Brown at mbrown at sans.org. > This can include things like sample contract language or URLs > information/resources you have seen or used. We will provide a summary of > the information to anyone who contributes or expresses and interest in > seeing the results. > > > *************************** > Action Required: > > Give some thought to helpful information on security controls and > practices specific to the outsourcing of application development work > through service providers that will help improve the resiliency of the > supply chain that may be in two categories: > > 1. Source information in the public domain with reference information on > where to find it (eg: url) > 2. Description of a practice/control along with a summary of the risks > mitigated > > We are striving to create a summary of practices/controls for > consideration for those organizations interested in significantly > increasing their supply chain resiliency and mitigate the risk of sabotage > of supply chain sources. This information along with the survey results > will provide the information security professional with a source of > information enabling him/her to determine the appropriate > practices/controls for his/her organization. > > > > Mason Brown, Director > SANS Institute (www.sans.org) > 865-692-0978 (w) > > > Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in > Baltimore, MD http://www.sans.org/info/39248 > > "SANS courses are hands-down the best security courses in the industry." - > Scott Hiltis, Bruce Power > > _______________________________________________ > 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 SMigues at cigital.com Sun Mar 22 16:15:57 2009 From: SMigues at cigital.com (Sammy Migues) Date: Sun, 22 Mar 2009 17:15:57 -0400 Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: <5148989F3B174D17B5153CF14351C97D@BROWN3> References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com><1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> <8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> <5148989F3B174D17B5153CF14351C97D@BROWN3> Message-ID: <41945506397C0C4886A8C5BFF089B5CA3993D089F9@va-mailhub.cigital.com> Hello everyone, To reinforce Mason's request, we're looking for any collection of "controls" (contractual, technical, people, process, etc.) that organizations should request, demand, cajole, enforce, etc. when out-sourcing software development to ensure the required "software security" in the resulting deliverable. For the purposes of this exercise, you can define "controls" and "software security" as broadly as you like and we'll sort it out later. Our next meeting with Jim is Tuesday afternoon and any pointers to public information, or copies of shareable non-public information, you can provide will be much appreciated. Thanks, --Sammy. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Mason Brown Sent: Sunday, March 22, 2009 9:09 AM To: 'Secure Code Mailing List' Subject: [SC-L] Supply Chain Resiliency Project Assistance Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a project for the Financial Services ISAC. There is a lot of knowledge on this list and I was hoping you might be willing to offer your thoughts. Below is the request from Jim. If you have thoughts or data and could share it, I'll be happy to collate and send back to the list or to anyone that requests. After he presents it to the FS-ISAC in May, the complete information will be made public. Important project if your organization uses contractors and outsourcers to design, build or deploy important applications. Jim Routh, CISO at Depository Trust and Clearing Corporation (and one of the top CISOs in implementing application security), leads a broad industry team identifying leading practices in improving supply chain resiliency -- specifically in the area of procurement for outsourcing software development and services. They have asked for your help in finding sources of information in the public domain and/or descriptions of a practice or control that you have used that actually mitigates one or more risks. If you have experience or knowledge of security controls and practices specific to the outsourcing of application development through service providers please send a note to Mason Brown at mbrown at sans.org. This can include things like sample contract language or URLs information/resources you have seen or used. We will provide a summary of the information to anyone who contributes or expresses and interest in seeing the results. *************************** Action Required: Give some thought to helpful information on security controls and practices specific to the outsourcing of application development work through service providers that will help improve the resiliency of the supply chain that may be in two categories: 1. Source information in the public domain with reference information on where to find it (eg: url) 2. Description of a practice/control along with a summary of the risks mitigated We are striving to create a summary of practices/controls for consideration for those organizations interested in significantly increasing their supply chain resiliency and mitigate the risk of sabotage of supply chain sources. This information along with the survey results will provide the information security professional with a source of information enabling him/her to determine the appropriate practices/controls for his/her organization. Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power _______________________________________________ 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 Sun Mar 22 13:30:31 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Sun, 22 Mar 2009 14:30:31 -0400 (EDT) Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: Message-ID: On Sat, 21 Mar 2009, ljknews wrote: > The root problem (and I do not care about the terminology) > is that the C programming language promotes the use of > uncounted strings. I'd rephrase that because buffer overflows apply to many other data types besides strings. Anything using an array of pointer arithmetic is potentially subject to overflows. I have little doubt that when you launch 200 simultaneous connections against a bunch of applications, some of them will crash because the programmer only allocated enough memory to store 100 connections at once. A lot of the IOCTL overflows going on right now are more about malformed data structures than strings, as are many of the file format vulns. - Steve From prasad.shenoy at gmail.com Sun Mar 22 15:35:12 2009 From: prasad.shenoy at gmail.com (Prasad Shenoy) Date: Sun, 22 Mar 2009 16:35:12 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: References: Message-ID: <43c6c8500903221335h74b4d1a8kd445c73e97015459@mail.gmail.com> Great idea but why would you say CISSP is meaningless or MCSE is meaningless? Certifications are like technology. They have a place where they fit. CISSP became so popular and prolific because of the vast field of coverage (10 domains) that a certified practitioner had to study, understand, relate to and practice if given a situation. I am strongly against any certification that touts that you would be able to change the world for good. As silly as it might sound, there are quite a handful of these. On the other hand, companies like CISCO and Microsoft offer certification that allow "professional" to get certified and demonstrate their ability to understand and take over the responsibility of the said position that the certificate applies to. Now, if you make a case against certifications just because it has become so easy to cram overnight and get certified in the morning, then that's not justice. There are 2 extremes to the spectrum and you see only 1. It's like giving the entire security industry (professionals with certifications mostly) becuase of a few (thousand) individuals who don't prove to be laible candidates to have obtained that certification. You can compare it to how the world panned out the meaning of the holy word "Hacker" to what it is today. Prasad On Wed, Mar 18, 2009 at 5:29 PM, Jeremy Epstein wrote: > Colleagues, > > I'm pleased to announce the creation of LAMN, the Legion Against > Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO > - and you're proud of it - this group is for you. > > You can join LAMN on LinkedIn by searching in the "groups" area. Unlike so > many other certifications, LAMN doesn't charge fees, require outrageously > overpriced exams, or demand check-the-box continuing education. > > Hope to see many people joining this group - and feel free to pass this > along! > --Jeremy > > P.S. After you join the group, you can proudly write your name , > LAMN - which conveniently also stands for Letters After My Name. I can't > recall who suggested the term to me, but would be happy to give credit if > someone wants to step forward and claim credit. > _______________________________________________ > 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. > _______________________________________________ > > -- Thought for the day - "Emails can hurt feelings. If this one did, please ignore your feelings." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090322/b9fb54b6/attachment.html From wisseman_stan at bah.com Sun Mar 22 21:20:49 2009 From: wisseman_stan at bah.com (Wisseman, Stan [USA]) Date: Sun, 22 Mar 2009 22:20:49 -0400 Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: References: <5148989F3B174D17B5153CF14351C97D@BROWN3> Message-ID: <3DDD87CF054E824191CB05B05E089BBE03BD70E8@MCLNEXVS07.resource.ds.bah.com> Hi Mason, The DHS Software Assurance Initiative has an Acquisition Working Group: https://buildsecurityin.us-cert.gov/swa/acqwg.html The efforts of the WG just got released on the NDU Press site: http://www.ndu.edu/inss/press/books/irmc.pdf The body of the document provides guidance on how to enhance the acquisition lifecycle with SwA considerations. The Appendices have suggested contract language and due diligence questions. Links to most of the references in the document are available on the resources section of the WG site, including Word versions of the questionnaires and a tutorial based on the document: https://buildsecurityin.us-cert.gov/swa/acqart.html Stan ------------------------------------ On 3/22/09 9:08 AM, "Mason Brown" wrote: Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a project for the Financial Services ISAC. There is a lot of knowledge on this list and I was hoping you might be willing to offer your thoughts. Below is the request from Jim. If you have thoughts or data and could share it, I'll be happy to collate and send back to the list or to anyone that requests. After he presents it to the FS-ISAC in May, the complete information will be made public. Important project if your organization uses contractors and outsourcers to design, build or deploy important applications. Jim Routh, CISO at Depository Trust and Clearing Corporation (and one of the top CISOs in implementing application security), leads a broad industry team identifying leading practices in improving supply chain resiliency -- specifically in the area of procurement for outsourcing software development and services. They have asked for your help in finding sources of information in the public domain and/or descriptions of a practice or control that you have used that actually mitigates one or more risks. If you have experience or knowledge of security controls and practices specific to the outsourcing of application development through service providers please send a note to Mason Brown at mbrown at sans.org. This can include things like sample contract language or URLs information/resources you have seen or used. We will provide a summary of the information to anyone who contributes or expresses and interest in seeing the results. *************************** Action Required: Give some thought to helpful information on security controls and practices specific to the outsourcing of application development work through service providers that will help improve the resiliency of the supply chain that may be in two categories: 1. Source information in the public domain with reference information on where to find it (eg: url) 2. Description of a practice/control along with a summary of the risks mitigated We are striving to create a summary of practices/controls for consideration for those organizations interested in significantly increasing their supply chain resiliency and mitigate the risk of sabotage of supply chain sources. This information along with the survey results will provide the information security professional with a source of information enabling him/her to determine the appropriate practices/controls for his/her organization. Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power _______________________________________________ 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 Mon Mar 23 07:52:15 2009 From: dave.wichers at aspectsecurity.com (Dave Wichers) Date: Mon, 23 Mar 2009 08:52:15 -0400 Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: <5148989F3B174D17B5153CF14351C97D@BROWN3> References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com><1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry><8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> <5148989F3B174D17B5153CF14351C97D@BROWN3> Message-ID: Mason, I know you and Jim are already aware of the OWASP Legal Project, which has the Secure Software Development contract annex: http://www.owasp.org/index.php/Category:OWASP_Legal_Project, which was developed by Jeff Williams. For everyone else, this guideline has been available at OWASP for many years and served as the basis for the SANS Application Security Procurement Language effort detailed here: http://www.sans.org/appseccontract/. I'm assuming this supply chain resiliency effort is a continuation of the Application Security Procurement Language effort by Jim Routh and Will Pelgrin. -Dave -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Mason Brown Sent: Sunday, March 22, 2009 9:09 AM To: 'Secure Code Mailing List' Subject: [SC-L] Supply Chain Resiliency Project Assistance Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a project for the Financial Services ISAC. There is a lot of knowledge on this list and I was hoping you might be willing to offer your thoughts. Below is the request from Jim. If you have thoughts or data and could share it, I'll be happy to collate and send back to the list or to anyone that requests. After he presents it to the FS-ISAC in May, the complete information will be made public. Important project if your organization uses contractors and outsourcers to design, build or deploy important applications. Jim Routh, CISO at Depository Trust and Clearing Corporation (and one of the top CISOs in implementing application security), leads a broad industry team identifying leading practices in improving supply chain resiliency -- specifically in the area of procurement for outsourcing software development and services. They have asked for your help in finding sources of information in the public domain and/or descriptions of a practice or control that you have used that actually mitigates one or more risks. If you have experience or knowledge of security controls and practices specific to the outsourcing of application development through service providers please send a note to Mason Brown at mbrown at sans.org. This can include things like sample contract language or URLs information/resources you have seen or used. We will provide a summary of the information to anyone who contributes or expresses and interest in seeing the results. *************************** Action Required: Give some thought to helpful information on security controls and practices specific to the outsourcing of application development work through service providers that will help improve the resiliency of the supply chain that may be in two categories: 1. Source information in the public domain with reference information on where to find it (eg: url) 2. Description of a practice/control along with a summary of the risks mitigated We are striving to create a summary of practices/controls for consideration for those organizations interested in significantly increasing their supply chain resiliency and mitigate the risk of sabotage of supply chain sources. This information along with the survey results will provide the information security professional with a source of information enabling him/her to determine the appropriate practices/controls for his/her organization. Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power _______________________________________________ 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 Mar 23 09:22:35 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 23 Mar 2009 10:22:35 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: Message-ID: hi guys, I think there is a bit of confusion here WRT "root" problems. In C, the main problem is not simply strings and string representation, but rather that the "sea of bits" can be recast to represent most anything. The technical term for the problem is the problem of type safety. C is not type safe. Building secure software in a non type safe language is much harder than building secure software in a type safe language (like Java or C#). gem (still supposedly on vacation in SC) http://www.cigital.com/~gem On 3/22/09 2:30 PM, "Steven M. Christey" wrote: On Sat, 21 Mar 2009, ljknews wrote: > The root problem (and I do not care about the terminology) > is that the C programming language promotes the use of > uncounted strings. I'd rephrase that because buffer overflows apply to many other data types besides strings. Anything using an array of pointer arithmetic is potentially subject to overflows. I have little doubt that when you launch 200 simultaneous connections against a bunch of applications, some of them will crash because the programmer only allocated enough memory to store 100 connections at once. A lot of the IOCTL overflows going on right now are more about malformed data structures than strings, as are many of the file format vulns. - 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 mbrown at sans.org Mon Mar 23 11:00:52 2009 From: mbrown at sans.org (Mason Brown) Date: Mon, 23 Mar 2009 16:00:52 +0000 (UTC) Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: References: <49C2D509.9030600@secureconsulting.net><184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com><1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry><8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> <5148989F3B174D17B5153CF14351C97D@BROWN3> Message-ID: Thanks Dave. Yeah, we have the OWASP and SANS stuff plus a bunch of other from DHS and so on. Mostly we're looking for things people have done that actually worked. IOW, examples of controls are even better than research or whitepapers. This initiative is actually unrelated to the procurement language stuff Jim and Will worked on. Although I'm sure Jim will include that in his summary. This is an Financial Services ISAC (FS-ISAC) sponsored program. It focuses on a lot more than the procurement or services angles -- this working group is just one part of a broader effort on supply chain resiliency. They will be presenting the results to FS-ISAC in May, I think. Mase Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power -----Original Message----- From: Dave Wichers [mailto:dave.wichers at aspectsecurity.com] Sent: Monday, March 23, 2009 8:52 AM To: Mason Brown; Secure Code Mailing List Subject: RE: [SC-L] Supply Chain Resiliency Project Assistance Mason, I know you and Jim are already aware of the OWASP Legal Project, which has the Secure Software Development contract annex: http://www.owasp.org/index.php/Category:OWASP_Legal_Project, which was developed by Jeff Williams. For everyone else, this guideline has been available at OWASP for many years and served as the basis for the SANS Application Security Procurement Language effort detailed here: http://www.sans.org/appseccontract/. I'm assuming this supply chain resiliency effort is a continuation of the Application Security Procurement Language effort by Jim Routh and Will Pelgrin. -Dave -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Mason Brown Sent: Sunday, March 22, 2009 9:09 AM To: 'Secure Code Mailing List' Subject: [SC-L] Supply Chain Resiliency Project Assistance Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a project for the Financial Services ISAC. There is a lot of knowledge on this list and I was hoping you might be willing to offer your thoughts. Below is the request from Jim. If you have thoughts or data and could share it, I'll be happy to collate and send back to the list or to anyone that requests. After he presents it to the FS-ISAC in May, the complete information will be made public. Important project if your organization uses contractors and outsourcers to design, build or deploy important applications. Jim Routh, CISO at Depository Trust and Clearing Corporation (and one of the top CISOs in implementing application security), leads a broad industry team identifying leading practices in improving supply chain resiliency -- specifically in the area of procurement for outsourcing software development and services. They have asked for your help in finding sources of information in the public domain and/or descriptions of a practice or control that you have used that actually mitigates one or more risks. If you have experience or knowledge of security controls and practices specific to the outsourcing of application development through service providers please send a note to Mason Brown at mbrown at sans.org. This can include things like sample contract language or URLs information/resources you have seen or used. We will provide a summary of the information to anyone who contributes or expresses and interest in seeing the results. *************************** Action Required: Give some thought to helpful information on security controls and practices specific to the outsourcing of application development work through service providers that will help improve the resiliency of the supply chain that may be in two categories: 1. Source information in the public domain with reference information on where to find it (eg: url) 2. Description of a practice/control along with a summary of the risks mitigated We are striving to create a summary of practices/controls for consideration for those organizations interested in significantly increasing their supply chain resiliency and mitigate the risk of sabotage of supply chain sources. This information along with the survey results will provide the information security professional with a source of information enabling him/her to determine the appropriate practices/controls for his/her organization. Mason Brown, Director SANS Institute (www.sans.org) 865-692-0978 (w) Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in Baltimore, MD http://www.sans.org/info/39248 "SANS courses are hands-down the best security courses in the industry." - Scott Hiltis, Bruce Power _______________________________________________ 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 andrews at rbacomm.com Mon Mar 23 12:37:11 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Mon, 23 Mar 2009 12:37:11 -0500 Subject: [SC-L] The Importance of Type Safety In-Reply-To: References: Message-ID: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> Sure, but I would challenge that it is a rather meaningless statement. I can keep my children safer if I keep them inside and eliminate all the sharp corners, but then they will never get to use the swimming pool in our back yard. Type safety can be good and appropriate, but it is not the only factor. Perhaps we will get to a world where all the "management overhead" doesn't matter, but until then, the extra cost for type safety should be weighed against other factors, not just discounted out of hand. Getting back to the topic at hand, perhaps building a Sauder cabinet is less likely to end up having you harm yourself with tools, but the end product is not always as strong. The "price" of having more structure is the loss of some high end features. That said, I own some such shelving and they work fairly well, but I don't discount building shelves (letting someone else do the work) because of a higher "risk" doing so. Just a thought. Brad Quoting Gary McGraw : > Building secure software in a non type safe language is much harder > than building secure software in a type safe language (like Java or > C#). From alphonce at cse.Buffalo.EDU Mon Mar 23 13:16:39 2009 From: alphonce at cse.Buffalo.EDU (Carl Alphonce) Date: Mon, 23 Mar 2009 14:16:39 -0400 Subject: [SC-L] The Importance of Type Safety In-Reply-To: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> References: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> Message-ID: <49C7D207.4080406@cse.buffalo.edu> Brad Andrews wrote: > Perhaps we will get to a world where all the "management overhead" > doesn't matter, but until then, the extra cost for type safety should > be weighed against other factors, not just discounted out of hand. I usually just lurk on this list, but in this case I'll bite - what is the cost of type safety that you're concerned about? ------------------------------------------------------------------------ () ascii ribbon campaign - against html e-mail /\ ------------------------------------------------------------------------ Carl Alphonce alphonce at cse.buffalo.edu Dept of Computer Science and Engineering (716) 645-3180 x115 (tel) University at Buffalo (716) 645-3464 (fax) Buffalo, NY 14260-2000 www.cse.buffalo.edu/faculty/alphonce From rklists at gmail.com Mon Mar 23 13:57:00 2009 From: rklists at gmail.com (Rohit Lists) Date: Mon, 23 Mar 2009 14:57:00 -0400 Subject: [SC-L] Supply Chain Resiliency Project Assistance In-Reply-To: References: <49C2D509.9030600@secureconsulting.net> <184D5FFC5203644FB4F8864B0EE445B401F4ABBF@MCLNEXVS06.resource.ds.bah.com> <1388449411-1237573720-cardhu_decombobulator_blackberry.rim.net-1616216087-@bxe1118.bisx.prod.on.blackberry> <8497994E-2936-466A-9150-872BFC95C809@arctecgroup.net> <5148989F3B174D17B5153CF14351C97D@BROWN3> Message-ID: Mase, I'm excited to see what FS-ISAC comes up with at the conference. In my experience, the OWASP Secure Contract Annex is a great resource. That said, sometimes people are looking for an interim "quick and dirty" way to evaluate vendors for security while they work on building application security into the contact language and throughout the procurement process. We're working with a few different companies on this problem right now. What I've seen work is to get the software vendor's lead lead developer/architect on the phone with an application security SME. You can gauge a lot through a simple conversation by asking a few pointed questions: * Describe your process for training developers on software security. Be specific about what guides/books/courses you use * What tools do you use to perform security runtime and static analysis testing? * How do you integrate security into the earlier phases of the SDLC - e.g. requirements, architecture and design? It might also be a good idea to ask a few more technical questions: * How do you protect against SQL injection? * How to you protect against parameter manipulation attacks? If every answer consists entirely of "We use 128-bit encryption" and "We have a firewall" (yes people really do say that) then you have a red flag. If you're evaluating a set of different vendors then you can assign scores to each answer and rank the summary of scores against oneanother. Of course this process is extremely subjective and has several obvious limitations as compared to more rigorous methods that require supporting documentation. That said, I believe it's a good idea to have an informal process in the interim rather than no way to evaluate security whatsoever. Cheers, Rohit On Mon, Mar 23, 2009 at 12:00 PM, Mason Brown wrote: > > Thanks Dave. ?Yeah, we have the OWASP and SANS stuff plus a bunch of other > from DHS and so on. ?Mostly we're looking for things people have done that > actually worked. ?IOW, examples of controls are even better than research > or whitepapers. > > This initiative is actually unrelated to the procurement language stuff > Jim and Will worked on. ?Although I'm sure Jim will include that in his > summary. ?This is an Financial Services ISAC (FS-ISAC) sponsored program. > It focuses on a lot more than the procurement or services angles -- this > working group is just one part of a broader effort on supply chain > resiliency. ?They will be presenting the results to FS-ISAC in May, I > think. > > Mase > > > Mason Brown, Director > SANS Institute (www.sans.org) > 865-692-0978 (w) > > > Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in > Baltimore, MD http://www.sans.org/info/39248 > > "SANS courses are hands-down the best security courses in the industry." - > Scott Hiltis, Bruce Power > > > -----Original Message----- > From: Dave Wichers [mailto:dave.wichers at aspectsecurity.com] > Sent: Monday, March 23, 2009 8:52 AM > To: Mason Brown; Secure Code Mailing List > Subject: RE: [SC-L] Supply Chain Resiliency Project Assistance > > Mason, > > I know you and Jim are already aware of the OWASP Legal Project, which has > the Secure Software Development contract annex: > http://www.owasp.org/index.php/Category:OWASP_Legal_Project, which was > developed by Jeff Williams. > > For everyone else, this guideline has been available at OWASP for many > years and served as the basis for the SANS Application Security > Procurement Language effort detailed here: > http://www.sans.org/appseccontract/. > > I'm assuming this supply chain resiliency effort is a continuation of the > Application Security Procurement Language effort by Jim Routh and Will > Pelgrin. > > -Dave > > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Mason Brown > Sent: Sunday, March 22, 2009 9:09 AM > To: 'Secure Code Mailing List' > Subject: [SC-L] Supply Chain Resiliency Project Assistance > > > Jim Routh, CISO at Depository Trust and Clearing Corporation is leading a > project for the Financial Services ISAC. ?There is a lot of knowledge on > this list and I was hoping you might be willing to offer your thoughts. > Below is the request from Jim. ?If you have thoughts or data and could > share it, I'll be happy to collate and send back to the list or to anyone > that requests. ?After he presents it to the FS-ISAC in May, the complete > information will be made public. > > Important project if your organization uses contractors and outsourcers to > design, build or deploy important applications. Jim Routh, CISO at > Depository Trust and Clearing Corporation (and one of the top CISOs in > implementing application security), leads a broad industry team > identifying leading practices in improving supply chain resiliency -- > specifically in the area of procurement for outsourcing software > development and services. They have asked for your help in finding sources > of information in the public domain and/or descriptions of a practice or > control that you have used that actually mitigates one or more risks. If > you have experience or knowledge of security controls and practices > specific to the outsourcing of application development through service > providers please send a note to Mason Brown at mbrown at sans.org. > This can include things like sample contract language or URLs > information/resources you have seen or used. We will provide a summary of > the information to anyone who contributes or expresses and interest in > seeing the results. > > > *************************** > Action Required: > > Give some thought to helpful information on security controls and > practices specific to the outsourcing of application development work > through service providers that will help improve the resiliency of the > supply chain that may be in two categories: > > 1. Source information in the public domain with reference information on > where to find it (eg: url) 2. Description of a practice/control along with > a summary of the risks mitigated > > We are striving to create a summary of practices/controls for > consideration for those organizations interested in significantly > increasing their supply chain resiliency and mitigate the risk of sabotage > of supply chain sources. This information along with the survey results > will provide the information security professional with a source of > information enabling him/her to determine the appropriate > practices/controls for his/her organization. > > > > Mason Brown, Director > SANS Institute (www.sans.org) > 865-692-0978 (w) > > > Don't miss SANSFIRE 2009 with the Internet Storm Center! June 13-22 in > Baltimore, MD http://www.sans.org/info/39248 > > "SANS courses are hands-down the best security courses in the industry." > - > Scott Hiltis, Bruce Power > > _______________________________________________ > 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. > _______________________________________________ > -- Rohit Sethi Security Compass http://www.securitycompass.com From securecoding at nxtg.net Mon Mar 23 14:46:52 2009 From: securecoding at nxtg.net (AF) Date: Mon, 23 Mar 2009 20:46:52 +0100 Subject: [SC-L] The Importance of Type Safety In-Reply-To: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> References: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> Message-ID: <49C7E72C.1080101@nxtg.net> Brad Andrews wrote: > [..] > Perhaps we will get to a world where all the "management overhead" > doesn't matter, but until then, the extra cost for type safety should > be weighed against other factors, not just discounted out of hand. > Hi Brad, Could you please explain what you mean by "the extra cost for type safety"? regards, Antonio Fontes From Paco at cigital.com Mon Mar 23 15:22:52 2009 From: Paco at cigital.com (Paco Hope) Date: Mon, 23 Mar 2009 16:22:52 -0400 Subject: [SC-L] CSSLP In-Reply-To: <0FFAE225523A43DC867E5331C8784D63@workhorse> Message-ID: On 3/21/09 6:43 PM, "Jim Manico" wrote: > What really bothers me is that the CSSLP looks appsec operations focused - not > developer SDLC focused (or so I've heard). The SANS cert for software > security seems to drill a lot more into actual activities a developer should > take in order write secure code and seems somewhat reasonable to me. I think a > secure software architecture cert would round out current offerings well. As a SME for that exam (i.e., one of the guys who makes exam questions and such), you're exactly right. It definitely is skewed towards a holistic, operations-type feel. However, you've misidentified its target. The target of the CSSLP is anyone involved in the software (though perhaps we should say "system") development lifecycle. It targets not just developers, but also testers, release managers, test managers, and others who are important to the big picture of getting software out the door. It's not a certified secure developer (i.e., code-slinger). The person who holds the cert should be acquainted with security in more phases of the lifecycle than just one. It does not, however, certify them as a security ninja in any phase. There was another comment about the CISSP that I found poignant: "It was too damn easy to pass and too damn hard to keep up with the CPE point entry..." Although point entry is tedious, it keeps the cert honest. You can't spend 3 years converting oxygen into CO2 and remain certified. You actually have to do a few things. A CISSP person who has renewed once or twice is quite different from someone who has passed the exam after a cram session. Someone who certified once and lets their certification lapse is indistinguishable from the marginally-qualified candidate who crammed, passed, but ultimately couldn't maintain their cert. To reject certifications altogether is (to me) to endorse a continuation of the wild, wild west attitude towards security. Hire the best gunslinger you can get, and figure out who that is by word of mouth, rumor, and wanted posters at the post office. Like it or not, the citizens of this wild west are going to demand governance by a recognizable authority. Sooner or later these badge-wearing officials will come to town, and the scofflaws will be marginalized. The era of Wild Bill Hickock and Billy the Kid are over. It's only a matter of time before, for better or worse, the law moves in. We need to be on the right side, shaping those laws, not avoiding them. (Apologies to our international audience for an intensely US-centric metaphor) Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ ? +1.703.585.7868 Software Confidence. Achieved. From gem at cigital.com Mon Mar 23 09:14:18 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 23 Mar 2009 10:14:18 -0400 Subject: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs In-Reply-To: <43c6c8500903221335h74b4d1a8kd445c73e97015459@mail.gmail.com> Message-ID: Hi sc-l, I tend to agree with Prasad, though in a fit of fractal possibility, I also agree with Jeremy. Turns out I wrote something about this very issue in May 2007 for darkreading: Certifiable http://www.darkreading.com/document.asp?doc_id=123606 gem (supposedly on vacation in SC) http://www.cigital.com/~gem On 3/22/09 4:35 PM, "Prasad Shenoy" wrote: Great idea but why would you say CISSP is meaningless or MCSE is meaningless? Certifications are like technology. They have a place where they fit. CISSP became so popular and prolific because of the vast field of coverage (10 domains) that a certified practitioner had to study, understand, relate to and practice if given a situation. I am strongly against any certification that touts that you would be able to change the world for good. As silly as it might sound, there are quite a handful of these. On the other hand, companies like CISCO and Microsoft offer certification that allow "professional" to get certified and demonstrate their ability to understand and take over the responsibility of the said position that the certificate applies to. Now, if you make a case against certifications just because it has become so easy to cram overnight and get certified in the morning, then that's not justice. There are 2 extremes to the spectrum and you see only 1. It's like giving the entire security industry (professionals with certifications mostly) becuase of a few (thousand) individuals who don't prove to be laible candidates to have obtained that certification. You can compare it to how the world panned out the meaning of the holy word "Hacker" to what it is today. Prasad On Wed, Mar 18, 2009 at 5:29 PM, Jeremy Epstein wrote: Colleagues, I'm pleased to announce the creation of LAMN, the Legion Against Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it - this group is for you. You can join LAMN on LinkedIn by searching in the "groups" area. Unlike so many other certifications, LAMN doesn't charge fees, require outrageously overpriced exams, or demand check-the-box continuing education. Hope to see many people joining this group - and feel free to pass this along! --Jeremy P.S. After you join the group, you can proudly write your name , LAMN - which conveniently also stands for Letters After My Name. I can't recall who suggested the term to me, but would be happy to give credit if someone wants to step forward and claim credit. _______________________________________________ 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 andrews at rbacomm.com Mon Mar 23 16:58:30 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Mon, 23 Mar 2009 16:58:30 -0500 Subject: [SC-L] The Importance of Type Safety In-Reply-To: <49C7E72C.1080101@nxtg.net> References: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> <49C7E72C.1080101@nxtg.net> Message-ID: <20090323165830.ftyfhzw6s8s4g8cg@webmail.rbacomm.com> It may not always be true, but languages with stronger type safety normally also have a larger execution overhead. This is somewhat unavoidable since the extra checking to make sure the types match does take machine cycles. Of course the compiler can enforce a lot of these rules, so some of the performance hit could be at compile time, but it is still there. In addition, you lose some flexibility. Its kind of like swimming with water wings (to continue my pool analogy). You are much less likely to drown, they limit what you can do at the same time. You are not likely to pick up too many things off the bottom of the pool with water wings on, unless you are really creative and strong. The flexibility in C/C++ remains there for a reason - it is helpful to at least some sorts of problems. It may or may not be the best for security, but it is a "cost" that should be considered as well as compile or run-time performance. Does this help? Brad Quoting AF : > Brad Andrews wrote: >> [..] >> Perhaps we will get to a world where all the "management overhead" >> doesn't matter, but until then, the extra cost for type safety should >> be weighed against other factors, not just discounted out of hand. >> > Hi Brad, > Could you please explain what you mean by "the extra cost for type safety"? From floodeen at gmail.com Mon Mar 23 16:36:52 2009 From: floodeen at gmail.com (Rob Floodeen) Date: Mon, 23 Mar 2009 17:36:52 -0400 Subject: [SC-L] CSSLP In-Reply-To: References: <0FFAE225523A43DC867E5331C8784D63@workhorse> Message-ID: <2f1215010903231436l14abf591hc6be36f2782f34d0@mail.gmail.com> Paco, Does certification belong in the realm of Secure Coding? What is it we are really trying to achieve with a certification? -Rob On Mon, Mar 23, 2009 at 4:22 PM, Paco Hope wrote: > On 3/21/09 6:43 PM, "Jim Manico" wrote: > >> What really bothers me is that the CSSLP looks appsec operations focused - not >> developer SDLC focused (or so I've heard). The SANS cert for software >> security seems to drill a lot more into actual activities a developer should >> take in order write secure code and seems somewhat reasonable to me. I think a >> secure software architecture cert would round out current offerings well. > > As a SME for that exam (i.e., one of the guys who makes exam questions and > such), you're exactly right. It definitely is skewed towards a holistic, > operations-type feel. However, you've misidentified its target. > > The target of the CSSLP is anyone involved in the software (though perhaps > we should say "system") development lifecycle. It targets not just > developers, but also testers, release managers, test managers, and others > who are important to the big picture of getting software out the door. It's > not a certified secure developer (i.e., code-slinger). The person who holds > the cert should be acquainted with security in more phases of the lifecycle > than just one. It does not, however, certify them as a security ninja in any > phase. > > There was another comment about the CISSP that I found poignant: "It was too > damn easy to pass and too damn hard to keep up with the CPE point entry..." > > Although point entry is tedious, it keeps the cert honest. You can't spend 3 > years converting oxygen into CO2 and remain certified. You actually have to > do a few things. A CISSP person who has renewed once or twice is quite > different from someone who has passed the exam after a cram session. Someone > who certified once and lets their certification lapse is indistinguishable > from the marginally-qualified candidate who crammed, passed, but ultimately > couldn't maintain their cert. > > To reject certifications altogether is (to me) to endorse a continuation of > the wild, wild west attitude towards security. Hire the best gunslinger you > can get, and figure out who that is by word of mouth, rumor, and wanted > posters at the post office. Like it or not, the citizens of this wild west > are going to demand governance by a recognizable authority. Sooner or later > these badge-wearing officials will come to town, and the scofflaws will be > marginalized. The era of Wild Bill Hickock and Billy the Kid are over. It's > only a matter of time before, for better or worse, the law moves in. We need > to be on the right side, shaping those laws, not avoiding them. > > (Apologies to our international audience for an intensely US-centric > metaphor) > > Paco > -- > Paco Hope, CISSP, CSSLP > Technical Manager, Cigital, Inc > http://www.cigital.com/ ? +1.703.585.7868 > 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. > _______________________________________________ > From jeremy.j.epstein at gmail.com Mon Mar 23 20:58:02 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Mon, 23 Mar 2009 21:58:02 -0400 Subject: [SC-L] The Importance of Type Safety In-Reply-To: <20090323165830.ftyfhzw6s8s4g8cg@webmail.rbacomm.com> References: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> <49C7E72C.1080101@nxtg.net> <20090323165830.ftyfhzw6s8s4g8cg@webmail.rbacomm.com> Message-ID: This is kind of a funny discussion, to those of us over a "certain age". When I was a young-un :-), the argument was that you couldn't write real software in a "high level" language like C because it was too inefficient compared to assembly language, and you lost flexibility since you didn't have direct hardware access. Then someone actually measured it, and discovered that writing in a higher level language yielded more efficient programs, because programmers could focus on the bigger picture. Plus, optimizing compilers helped reduce the difference through better optimization than most programmers could do by hand. And the very small portion that needed the hardware access could be handled specially. A decade or so ago, we heard the same thing about Java - can't write "real" code in it because it's too inefficient. But Java compilers have gotten better, and the high level abstractions allow programmers to focus on the important stuff, and not on some of the details (like bounds checking). My bet is that if someone repeated the assembly vs. C experiment, they'd find that writing in Java is (for most people) more efficient than writing in C. Yes, there are some C programmers who can write more efficient code - but not most. Similarly for flexibility - yes, there are things you can't do in Java, but most of them are things you shouldn't be doing anyway... --Jeremy From lists at ticm.com Tue Mar 24 07:14:56 2009 From: lists at ticm.com (Bret Watson) Date: Tue, 24 Mar 2009 21:14:56 +0900 Subject: [SC-L] CSSLP In-Reply-To: <2f1215010903231436l14abf591hc6be36f2782f34d0@mail.gmail.co m> References: <0FFAE225523A43DC867E5331C8784D63@workhorse> <2f1215010903231436l14abf591hc6be36f2782f34d0@mail.gmail.com> Message-ID: <49c8cf3a.1f068e0a.43cd.1446@mx.google.com> > > > Although point entry is tedious, it keeps the cert honest. You > can't spend 3 > > years converting oxygen into CO2 and remain certified. You actually have to > > do a few things. A CISSP person who has renewed once or twice is quite > > different from someone who has passed the exam after a cram > session. Someone > > who certified once and lets their certification lapse is indistinguishable > > from the marginally-qualified candidate who crammed, passed, but ultimately > > couldn't maintain their cert. OK I'll bite... 1. entering the CPE points was the drag - the interface was horrible and slow. 2. I didn't do a cram session - after 12 years as a it security manager I passed it in 40 minutes (and I had actually been through the questions three times by then) 3. To be honest I didn't expect otherwise - the exam was intended to certify people with the appropriate experience - originally, then someone found out what a money spinner it was to run cram schools for it since the questions are multiple choice - that is where the value of CISSP was lost. To me having a CISSP is a good measure when I'm looking for a mid-level consultant, not a junior. If the mid-level consultant doesn't have the CISSP - then good chance they are padding their experience. However if they renew it - I just consider their last company was willing to fund it. I find certifications are useful for two things only 1. it proves you can pass the exam, no matter that you went to the cram school or not - something must have stuck. 2. HR likes it because its easy to filter resumes Without the experience - someone with a cert is like someone with a degree - no experience to be able to convert knowledge into practice. Of course certs with real practical exams are something else - I'll pay them any day. SANS, CISCO, MS all have these and they have real value - you can't cram for them and they actually test your ability to extrapolate from your knowledge into the real world. Cheers Bret From steingra at gmail.com Tue Mar 24 13:50:03 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Tue, 24 Mar 2009 11:50:03 -0700 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: Message-ID: <490a979e0903241150p425c98e0idd748c818906728@mail.gmail.com> On Mon, Mar 23, 2009 at 7:22 AM, Gary McGraw wrote: > hi guys, > > I think there is a bit of confusion here WRT "root" problems. In C, the > main problem is not simply strings and string representation, but rather > that the "sea of bits" can be recast to represent most anything. The > technical term for the problem is the problem of type safety. C is not type > safe. Really? It isn't that the standard von Neumann architecture doesn't differentiate between data and code? We've gone over this ground before with stack-machines like the Burroughs B5500 series which were not susceptible to buffer overflows that changed control flow because code and data were truly distinct chunks of memory. Sure its a different programming/hardware model, but if you want to fix the root cause you'll have to go deeper than language choice right? You might have other tradeoffs but the core problem here isn't just type safety. Just like in the HTML example. The core problem is that the language/format mixes code and data with no way to differentiate between them. Or is my brain working too slowly today? -- Andy Steingruebl steingra at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090324/9f5dd68c/attachment.html From jsteven at cigital.com Tue Mar 24 20:51:10 2009 From: jsteven at cigital.com (John Steven) Date: Tue, 24 Mar 2009 21:51:10 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: <66E3B4EA94D84A469ED42817F796DF1C@workhorse> References: <49C2D509.9030600@secureconsulting.net> <1278681275-1237581458-cardhu_decombobulator_blackberry.rim.net-1371722829-@bxe1156.bisx.prod.on.blackberry>, <66E3B4EA94D84A469ED42817F796DF1C@workhorse> Message-ID: <41945506397C0C4886A8C5BFF089B5CA3993D93137@va-mailhub.cigital.com> All, I'll address Jim's questions, each in turn: [Adapters] Adapters can take a few forms, but let's address three specific scenarios that fan-in to an assessment results/presentation step and a few that fan-out. [Fan in] Fan in typically comes from three sources: 1) static tools, 2) testing tools, and 3) manual analysis. Adapters that deal with fan-in have three challenges to surmount: A) Technically trans-code results from #1, #2, or #3 into a single tool's format for roll-up, or a tool-independent alternative B) Normalize results between #1, #2, and #3 so that 'apples' and 'oranges' get reported rather than 'apples' and 'cars' C) Code results with organization-specific "whathaveyou" [Challenge A - Trans-code] The good news about the tools is that they nearly all export to some XML format you can manipulate. This tackles output from #1 and #2. Organizations that adopted any tool early have struggled with keeping up with format changes but have indicated to me that they're willing to pay this small price for the ability to 'plug' that many results into their developers' bug-tracking systems. A bigger challenge (effort and therefore cost-wise) is getting manual results (#3) into either the format driven by the tool responsible for reporting or that independent format I described. Smart consulting firms have built 'emselves workflow to manage this. In the '90's we at Cigital used to pine for the report-generating automation of our then-competitor @Stake and waffle about whether our client-base was too disparate and our assessments too varied in scope to support a similar trick. I see no reason not to, within an organization, code up something that helps--technically--integrate your manual review findings with those found by tools. [Challenge B - Normalize] Manual reviewers report to me their discomfort with the rigidity of systems like "The Seven Kingdoms" and its competitors. Mind you, I don't dislike these taxonomies, but people get crotchety and might complain if they're forced to cram their findings down into a SAST or DAST report. They perceive, it would seem, the vulnerabilities they find to be like snowflakes ;-) An independent format can be successful as well. One can roll their own (for their organization), or lean heavily on the community and go with something like Mitre's CWE. At Cigital, we're involved with CWE and follow-on work but have also helped people organize their own. A critical discussion of this trade off is possible, but beyond the scope of this email. That leads us into...The cost of normalizing results between #1 and #2 eclipses the technical challenges of building the adapter. [Challenge C - 'Whathaveyou'] I would say this though: if your organization has progressed to the point where it possesses security standards (prescriptive or otherwise), they should absolutely be referenced by appropriate findings in the report. This goes for both violations of the standards and the applicability of standards that would serve to prevent or mitigate a particular risk. References to policy/standards can be augmented with best practices, if your organization makes that distinction. I've seen organizations link to internal/external resources for training and/or further information as well. If you're going to try to transition from "the bug hunt" to "building security in", one great way is to provide developers immediately-available information as they're making the mistake. [Fan out] Now, you have to 'fan out' into support for bug-tracking systems. Most organizations' security groups have at least as much battle to fight here as a security consultancy, actually. Why? Because the organization hasn't mandated a single development toolkit. The good news here is that while there may be more fan-out than there was fan-in, bug-tracking tools were built to be supplied data. Writing this portion of the adapter--a conduit between what normalized findings you've compiled and the offending team's bug tracking system is fairly (technically) straightforward. [Industry Std. 'Schema'] Sean Barnum has done a flotilla of work on this topic with Bob Martin at Mitre. I've copied him and will let them comment on this. Though it can be cumbersome or uninteresting to practitioners, I think the work they're doing is important because whether its admitted or not, work on audit, testing, and verification methodologies/standards must implicitly take a stand on defining the words you listed (finding, root cause, vuln., etc.). Where such efforts take a stand, one's organization can find alignment with their own notions quite challenging. Where it's implicit (or worse, ambiguously and poorly defined) you get lots of wasted time as assessors argue with development over semantics, next steps, and responsibilities. Each methodology has its own limitations in this department, resulting from its focus and perspective, IMO. If you look at OSSTM, there's a wealth of definition around activities, which really helps those implementing it differentiate what techniques they could apply in testing their system. Their template reporting form falls short on defining constructs such as root cause and finding and 'speaks' like an auditor's report. This doesn't do the depth and breadth of their assessing techniques justice which means, ultimately, adopting it will take a lot of work in the realm of that normalization task we treated earlier. NIST's methodology formalized controls even more producing the 800-53 publication. I need to look at their recent foray into app sec and reconsider ASVS much more closely and for much longer to make judgments in this realm. Currently, I've only considered it in the insanely and unfairly narrow context of "a set of stuff to look for". I'll follow up with you on this later this week or next. [Correlating Risk Systems] Taking your question literally: Risk systems? Most risk management companies wield Powerpoint and Excel, and as such, glue is hard to come by--let alone 'open glue'. I don't have much experience with Archer, but their glue is proprietary but their suite includes the ability to weave together policy, requirements, findings, and change/bug management. It sits outside the MS Office stack, but what little experience I've had with it wasn't necessarily positive ;-) I hope this answers your questions... if not, fire more away, -jOHN ________________________________________ From: Jim Manico [jim at manico.net] I like where your head is at - great list. Regarding: > Builds adapters so that bugs are automatically entered in tracking systems Does the industry have: 1) A standard schema for findings, root causes, vulnerabilities, etc, and the inter-relation of these key terms (and others?) 2) Standardized API's for allowing different risk systems for correlate this data? Or is it, right now, mostly proprietary glue? Curious... Also, how do you build adaptors so that manual processes are automatically entered in a tracking system? Are you just talking about content management ststems to make it easy to manual reviewers to enter data into rosk mangement software? Anyhow, I like where your head is at and it definately got me thinking. - Jim ----- Original Message ----- From: "Tom Brennan - OWASP" To: "John Steven" ; ; "Benjamin Tomhave" ; "Secure Code MailingList" Sent: Friday, March 20, 2009 10:37 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) > John Stevens for Cyber Czar! > > I have "Elect J.Stevens" bumper stickers printing, I retooled my Free > Kevin sticker press. > > Well stated ;) have a great weekend! > > -----Original Message----- > From: John Steven > > Date: Fri, 20 Mar 2009 14:35:01 > To: Benjamin Tomhave; Secure Code > MailingList > Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist > (informIT) > > > Tom, Ben, All, > > I thought I'd offer more specifics in an attempt to clarify. I train > people here to argue your position Ben: security vulnerabilities don't > count unless they affect development. To this end, we've specifically > had success with the following approaches: > > [Integrate Assessment Practices] > [What?] > Wrap the assessment activities (both tool-based and manual techniques) in > a process that: > * Normalizes findings under a common reporting vocabulary and > demonstrates impact > * Include SAST, DAST, scanning, manual, out-sourced, & ALL findings > producers in this framework > * Anchors findings in either a developmental root cause or other > software artifact: > * Use Case, reqs, design, spec, etc. > * Builds adaptors so that bugs are automatically entered in tracking > systems > * Adaptors should include both tool-based and manual findings > * Calculates impact with an agreed-upon mechanism that rates security > risk with other factors: > * Functional release criteria > * Other non-security non-functional requirements > > [Realistic?] > I believe so. Cigital's more junior consultants work on these very tasks, > and they don't require an early-adopter to fund or agree to them. There's > plenty of tooling out there to help with the adapters and plenty of > presentations/papers on risk (http://www.riskanalys.is), normalizing > findings ( http://cwe.mitre.org/.) , and assessment methodology > (http://www.cigital.com/papers/download/j15bsi.pdf). > > [Panacea?] > No. I've done research and consulting in functional testing. If you think > security is powerless against development, try spending a few years in a > tester's shoes! Functionality may be king for development and PMs, but > I've found that functional testing has little to no power. While a lack of > features may prevent software from going out the door, very rarely do I > find that functional testing can implement an effective "go/no-go" gate > from their seat in the org. That's why testing efforts seek muscle from > their friend Security (and its distant cousins under quality "Load and > Performance") to stop releases from going out the door. > > There's no reason NOT to integrate with testing efforts, reporting, and > groups: we should. There's every reason security should adhere to the same > interface everyone else does with developers (let them produce code and > let them consume bugs)... I think the steps I outlined under 'what' bring > us closer. I enjoyed Guy's book, but I don't think we need to (or can > expect to) flip organizational precedent and behavior on its head to make > progress. > > [Steering] > The above scenario doesn't allow explicitly for two key input/outputs > from the software security ecosystem: > > > 1. Handling ultra-high-priority issues in real time > 2. Adjusting and evolving to changing threat landscapes > > I've long suggested establishing a steering committee for this. > > [What?] > Establish a steering committee on which a software security, dev, > architecture, operations, and corporate risk sit. These folk should manage > the risk-model, scoring, security standards that drive the assessment > verification standard, and the definition of both short-term and > longer-term mitigating strategies. I'd argue that you'd like Industry > representation too. That organization could come in written form (like the > Top N lists) or in the form of consulting or a panel. > > When incidents or firefights come into play, absolutely allow them to be > handled out of band (albeit through a documented process), but! Not until > they've been rated with the agreed-upon model. > > [Realistic?] > Yes. I have several clients that use this structure. I speak with > non-clients that do the same. Data gathering for scoring and > prioritization is easy if you've done the steps in the previous section. > The operations guys help you grade the pertinence of your efforts to what > they're seeing 'in the wild' too. > > [Panacea?] > Does a steering committee help you respond with agility to a high-priority > threat in real time? Not explicitly. But, it does help if your > organizational stakeholders already have a working relationship and a > mutual respect. Also: I think one root cause of the underlying discomfort > (or dislike) with people's perspectives on this thread has been: > > "OK, Fine Gary... you don't like Top N lists... So what do you do?" > > Well, in my mind... The above answers that question. > > [Assessment and Tools] > Do I believe that the normalized findings will emerge only from static > analysis (or any other kind of vulnerability detection tool)? Absolutely > not. People who follow my writing know I expect dramatic(ally high and > low) numbers to be associated with tools. Let's summarize my data. > Organizations can expect: > > > * Static analysis tools to account for 15-20% of their total findings, > out of the box > * An initial false positive rate as high as 75-99% from a static > analysis tool, without tuning > * Less than 09% code coverage (by even shallow coverage metrics) from > pen-testing tools > > Qualitatively, I can tell you that I expect an overwhelming majority of > static analysis results produced in an organization to come from > customization of their adopted product. > > Simply: if you base your world view on only those things a tool (any > tool) produces, you're world view is as narrow as a Neo-con's-and will > prove about as ineffective. The same is true of those who narrow their > scope to the OWASP Top-10 or the SANS Top 25. > > [Top N Redux] > Some have left the impression that starting with a Top N list is of no > use. Please don't think I'm in this camp. In my last two presentations > I've indicated, "If you're starting from scratch these lists (or lists > intrinsically baked into a tool's capabilities for detection) are a great > place to start." and if you can't afford frequent industry interaction-use > Top N lists as a proxy for it. They're valuable, but like anything, only > to a point. > > For me, this discussion will remain circular until we think about it in > terms of measured, iterative organizational improvement. Why? Because when > an organization focuses on getting beyond a "Top N" list it will just > create their own organization-specific "Top N" list :-) If they're smart > though, they'll call it a dash board and vie for a promotion ;-) > >>From the other side? People building Top N lists know they're not a >>panacea, but also know that a lot of organizations simply can't stomach >>the kind of emotional investment that bsimm (and the ilk) come with. > > This leaves me with the following: > > [Conclusions] > Top N lists are neither necessary nor sufficient for organization success > Top N lists are necessary but not sufficient for industry success > Maturity models are neither necessary nor sufficient for organizational > success > Maturity models are necessary but not sufficient for industry success > > Always avail yourself of what the industry produces; > Never confine yourself to a single industry artifact dogmatically; > Whatever you consume from industry, improve it by making it your own; > Where-ever your are in your journey, continue to improve iteratively. > > [Related Perennial Rabbit Holes] (bonus) > Bugs vs. Flaws: John Steven'06 - > http://www.mail-archive.com/sc-l at securecoding.org/msg00888.html > Security Vs. Quality: Cowan '02 - > http://www.securityfocus.com/archive/98/304766 > > ---- > 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. > > > On 3/19/09 7:28 PM, "Benjamin Tomhave" > wrote: > > Why are we differentiating between "software" and "security" bugs? It > seems to me that all bugs are software bugs, and how quickly they're > tackled is a matter of prioritizing the work based on severity, impact, > and ease of resolution. It seems to me that, while it is problematic > that security testing has been excluded historically, our goal should > not be to establish yet another security-as-bolt-on state, but rather > leapfrog to the desired end-state where QA testing includes security > testing as well as functional testing. In fact, one could even argue > that security testing IS functional testing, but anyway... > > If you're going to innovate, you must as well jump the curve*. > > -ben > > * see Kawasaki "Art of Innovation" > http://blog.guykawasaki.com/2007/06/art_of_innovati.html > > Gary McGraw wrote: >> Aloha Jim, >> >> I agree that security bugs should not necessarily take precedence >> over other bugs. Most of the initiatives that we observed cycled ALL >> security bugs into the standard bug tracking system (most of which >> rank bugs by some kind of severity rating). Many initiatives put >> more weight on security bugs...note the term "weight" not "drop >> everything and run around only working on security." See the CMVM >> practice activities for more. >> >> The BSIMM helps to measure and then evolve a software security >> initiative. The top N security bugs activity is one of an arsenal of >> tools built and used by the SSG to strategically guide the rest of >> their software security initiative. Making this a "top N bugs of any >> kind" list might make sense for some organizations, but is not >> something we would likely observe by studying the SSG and the >> software security initiative. Perhaps we suffer from the "looking >> for the keys under the streetlight" problem. >> >> gem >> >> >> On 3/19/09 2:31 PM, "Jim Manico" wrote: >> >>> The top N lists we observed among the 9 were BUG lists only. So >>> that means that in general at least half of the defects were not >>> being identified on the "most wanted" list using that BSIMM set of >>> activities. >> >> This sounds very problematic to me. There are many standard software >> bugs that are much more critical to the enterprise than just security >> bugs. It seems foolhardy to do risk assessment on security bugs only >> - I think we need to bring the worlds of software development and >> security analysis together more. Divided we (continue to) fail. >> >> And Gary, this is not a critique of just your comment, but of >> WebAppSec at large. >> >> - Jim >> >> >> ----- Original Message ----- From: "Gary McGraw" >> To: "Steven M. Christey" Cc: "Sammy Migues" >> ; "Michael Cohen" ; "Dustin >> Sullivan" ; "Secure Code Mailing List" >> Sent: Thursday, March 19, 2009 2:50 AM >> Subject: Re: [SC-L] BSIMM: Confessions of a Software Security >> Alchemist (informIT) >> >> >>> Hi Steve, >>> >>> Sorry for falling off the thread last night. Waiting for the posts >>> to clear was not a great idea. >>> >>> The top N lists we observed among the 9 were BUG lists only. So >>> that means that in general at least half of the defects were not >>> being identified on the "most wanted" list using that BSIMM set of >>> activities. You are correct to point out that the "Architecture >>> Analysis" practice has other activities meant to ferret out those >>> sorts of flaws. >>> >>> I asked my guys to work on a flaws collection a while ago, but I >>> have not seen anything yet. Canuck? >>> >>> There is an important difference between your CVE data which is >>> based on externally observed bugs (imposed on vendors by security >>> types mostly) and internal bug data determined using static >>> analysis or internal testing. I would be very interested to know >>> whether Microsoft and the CVE consider the same bug #1 on internal >>> versus external rating systems. The difference is in the term >>> "reported for" versus "discovered internally during SDL activity". >>> >>> gem >>> >>> http://www.cigital.com/~gem >>> >>> >>> On 3/18/09 6:14 PM, "Steven M. Christey" >>> wrote: >>> >>> >>> >>> On Wed, 18 Mar 2009, Gary McGraw wrote: >>> >>>> Many of the top N lists we encountered were developed through the >>>> consistent use of static analysis tools. >>> Interesting. Does this mean that their top N lists are less likely >>> to include design flaws? (though they would be covered under >>> various other BSIMM activities). >>> >>>> After looking at millions of lines of code (sometimes >>>> constantly), a ***real*** top N list of bugs emerges for an >>>> organization. Eradicating number one is an obvious priority. >>>> Training can help. New number one...lather, rinse, repeat. >>> I believe this is reflected in public CVE data. Take a look at the >>> bugs that are being reported for, say, Microsoft or major Linux >>> vendors or most any product with a long history, and their current >>> number 1's are not the same as the number 1's of the past. >>> >>> - 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. >> _______________________________________________ >> >> > > -- > 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: ] > "Concern for man and his fate must always form the chief interest of all > technical endeavors. Never forget this in the midst of your diagrams and > equations." > Albert Einstein > _______________________________________________ > 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 eireann.leverett at ge.com Wed Mar 25 09:31:22 2009 From: eireann.leverett at ge.com (Leverett, Eireann (GE Infra, Energy)) Date: Wed, 25 Mar 2009 15:31:22 +0100 Subject: [SC-L] SC-L Digest, Vol 5, Issue 50 In-Reply-To: Message-ID: "The core problem is that the language/format mixes code and data with no way to differentiate between them." I'm with you on this one. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4432 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20090325/13e94858/attachment.bin From ken at krvw.com Wed Mar 25 10:09:52 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 25 Mar 2009 11:09:52 -0400 Subject: [SC-L] SAMM 1.0 Released! | OpenSAMM Message-ID: <38C04E3E-3510-45BC-B5AA-529DD2428BCF@krvw.com> Good news today from the Software Assurance Maturity Model (SAMM) group. http://www.opensamm.org/2009/03/samm-10-released/ Their release says: "The Beta release has been out for quite a while now (since August 2008) and lots of organizations and individuals have provided excellent feedback to help improve the model. I?ve heard lots of stories from people using SAMM (some are consulting firms, and some are development organizations) and that feedback has been some of the most valuable. This release marks the official 1.0 version of SAMM and there?s a few new pieces added: * Executive summary and introduction to the model * Improved details on applying the model to solve problems * Assessment worksheets for evaluating existing programs * Roadmaps for financial services and government organizations * Improvements and refinements to the model (I?ll cover changes individually in separate posts) Many thanks to the individual reviewers and the organizations that have volunteered time to help improve SAMM. I look forward to more active participants as we push forward with some of the future development plans for SAMM." 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/20090325/5f43ea03/attachment.bin From andrews at rbacomm.com Wed Mar 25 10:21:34 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 25 Mar 2009 10:21:34 -0500 Subject: [SC-L] Online Secure Development Training? Message-ID: <20090325102134.g9hvpl87ms8k4sgo@webmail.rbacomm.com> Does anyone know of any good CBT training on secure development, especially covering higher level issues and secure code review? Brad From chandra at list.org Wed Mar 25 13:55:06 2009 From: chandra at list.org (Pravir Chandra) Date: Wed, 25 Mar 2009 11:55:06 -0700 Subject: [SC-L] SAMM 1.0 Released! | OpenSAMM In-Reply-To: <38C04E3E-3510-45BC-B5AA-529DD2428BCF@krvw.com> References: <38C04E3E-3510-45BC-B5AA-529DD2428BCF@krvw.com> Message-ID: Hey Ken. Thanks for sending this out. I've mentioned it before, but today I'm proud to announce that the Software Assurance Maturity Model (SAMM) version 1.0 has been released and is freely available for download from http://www.opensamm.org For those unfamiliar, SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. The resources provided by SAMM will aid in: * Evaluating an organization?s existing software security practices * Building a balanced software security program in well-defined iterations * Demonstrating concrete improvements to a security assurance program * Defining and measuring security-related activities within an organization SAMM was defined with flexibility in mind such that it can be utilized by small, medium, and large organizations using any style of development. Additionally, this model can be applied organization-wide, for a single line-of-business, or even for an individual project. As an open project, SAMM content shall always remain vendor-neutral and freely available for all to use. The project has received a huge amount of attention and is keeping me busy, but we're always open to more feedback and supporters. Thanks! p. On Wed, Mar 25, 2009 at 8:09 AM, Kenneth Van Wyk wrote: > Good news today from the Software Assurance Maturity Model (SAMM) group. > > http://www.opensamm.org/2009/03/samm-10-released/ > > Their release says: > > "The Beta release has been out for quite a while now (since August 2008) and > lots of organizations and individuals have provided excellent feedback to > help improve the model. I?ve heard lots of stories from people using SAMM > (some are consulting firms, and some are development organizations) and that > feedback has been some of the most valuable. This release marks the official > 1.0 version of SAMM and there?s a few new pieces added: > > ? ?* Executive summary and introduction to the model > ? ?* Improved details on applying the model to solve problems > ? ?* Assessment worksheets for evaluating existing programs > ? ?* Roadmaps for financial services and government organizations > ? ?* Improvements and refinements to the model (I?ll cover changes > individually in separate posts) > > Many thanks to the individual reviewers and the organizations that have > volunteered time to help improve SAMM. I look forward to more active > participants as we push forward with some of the future development plans > for SAMM." > > > > 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. > _______________________________________________ > > -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From andrews at rbacomm.com Wed Mar 25 12:17:19 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 25 Mar 2009 12:17:19 -0500 Subject: [SC-L] Online Secure Development Training? In-Reply-To: References: <20090325102134.g9hvpl87ms8k4sgo@webmail.rbacomm.com> Message-ID: <20090325121719.s1txlr0wsiswc8sw@webmail.rbacomm.com> Thanks for all the replies. I did want to emphasize that I am specifically looking for CBT versions of courses, not the instructor-led variety. Someone asked me about what was available and I said I would ask around. I have only seen the instructor-led ones myself. Thanks for all the replies! :) Brad From tomb at owasp.org Wed Mar 25 10:38:54 2009 From: tomb at owasp.org (Tom Brennan) Date: Wed, 25 Mar 2009 11:38:54 -0400 Subject: [SC-L] Online Secure Development Training? In-Reply-To: <20090325102134.g9hvpl87ms8k4sgo@webmail.rbacomm.com> References: <20090325102134.g9hvpl87ms8k4sgo@webmail.rbacomm.com> Message-ID: <84eded9c0903250838t3087b137va51570b02c668e53@mail.gmail.com> Brad, take a peek at http://denimgroup.com/service_sec_training.html On Wed, Mar 25, 2009 at 11:21 AM, Brad Andrews wrote: > > Does anyone know of any good CBT training on secure development, > especially covering higher level issues and secure code review? > > Brad > _______________________________________________ > 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. > _______________________________________________ > -- Tom Brennan Board Member OWASP Foundation Tel: 973-795-1046 x112 Url: www.owasp.org From dave.wichers at aspectsecurity.com Wed Mar 25 11:41:25 2009 From: dave.wichers at aspectsecurity.com (Dave Wichers) Date: Wed, 25 Mar 2009 12:41:25 -0400 Subject: [SC-L] Online Secure Development Training? In-Reply-To: <20090325102134.g9hvpl87ms8k4sgo@webmail.rbacomm.com> References: <20090325102134.g9hvpl87ms8k4sgo@webmail.rbacomm.com> Message-ID: My company, Aspect Security, is producing a full line of secure coding CBTs based on our large curriculum of live application security training courses that we have. I am not aware of any other initiatives like this, but there might be others. -Dave -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews Sent: Wednesday, March 25, 2009 11:22 AM To: SC-L at securecoding.org Subject: [SC-L] Online Secure Development Training? Does anyone know of any good CBT training on secure development, especially covering higher level issues and secure code review? Brad _______________________________________________ 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 25 10:42:20 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 25 Mar 2009 11:42:20 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: <490a979e0903241150p425c98e0idd748c818906728@mail.gmail.com> Message-ID: Hi Andy, The code/data mix is certainly a problem. Also a problem is the way stacks grow on many particular machines, especially with common C/C++ compilers. You noted a Burroughs where things were done better. There are many others. C is usually just a sloppy mess by default. Language choice can sometimes make up for bad machine architecture, but ultimately at some level of computational abstraction they come to be the same thing. You may recall that I am a scheme guy. TI made a scheme machine that never caught on some years back (around the same time as the LISP machine...like emacs only even more bindings at least on the Symbolics ). Those machines had a fundamentally different architecture at the processor level. In any case, type safety is at the root of these decisions and makes a HUGE difference. Go back and read your lambda calculus, think about closure, symbolic representation, continuations, and first class objects and I think you'll see what I mean. http://en.wikipedia.org/wiki/Lambda_calculus gem (supposedly still on vacation, but it is a rainy day) http://www.cigital.com/~gem On 3/24/09 2:50 PM, "Andy Steingruebl" wrote: On Mon, Mar 23, 2009 at 7:22 AM, Gary McGraw wrote: hi guys, I think there is a bit of confusion here WRT "root" problems. In C, the main problem is not simply strings and string representation, but rather that the "sea of bits" can be recast to represent most anything. The technical term for the problem is the problem of type safety. C is not type safe. Really? It isn't that the standard von Neumann architecture doesn't differentiate between data and code? We've gone over this ground before with stack-machines like the Burroughs B5500 series which were not susceptible to buffer overflows that changed control flow because code and data were truly distinct chunks of memory. Sure its a different programming/hardware model, but if you want to fix the root cause you'll have to go deeper than language choice right? You might have other tradeoffs but the core problem here isn't just type safety. Just like in the HTML example. The core problem is that the language/format mixes code and data with no way to differentiate between them. Or is my brain working too slowly today? From steingra at gmail.com Wed Mar 25 11:22:52 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Wed, 25 Mar 2009 09:22:52 -0700 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: <490a979e0903241150p425c98e0idd748c818906728@mail.gmail.com> Message-ID: <490a979e0903250922y62c9ea39w7fa1ec29dfd6e18a@mail.gmail.com> Ok, so your point then is that a desire for type-safety influenced the hardware architecture of these machines. Fair enough, though I don't know enough of the history of these machines to know how accurate it is. But how can I doubt you Gary? :) I was mainly reflecting in my comments though that the programming language and the hardware architecture are coupled in terms of the resulting security model. Or they can be anyway. On Wed, Mar 25, 2009 at 8:42 AM, Gary McGraw wrote: > Hi Andy, > > The code/data mix is certainly a problem. Also a problem is the way stacks > grow on many particular machines, especially with common C/C++ compilers. > You noted a Burroughs where things were done better. There are many > others. C is usually just a sloppy mess by default. > > Language choice can sometimes make up for bad machine architecture, but > ultimately at some level of computational abstraction they come to be the > same thing. You may recall that I am a scheme guy. TI made a scheme > machine that never caught on some years back (around the same time as the > LISP machine...like emacs only even more bindings at least on the Symbolics > ). Those machines had a > fundamentally different architecture at the processor level. > > In any case, type safety is at the root of these decisions and makes a HUGE > difference. Go back and read your lambda calculus, think about closure, > symbolic representation, continuations, and first class objects and I think > you'll see what I mean. http://en.wikipedia.org/wiki/Lambda_calculus > > gem > (supposedly still on vacation, but it is a rainy day) > > http://www.cigital.com/~gem > > > On 3/24/09 2:50 PM, "Andy Steingruebl" wrote: > > > On Mon, Mar 23, 2009 at 7:22 AM, Gary McGraw wrote: > hi guys, > > I think there is a bit of confusion here WRT "root" problems. In C, the > main problem is not simply strings and string representation, but rather > that the "sea of bits" can be recast to represent most anything. The > technical term for the problem is the problem of type safety. C is not type > safe. > > Really? It isn't that the standard von Neumann architecture doesn't > differentiate between data and code? We've gone over this ground before > with stack-machines like the Burroughs B5500 series which were not > susceptible to buffer overflows that changed control flow because code and > data were truly distinct chunks of memory. > > Sure its a different programming/hardware model, but if you want to fix the > root cause you'll have to go deeper than language choice right? You might > have other tradeoffs but the core problem here isn't just type safety. > > Just like in the HTML example. The core problem is that the > language/format mixes code and data with no way to differentiate between > them. > > Or is my brain working too slowly today? > -- Andy Steingruebl steingra at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090325/b7d376e2/attachment.html From ljknews at mac.com Wed Mar 25 12:18:48 2009 From: ljknews at mac.com (ljknews) Date: Wed, 25 Mar 2009 13:18:48 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: Message-ID: At 11:42 AM -0400 3/25/09, Gary McGraw wrote: > The code/data mix is certainly a problem. Also a problem > is the way stacks grow on many particular machines, especially > with common C/C++ compilers. You noted a Burroughs where > things were done better. There are many others. C is > usually just a sloppy mess by default. > > Language choice can sometimes make up for bad machine > architecture, but ultimately at some level of computational > abstraction they come to be the same thing. You may recall > that I am a scheme guy. TI made a scheme machine that never > caught on some years back (around the same time as the LISP > machine...like emacs only even more bindings at least on the > Symbolics ). > Those machines had a fundamentally different architecture > at the processor level. Even with Ada (my favorite) it is _possible_ to violate type safety. But it requires using a construct for which managers can trivially scan the source code. And there are few cases where it is _impossible_ to program in a type-safe manner. C++ has an escape from type safety a bit harder to scan for - dropping into C. To determine the difference in the effective type safety of two languages, consider the likelihood that the _average_ programmer is going to violate type safety. You cannot manage to hire programmers exclusively from Lake Wobegon*. Worry about enforcement by the hardware architecture after you have squeezed out all errors that can be addressed by software techniques. -- Larry Kilgallen * For non-US readers, Lake Wobegon is an imaginary community where all the school children are above average. From jim at manico.net Wed Mar 25 18:41:56 2009 From: jim at manico.net (Jim Manico) Date: Wed, 25 Mar 2009 13:41:56 -1000 Subject: [SC-L] OWASP Podcast #14 - Pravir Chandra and OpenSAMM Message-ID: <906176A50D494BE39CC2E0C4ED233B27@workhorse> I just pushed OWASP Podast #14 live, an interview with Pravir Chandra. Pravir talks about the OWASP OpenSAMM project and software maturity models in general. Pravir has been deep in this space for some time and even provides us with the inside scoop as to how OpenSAMM relates to BSIMM. To listen to OWASP Podcast #14 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes! Cheers to SC-L, Jim Manico - OWASP Podcast Host -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090325/71781e3e/attachment-0001.html From steingra at gmail.com Wed Mar 25 15:00:11 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Wed, 25 Mar 2009 13:00:11 -0700 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: References: Message-ID: <490a979e0903251300i377cdcd0p257b4e6014324177@mail.gmail.com> On Wed, Mar 25, 2009 at 10:18 AM, ljknews wrote: > > Worry about enforcement by the hardware architecture after > you have squeezed out all errors that can be addressed by > software techniques.\ Larry, Given the focus we've seen fro Microsoft and protecting developers from mistakes through things like DEP, ASLR, SEH, etc. why do you think that these can't be done in parallel? I mean, we used to not have Virtual Memory or real MMUs and the developer had to make sure they didn't step on other people's pages. Hardware support for protection on pages has helped with a lot of things right? I'm not saying I'm holding out hope for hardware to solve all our problems (that would be silly) but I do think it can be fairly useful for some classes of problems and a lot more scalable/repeatable. Practical right now, no. But we're sort of in the realm of fantasy in this discussion already if we think the general mass of people writing software are going to switch languages because certain ones are more reliable.... - Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090325/dd8dcad1/attachment.html From ljknews at mac.com Wed Mar 25 15:36:24 2009 From: ljknews at mac.com (ljknews) Date: Wed, 25 Mar 2009 16:36:24 -0400 Subject: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) In-Reply-To: <490a979e0903251300i377cdcd0p257b4e6014324177@mail.gmail.com> References: <490a979e0903251300i377cdcd0p257b4e6014324177@mail.gmail.com> Message-ID: At 1:00 PM -0700 3/25/09, Andy Steingruebl wrote: > On Wed, Mar 25, 2009 at 10:18 AM, ljknews ><ljknews at mac.com> wrote: > > > Worry about enforcement by the hardware architecture after > you have squeezed out all errors that can be addressed by > software techniques.\ > > > Larry, > > Given the focus we've seen fro Microsoft and protecting developers from > mistakes through things like DEP, ASLR, SEH, etc. why do you think that > these can't be done in parallel? I don't know any of those acronyms, and I have very little to do with Microsoft. The last software of theirs I bought was Microsoft Word V5.1a, the last one _before_ they introduced Macro viruses. >I mean, we used to not have Virtual >Memory or real MMUs and the developer had to make sure they didn't step on >other people's pages. Hardware support for protection on pages has helped >with a lot of things right? Yes, but for me that was prior to 1978, and the benefit of hardware protection pales by comparison to the benefit of not programming everything in assembly language. > I'm not saying I'm holding out hope for hardware to solve all our >problems (that would be silly) but I do think it can be fairly useful for >some classes of problems and a lot more scalable/repeatable. >Practical >right now, no. But we're sort of in the realm of fantasy in this >discussion already if we think the general mass of people writing software >are going to switch languages because certain ones are more reliable.... I don't expect programmers to make that decision - I expect astute management to make that decision (wherever astute management happens to surface). Management has a lot easier time changing languages than changing hardware architectures. Sometimes the hardware is even dictated by the customer (such as when trying to sell into a particular market). -- Larry Kilgallen From securecoding at nxtg.net Thu Mar 26 04:45:28 2009 From: securecoding at nxtg.net (AF) Date: Thu, 26 Mar 2009 10:45:28 +0100 Subject: [SC-L] The Importance of Type Safety In-Reply-To: <20090323165830.ftyfhzw6s8s4g8cg@webmail.rbacomm.com> References: <20090323123711.1yyupiq2h8oc4wwk@webmail.rbacomm.com> <49C7E72C.1080101@nxtg.net> <20090323165830.ftyfhzw6s8s4g8cg@webmail.rbacomm.com> Message-ID: <49CB4EB8.8080107@nxtg.net> Actually, I thought you meant "managing costs of development with type safe languages" on the human management aspect (learning, training, design and development time, testing, etc.) and not about pure computer, compiler or runtime performance. On that aspect, I can only agree with you (mostly blindly because I don't have the knowledge to qualify these internals by myself ; ) Thank you for your answer, Antonio Fontes Brad Andrews wrote: > It may not always be true, but languages with stronger type safety > normally also have a larger execution overhead. This is somewhat > unavoidable since the extra checking to make sure the types match does > take machine cycles. Of course the compiler can enforce a lot of > these rules, so some of the performance hit could be at compile time, > but it is still there. > > In addition, you lose some flexibility. Its kind of like swimming > with water wings (to continue my pool analogy). You are much less > likely to drown, they limit what you can do at the same time. You are > not likely to pick up too many things off the bottom of the pool with > water wings on, unless you are really creative and strong. > > The flexibility in C/C++ remains there for a reason - it is helpful to > at least some sorts of problems. It may or may not be the best for > security, but it is a "cost" that should be considered as well as > compile or run-time performance. > > Does this help? > > Brad > > Quoting AF : > > >> Brad Andrews wrote: >> >>> [..] >>> Perhaps we will get to a world where all the "management overhead" >>> doesn't matter, but until then, the extra cost for type safety should >>> be weighed against other factors, not just discounted out of hand. >>> >>> >> Hi Brad, >> Could you please explain what you mean by "the extra cost for type safety"? >> > > _______________________________________________ > 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 Stephan.Neuhaus at disi.unitn.it Tue Mar 31 02:33:00 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Tue, 31 Mar 2009 09:33:00 +0200 Subject: [SC-L] CfP: MetriSec 2009 Message-ID: <569593E2-FF98-420F-ACF7-ADDEEA9C5059@disi.unitn.it> ------------------------------------------------------------------ Call for Papers MetriSec 2009 5th International Workshop on SECURITY MEASUREMENTS AND METRICS (Formerly the Workshop on Quality of Protection - QoP) http://www.cs.kuleuven.be/conference/MetriSec2009/ Affiliated with the International Symposium on Empirical Software Engineering and Measurement (ESEM) October 14, 2009 Lake Buena Vista, Florida, USA ------------------------------------------------------------------ WORKSHOP OVERVIEW Quantitative assessment is a major stumbling block for software and system security. Although some security metrics exist, they are rarely adequate. The engineering importance of metrics is intuitive: you cannot consistently improve what you cannot measure. Economics is an additional driver for security metrics: customers are unlikely to pay a premium for security if they are unable to quantify what they receive. The goal of the workshop is to foster research into security measurements and metrics and to continue building the community of individuals interested in this field. MetriSec continues the tradition started by the Quality of Protection (QoP) workshop series; this year, the new co-location with ESEM is an opportunity for the security metrics folks to meet the metrics community at large. The organizers solicit original submissions from industry and academic experts on the development and application of repeatable, meaningful measurements in the fields of software and system security. The topics of interest include, but are not limited to: * Security metrics * Security measurement and monitoring * Development of predictive models * Experimental validation of models * Formal theories of security metrics * Security quality assurance * Empirical assessment of security architectures and solutions * Mining data from attack and vulnerability repositories: e.g. CVE, CVSS * Static analysis metrics * Simulation and statistical analysis * Stochastic modeling * Security risk analysis * Industrial experience IMPORTANT DATES Abstract submission: May 28 Submission of paper: June 4 Acceptance notification: July 10 Submission of camera-ready: August 15 PUBLICATION Authors of accepted papers must present their work at the workshop. The proceedings of the workshop will be electronically published by the IEEE. PAPER SUBMISSION Submissions are sought in any of the following three categories: (a) Research papers describing original results, both theoretical and experimental, are solicited in any of the above mentioned topics. Theoretical papers should clearly state the contribution and include some initial validation. This year, experimental papers are particularly welcome. In this case authors are required to explicitly state their hypothesis, to detail the methodology used, and to describe the experiment set-up. (b) Preliminary research results or new ideas can be submitted in the form of short papers. (c) Industry experience reports are also welcome. Industry papers should have at least one author from industry or government, and will be considered for their industrial relevance. The page limit for the final proceedings version is 8 pages in double- column format; short papers are limited to 4 pages. Authors should use the ACM SIG Proceedings Template when preparing their submission. Only PDF files are accepted. PROGRAM CHAIRS Andy Ozment (US) Riccardo Scandariato (Katholieke Universiteit Leuven, BE) WEB CHAIR Thomas Heyman (Katholieke Universiteit Leuven, BE) From gunnar at arctecgroup.net Tue Mar 31 15:48:54 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 31 Mar 2009 15:48:54 -0500 Subject: [SC-L] Metricon 4.0 CFP Message-ID: http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon4.0 Metricon 4.0 CALL FOR PAPERS MetriCon 4 - The Importance of Context MetriCon 4.0 is intended as a forum for lively, practical discussion in the area of security metrics. It is a forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific approaches that demonstrate the value of security metrics with respect to a security- related goal. Topics and presentations will be selected for their potential to stimulate discussion in the workshop. MetriCon 4.0 will be a one-day event, Tuesday, August 11, 2009, co-located with the 18th USENIX Security Symposium -------------- next part -------------- A non-text attachment was scrubbed... Name: out.png Type: image/png Size: 927 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20090331/f5cf2363/attachment.png -------------- next part -------------- in Montreal, Quebec. Beginning first thing in the morning, with meals taken in the meeting room, and extending into the evening. Attendance will be by invitation and limited to 60 participants. All participants will be expected to "come with findings" and be willing to address the group in some fashion, formally or not. In keeping with the theme of The Importance of Context, preference will be given to the authors of position papers/presentations who have actual work in progress that demonstrates the value of security metrics with respect to a security-related goal. Topics that demonstrate the importance of context include: ? Data and analyses emerging from ongoing metrics efforts ? Studies in specific subject matter areas ? Time and situation-dependent aspects of security metrics ? Long-term trend analysis and forecasts ? Measures of the depth and breadth of security defenses ? Metrics definitions that can be operationalized ? Incorporating unknown vulnerabilities into security metrics ? Security and risk modeling calibrations ? Security measures in system design ? Software assurance initiatives ? Security metrics relationship to security assessments The program committee will also consider any innovative security metrics related workHow to ParticipateSubmit a short position paper or description of work done or ongoing. Your submission must be brief -- no longer than two pages including both text and graphical displays of quantitative information. Author names and affiliations should appear first in the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to the MetriCon 4.0 Program Committee -------------- next part -------------- A non-text attachment was scrubbed... Name: out.png Type: image/png Size: 927 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20090331/f5cf2363/attachment-0001.png -------------- next part -------------- . These requests to participate are due no later than noon GMT, Monday, May 25, 2009 (a hard deadline). You should receive an email acknowledgment of your submission within a day or two of posting; take action if you do not. The Program Committee will invite both attendees and presenters. Participants of either sort will be notified of acceptance quickly -- by June15, 2009. Presenters who want hardcopy materials to be distributed at the Workshop must provide originals of those materials to the Program Committee by July 27, 2009. 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. Program CommitteeJennifer Bayuk, Independent Consultant, Chair Warren Axelrod, Financial Services Technology Consortium (FSTC) Fred Cohen, Fred Cohen & Associates & California Sciences Institute Lloyd Ellam, Iceberg Networks Dan Geer, In-Q-Tel Andrew Jaquith, Forrester Research Wayne Jansen, National Institute of Standards and Technology (NIST) Gene Kim, Tripwire Gunnar Peterson, Arctec Group Chris Walsh, SurePayroll From secureCoding2dave at davearonson.com Wed Apr 1 10:25:07 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Wed, 1 Apr 2009 11:25:07 -0400 Subject: [SC-L] Certified Application Security Specialists Message-ID: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> Y'all- I think I've finally found the right certification for me! Check out the Institute for Certified Application Security Specialists, at http://www.asscert.com/ today! -Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From jeremy.j.epstein at gmail.com Wed Apr 1 11:02:19 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Wed, 1 Apr 2009 12:02:19 -0400 Subject: [SC-L] Certified Application Security Specialists In-Reply-To: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> References: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> Message-ID: The cat's out of the bag. LAMN is being acquired by ASSCERT.... we decided that some certifications *are* valid. On Wed, Apr 1, 2009 at 11:25 AM, SC-L Reader Dave Aronson wrote: > Y'all- > > I think I've finally found the right certification for me! Check out > the Institute for > Certified Application Security Specialists, at http://www.asscert.com/ today! > > -Dave > > -- > Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII > ------------------------------------| Play: davearonson.net | \/ Ribbon > "Specialization is for insects." | Life: dare2xl.com | /\ Campaign > -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web > _______________________________________________ > 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 SMigues at cigital.com Wed Apr 1 11:08:33 2009 From: SMigues at cigital.com (Sammy Migues) Date: Wed, 1 Apr 2009 12:08:33 -0400 Subject: [SC-L] Julia Allen podcast on BSIMM In-Reply-To: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> References: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> Message-ID: <41945506397C0C4886A8C5BFF089B5CA3993ECB831@va-mailhub.cigital.com> Hello everyone, Julia Allen, a senior researcher over at CERT, did a podcast with Gary, Brian, and me several weeks ago on the Building Security In Maturity Model (BSIMM). You can listen to the results over at http://www.cert.org/podcast/show/20090331mcgraw.html. We talk a little about our mindset when starting the BSIMM research and our goals for the business uses. Just as a reminder, BSIMM was released under Creative Commons license and is freely available at http://bsi-mm.com. --Sammy. From rcs at cert.org Wed Apr 1 11:33:24 2009 From: rcs at cert.org (Robert Seacord) Date: Wed, 1 Apr 2009 12:33:24 -0400 Subject: [SC-L] Julia Allen podcast on BSIMM In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3993ECB831@va-mailhub.cigital.com> References: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> <41945506397C0C4886A8C5BFF089B5CA3993ECB831@va-mailhub.cigital.com> Message-ID: I might as well plug the podcast Julia did with me as well, "Mainstreaming Secure Coding Practices". It is available at http://www.cert.org/podcast/show/20090317seacord.html rCs -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Sammy Migues Sent: Wednesday, April 01, 2009 12:09 PM To: Secure Coding Cc: Julia Allen Subject: [SC-L] Julia Allen podcast on BSIMM Hello everyone, Julia Allen, a senior researcher over at CERT, did a podcast with Gary, Brian, and me several weeks ago on the Building Security In Maturity Model (BSIMM). You can listen to the results over at http://www.cert.org/podcast/show/20090331mcgraw.html. We talk a little about our mindset when starting the BSIMM research and our goals for the business uses. Just as a reminder, BSIMM was released under Creative Commons license and is freely available at http://bsi-mm.com. --Sammy. _______________________________________________ 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 Apr 1 11:29:57 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 1 Apr 2009 12:29:57 -0400 Subject: [SC-L] Reality Check: Brad Arkin from Adobe Message-ID: hi sc-l, In the 4the episode of Reality Check, I interview Brad Arkin who runs the Software Security Group at Adobe. Brad worked for Cigital a million years ago and helped me found Cigital's SSG in 1997 (along with John Viega). He also worked for @stake and Symantec focusing on all aspects of software security with a special emphasis on training. His knowledge of software security, especially from an operational perspective is second to none. Among other things, we touch on the BSIMM. http://www.cigital.com/realitycheck/show-004/ Reality Check is a podcast series devoted entirely to practitioners running real software security initiatives. Previous victims include Steve Lipner (Microsoft), Jim Routh (DTCC), and Eric Baise (EMC). The series is syndicated by CSO Online. Your feedback is welcome. gem http://www.cigital.com/~gem From gem at cigital.com Wed Apr 1 11:37:13 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 1 Apr 2009 12:37:13 -0400 Subject: [SC-L] Reality Check: Brad Arkin from Adobe In-Reply-To: Message-ID: no prob. On 4/1/09 12:33 PM, "Bill Brenner" wrote: Folks: This will be going up tomorrow instead of today, because some work is being done to the podcast-uploading system we use. I'll give you a shout the second it launches on CSO. Thanks, Bill Brenner Senior Editor, CSO magazine/CSOonline CXO Media Inc. bbrenner at cxo.com Office phone: 1-508-988-7587 IM: bbrenner70 Twitter: BillBrenner70 LinkedIn: http://www.linkedin.com/profile?viewProfile=&key=3382655&trk=tab_pro Facebook: http://www.facebook.com/profile.php?id=1426070157&ref=name From goertzel_karen at bah.com Wed Apr 1 17:05:28 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 1 Apr 2009 18:05:28 -0400 Subject: [SC-L] Certified Application Security Specialists References: <3f4922c70904010825i149b1e08j7eff273d48c3fab7@mail.gmail.com> Message-ID: <184D5FFC5203644FB4F8864B0EE445B401F4AC7B@MCLNEXVS06.resource.ds.bah.com> Yes, yes. We know. It's April 1st and all's right with the world. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of SC-L Reader Dave Aronson Sent: Wed 01-Apr-09 11:25 To: Secure Coding Subject: [SC-L] Certified Application Security Specialists Y'all- I think I've finally found the right certification for me! Check out the Institute for Certified Application Security Specialists, at http://www.asscert.com/ today! -Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII ------------------------------------| Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web _______________________________________________ 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/20090401/6cef07ee/attachment.html From jim at manico.net Mon Apr 6 11:45:39 2009 From: jim at manico.net (Jim Manico) Date: Mon, 6 Apr 2009 05:45:39 -1000 Subject: [SC-L] OWASP Podcast 15 Message-ID: I had the pleasure of interview Dr. Brian Chess from Fortify Software for OWASP Podcast 15. Brian talked about BSIMM and more - demonstrated a lot of class as always. Have a listen! Direct Link: http://www.owasp.org/download/jmanico/owasp_podcast_15.mp3 To stay connected to the OWASP Podcast Series: OWASP Podcast Homepage: http://www.owasp.org/index.php/OWASP_Podcast RSS Feed: http://www.owasp.org/download/jmanico/podcast.xml iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 Twitter: http://twitter.com/manicode (production updates) PS: For bonus points; spot where the Berkley PhD calls OWASP members "Hippies" =D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090406/f61dc447/attachment.html From gem at cigital.com Tue Apr 7 15:37:01 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 7 Apr 2009 15:37:01 -0400 Subject: [SC-L] FSTC Message-ID: Hi sc-l, Today Brian, Sammy and I briefed an industry group in the financial services vertical called the FSTC (Financial Services Technology Forum) about the BSIMM. We've often discussed outreach on this list and the importance of not becoming too insular in the software security community. In my view, this is the kind of outreach that helps move the field forward past the early adopter stage. The FSTC is reaching out both to large and small banks as well as to regulators on the software security front. Many vendors are involved in the effort as well. Roger Lang can send you an executive summary about the FSTC and its Software Assurance initiative if you're interested in participating. For more see: http://fstc.org/ gem http://www.cigital.com/~gem From jim at manico.net Thu Apr 9 13:16:56 2009 From: jim at manico.net (Jim Manico) Date: Thu, 9 Apr 2009 07:16:56 -1000 Subject: [SC-L] OWASP Podcast #16 Message-ID: <8E7DBDCF81C849E2AA555278C0D23D46@workhorse> Hello SC-l, OWASP Podcast #16, an interview with Dave Aitel, is now live. Dave == cool. I hope you enjoy. Direct Link: http://www.owasp.org/download/jmanico/owasp_podcast_16.mp3 RSS: http://www.owasp.org/download/jmanico/podcast.xml iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 Regards, - Jim Manico OWASP Podcast Host -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090409/b40a384b/attachment.html From stephencraig.evans at gmail.com Fri Apr 10 09:42:13 2009 From: stephencraig.evans at gmail.com (Stephen Craig Evans) Date: Fri, 10 Apr 2009 21:42:13 +0800 Subject: [SC-L] OWASP Podcast #16 In-Reply-To: <8E7DBDCF81C849E2AA555278C0D23D46@workhorse> References: <8E7DBDCF81C849E2AA555278C0D23D46@workhorse> Message-ID: <930fd0230904100642k169b31ccxa9f64916eab68655@mail.gmail.com> Hi Jim, I check the web site daily before you even announce the podcasts. Tremendous stuff as you don't lob softball questions plus you get quickly to the point. Thanks for your effort; I've learned a lot from them already. Keep up the great work, Stephen On Fri, Apr 10, 2009 at 1:16 AM, Jim Manico wrote: > Hello SC-l, > > OWASP Podcast #16, an interview with Dave Aitel, is now live. Dave == cool. > I hope you enjoy. > > Direct Link: http://www.owasp.org/download/jmanico/owasp_podcast_16.mp3 > RSS: http://www.owasp.org/download/jmanico/podcast.xml > iTunes: > http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 > > Regards, > - Jim Manico > OWASP Podcast Host > > > _______________________________________________ > 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. > _______________________________________________ > > -- http://www.linkedin.com/in/stephencraigevans From James.McGovern at thehartford.com Mon Apr 13 09:38:09 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Mon, 13 Apr 2009 09:38:09 -0400 Subject: [SC-L] OWASP Hartford: Scott Ambler - Agility and Security: Two Great Tastes Which Go Great Together Message-ID: <193C2C0486582D4B9917A217C4DA91E001489A7B@AD1HFDEXC307.ad1.prod> > When: Monday, April 13, 2009 4:00 PM-6:00 PM (GMT-05:00) Eastern Time (US & Canada). > Where: The Hartford: 55 Farmington Avenue, The Great Room > > *~*~*~*~*~*~*~*~*~* > > The Hartford Chapter of OWASP is pleased to announce Scott Ambler as our first speaker of the year. This event is 100% free to attend. Seating is limited. We will be starting promptly at 4pm> ...> > > Agility and Security: Two Great Tastes Which Go Great Together > > Security is usually an afterthought on software development projects, regardless of the paradigm being followed, but it doesn't have to be this way. Traditional approaches would have you add a lot of additional bureaucracy to your process and the agile extremists will tell you to write up some stories on index cards. Good luck with those strategies. Disciplined agile teams, particularly those working at scale, have discovered ways to address enterprise issues such as security in effective manners which gets the job done without unnecessary bureaucracy, albeit with more sophisticated tools than a stack of index cards. This presentation overviews the Agile Process Maturity Model (APMM), what it means to scale agile approaches to meet your real-world needs, and strategies for addressing security concerns in a disciplined agile manner. > Scott W. Ambler is the Practice Leader for Agile Development at IBM Corporation. He works in the IBM Methods group developing process materials and travels the world helping clients to understand and adopt software processes that are right for them. A prolific author, Scott has received awards for several books, including those focused on the Unified Process, agile software development, Unified Modeling Language, and development based on the CMM (Capability Maturity Model). A widely recognized expert on Agile Process, he is a regular speaker at international IT conferences and a senior contributing editor for Dr. Dobb> '> s Journal. Scott also writes the Agile Software Development at Scale blog on IBM DeveloperWorks. > > Prior to working for IBM, Scott led the development of several software processes, including Agile Modeling (AM), Agile Data (AD), Enterprise Unified Process (EUP), and Agile Unified Process (AUP). He holds a BSC in computer science and a MS in information science from the University of Toronto. ************************************************************ 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/20090413/06df859a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3839 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20090413/06df859a/attachment.bin From gem at cigital.com Wed Apr 15 15:47:49 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 15 Apr 2009 15:47:49 -0400 Subject: [SC-L] RSA panel Message-ID: hi sc-l, Presumably some of you will be at RSA this year. I'm doing three panels and a talk (with Brian Chess) on the BSIMM. One of the panels (the one on surveillance) has already generated some press interest: http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1353725,00.html My favorite question in the short Q&A is, "why should a software security guy care about privacy and surveillance?" Uh, yeah. Do YOU guys care? I do. The panel is sponsored by IEEE Security & Privacy magazine, and a reception will follow the panel. Come see us. Hope to see some of you at RSA. gem http://www.cigital.com/~gem From andrews at rbacomm.com Wed Apr 15 18:55:10 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 15 Apr 2009 17:55:10 -0500 Subject: [SC-L] RSA panel In-Reply-To: References: Message-ID: <20090415175510.xl2hklksowckskwg@webmail.rbacomm.com> Are any of these going to be recorded? That would help those of us with no travel budget or time. :) Brad Quoting Gary McGraw : > hi sc-l, > > Presumably some of you will be at RSA this year. I'm doing three > panels and a talk (with Brian Chess) on the BSIMM. From jeremy.j.epstein at gmail.com Wed Apr 15 21:46:37 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Wed, 15 Apr 2009 21:46:37 -0400 Subject: [SC-L] RSA panel In-Reply-To: References: Message-ID: I'm also doing a panel on security in voting systems. Podcast at https://365.rsaconference.com/blogs/podcast_series_rsa_conference_2009/2009/04/15/jeremy-epstein-rr-107-technology-lessons-learned-from-election-2008 Hope to see many of you at the panel - Tue @ 410pm. --Jeremy On Wed, Apr 15, 2009 at 3:47 PM, Gary McGraw wrote: > hi sc-l, > > Presumably some of you will be at RSA this year. ?I'm doing three panels and a talk (with Brian Chess) on the BSIMM. ?One of the panels (the one on surveillance) has already generated some press interest: > http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1353725,00.html > > My favorite question in the short Q&A is, "why should a software security guy care about privacy and surveillance?" ?Uh, yeah. ?Do YOU guys care? ?I do. > > The panel is sponsored by IEEE Security & Privacy magazine, and a reception will follow the panel. ?Come see us. > > Hope to see some of you at RSA. > > gem > > http://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. > _______________________________________________ > From jeremy.j.epstein at gmail.com Thu Apr 16 07:24:59 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Thu, 16 Apr 2009 07:24:59 -0400 Subject: [SC-L] RSA panel In-Reply-To: <20090415175510.xl2hklksowckskwg@webmail.rbacomm.com> References: <20090415175510.xl2hklksowckskwg@webmail.rbacomm.com> Message-ID: RSA records all the sessions and makes the recordings available for purchase at some exorbitant fee. On 4/15/09, Brad Andrews wrote: > > Are any of these going to be recorded? That would help those of us > with no travel budget or time. :) > > Brad > > Quoting Gary McGraw : > >> hi sc-l, >> >> Presumably some of you will be at RSA this year. I'm doing three >> panels and a talk (with Brian Chess) on the BSIMM. > _______________________________________________ > 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. > _______________________________________________ > -- Sent from my mobile device From gem at cigital.com Thu Apr 16 09:59:26 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 16 Apr 2009 09:59:26 -0400 Subject: [SC-L] informIT: Software Security Still Growing Message-ID: hi sc-l, I'm pleased to report that even in the face of global recession, the software security space continues to grow. The space as a whole, tracked through the annual revenue of tools and services vendors, is approaching $500M. As many of you know, I publish an annual "state of the practice" article with lots of numbers in it. The 2008 numbers were just published this morning: http://www.informit.com/articles/article.aspx?p=1338343 For pointers to previous years' data and some discussion of the analysts covering the space (including pointers to the Gartner magic quadrant and a report by Forrester), see this Justice League posting: http://www.cigital.com/justiceleague/2009/04/16/software-security-2008/ If Q1 results from Cigital are any indication, 2009 promises to be yet another record year for software security. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck book www.swsec.com From gem at cigital.com Mon Apr 20 16:16:39 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 20 Apr 2009 16:16:39 -0400 Subject: [SC-L] pre-RSA coverage Message-ID: hi sc-l, Greetings from San Fran. The timing on this article is great...just before RSA. http://news.cnet.com/8301-1009_3-10222698-83.html?tag=newsEditorsPicksArea.0 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 Apr 23 09:43:09 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 23 Apr 2009 09:43:09 -0400 Subject: [SC-L] Silver Bullet 37: Virgil Gligor Message-ID: hi sc-l, Turns out that most all of us are newbies when it comes to computer security. There is plenty to learn from people who have been active in the field from the 70s. One such influential thinker (and friend) is Virgil Gligor. Virgil recently moved from University of Maryland to CMU where he co-directs the Cylab. http://www.cigital.com/silverbullet/show-037/ We talk about Virgil's view of software security as well as how Virgil feels about security and individual liberty. Virgil's views are informed by his childhood in Romania. He knows precisely what freedom is. Enjoy, and as usual your feedback would be great. gem http://www.cigital.com From rklists at gmail.com Thu Apr 23 14:41:11 2009 From: rklists at gmail.com (Rohit Sethi) Date: Thu, 23 Apr 2009 11:41:11 -0700 Subject: [SC-L] Security Analysis of the Core J2EE Patterns Message-ID: Hi list, Security Compass is pleased to announce the launch of SecCom Labs at http://labs.securitycompass.com - our site dedicated to free security resources for software developers. The first major contribution is a security analysis of the Core J2EE Patterns. We reviewed every pattern and outlined common security pitfalls and positive security practices based on our experience. Our hope is that by analying security at the pattern level, we can help spur secure software at the design phase. We'd really appreciate your feedback! We'll be presenting the paper at the RSA conference tomorrow morning 10:10 at Purple 310. We're bringing hard copies of the paper to distribute at the talk, and we'd love to see you there. Cheers, -- Rohit Sethi Security Compass http://www.securitycompass.com From jim at manico.net Thu Apr 23 17:31:58 2009 From: jim at manico.net (Jim Manico) Date: Thu, 23 Apr 2009 11:31:58 -1000 Subject: [SC-L] OWASP Podcast 17 Message-ID: <1A138FC3825949F5B309941337FE5770@workhorse> Hello sc-l, OWASP Podcast 17 - an Interview with Robert "RSnake" Hansen - is now live. Show Notes: https://www.owasp.org/index.php/Podcast_17 Direct Download: http://www.owasp.org/download/jmanico/owasp_podcast_17.mp3 RSS: http://www.owasp.org/download/jmanico/podcast.xml iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 Thanks for listening, - Jim Manico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090423/48a40321/attachment.html From koved at us.ibm.com Mon Apr 27 09:43:43 2009 From: koved at us.ibm.com (Larry Koved) Date: Mon, 27 Apr 2009 09:43:43 -0400 Subject: [SC-L] [W2SP2009] Web 2.0 Security & Privacy -- May 21, 2009 Message-ID: Web 2.0 Security & Privacy 2009 Claremont Resort in Oakland, California May 21, 2009 http://w2spconf.com/2009/ 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. This workshop is the 3rd in a series of successful workshops on this topic. Registration is now open. See the main conference web site for registration information: http://oakland09.cs.virginia.edu/ . (You may register and participate in the workshop even if you are not attending the 30th IEEE Symposium on Security & Privacy.) If you would, please pass this information on to your colleagues who may be interested in this workshop. Thanks. Larry Koved & Dan Wallach Co-chairs, W2SP -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090427/1611f322/attachment.html From sc-l-bounces at SecureCoding.org Mon Apr 27 14:09:36 2009 From: sc-l-bounces at SecureCoding.org (sc-l-bounces at SecureCoding.org) Date: Mon, 27 Apr 2009 14:09:36 -0400 Subject: [SC-L] Job wanted: s/w engineer in Northern Virginia/DC Message-ID: [Moderator's note: I got the following SC-L submission from long-time SC-Ler, Dave Aronson. I wasn't sure whether to accept it or not, so I considered it for a couple days and here's my decision and opinion: 1 - I really don't want SC-L to be a jobs wanted/offered board per se. 2 - Such postings have been few and far between. 3 - That said, they can be truly helpful to our community. So, I'm willing to make an occasional exception and accept this posting. I reserve the right to reject any similar postings in the future if the traffic level gets to be too high. I know, that's a fuzzy "policy", but that's life. As always, I'm open to your comments and suggestions. Cheers, Ken P.S. Good luck, Dave.] From: SC-L Reader Dave Aronson Date: April 24, 2009 6:33:52 PM EDT To: Secure Coding List Subject: job wanted: s/w eng in nova/dc Dear Fellow SC-L'ers: Long story short, I'm looking for work. I'm possibly going to be laid off in a few weeks, and am seeking a software engineering position in Northern Virginia. Also willing to consider a training position, contracts, DC, or maybe even Maryland. Brief summary of qualifications: 24 years of software development, mainly in C under Unix, and lately for multi-level security apps such as data guards, but also lots of experience with other languages, systems, and fields, including secure coding related applications such as static analysis. Also some experience in training, including on technical topics. Secret clearance. My full resume is available at http://www.davearonson.com/ or if that's down then http://mysite.verizon.net/~nosnoraevad/. Thanks, Dave -- Dave Aronson, software engineer soon to be for hire. Looking for job (or contract) in Washington DC area. See http://www.davearonson.com/ for resume - if that is down see http://mysite.verizon.net/~nosnoraevad/. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090427/d9c869fb/attachment.html From ken at krvw.com Tue Apr 28 12:45:47 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 28 Apr 2009 12:45:47 -0400 Subject: [SC-L] Application Security Starts in the Development Lifecycle Message-ID: <184F9D0E-5F48-4CA8-8F14-86E175BEB20B@krvw.com> FYI, some eWeek coverage of application security and how it is being taken more seriously in the enterprise these days. No big surprises for long-time SC-L folks, but still an interesting read from a fairly mainstream IT Security outlet. http://www.eweek.com/c/a/Security/Application-Security-Starts-in-the-Development-Lifecycle-792076/?kc=rss 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/20090428/ba4116df/attachment.bin From chandra at list.org Thu Apr 30 00:47:07 2009 From: chandra at list.org (Pravir Chandra) Date: Wed, 29 Apr 2009 21:47:07 -0700 Subject: [SC-L] SAMM helps with real software development Message-ID: The Real Software blog by Jim Bird has a good post about how his software security assurance program has evolved over time, and now, SAMM is helping out. http://swreflections.blogspot.com/2009/04/opensamm-shows-way.html p. -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From jeremy.j.epstein at gmail.com Wed May 6 09:46:11 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Wed, 6 May 2009 09:46:11 -0400 Subject: [SC-L] Seeking vulnerable server-side scripts Message-ID: Greetings, I'm experimenting (on paper initially) with a technique for improving resiliency of web applications, and to do so am looking for examples of server side scripts (PHP, Perl, whatever) that have security vulnerabilities, to see if the technique would work. If you have scripts you'd be willing to share, please contact me off-list. The scripts don't have to be open source; I'm happy to take scripts that are not for redistribution (but I can't sign formal NDAs). The ideal scenario would include enough of the infrastructure (scripts, descriptions of the environment) and a description of the vulnerability... but again, I'll take what I can get for now. The important thing is that the scripts be server-side and written in an interpreted scripting language; I'm not looking for server-side C or Java programs. If there are repositories of such things, please excuse the newbie question and point me in the right direction! Thanks, --Jeremy 703-989-8907 (mobile) jeremy.j.epstein at gmail.com P.S. Yes, you may forward this message to other people, but I'd appreciate not sending it to other lists without checking with me first. From coley at linus.mitre.org Wed May 6 12:52:30 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 6 May 2009 12:52:30 -0400 (EDT) Subject: [SC-L] Seeking vulnerable server-side scripts In-Reply-To: References: Message-ID: Jeremy, CVE is littered with these kinds of issues, for PHP especially. The scripts are often open source, fully-functional packages that just happen to have lots of security issues. Sometimes the root cause is buried fairly deep in the code, but the people who find these bugs often care only about the attack. The CVE descriptions are often straightforward. To find the best options, I'd grab CVEs that mention scripts ending in a .php extension, select the ones with both milw0rm and Secunia references, then examine the milw0rm reference to see if the researcher lists a download URL for the product (this is probably 25% or more of all milw0rms, so you won't have to look very hard). While you'll get a lot of XSS, SQL injection, and file inclusion, you'll also get more subtle issues like eval injection, file upload, redirect-without-exit, static code injection, variable extraction, and other issues that affect most interpreted languages (although the vuln research emphasis is on PHP). Since CVE descriptions are well-formed for well-known vuln types, you could find the weird ones pretty quickly. - Steve From jericho at attrition.org Wed May 6 13:08:47 2009 From: jericho at attrition.org (security curmudgeon) Date: Wed, 6 May 2009 17:08:47 +0000 (UTC) Subject: [SC-L] Seeking vulnerable server-side scripts In-Reply-To: References: Message-ID: Hi Jeremy, : I'm experimenting (on paper initially) with a technique for improving : resiliency of web applications, and to do so am looking for examples : of server side scripts (PHP, Perl, whatever) that have security : vulnerabilities, to see if the technique would work. If you have : If there are repositories of such things, please excuse the newbie : question and point me in the right direction! There are several applications designed specifically for this: Mutillidae http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10 Foundstone's Hacme Bank and Hacme Travel http://www.foundstone.com/us/resources-free-tools.asp WebGoat http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project I believe there are more, but those are the first to come to mind. From andrews at rbacomm.com Wed May 6 13:41:05 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 06 May 2009 12:41:05 -0500 Subject: [SC-L] Insecure Java Code Snippets Message-ID: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> Does anyone know of a source of insecure Java snippets? I would like to get some for a monthly meeting of leading technical people. My idea was to have a "find the bug" like the old C-Lint ads. Does anyone know of a source of something like this. Brad From jericho at attrition.org Wed May 6 13:17:19 2009 From: jericho at attrition.org (security curmudgeon) Date: Wed, 6 May 2009 17:17:19 +0000 (UTC) Subject: [SC-L] Seeking vulnerable server-side scripts In-Reply-To: References: Message-ID: : There are several applications designed specifically for this: : : Mutillidae : http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10 : : Foundstone's Hacme Bank and Hacme Travel : http://www.foundstone.com/us/resources-free-tools.asp : : WebGoat : http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project : : : I believe there are more, but those are the first to come to mind. A couple more: Stanford SecuriBench http://suif.stanford.edu/~livshits/securibench/ w3af's "moth" http://sourceforge.net/project/showfiles.php?group_id=170274 http://sourceforge.net/mailarchive/forum.php?thread_name=cdfaf8b20905051759o76a0f6f1o171928dd9b1d5e30%40mail.gmail.com&forum_name=w3af-develop From jim at manico.net Wed May 6 14:25:36 2009 From: jim at manico.net (Jim Manico) Date: Wed, 6 May 2009 08:25:36 -1000 Subject: [SC-L] Seeking vulnerable server-side scripts References: Message-ID: <02C7AB57E1444A43B8E05DD9693D2821@workhorse> I heard that http://www.twitter.com is a fun one, too. LITTERED with major vulns. - Jim ----- Original Message ----- From: "security curmudgeon" To: "Jeremy Epstein" Cc: Sent: Wednesday, May 06, 2009 7:17 AM Subject: Re: [SC-L] Seeking vulnerable server-side scripts > > : There are several applications designed specifically for this: > : > : Mutillidae > : > http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10 > : > : Foundstone's Hacme Bank and Hacme Travel > : http://www.foundstone.com/us/resources-free-tools.asp > : > : WebGoat > : http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project > : > : > : I believe there are more, but those are the first to come to mind. > > A couple more: > > Stanford SecuriBench > http://suif.stanford.edu/~livshits/securibench/ > > w3af's "moth" > http://sourceforge.net/project/showfiles.php?group_id=170274 > http://sourceforge.net/mailarchive/forum.php?thread_name=cdfaf8b20905051759o76a0f6f1o171928dd9b1d5e30%40mail.gmail.com&forum_name=w3af-develop > > > _______________________________________________ > 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 Wed May 6 14:26:19 2009 From: jim at manico.net (Jim Manico) Date: Wed, 6 May 2009 08:26:19 -1000 Subject: [SC-L] Insecure Java Code Snippets References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> Message-ID: <1F1323C03FDD4F8389B6A7DC81303044@workhorse> Any Java Education book, like Cay Hortsman's Core Java. Seriously. - Jim ----- Original Message ----- From: "Brad Andrews" To: Sent: Wednesday, May 06, 2009 7:41 AM Subject: [SC-L] Insecure Java Code Snippets > > > Does anyone know of a source of insecure Java snippets? I would like > to get some for a monthly meeting of leading technical people. My > idea was to have a "find the bug" like the old C-Lint ads. > > Does anyone know of a source of something like this. > > Brad > _______________________________________________ > 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 jrose at owasp.org Wed May 6 14:31:02 2009 From: jrose at owasp.org (jrose) Date: Wed, 6 May 2009 14:31:02 -0400 Subject: [SC-L] Seeking vulnerable server-side scripts In-Reply-To: References: Message-ID: Use google codesearch: http://www.google.com/codesearch?hl=en&lr=&q=select.*from.*%5C%24_%28GET%7CPOST%7CCOOKIES%29+lang%3Aphp&btnG=Search http://www.google.com/codesearch?hl=en&lr=&q=input.*type%3Dhidden.*%3D.*%5C%24_%28GET%7CPOST%7CCOOKIE%29&btnG=Search http://www.google.com/codesearch?hl=en&lr=&q=fopen%5C%28.*%5C%24_GET&btnG=Search http://www.google.com/codesearch?hl=en&lr=&q=%5C+file%5C%28.*%5C%24_POST&btnG=Search http://www.google.com/codesearch?hl=en&lr=&q=file_get_contents%5C%28.*%5C%24_GET&btnG=Search - Jon On May 6, 2009, at 1:17 PM, security curmudgeon wrote: > > : There are several applications designed specifically for this: > : > : Mutillidae > : http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10 > : > : Foundstone's Hacme Bank and Hacme Travel > : http://www.foundstone.com/us/resources-free-tools.asp > : > : WebGoat > : http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project > : > : > : I believe there are more, but those are the first to come to mind. > > A couple more: > > Stanford SecuriBench > http://suif.stanford.edu/~livshits/securibench/ > > w3af's "moth" > http://sourceforge.net/project/showfiles.php?group_id=170274 > http://sourceforge.net/mailarchive/forum.php?thread_name=cdfaf8b20905051759o76a0f6f1o171928dd9b1d5e30%40mail.gmail.com&forum_name=w3af-develop > > > _______________________________________________ > 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 brian at fortify.com Wed May 6 14:34:43 2009 From: brian at fortify.com (Brian Chess) Date: Wed, 06 May 2009 11:34:43 -0700 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> Message-ID: We keep a big catalog here: http://www.fortify.com/vulncat On 5/6/09 10:41 AM, "Brad Andrews" wrote: > > > > Does anyone know of a source of insecure Java snippets? I would like > to get some for a monthly meeting of leading technical people. My > idea was to have a "find the bug" like the old C-Lint ads. > > Does anyone know of a source of something like this. > > Brad > _______________________________________________ > 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/20090506/5a122014/attachment.html From coley at linus.mitre.org Wed May 6 14:41:32 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 6 May 2009 14:41:32 -0400 (EDT) Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> Message-ID: On Wed, 6 May 2009, Brad Andrews wrote: > Does anyone know of a source of insecure Java snippets? I would like > to get some for a monthly meeting of leading technical people. My > idea was to have a "find the bug" like the old C-Lint ads. CWE has many snippets like this for various languages, but primarily C and Java: 1) Load the CWE full dictionary (CWE-2000): http://cwe.mitre.org/data/definitions/2000.html 2) Click the "Slice" link in the top right 3) Go get lunch while your browser loads (well it's 10 to 30 seconds but that's a lunch in Internet time) 4) Search for "Java Example:" 5) Tell cwe at mitre.org if you notice any errors or oddities I stopped counting at 50 snippets. If you speak XSLT, you can easily construct a query to pull out the Demonstrative_Example elements that look a little like: Demonstrative_Example//Example_Body//Block//Code_Example_Language = Java For a little less data, you can use the CWE Java view (CWE-660): http://cwe.mitre.org/data/definitions/660.html but this doesn't include language-independent issues like XSS and SQL injection. I'd love to hear from others who have repositories like this. - Steve From goertzel_karen at bah.com Wed May 6 15:40:09 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 6 May 2009 15:40:09 -0400 Subject: [SC-L] Insecure Java Code Snippets References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> Message-ID: <184D5FFC5203644FB4F8864B0EE445B40392DF17@MCLNEXVS06.resource.ds.bah.com> The NIST SAMATE Reference Dataset has mainly C code in it, but there is also Java, C++, and PHP. There's a search function that allows you to search by programming language to find what you want. http://samate.nist.gov/SRD/ -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of Brad Andrews Sent: Wed 06-May-09 13:41 To: sc-l at securecoding.org Subject: [SC-L] Insecure Java Code Snippets Does anyone know of a source of insecure Java snippets? I would like to get some for a monthly meeting of leading technical people. My idea was to have a "find the bug" like the old C-Lint ads. Does anyone know of a source of something like this. Brad _______________________________________________ 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/20090506/85826f0c/attachment.html From andrews at rbacomm.com Wed May 6 16:22:59 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 06 May 2009 15:22:59 -0500 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B40392DF17@MCLNEXVS06.resource.ds.bah.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <184D5FFC5203644FB4F8864B0EE445B40392DF17@MCLNEXVS06.resource.ds.bah.com> Message-ID: <20090506152259.pqnez55q28oc88ss@webmail.rbacomm.com> Thanks Karen, that site may have enough of what I can use. Still a bit of work to do, but worth pursuing. The other sources were a bit too short on the snippets side, which is my fault for not making the question better. I don't know how many of you used to read the C-Lint ads that said "find the bug in this C code". They were very difficult in all the cases I worked at. :) The whole point of their ad was that their product would find things you couldn't find easily in a manual review. I want something like that. Just playing "tell me the security flaw in these 3 lines of code will not do quite the same thing. I will find a copy of Core Java to look through again, but I don't recall seeing things in this format when I looked before. The challenge with this is that I need something that fits well in a single PowerPoint slide (so it can be viewed while the participants eat). It also has to be fairly difficult. I am not sure that just "not filtering user input" is sufficiently strong. I want something that would take some thinking. I expect that I will have to design and format these myself, but I would love to have something sooner by using something that already did this. Thanks for the other replies. I am going to check out the NIST site some more. I will read over the other sites, but using them will take more effort than I was hoping for. Brad Quoting "Goertzel, Karen [USA]" : > The NIST SAMATE Reference Dataset has mainly C code in it, but there > is also Java, C++, and PHP. There's a search function that allows > you to search by programming language to find what you want. > > http://samate.nist.gov/SRD/ From livshits at microsoft.com Wed May 6 18:41:37 2009 From: livshits at microsoft.com (Ben Livshits) Date: Wed, 6 May 2009 15:41:37 -0700 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B40392DF17@MCLNEXVS06.resource.ds.bah.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <184D5FFC5203644FB4F8864B0EE445B40392DF17@MCLNEXVS06.resource.ds.bah.com> Message-ID: <1F83EA310ED12747B8739AC135DD496838C0EACF83@NA-EXMSG-C120.redmond.corp.microsoft.com> See here: http://suif.stanford.edu/~livshits/work/securibench-micro/ -Ben From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Goertzel, Karen [USA] Sent: Wednesday, May 06, 2009 12:40 PM To: Brad Andrews; sc-l at securecoding.org Subject: Re: [SC-L] Insecure Java Code Snippets The NIST SAMATE Reference Dataset has mainly C code in it, but there is also Java, C++, and PHP. There's a search function that allows you to search by programming language to find what you want. http://samate.nist.gov/SRD/ -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_karen at bah.com -----Original Message----- From: sc-l-bounces at securecoding.org on behalf of Brad Andrews Sent: Wed 06-May-09 13:41 To: sc-l at securecoding.org Subject: [SC-L] Insecure Java Code Snippets Does anyone know of a source of insecure Java snippets? I would like to get some for a monthly meeting of leading technical people. My idea was to have a "find the bug" like the old C-Lint ads. Does anyone know of a source of something like this. Brad _______________________________________________ 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/20090506/7eb3e075/attachment.html From andrews at rbacomm.com Wed May 6 18:49:35 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 06 May 2009 17:49:35 -0500 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> Message-ID: <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> I had the name wrong, it was PC-Lint. See http://www.gimpel.com/html/bugs.htm That is what I am looking for, not just a general listing of bugs or insecure code. I want bugs that are hard to find and formatted like this. If I do create some and do it on my own (outside work), I will try to submit them to OWASP, possibly starting a project on that. Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. They can be really hard to figure out, though maybe not by all the smart people here! :) Brad From ljknews at mac.com Thu May 7 09:11:07 2009 From: ljknews at mac.com (ljknews) Date: Thu, 07 May 2009 09:11:07 -0400 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> Message-ID: At 5:49 PM -0500 5/6/09, Brad Andrews wrote: > Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. > They can be really hard to figure out, And yet people keep choosing those programming languages. -- Larry Kilgallen From martin.johns at gmail.com Thu May 7 10:55:26 2009 From: martin.johns at gmail.com (Martin Johns) Date: Thu, 7 May 2009 16:55:26 +0200 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> Message-ID: <28bb57460905070755r49a6684ahfd79e5a1ee95b593@mail.gmail.com> Brad, I recently read a book called "Java Puzzlers" (http://www.amazon.com/Java-TM-Puzzlers-Pitfalls-Corner/dp/032133678X/ref=sr_1_1?ie=UTF8&s=books&qid=1241707826&sr=8-1 ). The book consist of small Java programs that appear to do one thing but actually behave differently than expected. I guess this is more in the line of snippets that you are looking for. However, the examples in the book are not centered on security. Hence, some modifications would still be necessary to fit your purpose. Best, Martin -- Martin Johns http://www.martinjohns.com From rklists at gmail.com Thu May 7 12:05:29 2009 From: rklists at gmail.com (Rohit Sethi) Date: Thu, 7 May 2009 12:05:29 -0400 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> Message-ID: Brad, I recommend you approach this problem in reverse. Think of the bug you want people to hunt for and then put together an appropriate regular expressions in Google Code Search (http://www.google.com/codesearch) For instance "lang:java request getParameter .*price" might be a good starting point. After doing that search I found a few different possible vulns. Once you find a vulnerability you can extract as much or as little code out of it as you'd like. I use this often in class design. Cheers, Rohit On Wed, May 6, 2009 at 6:49 PM, Brad Andrews wrote: > > I had the name wrong, it was PC-Lint. > > See > > http://www.gimpel.com/html/bugs.htm > > That is what I am looking for, not just a general listing of bugs or > insecure code. ?I want bugs that are hard to find and formatted like > this. ?If I do create some and do it on my own (outside work), I will > try to submit them to OWASP, possibly starting a project on that. > > Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. ?They can > be really hard to figure out, though maybe not by all the smart people > here! ?:) > > Brad > _______________________________________________ > 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 andrews at rbacomm.com Thu May 7 13:47:47 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Thu, 07 May 2009 12:47:47 -0500 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> Message-ID: <20090507124747.p8bvjxoeios0kow8@webmail.rbacomm.com> Quoting ljknews : > At 5:49 PM -0500 5/6/09, Brad Andrews wrote: > >> Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. >> They can be really hard to figure out, > > And yet people keep choosing those programming languages. They offer quite a bit of power in exchange for the danger. A steak knife can be dangerous, but I would greatly prefer it over a butter knife if I am eating a steak. :) I also believe some Java security flaws can be just as difficult to figure out. Some aren't, but why would secure code review be such a challenge if it was so easy? Brad From coley at linus.mitre.org Thu May 7 15:54:36 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 7 May 2009 15:54:36 -0400 (EDT) Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> Message-ID: On Thu, 7 May 2009, ljknews wrote: > At 5:49 PM -0500 5/6/09, Brad Andrews wrote: > > > Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. > > They can be really hard to figure out, > > And yet people keep choosing those programming languages. Yeah. Like the developers of the compilers/interpreters for Java, Perl, PHP, Ruby, Python, and probably whatever else the kids are raving about these days. ;-) And of course these languages never use C/C++ libraries. I imagine that at some point, even things like Ada boil down to some assembly code somewhere. More seriously, at one point or another you're building on top of something else that's insecure, and while that might mostly remove you from the bugs that occur at the lower level, all it really means is the vulnerabilities shift to a higher level and are much more powerful. C programmers would rarely bother to take untrusted input, insert it into a program, compile the program, and execute that program. But PHP programmers like to do that all the time by implementing config files as PHP programs and inserting untrusted data into them. Or how about all those web worms compromising gazillions of LAMP installations because of PHP's little remote file inclusion feature? I'm not saying that later-generation languages don't have important features that are useful for security, but I personally wouldn't want to implement some real-time high-throughput packet analyzer in Java, nor would I want to implement a blogging system in C. Compiler features like canary-based protection are making significant improvements for C-based security, just like Java performance is improving. Can't wait for the flames. - Steve From ljknews at mac.com Thu May 7 15:44:08 2009 From: ljknews at mac.com (ljknews) Date: Thu, 07 May 2009 15:44:08 -0400 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090507124747.p8bvjxoeios0kow8@webmail.rbacomm.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> <20090507124747.p8bvjxoeios0kow8@webmail.rbacomm.com> Message-ID: At 12:47 PM -0500 5/7/09, Brad Andrews wrote: > Quoting ljknews : > >> At 5:49 PM -0500 5/6/09, Brad Andrews wrote: >> >>> Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. >>> They can be really hard to figure out, >> >> And yet people keep choosing those programming languages. > > They offer quite a bit of power in exchange for the danger. I would be interested in hearing what they can do that cannot be done in Ada. My bias is based on my experience. I am sure somebody who knows Eiffel would be interested in hearing what C/C++ can do that cannot be done in Eiffel. -- Larry Kilgallen From secureCoding2dave at davearonson.com Fri May 8 09:15:54 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Fri, 8 May 2009 09:15:54 -0400 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> <20090507124747.p8bvjxoeios0kow8@webmail.rbacomm.com> Message-ID: <3f4922c70905080615q4d7d9b3bhacd096173e47de7e@mail.gmail.com> ljknews wrote: > At 12:47 PM -0500 5/7/09, Brad Andrews wrote: >> Quoting ljknews : >>> At 5:49 PM -0500 5/6/09, Brad Andrews wrote: >>>> Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. >>>> They can be really hard to figure out, >>> And yet people keep choosing those programming languages. >> They offer quite a bit of power in exchange for the danger. > I would be interested in hearing what they can do that cannot > be done in Ada. It's rarely (I won't say never!) a question of what *can't* be done in language X or Y. Usually, it's about what's *easier* to do in X or Y. Sometimes the security tradeoff is worth taking the hard way, but sometimes the choice is to the point of being at all practical or not. -Dave, making good progress on the job hunt, thanks in part to people here -- Dave Aronson, software engineer soon to be for hire. Looking for job (or contract) in Washington DC area. See http://www.davearonson.com/ for resume - if that is down see http://mysite.verizon.net/~nosnoraevad/. From ljknews at mac.com Fri May 8 11:16:57 2009 From: ljknews at mac.com (ljknews) Date: Fri, 08 May 2009 11:16:57 -0400 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <3f4922c70905080615q4d7d9b3bhacd096173e47de7e@mail.gmail.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> <2fd9390e0905061531w32db18b0l425770380254a59f@mail.gmail.com> <20090506174935.p1441g4l0c8co8o8@webmail.rbacomm.com> <20090507124747.p8bvjxoeios0kow8@webmail.rbacomm.com> <3f4922c70905080615q4d7d9b3bhacd096173e47de7e@mail.gmail.com> Message-ID: At 9:15 AM -0400 5/8/09, SC-L Reader Dave Aronson wrote: > ljknews wrote: >> At 12:47 PM -0500 5/7/09, Brad Andrews wrote: >>> Quoting ljknews : >>>> At 5:49 PM -0500 5/6/09, Brad Andrews wrote: >>>>> Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. >>>>> They can be really hard to figure out, >>>> And yet people keep choosing those programming languages. >>> They offer quite a bit of power in exchange for the danger. >> I would be interested in hearing what they can do that cannot >> be done in Ada. > > It's rarely (I won't say never!) a question of what *can't* be done in > language X or Y. Usually, it's about what's *easier* to do in X or Y. > Sometimes the security tradeoff is worth taking the hard way, but > sometimes the choice is to the point of being at all practical or not. Well the _easiest_ development comes from not worrying about security. So tell me what you think is easier in C/C++. -- Larry Kilgallen From gem at cigital.com Fri May 8 15:06:43 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 8 May 2009 15:06:43 -0400 Subject: [SC-L] Reality Check #5: David Hahn (Wells Fargo) Message-ID: hi sc-l, I'm pleased to announce that the fifth episode of the Reality Check podcast just went live. This episode features David Hahn from Wells Fargo. David and I discuss the Wells Fargo software security initiative (at least the one that covers wellfargo.com). David's website has 11 million active users, and that's before the Wachovia merger! http://www.cigital.com/realitycheck/show-005/ As always, your feedback is welcome. Reality Check is syndicated by CSO magazine where you can also find a feed for the podcast. gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From Kevin.Wall at qwest.com Sun May 10 10:42:31 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Sun, 10 May 2009 09:42:31 -0500 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com><2fd9390e09 05061531w32db18b0l425770380254a59f@mail.gmail.com><20090506174935.p1441g4l0 c8co8o8@webmail.rbacomm.com><2009050 7124747.p8bvjxoeios0kow8@webmail.rbacomm.com><3f4922c70905080615q4d7d9b3bhacd096173e47de7e@mail.gmail.com>, Message-ID: Larry Kilgallen wrote... > So tell me what you think is easier in C/C++. Well, just from a pure language POV, in comparing C++ with Java (sorry, not qualified to comment on Ada), there is one advantage to C/C++ over Java and that is in C++ I have a much higher level of confidence of doing things to clean up something when and object is destroyed. In C++, you can write a destructor to do this clean-up and you can predict exactly when the DTOR will execute. In Java, it is not so simple, even if all you want is to reclaim memory. You never really know when an object's finalize() method will be called (or even if it ever will except at exit) You are not supposed to rely on the timeliness of object finalization, nor are you really supposed to rely on finalizers to really do anything except for release memory. So why is this important? It's important because sometimes correctness and/or security depends on proper "clean-up". E.g., releasing a semaphore, overwriting memory (say for passwords or crypto keys), etc. Aside from that, the fact that Java doesn't allow you (native) access to all system calls can make things much more difficult. E.g., no direct access to fcntl(2) makes it impossible to use *nix mandatory file and/or record locking unless resorting to JNI. Or the fact that (AFAIK) Java doesn't support exclusive opens of a file or deal natively with sym links can cause security issues in certain situations. Of course these things are not so much the language per se as they are the supporting runtime environment which Sun wanted to ensure was portable across all the OSes that they support for Java. It's a trade-off and given their design goals, probably an appropriate one, but it does make doing certain tasks a bit more difficult to do securely. (Another example, Java supports nothing in its runtime environment to prevent an object from being paged out to swap--something that again would be desirable for things like crypto keys.) -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME From rcs at cert.org Sun May 10 18:34:52 2009 From: rcs at cert.org (Robert Seacord) Date: Sun, 10 May 2009 18:34:52 -0400 Subject: [SC-L] Insecure Java Code Snippets In-Reply-To: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> References: <20090506124105.fcwg0ux8dco4g4c4@webmail.rbacomm.com> Message-ID: Brad, You can also look at The CERT Sun Microsystems Secure Coding Standard for Java at: https://www.securecoding.cert.org/confluence/display/java/The+CERT+Sun+Microsystems+Secure+Coding+Standard+for+Java Which has many examples of secure/insecure Java source code. rCs -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews Sent: Wednesday, May 06, 2009 1:41 PM To: sc-l at securecoding.org Subject: [SC-L] Insecure Java Code Snippets Does anyone know of a source of insecure Java snippets? I would like to get some for a monthly meeting of leading technical people. My idea was to have a "find the bug" like the old C-Lint ads. Does anyone know of a source of something like this. Brad _______________________________________________ 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 Wed May 13 06:07:39 2009 From: jim at manico.net (Jim Manico) Date: Wed, 13 May 2009 00:07:39 -1000 Subject: [SC-L] OWASP Podcast Update Message-ID: Hello sc-l, OWASP Podcast #19 and #20 were both released this week! OWASP Podcast #19 is a 55 minute "news commentary" program http://www.owasp.org/download/jmanico/owasp_podcast_19.mp3 OWASP Podcast #20 is a 13 minute interview with Mike Baily; the researcher who disclosed multiple CSRF vulns in the AV vendor space http://www.owasp.org/download/jmanico/owasp_podcast_20.mp3 Thanks kindly for listening! Jim Manico OWASP Podcast Series Host podcast at owasp.org Archives: https://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows RSS Feed: http://www.owasp.org/download/jmanico/podcast.xml -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090513/84b82020/attachment.html From koved at us.ibm.com Wed May 13 23:19:09 2009 From: koved at us.ibm.com (Larry Koved) Date: Wed, 13 May 2009 23:19:09 -0400 Subject: [SC-L] [W2SP2009] Web 2.0 Security & Privacy -- May 21, 2009 In-Reply-To: Message-ID: Reminder: One week until the workshop. Web 2.0 Security & Privacy 2009 Claremont Resort in Oakland, California May 21, 2009 http://w2spconf.com/2009/ 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. This workshop is the 3rd in a series of successful workshops on this topic. Registration is now open. See the main conference web site for registration information: http://oakland09.cs.virginia.edu/ . (You may register and participate in the workshop even if you are not attending the 30th IEEE Symposium on Security & Privacy.) If you would, please pass this information on to your colleagues who may be interested in this workshop. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090513/6039af3a/attachment.html From gem at cigital.com Fri May 15 08:42:53 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 15 May 2009 08:42:53 -0400 Subject: [SC-L] InformIT: Twitter Security Message-ID: hi sc-l, It was inevitable---an article about Twitter Security. If my latest column were a tweet, it wouldn't have much content. You can be the judge about whether a longer form does: http://www.informit.com/articles/article.aspx?p=1350268 As always, your feedback is welcome. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From gunnar at arctecgroup.net Tue May 19 17:42:51 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Tue, 19 May 2009 16:42:51 -0500 Subject: [SC-L] InformIT: Twitter Security In-Reply-To: References: Message-ID: <22C87B81-F9CC-44CC-9AA3-7A76B0C9C247@arctecgroup.net> hi gary one other interesting note on twitter security that i am retweeting from @cykyc & @focalintent: you put your SSN in number-dash format, twitter automatically obfuscates it to XXX-XX-XXXX! Now we just need fortune 500 to run twitter instead of ERP, CRM, etc. -gunnar On May 15, 2009, at 7:42 AM, Gary McGraw wrote: > hi sc-l, > > It was inevitable---an article about Twitter Security. If my latest > column were a tweet, it wouldn't have much content. You can be the > judge about whether a longer form does: > > http://www.informit.com/articles/article.aspx?p=1350268 > > As always, your feedback is welcome. > > 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 gem at cigital.com Tue May 19 10:34:55 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 19 May 2009 10:34:55 -0400 Subject: [SC-L] Cigital news (European market) Message-ID: hi sc-l, Cigital has acquired the European operations of Security Innovation. A press release went out this morning. http://www.cigital.com/news/index.php?pg=art&artid=158 We believe that the European software security market is 2-3 years behind the US market, but poised for rapid growth that will align it with the US market in a much shorter period. From what I can tell, the European market is 14-20% the size of the US market. What do you guys think? gem http://www.cigital.com/~gem From list-spam at secureconsulting.net Tue May 19 18:38:21 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 19 May 2009 15:38:21 -0700 Subject: [SC-L] for your consideration Message-ID: <4A1334DD.1090702@secureconsulting.net> Which Came First: The Software or The Security? http://www.secureconsulting.net/2009/05/which_came_first_the_software.html 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: ] "I told the doctor I broke my leg in two places. He told me to quit going to those places." Henny Youngman From ken at krvw.com Tue May 19 21:21:13 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 20 May 2009 11:21:13 +1000 Subject: [SC-L] Cigital news (European market) In-Reply-To: References: Message-ID: <5C3C7B6F-1F49-4FA9-AA55-FA20C8167E86@krvw.com> On May 20, 2009, at 12:34 AM, Gary McGraw wrote: > We believe that the European software security market is 2-3 years > behind the US market, but poised for rapid growth that will align it > with the US market in a much shorter period. From what I can tell, > the European market is 14-20% the size of the US market. My experience there tells me that's an over-simplification of the situation. On one hand, some of the OWASP chapter meetings I've gone to in Europe have been as well or even better attended than their counterparts I've gone to in the US -- primarily in the DC metro area. And not just in terms of quantity. Many of the folks I've spoken with and worked with have been in many cases as well or even better clued than their US counterparts. So there's clearly an eagerness and awareness among the practitioners and academics, which is good. European enterprises, on the other hand, tend to be quite conservative in taking to new practices. They want to see clear justifications before diving in. But I just don't get the feeling that they're trying in any way to "align themselves with the US market". They'll do their own thing in their own time, which is as it should be. From my own little "nanocosm" perspective, I continue to see the bulk of my consulting engagements coming out of Europe and Southeast Asia. I've found both markets to be quite receptive to software security efforts for the past several years. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- 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/20090520/5c625bff/attachment.bin From list-spam at secureconsulting.net Tue May 19 21:55:37 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 19 May 2009 18:55:37 -0700 Subject: [SC-L] Cigital news (European market) In-Reply-To: <5C3C7B6F-1F49-4FA9-AA55-FA20C8167E86@krvw.com> References: <5C3C7B6F-1F49-4FA9-AA55-FA20C8167E86@krvw.com> Message-ID: <4A136319.8090109@secureconsulting.net> Kenneth Van Wyk wrote: > But I just don't get the feeling that they're trying in any way to > "align themselves with the US market". They'll do their own thing in > their own time, which is as it should be. > That syncs with my limited experience with Europeans, both in the past (the French in particular) and in the present (Dutch). Any suggestion that Europe will "follow" the US is probably an error in judgment and highly likely to offend. We should never forget that we're a mere 233 years old independently compared to their several centuries. The Roman Empire lasted almost twice that long. -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: ] "Perfection is not attainable, but if we chase perfection we can catch excellence." Vince Lombardi From matt at piscis-security.com Tue May 19 22:42:25 2009 From: matt at piscis-security.com (Matt Fisher) Date: Tue, 19 May 2009 21:42:25 -0500 Subject: [SC-L] InformIT: Twitter Security In-Reply-To: <22C87B81-F9CC-44CC-9AA3-7A76B0C9C247@arctecgroup.net> References: <22C87B81-F9CC-44CC-9AA3-7A76B0C9C247@arctecgroup.net> Message-ID: <2A9EB7CB4A6ABC4391D7D77E93A7A1132274131156@34093-MBX-C05.mex07a.mlsrvr.com> Thought I'd throw this out there in case you hadn't heard already: http://www.fcw.com/Articles/2009/04/10/Web-Facebook-GSA.aspx . It's starting to affect me real-world already. those of us in the DC area, ramp up your incident response rates now, cause you know it's coming and you know it's going to be good. -matt. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson Sent: Tuesday, May 19, 2009 5:43 PM To: Gary McGraw Cc: Secure Code Mailing List Subject: hi gary one other interesting note on twitter security that i am retweeting from @cykyc & @focalintent: you put your SSN in number-dash format, twitter automatically obfuscates it to XXX-XX-XXXX! Now we just need fortune 500 to run twitter instead of ERP, CRM, etc. -gunnar On May 15, 2009, at 7:42 AM, Gary McGraw wrote: > hi sc-l, > > It was inevitable---an article about Twitter Security. If my latest > column were a tweet, it wouldn't have much content. You can be the > judge about whether a longer form does: > > http://www.informit.com/articles/article.aspx?p=1350268 > > As always, your feedback is welcome. > > 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 elebanidze at cigital.com Tue May 19 23:39:44 2009 From: elebanidze at cigital.com (Evgeny Lebanidze) Date: Tue, 19 May 2009 23:39:44 -0400 Subject: [SC-L] Cigital news (European market) In-Reply-To: <4A136319.8090109@secureconsulting.net> References: <5C3C7B6F-1F49-4FA9-AA55-FA20C8167E86@krvw.com> <4A136319.8090109@secureconsulting.net> Message-ID: <853A02533F8C88439F2331EB1938538446B17E0D6C@va-mailhub.cigital.com> Well, this is hardly a matter of who has a more ancient history, there can be no argument about that. It all ultimately comes down to a business decision. Software security has been picking up in the States because consumers are beginning to demand it explicitly in addition to expecting it implicitly. In some cases security can even be used as a competitive differentiator. I don't know if the same trend is unraveling in Europe, but even if it's not, it makes sense that the European companies would focus on the adoption of software security in order to remain competitive in the US market. Evgeny -------------------------------------------- Evgeny Lebanidze Sr. Security Consultant, Cigital. Inc. evgeny at cigital.com -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave Sent: Tuesday, May 19, 2009 9:56 PM To: Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] Cigital news (European market) Kenneth Van Wyk wrote: > But I just don't get the feeling that they're trying in any way to > "align themselves with the US market". They'll do their own thing in > their own time, which is as it should be. > That syncs with my limited experience with Europeans, both in the past (the French in particular) and in the present (Dutch). Any suggestion that Europe will "follow" the US is probably an error in judgment and highly likely to offend. We should never forget that we're a mere 233 years old independently compared to their several centuries. The Roman Empire lasted almost twice that long. -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: ] "Perfection is not attainable, but if we chase perfection we can catch excellence." Vince Lombardi _______________________________________________ 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 connectjunkie at gmail.com Wed May 20 05:28:24 2009 From: connectjunkie at gmail.com (Justin Clarke) Date: Wed, 20 May 2009 10:28:24 +0100 Subject: [SC-L] Cigital news (European market) In-Reply-To: <5C3C7B6F-1F49-4FA9-AA55-FA20C8167E86@krvw.com> Message-ID: On 20/05/2009 02:21, "Kenneth Van Wyk" wrote: > On May 20, 2009, at 12:34 AM, Gary McGraw wrote: >> We believe that the European software security market is 2-3 years >> behind the US market, but poised for rapid growth that will align it >> with the US market in a much shorter period. From what I can tell, >> the European market is 14-20% the size of the US market. > > > My experience there tells me that's an over-simplification of the > situation. It may be a simplification, but in my experience since moving from the US market to the UK market several years ago, its true enough for the UK market at least. > European enterprises, on the other hand, tend to be quite conservative > in taking to new practices. They want to see clear justifications > before diving in. > > But I just don't get the feeling that they're trying in any way to > "align themselves with the US market". They'll do their own thing in > their own time, which is as it should be. European enterprises also have different regulatory drivers. A large amount of the commonality in approaches in financial services can be tied back to the various regulatory regimes becoming somewhat closer - in that context its probably more with knowing what has worked in the US context and trying something similar in Europe than "following"... Remembering many of the larger European organisations have operations in the US. > From my own little "nanocosm" perspective, I continue to see the bulk > of my consulting engagements coming out of Europe and Southeast Asia. > I've found both markets to be quite receptive to software security > efforts for the past several years. Very true - In my case it was just that some of the approaches were very different to what I was used to having just come from the New York market to the London market :-) Justin From gem at cigital.com Wed May 20 06:36:24 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 20 May 2009 06:36:24 -0400 Subject: [SC-L] Cigital news (European market) In-Reply-To: <4A136319.8090109@secureconsulting.net> Message-ID: hi all, In my view, the European market now looks very similar to the US market of 2-3 years ago (not a decade ago). I predict a rash of pen testing, folllowed by adoption of SDLC integration. This will, of course, evolve in a very European way and there will be important regional differences. The good news is that the market is very likely to consolidate quickly to a very reasonable approach to software security. In that sense only will the market be like the US market. I believe it will get things right more easily. BTW, I have seen "the same" phenomenon in the US as NY led and the West coast (read CA) followed in software security. This is, of course, a huge generalization. The west coast is still in the throes of pen testing for the most part and just beginning to adopt software security initiatives. gem http://www.cigital.com/~gem On 5/19/09 9:55 PM, "Benjamin Tomhave" wrote: Kenneth Van Wyk wrote: > But I just don't get the feeling that they're trying in any way to > "align themselves with the US market". They'll do their own thing in > their own time, which is as it should be. > That syncs with my limited experience with Europeans, both in the past (the French in particular) and in the present (Dutch). Any suggestion that Europe will "follow" the US is probably an error in judgment and highly likely to offend. We should never forget that we're a mere 233 years old independently compared to their several centuries. The Roman Empire lasted almost twice that long. -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: ] "Perfection is not attainable, but if we chase perfection we can catch excellence." Vince Lombardi _______________________________________________ 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 May 20 07:10:02 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 20 May 2009 07:10:02 -0400 Subject: [SC-L] Silver Bullet: Kay Connelly Message-ID: hi sc-l, Silver Bullet 38 just went live. This episode features an up-and-coming professor Kay Connelly from Indiana University. Kay focuses on privacy and security. Much of her work takes into account the essential human nature of technology. Her work with seniors, security, and usability is particularly interesting. Have a listen: http://www.cigital.com/silverbullet/show-038/ As always, your feedback on the podcast is welcome. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From jim at manico.net Fri May 22 21:05:56 2009 From: jim at manico.net (Jim Manico) Date: Fri, 22 May 2009 15:05:56 -1000 Subject: [SC-L] OWASP Podcast #22 Message-ID: <0FE1E296DED941D29DB326D443268491@workhorse> Hello SC-L, OWASP Podcast #22, an interview with Dan Cornell, CTO of the Denim Group - is now live! http://www.owasp.org/index.php/Podcast_22 Dan is a smart cookie who puts in incredible amount of time volunteering for OWASP. He's a great guy with a very pragmatic perspective on Application Security. I hope you enjoy! Aloha from Kauai, Jim Manico OWASP Podcast Series Host -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090522/a8fcae2f/attachment.html From ford.trey at gmail.com Tue May 26 16:49:21 2009 From: ford.trey at gmail.com (Trey Ford) Date: Tue, 26 May 2009 16:49:21 -0400 Subject: [SC-L] OWASP PCI Project Introduction Message-ID: OWASP PCI Project :: Introduction and Call for Participation! We are formally introducing the OWASP PCI Project to the Web Application Security community! The industry needs a workspace for PCI QSAs* and Application Security experts to work constructively together - the OWASP PCI Project will serve as the platform in building community consensus. The PCI Project drives focused discussion and awareness, promoting a thorough understanding of how to ensure safety in online payments. Our mission is to: +Make payment application security requirements achievable, +QSA perspective and audit points accessible, +A unified and mutually agreed upon approach to secure payment applications, and sustainable compliance The scope of this group will ultimately extend beyond PCI, becoming a scalable software risk management framework for other regulations. ?By focusing on managing risk ? we are ensuring web sites, applications, and web enabled software of any type are secured the right way (and making compliance a natural and sustainable byproduct). Now is the time to get involved!? Visit the project site and sign up! ?We are starting to build the project roadmap, we need YOUR help in framing this project! Proposed projects include: +PCI Application Security Scoping Guidance, +Application Security Development Guidance, +PCI Application Security Auditor?s Playbooks, +More to come! Feel free to contact Trey Ford or Ed Bellis directly with any questions. ford trey gmail com ed bellis gmail com OWASP PCI Project : http://www.owasp.org/index.php/Category:OWASP_PCI_Project Thank you, Trey Ford and Ed Bellis * QSAs are Qualified Security Assessors- the individuals responsible for performing onsite audits and interpreting the PCI standard) From gem at cigital.com Mon Jun 1 14:10:47 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 1 Jun 2009 14:10:47 -0400 Subject: [SC-L] IEEE S&P: special issue on Securing Online Games Message-ID: hi sc-l, You may recall the CFP that Ming Chow and I put out back in the Fall for a special issue on Securing Online Games. After some great submissions and lots of hard work, I am pleased to announce that IEEE Security & Privacy magazine's May/June 2009 edition was just released. The issue (volume 7: number 3) covers Securing Online Games in a series of 4 peer reviewed articles that help define the state of the practice. For more about the issue, see: http://www.computer.org/portal/site/security Also in the same issue is a print transcript of Silver Bullet 36. That's the episode where James McGovern turned the tables and interviewed me. That transcript is on the web here: http://www.cigital.com/silverbullet/shows/silverbullet-036-gem.pdf The future of software security is on view today in online games. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleage book www.swsec.com From jim at manico.net Mon Jun 1 15:58:37 2009 From: jim at manico.net (Jim Manico) Date: Mon, 1 Jun 2009 09:58:37 -1000 Subject: [SC-L] OWASP Podcast #23 - Dr. Boaz Gelbord References: Message-ID: Hello SC-L, OWASP Podcast #23, an interview with Dr. Boaz Gelbord, is now live. http://www.owasp.org/download/jmanico/owasp_podcast_23.mp3 Boaz co-authored the 2009 OWASP Security Spending Benchmarks Project with Jeremiah Grossman. Boaz is also the new OWASP Developers Guide project lead. Thanks for listening, I hope you enjoy. Regards, Jim Manico Aspect Security/OWASP Podcast Host RSS: http://www.owasp.org/download/jmanico/podcast.xml iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090601/3ac84f58/attachment.html From ken at krvw.com Wed Jun 3 10:54:40 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 3 Jun 2009 10:54:40 -0400 Subject: [SC-L] Usability News - Why Security and Usability don't go hand in hand Message-ID: <221CFDB7-DB20-44DC-BDFF-8E00160AD33A@krvw.com> FYI, a short but interesting read on usability vs. security in software. http://www.usabilitynews.com/news/article5692.asp Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- 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/20090603/d031b0fb/attachment.bin From gem at cigital.com Wed Jun 3 15:01:55 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 3 Jun 2009 15:01:55 -0400 Subject: [SC-L] Reality Check: Andy Steingruebl Message-ID: hi sc-l, Episode 6 of the Reality Check security podcast features our own Andy Steingruebl chatting with me about Paypal's software security initiative. This was a fun episode for me, because though I have known Andy for a while I had little insight into his software security initiative. Thanks to Andy for participating! http://www.cigital.com/realitycheck/show-006/ I am currently on the lookout for suggestions of people to include in the Reality Check series. Remember, the criteria are that the victim should be running a large-scale software security initiative. Your comments are welcome. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From listas at sapao.net Thu Jun 4 11:57:09 2009 From: listas at sapao.net (Lucas Ferreira) Date: Thu, 4 Jun 2009 12:57:09 -0300 Subject: [SC-L] OWASP AppSec Brasil - Call for presentations In-Reply-To: <245770850905110949g6739c36fpe85b14a81be1ddb2@mail.gmail.com> References: <245770850905110949g6739c36fpe85b14a81be1ddb2@mail.gmail.com> Message-ID: <245770850906040857m15b64f96i5b98e818ad3cc33e@mail.gmail.com> **OWASP APPSEC BRASIL 2009** **CALL FOR PRESENTATIONS** Colleagues, OWASP is currently soliciting presentations for the OWASP AppSec Brasil 2009 Conference that will take place at C?mara dos Deputados in Bras?lia, DF on October 27th through 30th of 2009. There will be training courses on October 27th and 28th followed by plenary sessions on the 29th and 30th with each day having one single track. The conference will be organized and supported by the TI-Controle Community (www.ticontrole.gov.br) and the Deputy Chamber (www2.camara.gov.br/english). We are seeking people and organizations that want to present on any of the following topics (in no particular order): - Application Threat Modeling - Business Risks with Application Security - Hands-on Source Code Review - Metrics for Application Security - OWASP Tools and Projects - Privacy Concerns with Applications and Data Storage - Secure Coding Practices (J2EE/.NET) - Starting and Managing Secure Development Lifecycle Programs - Technology specific presentations on security such as AJAX, XML, etc - Web Application Security countermeasures - Web Application Security Testing - Web Services-, XML- and Application Security - Anything else relating to OWASP and Application Security To make a submission you must include : - Presenter name - Additional author(s) name(s) - Presenter(s) Email and/or Phone number(s) - Presenter(s) bio(s) and, optionally, bios of the other authors - Title - Abstract - Presentation outline, defining all topics that will be covered by the presentation - Any supporting research/tools (will not be released outside of CFP committee) Each presenter will have 45 minutes for the presentation, followed by 10 minutes reserved for questions from the audience. The presentations must respect the restrictions of the OWASP Speaker Agreement. **Important Dates:** Submission deadline is July 11th 2009 at 11:59 PM (UTC/GMT -3). Notification of acceptance is August 7th 2009. Final version is due September 5th 2009. Proposals must be sent by email to appsec.brasil (at) camara.gov.br For more information, please see the following web pages: Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2009 FAQ: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement TI-Controle: http://www.ticontrole.gov.br Deputy Chamber: http://www2.camara.gov.br/english Please forward to all interested practitioners and colleagues. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090604/27e1f4ac/attachment.html From listas at sapao.net Thu Jun 4 11:58:08 2009 From: listas at sapao.net (Lucas Ferreira) Date: Thu, 4 Jun 2009 12:58:08 -0300 Subject: [SC-L] OWASP AppSec Brasil 2009 - Call for Training Providers In-Reply-To: <245770850905181647p443bab9bqec16e7f957daae66@mail.gmail.com> References: <245770850905181647p443bab9bqec16e7f957daae66@mail.gmail.com> Message-ID: <245770850906040858n900a058n718095b4f9004e24@mail.gmail.com> **OWASP APPSEC BRASIL 2009** **CALL FOR TRAINING SESSIONS** Colleagues, OWASP is currently soliciting training proposals for the OWASP AppSec Brasil 2009 Conference which will take place at C?mara dos Deputados (Deputy Chamber) in Bras?lia, DF, on October 27th through October 30th 2009. There will be training courses on October 27th and 28th followed by plenary sessions on the 29th and 30th with one single track per day. The conference will be organized and supported by the TI-Controle Community (www.ticontrole.gov.br) and the Deputy Chamber (www2.camara.gov.br/english). We are seeking training proposals on the following topics (in no particular order): - Application Threat Modeling - Business Risks with Application Security - Hands-on Source Code Review - Metrics for Application Security - OWASP Tools and Projects - Privacy Concerns with Applications and Data Storage - Secure Coding Practices (J2EE/.NET) - Starting and Managing Secure Development Lifecycle Programs - Technology specific presentations on security such as AJAX, XML, etc - Web Application Security countermeasures - Web Application Security Testing - Web Services-, XML- and Application Security - Anything else relating to OWASP and Application Security Proposals on topics not listed above but related to the conference (i.e. which are related to Application Security) may also be accepted. There may be 1 or 2-day courses. The proposals must respect the restrictions of the OWASP Speaker Agreement. The conference sponsors will provide lodging and domestic (within Brazil) air travel for one presenter per course, no other compensation is available. If you require a different arrangement, please contact the conference organization team at the email address bellow. **Important Dates:** Submission deadline is July 11th 2009 at 11:59 PM (UTC/GMT -3). Notification of acceptance is August 7th 2009. Final version is due September 5th 2009. To make a proposal, please fill the form (http://www.owasp.org/images/4/4b/OWASP_AppSec_Brazil_09_CFT.docx) and send it by email to appsec.brasil (at) camara.gov.br For more information, please see the following web pages: Proposal form as a zipped RTF file: http://www.owasp.org/images/e/ea/OWASP_AppSec_Brazil_09_CFT_RTF.zip Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2009 FAQ: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement TI-Controle: http://www.ticontrole.gov.br Deputy Chamber: http://www2.camara.gov.br/english Please forward to all interested practitioners and colleagues. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090604/5584a66a/attachment.html From robert at webappsec.org Mon Jun 15 14:09:22 2009 From: robert at webappsec.org (robert at webappsec.org) Date: Mon, 15 Jun 2009 14:09:22 -0400 (EDT) Subject: [SC-L] Article: 'Setting the appropriate security defect handling expectations in development and QA' Message-ID: <20090615180922.49851.qmail@cgisecurity.net> Greetings, I have just published the following article on handling application security defects (vulnerabilities) in development and QA. "If you've worked in information security you've likely had to report a security defect to development in an effort to remediate the issue. Depending on your organization and its culture this can be a rather difficult task. As an information security professional it is your job to detect, communicate, and see to the remediation of such issues in your company as these issues are discovered. Likely development is saying that they're to busy to fix the issue and that if they try fixing it they'll miss the deadline for their release, resulting in their group getting penalized (sometimes bonuses are tied to release cycles) or getting a negative comment on their performance review. In other situations development may just be stubborn requiring full proof of concept code before taking your security defect seriously. Development may even refer to infosec as a group that impedes progress by throwing bugs into the grinding gears of a given software release. As an infosec professional you may feel at times helpless, or unable to do your job successfully due to the actions and stances of other groups. If you're currently in this situation there are a few things that you can do to get development either on the same page as you, or at least in agreement to the handling of these issues when they inevitably creep up." Setting the appropriate security defect handling expectations in development and QA http://www.qasec.com/2009/06/setting-the-appropriate-security-defect-handling-expectations-in-development-and-qa.html Regards, - Robert http://www.webappsec.org/ http://www.cgisecurity.com/ http://www.qasec.com/ From gem at cigital.com Thu Jun 18 12:07:43 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 18 Jun 2009 12:07:43 -0400 Subject: [SC-L] Software Security and Business Message-ID: hi sc-l, We all know that justifying our activities from a business perspective is essential to a healthy and successful software security initiative. Real data helps. In the Boardroom, numbers are king. Jim Routh (CSO of KPMG and ex CSO of DTCC) and I wrote this month's informIT article about demonstrating software security business value at DTCC. This is a case study of one very successful software security initiative. How DTCC Builds Better Software and at a Lower Cost http://www.informit.com/articles/article.aspx?p=1357183 For more about DTCC's software security initiative, also listen to Reality Check episode 2: http://www.cigital.com/realitycheck/show-002/ As always, we welcome your feedback. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Thu Jun 18 12:25:54 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 18 Jun 2009 12:25:54 -0400 Subject: [SC-L] Silver Bullet: Matt Blaze Message-ID: hi sc-l, When it rains it pours...especially in Virginia these days. Silver Bullet number 39 is an interview with Matt Blaze, security and privacy luminary. Matt and I spent lots of time digging into Matt's public policy work. Matt is an important voice of sanity whose opinions I greatly admire. And he coined the term "trust management." http://www.cigital.com/silverbullet/show-039/ Some of Matt's work has been published by IEEE Security & Privacy magazine in highly popular articles. There are a couple of pointers on the Silver Bullet page for the episode. IEEE S&P is the co-sponsor of Silver Bullet. As always, your feedback is welcome. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From goertzel_karen at bah.com Wed Jun 17 15:29:37 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 17 Jun 2009 15:29:37 -0400 Subject: [SC-L] Mocana's NanoDefender References: <20090615180922.49851.qmail@cgisecurity.net> Message-ID: <184D5FFC5203644FB4F8864B0EE445B40392E171@MCLNEXVS06.resource.ds.bah.com> I came across this while doing some research into antimalware tools. If it actually work,s it seems like a nifty little trick to have in one's "secure coding" back pocket. http://mocana.com/NanoDefender.html -- 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/20090617/ca08a855/attachment.html From jim at manico.net Wed Jun 17 19:16:02 2009 From: jim at manico.net (Jim Manico) Date: Wed, 17 Jun 2009 13:16:02 -1000 Subject: [SC-L] OWASP Podcast 26 - News Roundtable Message-ID: <53089EACB8D1430282F11A46F2D323EF@workhorse> Hello SC-L, I just pushed OWASP Podcast #26 live. We had Tom Brennan (White Hat Security), Jeff Williams (Aspect), Alex Smolen (Foundstone), Andre Gironda (The "House" of AppSec) on the show - a very mixed group with different perspectives. Download options and show notes are here http://www.owasp.org/index.php/Podcast_26 or just grab the mp3 http://www.owasp.org/download/jmanico/owasp_podcast_26.mp3 Thanks for listening! (or at least downloading :) Best Regards, Jim Manico OWASP Podcast Host PS : We discussed the following articles on this show. 4/16 http://www.informit.com/articles/article.aspx?p=1338343 http://www.cigital.com/justiceleague/2009/04/16/software-security-2008/ Gary McGraw uses statistics to show that Software Security has come of ag 4/17 http://research.zscaler.com/2009/04/we-used-to-laugh-at-xss.html Michael Sutton discusses history of XSS from Defcon 10 (2002) to the present day (Twitter worm) 4/17 http://jeremiahgrossman.blogspot.com/2009/04/software-security-grew-to-nearly-500m.html Jeremiah uses McDonalds and Mortons as comparatives for black-box vs. white-box security testing 4/17 http://jeremiahgrossman.blogspot.com/2009/04/website-threats-and-their-capabilities.html OWASP Catalyst announced 4/20 http://paco.to/?p=305 Paco lists 5 reasons for software certifications 4/20 http://www.greensheet.com/newswire.php?newswire_id=11693 Qualys, Inc., the leading provider of on demand IT security risk and compliance management solutions, today announced QualysGuard(R) PCI Connect which is the industry's first Software-as-as-Service (SaaS) ecosystem for PCI compliance connecting merchants to multiple partners and security solutions in order to document and meet all 12 requirements for PCI DSS 4/20 http://labs.securitycompass.com/index.php/2009/04/20/security-analysis-of-core-j2ee-design-patterns/ Rohit Sethi of SecurityCompass posts a blog post on a new Security Compass Labs blog about "Security Analysis of Core Java Enterprise Patterns" 4/21 http://docs.google.com/Doc?id=dd7x5smw_16hdd34ggz mario heiderich posts some results of browser fuzzing on extraneous characters in tags 4/22 http://plynt.com/blog/2009/04/how-frequently-should-an-appli/ The Plynt blog asks the question, "How frequently shoud Applications be Tested?" 4/24 http://www.troopers09.org/content/e3/e445/index_eng.html Wendel Guglielmetti Henrique from Trustwave and Sandro Gauchi of EnableSecurity spoke at TROOPERS09 in Munch about "The Truth of Web Application Firewalls: what the vendors do NOT want you to know" 4/27 http://tacticalwebappsec.blogspot.com/2009/04/scanner-and-waf-data-sharing.html Ryan Barnett gives guidance on how best to make VA+WAF work together 4/27 http://www.owasp.org/index.php/Category:OWASP_PCI_Project Ed Bellis and Trey Ford start a PCI effort to ensure their activities uniformly meet PCI requirements, and for those getting started - to aid in building a website security strategy that also ensures sustainable PCI compliance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090617/7568ba9c/attachment.html From andrews at rbacomm.com Thu Jun 18 18:04:07 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Thu, 18 Jun 2009 17:04:07 -0500 Subject: [SC-L] Work in the Secure Development/Secure Code Review Area? Message-ID: <20090618170407.tso4uoxla80ogw40@webmail.rbacomm.com> What kinds of positions/work are available in this area now? Could someone make a living doing freelance research/articles/presentations in this area? I will be leaving my company at the end of August and I am actively planning my future now. If you have some good thoughts or ideas, please let me know. I have plenty of ideas, but I thought this list might have some people who would know things I might not have thought about. I plan on being more active in OWASP, but that won't pay anything, so I need to find a way to make enough to support work like that. I would also like to put anything I find into an article/paper/something because I figure the "career question" is of interest to a lot of people. :) -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI From James.McGovern at thehartford.com Fri Jun 19 10:05:25 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Fri, 19 Jun 2009 10:05:25 -0400 Subject: [SC-L] Work in the Secure Development/Secure Code Review Area? In-Reply-To: <20090618170407.tso4uoxla80ogw40@webmail.rbacomm.com> References: <20090618170407.tso4uoxla80ogw40@webmail.rbacomm.com> Message-ID: The market for doing freelance writing has all but disappeared. You could consider writing a book but you would probably earn more money working at MacDonalds bagging fries than writing. In terms of presentations, most conferences/events also do not pay. If you managed to however put together training courses, there is some possibility. Being involved in OWASP will help you network with others who actually have money to spend on your services. Many OWASP meetings are held in space of major corporations (e.g. http://www.owasp.org/index.php/Hartford) -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews Sent: Thursday, June 18, 2009 6:04 PM To: sc-l at securecoding.org Subject: [SC-L] Work in the Secure Development/Secure Code Review Area? What kinds of positions/work are available in this area now? Could someone make a living doing freelance research/articles/presentations in this area? I will be leaving my company at the end of August and I am actively planning my future now. If you have some good thoughts or ideas, please let me know. I have plenty of ideas, but I thought this list might have some people who would know things I might not have thought about. I plan on being more active in OWASP, but that won't pay anything, so I need to find a way to make enough to support work like that. I would also like to put anything I find into an article/paper/something because I figure the "career question" is of interest to a lot of people. :) -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI _______________________________________________ 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. _______________________________________________ ************************************************************ 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 prasad.shenoy at gmail.com Fri Jun 19 16:18:42 2009 From: prasad.shenoy at gmail.com (Prasad Shenoy) Date: Fri, 19 Jun 2009 16:18:42 -0400 Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser Message-ID: <43c6c8500906191318wf7a1bdu2f8f0783bca18025@mail.gmail.com> Lenny Zeltser has published a Security Architecture Cheat Sheet. Out of his many cheat sheets, this one in particular might be of interest (in order of relevance :-)) to coders and architects on the group. http://www.zeltser.com/security-management/security-architecture-cheat-sheet.pdf Regards, Prasad Shenoy From jim at manico.net Fri Jun 19 23:15:14 2009 From: jim at manico.net (Jim Manico) Date: Fri, 19 Jun 2009 17:15:14 -1000 Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser References: <43c6c8500906191318wf7a1bdu2f8f0783bca18025@mail.gmail.com> Message-ID: <8FF5F36E8A1148E9BB3732CA7B44BEB4@workhorse> Very nice work. Since this is written under the creative common 3 license, I put a copy (with attribution to Lenny) on OWASP.org at http://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet in case anyone wishes to collaborate on this guide. - Jim ----- Original Message ----- From: "Prasad Shenoy" To: Sent: Friday, June 19, 2009 10:18 AM Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser > Lenny Zeltser has published a Security Architecture Cheat Sheet. Out > of his many cheat sheets, this one in particular might be of interest > (in order of relevance :-)) to coders and architects on the group. > > http://www.zeltser.com/security-management/security-architecture-cheat-sheet.pdf > > Regards, > Prasad Shenoy > _______________________________________________ > 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 prasad.shenoy at gmail.com Sat Jun 20 08:04:36 2009 From: prasad.shenoy at gmail.com (Prasad Shenoy) Date: Sat, 20 Jun 2009 08:04:36 -0400 Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser In-Reply-To: <8FF5F36E8A1148E9BB3732CA7B44BEB4@workhorse> References: <43c6c8500906191318wf7a1bdu2f8f0783bca18025@mail.gmail.com> <8FF5F36E8A1148E9BB3732CA7B44BEB4@workhorse> Message-ID: <43c6c8500906200504w2a67b389ib9cbe827b7de3736@mail.gmail.com> Good idea :-) On Fri, Jun 19, 2009 at 11:15 PM, Jim Manico wrote: > Very nice work. > > Since this is written under the creative common 3 license, I put a copy > (with attribution to Lenny) on OWASP.org at > http://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet in case > anyone wishes to collaborate on this guide. > > - Jim > > > ----- Original Message ----- From: "Prasad Shenoy" > To: > Sent: Friday, June 19, 2009 10:18 AM > Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser > > >> Lenny Zeltser has published a Security Architecture Cheat Sheet. Out >> of his many cheat sheets, this one in particular might be of interest >> (in order of relevance :-)) to coders and architects on the group. >> >> >> http://www.zeltser.com/security-management/security-architecture-cheat-sheet.pdf >> >> Regards, >> Prasad Shenoy >> _______________________________________________ >> 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. >> _______________________________________________ >> > > -- Thought for the day - "Emails can hurt feelings. If this one did, please ignore your feelings." From john.wilander at omegapoint.se Tue Jun 23 16:55:36 2009 From: john.wilander at omegapoint.se (John Wilander) Date: Tue, 23 Jun 2009 22:55:36 +0200 Subject: [SC-L] OWASP AppSec Research 2010 - Call for Papers In-Reply-To: Message-ID: Dear secure coding friends, In exactly one year -- June 21-24, 2010 -- let's all meet in beautiful Stockholm, Sweden. OWASP Sweden, Norway, and Denmark hereby invite you to OWASP AppSec Research 2010. AppSec Research = AppSec Europe This conference was formerly known as OWASP AppSec Europe. We have added 'Research' to highlight that we invite both industry and academia. All the regular AppSec Europe visitors and topics are welcome along with contributions from universities and research institutes. This is the European conference for anyone interested in or working with application security. Co-host is the Department of Computer and Systems Science at Stockholm University, offering a great venue in the fabulous Aula Magna. Call for Papers and Proposals We offer two options: 1. Full papers. Peer-reviewed 12 page papers that will be published in formal proceedings by Springer-Verlag Lecture Notes in Computer Science (final approval pending). 2. Presentation proposals. A presentation proposal should consist of a 2-page position paper representing the essential matter proposed by the speaker(s). Proposals must include sufficient material for the reviewers to make an informed decision. Topics of Interest We encourage the publication and presentation of new tools, new methods, empirical data, novel ideas, and lessons learned in the following areas: ? Web application security ? Security aspects of new/emerging web technologies/paradigms (mashups, web 2.0, offline support, etc) ? Security in web services, REST, and service oriented architectures ? Security in cloud-based services ? Security of frameworks (Struts, Spring, ASP.Net MVC etc) ? New security features in platforms or languages ? Next-generation browser security ? Security for the mobile web ? Secure application development (methods, processes etc) ? Threat modeling of applications ? Vulnerability analysis (code review, pentest, static analysis etc) ? Countermeasures for application vulnerabilities ? Metrics for application security ? Application security awareness and education Submission Deadline and Instructions Submission deadline is Sunday February 7th 23:59 (Apia, Samoa time). Submissions should be at most 12 pages long in the Springer LNCS style for "Proceedings and Other Multiauthor Volumes". Templates for preparing papers in this style for LaTeX, Word, etc can be downloaded from: http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0. Full papers must be submitted in a form suitable for anonymous review: remove author names and affiliations from the title page, and avoid explicit self-referencing in the text. Program Committee ? John Wilander, Omegapoint and Link?ping University (chair) ? Alan Davidson, Stockholm University/Royal Institute of Technology (co-host) ? Andrei Sabelfeld, Chalmers UT ? Engin Kirda, Institute Eurecom ? Lieven Desmet, Katholieke Universiteit Leuven ? Martin Johns, University of Passau ? Christoph Kern, Google ? Sergio Maffeis, Imperial College London Organizing Committee ? John Wilander, chapter leader Sweden (chair) ? Mattias Bergling (vice chair) ? Alan Davidson, Stockholm University/Royal Institute of Technology (co-host) ? Ulf Munkedal, chapter leader Denmark ? K?re Presttun, chapter leader Norway ? Stefan Pettersson (sponsoring coordinator) ? Carl-Johan Bostorp (schedule and event coordinator) ? Martin Holst Swende (coffee/lunch/dinner) ? Kate Hartmann, OWASP ? Sebastien Deleersnyder, OWASP Board Countdown Challenges -- Free Tickets to Win! There will be a challenge posted on the conference wiki page the 21st every month up until the event. The winner will get free entrance to the conference. What are you waiting for? The first challenge is posted. Go, go, go -- https://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm%2C_Sw eden#AppSec_Research_Challenge_1:_Input_Validation_and_Regular_Expressions. OWASP The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org. Welcome to Stockholm next year! Regards, John Wilander -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090623/fd3948d8/attachment.html From listas at sapao.net Wed Jun 24 13:16:58 2009 From: listas at sapao.net (Lucas Ferreira) Date: Wed, 24 Jun 2009 14:16:58 -0300 Subject: [SC-L] OWASP AppSec Brasil - 2nd Call for presentations Message-ID: <245770850906241016l660e3fdbsd2e41a42906e3d79@mail.gmail.com> **OWASP APPSEC BRASIL 2009** **2nd CALL FOR PRESENTATIONS** Colleagues, OWASP is currently soliciting presentations for the OWASP AppSec Brasil 2009 Conference that will take place at C?mara dos Deputados in Bras?lia, DF on October 27th through 30th of 2009. There will be training courses on October 27th and 28th followed by plenary sessions on the 29th and 30th with each day having one single track. The conference will be organized and supported by the TI-Controle Community (www.ticontrole.gov.br) and the Deputy Chamber (www2.camara.gov.br/english). We have confirmed Mr. Gary McGraw as a keynote speaker for this conference. For more information, please see the conference page listed at the bottom of this message. We are seeking people and organizations that want to present on any of the following topics (in no particular order): - Application Threat Modeling - Business Risks with Application Security - Hands-on Source Code Review - Metrics for Application Security - OWASP Tools and Projects - Privacy Concerns with Applications and Data Storage - Secure Coding Practices (J2EE/.NET) - Starting and Managing Secure Development Lifecycle Programs - Technology specific presentations on security such as AJAX, XML, etc - Web Application Security countermeasures - Web Application Security Testing - Web Services-, XML- and Application Security - Anything else relating to OWASP and Application Security To make a submission you must include : - Presenter name - Additional author(s) name(s) - Presenter(s) Email and/or Phone number(s) - Presenter(s) bio(s) and, optionally, bios of the other authors - Title - Abstract - Presentation outline, defining all topics that will be covered by the presentation - Any supporting research/tools (will not be released outside of CFP committee) Each presenter will have 45 minutes for the presentation, followed by 10 minutes reserved for questions from the audience. The presentations must respect the restrictions of the OWASP Speaker Agreement. **Important Dates:** Submission deadline is July 11th 2009 at 11:59 PM (UTC/GMT -3). Notification of acceptance is August 7th 2009. Final version is due September 5th 2009. Proposals must be sent by email to appsec.brasil (at) camara.gov.br For more information, please see the following web pages: Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2009 FAQ: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement TI-Controle: http://www.ticontrole.gov.br Deputy Chamber: http://www2.camara.gov.br/english Please forward to all interested practitioners and colleagues. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090624/b09e1460/attachment.html From listas at sapao.net Wed Jun 24 13:22:41 2009 From: listas at sapao.net (Lucas Ferreira) Date: Wed, 24 Jun 2009 14:22:41 -0300 Subject: [SC-L] OWASP AppSec Brasil 2009 - 2nd Call for Training Providers Message-ID: <245770850906241022u5b522655see1f04a3efde4312@mail.gmail.com> **OWASP APPSEC BRASIL 2009** **2nd CALL FOR TRAINING SESSIONS** Colleagues, OWASP is currently soliciting training proposals for the OWASP AppSec Brasil 2009 Conference which will take place at C?mara dos Deputados (Deputy Chamber) in Bras?lia, DF, on October 27th through October 30th 2009. There will be training courses on October 27th and 28th followed by plenary sessions on the 29th and 30th with one single track per day. The conference will be organized and supported by the TI-Controle Community (www.ticontrole.gov.br) and the Deputy Chamber (www2.camara.gov.br/english). We are seeking training proposals on the following topics (in no particular order): - Application Threat Modeling - Business Risks with Application Security - Hands-on Source Code Review - Metrics for Application Security - OWASP Tools and Projects - Privacy Concerns with Applications and Data Storage - Secure Coding Practices (J2EE/.NET) - Starting and Managing Secure Development Lifecycle Programs - Technology specific presentations on security such as AJAX, XML, etc - Web Application Security countermeasures - Web Application Security Testing - Web Services-, XML- and Application Security - Anything else relating to OWASP and Application Security Proposals on topics not listed above but related to the conference (i.e. which are related to Application Security) may also be accepted. There may be 1 or 2-day courses. The proposals must respect the restrictions of the OWASP Speaker Agreement. The conference sponsors will provide lodging and domestic (within Brazil) air travel for one presenter per course, no other compensation is available. If you require a different arrangement, please contact the conference organization team at the email address bellow. **Important Dates:** Submission deadline is July 11th 2009 at 11:59 PM (UTC/GMT -3). Notification of acceptance is August 7th 2009. Final version is due September 5th 2009. To make a proposal, please fill the form (http://www.owasp.org/images/4/4b/OWASP_AppSec_Brazil_09_CFT.docx) and send it by email to appsec.brasil (at) camara.gov.br For more information, please see the following web pages: Proposal form as a zipped RTF file: http://www.owasp.org/images/e/ea/OWASP_AppSec_Brazil_09_CFT_RTF.zip Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2009 FAQ: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement TI-Controle: http://www.ticontrole.gov.br Deputy Chamber: http://www2.camara.gov.br/english Please forward to all interested practitioners and colleagues. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090624/f0634220/attachment.html From mtesauro at gmail.com Mon Jun 29 14:42:40 2009 From: mtesauro at gmail.com (Matt Tesauro) Date: Mon, 29 Jun 2009 13:42:40 -0500 Subject: [SC-L] Ross Anderson Interview: OWASP Podcast #28 Message-ID: <4A490B20.9020304@gmail.com> I apologize for the shameless self promotion, but I wanted to let you know that the interview I did with Ross Anderson at AppSec EU 2009 [1] is now available as an OWASP Podcast here: http://www.owasp.org/index.php/Podcast_28 and on iTunes [2]. It covers some very interesting topics and expands on some of the issues raised in his keynote on May 13th [3] titled "Web App Security ? The Good, the Bad and the Ugly". Definitely worth listening to the 32 minutes - in my humble opinion. You may know Ross Anderson for his very well regarded book Security Engineering [4] which is now in its second edition. [1] http://www.owasp.org/index.php/OWASP_AppSec_Europe_2009_-_Poland [2] http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 [3] http://www.owasp.org/index.php/OWASP_AppSec_Europe_2009_-_Poland#tab=Conference_-_May_13 [4] http://www.cl.cam.ac.uk/~rja14/book.html Cheers! -- -- Matt Tesauro OWASP Live CD Project Lead http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project http://AppSecLive.org - Community and Download site From stacy at safecode.org Mon Jun 29 16:52:04 2009 From: stacy at safecode.org (Stacy Simpson) Date: Mon, 29 Jun 2009 16:52:04 -0400 Subject: [SC-L] SAFECode Seeks Comment on Secure Development Practices Message-ID: All, I wanted to let you know that the Software Assurance Forum for Excellence in Code (SAFECode) will be accepting comments on its paper, "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today," through the end of July. As background, SAFECode originally released this paper in October 2008. It outlines a core set of secure development practices that can be applied across diverse development environments to improve software security and is based on an analysis of the individual software assurance efforts of SAFECode members. The brief paper describes each identified security practice across the software development lifecycle ? Requirements, Design, Programming, Testing, Code Handling and Documentation ? and offers implementation advice based on the experiences of SAFECode members. SAFECode will be releasing an updated version of the paper in late 2009, and in an effort to make the paper?s recommendations as useful and relevant as possible, we are offering experts outside of our membership an opportunity to provide input into the paper?s next version. If you would like to review the paper and/or submit comments, please visit: http://www.safecode.org/feedback.php We will be accepting comments until July 31, 2009. Thanks, Stacy Simpson SAFECode stacy at safecode.org +1 703-812-9199 From gunnar at arctecgroup.net Fri Jul 3 10:13:35 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 3 Jul 2009 09:13:35 -0500 Subject: [SC-L] Life imitates McGraw Message-ID: <596825EE-E367-45C9-8F9A-F3193E8E87F8@arctecgroup.net> Billions stolen in online robbery Space trading game Eve Online has suffered a virtual version of the credit crunch. One of the game's biggest financial institutions lost a significant chunk of its deposits as a huge theft started a run on the bank. One of the bank's controllers stole about 200bn kredits and swapped them for real world cash of ?3,115. As news of the theft spread, many of the bank's customers rushed to remove their virtual cash. ... The scandal is not the first to play out in Eve Online. In early 2009 one of the game's biggest corporations, called Band of Brothers, was brought down by industrial espionage. http://news.bbc.co.uk/2/hi/technology/8132547.stm -gunnar From gem at cigital.com Mon Jul 6 10:27:59 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 6 Jul 2009 10:27:59 -0400 Subject: [SC-L] Reality Check #7: Jerry Archer Message-ID: hi sc-l, I'm just back from vacation and still rinsing the sand off. I am a bit behind announcing the debut of Reality Check #7. This episode features Jerry Archer, CSO of Intuit. Intuit has an extensive software security initiative underway which jerry and I discuss in this podcast: http://www.cigital.com/realitycheck/show-007/ As always, your feedback is welcome. Now back to the email pile... gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From jim at manico.net Wed Jul 8 01:54:14 2009 From: jim at manico.net (James Manico) Date: Tue, 7 Jul 2009 22:54:14 -0700 Subject: [SC-L] OWASP Podcast Series Update Message-ID: Hello SC-L, We've been rather busy at the OWASP Podcast Series lately! Since June 1st the OWASP Podcast Team has released 9 Podcasts! Please take a look at our show list at http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows Recent features Podcasts include 1. An interview with *Mark Curphey*, the founder of the OWASP Project and currently the director of the security tools team at Microsoft. http://www.owasp.org/download/jmanico/owasp_podcast_31.mp3 2. *Billy Hoffman and Matt Wood*, the HP WebAppSec research team http://www.owasp.org/download/jmanico/owasp_podcast_30.mp3 3. An interview with *Ross Anderson* from OWASP EU Poland (Matt Tesauro is the interviewer) http://www.owasp.org/download/jmanico/owasp_podcast_28.mp3 Other excellent interviews this month include Rafal Losand Justin Clarke . Our audience has exploded; it's really a honor and a pleasure to produce this podcast series. We will be slowing down in August to give everyone a chance to catch up, but will surely kick it back in gear in September as additional OWASP volunteersjoin the team. Much Aloha, Jim Manico OWASP Podcast Series Host -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090707/55e4a3f9/attachment.html From listas at sapao.net Wed Jul 8 14:42:30 2009 From: listas at sapao.net (Lucas Ferreira) Date: Wed, 8 Jul 2009 15:42:30 -0300 Subject: [SC-L] AppSec Brasil 2009 - email issues Message-ID: <245770850907081142pddec516s1bb713330378cfd2@mail.gmail.com> Dear colleagues, the AppSec Brasil 2009 Conference had a few issues receiving emails sent from Gmail in the last couple of weeks. So, if you or anyone you know sent us a proposal, please verify that a confirmation email was received. If not, please send us the proposal again. Sorry for the inconvenience, AppSec Brasil Organizing Team ---------------- *CALL FOR PRESENTATIONS* OWASP is currently soliciting presentations for the OWASP AppSec Brasil 2009 Conference that will take place at C?mara dos Deputados in Bras?lia, DF on October 27th through 30th of 2009. There will be training courses on October 27th and 28th followed by plenary sessions on the 29th and 30th with each day having one single track. The conference will be organized and supported by the TI-Controle Community (www.ticontrole.gov.br) and the Deputy Chamber (www2.camara.gov.br/english). We are seeking people and organizations that want to present on any of the following topics (in no particular order): - Application Threat Modeling - Business Risks with Application Security - Hands-on Source Code Review - Metrics for Application Security - OWASP Tools and Projects - Privacy Concerns with Applications and Data Storage - Secure Coding Practices (J2EE/.NET) - Starting and Managing Secure Development Lifecycle Programs - Technology specific presentations on security such as AJAX, XML, etc - Web Application Security countermeasures - Web Application Security Testing - Web Services-, XML- and Application Security - Anything else relating to OWASP and Application Security To make a submission you must include : - Presenter name - Additional author(s) name(s) - Presenter(s) Email and/or Phone number(s) - Presenter(s) bio(s) and, optionally, bios of the other authors - Title - Abstract - Presentation outline, defining all topics that will be covered by the presentation - Any supporting research/tools (will not be released outside of CFP committee) Each presenter will have 45 minutes for the presentation, followed by 10 minutes reserved for questions from the audience. The presentations must respect the restrictions of the OWASP Speaker Agreement. *Important Dates:* Submission deadline is July 11th 2009 at 11:59 PM (UTC/GMT -3). Notification of acceptance is August 7th 2009. Final version is due September 5th 2009. Proposals must be sent by email to *appsec.brasil (at) camara.gov.br* For more information, please see the following web pages: Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2009 FAQ: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement TI-Controle: http://www.ticontrole.gov.br Deputy Chamber: http://www2.camara.gov.br/english -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090708/b6a733de/attachment.html From gem at cigital.com Thu Jul 16 10:26:09 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 16 Jul 2009 10:26:09 -0400 Subject: [SC-L] informIT: US Cybersecurity Message-ID: hi sc-l, While I was on vacation last month, Gartner held its Information Security Summit in Washington. John Pescatore, one of Gartner's senior analysts and an important proponent of software security asked me to participate in a panel (together with Howard Schmidt) on the Obama administration's plans for cybersecurity. Since I couldn't make the panel, we recorded a video response to John's questions which John showed at the summit. The questions were formulated to prompt a reaction to Melissa Hathaway's 60-day review and Obama's speech at the White House. This month's informIT column is devoted to US Cybersecurity plans and my thoughts sparked by John's questions: http://www.informit.com/articles/article.aspx?p=1379758 The original video is now up on the Justice League blog as well: http://www.cigital.com/justiceleague/2009/07/14/moving-cybersecurity-past-cyberplatitudes/ As always, I welcome your feedback. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck book www.swsec.com From gem at cigital.com Fri Jul 17 12:25:35 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 17 Jul 2009 12:25:35 -0400 Subject: [SC-L] Silver Bullet 40: Bob Blakley Message-ID: hi sc-l, One of our sc-l listeners (gunnar) suggested Bob Blakley as an interview target. Bob is a particularly interesting guy because he both a well-respected scientist very active in the security research community and a real practitioner who among other things designed the CORBA security model. These days, Bob is an analyst for the Burton Group. http://www.cigital.com/silverbullet/show-040/ Thanks to Gunnar for the suggestion. As always, your feedback on the podcast is welcome. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From gunnar at arctecgroup.net Fri Jul 17 13:28:37 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 17 Jul 2009 12:28:37 -0500 Subject: [SC-L] Silver Bullet 40: Bob Blakley In-Reply-To: References: Message-ID: +1 great interview -gunnar On Jul 17, 2009, at 11:25 AM, Gary McGraw wrote: > hi sc-l, > > One of our sc-l listeners (gunnar) suggested Bob Blakley as an > interview target. Bob is a particularly interesting guy because he > both a well-respected scientist very active in the security research > community and a real practitioner who among other things designed > the CORBA security model. These days, Bob is an analyst for the > Burton Group. > > http://www.cigital.com/silverbullet/show-040/ > > Thanks to Gunnar for the suggestion. As always, your feedback on > the podcast is welcome. > > gem > > company www.cigital.com > podcast www.cigital.com/realitycheck > blog www.cigital.com/justiceleague > book www.swsec.com > From rcs at cert.org Mon Jul 20 09:04:34 2009 From: rcs at cert.org (Robert Seacord) Date: Mon, 20 Jul 2009 09:04:34 -0400 Subject: [SC-L] As-if Infinitely Ranged Integer Model In-Reply-To: References: Message-ID: The Secure Coding Initiative at CERT has published a new Technical Note CMU/SEI-2009-TN-023 entitled "As-if Infinitely Ranged Integer Model". Abstract: Integer overflow and wraparound are major causes of software vulnerabilities in the C and C++ programming languages. In this paper we present the as-if infinitely ranged (AIR) integer model, which provides a largely automated mechanism for eliminating integer overflow and integer truncation. The AIR integer model either produces a value equivalent to one that would have been obtained using infinitely ranged integers or results in a runtime constraint violation. Unlike previous integer models, AIR integers do not require precise traps, and consequently do not break or inhibit most existing optimizations. Authors: David Keaton (self) Thomas Plum (Plum Hall Inc.) Robert C. Seacord (SEI/CERT) David Svoboda (SEI/CERT) Alex Volkovitsky (SEI/CERT) Timothy Wilson (SEI/CERT) A PDF Download of this paper is available at: http://www.sei.cmu.edu/publications/documents/09.reports/09tn023.html I would be interested in hearing your opinions on this work, either publically or privately. We are planning on continuing this project, as described by the report. Thanks, rCs ---- Robert C. Seacord Secure Coding Team Lead CERT / Software Engineering Institute Work: +1 412.268.7608 FAX: +1 412.268.6989 From gem at cigital.com Tue Jul 21 11:18:39 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 21 Jul 2009 11:18:39 -0400 Subject: [SC-L] SB transcript: Virgil Gligor Message-ID: hi sc-l, The transcript for episode 37 (an interview with Virgil Gligor) was just published in IEEE Security & Privacy magazine. Here is a link to a pdf file: http://www.cigital.com/silverbullet/shows/silverbullet-037-vgligor.pdf The original episode can be found here: http://www.cigital.com/silverbullet/show-037/ gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From kowsik at gmail.com Fri Jul 24 01:55:06 2009 From: kowsik at gmail.com (kowsik) Date: Thu, 23 Jul 2009 22:55:06 -0700 Subject: [SC-L] Large scale development with Ruby Message-ID: <7db9abd30907232255j643ac771ncefba1255af93d82@mail.gmail.com> Not so much about secure-coding, but more about how we take unit testing and TDD very seriously: http://labs.mudynamics.com/2009/07/23/large-scale-ruby-development-with-tdd/ Are there people on the sc-l that have a comparable large-scale ruby project? I would love to hear about the "gotchas" of using Ruby in production environments and what to watch out for... Thanks, K. --- http://labs.mudynamics.com http://www.pcapr.net From ken at krvw.com Tue Jul 28 10:19:28 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 28 Jul 2009 10:19:28 -0400 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. Message-ID: <646115F6-C87C-4A6B-A5BD-C1D85FB7581D@krvw.com> Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- 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/20090728/c77b2402/attachment.bin From prasad.shenoy at gmail.com Tue Jul 28 10:39:58 2009 From: prasad.shenoy at gmail.com (Prasad Shenoy) Date: Tue, 28 Jul 2009 10:39:58 -0400 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <646115F6-C87C-4A6B-A5BD-C1D85FB7581D@krvw.com> References: <646115F6-C87C-4A6B-A5BD-C1D85FB7581D@krvw.com> Message-ID: <43c6c8500907280739u5cb4ed44w4fa318e6e6e72a07@mail.gmail.com> Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks & Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: > Wow, big acquisition news in the static code analysis space announced today: > > http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > (This email is digitally signed with a free x.509 certificate from CAcert. > If you're unable to verify the signature, try getting their root CA > certificate at http://www.cacert.org -- for free.) > > > > > > > _______________________________________________ > 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 matt at piscis-security.com Tue Jul 28 12:29:30 2009 From: matt at piscis-security.com (Matt Fisher) Date: Tue, 28 Jul 2009 11:29:30 -0500 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. Message-ID: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -----Original Message----- From: Prasad Shenoy Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks & Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: > Wow, big acquisition news in the static code analysis space announced today: > > http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > (This email is digitally signed with a free x.509 certificate from CAcert. > If you're unable to verify the signature, try getting their root CA > certificate at http://www.cacert.org -- for free.) > > > > > > > _______________________________________________ > 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 tomb at owasp.org Tue Jul 28 13:24:06 2009 From: tomb at owasp.org (Tom Brennan) Date: Tue, 28 Jul 2009 17:24:06 +0000 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> Message-ID: <227939985-1248801836-cardhu_decombobulator_blackberry.rim.net-76346069-@bxe1121.bisx.prod.on.blackberry> Fortify (www.fortify.com) has Partnered with WhiteHat Security (www.whitehatsec.com) too Tom Brennan Board Member - OWASP Foundation Url: www.owasp.org | Tel: 973-202-0122 http://www.linkedin.com/in/tombrennan -----Original Message----- From: Matt Fisher Date: Tue, 28 Jul 2009 11:29:30 To: Prasad Shenoy; Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -----Original Message----- From: Prasad Shenoy Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks & Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: > Wow, big acquisition news in the static code analysis space announced today: > > http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > (This email is digitally signed with a free x.509 certificate from CAcert. > If you're unable to verify the signature, try getting their root CA > certificate at http://www.cacert.org -- for free.) > > > > > > > _______________________________________________ > 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 matt at piscis-security.com Tue Jul 28 13:29:41 2009 From: matt at piscis-security.com (Matt Fisher) Date: Tue, 28 Jul 2009 12:29:41 -0500 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. Message-ID: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> Ah sorry didn't mean to leave you out Tom. -----Original Message----- From: Tom Brennan Sent: July 28, 2009 1:24 PM To: Matt Fisher ; sc-l-bounces at securecoding.org ; Prasad Shenoy ; Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Fortify (www.fortify.com) has Partnered with WhiteHat Security (www.whitehatsec.com) too Tom Brennan Board Member - OWASP Foundation Url: www.owasp.org | Tel: 973-202-0122 http://www.linkedin.com/in/tombrennan -----Original Message----- From: Matt Fisher Date: Tue, 28 Jul 2009 11:29:30 To: Prasad Shenoy; Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -----Original Message----- From: Prasad Shenoy Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk Cc: Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks & Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: > Wow, big acquisition news in the static code analysis space announced today: > > http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= > > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > (This email is digitally signed with a free x.509 certificate from CAcert. > If you're unable to verify the signature, try getting their root CA > certificate at http://www.cacert.org -- for free.) > > > > > > > _______________________________________________ > 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 arian.evans at anachronic.com Tue Jul 28 13:40:30 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Tue, 28 Jul 2009 10:40:30 -0700 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> Message-ID: Right now, officially, I think that is about it. IBM, Veracode, and AoD (in Germany) claims they have this too. As Mattyson mentioned, Veracode only does static binary analysis (no source analysis). They offer "dynamic scanning" but I believe it is using NTO Spider IIRC which is a simplified scanner that targets unskilled users last I saw it. At one point I believe Veracode was in discussions with SPI to use WI, but since the Veracoders haunt this list I'll let them clarify what they use if they want. So IBM: soon. Veracode: sort-of. AoD: on paper And more to come in short order no doubt. I think we all knew this was coming sooner or later. Just a matter of "when". The big guys have a lot of bucks to throw at this problem if they want to, and pull off some really nice integrations. Be interesting to see what they do, and how useful the integrations really are to organizations. -- Arian Evans On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisher wrote: > Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. ?Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. > > -----Original Message----- > From: Prasad Shenoy > Sent: July 28, 2009 12:22 PM > To: Kenneth Van Wyk > Cc: Secure Coding > Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. > > > Wow indeed. Does that makes IBM the only vendor to offer both Static > and Dynamic software security testing/analysis capabilities? > > Thanks & Regards, > Prasad N. Shenoy > > On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: >> Wow, big acquisition news in the static code analysis space announced today: >> >> http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= >> >> >> Cheers, >> >> Ken >> >> ----- >> Kenneth R. van Wyk >> KRvW Associates, LLC >> http://www.KRvW.com >> >> (This email is digitally signed with a free x.509 certificate from CAcert. >> If you're unable to verify the signature, try getting their root CA >> certificate at http://www.cacert.org -- for free.) >> >> >> >> >> >> >> _______________________________________________ >> 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 jim at manico.net Tue Jul 28 14:39:09 2009 From: jim at manico.net (Jim Manico) Date: Tue, 28 Jul 2009 08:39:09 -1000 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> Message-ID: <549C10AF-4737-44A3-85CA-1A1AADA8F3A2@manico.net> A quick note, in the Java world (obfuscation aside), the source and "binary" is really the same thing. The fact that Fortify analizes source and Veracode analizes class files is a fairly minor detail. Jim Manico On Jul 28, 2009, at 7:40 AM, "Arian J. Evans" wrote: > Right now, officially, I think that is about it. IBM, Veracode, and > AoD (in Germany) claims they have this too. > > As Mattyson mentioned, Veracode only does static binary analysis (no > source analysis). They offer "dynamic scanning" but I believe it is > using NTO Spider IIRC which is a simplified scanner that targets > unskilled users last I saw it. > > At one point I believe Veracode was in discussions with SPI to use WI, > but since the Veracoders haunt this list I'll let them clarify what > they use if they want. > > So IBM: soon. > > Veracode: sort-of. > > AoD: on paper > > And more to come in short order no doubt. I think we all knew this was > coming sooner or later. Just a matter of "when". > > The big guys have a lot of bucks to throw at this problem if they want > to, and pull off some really nice integrations. Be interesting to see > what they do, and how useful the integrations really are to > organizations. > > -- > Arian Evans > > > > > > On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisher security.com> wrote: >> Pretty much. Hp /spi has integrations as well but I don't recall >> devinspect ever being a big hit. Veracode does both as well as >> static binary but as asaas model. Watchfire had a RAD integration >> as well iirc but it clearly must not haved had the share ounce does. >> >> -----Original Message----- >> From: Prasad Shenoy >> Sent: July 28, 2009 12:22 PM >> To: Kenneth Van Wyk >> Cc: Secure Coding >> Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. >> >> >> Wow indeed. Does that makes IBM the only vendor to offer both Static >> and Dynamic software security testing/analysis capabilities? >> >> Thanks & Regards, >> Prasad N. Shenoy >> >> On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk >> wrote: >>> Wow, big acquisition news in the static code analysis space >>> announced today: >>> >>> http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= >>> >>> >>> Cheers, >>> >>> Ken >>> >>> ----- >>> Kenneth R. van Wyk >>> KRvW Associates, LLC >>> http://www.KRvW.com >>> >>> (This email is digitally signed with a free x.509 certificate from >>> CAcert. >>> If you're unable to verify the signature, try getting their root CA >>> certificate at http://www.cacert.org -- for free.) >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Jul 28 16:36:33 2009 From: ljknews at mac.com (ljknews) Date: Tue, 28 Jul 2009 16:36:33 -0400 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <549C10AF-4737-44A3-85CA-1A1AADA8F3A2@manico.net> References: <549C10AF-4737-44A3-85CA-1A1AADA8F3A2@manico.net> Message-ID: At 8:39 AM -1000 7/28/09, Jim Manico wrote: > A quick note, in the Java world (obfuscation aside), the source and > "binary" is really the same thing. The fact that Fortify analizes > source and Veracode analizes class files is a fairly minor detail. It seems to me that would only be true for those using a Java bytecode engine, not those using a Java compiler that creates machine code. -- Larry Kilgallen From andrews at rbacomm.com Tue Jul 28 17:03:06 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Tue, 28 Jul 2009 16:03:06 -0500 Subject: [SC-L] Integrated Dynamic and Static Scanning In-Reply-To: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> Message-ID: <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> Partnering is not the same thing as having a single owner for both tools. I also believe WhiteHat is "hire them and they do it" model, though they do put hardware in your enterprise. IIRC, you could not do all the work yourself if you had whatever components they provided. I don't think AppScan and the Ounce programs will be integrated to this extent soon, but it would be much easier, since they are both in the same company. That level of integration is highly unlikely without the "common owner" this deal provides. The end result may or may not be better, especially if they take the IBM trend of charging more rather that the simpler model Ounce was taking recently. (Though was that sustainable?) I would be interested in hearing how the Fortify/WhiteHat integration worked. -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI > Fortify (www.fortify.com) has Partnered with WhiteHat Security > (www.whitehatsec.com) too From jsteven at cigital.com Wed Jul 29 08:44:25 2009 From: jsteven at cigital.com (John Steven) Date: Wed, 29 Jul 2009 08:44:25 -0400 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: Message-ID: All, The question of "Is my answer going to be high-enough resolution to support manual review?" or "...to support a developer fixing the problem?" comes down to "it depends". And, as we all know, I simply can't resist an "it depends" kind of subtlety. Yes, Jim, if you're doing a pure JavaSE application, and you don't care about non-standards compilers (jikes, gcj, etc.), then the source and the binary are largely equivalent (at least in terms of resolution).... Larry mentioned gcj. Ease of parsing, however, is a different story (for instance, actual dependencies are way easier to pull out of a binary than the source code, whereas stack-local variable names are easiest in source). Where you care about "a whole web application" rather than a pure-Java module, you have to concern yourself with JSP and all the other MVC technologies. Placing aside the topic of XML-based configuration files, you'll want to know what (container) your JSPs were compiled to target. In this case, source code is different than binary. Similar factors sneak themselves in across the Java platform. Then you've got the world of Aspect Oriented programming. Spring and a broader class of packages that use AspectJ to weave code into your application will dramatically change the face of your binary. To get the same resolution out of your source code, you must in essence 'apply' those point cuts yourself... Getting binary-quality resolution from source code therefore means predicting what transforms will occur at what point-cut locations. I doubt highly any source-based approach will get this thoroughly correct. Finally, from the perspective of dynamic analysis, one must consider the post-compiler transforms that occur. Java involves both JIT and Hotspot (using two hotspot compilers: client and server, each of which conducting different transforms), which neither binary nor source-code-based static analysis are likely to correctly predict or account for. The binary image that runs is simply not that which is fed to classloader.defineClass[] as a bytestream. ...and (actually) finally, one of my favorite code-review techniques is to ask for both a .war/ear/jar file AND the source code. This almost invariable get's a double-take, but it's worth the trouble. How many times do you think a web.xml match between the two? What exposure might you report if they were identical? ... What might you test for If they're dramatically different? Ah... Good times, ---- 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. On 7/28/09 4:36 PM, "ljknews" wrote: At 8:39 AM -1000 7/28/09, Jim Manico wrote: > A quick note, in the Java world (obfuscation aside), the source and > "binary" is really the same thing. The fact that Fortify analizes > source and Veracode analizes class files is a fairly minor detail. It seems to me that would only be true for those using a Java bytecode engine, not those using a Java compiler that creates machine code. From James.McGovern at thehartford.com Wed Jul 29 09:05:43 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Wed, 29 Jul 2009 09:05:43 -0400 Subject: [SC-L] Integrated Dynamic and Static Scanning In-Reply-To: <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> Message-ID: Sometimes integration is a good and bad thing. I hope that my Ounce enhancement request for integration with HP Quality Center and Archer GRC doesn't get deprioritized over rebranding efforts. Likewise, this also has the potential of causing many more IBM employees than current to pay attention to the needs of secure code. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews Sent: Tuesday, July 28, 2009 5:03 PM To: sc-l at securecoding.org Subject: [SC-L] Integrated Dynamic and Static Scanning Partnering is not the same thing as having a single owner for both tools. I also believe WhiteHat is "hire them and they do it" model, though they do put hardware in your enterprise. IIRC, you could not do all the work yourself if you had whatever components they provided. I don't think AppScan and the Ounce programs will be integrated to this extent soon, but it would be much easier, since they are both in the same company. That level of integration is highly unlikely without the "common owner" this deal provides. The end result may or may not be better, especially if they take the IBM trend of charging more rather that the simpler model Ounce was taking recently. (Though was that sustainable?) I would be interested in hearing how the Fortify/WhiteHat integration worked. -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI > Fortify (www.fortify.com) has Partnered with WhiteHat Security > (www.whitehatsec.com) too _______________________________________________ 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. _______________________________________________ ************************************************************ 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 andrews at rbacomm.com Wed Jul 29 16:17:38 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 29 Jul 2009 15:17:38 -0500 Subject: [SC-L] Source or Binary In-Reply-To: References: Message-ID: <20090729151738.f9yyf1etqroo4o8g@webmail.rbacomm.com> This is something where I have to watch my own mind. Figuring out a binary in C++ is very difficult. The Java is not really a binary, at least not in the "runs by itself" meaning. (Everything is (a) binary in reality, including the file holding this email.) Realizing that java "binaries" hold a lot more is a mental shift that probably must be actively kept in mind. Those with only Java experience may think it is obvious, but how many developers did not start with Java and have not purged this concept from their mind. This is a topic worth consideration when we are educating developers on secure development. At least it seems to to me! -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI From gem at cigital.com Wed Jul 29 16:37:53 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 29 Jul 2009 16:37:53 -0400 Subject: [SC-L] Software protection Message-ID: hi sc-l, Christian Collberg (an important pioneer in software protection) just published a great book called "Surreptitious Software". It's just plain good. http://www.amazon.com/Surreptitious-Software-Watermarking-Tamperproofing-Addison-Wesley/dp/0321549252 I blogged about the book on Justice League today: http://www.cigital.com/justiceleague/2009/07/29/is-software-protection-software-security/ Who agrees that software protection is part of software security? Who disagrees? gem http://www.cigital.com/~gem From ken at krvw.com Wed Jul 29 17:22:45 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 29 Jul 2009 17:22:45 -0400 Subject: [SC-L] Source or Binary In-Reply-To: <20090729151738.f9yyf1etqroo4o8g@webmail.rbacomm.com> References: <20090729151738.f9yyf1etqroo4o8g@webmail.rbacomm.com> Message-ID: <0B4FB5A7-98EC-4886-BC83-E875507266A4@krvw.com> On Jul 29, 2009, at 4:17 PM, Brad Andrews wrote: > Realizing that java "binaries" hold a lot more is a mental shift > that probably must be actively kept in mind. Those with only Java > experience may think it is obvious, but how many developers did not > start with Java and have not purged this concept from their mind. Fair enough, but understand too that a Java class file (like those in a typical jar file, which is just a fancy word for ZIP format) can be trivially decompiled into quite legible Java source. Numerous open source Java decompilers (e.g., Jode, Jad) exist that make this extremely easy. And FWIW, that's exactly how the Etisalat Blackberry software "update" was analyzed and proven to contain spyware last week. Note that, there are many options to distributing these trivially decompiled class files... Cheers, Ken van Wyk -------------- 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/20090729/55c99b15/attachment.bin From andrews at rbacomm.com Wed Jul 29 18:37:26 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 29 Jul 2009 17:37:26 -0500 Subject: [SC-L] Integrated Dynamic and Static Scanning In-Reply-To: <2fd9390e0907291355r16c0e5eaye46dad61260b1e46@mail.gmail.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> <2fd9390e0907291355r16c0e5eaye46dad61260b1e46@mail.gmail.com> Message-ID: <20090729173726.v83kqwde1wwgkow4@webmail.rbacomm.com> While I completely agree with this statement, it is a much tougher sell to management that is seeking to keep the company making money (or perhaps even alive). I believe that having (and using) an imperfect tool is better than nothing, so I would at least push for that. Getting things that play well together is even better. I think a complete overhaul and digging security flaws out is even better, but is a much harder sell in many places in my experience. Perhaps I am too jaded, but you have to work with what you can get approved and paid for. The cost of the "indispensable" experience is much higher than most companies will stomach. :) Some companies do value it, but most haven't "seen the light" yet in my experience. While that is limited compared to many on this list, I think my perspective is something that is easy to lose track of when you are fixing security issues every day. Everyone doesn't share the vision, unfortunately. And some of those that see the problem don't have the budget and executive support to fix the problem.... -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Andre Gironda : > On 7/28/09, Brad Andrews wrote: > > Experts can't be replaced by tools. From andrews at rbacomm.com Wed Jul 29 18:39:25 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Wed, 29 Jul 2009 17:39:25 -0500 Subject: [SC-L] Integrated Dynamic and Static Scanning In-Reply-To: References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> Message-ID: <20090729173925.aw6j41vmokck4ww8@webmail.rbacomm.com> That is certainly true. I was just commenting on the issue of systems that work together tightly. None do now (as far as I know), but this should potentially allow that to happen. I did here a few moans when this news came out, since IBM is not known for inexpensiveness from what I hear.... :) -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "McGovern, James F (HTSC, IT)" : > Sometimes integration is a good and bad thing. From matt at piscis-security.com Wed Jul 29 20:45:37 2009 From: matt at piscis-security.com (Matt Fisher) Date: Wed, 29 Jul 2009 19:45:37 -0500 Subject: [SC-L] Integrated Dynamic and Static Scanning In-Reply-To: <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A4@34093-MBX-C05.mex07a.mlsrvr.com> <20090728160306.6bbmpo624n40ok8c@webmail.rbacomm.com> Message-ID: <2A9EB7CB4A6ABC4391D7D77E93A7A113228D2B289C@34093-MBX-C05.mex07a.mlsrvr.com> Re. Whitehat: yes they have boxes, no they aren't required, yes they have people. I'm sure they'll expand when they return from Vegas. Re. Ounce: there's seriously no way to tell which way it will go. Some companies do really well at acquiring smaller companies and making them flourish, while other companies quite simply don't (or worse). I've seen web/sca "integrations" in the past (and present) and they're usually very cosmetic, like report munging or one tool calling the other to kick it off automatically. Knowing your SaaS has additional capabilities is good (although whether they're "integrated" capabilities or not seems irrelevant). It seems completely unimportant from an SDL or pen-test/expert group perspective. Frankly I would hope that the PM priority would be integration into the dev environments first and foremost: into RAD (if not so already), Req Pro, and the various other support systems dev teams use. >> simpler model Ounce was taking recently. (Though was that sustainable?) It clearly didn't have to be sustainable and certainly one can suspect it was never intended to be either. One thing for ISV's is sure however: the cost of buying your way into the dev space just went up. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews Sent: Tuesday, July 28, 2009 5:03 PM To: sc-l at securecoding.org Subject: [SC-L] Integrated Dynamic and Static Scanning Partnering is not the same thing as having a single owner for both tools. I also believe WhiteHat is "hire them and they do it" model, though they do put hardware in your enterprise. IIRC, you could not do all the work yourself if you had whatever components they provided. I don't think AppScan and the Ounce programs will be integrated to this extent soon, but it would be much easier, since they are both in the same company. That level of integration is highly unlikely without the "common owner" this deal provides. The end result may or may not be better, especially if they take the IBM trend of charging more rather that the simpler model Ounce was taking recently. (Though was that sustainable?) I would be interested in hearing how the Fortify/WhiteHat integration worked. -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI > Fortify (www.fortify.com) has Partnered with WhiteHat Security > (www.whitehatsec.com) too _______________________________________________ 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 michaelslists at gmail.com Wed Jul 29 20:08:35 2009 From: michaelslists at gmail.com (silky) Date: Thu, 30 Jul 2009 10:08:35 +1000 Subject: [SC-L] Source or Binary In-Reply-To: <20090729151738.f9yyf1etqroo4o8g@webmail.rbacomm.com> References: <20090729151738.f9yyf1etqroo4o8g@webmail.rbacomm.com> Message-ID: <5e01c29a0907291708r6220f6c6r6c44871829b9b662@mail.gmail.com> On 7/30/09, Brad Andrews wrote: > > This is something where I have to watch my own mind. Figuring out a > binary in C++ is very difficult. The Java is not really a binary, at > least not in the "runs by itself" meaning. (Everything is (a) binary > in reality, including the file holding this email.) Of course it's a binary, it "runs by itself", when there is a java vm to run it. Just like you need a win32 vm to run a typical .exe. > Realizing that java "binaries" hold a lot more is a mental shift that > probably must be actively kept in mind. Hold a lot more what? This doesn't make sense. -- noon silky http://lets.coozi.com.au/ From Paco at cigital.com Thu Jul 30 10:08:37 2009 From: Paco at cigital.com (Paco Hope) Date: Thu, 30 Jul 2009 10:08:37 -0400 Subject: [SC-L] Source or Binary In-Reply-To: <5e01c29a0907291708r6220f6c6r6c44871829b9b662@mail.gmail.com> Message-ID: On 7/29/09 8:08 PM, "silky" wrote: > Of course it's a binary, it "runs by itself", when there is a java vm > to run it. Just like you need a win32 vm to run a typical .exe. You misunderstand the notion of virtual machines if you think of Win32 as a virtual machine. There is nothing "virtual" about windows. It runs on the real hardware (ignoring things like VMWare). Your Windows EXEs (except those running in the .NET CLR) also run on the real x86 hardware. I.e., your variables are loaded into CPU registers and operated on, etc. The Java Virtual Machine is a theoretical machine, and Java code is compiled down to Java bytecode that runs on this theoretical machine. The Java VM is the actual Windows EXE that runs on the real hardware. It reads these bytecodes and executes them. There is a very significant level of abstraction between a Java program running in a Java virtual machine and native code that has been compiled to a native object format (e.g., an .exe). >> Realizing that java "binaries" hold a lot more is a mental shift that >> probably must be actively kept in mind. > > Hold a lot more what? This doesn't make sense. It makes a lot of sense. Because Java is a string-based language, a great deal of symbolic information (e.g., class names, method names, inheritance hierarchies) remains in the class file, literally in string format, after you compile. If you're in the C++ world and you compile and then strip your binaries, that symbolic information is reduced a lot. If you use a java decompiler (e.g., jad, jode, etc.), you can get .java files from .class files and they are remarkably usable. While C++ decompilation is possible, the fidelity of decompiled Java programs is significantly higher. I.e., they match their original source, sometimes in astonishing accuracy. Take a look at java decompilation and compare it to what you know about native code decompilation. It is absolutely true that (ignoring anti-reversing techniques like obfuscation), Java binaries carry a lot more usable information to help in the dissection and understanding of their execution than an equivalent native-code program would. Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ ? +1.703.585.7868 Software Confidence. Achieved. From Kevin.Wall at qwest.com Thu Jul 30 12:12:07 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Thu, 30 Jul 2009 11:12:07 -0500 Subject: [SC-L] Source or Binary In-Reply-To: References: <5e01c29a0907291708r6220f6c6r6c44871829b9b662@mail.gmail.com> Message-ID: In a message dated July 30, 2009 10:09 AM EDT, Paco Hope wrote... > The Java Virtual Machine is a theoretical machine, and Java > code is compiled > down to Java bytecode that runs on this theoretical machine. > The Java VM is > the actual Windows EXE that runs on the real hardware. It reads these > bytecodes and executes them. There is a very significant level of > abstraction between a Java program running in a Java virtual > machine and > native code that has been compiled to a native object format (e.g., an > .exe). There's theory, and then there's practice. This is almost 100% accurate from a practical matter with the exception of HotSpot or other JIT compiler technologies that compile certain byte code into machine code and then execute that instead of the original byte code. I'm sure that Paco is aware of that, but just not sure all the other readers are. -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 From ken at krvw.com Thu Jul 30 14:37:38 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 30 Jul 2009 14:37:38 -0400 Subject: [SC-L] CERIAS : Beware SQL injections due to missing prepared statement support Message-ID: <6AE10842-F42A-4B2F-8F93-4061C42EE25D@krvw.com> Here's one for the daily UGH! Great points raised by Pascal Meunier (see below) about poorly implemented language support for Prepared Statement SQL calls. In particular, Python's pyPGSQL actually takes its prepared statement and translates internally to an old-style concatenated string query, thereby opening itself up to various SQL injection vulnerabilities. http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When :16:32:23Z Interesting article, Pascal. Thanks! Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- 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/20090730/dd2eb7cb/attachment.bin From pmeunier at cerias.purdue.edu Thu Jul 30 15:10:04 2009 From: pmeunier at cerias.purdue.edu (Pascal Meunier) Date: Thu, 30 Jul 2009 15:10:04 -0400 Subject: [SC-L] CERIAS : Beware SQL injections due to missing prepared statement support In-Reply-To: <6AE10842-F42A-4B2F-8F93-4061C42EE25D@krvw.com> References: <6AE10842-F42A-4B2F-8F93-4061C42EE25D@krvw.com> Message-ID: <4A71F00C.60206@cerias.purdue.edu> Actually it's not vulnerable because the strings are escaped first. My point is simply that using prepared statements would have been more robust than escaping strings on the client side. I'm sorry I didn't make that clear, I'll go edit my post now. Thanks! Pascal Kenneth Van Wyk wrote: > Here's one for the daily UGH! > > Great points raised by Pascal Meunier (see below) about poorly > implemented language support for Prepared Statement SQL calls. In > particular, Python's pyPGSQL actually takes its prepared statement and > translates internally to an old-style concatenated string query, thereby > opening itself up to various SQL injection vulnerabilities. > > http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When:16:32:23Z > > > Interesting article, Pascal. Thanks! > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > (This email is digitally signed with a free x.509 certificate from > CAcert. If you're unable to verify the signature, try getting their root > CA certificate at http://www.cacert.org -- for free.) > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jul 30 17:20:52 2009 From: jsteven at cigital.com (John Steven) Date: Thu, 30 Jul 2009 17:20:52 -0400 Subject: [SC-L] Static Vs. Binary In-Reply-To: Message-ID: Something occurred to me last night as I pondered where this discussion?s tendrils are taking us. An point I only made implicitly is this: The question wrote: > All, > > The question of ?Is my answer going to be high-enough resolution to support > manual review?? or ?...to support a developer fixing the problem?? comes down > to ?it depends?. And, as we all know, I simply can?t resist an ?it depends? > kind of subtlety. > > Yes, Jim, if you?re doing a pure JavaSE application, and you don?t care about > non-standards compilers (jikes, gcj, etc.), then the source and the binary are > largely equivalent (at least in terms of resolution).... Larry mentioned gcj. > Ease of parsing, however, is a different story (for instance, actual > dependencies are way easier to pull out of a binary than the source code, > whereas stack-local variable names are easiest in source). > > Where you care about ?a whole web application? rather than a pure-Java module, > you have to concern yourself with JSP and all the other MVC technologies. > Placing aside the topic of XML-based configuration files, you?ll want to know > what (container) your JSPs were compiled to target. In this case, source code > is different than binary. Similar factors sneak themselves in across the Java > platform. > > Then you?ve got the world of Aspect Oriented programming. Spring and a broader > class of packages that use AspectJ to weave code into your application will > dramatically change the face of your binary. To get the same resolution out of > your source code, you must in essence Oapply? those point cuts yourself... > Getting binary-quality resolution from source code therefore means predicting > what transforms will occur at what point-cut locations. I doubt highly any > source-based approach will get this thoroughly correct. > > Finally, from the perspective of dynamic analysis, one must consider the > post-compiler transforms that occur. Java involves both JIT and Hotspot (using > two hotspot compilers: client and server, each of which conducting different > transforms), which neither binary nor source-code-based static analysis are > likely to correctly predict or account for. The binary image that runs is > simply not that which is fed to classloader.defineClass[] as a bytestream. > > ...and (actually) finally, one of my favorite code-review techniques is to > ask for both a .war/ear/jar file AND the source code. This almost invariable > get?s a double-take, but it?s worth the trouble. How many times do you think a > web.xml match between the two? What exposure might you report if they were > identical? ... What might you test for If they?re dramatically different? > > Ah... Good times, > ---- > 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. > > > On 7/28/09 4:36 PM, "ljknews" wrote: > >> At 8:39 AM -1000 7/28/09, Jim Manico wrote: >> >>> A quick note, in the Java world (obfuscation aside), the source and >>> "binary" is really the same thing. The fact that Fortify analizes >>> source and Veracode analizes class files is a fairly minor detail. >> >> It seems to me that would only be true for those using a >> Java bytecode engine, not those using a Java compiler that >> creates machine code. From chandra at list.org Thu Jul 30 22:57:06 2009 From: chandra at list.org (Pravir Chandra) Date: Fri, 31 Jul 2009 02:57:06 +0000 Subject: [SC-L] Static Vs. Binary In-Reply-To: References: Message-ID: <335433406-1249009022-cardhu_decombobulator_blackberry.rim.net-1085458919-@bxe1051.bisx.prod.on.blackberry> First, I generally agree that there are many factors that make the true and factual fidelity of static analysis really REALLY difficult. However, I submit that by debating this point, you're belaboring the correct angle of survivable Neptunian atmospheric entry with people that don't generally value the benefit of flying humans past the moon. The point being, if you're debating the minutiae of static analysis vis-a-vis compile time optimizations, you're convincing people to let good be the enemy of perfect. There are few (if any) perfect technologies, but we use them because they're needed and provide a ton of great value. Anyone who doubts this should glance at the device you're reading this on and imagine yourself refusing to use it because it doesn't have perfect security (or reliability, or usability, etc.). p. ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: John Steven Date: Thu, 30 Jul 2009 17:20:52 To: Secure Coding Subject: [SC-L] Static Vs. Binary Something occurred to me last night as I pondered where this discussion?s tendrils are taking us. An point I only made implicitly is this: The question wrote: > All, > > The question of ?Is my answer going to be high-enough resolution to support > manual review?? or ?...to support a developer fixing the problem?? comes down > to ?it depends?. And, as we all know, I simply can?t resist an ?it depends? > kind of subtlety. > > Yes, Jim, if you?re doing a pure JavaSE application, and you don?t care about > non-standards compilers (jikes, gcj, etc.), then the source and the binary are > largely equivalent (at least in terms of resolution).... Larry mentioned gcj. > Ease of parsing, however, is a different story (for instance, actual > dependencies are way easier to pull out of a binary than the source code, > whereas stack-local variable names are easiest in source). > > Where you care about ?a whole web application? rather than a pure-Java module, > you have to concern yourself with JSP and all the other MVC technologies. > Placing aside the topic of XML-based configuration files, you?ll want to know > what (container) your JSPs were compiled to target. In this case, source code > is different than binary. Similar factors sneak themselves in across the Java > platform. > > Then you?ve got the world of Aspect Oriented programming. Spring and a broader > class of packages that use AspectJ to weave code into your application will > dramatically change the face of your binary. To get the same resolution out of > your source code, you must in essence Oapply? those point cuts yourself... > Getting binary-quality resolution from source code therefore means predicting > what transforms will occur at what point-cut locations. I doubt highly any > source-based approach will get this thoroughly correct. > > Finally, from the perspective of dynamic analysis, one must consider the > post-compiler transforms that occur. Java involves both JIT and Hotspot (using > two hotspot compilers: client and server, each of which conducting different > transforms), which neither binary nor source-code-based static analysis are > likely to correctly predict or account for. The binary image that runs is > simply not that which is fed to classloader.defineClass[] as a bytestream. > > ...and (actually) finally, one of my favorite code-review techniques is to > ask for both a .war/ear/jar file AND the source code. This almost invariable > get?s a double-take, but it?s worth the trouble. How many times do you think a > web.xml match between the two? What exposure might you report if they were > identical? ... What might you test for If they?re dramatically different? > > Ah... Good times, > ---- > 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. > > > On 7/28/09 4:36 PM, "ljknews" wrote: > >> At 8:39 AM -1000 7/28/09, Jim Manico wrote: >> >>> A quick note, in the Java world (obfuscation aside), the source and >>> "binary" is really the same thing. The fact that Fortify analizes >>> source and Veracode analizes class files is a fairly minor detail. >> >> It seems to me that would only be true for those using a >> Java bytecode engine, not those using a Java compiler that >> creates machine code. _______________________________________________ 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 Jul 30 23:25:58 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 30 Jul 2009 23:25:58 -0400 Subject: [SC-L] Static Vs. Binary In-Reply-To: <335433406-1249009022-cardhu_decombobulator_blackberry.rim.net-1085458919-@bxe1051.bisx.prod.on.blackberry> References: <335433406-1249009022-cardhu_decombobulator_blackberry.rim.net-1085458919-@bxe1051.bisx.prod.on.blackberry> Message-ID: On Jul 30, 2009, at 10:57 PM, Pravir Chandra wrote: > First, I generally agree that there are many factors that make the > true and factual fidelity of static analysis really REALLY difficult. All good points, to be sure. I'm a pragmatist, perhaps at times to a fault. Let's not overlook in this debate the perspective of the practitioner. Often, analysis of "binaries" (and I'm including here bytecode of various types), is done because the practitioner lacks access to the src (e.g., third party libraries and such). I expect that anyone analyzing a system would at least _want_ to analyze the src code if it is available. That is, among the various things one would want to look at, including dynamic analysis of binaries. I'm sure this is all glaringly obvious, but what the heck. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- 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/20090730/adf3c5eb/attachment-0001.bin From tomb at owasp.org Sun Aug 2 15:07:00 2009 From: tomb at owasp.org (Tom Brennan) Date: Sun, 2 Aug 2009 19:07:00 +0000 Subject: [SC-L] TTBSP/Defcon Message-ID: <1028298321-1249240020-cardhu_decombobulator_blackberry.rim.net-781737256-@bxe1121.bisx.prod.on.blackberry> APPSEC community leaders, this new effort for the next generation is synergistic with our efforts and wanted to raise its awareness to you too http://www.securethetextbook.com/ Textbooks that are WRONG here is how you might point that out. A list of supported text books is one of the goals. After talking with Jon Kibler and Mike Cooper (project leaders) this effort is in step with our OWASP Global Education Committee mission. Thoughts/Discussion Tom Brennan Board Member - OWASP Foundation Url: www.owasp.org | Tel: 973-202-0122 http://www.linkedin.com/in/tombrennan From jsteven at cigital.com Tue Aug 4 08:35:20 2009 From: jsteven at cigital.com (John Steven) Date: Tue, 4 Aug 2009 08:35:20 -0400 Subject: [SC-L] Static Vs. Binary In-Reply-To: <335433406-1249009022-cardhu_decombobulator_blackberry.rim.net-1085458919-@bxe1051.bisx.prod.on.blackberry> Message-ID: Pravir, HA! :D (Knowing me, you can predict what I?m about to say) YES, explaining what the tools will need to do correctly as they continue their next-generation isn?t useful to a practitioner on this list today. ... But, it is very important to understand-as a practitioner-what your tools aren?t taking into account accurately; many organizations do little else than triage and report on tool results. For instance, when a particular tools says it supports a technology (Such as Spring, or SpringMVC) what does that mean? Weekly, our consultants augment a list of things the [commercial tool they?re using that day] doesn?t do because it doesn?t ?see? a config file, a property, some aspect that would have been present in the binary, (even the source code) etc... I?ll accept that my advice being targeted at the tool vendors themselves isn?t very useful by consumers of this list (it is for your new company though eh?), but I think it is important as a security practitioner, if you?re building an assurance program within your org., to understand what the tools/techniques you?re finding (or disproving) the existence of within your applications? code bases. This will include what their notion of ?binary? is increasingly, as list participants begin to consume vendor SAAS static analysis of binary services. ---- 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. On 7/30/09 10:57 PM, "Pravir Chandra" wrote: First, I generally agree that there are many factors that make the true and factual fidelity of static analysis really REALLY difficult. However, I submit that by debating this point, you're belaboring the correct angle of survivable Neptunian atmospheric entry with people that don't generally value the benefit of flying humans past the moon. The point being, if you're debating the minutiae of static analysis vis-a-vis compile time optimizations, you're convincing people to let good be the enemy of perfect. There are few (if any) perfect technologies, but we use them because they're needed and provide a ton of great value. Anyone who doubts this should glance at the device you're reading this on and imagine yourself refusing to use it because it doesn't have perfect security (or reliability, or usability, etc.). -----Original Message----- From: John Steven Something occurred to me last night as I pondered where this discussion?s tendrils are taking us. An point I only made implicitly is this: The question wrote: > All, > > The question of ?Is my answer going to be high-enough resolution to support > manual review?? or ?...to support a developer fixing the problem?? comes down > to ?it depends?. And, as we all know, I simply can?t resist an ?it depends? > kind of subtlety. > > Yes, Jim, if you?re doing a pure JavaSE application, and you don?t care about > non-standards compilers (jikes, gcj, etc.), then the source and the binary are > largely equivalent (at least in terms of resolution).... Larry mentioned gcj. > Ease of parsing, however, is a different story (for instance, actual > dependencies are way easier to pull out of a binary than the source code, > whereas stack-local variable names are easiest in source). > > Where you care about ?a whole web application? rather than a pure-Java module, > you have to concern yourself with JSP and all the other MVC technologies. > Placing aside the topic of XML-based configuration files, you?ll want to know > what (container) your JSPs were compiled to target. In this case, source code > is different than binary. Similar factors sneak themselves in across the Java > platform. > > Then you?ve got the world of Aspect Oriented programming. Spring and a broader > class of packages that use AspectJ to weave code into your application will > dramatically change the face of your binary. To get the same resolution out of > your source code, you must in essence Oapply? those point cuts yourself... > Getting binary-quality resolution from source code therefore means predicting > what transforms will occur at what point-cut locations. I doubt highly any > source-based approach will get this thoroughly correct. > > Finally, from the perspective of dynamic analysis, one must consider the > post-compiler transforms that occur. Java involves both JIT and Hotspot (using > two hotspot compilers: client and server, each of which conducting different > transforms), which neither binary nor source-code-based static analysis are > likely to correctly predict or account for. The binary image that runs is > simply not that which is fed to classloader.defineClass[] as a bytestream. > > ...and (actually) finally, one of my favorite code-review techniques is to > ask for both a .war/ear/jar file AND the source code. This almost invariable > get?s a double-take, but it?s worth the trouble. How many times do you think a > web.xml match between the two? What exposure might you report if they were > identical? ... What might you test for If they?re dramatically different? > > On 7/28/09 4:36 PM, "ljknews" wrote: > >> At 8:39 AM -1000 7/28/09, Jim Manico wrote: >> >>> A quick note, in the Java world (obfuscation aside), the source and >>> "binary" is really the same thing. The fact that Fortify analizes >>> source and Veracode analizes class files is a fairly minor detail. >> >> It seems to me that would only be true for those using a >> Java bytecode engine, not those using a Java compiler that >> creates machine code. From cwysopal at Veracode.com Tue Aug 4 20:54:10 2009 From: cwysopal at Veracode.com (Chris Wysopal) Date: Tue, 4 Aug 2009 20:54:10 -0400 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> Message-ID: <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> I wouldn't say that NTO Spider is a "sort of" dynamic web scanner. It is a top tier scanner that can battle head to head on false negative rate with the big conglomerates' scanners: IBM AppScan and HP WebInspect. Larry Suto published an analysis a year ago, that certainly had some flaws (and was rightly criticized), but genuinely showed all three to be in the same league. I haven't seen a better head-to-head analysis conducted by anyone. A little bird whispered to me that we may see a new analysis by someone soon. As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. I am glad NIST SATE '09 will soon be underway and, at least for static analysis tools, we will have unbiased independent testing. I am hoping for a big improvement over last year. I especially like the category they are using for some flaws found as "valid but insignificant". Clearly they are improving based on feedback from SATE '08. Veracode was the first company to offer static and dynamic (web) analysis, and we have been for 2 years (announced Aug 8, 2007). We deliver it as a service. If you have a .NET or Java web app, you would cannot find a comparable solution form a single vendor today. -Chris -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Arian J. Evans Sent: Tuesday, July 28, 2009 1:41 PM To: Matt Fisher Cc: Kenneth Van Wyk; Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Right now, officially, I think that is about it. IBM, Veracode, and AoD (in Germany) claims they have this too. As Mattyson mentioned, Veracode only does static binary analysis (no source analysis). They offer "dynamic scanning" but I believe it is using NTO Spider IIRC which is a simplified scanner that targets unskilled users last I saw it. At one point I believe Veracode was in discussions with SPI to use WI, but since the Veracoders haunt this list I'll let them clarify what they use if they want. So IBM: soon. Veracode: sort-of. AoD: on paper And more to come in short order no doubt. I think we all knew this was coming sooner or later. Just a matter of "when". The big guys have a lot of bucks to throw at this problem if they want to, and pull off some really nice integrations. Be interesting to see what they do, and how useful the integrations really are to organizations. -- Arian Evans On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisher wrote: > Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. ?Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. > > -----Original Message----- > From: Prasad Shenoy > Sent: July 28, 2009 12:22 PM > To: Kenneth Van Wyk > Cc: Secure Coding > Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. > > > Wow indeed. Does that makes IBM the only vendor to offer both Static > and Dynamic software security testing/analysis capabilities? > > Thanks & Regards, > Prasad N. Shenoy > > On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: >> Wow, big acquisition news in the static code analysis space announced today: >> >> http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= >> >> >> Cheers, >> >> Ken >> >> ----- >> Kenneth R. van Wyk >> KRvW Associates, LLC >> http://www.KRvW.com >> >> (This email is digitally signed with a free x.509 certificate from CAcert. >> If you're unable to verify the signature, try getting their root CA >> certificate at http://www.cacert.org -- for free.) >> >> >> >> >> >> >> _______________________________________________ >> 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 arian.evans at anachronic.com Tue Aug 4 22:01:21 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Tue, 4 Aug 2009 19:01:21 -0700 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> Message-ID: Chris -- Good point with Larry's paper. NTO Spider is, by design, a simplified scanner for unskilled users, and I do not think it was designed to be an effective tool for deep dynamic analysis of a web application. It is, however, probably the best scanner on the market for people who don't have the time or skill to configure dynamic testing tools for their applications! Larry Suto's paper reinforces this use-case desktop webapp scanners: "Each scanner was run in default mode and not tuned in any capacity to the application. The importance of this lies in how effective the default mode so that scalability of scanning is not limited by manual intervention and setup procedures which can be very time consuming. Second, in most cases it is simply unrealistic to spend much time with many applications." While I definitely look forward to more objective data on this subject, I do not think Suto's report is a good example of how consultants or SaaS providers deliver "expert security analysis" when they use dynamic testing automation IMO. (I know this is not how I ever did things.) I think anyone who has experience with deep dynamic testing knows they need automation tools with custom configuration ability, the ability to record workflow, a framework to create custom tests, etc. I do not believe NTO spider offers any of these essential features. I believe it was explicitly designed for unskilled users' use-cases. (A valid and important market to be sure.) Admittedly I could be very wrong here. The NTO guys are sharp folks and I haven't seen Spider in a while. > As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. Completely agreed. I prefer to back up my statements about dynamic tools with hard, quantifiable data. Deprived of that, I tend to rely on historical experience, if it is a subject I have enough experience on within that problem domain. If you recall I used to do extensive testing and benchmarking of dynamic testing tools across custom widgets I wrote, and production enterprise applications, and publish them @OWASP and NIST conferences, and "HE: Webapps 2nd Ed". Back then the quality of the tools was very volatile, and changed significantly every release, and from application to application you would test, so by the time you vetted all your data, it was almost obsolete. Again the importance of customizable, manually guided tools, when dealing with new and bespoke applications. I tried to tackle static analysis but became overwhelmed by the challenge of setting up effective labs, and the huge array of static analysis tools that were available. Given that I now work on a dynamic testing platform: it would be completely fair to accuse me of being "non-objective" when discussing various vendors dynamic testing tools -- and I would have to agree with you. It won't make my statements any less valid, but I have to throw that out there to be fair. Ultimately you hit the need for objective data spot-on. I would be lying if I didn't say that I would LOVE to see more head-on benchmarking between static analysis technology vendors like Veracode, Fortify, Ounce, Coverity, Klockwork, etc. etc. The problem I had in the past with benchmarks was the huge degree of customization in each application I would test. While patterns emerge that are almost always automatable to some degree, the technologies almost always require hand care-and-feeding to get them to an effective place. I think this notion of combining the tools with qualified users is the true potential power of the SaaS solutions that are coming to market. I look forward to seeing the release of more objective analysis by smarter minds than I, and am very impressed with how far things have come since the simple tests I tried to run over the years. $0.02. Cheers, -- Arian Evans On Tue, Aug 4, 2009 at 5:54 PM, Chris Wysopal wrote: > > I wouldn't say that NTO Spider is a "sort of" dynamic web scanner. It is a top tier scanner that can battle head to head on false negative rate with the big conglomerates' scanners: IBM AppScan and HP WebInspect. ?Larry Suto published an analysis a year ago, that certainly had some flaws (and was rightly criticized), but genuinely showed all three to be in the same league. I haven't seen a better head-to-head analysis conducted by anyone. A little bird whispered to me that we may see a new analysis by someone soon. > > As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. ?I am glad NIST SATE '09 will soon be underway and, at least for static analysis tools, we will have unbiased independent testing. I am hoping for a big improvement over last year. ?I especially like the category they are using for some flaws found as "valid but insignificant". Clearly they are improving based on feedback from SATE '08. > > Veracode was the first company to offer static and dynamic (web) analysis, and we have been for 2 years (announced Aug 8, 2007). ?We deliver it as a service. If you have a .NET or Java web app, you would cannot find a comparable solution form a single vendor today. > > -Chris > > -----Original Message----- > From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Arian J. Evans > Sent: Tuesday, July 28, 2009 1:41 PM > To: Matt Fisher > Cc: Kenneth Van Wyk; Secure Coding > Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. > > Right now, officially, I think that is about it. IBM, Veracode, and > AoD (in Germany) claims they have this too. > > As Mattyson mentioned, Veracode only does static binary analysis (no > source analysis). They offer "dynamic scanning" but I believe it is > using NTO Spider IIRC which is a simplified scanner that targets > unskilled users last I saw it. > > At one point I believe Veracode was in discussions with SPI to use WI, > but since the Veracoders haunt this list I'll let them clarify what > they use if they want. > > So IBM: soon. > > Veracode: sort-of. > > AoD: on paper > > And more to come in short order no doubt. I think we all knew this was > coming sooner or later. Just a matter of "when". > > The big guys have a lot of bucks to throw at this problem if they want > to, and pull off some really nice integrations. Be interesting to see > what they do, and how useful the integrations really are to > organizations. > > -- > Arian Evans > > > > > > On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisher wrote: >> Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. ?Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. >> >> -----Original Message----- >> From: Prasad Shenoy >> Sent: July 28, 2009 12:22 PM >> To: Kenneth Van Wyk >> Cc: Secure Coding >> Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. >> >> >> Wow indeed. Does that makes IBM the only vendor to offer both Static >> and Dynamic software security testing/analysis capabilities? >> >> Thanks & Regards, >> Prasad N. Shenoy >> >> On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: >>> Wow, big acquisition news in the static code analysis space announced today: >>> >>> http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= >>> >>> >>> Cheers, >>> >>> Ken >>> >>> ----- >>> Kenneth R. van Wyk >>> KRvW Associates, LLC >>> http://www.KRvW.com >>> >>> (This email is digitally signed with a free x.509 certificate from CAcert. >>> If you're unable to verify the signature, try getting their root CA >>> certificate at http://www.cacert.org -- for free.) >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 arian.evans at anachronic.com Tue Aug 4 22:08:11 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Tue, 4 Aug 2009 19:08:11 -0700 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: References: Message-ID: Great answer, John. I especially like your point about web.xml. This goes dually for black-box testing. There would be a lot of advantage to being able to get (and compare) these types of config files today for dialing in BBB (Better Black Box vs. blind black box) testing. I don't think anyone is doing this optimally now. I know I am eager to find static analysis that can provide/guide my BBB testing with more context. I definitely think we will see more of these combined-services evolve in the future. It only makes sense, especially given some of the context-sensitive framing considerations in your response. Thanks for the solid thoughts, -- Arian Evans On Wed, Jul 29, 2009 at 5:44 AM, John Steven wrote: > All, > > The question of "Is my answer going to be high-enough resolution to support manual review?" or "...to support a developer fixing the problem?" comes down to "it depends". ?And, as we all know, I simply can't resist an "it depends" kind of subtlety. > > Yes, Jim, if you're doing a pure JavaSE application, and you don't care about non-standards compilers (jikes, gcj, etc.), then the source and the binary are largely equivalent (at least in terms of resolution).... Larry mentioned gcj. ?Ease of parsing, however, is a different story (for instance, actual dependencies are way easier to pull out of a binary than the source code, whereas stack-local variable names are easiest in source). > > Where you care about "a whole web application" rather than a pure-Java module, you have to concern yourself with JSP and all the other MVC technologies. Placing aside the topic of XML-based configuration files, you'll want to know what (container) your JSPs were compiled to target. In this case, source code is different than binary. Similar factors sneak themselves in across the Java platform. > > Then you've got the world of Aspect Oriented programming. Spring and a broader class of packages that use AspectJ to weave code into your application will dramatically change the face of your binary. To get the same resolution out of your source code, you must in essence 'apply' those point cuts yourself... Getting binary-quality resolution from source code ?therefore means predicting what transforms will occur at what point-cut locations. I doubt highly any source-based approach will get this thoroughly correct. > > Finally, from the perspective of dynamic analysis, one must consider the post-compiler transforms that occur. Java involves both JIT and Hotspot (using two hotspot compilers: client and server, each of which conducting different transforms), which neither binary nor source-code-based static analysis are likely to correctly predict or account for. The binary image that runs is simply not that which is fed to classloader.defineClass[] as a bytestream. > > ...and ?(actually) finally, one of my favorite code-review techniques is to ask for both a .war/ear/jar file AND the source code. This almost invariable get's a double-take, but it's worth the trouble. How many times do you think a web.xml match between the two? What exposure might you report if they were ?identical? ... What might you test for If they're dramatically different? > > Ah... Good times, > ---- > 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. > > > On 7/28/09 4:36 PM, "ljknews" wrote: > > At 8:39 AM -1000 7/28/09, Jim Manico wrote: > >> A quick note, in the Java world (obfuscation aside), the source and >> "binary" is really the same thing. The fact that Fortify analizes >> source and Veracode analizes class files is a fairly minor detail. > > It seems to me that would only be true for those using a > Java bytecode engine, not those using a Java compiler that > creates machine code. > > _______________________________________________ > 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 Kevin.Wall at qwest.com Tue Aug 4 23:35:29 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Tue, 4 Aug 2009 22:35:29 -0500 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a .mlsrvr.com><7 9348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local>, Message-ID: Arian J. Evans wrote... > The problem I had in the past with benchmarks was the huge degree of > customization in each application I would test. While patterns emerge > that are almost always automatable to some degree, the technologies > almost always require hand care-and-feeding to get them to an > effective place. I think this notion of combining the tools with > qualified users is the true potential power of the SaaS solutions that > are coming to market. It's a pity that the these dynamic-scanning vendors can't work together to come up with a common approach to at least helping this automation you speak of at least part way along. (Yes, I know. I'm dreaming. ;-) Some ideas that I've had in the past is that they could request and make use of: 1) HTTP access logs from Apache and/or the web / application server. These might be especially useful when the logs are specially configured to also collect POST parameters and then the application's regression tests are run against the application to collect the log data. Most web / app servers support Apache HTTPD style access log format, so parsing shouldn't be too terribly difficult in terms of the # of variations they need to handle. 2) For Java, the web.xml could be used to gather data that might allow some automation, especially wrt discovery of dynamic URLs that otherwise difficult to discover by autoscanning. 3) If Struts or Strut2 is being used, gather info from the Struts validators (forget OTTOMH what the XML files called where this is placed, bot those are what I'm referring to). 4) Define some new custom format to allow the information they need to be independently gathered. Ideally this would be minimally some file format (maybe define a DTD or XSD for some XML format), but their tools could offer some GUI interface as well. Of course, I'm not sure I'd expect to see anything like this in my lifetime. At this point, most of the users of these tools don't even see this as a need to the same degree that Arian and readers of SC-L do and it's not clear how vendors addressing these shortcomings IN A COMMON WAY would help them to compete. More likely, we'll get there from here by evolution and vendors copying ideas from one another. The other significant driver AGAINST this as I see it as many vendors sell "professional services" for specialized consulting on how to do these things manually. That bring in extra $$ into their companies so convincing them to give up their cash cow is a hard sell. And as a purchaser of one of these tools, if you don't have the needed expertise in house (many do, but I'm guessing a lot more don't), it's hard to tell your director that you can't use that $75K piece of shelfware that your security group just bought because they can't figure out how to configure it. Instead, they are more likely to quietly just drop another $10K or so for consulting discretely and hope their director or VP doesn't notice. -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME From arian.evans at anachronic.com Wed Aug 5 01:23:28 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Tue, 4 Aug 2009 22:23:28 -0700 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: References: Message-ID: Kevin -- excellent points. Starting on top: + this is happening... (really!) + "dynamic scanning" vendors are getting together to add/share more data-points and lessons with: ++ WAF vendors ++ static-analysis automation vendors ++ consultants doing Pen-Testing, static analysis, threat modeling, source reviews, etc. It is all fresh and fairly immature, but I expect it to evolve quickly. So don't give up hope yet :) I do not see dynamic "scanning tools" vendors working together due to market competition/differentiation (yet, at least) but I do see dynamic scanning platform vendors (like my employer) reaching out to the consulting community to figure out how to give them a better platform from which to automate their bulk work (test every FF for XSS, etc.) and add in custom testing/pattern matching. As you probably are aware, even patterns in highly bespoke applications can often be applied to others (in the same enterprise or globally). In fact, the current generation of runtime CSRF tests I work with are an evolution of extrapolating patterns from "bespoke" applications and finding out how often they occur across unlike applications. (often) If you have more specific examples/needs - feel free to contact me directly Kevin to discuss further. On Tue, Aug 4, 2009 at 8:35 PM, Wall, Kevin wrote: > It's a pity that the these dynamic-scanning vendors can't work together to > come up with a common approach to at least helping this automation > you speak of at least part way along. (Yes, I know. I'm dreaming. ;-) You are spot on. And all these are great ideas, but the implementation is where it gets tricky... > Some ideas that I've had in the past is that they could request and make > use of: > 1) HTTP access logs from Apache and/or the web / application server. > ? These might be especially useful when the logs are specially configured > ? to also collect POST parameters and then the application's regression > ? tests are run against the application to collect the log data. Most web / > ? app servers support Apache HTTPD style access log format, so parsing > ? shouldn't be too terribly difficult in terms of the # of variations they need This is a great idea, and one we have juggled around internally quite often regarding how best to handle implementation. At one point we went down exploring server-side agents to actively collect and report, but in my experience very few (<1%) of users can deploy agents like this on their production systems. And if they do, they are the first thing blamed for any issues and get removed (and after being proven "innocent" are still hard to re-add). I am thinking the better (though less effective) implementation is either (a) user-driven-upload feature for such files, or (b) client-side-parsing script you can run on a dedicated machine you control, and point at these config files to parse and upload the results to your dynamic testing vendor. I have been looking for a "configuration-management" vendor that provides this sort of "config-file management" that is common in the enterprise. After talking to many customers, as recently as BH Vegas this year, I cannot find any such vendor. Does one exist? (I have seen a few tools that do this over the years, but it seems like no one uses them). A vendor-supported config-management tool would be a great (and easy) hookpoint. Kind of like DNS server records for network-VA/PT testing, but on an "application entrypoint" layer. I would definitely like to hear more of your thoughts here. (on or offline) Unfortunately -- very few customers I work with ask for this type of thing. While I would love to provide it -- most are still asking for features to find/classify all of their enterprise application assets. /a_priori_but_related_problem > 2) For Java, the web.xml could be used to gather data that might allow some > ? automation, especially wrt discovery of dynamic URLs that otherwise difficult > ? to discover by autoscanning. Exactly. Also useful for identifying package mismanagement, accidentally deployed modules, and "backdoors". > 3) If Struts or Strut2 is being used, gather info from the Struts validators (forget > ? ?OTTOMH what the XML files called where this is placed, bot those are what I'm Same goes for most modern frameworks. Too bad we do not have a standard 'web.config' file-format for frameworks. > 4) Define some new custom format to allow the information they need to be > ? ?independently gathered. Ideally this would be minimally some file format > ? ?(maybe define a DTD or XSD for some XML format), but their tools could offer > ? ?some GUI interface as well. See above. I have also thought about a user-extensible script that would allow folks to tweak it to parse multiple types of config files across multiple frameworks/platforms, and normalize it into one big "config.xml" to feed into their testing framework. Thoughts? > Of course, I'm not sure I'd expect to see anything like this in my lifetime. Don't be too cynical. There are those of us that see the need, and want to build these tools for you. :) Dynamic testing companies can also work with companies like Veracode to capture/enable extra data-points for testing. And vice-versa. I have found vulnerabilities in the past on applications after they were rigorously "source-code scanned" and "fixed", simply because the source code scanning tool was not properly including linked libraries (where the exploitable weaknesses lived). A pity we could not feed those back to the source-scanning tool vendor. > At this point, most of the users of these tools don't even see this as a need to > the same degree that Arian and readers of SC-L do and it's not clear how Eh, that is the problem. But I think it is changing. Last year I had maybe one or two discussions/requests from folks to help them solve this type of problem. This year I have had more requests like this just in the first six months. Maturity of solutions-seekers growing. ++optimism. > copying ideas from one another. ?The other significant driver AGAINST this > as I see it as many vendors sell "professional services" for specialized > consulting on how to do these things manually. That bring in extra $$ Working for a software company -- I can say first hand we want to build *tools* to help end-users, consultants, robots, whomever solve this problem, without fielding an army of consultants. I think most software companies would prefer to do this. Pro-services @software companies often exist because of the need for revenue early on, or weaknesses in the product, or simply demand from customers. I know I prefer to automate things and make them easy for people, rather than fly around a lot on airplanes. :) > into their companies so convincing them to give up their cash cow is > a hard sell. And as a purchaser of one of these tools, if you don't have > the needed expertise in house (many do, but I'm guessing a lot more > don't), it's hard to tell your director that you can't use that $75K piece of > shelfware that your security group just bought because they can't figure out > how to configure it. Instead, they are more likely to quietly just drop another > $10K or so for consulting discretely and hope their director or VP doesn't Or $100k+ when you start talking about appsec tools, but point taken. Again -- I think this solves itself somewhat as you (the paying consumer) demands more, votes with your dollars, and as we see more cross-analysis and cross-functional integration between tools vendors, and you get more extensibility in your testing tools allowing you to leverage automation more smartly. My $0.02 FWIW, -- Arian Evans "It is incumbent on every generation to pay its own debts as it goes. A principle which if acted on would save one-half the wars of the world." -- Thomas Jefferson From coley at linus.mitre.org Wed Aug 5 14:24:05 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 5 Aug 2009 14:24:05 -0400 (EDT) Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> Message-ID: On Tue, 4 Aug 2009, Chris Wysopal wrote: > As a group of security practitioners it is amazing to me that we don't > have more quantifiable testing and tools/services are just dismissed > with anecdotal data. I am glad NIST SATE '09 will soon be underway and, > at least for static analysis tools, we will have unbiased independent > testing. I am hoping for a big improvement over last year. I especially > like the category they are using for some flaws found as "valid but > insignificant". Clearly they are improving based on feedback from SATE > '08. By the way, I don't recall anybody mentioning this to SC-L before, but the SATE 2008 writeup and raw data are available: http://samate.nist.gov/index.php/SATE.html In the NIST pub we cover a lot of lessons learned, especially in my paper. >From the raw data you can see the complexities in doing this kind of large-scale comparison. In my opinion, our biggest limitation was not using live tools. - Steve From coley at linus.mitre.org Wed Aug 5 16:57:00 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 5 Aug 2009 16:57:00 -0400 (EDT) Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <853A02533F8C88439F2331EB1938538448CB001FEF@va-mailhub.cigital.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> <853A02533F8C88439F2331EB1938538448CB001FEF@va-mailhub.cigital.com> Message-ID: On Wed, 5 Aug 2009, Romain Gaucher wrote: > But for me, we had a hard time with using a consistent and actually, > meaningful scoring: > - What is a false-positive? > - How important is this particular finding? For those on this list, I cover these in some detail in my paper within the NIST document. > This was to me one of the most important limitations since eventually we > had most of the traces from the different tools. ... and I did create my own program to take the traces and make them somewhat usable, but it was still slower than using the live tools. Also, that didn't help with constructs like: sprintf("%s%s", a, b); where the tool was flagging 'a' and I thought it was flagging 'b'. > As Chris said, most of these problems should be addressed in the next > SATE, and I hope many tool vendors will be in again :) So do I!! It would be nice to have a much cleaner data set to work with. - Steve From rgaucher at cigital.com Wed Aug 5 16:04:47 2009 From: rgaucher at cigital.com (Romain Gaucher) Date: Wed, 5 Aug 2009 16:04:47 -0400 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> Message-ID: <853A02533F8C88439F2331EB1938538448CB001FEF@va-mailhub.cigital.com> Steve, I definitely agree that not using the tools were a big limitation -- especially because the web interface wasn't as interactive and powerful as tool GUIs. But for me, we had a hard time with using a consistent and actually, meaningful scoring: - What is a false-positive? - How important is this particular finding? This was to me one of the most important limitations since eventually we had most of the traces from the different tools. As Chris said, most of these problems should be addressed in the next SATE, and I hope many tool vendors will be in again :) Romain > -----Original Message----- > From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of > Steven M. Christey > Sent: Wednesday, August 05, 2009 1:24 PM > To: Chris Wysopal > Cc: Secure Coding > Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. > > > On Tue, 4 Aug 2009, Chris Wysopal wrote: > > > As a group of security practitioners it is amazing to me that we don't > > have more quantifiable testing and tools/services are just dismissed > > with anecdotal data. I am glad NIST SATE '09 will soon be underway and, > > at least for static analysis tools, we will have unbiased independent > > testing. I am hoping for a big improvement over last year. I especially > > like the category they are using for some flaws found as "valid but > > insignificant". Clearly they are improving based on feedback from SATE > > '08. > > By the way, I don't recall anybody mentioning this to SC-L before, but the > SATE 2008 writeup and raw data are available: > > http://samate.nist.gov/index.php/SATE.html > > In the NIST pub we cover a lot of lessons learned, especially in my paper. > >From the raw data you can see the complexities in doing this kind of > large-scale comparison. In my opinion, our biggest limitation was not > using live tools. > > - 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 matt at piscis-security.com Wed Aug 5 22:14:47 2009 From: matt at piscis-security.com (Matt Fisher) Date: Wed, 5 Aug 2009 21:14:47 -0500 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> Message-ID: <2A9EB7CB4A6ABC4391D7D77E93A7A113228D39667A@34093-MBX-C05.mex07a.mlsrvr.com> >I think anyone who has experience with deep dynamic testing knows they >need automation tools with custom configuration ability, the ability to >record workflow, a framework to create custom tests, etc. Absolutely. But Arian there are differing deployment models. You don't just touch an application once in it's life and leave it, right ? You're doing architecture reviews, reviewing the functional requirement and RBACs, reviewing code, doing integrated security testing, doing a final validation (or as a friend once put it over drinks " the big giant pen-test"). For any of those activities, you need real live, experienced skilled testers. Once it goes live, however, you may very well have a SOC, NOC, or even "security" team who is tasked with the continual scanning and "monitoring" of their space who's goal is to touch everything - however lightly - at least once very x days. For this type of scenario where bulk scalability counts over quality - AND A QUALITY ASSESSMENT AND VALIDATION WAS ALREADY PERFORMED- I would suggest a scanner monkey may be appropriate. Of course you would NEVER want that to be your ONLY assessment or validation. Chris, SPI had a product called DevInspect that performed static and dynamic analysis as a single product, and was definitely around before Aug '07. Not saying it was red-hot, just saying it was there. I'd like to see NTO. Given the slower dev times of the larger companies and begrudgingly slow addition of core capabilities to them, I'm really hoping that some of the "smaller guys" end up growing and filling niches. For instance, I've heard that one smaller player crawls every bit as well as a major player, and *much* better than the other major player, but while costing considerably less than either. NTO reps, feel free to spam me (me, not the list). I will say this: Chris I'm completely with you in that I'm convinced that the majority of the market buying scanners is not doing so based on any objective empirical testing, but rather on "who found what" or what they "like". I'm even saddened to say that I recently saw a presentation by an organization tasked and paid to perform objective empirical analysis of scanners, that literally ranked them based on what they found, with absolutely no testing ground truth. I'm even more strongly convinced that the majority of those running these tools completely underestimate the expertise required to properly operate them and realize full potential from them. Given the complexity of testing software these days you still really need to know what you're doing to eak out of them what little value they hold. Even with realizing their full potential, however, there's still a lot of work to be done beyond a scan to perform anything resembling a complete assessment. Of course, a human assisted SaaS model has the potential to fill the gap, but from what I'm the majority of organizations using scanners like WI and AS in-house don't. Heck, even some really big name firms selling rather expensive fancily marketed assessments don't. Shame, really. -Matt. -----Original Message----- From: Chris Wysopal [mailto:cwysopal at Veracode.com] Sent: Tuesday, August 04, 2009 8:54 PM To: Arian J. Evans; Matt Fisher Cc: Kenneth Van Wyk; Secure Coding Subject: RE: [SC-L] IBM Acquires Ounce Labs, Inc. I wouldn't say that NTO Spider is a "sort of" dynamic web scanner. It is a top tier scanner that can battle head to head on false negative rate with the big conglomerates' scanners: IBM AppScan and HP WebInspect. Larry Suto published an analysis a year ago, that certainly had some flaws (and was rightly criticized), but genuinely showed all three to be in the same league. I haven't seen a better head-to-head analysis conducted by anyone. A little bird whispered to me that we may see a new analysis by someone soon. As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. I am glad NIST SATE '09 will soon be underway and, at least for static analysis tools, we will have unbiased independent testing. I am hoping for a big improvement over last year. I especially like the category they are using for some flaws found as "valid but insignificant". Clearly they are improving based on feedback from SATE '08. Veracode was the first company to offer static and dynamic (web) analysis, and we have been for 2 years (announced Aug 8, 2007). We deliver it as a service. If you have a .NET or Java web app, you would cannot find a comparable solution form a single vendor today. -Chris -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Arian J. Evans Sent: Tuesday, July 28, 2009 1:41 PM To: Matt Fisher Cc: Kenneth Van Wyk; Secure Coding Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Right now, officially, I think that is about it. IBM, Veracode, and AoD (in Germany) claims they have this too. As Mattyson mentioned, Veracode only does static binary analysis (no source analysis). They offer "dynamic scanning" but I believe it is using NTO Spider IIRC which is a simplified scanner that targets unskilled users last I saw it. At one point I believe Veracode was in discussions with SPI to use WI, but since the Veracoders haunt this list I'll let them clarify what they use if they want. So IBM: soon. Veracode: sort-of. AoD: on paper And more to come in short order no doubt. I think we all knew this was coming sooner or later. Just a matter of "when". The big guys have a lot of bucks to throw at this problem if they want to, and pull off some really nice integrations. Be interesting to see what they do, and how useful the integrations really are to organizations. -- Arian Evans On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisher wrote: > Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. ?Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. > > -----Original Message----- > From: Prasad Shenoy > Sent: July 28, 2009 12:22 PM > To: Kenneth Van Wyk > Cc: Secure Coding > Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. > > > Wow indeed. Does that makes IBM the only vendor to offer both Static > and Dynamic software security testing/analysis capabilities? > > Thanks & Regards, > Prasad N. Shenoy > > On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: >> Wow, big acquisition news in the static code analysis space announced today: >> >> http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= >> >> >> Cheers, >> >> Ken >> >> ----- >> Kenneth R. van Wyk >> KRvW Associates, LLC >> http://www.KRvW.com >> >> (This email is digitally signed with a free x.509 certificate from CAcert. >> If you're unable to verify the signature, try getting their root CA >> certificate at http://www.cacert.org -- for free.) >> >> >> >> >> >> >> _______________________________________________ >> 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 arian.evans at anachronic.com Wed Aug 5 23:41:44 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Wed, 5 Aug 2009 20:41:44 -0700 Subject: [SC-L] IBM Acquires Ounce Labs, Inc. In-Reply-To: <2A9EB7CB4A6ABC4391D7D77E93A7A113228D39667A@34093-MBX-C05.mex07a.mlsrvr.com> References: <2A9EB7CB4A6ABC4391D7D77E93A7A113228CE8E2A0@34093-MBX-C05.mex07a.mlsrvr.com> <79348E23E9D34F4F8032010B2913D72B02E36640@NexusCore.Veracode.local> <2A9EB7CB4A6ABC4391D7D77E93A7A113228D39667A@34093-MBX-C05.mex07a.mlsrvr.com> Message-ID: Mattyson -- I almost complete agree with you. I will say - during ongoing "deep dive" assessments, we commonly find that applications that have one or more authC/Z issues at launch, will reintroduce them over time, if they write and push a lot of code. Anecdotally I would say we see at least one major Auth issue (or similar critical issue) per year in volatile code, over time, during ongoing assessments. (I'll do some hard math later on this.) The recurring issues are usually singular in nature, and not systemic. I'll give you an example: so you find that an app has a broken auth system; let's say it is a J2EE app, pre-MVC. Fundamental auth design-issue. To remediate they write an auth.Request.Routing servlet, and all servlets are only supposed to take callers that come through auth.Request.Routing. Design issue solved. So about once a year someone pushes a servlet (or form) with sensitive/critical functions, that does not properly call auth.Request.Routing. So now you have an implementation (or process, code review, peer review, SDL) problem. You get the idea. Insert all your points. So regular, or ongoing deep dives have a lot of value for high-risk applications to figure out which of the rest of the "system" broke. :) I agree "scanner jockey" work definitely has a place, and so do ongoing deep dives. The two can be combined with the right platform. Next up is integrating all these different types of analysis, and leveraging them all to provide better business context. There are cost-effective ways to enable people to do deeper blackbox and whitebox, and get better (and more contextual) results, I want to promote that. (Contextual Black Box vs. Blind Black Box). But I will save that for another chapter in this discussion. nota bene: In case I sounded too critical I should add -- one of the best things I hear in the field about Veracode is the strength of their customer-first/customer-centric focus and support, which is near and dear to my own heart. That should be a model for us all, and I wouldn't want to partner/work with with anyone who did things differently. I also hear Veracode is very good about customizing/tuning results of static analysis for clients. I think customization for individual customers is an essential reality for all types of analysis of custom code and business needs. Once again I think this is an important lesson for us all, and in my biased opinion: a major strength of SaaS appsec offerings. Any time you have to eat your own dogfoot, *and* satisfy clients on a recurring basis: you are going to get better fast. ChrisW could also claim I owe him a large intellectual debt for discussions over the years, but thankfully he's too polite for that. :) btw// I used to joke about how the BUFD (big up front design) crowd almost always addresses security with a BFPT (big final pen test) before shipping. So, possibly, we had that discussion over beers. Dusseldorf? ;) Anyway, great discussion. If you look back @SC-L three years ago, discussions like this show how much the industry and customer needs are evolving. Good stuff. Cheers, -- Arian Evans On Wed, Aug 5, 2009 at 7:14 PM, Matt Fisher wrote: >>I think anyone who has experience with deep dynamic testing knows they >>need automation tools with custom configuration ability, the ability to >>record workflow, a framework to create custom tests, etc. > > Absolutely. ?But Arian there are differing deployment models. ?You don't just touch an application once in it's life and leave it, right ? You're doing architecture reviews, reviewing the functional requirement and RBACs, reviewing code, doing integrated security testing, doing a final validation (or as a friend once put it over drinks " the big giant pen-test"). ?For any of those activities, you need real live, experienced skilled testers. > > Once it goes live, however, you may very well have a SOC, NOC, or even "security" team who is tasked with the continual scanning and "monitoring" of their space who's goal is to touch everything - however lightly - at least once very x days. ?For this type of scenario where bulk scalability counts over quality - AND A QUALITY ASSESSMENT AND VALIDATION WAS ALREADY PERFORMED- I would suggest a scanner monkey may be appropriate. ?Of course you would NEVER want that to be your ONLY assessment or validation. > > Chris, SPI had a product called DevInspect that performed static and dynamic analysis as a single product, and was definitely around before Aug '07. ?Not saying it was red-hot, just saying it was there. > > I'd like to see NTO. ?Given the slower dev times of the larger companies and begrudgingly slow addition of core capabilities to them, ?I'm really hoping that some of the "smaller guys" end up growing and filling niches. ?For instance, I've heard that one smaller player crawls every bit as well as a major player, and *much* better than the other major player, but while costing considerably less than either. NTO reps, feel free to spam me (me, not the list). > > I will say this: Chris I'm completely with you in that I'm convinced that the majority of the market buying scanners is not doing so based on any objective empirical testing, but rather on "who found what" or what they "like". ?I'm even saddened to say that I recently saw a presentation by an organization tasked and paid to perform objective empirical analysis of scanners, that literally ranked them based on what they found, with absolutely no testing ground truth. > > I'm even more strongly convinced that the majority of those running these tools completely underestimate the expertise required to properly operate them and realize full potential from them. ?Given the complexity of testing software these days you still really need to know what you're doing to eak out of them what little value they hold. Even with realizing their full potential, however, there's still a lot of work to be done beyond a scan to perform anything resembling a complete assessment. ?Of course, a human assisted SaaS model has the potential to fill the gap, but from what I'm the majority of organizations using scanners like WI and AS in-house don't. Heck, even some really big name firms selling rather expensive fancily marketed assessments don't. > > Shame, really. > > -Matt. > > > -----Original Message----- > From: Chris Wysopal [mailto:cwysopal at Veracode.com] > Sent: Tuesday, August 04, 2009 8:54 PM > To: Arian J. Evans; Matt Fisher > Cc: Kenneth Van Wyk; Secure Coding > Subject: RE: [SC-L] IBM Acquires Ounce Labs, Inc. > > > I wouldn't say that NTO Spider is a "sort of" dynamic web scanner. It is a top tier scanner that can battle head to head on false negative rate with the big conglomerates' scanners: IBM AppScan and HP WebInspect. ?Larry Suto published an analysis a year ago, that certainly had some flaws (and was rightly criticized), but genuinely showed all three to be in the same league. I haven't seen a better head-to-head analysis conducted by anyone. A little bird whispered to me that we may see a new analysis by someone soon. > > As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. ?I am glad NIST SATE '09 will soon be underway and, at least for static analysis tools, we will have unbiased independent testing. I am hoping for a big improvement over last year. ?I especially like the category they are using for some flaws found as "valid but insignificant". Clearly they are improving based on feedback from SATE '08. > > Veracode was the first company to offer static and dynamic (web) analysis, and we have been for 2 years (announced Aug 8, 2007). ?We deliver it as a service. If you have a .NET or Java web app, you would cannot find a comparable solution form a single vendor today. > > -Chris > > -----Original Message----- > From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Arian J. Evans > Sent: Tuesday, July 28, 2009 1:41 PM > To: Matt Fisher > Cc: Kenneth Van Wyk; Secure Coding > Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. > > Right now, officially, I think that is about it. IBM, Veracode, and > AoD (in Germany) claims they have this too. > > As Mattyson mentioned, Veracode only does static binary analysis (no > source analysis). They offer "dynamic scanning" but I believe it is > using NTO Spider IIRC which is a simplified scanner that targets > unskilled users last I saw it. > > At one point I believe Veracode was in discussions with SPI to use WI, > but since the Veracoders haunt this list I'll let them clarify what > they use if they want. > > So IBM: soon. > > Veracode: sort-of. > > AoD: on paper > > And more to come in short order no doubt. I think we all knew this was > coming sooner or later. Just a matter of "when". > > The big guys have a lot of bucks to throw at this problem if they want > to, and pull off some really nice integrations. Be interesting to see > what they do, and how useful the integrations really are to > organizations. > > -- > Arian Evans > > > > > > On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisher wrote: >> Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. ?Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. >> >> -----Original Message----- >> From: Prasad Shenoy >> Sent: July 28, 2009 12:22 PM >> To: Kenneth Van Wyk >> Cc: Secure Coding >> Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. >> >> >> Wow indeed. Does that makes IBM the only vendor to offer both Static >> and Dynamic software security testing/analysis capabilities? >> >> Thanks & Regards, >> Prasad N. Shenoy >> >> On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: >>> Wow, big acquisition news in the static code analysis space announced today: >>> >>> http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= >>> >>> >>> Cheers, >>> >>> Ken >>> >>> ----- >>> Kenneth R. van Wyk >>> KRvW Associates, LLC >>> http://www.KRvW.com >>> >>> (This email is digitally signed with a free x.509 certificate from CAcert. >>> If you're unable to verify the signature, try getting their root CA >>> certificate at http://www.cacert.org -- for free.) >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 jeremiah at whitehatsec.com Thu Aug 6 19:30:03 2009 From: jeremiah at whitehatsec.com (Jeremiah Grossman) Date: Thu, 6 Aug 2009 16:30:03 -0700 Subject: [SC-L] Integrated Dynamic and Static Scanning Message-ID: Hey all, I've been monitoring this thread [1] and some excellent points have been raised (cross-posting to websecurity as the subject matter applies). I'm personally very interested in the potential benefits of an integration between dynamic and static analysis scanning technology. The spork of software security testing. The desire of many is a single solution that unifies the benefits of both methodologies and simultaneously reduces their respective well-described limitations. For at least the last couple of years there have been vendors claiming success in this area, of which I remain skeptical. A brief explanation of the bi-directional and somewhat simple sounding innovations that vendors are trying to develop: 1) Dynamic Scanner -> Static Analyzer A dynamic analysis engine capable of providing HTTP vulnerability details (URL, cookie, form etc.) to a static analysis tool. Static analysis results narrowed down to a single line of insecure code or subroutine to speed vulnerability remediation. Prioritize issues that are located in a publicly available code flow vs. those that are not technically remotely-exploitable. Isolate security issues where source code was not available, such as third-party libraries. Static Analyzer -> Dynamic Scanner 2) A static analyzer capable of providing a remotely available attack surface (URLs, Forms, etc.) to a dynamic analysis tool. Dynamic analysis may realize additional testing comprehensiveness, measurement of coverage depth, and hints for creating exploit proof-of-concepts. Not to mention able to provide more detailed application fix recommendations. As it stands currently, the state-of-the-art is basically a reporting mash-up. Very little of the aforementioned advancements have been proven to funtion outside of the lab environment. If anyone has evidence to the contrary they can point to, please speak up. For those curious as to Tom Brennan's comment, these are the areas Fortify and WhiteHat are together working on. This is an excellent time to be in the application and software security industry. Over the next few years there is going to be a lot of innovation and awareness in the "defense" side of the industry. Talent, skill, and experience is going to command a premium. [1] http://www.mail-archive.com/sc-l at securecoding.org/msg02731.html Regards, Jeremiah Grossman Chief Technology Officer WhiteHat Security, Inc. http://www.whitehatsec.com/ blog: http://jeremiahgrossman.blogspot.com/ twitter: @jeremiahg From jeremiah at whitehatsec.com Thu Aug 6 20:22:54 2009 From: jeremiah at whitehatsec.com (Jeremiah Grossman) Date: Thu, 6 Aug 2009 17:22:54 -0700 Subject: [SC-L] [WEB SECURITY] Re: Integrated Dynamic and Static Scanning In-Reply-To: References: Message-ID: Good catch, that is exactly right. My oversight. A while back Fortify released a white paper entitled "Misplaced Confidence in Application Penetration Testing" [reg required] http://www.fortify.com/security-resources/library/overviews.jsp Tools also available to help measure. On Aug 6, 2009, at 5:04 PM, James Landis wrote: > There's a big claim in area 2) that actually does exist: > instrumentation of static code to give you code coverage metrics for > your dynamic scanning efforts. Well, maybe it's not area 2), but > it's definitely a static analyzer vendor feeding dynamic analysis. > > -j > > On Thu, Aug 6, 2009 at 4:30 PM, Jeremiah Grossman > wrote: > Hey all, > > I've been monitoring this thread [1] and some excellent points have > been raised (cross-posting to websecurity as the subject matter > applies). I'm personally very interested in the potential benefits > of an integration between dynamic and static analysis scanning > technology. The spork of software security testing. The desire of > many is a single solution that unifies the benefits of both > methodologies and simultaneously reduces their respective well- > described limitations. For at least the last couple of years there > have been vendors claiming success in this area, of which I remain > skeptical. > > A brief explanation of the bi-directional and somewhat simple > sounding innovations that vendors are trying to develop: > > 1) Dynamic Scanner -> Static Analyzer > A dynamic analysis engine capable of providing HTTP vulnerability > details (URL, cookie, form etc.) to a static analysis tool. Static > analysis results narrowed down to a single line of insecure code or > subroutine to speed vulnerability remediation. Prioritize issues > that are located in a publicly available code flow vs. those that > are not technically remotely-exploitable. Isolate security issues > where source code was not available, such as third-party libraries. > > Static Analyzer -> Dynamic Scanner > 2) A static analyzer capable of providing a remotely available > attack surface (URLs, Forms, etc.) to a dynamic analysis tool. > Dynamic analysis may realize additional testing comprehensiveness, > measurement of coverage depth, and hints for creating exploit proof- > of-concepts. Not to mention able to provide more detailed > application fix recommendations. > > > As it stands currently, the state-of-the-art is basically a > reporting mash-up. Very little of the aforementioned advancements > have been proven to funtion outside of the lab environment. If > anyone has evidence to the contrary they can point to, please speak > up. For those curious as to Tom Brennan's comment, these are the > areas Fortify and WhiteHat are together working on. > > > This is an excellent time to be in the application and software > security industry. Over the next few years there is going to be a > lot of innovation and awareness in the "defense" side of the > industry. Talent, skill, and experience is going to command a premium. > > > [1] http://www.mail-archive.com/sc-l at securecoding.org/msg02731.html > > > Regards, > > Jeremiah Grossman > Chief Technology Officer > WhiteHat Security, Inc. > http://www.whitehatsec.com/ > blog: http://jeremiahgrossman.blogspot.com/ > twitter: @jeremiahg > > ---------------------------------------------------------------------------- > Join us on IRC: irc.freenode.net #webappsec > > Have a question? Search The Web Security Mailing List Archives:http://www.webappsec.org/lists/websecurity/archive/ > > Subscribe via RSS:http://www.webappsec.org/rss/websecurity.rss [RSS > Feed] > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > From arshan.dabirsiaghi at aspectsecurity.com Thu Aug 6 22:55:36 2009 From: arshan.dabirsiaghi at aspectsecurity.com (Arshan Dabirsiaghi) Date: Thu, 6 Aug 2009 22:55:36 -0400 Subject: [SC-L] [WEB SECURITY] Re: Integrated Dynamic and Static Scanning References: Message-ID: Without instrumentation this will be major, costly, epic fail. Assuming life without it for the time being, I think the future is brighter for dynamic-to-static integration. Let's consider a few of the logistical issues going the opposite way - from static findings to exploit generation after a simple source-to-sink, tool-identified path for a SQL injection vulnerability found deep in the business logic of an application: 1. The application has no idea what it's method/scheme/hostname/port for invoking it should be. It seems like a simple thing to deduce, but I guarantee it's a huge PITA for anyone actually doing the work to make it 100% reliable. After all, if it's not 100% reliable, how can we claim that this technology helps us any more than the static trace alone? The value-add here is in ease of verification. A mistake made in figuring out any of these values will mean that the exploit will not be verified and will turn out to be a false negative. All the infrastructure touched before the app makes this a complex problem - and if this little tiny bit of obvious information is complex to generate, what hope is there of getting the rest of the complex set of circumstances right that are required to re-create a vulnerability in action? Realistically the VA and the SA (VA+SA, it's everywhere you want to be) need to maintain synchronization per request to make this a semi-sane idea. You could hardcode these values, but what if you use a mix of values and therefore aren't static across the application? Knowing the tools, I know the finding will still be reported somewhere deep in a "don't bother checking these" category. =) 2. The SQL injection vulnerability would have to understand the query and how to manipulate it in order to generate a meaningful query and resulting exploit. If proof that you can cause a syntax error is enough to verify exploitability then I guess this isn't such a big deal. But what if the syntax error never reaches the screen? Have you verified anything in this case? 3. The application would have no idea what server-side forwards, virtualized paths and filters were traversed to reach the application's action entry point. This reverse-engineering is especially hairy in J2EE, yet would be needed to be reliably generated in order to form an exploit. Put Spring on top of it and we're talking complexity that's practically impossible to re-model. This is just the tip of the iceburg, I think. The only technically feasible application of this kind of integration can be found in instrumentation ideas like Fortify's "attack path tracing", which would ideally be tied into unit testing and regression testing when it makes sense. Are there any competitors to them in this market? Does anybody have real-life experiences with this tool set? The idea of VA+Fortify+ptrace is intriguing, but we're looking at an explosion of complexity that I doubt many customers have the expertise to manage. +1 to Fortify for innovation, but can we get some technical information or user experiences here? Arshan P.S. Has anybody talked about cost/value analysis? It'd be cool tech, for sure, but is it worth it? I'm not trying to dissuade anybody from pursuing these ideas, but I just want to make sure all the cards are on the table. ________________________________ From: Jeremiah Grossman [mailto:jeremiah at whitehatsec.com] Sent: Thu 8/6/2009 8:22 PM To: James Landis Cc: sc-l at securecoding.org; websecurity at webappsec.org Subject: Re: [WEB SECURITY] Re: [SC-L] Integrated Dynamic and Static Scanning Good catch, that is exactly right. My oversight. A while back Fortify released a white paper entitled "Misplaced Confidence in Application Penetration Testing" [reg required] http://www.fortify.com/security-resources/library/overviews.jsp Tools also available to help measure. On Aug 6, 2009, at 5:04 PM, James Landis wrote: > There's a big claim in area 2) that actually does exist: > instrumentation of static code to give you code coverage metrics for > your dynamic scanning efforts. Well, maybe it's not area 2), but > it's definitely a static analyzer vendor feeding dynamic analysis. > > -j > > On Thu, Aug 6, 2009 at 4:30 PM, Jeremiah Grossman > wrote: > Hey all, > > I've been monitoring this thread [1] and some excellent points have > been raised (cross-posting to websecurity as the subject matter > applies). I'm personally very interested in the potential benefits > of an integration between dynamic and static analysis scanning > technology. The spork of software security testing. The desire of > many is a single solution that unifies the benefits of both > methodologies and simultaneously reduces their respective well- > described limitations. For at least the last couple of years there > have been vendors claiming success in this area, of which I remain > skeptical. > > A brief explanation of the bi-directional and somewhat simple > sounding innovations that vendors are trying to develop: > > 1) Dynamic Scanner -> Static Analyzer > A dynamic analysis engine capable of providing HTTP vulnerability > details (URL, cookie, form etc.) to a static analysis tool. Static > analysis results narrowed down to a single line of insecure code or > subroutine to speed vulnerability remediation. Prioritize issues > that are located in a publicly available code flow vs. those that > are not technically remotely-exploitable. Isolate security issues > where source code was not available, such as third-party libraries. > > Static Analyzer -> Dynamic Scanner > 2) A static analyzer capable of providing a remotely available > attack surface (URLs, Forms, etc.) to a dynamic analysis tool. > Dynamic analysis may realize additional testing comprehensiveness, > measurement of coverage depth, and hints for creating exploit proof- > of-concepts. Not to mention able to provide more detailed > application fix recommendations. > > > As it stands currently, the state-of-the-art is basically a > reporting mash-up. Very little of the aforementioned advancements > have been proven to funtion outside of the lab environment. If > anyone has evidence to the contrary they can point to, please speak > up. For those curious as to Tom Brennan's comment, these are the > areas Fortify and WhiteHat are together working on. > > > This is an excellent time to be in the application and software > security industry. Over the next few years there is going to be a > lot of innovation and awareness in the "defense" side of the > industry. Talent, skill, and experience is going to command a premium. > > > [1] http://www.mail-archive.com/sc-l at securecoding.org/msg02731.html > > > Regards, > > Jeremiah Grossman > Chief Technology Officer > WhiteHat Security, Inc. > http://www.whitehatsec.com/ > blog: http://jeremiahgrossman.blogspot.com/ > twitter: @jeremiahg > > ---------------------------------------------------------------------------- > Join us on IRC: irc.freenode.net #webappsec > > Have a question? Search The Web Security Mailing List Archives:http://www.webappsec.org/lists/websecurity/archive/ > > Subscribe via RSS:http://www.webappsec.org/rss/websecurity.rss [RSS > Feed] > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > ---------------------------------------------------------------------------- Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed] Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090806/1f1abb7c/attachment-0001.html From livshits at microsoft.com Fri Aug 7 17:20:59 2009 From: livshits at microsoft.com (Ben Livshits) Date: Fri, 7 Aug 2009 21:20:59 +0000 Subject: [SC-L] Integrated Dynamic and Static Scanning In-Reply-To: References: Message-ID: <329FD08600F5474C9229F8A125613E20062FDBED@tk5ex14mbxc106.redmond.corp.microsoft.com> Speaking of the lab environment, my thesis from 2006 (http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/thesis.pdf) explores the interplay between static and runtime in gory detail. I am not aware of these hybrid approaches being integrated into commercial products. Regards, -Ben -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jeremiah Grossman Sent: Thursday, August 06, 2009 4:30 PM To: sc-l at securecoding.org; websecurity at webappsec.org Subject: Re: [SC-L] Integrated Dynamic and Static Scanning Hey all, I've been monitoring this thread [1] and some excellent points have been raised (cross-posting to websecurity as the subject matter applies). I'm personally very interested in the potential benefits of an integration between dynamic and static analysis scanning technology. The spork of software security testing. The desire of many is a single solution that unifies the benefits of both methodologies and simultaneously reduces their respective well-described limitations. For at least the last couple of years there have been vendors claiming success in this area, of which I remain skeptical. A brief explanation of the bi-directional and somewhat simple sounding innovations that vendors are trying to develop: 1) Dynamic Scanner -> Static Analyzer A dynamic analysis engine capable of providing HTTP vulnerability details (URL, cookie, form etc.) to a static analysis tool. Static analysis results narrowed down to a single line of insecure code or subroutine to speed vulnerability remediation. Prioritize issues that are located in a publicly available code flow vs. those that are not technically remotely-exploitable. Isolate security issues where source code was not available, such as third-party libraries. Static Analyzer -> Dynamic Scanner 2) A static analyzer capable of providing a remotely available attack surface (URLs, Forms, etc.) to a dynamic analysis tool. Dynamic analysis may realize additional testing comprehensiveness, measurement of coverage depth, and hints for creating exploit proof-of-concepts. Not to mention able to provide more detailed application fix recommendations. As it stands currently, the state-of-the-art is basically a reporting mash-up. Very little of the aforementioned advancements have been proven to funtion outside of the lab environment. If anyone has evidence to the contrary they can point to, please speak up. For those curious as to Tom Brennan's comment, these are the areas Fortify and WhiteHat are together working on. This is an excellent time to be in the application and software security industry. Over the next few years there is going to be a lot of innovation and awareness in the "defense" side of the industry. Talent, skill, and experience is going to command a premium. [1] http://www.mail-archive.com/sc-l at securecoding.org/msg02731.html Regards, Jeremiah Grossman Chief Technology Officer WhiteHat Security, Inc. http://www.whitehatsec.com/ blog: http://jeremiahgrossman.blogspot.com/ twitter: @jeremiahg _______________________________________________ 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 vadim.okun at nist.gov Wed Aug 12 17:32:39 2009 From: vadim.okun at nist.gov (Vadim Okun) Date: Wed, 12 Aug 2009 17:32:39 -0400 Subject: [SC-L] Static analysis tool exposition (SATE) 2009 - call for participation Message-ID: <4A8334F7.10006@nist.gov> We are preparing an exposition for static analysis tools that find security relevant defects. Briefly, participating tool makers run their tools on real programs. Researchers led by NIST analyze the tool reports. Everyone reports results and experiences at a workshop. The tool reports and analysis are made publicly available later. The plan is at http://samate.nist.gov/SATE.html We plan to provide the test sets by 19 August, and to hold the workshop on 6 November. We invite tool makers to sign up. If you would like to participate in the exposition, or if you have questions, please email Vadim Okun (vadim.okun 'at' nist.gov). Sincerely, Vadim From secse-chair at sislab.no Tue Aug 18 10:04:38 2009 From: secse-chair at sislab.no (Martin Gilje Jaatun) Date: Tue, 18 Aug 2009 16:04:38 +0200 Subject: [SC-L] CFP - Secure Software Engineering (SecSE 2010) Message-ID: <4A8AB4F6.2020908@sislab.no> Fourth International Workshop on Secure Software Engineering (SecSE2010) http://www.sintef.org/secse In conjunction with ARES 2010 http://www.ares-conference.eu/conf/ February, 15th - 18th 2010 Andrzej Frycz Modrzewski Cracow College, Krakow, Poland Call for Papers =============== Software is an integral part of everyday life, and we expect and depend upon software systems to perform correctly. Software security is about ensuring that systems continue to function correctly also under malicious attack. As most systems now are web-enabled, the number of attackers with access to the system increases dramatically and thus the threat scenario changes. The traditional approach to secure a system includes putting up defence mechanisms like IDS and firewalls, but such measures are no longer sufficient by themselves. We need to be able to build better, more robust and more secure systems. Even more importantly, however, we should strive to achieve these qualities in all software systems, not just the ones that need special protection. This workshop will focus on techniques, experiences and lessons learned for building secure and dependable software. Topics ====== Suggested topics include, but are not limited to: - Secure architecture and design - Security in agile software development - Aspect-oriented software development for secure software - Security requirements - Risk management in software projects - Secure implementation - Secure deployment - Testing for security - Quantitative measurement of security properties - Static and dynamic analysis for security - Verification and assurance techniques for security properties - Lessons learned - Security and usability - Teaching secure software development - Experience reports on successfully attuning developers to secure software engineering Important dates: - Submission Deadline: September 30th 2009 - Author Notification: November 1st 2009 - Author Registration: November 11th 2009 - Proceedings Version: November 11th 2009 - Conference/ Workshop: February, 15th - 18th 2010 Submission Guidelines ===================== Authors are invited to submit papers in IEEE Computer Society Proceedings Manuscripts style (two columns, single-spaced, including figures and references, using 10 pt fonts, and number each page). Please consult the IEEE CS Author Guidelines at the following web page: http://www2.computer.org/portal/web/cscps/formatting We solicit the submission of academic workshop papers (6 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Duplicate submissions are not allowed. A submission is considered to be a duplicate submission if it is submitted to other conferences/workshops/journals or if it has been already accepted to be published in other conferences/workshops/journals. Duplicate submissions thus will be automatically rejected without review. Contact author must provide the following information: Paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords. Paper registration and submission is done through the ARES & CISIS 2010 Paper Management System at the following address: https://stdev.ifs.tuwien.ac.at/ares2010/ Submission of a paper implies that should the paper be accepted, at least one of the authors will register for the ARES conference and present the paper in the workshop. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. Note that SecSE 2010 does not require anonymized submissions. Publication =========== All accepted papers will be published as ISBN proceedings by the IEEE Computer Society, and will be available online through IEEE Xplore (EI indexing). Journal special issue: Distinguished papers submitted to SecSE will be invited for possible publication in the International Journal of Secure Software Engineering (ISSN 1947-3036 - http://www.igi-global.com/ijsse). Organizing committee: ==================== Martin Gilje Jaatun, SINTEF ICT, Norway Torbj?rn Skramstad, Norwegian University of Science and Technology (NTNU) Lillian R?stad, Norwegian University of Science and Technology (NTNU) Enquiries to the organizing committee may be sent to: SecSE "replace with at-character" sislab.no Program committee (to be confirmed) =================================== Rub?n Alonso, Visual Tools, Spain Sergey Bratus, Dartmouth College, USA Ana Cavalli, GET/INT, France Estibaliz Delgado, European Software Institute, Spain Ivan Flechais, University of Oxford, UK Khaled M. Khan, Qatar University, Qatar Andrea Lanzi, Institute Eurecom, France Per H?kon Meland, SINTEF ICT, Norway Khalid Mughal, University of Bergen, Norway Jong Hyuk Park, Kyungnam University, Korea Pierre Parrend, FZI, Germany Holger Peine, FH Hannover, Germany Chunming Rong, University of Stavanger, Norway Lillian R?stad, NTNU, Norway Riccardo Scandariato, KU Leuven, Belgium Christoph Schuba, Sun Microsystems Inc., USA Nahid Shahmehri, Link?ping University, Sweden Torbj?rn Skramstad, NTNU, Norway Panagiotis Trimintzios, ENISA, EU Bart De Win, KU Leuven, Belgium Stephen Wolthusen, Royal Holloway University of London, UK George Yee, Carleton University, Canada Mohammad Zulkernine, Queens University, Canada From arian.evans at anachronic.com Tue Aug 18 14:21:35 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Tue, 18 Aug 2009 11:21:35 -0700 Subject: [SC-L] What is the size of this list? Message-ID: Jeremiah Grossman and I were both pondering the size of the SCL recently. Is the list size public? I realized I tend to think of SCL as a small list of 30 people from 2003 who are are all about 2 degrees of Kevin Bacon away from each other. Now that what we do has become a true industry, and and the world at large is starting to take insecure code seriously, the importance of this subject is much greater than a few years ago. I am curious why I don't see many new names on SC-L. Lots of lurkers? btw// SCL has always been a great place for academic and progressive-minded folks to talk about state of the art, and future ideas for secure coding. I have always recommended it to developers looking for new places to learn as a "best and brightest" haunt. So thanks for running it guys, -- Arian Evans From ken at krvw.com Wed Aug 19 07:06:59 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 19 Aug 2009 07:06:59 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Message-ID: <850D5637-F9CE-4C8D-9EDE-395855815257@krvw.com> On Aug 18, 2009, at 2:21 PM, Arian J. Evans wrote: > Jeremiah Grossman and I were both pondering the size of the SCL > recently. > Is the list size public? It's not public per se, but only in the sense that the number isn't directly available--unless you ask for it. The list has pretty consistently hovered around 1000 subscribers since pretty shortly after I launched it in late 2003. > I am curious why I don't see many new names on SC-L. Lots of lurkers? We do seem to have a high percentage of lurkers, but I always like to encourage newcomers as well as new active participants. I do my best to keep my moderating light, and I welcome all perspectives and opinions on the topics we discuss here. My primary moderating criteria are ensuring submissions are relevant to the list charter and keep a civil tone. Beyond that, everyone on the list is largely free to say/discuss whatever suits. Plain and simple: the list is what the members make of it. > btw// SCL has always been a great place for academic and > progressive-minded folks to talk about state of the art, and future > ideas for secure coding. I have always recommended it to developers > looking for new places to learn as a "best and brightest" haunt. So > thanks for running it guys, Thanks. I've consistently found over the years that efforts like this are worth the effort in a myriad of ways, and it's something that I gladly take on. 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/20090819/9da7705c/attachment.bin From secureCoding2dave at davearonson.com Wed Aug 19 09:24:14 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Wed, 19 Aug 2009 09:24:14 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Message-ID: <3f4922c70908190624t33829a25o9cd9d75cd95b3dc2@mail.gmail.com> Arian J. Evans wrote: > I realized I tend to think of SCL as a small list of 30 people from > 2003 who are are all about 2 degrees of Kevin Bacon away from > each other. Sometimes more so than we know! I've been here for almost six years now, and until May, I had no idea that Karen used to work in the very same little department at the company that was about to lay me off, nor that we had a few other friends in common (albeit again from the software assurance community). > I am curious why I don't see many new names on SC-L. Lots of lurkers? That's probably true of any email list. I run a few where the same couple dozen or so names keep popping up in the From lines... out of thousands of members. -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. From rafael.ruiz at navico.com Wed Aug 19 11:36:30 2009 From: rafael.ruiz at navico.com (Rafael Ruiz) Date: Wed, 19 Aug 2009 08:36:30 -0700 Subject: [SC-L] What is the size of this list? In-Reply-To: <3f4922c70908190624t33829a25o9cd9d75cd95b3dc2@mail.gmail.com> Message-ID: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. From floodeen at gmail.com Wed Aug 19 16:14:32 2009 From: floodeen at gmail.com (Rob Floodeen) Date: Wed, 19 Aug 2009 16:14:32 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: References: <3f4922c70908190624t33829a25o9cd9d75cd95b3dc2@mail.gmail.com> Message-ID: <2f1215010908191314oa2d471bn4cc565f84dd1b431@mail.gmail.com> Hi SC-L, I'm a Lurker. I work for CERT | SEI | CMU and monitor the list in an attempt to keep an ear to the ground. While I'm not a professional programmer I do have an undergrad and graduate degree in CS which means I've been trained a little about programming. I'm really interested in two things with this list, 1. How do we teach secure coding from a training perspective (I develop training scenarios for CERT and I'm in the Workforce Development group, so this is exactly the kind of list that draws my attention.) 2. How to incorporate the concept of secure coding and new techniques/tools to do so. This should be a minor objective through our academic curriculum as well. Just like advanced math skills, we should have advanced secure coding skills for Software Engineers. Warm Regards, -Robert Floodeen On Wed, Aug 19, 2009 at 11:36 AM, Rafael Ruiz wrote: > Hi people, > > I am a lurker (I think), I am an embedded programmer and work at > Lowrance (a brand of the Navico company), and I don't think I can't > provide too much to security because embedded software is closed per se. > Or maybe I am wrong, is there a way to grab the source code from an > electronic equipment? That would be the only concern for embedded > programmers like me, but I just like to learn about the thinks you talk. > > Thank you. > > Greetings from Mexico. > > _______________________________________________ > 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 Wed Aug 19 16:34:40 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Wed, 19 Aug 2009 13:34:40 -0700 Subject: [SC-L] What is the size of this list? In-Reply-To: <850D5637-F9CE-4C8D-9EDE-395855815257@krvw.com> References: <850D5637-F9CE-4C8D-9EDE-395855815257@krvw.com> Message-ID: inline On Wed, Aug 19, 2009 at 4:06 AM, Kenneth Van Wyk wrote: > The list has pretty consistently hovered around 1000 subscribers since > pretty shortly after I launched it in late 2003. Interesting. I would not have guessed that the list was so large. Guess I need to stop making inside jokes and calling people names from private jokes on the list lest I confuse the unwary. [...] >?I do my best to keep my moderating light, and I welcome all perspectives > and opinions on the topics we discuss here. This list maintains a very high signal-to-noise ratio IMO. I think your moderation, if any, is effective so far. > Thanks. ?I've consistently found over the years that efforts like this are > worth the effort in a myriad of ways, and it's something that I gladly take on. This list is useful and appreciated. Thanks again, -ae From josh at codenomicon.com Wed Aug 19 21:15:22 2009 From: josh at codenomicon.com (Joshua Morin) Date: Wed, 19 Aug 2009 21:15:22 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Message-ID: <4A8CA3AA.8040806@codenomicon.com> Hi everyone, I'm a victim of being a lurker, I work for Codenomicon doing blackbox security testing, research, and much more. I take interest in the SC-L to keep a fresh perspective/hone in on peoples ideas about software assurance and whitebox security. BR, Joshua Morin Security Strategist Codenomicon Ltd. From secse-chair at sislab.no Thu Aug 20 05:14:18 2009 From: secse-chair at sislab.no (Martin Gilje Jaatun) Date: Thu, 20 Aug 2009 11:14:18 +0200 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Message-ID: <4A8D13EA.6060905@sislab.no> Rafael Ruiz wrote: > I am a lurker (I think), I am an embedded programmer and work at > Lowrance (a brand of the Navico company), and I don't think I can't > provide too much to security because embedded software is closed per se. > IMHO, it is very dangerous to assume that "since it is embedded, nobody has the source code". This "security through obscurity" approach was employed by the Bell telephone system in th 70's and 80's, but it turned out that there was no limit to what Phone Phreaks and their kin could dig up of supposedly secret information, including schematics and instruction manuals. In more recent times, reverse engineering of the DVD Content Scrambling System (CSS) and various RFID electronic fare cards has proven that if someone has physical access to a device, you must also assume that they can access the software. -Martin From nmatatal at uci.edu Wed Aug 19 17:15:36 2009 From: nmatatal at uci.edu (Neil Matatall) Date: Wed, 19 Aug 2009 14:15:36 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? Message-ID: <4A8C6B78.2080608@uci.edu> Inspired by the "What is the size of this list?" discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? I started a discussion in the Educause group on linked in. I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=138011&discussionID=5737656 It looks like some Universities are offering courses now... Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090819/7ba3aeed/attachment.htm From gem at cigital.com Thu Aug 20 09:26:32 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 20 Aug 2009 09:26:32 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: <4A8D13EA.6060905@sislab.no> Message-ID: hi martin and rafael, I agree with Martin. Software security is essential in most embedded systems. Also note that there is an interesting fractal line between hardware and software in such systems that often makes for interesting security situations. Consider Java-based smart cards (which I worked on a decade ago) which were susceptible to both malicious applets and differential power analysis. Designing a secure system involved understanding both the hardware and the software. At Cigital we continue to do lots of software security work with embedded systems companies, especially in the mobile space. The OS vendors, the carriers, and the application providers all have security responsibilities (and can all screw the whole thing up). By the way, QUALCOMM was a member of the BSIMM study and has a mature software security initiative underway. See http://bsi-mm.com gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com On 8/20/09 5:14 AM, "Martin Gilje Jaatun" wrote: Rafael Ruiz wrote: > I am a lurker (I think), I am an embedded programmer and work at > Lowrance (a brand of the Navico company), and I don't think I can't > provide too much to security because embedded software is closed per se. > IMHO, it is very dangerous to assume that "since it is embedded, nobody has the source code". This "security through obscurity" approach was employed by the Bell telephone system in th 70's and 80's, but it turned out that there was no limit to what Phone Phreaks and their kin could dig up of supposedly secret information, including schematics and instruction manuals. In more recent times, reverse engineering of the DVD Content Scrambling System (CSS) and various RFID electronic fare cards has proven that if someone has physical access to a device, you must also assume that they can access the software. -Martin _______________________________________________ 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 bishop at cs.ucdavis.edu Thu Aug 20 09:27:16 2009 From: bishop at cs.ucdavis.edu (Matt Bishop) Date: Thu, 20 Aug 2009 06:27:16 -0700 Subject: [SC-L] What is the size of this list? In-Reply-To: <2f1215010908191314oa2d471bn4cc565f84dd1b431@mail.gmail.com> References: <3f4922c70908190624t33829a25o9cd9d75cd95b3dc2@mail.gmail.com> <2f1215010908191314oa2d471bn4cc565f84dd1b431@mail.gmail.com> Message-ID: <71B38783-C9E4-4003-AC98-A9ABE7C7B9D0@cs.ucdavis.edu> Another lurker revealing himself ... my name is Matt Bishop, and I lurk at the University of California at Davis where I teach and do research in lots of areas of computer security, including (surprise!) what is traditionally called "secure programming" and "secure software development". For what it's worth, I don't like the use of the term "secure" because it's too vague -- I'd prefer "robust" or something related to assurance, but I can't come up with a short term. Oh, well. I've been working with "secure coding" for many years. I'm particularly interested in the interaction between coding and policy, and also in how to teach this stuff. I've done some training (long ago, with SANS), but now I focus on college/university education (for the most part). I get lots of good examples and ideas from this list, and sometimes the postings challenge me to think about different perspectives. In particular, the discussions of how people use these techniques, and the ones people find the most pernicious and troubling, help me give realistic examples when I teach students how to write good code. So Ken, thank you for starting and maintaining this list -- I think you've done the community a great service. A thought about Rob Floodeen's comment: > 2. How to incorporate the concept of secure coding and new > techniques/tools to do so. This should be a minor objective through > our academic curriculum as well. Just like advanced math skills, we > should have advanced secure coding skills for Software Engineers. My own feeling is that this should be a basic skill for people who program, not just software engineers. But the level at which practitioners (for want of a better term) need to know this varies depending on what they do. An occasional programmer (a physicist, for example) probably doesn't need to know about race conditions and, indeed, about security in general -- but she would need to know how to write a program that checks its input (lest the results be invalid -- GIGO), which is "security" from her point of view. A software engineer darn well better know about race conditions, though! So I agree with what Rob posted, and I did have one thought. Is writing good English a "minor" objective of an English major? Probably, in the sense English curricula focus on interpretation of literature, literary criticism, and other aspects of literature. But it's an essential one. So perhaps "incidental and important" describes how I feel better than "minor". Matt From James.McGovern at thehartford.com Thu Aug 20 11:07:12 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Thu, 20 Aug 2009 11:07:12 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8C6B78.2080608@uci.edu> References: <4A8C6B78.2080608@uci.edu> Message-ID: Here is where my enterpriseyness will show. I believe the answer to the question of where secure coding belongs in the curiculum is somewhat flawed and requires addressing the curiculum holistically. If you go to art school, you are required to study the works of the masters. You don't attempt to paint a Picasso in the first semester, yet us IT folks think it is OK to write code before studying the differences between good code and bad code. If a student never learns good from bad and over time develops bad habits, then teaching security at ANY stage later in life is the wrong answer. We need to remix the way IT is taught in Universities and revisit the fundamentals of how to approach IT as a whole. My second and conflicting opinion says that Universities shouldn't be teaching secure code as they won't get it right. Students should understand the business/economic impact that lack of secure coding causes. If this is left strictly to Universities, it will most certainly feel academic (in the bad sense). A person doesn't become a real IT professional until they have a few years of real-world experience under their belts and therefore maybe this is best left to their employers as part of professional development and/or Master's programs that are IT-focused but not about the traditional computer-science/software engineering way of thinking... http://twitter.com/mcgoverntheory ************************************************************ 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/20090820/ab100fed/attachment-0001.htm From james.walden at gmail.com Thu Aug 20 11:57:23 2009 From: james.walden at gmail.com (James Walden) Date: Thu, 20 Aug 2009 11:57:23 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8C6B78.2080608@uci.edu> References: <4A8C6B78.2080608@uci.edu> Message-ID: <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> On Wed, Aug 19, 2009 at 5:15 PM, Neil Matatall wrote: > So where does secure coding belong in the curriculum? I think secure coding should be taught at the same time that coding is taught. There are aspects of security that can be taught from the beginning, such as input validation and error handling. It's a more efficient and I suspect more effective means of teaching to teach students the best known methods of secure coding first rather than initially teaching them to code insecurely then trying to fix that later. Northern Kentucky University, where I teach, does this in some classes and we're working to move it into all classes. Secure coding is also a large component of our computer security course, and we have a separate secure software engineering class at the graduate level (there is also a security module in the undergraduate software engineering course.) I agree with James McGovern on the need for students to study good and bad code. It has always surprised me how little code reading is done in a typical computer science program, and I think this is particularly important for security. While you can teach students secure coding techniques, they will likely not stick with them once they see examples of bad code elsewhere if they don't understand the reasons why they're using those techniques. That's one reason why a general computer security class is essential to the secure coding curriculum. James Walden Northern Kentucky University http://faculty.cs.nku.edu/~waldenj From pmeunier at cerias.purdue.edu Thu Aug 20 12:01:20 2009 From: pmeunier at cerias.purdue.edu (Pascal Meunier) Date: Thu, 20 Aug 2009 12:01:20 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> Message-ID: <20090820120120.78b9b865@Saguenay> On Thu, 20 Aug 2009 11:07:12 -0400 "McGovern, James F (HTSC, IT)" wrote: > Here is where my enterpriseyness will show. I believe the answer to the > question of where secure coding belongs in the curiculum is somewhat > flawed and requires addressing the curiculum holistically. > > If you go to art school, you are required to study the works of the > masters. You don't attempt to paint a Picasso in the first semester, yet > us IT folks think it is OK to write code before studying the differences > between good code and bad code. If a student never learns good from bad > and over time develops bad habits, then teaching security at ANY stage > later in life is the wrong answer. We need to remix the way IT is taught > in Universities and revisit the fundamentals of how to approach IT as a > whole. > > My second and conflicting opinion says that Universities shouldn't be > teaching secure code as they won't get it right. That's a bold statement. I've been teaching secure coding for many years at Purdue. Nobody has told me before that what I did had a negative impact ;) >Students should > understand the business/economic impact that lack of secure coding > causes. If this is left strictly to Universities, it will most certainly > feel academic (in the bad sense). Applying this logic in a different domain, people shouldn't be taught gun safety until they're on the firing range and have a gun in their hands... What you do in practice with the knowledge you acquire anywhere is always up to you. No matter the subject, when you're told that you shouldn't "touch a hot oven", it's academic or feels like watching a movie until you actually "touch one". However, if you were warned and taught good practices, after the incident you will quickly practice what you were taught, if you have sense. If you were never warned then you'll blame your teachers and whoever else for leaving that out, and you'll have to spend time unlearning the bad practices and learning what you should have been taught. In this sense, isn't your second point contradictory with the first? In any case, I'd rather not be blamed ;) >A person doesn't become a real IT > professional until they have a few years of real-world experience under > their belts and therefore maybe this is best left to their employers as > part of professional development I agree that experience matters so that it validates what people were taught, and that good practices get applied. However, given the real-world security practice in some companies, it seems unlikely that real-world experience alone would teach people better than academia could (if that's what you meant). I believe that the most productive approach at a university level is to equip and "prime" students so that they know some good practices (e.g., in the area of secure coding), can perform critical thinking and can keep learning from their experiences in the real world. Regards, Pascal > and/or Master's programs that are > IT-focused but not about the traditional computer-science/software > engineering way of thinking... > > http://twitter.com/mcgoverntheory > ************************************************************ > 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 goertzel_karen at bah.com Thu Aug 20 12:20:55 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Thu, 20 Aug 2009 12:20:55 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: <71B38783-C9E4-4003-AC98-A9ABE7C7B9D0@cs.ucdavis.edu> References: <3f4922c70908190624t33829a25o9cd9d75cd95b3dc2@mail.gmail.com> <2f1215010908191314oa2d471bn4cc565f84dd1b431@mail.gmail.com>, <71B38783-C9E4-4003-AC98-A9ABE7C7B9D0@cs.ucdavis.edu> Message-ID: As far as I'm concerned, being able to understand English is crucial to meaningful interpretation of literature written in that language, and being able to write and speak English with mastery is crucial to effective self-expression as a critic. So English mastery is not just "incidental and important", it is absolutely vital to the success of the English major who aspires to more than mediocrity. I feel the same way about software development. Writing software sloppily results in software the functional objectives of which can be subverted, either accidentally or intentionally. Such software cannot be said to satisfy those objectives, and thus it must be seen as failing, at least partially. It's only because we have accepted such partial failure for as long as there has been software that our standards for what we consider "goodness" for software are so poor. If we applied the same poor standards to safety-critical mechanical systems a heck of a lot more of us would be reading this mailing list from hospital beds, nursing home rooms, or the afterlife. That's if they even have Internet access in the afterlife. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Matt Bishop [bishop at cs.ucdavis.edu] Sent: Thursday, August 20, 2009 9:27 AM To: Secure Coding List Subject: Re: [SC-L] What is the size of this list? ...So I agree with what Rob posted, and I did have one thought. Is writing good English a "minor" objective of an English major? Probably, in the sense English curricula focus on interpretation of literature, literary criticism, and other aspects of literature. But it's an essential one. So perhaps "incidental and important" describes how I feel better than "minor". Matt From bishop at cs.ucdavis.edu Thu Aug 20 12:41:11 2009 From: bishop at cs.ucdavis.edu (Matt Bishop) Date: Thu, 20 Aug 2009 09:41:11 -0700 Subject: [SC-L] What is the size of this list? In-Reply-To: References: <3f4922c70908190624t33829a25o9cd9d75cd95b3dc2@mail.gmail.com> <2f1215010908191314oa2d471bn4cc565f84dd1b431@mail.gmail.com>, <71B38783-C9E4-4003-AC98-A9ABE7C7B9D0@cs.ucdavis.edu> Message-ID: <34277996-923B-4D4F-919A-630573B00939@cs.ucdavis.edu> Karen, Ah, once again I expressed myself poorly. Apologies to all; it was too early in the morning to write (I'm on Pacific time). > As far as I'm concerned, being able to understand English is crucial > to meaningful interpretation of literature written in that language, > and being able to write and speak English with mastery is crucial to > effective self-expression as a critic. So English mastery is not > just "incidental and important", it is absolutely vital to the > success of the English major who aspires to more than mediocrity. I did not mean that it was unimportant; indeed, I very strongly agree with you. I mean that learning to express oneself is part of the focus of a good English curriculum, but not the only one. You begin with basic instruction in that (English/Rhetoric/Comp Lit 1A-1B-1C), and then take an advanced course or two on that topic, and then continue to hone your skills on courses like Shakespeare, Orwell, Milton, Steinbeck, etc. But in those later courses the primary goal is not to teach you clarity of expression; you are assumed to know how to express yourself, and your skills improve as a result of constructive criticism on what you write. And without the ability to express yourself clearly, you can't discuss themes, characterizations, and other aspects of English. I think "secure" programming should be taught similarly. The primary goal of learning to program is not to write "secure" programs. it is to learn to write good programs, designed with the appropriate amount of thought for the requirements and use. Someone specializing in analysis of algorithms will probably not delve as deeply into software engineering as someone specializing in that area, and I think that requiring the algorithmist (is there such a word?) to know software engineering at that level is inappropriate. *But* the algorithmist should know how to write good code, and that's basically what we are talking about. I hope this clarifies what I meant. Learning to write good code is incidental to one's studies in the sense that it is not the end goal, but it is a necessary skill, and an important one, for all who program. > I feel the same way about software development. Writing software > sloppily results in software the functional objectives of which can > be subverted, either accidentally or intentionally. Such software > cannot be said to satisfy those objectives, and thus it must be seen > as failing, at least partially. It's only because we have accepted > such partial failure for as long as there has been software that our > standards for what we consider "goodness" for software are so poor. Yep; if your requirements are poorly thought out, your software may satisfy them, but it (almost certainly) won't do what it should. An observation: it's not just in software that we accept partial failures. Think of the last time you called a large company about a problem :-). Thanks, Karen! Matt From goertzel_karen at bah.com Thu Aug 20 13:59:03 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Thu, 20 Aug 2009 13:59:03 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> Message-ID: I'm more devious. I think what needs to happen is that we need to redefine what we mean by "functionally correct" or "quality" code. If determination of functional correctness were extended from "must operate as specified under expected conditions" to "must operate as specified under all conditions", functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com From arian.evans at anachronic.com Thu Aug 20 14:09:40 2009 From: arian.evans at anachronic.com (Arian J. Evans) Date: Thu, 20 Aug 2009 11:09:40 -0700 Subject: [SC-L] embedded systems security analysis Message-ID: Rafael -- to clarify concretely: There are quite a few researchers that attack/exploit embedded systems. Some google searches will probably provide you with names. None of the folks I know of that actively work on exploiting embedded systems are on this list....but I figure if I know a handful of them in my small circle of software security folks - there have to be many more out there. Assuming you are safe is not just a dangerous assumption: but wrong. Specifically - One researcher I know pulls boards & system components apart and finds out who the source IC and component makers are. Then they contact the component and IC makers and pretends to be the board or system vendor who purchased the components, and asks for documentation, debuggers, magic access codes hidden in firmware (if he cannot reverse them). If this fails, the researcher has also befriended people at companies who do work with the IC or board maker, traded them information, in exchange for debuggers and the like. This particular researcher does not publish any of their research in this area. They do it mainly (I think) to help build better tools and as a hobby. (Several of you on this list probably know exactly whom I'm talking about. This person would prefer privacy, and I think the person's employer demands it, unless you get him in person and feed him enough beer.) If I were a bettin' man I'd figure if I know a few person doing this type of thing for quite a few years now -- there are bound to be many, many more.... Not sure what list to go to for talks on that type of thing. Blackhat.com has some older presentations on this subject. -- Arian Evans On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruiz wrote: > Hi people, > > I am a lurker (I think), I am an embedded programmer and work at > Lowrance (a brand of the Navico company), and I don't think I can't > provide too much to security because embedded software is closed per se. > Or maybe I am wrong, is there a way to grab the source code from an > electronic equipment? That would be the only concern for embedded > programmers like me, but I just like to learn about the thinks you talk. > > Thank you. > > Greetings from Mexico. > > _______________________________________________ > 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 Aug 20 14:55:32 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 20 Aug 2009 14:55:32 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8C6B78.2080608@uci.edu> Message-ID: hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of "Software Security" . Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since then. * University of California at Davis * University of Virginia * Johns Hopkins University * Princeton University * Purdue University (especially the CERIAS center) * Rice University * University of California at Berkeley * Stanford University * Naval Postgraduate School (a military school for graduates) * University of Idaho * Iowa State University * George Washington University * United States Military Academy at West Point Matt Bishop made some excellent points in this thread. He and I discuss the notion of education versus training at length in Silver Bullet episode 31 part of which was transcribed here . gem company www.cigital.com book www.swsec.com On 8/19/09 5:15 PM, "Neil Matatall" wrote: Inspired by the "What is the size of this list?" discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? I started a discussion in the Educause group on linked in. I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=138011&discussionID=5737656 It looks like some Universities are offering courses now... Neil From James.McGovern at thehartford.com Thu Aug 20 15:12:20 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Thu, 20 Aug 2009 15:12:20 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> Message-ID: Wanted to introduce another worst practice in terms of Universities vs Enterprises that isn't about curriculum but is about knowledge of secure coding. There are user groups such as OWASP where topics such as secure coding are frequently discussed. These events are 100% free to attend and are filled with professionals. On my side of town, the professors that happen to be adjunct and have a day job in corporations for whatever reason also are not only introducing secure coding techniques into their material, they are encouraging their students to attend our local Hartford OWASP chapter (http://www.owasp.org/index.php/Hartford) Likewise, on numerous occasions, we have reached out and extended the same invite to fulltime professors who have neither made any effort in attending nor even sharing with their students. So, when do we ask the more difficult question of whether current professors are capable of teaching the curriculum in a manner that enables the success for their students... ************************************************************ 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 secureCoding2dave at davearonson.com Thu Aug 20 15:13:48 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Thu, 20 Aug 2009 15:13:48 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> Message-ID: <3f4922c70908201213t726f919j628c153b18593975@mail.gmail.com> Goertzel, Karen [USA] wrote: > If determination of functional correctness were extended from "must > operate as specified under expected conditions" to "must operate as > specified under all conditions", functional correctness would necessarily > require security, safety, fault tolerance, and all those other good things > that make software dependable instead of just correct. A much-too-late entry for the bumper sticker contest we had here a few years back: "Works as you wish, under all condish." (Okay, okay, so maybe that kind of abbreviating is a bit out of style... by 70 years or so....) -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. From secse-chair at sislab.no Thu Aug 20 15:45:50 2009 From: secse-chair at sislab.no (Martin Gilje Jaatun) Date: Thu, 20 Aug 2009 21:45:50 +0200 Subject: [SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?) In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> Message-ID: <4A8DA7EE.5000006@sislab.no> Karen, Matt & all, Goertzel, Karen [USA] wrote: > I'm more devious. I think what needs to happen is that we need to redefine what we mean by "functionally correct" or "quality" code. If determination of functional correctness were extended from "must operate as specified under expected conditions" to "must operate as specified under all conditions", functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. > I couldn't agree more! However, I have had several discussions with a colleague who is fairly well known in the"Software Process Improvement Mafia" on the topic of how to ensure that security requirements are considered for _all_ kinds of code, not just "security software". Particularily in the context of agile development techniques, security keeps getting the short end of the stick, losing every time to "working features". His stance on this is that "if security were important to the customer, the customer would provide and prioritize security requirements". To me, this is a bit like saying "If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it". If we can "brainwash" the coming generations of programmers into accepting Karen's definition of "quality code", we might finally be getting somewhere. -Martin From Kevin.Wall at qwest.com Thu Aug 20 15:36:16 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Thu, 20 Aug 2009 14:36:16 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> Message-ID: Karen Goertzel wrote... > I'm more devious. I think what needs to happen is that we > need to redefine what we mean by "functionally correct" or > "quality" code. If determination of functional correctness > were extended from "must operate as specified under expected > conditions" to "must operate as specified under all > conditions", functional correctness would necessarily require > security, safety, fault tolerance, and all those other good > things that make software dependable instead of just correct. Except, unfortunately, as an industry / profession, we can't even get the far-simpler (IMO) _functional correctness_ right let alone (so-called) "non-functional" issues such as security, safety, fault tolerance, etc. (Mathematical rigor and proof-of-correctness aside, but in many [most?] cases that's not practical and even if it were, most programmers' brains turn to mathematical mush whenever they see any kind of correctness proof. Meaning that "it ain't going to happen" if it requires thinking. ;-) In some regard, I think this holds things back. If we don't do a good job testing that the software does all that it's supposed to do under *ideal* conditions, how are we ever to expect developers and testers to test to make sure that the software doesn't do additional things that it's NOT supposed to do under less than ideal conditions. There's a reason why Ross Anderson and Roger Needham talked about "Programming Satan's Computer" (see http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf). [Yes, I 'm aware that paper was about the correctness of distributed cryptographic protocols, but I think both Anderson and Needham would agree that the term "Programming Satan's Computer" applies more generally than just to that narrow aspect of security.] Not that I'm advocating of giving up, mind you. If the battle seems hopeless, perhaps we would see more progress if we were to address secure programming issues simply as a related aspect of program correctness. Why? Because the development community seems to be more willing to address those things. (Obviously, part of that is that many programming flaws are rather tangible and something that casual users can experience. Yeah! That's the ticket. Let's teach the general populace how to hack into systems! Pass out free "You've been pwnd!" T-shirts with every successful pwnage. Now *THAT* would be devious. ;-) -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 From goertzel_karen at bah.com Thu Aug 20 16:04:29 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Thu, 20 Aug 2009 16:04:29 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, Message-ID: Here's an extract from the Information Assurance Technology Analysis Center (part of DTIC) "Software Security Assurance: A State of the Art Report" (http://iac.dtic.mil/iatac/download/security.pdf): Courses on secure software development, secure programming, etc., typically begin by introducing common attacks against software-intensive information systems and the vulnerabilities targeted by those attacks, then progress to modeling, design, coding, and testing practices that software developers can adopt to reduce the likelihood that exploitable vulnerabilities will appear in the software they produce. The following is a representative sampling of such courses: - Arizona State University: Software Security - Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems - Carnegie Mellon University (CMU) and University of Ontario (Canada): Secure Software Systems - George Mason University: Secure Software Design and Programming - George Washington University: Security and Programming Languages - Catholic University of Leuven (Belgium): Development of Secure Software - New Mexico Tech: Secure Software Construction - North Dakota State University: Engineering Secure Software - Northeastern University: Engineering Secure Software Systems - Northern Kentucky University, Rochester Institute of Technology, and University of Denver: Secure Software Engineering - Polytechnic University: Application Security - Purdue University: Secure Programming - Queen?s University (Kingston, ON, Canada): Software Reliability and Security - Santa Clara University: Secure Coding in C and C++ - University of California at Berkeley, Walden University (online): Secure Software Development - University of California at Santa Cruz: Software Security Testing - University of Canterbury (New Zealand): Secure Software - University of Nice Sophia-Antipolis (Nice, France): Formal Methods and Secure Software - University of Oxford (UK): Design for Security - University of South Carolina: Building Secure Software. As noted earlier, other schools offer lectures on secure coding and other software security relevant topics within their larger software engineering or computer security course offerings. At least two universities - the University of Texas at San Antonio and University of Dublin (Ireland) - have established reading groups focusing on software security. As part of its Trustworthy Computing initiative, Microsoft Research has established its Trustworthy Computing Curriculum program [309] for promoting university development of software security curricula. Interested institutions submit proposals to Microsoft, and those that are selected are provided seed funding for course development. Another recent trend is post-graduate degree programs with specialties or concentrations in secure software engineering (or security engineering for software-intensive systems). Some of these are standard degree programs, while others are specifically designed for the continuing education of working professionals. The following are typical examples: - James Madison University: Master of Science in Computer Science with a Concentration in Secure Software Engineering - Northern Kentucky University: Graduate Certificate in Secure Software Engineering - Stanford University: Online Computer Security Certificate in Designing Secure Software From the Ground Up - University of Colorado at Colorado Springs: Graduate Certificate in Secure Software Systems - Walden University (online): Master of Science in Software Engineering with a Specialization in Secure Computing - University of Central England at Birmingham: Master of Science in Software Development and Security - Chalmers University (Gothenburg, Sweden): Master of Science in Secure and Dependable Computer Systems. In another interesting trend (to date, exclusively in non-US schools), entire academic departments - and in one case a whole graduate school?are being devoted to teaching and research in software dependability, including security, e.g.: - University of Oldenburg (Germany) TrustSoft Graduate School of Trustworthy Software Systems - Fraunhofer Institute for Experimental Software Engineering (IESE) (Kaiserslautern, Germany): Department of Security and Safety - Bond University (Queensland, Australia): Centre for Software Assurance. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw [gem at cigital.com] Sent: Thursday, August 20, 2009 2:55 PM To: Neil Matatall; Secure Code Mailing List Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of "Software Security" . Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since then. * University of California at Davis * University of Virginia * Johns Hopkins University * Princeton University * Purdue University (especially the CERIAS center) * Rice University * University of California at Berkeley * Stanford University * Naval Postgraduate School (a military school for graduates) * University of Idaho * Iowa State University * George Washington University * United States Military Academy at West Point Matt Bishop made some excellent points in this thread. He and I discuss the notion of education versus training at length in Silver Bullet episode 31 part of which was transcribed here . gem company www.cigital.com book www.swsec.com On 8/19/09 5:15 PM, "Neil Matatall" wrote: Inspired by the "What is the size of this list?" discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? I started a discussion in the Educause group on linked in. I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=138011&discussionID=5737656 It looks like some Universities are offering courses now... Neil _______________________________________________ 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 nmatatal at uci.edu Thu Aug 20 16:16:27 2009 From: nmatatal at uci.edu (Neil Matatall) Date: Thu, 20 Aug 2009 13:16:27 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, Message-ID: <4A8DAF1B.6080401@uci.edu> Everyone, Thank you for all of the input. Really. This information has been extremely helpful! Neil Goertzel, Karen [USA] wrote: > Here's an extract from the Information Assurance Technology Analysis Center (part of DTIC) "Software Security Assurance: A State of the Art Report" (http://iac.dtic.mil/iatac/download/security.pdf): > > Courses on secure software development, secure programming, etc., typically > begin by introducing common attacks against software-intensive information > systems and the vulnerabilities targeted by those attacks, then progress to > modeling, design, coding, and testing practices that software developers can adopt > to reduce the likelihood that exploitable vulnerabilities will appear in the software > they produce. The following is a representative sampling of such courses: > > - Arizona State University: Software Security > - Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems > - Carnegie Mellon University (CMU) and University of Ontario (Canada): > Secure Software Systems > - George Mason University: Secure Software Design and Programming > - George Washington University: Security and Programming Languages > - Catholic University of Leuven (Belgium): Development of Secure Software > - New Mexico Tech: Secure Software Construction > - North Dakota State University: Engineering Secure Software > - Northeastern University: Engineering Secure Software Systems > - Northern Kentucky University, Rochester Institute of Technology, and > University of Denver: Secure Software Engineering > - Polytechnic University: Application Security > - Purdue University: Secure Programming > - Queen?s University (Kingston, ON, Canada): Software Reliability > and Security > - Santa Clara University: Secure Coding in C and C++ > - University of California at Berkeley, Walden University (online): Secure > Software Development > - University of California at Santa Cruz: Software Security Testing > - University of Canterbury (New Zealand): Secure Software > - University of Nice Sophia-Antipolis (Nice, France): Formal Methods > and Secure Software > - University of Oxford (UK): Design for Security > - University of South Carolina: Building Secure Software. > > As noted earlier, other schools offer lectures on secure coding and other > software security relevant topics within their larger software engineering or > computer security course offerings. At least two universities - the University > of Texas at San Antonio and University of Dublin (Ireland) - have established > reading groups focusing on software security. > > As part of its Trustworthy Computing initiative, Microsoft Research > has established its Trustworthy Computing Curriculum program [309] for > promoting university development of software security curricula. Interested > institutions submit proposals to Microsoft, and those that are selected are > provided seed funding for course development. > > Another recent trend is post-graduate degree programs with specialties > or concentrations in secure software engineering (or security engineering for > software-intensive systems). Some of these are standard degree programs, > while others are specifically designed for the continuing education of working > professionals. The following are typical examples: > > - James Madison University: Master of Science in Computer Science with > a Concentration in Secure Software Engineering > - Northern Kentucky University: Graduate Certificate in Secure > Software Engineering > - Stanford University: Online Computer Security Certificate in Designing > Secure Software From the Ground Up > - University of Colorado at Colorado Springs: Graduate Certificate in > Secure Software Systems > - Walden University (online): Master of Science in Software Engineering > with a Specialization in Secure Computing > - University of Central England at Birmingham: Master of Science in > Software Development and Security > - Chalmers University (Gothenburg, Sweden): Master of Science in > Secure and Dependable Computer Systems. > > In another interesting trend (to date, exclusively in non-US schools), > entire academic departments - and in one case a whole graduate school?are > being devoted to teaching and research in software dependability, including > security, e.g.: > > - University of Oldenburg (Germany) TrustSoft Graduate School of > Trustworthy Software Systems > - Fraunhofer Institute for Experimental Software Engineering (IESE) > (Kaiserslautern, Germany): Department of Security and Safety > - Bond University (Queensland, Australia): Centre for Software Assurance. > > > Karen Mercedes Goertzel, CISSP > Associate > 703.698.7454 > goertzel_karen at bah.com > ________________________________________ > From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw [gem at cigital.com] > Sent: Thursday, August 20, 2009 2:55 PM > To: Neil Matatall; Secure Code Mailing List > Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > > hi neil, > > For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of "Software Security" . Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since then. > > * University of California at Davis > * University of Virginia > * Johns Hopkins University > * Princeton University > * Purdue University (especially the CERIAS center) > * Rice University > * University of California at Berkeley > * Stanford University > * Naval Postgraduate School (a military school for graduates) > * University of Idaho > * Iowa State University > * George Washington University > * United States Military Academy at West Point > > Matt Bishop made some excellent points in this thread. He and I discuss the notion of education versus training at length in Silver Bullet episode 31 part of which was transcribed here . > > gem > > company www.cigital.com > book www.swsec.com > > > On 8/19/09 5:15 PM, "Neil Matatall" wrote: > > Inspired by the "What is the size of this list?" discussion, I decided I won't be a lurker :) > > A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions > > So where does secure coding belong in the curriculum? > > Higher Ed? High School? > > Undergrad? Grad? Extension? > > I started a discussion in the Educause group on linked in. I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=138011&discussionID=5737656 > > It looks like some Universities are offering courses now... > > Neil > > > _______________________________________________ > 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 goertzel_karen at bah.com Thu Aug 20 16:27:51 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Thu, 20 Aug 2009 16:27:51 -0400 Subject: [SC-L] embedded systems security analysis In-Reply-To: References: Message-ID: A colleague and I have been looking at the problem a bit, in the context of need for survivability in safety-critical systems. Below is an extract of the paper "Software Survivability: Where Safety and Security Converge" authored by Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore Winograd at the American Institute of Aeronautics and Astronautics' Infotech at Aerospace Conference in Seattle last spring. There's also a brief discussion of security issues associated with embedded software in the DHS/DACS "Enhancing the Development Life Cycle to Produce Secure Software" - specifically pages 272-275. The document is freely downloadable after quick registration on the DACS (DTIC's Data and Analysis Center for Software) Web site: https://www.dacs.dtic.mil/techs/enhanced_life_cycles/ Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com -- B. Embedded No Longer Means Isolated Before discounting a comparable threat to embedded systems, consider the following excerpt from Chapter seven of Exploiting Software [8] by Greg Hoglund and Gary McGraw: "For no valid technical reasons, people seem to believe that embedded systems are invulnerable to remote software-based attacks. One common misconception runs that because a device does not include an interactive shell out of the box, then accessing or using ?shell code? is not possible. This is probably why some people (wrongly) explain that the worst thing that an attacker can do to most embedded systems is merely to crash the device. The problem with this line of reasoning is that injected code is, in fact, capable of executing any set of instructions, including an entire shell program that encompasses and packages up for convenient use standard, supporting [operating system]-level functions. It does not matter that such code does not ship with the device. Clearly, this kind of code can simply be placed into the target during an attack. Just for the record, an attack of this sort may not need to insert a complete interactive TCP/IP shell. Instead, the attack might simply wipe out a configuration file or alter a password. There are any numbers of complex programs that can be inserted via a remote attack on an embedded system. Shell code is only one of them. Even the most esoteric of equipment can be reverse engineered, debugged, and played with. It does not really matter what processor or addressing scheme is being used, because all an attacker needs to do is to craft operational code for the target hardware. Common embedded hardware is (for the most part) well documented, and such documents are widely available." One of the most widely publicized successful attacks on an embedded system was the 2002 hack of the flash memory of the Microsoft XBox game cube in order to access the algorithm used by the game cube?s cryptosystem to decrypt and verify its bootloader. [9] Now consider how safety-critical embedded systems?from temperature controls to medical devices to on-board airplane and automotive computers and sensors?are increasingly becoming network-accessible. For example, embedded software in implanted medical devices is now accessible via radio frequency identification (RFID) interfaces. [10] And telemedicine applications in use by DoD enable software-controlled surgical robots located in U.S. military facilities in Iraq to be operated via satellite uplinks by doctors at the U.S. Navy Hospital in Bethesda, Maryland. [11] Consider General Motors? OnStar and its less familiar rivals (Ford?s RESCU and VEMS, Volvo?s OnCall, BMW?s Assist, Mercedes-Benz?s TeleAid and COMAND). These services all include the ability of call center representatives to perform remote telematic diagnostics of the onboard computers in their subscribers? vehicles. The data they collect via transmissions from the cars? computers are returned to the remote call centers via cellular or satellite phone links. Remote monitoring and diagnosis of automotive computers sounds benign enough (though there are significant privacy concerns associated with some of the data being gathered by these services), but OnStar has gone a step beyond simple observation to actual remote control of at least one of the automobile?s safety-critical onboard computers: the one that controls its ignition. As USA Today reported in October 2007, [12] the 1.7 million General Motors 2009 vehicles equipped with OnStar now allow their owners to grant permission for OnStar to cooperate with the police if their vehicles are stolen; specifically, if a police car is involved in a high-speed car chase with a stolen OnStar-enabled vehicle, the police can request that the stolen vehicle?s engine ?be remotely switched off through the OnStar mobile communications system?. The objective of this police/OnStar cooperation is laudable: it allows the police to terminate car chases involving stolen vehicles, thereby reducing the number of fatal accidents associated with such chases (such reductions are the stated objective of the program), while coincidentally increasing their arrest rates and stolen auto recovery rates (not mentioned as drivers for the program). What the new use of OnStar also heralds is a transition of one of the world?s most successful telematics systems from passive data collection to active control of remote embedded systems. Imagine a hacker ingenious enough to locate, intercept?and tamper with?OnStar cellular transmissions: what potentially disastrous, even deadly, havoc might such a hacker be able to wreak by shutting off car engines willy-nilly during a typical New York City rush hour? As with so many network connections before it, now that OnStar?s two-way connectivity is there, other potential applications are already suggesting themselves, and no doubt at least some of these will prove irresistible. It has been suggested, for example, that OnStar could be used to load new firmware into automobile computers without the customers having to take their cars into a dealership. Now imagine that capability threatened by the programmer laid off from GM who decides to take revenge by hacking into the OnStar call center and inserting malicious logic or even just ?garbage bits? into transmission streams over OnStar?s cellular links. [13] The question of OnStar?s inherent security vulnerability was raised by PC Today?s ?On the Road? columnist. After summarizing OnStar?s and comparable services? security measures (many of which rely on security through obscurity) and reporting the vulnerability found in such services by security researchers, the columnist concluded: [14] "?auto makers must not relax their diligence, as the future of telematics security is still unclear. In their detailed report, Security in Automotive Bus Systems, researchers Marko Wolf, Andr? Weimerskirch, and Christof Paar noted, ?[Some] automotive communication networks have access to crucial components of the vehicle, like brakes, airbags, and the engine control. Cars that are equipped with driving aid systems allow deep interventions in the driving behavior of the vehicle?. Malicious attackers are not to be underestimated.?" Do the benefits of network addressable embedded systems and remote telematics outweigh the risks? In most cases, probably. But they should also at least raise the question: is the security of embedded systems adequate to protect them against direct hacking or malicious code insertion over network connections that they were never originally designed to support? This is a question that is relevant for all safety-critical systems that are being exposed, to any degree, to access via network connections. Embedded systems have inherently much higher reliability expectations than most of other software systems. They are also subject to unique security threats: hackers may use sensitive test equipment to steal, disassemble, and probe small devices to remove memory elements from the system to extract their contents. They may use debugging ports and software to read sensitive data or force unintended operations. They may measure the device?s electromagnetic radiation or power consumption to gain clues about hidden functions and concealed information. They may force the system to operate outside its design parameters through introduction of extreme temperatures, voltage excursions, and clock variations, thereby exposing anomalous and vulnerable behaviors. Memory devices are a favorite target of attack because they store both the system?s firmware and software and its sensitive data. Many such devices can be read while in circuit, and may provide temporary plain text data during operation. If the device includes a tamper sensor, the designer can incorporate hardware or software resources that will rapidly erase sensitive data before the device can be extracted. Another threat unique to software within embedded systems is reverse engineering of the physical system to enable the attacker to devise countermeasures to the system?s security protections, or to the system itself, e.g., countermeasures to a weapons system. An attacker might also use information gained through reverse engineering to design a new version of the system that can then be used to target the copied system or its originator. Embedded software is far more likely to be implemented using any one of a large number of fairly obscure (outside of the embedded development community) and non-standard software architectures, languages, and host operating systems. ?Security through obscurity? is a dubious advantage of the unfamiliarity and non-standardization of embedded software, but it also places a greater burden on each implementer to determine whether the architecture and operating system chosen provide adequate security protection or any at all. The proliferation of existing and emerging embedded-system architectures is also multiplying the number of attack paths and the number and variety of security threats that can leverage those attack paths to cause operational disruptions, to force unintended operations, or to extract sensitive data. The same proliferation is inhibiting the development of an industry-wide scheme for security protection of embedded software. Some key secure software design principles are particularly relevant to embedded software design: ? Differentiation between low- and high-consequence functions and public and private data. By denying user access to high-consequence functions and private data, the designer can reduce the risks to these elements of the embedded system; ? The design must provide protection during the embedded system?s normal operation, during attack through a network connection, and during electronic probing (e.g., in an attacker?s laboratory). Most specifications for embedded operating system security (e.g., Multiple Independent Layers of Security/Safety [MILS], which is supported by real-time operating systems (RTOS) from Green Hills Software, LynuxWorks, and Wind River Software) focus on implementing the security protections defined in the Common Criteria. Unfortunately, Common Criteria protections, which focus on confidentiality, integrity, availability, and access control of data handled by computer systems, and of accountability of their users, do little or nothing to assure the security of the software itself. Security concerns have changed the basic design guidelines for embedded products. Traditional criteria for evaluating embedded systems designs?smallness of circuitry, efficiency of code, and long mean times between failures?are no longer sufficient to assure those systems? dependability, trustworthiness, and survivability. Unfortunately, to date embedded system designers have limited their focus on software security protection to preventing physical access to the embedded software by strengthening its physical packaging, mainly through use of ?anti-tamper? mechanisms. 8. Hoglund, Greg and Gary McGraw. Exploiting Software: How to Break Code (Boston, MA: Addison-Wesley, 2004). For more information: http://www.exploitingsoftware.com/ 9. Huang, Andrew ?Bunnie?. ?Keeping Secrets in Hardware: The Microsoft XBox Case Study?. Massachussetts Institute of Technology AI Memo #2002-008, 26 May 2002. Accessed 2 March 2009 at: http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf 10. Becker, T.J. ?Improving Medical Devices: Georgia Tech Research Center Expands Testing Capabilities to Help Reduce Potential Interference?. Georgia Tech Research News, 25 July 2006. Accessed 2 March 2009 at: http://www.gtresearchnews.gatech.edu/newsrelease/eas-center.htm 11. Ackerman, Robert K. ?Telemedicine Reaches Far and Wide?. SIGNAL, March 2005. Accessed 2 March 2009 at: http://www.afcea.org/signal/articles/templates/SIGNAL_Article_Template.asp?articleid= 693&zoneid=128. Also H. Murakami, et al., Tohoku University Sendai. ?Telemedicine Using Mobile Satellite Communication?. IEEE Transactions on Biomedical Engineering, Volume 41 Issue 5, May 1994, pp. 488-497. Digital Object Identifier: 10.1109/10.293224 12. Woodyard, Chris Woodyard. ?Device can remotely halt auto chases?. USA Today, 9 October 2007. Accessed 20 February 2009 at: http://abcnews.go.com/Business/Autos/story?id=3706113 13. Note that malicious code deliveries (the most common installation method for viruses, worms) and insertions (the most common installation method for Trojan horses) have been involved in several recorded SCADA security incidents. See Turk, Robert J., Idaho National Laboratory. ?Cyber Incidents Involving Control Systems?, INL/EXT-05-00671, October 2005. Accessed 2 March 2009 at: http://www.inl.gov/technicalpublications/Documents/3480144.pdf 14. Farwell, Jennifer. ?Hijacked, Corrupted and Crashed: Does the New Generation of Computerized Cars Pose a Security Threat??. PC Today, Volume 3 Issue 10, October 2005. Accessed 14 March 2009 at: http://www.pctoday.com/editorial/article.asp?article=articles%2F2005%2Ft0310%2F05t10%2F05t10.asp From neumann at csl.sri.com Thu Aug 20 18:50:21 2009 From: neumann at csl.sri.com (Peter G. Neumann) Date: Thu, 20 Aug 2009 15:50:21 PDT Subject: [SC-L] What is the size of this list? In-Reply-To: Your message of Thu, 20 Aug 2009 09:41:11 -0700 Message-ID: Let me amplify what Matt Bishop has said. I tend to deal with TRUSTWORTHINESS, which encompasses security, reliability, survivability, human safety, and anything else that you have to trust whether you like it or not. Security is only one aspect of it. Long ago Butler Lampson wrote a paper pointing out that if it is not secure, it won't be reliable, and if it is not reliable, it is may not be secure. That was applied to access controls in hardware, but it is equally applied to SYSTEMS. Also, all of those trustworthiness properties tend to be emergent properties of the entire system/enterprise/whatever. Beware of folks who tell you their crypto algorithm (for example) is 100% secure, and ignore that fact that if it badly implemented or the keys are stored in an unsecure operating system, then all bets are off and 100% secure becomes 0% secure. end of soapbox, which some of you have heard from me before. Peter From jeremy.j.epstein at gmail.com Thu Aug 20 17:39:50 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Thu, 20 Aug 2009 17:39:50 -0400 Subject: [SC-L] embedded systems security analysis In-Reply-To: References: Message-ID: I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It might be something like the ability to insert a card in a PC slot (as in the Princeton attack on Diebold touchscreen systems), a USB stick (some of the UC Santa Barbara attacks - I think that was ES&S touchscreen machines), Harri Hursti's attacks via a memory card on Diebold optical scanners, Princeton's attacks via a proprietary memory card on Sequoia systems, etc. (There are others too - the machines in my county use USB sticks and run Windows CE, so I believe they're susceptible to even trivial attacks via an autorun.) I also worked with a team that did some attacks on another embedded system in a voting machine, although we didn't get far enough to publish results before we ran out of students to do the grunt work. So I'd 1000% agree with Arian - not only is assuming you're safe dangerous, but it's also wrong. There's lots of attacks on other types of embedded systems - there have been a few against electric power control systems, water control systems, etc. And there are more that haven't seen the light of day.... I just heard about a very serious attack the other day that hasn't ever made it into the news. --Jeremy On Thu, Aug 20, 2009 at 2:09 PM, Arian J. Evans wrote: > Rafael -- to clarify concretely: > > There are quite a few researchers that attack/exploit embedded > systems. Some google searches will probably provide you with names. > > None of the folks I know of that actively work on exploiting embedded > systems are on this list....but I figure if I know a handful of them > in my small circle of software security folks - there have to be many > more out there. > > Assuming you are safe is not just a dangerous assumption: but wrong. > > Specifically - > > One researcher I know pulls boards & system components apart and finds > out who the source IC and component makers are. > > Then they contact the component and IC makers and pretends to be the > board or system vendor who purchased the components, and asks for > documentation, debuggers, magic access codes hidden in firmware (if he > cannot reverse them). > > If this fails, the researcher has also befriended people at companies > who do work with the IC or board maker, traded them information, in > exchange for debuggers and the like. > > This particular researcher does not publish any of their research in > this area. They do it mainly (I think) to help build better tools and > as a hobby. (Several of you on this list probably know exactly whom > I'm talking about. This person would prefer privacy, and I think the > person's employer demands it, unless you get him in person and feed > him enough beer.) > > If I were a bettin' man I'd figure if I know a few person doing this > type of thing for quite a few years now -- there are bound to be many, > many more.... > > Not sure what list to go to for talks on that type of thing. > Blackhat.com has some older presentations on this subject. > > -- > Arian Evans > > > > On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruiz wrote: >> Hi people, >> >> I am a lurker (I think), I am an embedded programmer and work at >> Lowrance (a brand of the Navico company), and I don't think I can't >> provide too much to security because embedded software is closed per se. >> Or maybe I am wrong, is there a way to grab the source code from an >> electronic equipment? That would be the only concern for embedded >> programmers like me, but I just like to learn about the thinks you talk. >> >> Thank you. >> >> Greetings from Mexico. >> >> _______________________________________________ >> 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 rafael.ruiz at navico.com Thu Aug 20 19:35:57 2009 From: rafael.ruiz at navico.com (Rafael Ruiz) Date: Thu, 20 Aug 2009 16:35:57 -0700 Subject: [SC-L] embedded systems security analysis In-Reply-To: Message-ID: Thank you for all the info you guys have sent, it has been very informative... :) It is harder to steal the source (you need more electronical knowledge and expensive debuggers and stuff) but it is possible... Do you guys know some pages with security tips for embedded systems? From goertzel_karen at bah.com Thu Aug 20 20:11:12 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Thu, 20 Aug 2009 20:11:12 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Your message of Thu, 20 Aug 2009 09:41:11 -0700, Message-ID: Interesting. My definition of "secure" is for software is "dependable, trustworthy, and survivable (or, if you prefer, resilient)", i.e., (1) It's got to behave correctly and predictably; (2) It's got to behave non-maliciously and also not be subvertible (i.e., no weaknesses that can be exploited as vulnerabilities); (3) When it comes under attack, 1 & 2 need to hold true for as long as possible before the software's execution gracefully degrades and ultimately fails; when it does fail, it must do so in a manner that doesn't make it, its data, or its resources vulnerable to further compromise, and it must recover to an acceptable level of operation (which, obviously, needs to be specified) as quickly as possible, with as little damage as possible (and having minimised the extent of that damage). Obviously, there's very little software that can satisfy all three of these criteria 100%. But even 50% is better than 0%. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: Peter G. Neumann [neumann at csl.sri.com] Sent: Thursday, August 20, 2009 6:50 PM To: Matt Bishop Cc: Goertzel, Karen [USA]; Secure Coding List Subject: Re: [SC-L] What is the size of this list? Let me amplify what Matt Bishop has said. I tend to deal with TRUSTWORTHINESS, which encompasses security, reliability, survivability, human safety, and anything else that you have to trust whether you like it or not. Security is only one aspect of it. Long ago Butler Lampson wrote a paper pointing out that if it is not secure, it won't be reliable, and if it is not reliable, it is may not be secure. That was applied to access controls in hardware, but it is equally applied to SYSTEMS. Also, all of those trustworthiness properties tend to be emergent properties of the entire system/enterprise/whatever. Beware of folks who tell you their crypto algorithm (for example) is 100% secure, and ignore that fact that if it badly implemented or the keys are stored in an unsecure operating system, then all bets are off and 100% secure becomes 0% secure. end of soapbox, which some of you have heard from me before. Peter From mlyman-cissp at comcast.net Fri Aug 21 08:17:03 2009 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Fri, 21 Aug 2009 07:17:03 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8C6B78.2080608@uci.edu> References: <4A8C6B78.2080608@uci.edu> Message-ID: <4A8E903F.1030007@comcast.net> Neil Matatall wrote: > So where does secure coding belong in the curriculum? > > Higher Ed? High School? > > Undergrad? Grad? Extension? Secure coding needs to be taught anytime programing is taught. >From my experience in my son's boy scout troop, I'm not sure I'd call it out as security and confuse middle school/junior high school students but I'd teach them basics like input validation and bounds checking as basic good programing. The security aspects can wait until later when they can better handle several concepts at once. After that is just needs to be part of the course and called out for what it is. There is room for stand alone security focused training and courses but it needs to be drilled in all along the way. I recall my own computer science instructors telling us *not* to spend time on bells and whistles and concentrate on the concept the lesson was covering. If the lesson was on pointers, adding things like error checking and user friendly features didn't count for anything. I can understand why that was said but it sends the wrong message and begins the development of bad habits. That was 20 to 30 years ago and most computer users' idea of security was locking their car doors but it did set us up for bad habits. Basics need to be drilled in early and always count for something even if the lesson is while loops. -- Mike Lyman mlyman at west-point.org From colin.cassidy at ge.com Fri Aug 21 08:40:33 2009 From: colin.cassidy at ge.com (Cassidy, Colin (GE Infra, Energy)) Date: Fri, 21 Aug 2009 14:40:33 +0200 Subject: [SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?) In-Reply-To: <4A8DA7EE.5000006@sislab.no> References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> <4A8DA7EE.5000006@sislab.no> Message-ID: <2D3692016CCD2D4AA33741E25925EA7102EFBB08@BUDMLVEM06.e2k.ad.ge.com> Martin Gilje Jaatun wrote: > Karen, Matt & all, > > Goertzel, Karen [USA] wrote: > > I'm more devious. I think what needs to happen is that we > need to redefine what we mean by "functionally correct" or > "quality" code. If determination of functional correctness > were extended from "must operate as specified under expected > conditions" to "must operate as specified under all > conditions", functional correctness would necessarily require > security, safety, fault tolerance, and all those other good > things that make software dependable instead of just correct. > > > I couldn't agree more! > > However, I have had several discussions with a colleague who is fairly > well known in the"Software Process Improvement Mafia" on the topic of > how to ensure that security requirements are considered for > _all_ kinds > of code, not just "security software". Particularily in the context of > agile development techniques, security keeps getting the short end of > the stick, losing every time to "working features". His stance on this > is that "if security were important to the customer, the > customer would > provide and prioritize security requirements". To me, this is > a bit like > saying "If the customer doesn't explicitly state that the software > should be Y2k-proof, he/she is not really bothered about it". The problem (certainly as I see it) is that the customer is likely to say "Make it secure" without really understanding what that means. Secure against what exactly? Or you'll get a list of security features that the customer wants, but as we all know security features != secure product. Instead we've taken a combined approach of including customer requirements and adding specific requirements of our own focusing a good Secure development practices. > If we can "brainwash" the coming generations of programmers into > accepting Karen's definition of "quality code", we might finally be > getting somewhere. And that's the trick we've been attempting here. Secure software is nothing more than really good quality code. We already use coding guidelines and have a strong(ish) process of code reviews. So we have augmented our coding and review guidelines to include secure coding aspect such as input/output validation, good memory management etc. That said there is still a lot of scope for improvement in the rest of the software development process (testing and design in particular). CJC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4427 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20090821/7180bd1c/attachment-0001.bin From goertzel_karen at bah.com Fri Aug 21 09:48:47 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 21 Aug 2009 09:48:47 -0400 Subject: [SC-L] embedded systems security analysis In-Reply-To: References: , Message-ID: We looked at the problem of voting system security specifically in the context of insider threat for last year's IATAC State of the Art Report on the Insider Threat to Information Systems - some of which involved "rogue" developers engineering backdoors into such systems. Unfortunately the document is limited distribution and FOUO, so I can't excerpt here. But if you're interested and a government employee or contractor, let me know and I'll get you instructions on how to register with DTIC to obtain a copy. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Jeremy Epstein [jeremy.j.epstein at gmail.com] Sent: Thursday, August 20, 2009 5:39 PM To: Arian J. Evans Cc: Secure Coding List Subject: Re: [SC-L] embedded systems security analysis I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It... From goertzel_karen at bah.com Fri Aug 21 10:44:21 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 21 Aug 2009 10:44:21 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8E903F.1030007@comcast.net> References: <4A8C6B78.2080608@uci.edu>,<4A8E903F.1030007@comcast.net> Message-ID: I think we need to start indoctrinating kids in the womb. Start selling Baby Schneier CDs alongside Baby Mozart. :) Seriously, though, cyberspace is such an integral part of modern life, parents need to inculcate online security into their toddlers the same way they teach them to look both ways before crossing the street, and not to talk to or get into the car with strangers. In essence, we need to teach kids the virtual equivalents of these safe behaviours when they go online - which some of them are doing as early as age 4! If they can be "brainwashed" that early, they will come to have higher expectations of what SHOULD be present with regard to security properties in software-based systems. Then the notion won't seem alien to them. What will seem alien TO US is that they won't understand the struggles we've had to get people to start adding security. The idea of security having ever NOT been there will be bizarre to them. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Mike Lyman [mlyman-cissp at comcast.net] Sent: Friday, August 21, 2009 8:17 AM To: Secure Coding Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Neil Matatall wrote: > So where does secure coding belong in the curriculum? > > Higher Ed? High School? > > Undergrad? Grad? Extension? Secure coding needs to be taught anytime programming is taught.... From gem at cigital.com Fri Aug 21 11:00:35 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 21 Aug 2009 11:00:35 -0400 Subject: [SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?) In-Reply-To: <2D3692016CCD2D4AA33741E25925EA7102EFBB08@BUDMLVEM06.e2k.ad.ge.com> Message-ID: Actually CJC, it's often even worse than that. In many cases, the customer or consumer has an implicit requirement for security that remains unstated. Only when the system fails and is successfully attacked does that requirement shift from implicit to explicit. "You mean it wasn't secure?? You've got to be kidding..." In some sense that's what happened to Microsoft way back in the virus-bag days. History shows that it is best to anticipate implicit requirements and address them as possible. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 8/21/09 8:40 AM, "Cassidy, Colin (GE Infra, Energy)" wrote: Martin Gilje Jaatun wrote: > Karen, Matt & all, > > Goertzel, Karen [USA] wrote: > > I'm more devious. I think what needs to happen is that we > need to redefine what we mean by "functionally correct" or > "quality" code. If determination of functional correctness > were extended from "must operate as specified under expected > conditions" to "must operate as specified under all > conditions", functional correctness would necessarily require > security, safety, fault tolerance, and all those other good > things that make software dependable instead of just correct. > > > I couldn't agree more! > > However, I have had several discussions with a colleague who is fairly > well known in the"Software Process Improvement Mafia" on the topic of > how to ensure that security requirements are considered for > _all_ kinds > of code, not just "security software". Particularily in the context of > agile development techniques, security keeps getting the short end of > the stick, losing every time to "working features". His stance on this > is that "if security were important to the customer, the > customer would > provide and prioritize security requirements". To me, this is > a bit like > saying "If the customer doesn't explicitly state that the software > should be Y2k-proof, he/she is not really bothered about it". The problem (certainly as I see it) is that the customer is likely to say "Make it secure" without really understanding what that means. Secure against what exactly? Or you'll get a list of security features that the customer wants, but as we all know security features != secure product. Instead we've taken a combined approach of including customer requirements and adding specific requirements of our own focusing a good Secure development practices. > If we can "brainwash" the coming generations of programmers into > accepting Karen's definition of "quality code", we might finally be > getting somewhere. And that's the trick we've been attempting here. Secure software is nothing more than really good quality code. We already use coding guidelines and have a strong(ish) process of code reviews. So we have augmented our coding and review guidelines to include secure coding aspect such as input/output validation, good memory management etc. That said there is still a lot of scope for improvement in the rest of the software development process (testing and design in particular). CJC From floodeen at gmail.com Fri Aug 21 11:02:30 2009 From: floodeen at gmail.com (Rob Floodeen) Date: Fri, 21 Aug 2009 11:02:30 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> Message-ID: <2f1215010908210802v79e79bd1lf468f075998f1ca5@mail.gmail.com> Gary wrote: "He and I discuss the notion of education versus training at length" And I don't want to bring up the discussion of the difference, however it does get me to think. In CS, we do a lot of Math, but programming is not like Math. Math is easy to verify if it is done correctly. But in programing what does correctly mean? So it has to be taught and incorporated in it's own way. I think a way ahead should consider the following: 1. the instructional staff reads all the code, all the time (But think of how long this would take) 2. a formal method for deducting points from a properly working but incorrectly constructed program (a "Show your work" secure coding equivalent) 3. a capability to verify and reinforce good practices consistently and continually Of course we can teach a class on best practices, things not to do, etc. etc. But how do we continually reinforce it throughout a curriculum or even a career? -Rob Floodeen On Thu, Aug 20, 2009 at 2:55 PM, Gary McGraw wrote: > hi neil, > > For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of "Software Security" . ?Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since then. > > * University of California at Davis > * University of Virginia > * Johns Hopkins University > * Princeton University > * Purdue University (especially the CERIAS center) > * Rice University > * University of California at Berkeley > * Stanford University > * Naval Postgraduate School (a military school for graduates) > * University of Idaho > * Iowa State University > * George Washington University > * United States Military Academy at West Point > > Matt Bishop made some excellent points in this thread. ?He and I discuss the notion of education versus training at length in Silver Bullet episode 31 part of which was transcribed here . > > gem > > company www.cigital.com > book www.swsec.com > > > On 8/19/09 5:15 PM, "Neil Matatall" wrote: > > Inspired by the "What is the size of this list?" discussion, I decided I won't be a lurker :) > > A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions > > So where does secure coding belong in the curriculum? > > Higher Ed? ?High School? > > Undergrad? Grad? Extension? > > I started a discussion in the Educause group on linked in. ?I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=138011&discussionID=5737656 > > It looks like some Universities are offering courses now... > > Neil > > > _______________________________________________ > 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 Fri Aug 21 11:23:16 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Fri, 21 Aug 2009 08:23:16 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8C6B78.2080608@uci.edu> References: <4A8C6B78.2080608@uci.edu> Message-ID: <490a979e0908210823m2a1b28cdj672f973315794d58@mail.gmail.com> On Wed, Aug 19, 2009 at 2:15 PM, Neil Matatall wrote: > Inspired by the "What is the size of this list?" discussion, I decided I > won't be a lurker :) > > A question prompted by > http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html > and the OWASP podcast mentions > > So where does secure coding belong in the curriculum? > > Higher Ed?? High School? > > Undergrad? Grad? Extension? Does it help at all to consider how and where most people actually learn to program/develop? I don't have percentages handy of how many people with a job title or informal role as "programmer" or "developer" actually took any formal education in this. If we're just trying to reach the group of developers that went through formal training then we've seen some pretty good answers here in this thread already. If we want to cover others though, we need to look elsewhere. Let's look at another few fields where safety is important and yet the work is often done by both professionals and amateurs - Plumbing and/or Electrical Work. My own view is that much software development is actually a lot closer to the work of the amateur electrician than the professional electrician. That is, unlike fields like engineer, architect, lawyer, accountant, we don't rely on professional standards, degrees, certifications, etc. for most programmers. I'm leaving aside for a moment whether we can or should, and just pointing out that it is the case. In the case of the amateur electrician you'll find a wide variety in their knowledge of safety concerns, adherence to code, etc. They probably know enough to not electrocute themselves while they are working (though not always) but don't necessarily know enough to put in wiring that won't burn their house down in a few years. I think our real question isn't just how to reach the "professional" programmer trained via formal training programs, but also how to reach the "amateur" programmer trained via books, trial+error, etc. In these cases the best bet is to make sure that the general training manuals, how-to guides, etc. have a lot of safety/security information included in them. That the books people use to learn actually show them safe examples, etc. Obviously there are variations of code requirements per location and such, but basic safety rules will probably be mostly universal. - Andy From gunnar at arctecgroup.net Fri Aug 21 11:30:02 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 21 Aug 2009 10:30:02 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <4A8E903F.1030007@comcast.net> Message-ID: > I think we need to start indoctrinating kids in the womb. Start > selling Baby Schneier CDs alongside Baby Mozart. :) > I can recommend this book, it was given to me by a client. Enigma: A Magical Mystery "Grade 3?6?Someone has stolen the props belonging to the residents of a retirement home for magicians, and Bertie Badger, the grandson of one of the illusionists, vows to find them. As he meets the performers, they each tell him a little about their specialty and what's missing. "My top hat, cape, and wand have gone, but there is worse to tell:/My precious magic bunny rabbit's disappeared as well!" Bertie discovers the thief, but it is left to readers to find the lost items hidden in the illustrations. Base's visual mystery books have delighted children for years, but this one has the added feature of a moving panel in the back cover that reveals a secret code. Children must turn dials to proper settings before it can be moved. The clues for setting them appear in the illustrations but are not at all obvious. With a little persistence, however, the target audience should be able to solve the puzzle. After readers crack the code, they can search for the missing items hidden in the art and decipher other messages found in the end matter. " http://www.amazon.com/Enigma-Magical-Mystery-Graeme-Base/dp/081097245X -gunnar From Kevin.Wall at qwest.com Fri Aug 21 11:38:36 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Fri, 21 Aug 2009 10:38:36 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <4A8E903F.1030007@comcast.net>, Message-ID: Karen Goertzel wrote... > I think we need to start indoctrinating kids in the womb. Start selling Baby Schneier CDs alongside Baby Mozart. :) Yeah, I can hardly wait to hear Schneier's remake of that Dr. Seuss children's classic One Fish, Twofish, Red Fish, Blowfish -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME From andrews at rbacomm.com Fri Aug 21 11:41:27 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 10:41:27 -0500 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Your message of Thu, 20 Aug 2009 09:41:11 -0700, Message-ID: <20090821104127.di7eute4m8gowsgo@webmail.rbacomm.com> I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can "prove" programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a "flawless" piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Goertzel, Karen [USA]" : > Interesting. My definition of "secure" is for software is > "dependable, trustworthy, and survivable (or, if you prefer, > resilient)", i.e., > > (1) It's got to behave correctly and predictably; > > (2) It's got to behave non-maliciously and also not be subvertible > (i.e., no weaknesses that can be exploited as vulnerabilities); > > (3) When it comes under attack, 1 & 2 need to hold true for as long > as possible before the software's execution gracefully degrades and > ultimately fails; when it does fail, it must do so in a manner that > doesn't make it, its data, or its resources vulnerable to further > compromise, and it must recover to an acceptable level of operation > (which, obviously, needs to be specified) as quickly as possible, > with as little damage as possible (and having minimised the extent > of that damage). > > Obviously, there's very little software that can satisfy all three > of these criteria 100%. But even 50% is better than 0%. From andrews at rbacomm.com Fri Aug 21 11:51:55 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 10:51:55 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8E903F.1030007@comcast.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> Message-ID: <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> Has anyone who holds to this taught a beginning level programming class? Getting students to understand what a loop is can be hard enough, given limited time. Diving into exploits and buffer overflows can be much more difficult. I am sure some things could be put into a basic class, but the ideas are a bit deeper. Security at the "Hello World!" or Mortgage Calculator program level seems quite difficult. This bears some thinking through, but the security risks seem to be: - Make sure the input amount is in dollars. - Make sure the term is numeric and within "reasonable" ranges. - Make sure that interest rate is in the form of XX.XX. Other things checked for would be - Proper output. - Pausing at the right point so the output can be viewed correctly. I am sure I am missing things, but this should serve as a base. Where do you inject security there? Sure, you can note the importance of checking the data, but just because someone checks the input here doesn't mean they will have a clue on checking the input on a web form for an SQL injection attempt. I get students who can't loop to start over, they are certainly not going to catch that they need to do deeper input inspection, especially in a completely unrelated topic. I am probably blowing some smoke here and I may disagree with myself later, but I think this discussion is worth having. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Mike Lyman : > Neil Matatall wrote: >> So where does secure coding belong in the curriculum? >> >> Higher Ed? High School? >> >> Undergrad? Grad? Extension? > > Secure coding needs to be taught anytime programing is taught. > >> From my experience in my son's boy scout troop, I'm not sure I'd call it > out as security and confuse middle school/junior high school students > but I'd teach them basics like input validation and bounds checking as > basic good programing. The security aspects can wait until later when > they can better handle several concepts at once. > > After that is just needs to be part of the course and called out for > what it is. There is room for stand alone security focused training and > courses but it needs to be drilled in all along the way. I recall my own > computer science instructors telling us *not* to spend time on bells and > whistles and concentrate on the concept the lesson was covering. If the > lesson was on pointers, adding things like error checking and user > friendly features didn't count for anything. I can understand why that > was said but it sends the wrong message and begins the development of > bad habits. That was 20 to 30 years ago and most computer users' idea of > security was locking their car doors but it did set us up for bad > habits. Basics need to be drilled in early and always count for > something even if the lesson is while loops. > -- > > 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 andrews at rbacomm.com Fri Aug 21 11:54:56 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 10:54:56 -0500 Subject: [SC-L] Functional Correctness In-Reply-To: <2D3692016CCD2D4AA33741E25925EA7102EFBB08@BUDMLVEM06.e2k.ad.ge.com> References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> <4A8DA7EE.5000006@sislab.no> <2D3692016CCD2D4AA33741E25925EA7102EFBB08@BUDMLVEM06.e2k.ad.ge.com> Message-ID: <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> I completely agree, though how are we really going to reach this point? We have been talking about this at least since I got into development in the early 1980s. We are not anywhere closer, though we have lots of neat tools that do lots of neat stuff. Unfortunately, our programs are also a lot more complicated, making the "correct" proof much more difficult. Can we really believe it is "just around the corner" to prove this? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Cassidy, Colin (GE Infra, Energy)" : > Martin Gilje Jaatun wrote: > >> Karen, Matt & all, >> >> Goertzel, Karen [USA] wrote: >> > I'm more devious. I think what needs to happen is that we >> need to redefine what we mean by "functionally correct" or >> "quality" code. From andrews at rbacomm.com Fri Aug 21 12:08:32 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 11:08:32 -0500 Subject: [SC-L] Customer Demand In-Reply-To: <4A8DA7EE.5000006@sislab.no> References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> <4A8DA7EE.5000006@sislab.no> Message-ID: <20090821110832.8lk2au0ijo4gs4kk@webmail.rbacomm.com> While no customer is likely to say they don't care about software working now that we are past Y2K, they don't think about it at all and are unlikely to allow any schedule slippage to allow for making sure that is true. Customers only really care about the things they will pay for. Many companies claim they "can't stand" poor software or services, but they still pay for them, so they will keep getting them. Until we convince them that good security really is important and that they must demand and pay for it, we won't make the progress we want to make. How many companies wouldn't even be doing the PCI level of effort if they weren't forced to do so? How many strictly limit it to their "PCI environment" rather than looking at the risk to the whole enterprise? Even major breaches don't help since the "it can't happen here" attitude is common all over, in spite of the fact it is a risky stance. While part of this is just a cynical rant, I think the base point is that we have a whole lot more selling to do on the need for software security before we can properly place it throughout the curriculum. That sales job is hard. The fact a few people have "gotten it" doesn't mean most have or that we are completely ready for the next step. I realize many here may not be saying that, but that is the message I get stepping back. And I am a dreamer/visionary. I like to think well ahead of things, but focusing too much there makes us likely to continue to be a niche area, leaving lots of vulnerabilities. Wouldn't a better focus be on the customer demand end? Stirring that up will do more to advance secure development than any number of maturity models. Unfortunately, it is a much more difficult task. I would bet it is also not as conceptually interesting to many. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Martin Gilje Jaatun : > His stance on this > is that "if security were important to the customer, the customer would > provide and prioritize security requirements". To me, this is a bit like > saying "If the customer doesn't explicitly state that the software > should be Y2k-proof, he/she is not really bothered about it". From andrews at rbacomm.com Fri Aug 21 12:18:11 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 11:18:11 -0500 Subject: [SC-L] Grading Secure Programs In-Reply-To: <2f1215010908210802v79e79bd1lf468f075998f1ca5@mail.gmail.com> References: <4A8C6B78.2080608@uci.edu> <2f1215010908210802v79e79bd1lf468f075998f1ca5@mail.gmail.com> Message-ID: <20090821111811.dxezejwoz4s8c00s@webmail.rbacomm.com> This brings up a great point. How can we grade a program's security level? Is it just a checkoff list? Which elements should be in that checkoff list? The worst part of teaching is grading papers (programs are a close second). Making that more complicated is not likely to work. I already spend more time than I want on it, how are you going to convince me to spend more time looking for "secure programs"? It won't happen. (10 seconds grading would be too long, so "enough time" is a relative rather than an absolute time.) This also ties back to what things you can really look for in most instructional programs, though this would depend on the level of the class. Still, if you are going to require a solid mathematical algorithm, you had better have spent some time going over how to implement mathematical algorithms in code. In the same way, if you want a student to check against SQL injection, you have to have taught that at some point. (Neither have to be in the same class, but they must be prerequisites and likely part of a lower level class.) Curious question: How many proclaiming "weave it into the curriculum" have worked with many lower-level classes as an instructor? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Rob Floodeen : > 2. a formal method for deducting points from a properly working but > incorrectly constructed program (a "Show your work" secure coding > equivalent) From rcs at cert.org Fri Aug 21 13:08:52 2009 From: rcs at cert.org (Robert Seacord) Date: Fri, 21 Aug 2009 13:08:52 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A8DAF1B.6080401@uci.edu> References: <4A8C6B78.2080608@uci.edu>, <4A8DAF1B.6080401@uci.edu> Message-ID: Neil, I teach two software security classes at Carnegie Mellon: CS 15392 Secure Programming - Undergraduate Computer Science https://www.securecoding.cert.org/confluence/display/sci/S08+15392+Secure+Programming INI 14735 Secure Software Engineering - Graduate Course in Information Networking Institute (INI) The INI materials are on our blackboard system and harder to share, but much of the material is the same as the undergraduate course. If your (or anyone else) is interested in teaching this course (or portions of this course) at your college or university I would be happy to share the power point slides and other course materials with you. However, because the SEI offers a 4 day version of this course to professional audiences (see http://www.sei.cmu.edu/products/courses/p63.html), as well as licensing this course to organizations to provide this training, this offer only applies to higher education and not to professional education. Thanks, rCs ---- Robert C. Seacord Secure Coding Team Lead CERT / Software Engineering Institute Work: +1 412.268.7608 FAX: +1 412.268.6989 From gem at cigital.com Fri Aug 21 14:51:32 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 21 Aug 2009 14:51:32 -0400 Subject: [SC-L] Silver Bullet: Fred Schneider Message-ID: hi sc-l, The 41st epsiode of Silver Bullet just went live. This episode features a conversation with Fred Schneider, a computer sceince professor at Cornell and a very important thought leader in security research. Fred was the author of the seminal National Academies study "Trust in Cyberspace". We talk about the relationship between reliability and security, about fault tolerant systems, and about diversity as a security mechanism. We also talk about writing secure code, outlawing C, and the end of the age of bugs. Fred brings up the idea of categories of attack and the evolution of attacks from configuration, through bugs, to flaws and finally to trust problems. http://www.cigital.com/silverbullet/show-041/ Fred is particularly well spoken and cogent, and it was a great privilege to chat about security with him. As always, your feedback is welcome. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From gunnar at arctecgroup.net Fri Aug 21 15:44:17 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 21 Aug 2009 14:44:17 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> Message-ID: > I am sure some things could be put into a basic class, but the ideas > are a bit deeper. Security at the "Hello World!" or Mortgage > Calculator program level seems quite difficult. > I am not so sure. Granted an entry level programmer is going to be an expert, but they can be pretty effective. I have taught App Security classes where there were people with 20+ years of programming experience and people with 3 months of OJT programming experience. At the end of the two day class they each had the exact same amount of App Security training. The basic concepts of AAA and so on are not so hard to understand. My guess is its much harder to start with Hello World, with no security, add layers and layers of stuff on top of that over the decades and then have to go back and question every single thing... Someone who spent 20 years building cars with no brakes would have a different experience than someone who was taught from the get go that all cars have brakes and here is how you design/build them. -gunnar From gem at cigital.com Fri Aug 21 15:43:36 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 21 Aug 2009 15:43:36 -0400 Subject: [SC-L] Functional Correctness In-Reply-To: <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> Message-ID: hi sc-l, There are many important security researchers who have given up on proving things about software as non-practical. Among them: Ross Anderson, Virgil Gligor, Bob Blakely, and Fred Schneider. All four of those guys have been past silver bullet victims, and each time we discussed the antiquated notion of formal approaches to software development. Software security is an intensely practical problem that will require a practical approach. By studying organizations that are doing a decent job, perhaps we can draw some practical lessons. That's precisely what we're up to with the BSIMM . gem http://www.cigital.com/~gem On 8/21/09 11:54 AM, "Brad Andrews" wrote: I completely agree, though how are we really going to reach this point? We have been talking about this at least since I got into development in the early 1980s. We are not anywhere closer, though we have lots of neat tools that do lots of neat stuff. Unfortunately, our programs are also a lot more complicated, making the "correct" proof much more difficult. Can we really believe it is "just around the corner" to prove this? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Cassidy, Colin (GE Infra, Energy)" : > Martin Gilje Jaatun wrote: > >> Karen, Matt & all, >> >> Goertzel, Karen [USA] wrote: >> > I'm more devious. I think what needs to happen is that we >> need to redefine what we mean by "functionally correct" or >> "quality" code. _______________________________________________ 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 Stephan.Neuhaus at disi.unitn.it Fri Aug 21 15:35:19 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Fri, 21 Aug 2009 21:35:19 +0200 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> Message-ID: <06B9BA41-CCB9-43C5-BCF5-7BE5ACCE4FD9@disi.unitn.it> On Aug 21, 2009, at 17:51, Brad Andrews wrote: > Has anyone who holds to this taught a beginning level programming > class? I have. I taught a security class to undergrads. It was easier than I thought, at least the basics were. I got them excited by a "let's try to break things" attitude. They wrote buffer overflow exploits (using freely available shellcode), they cracked linear congruential PRNGs, they subverted insecure protocols. As far as I can tell, they had a good time, since I had the highest retention rate for optional courses in that year: 40 signed up for the course and 39 took the final exam. Once they understood that the right mind-set is not "oh come on, what can possibly go wrong?" but "okay, let's see what *can* go wrong", they were on their way. Stephan From goertzel_karen at bah.com Fri Aug 21 16:05:46 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 21 Aug 2009 16:05:46 -0400 Subject: [SC-L] Customer Demand In-Reply-To: <20090821110832.8lk2au0ijo4gs4kk@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> <4A8DA7EE.5000006@sislab.no>, <20090821110832.8lk2au0ijo4gs4kk@webmail.rbacomm.com> Message-ID: I think we need a multifaceted approach that includes supply side, demand side, insurance companies, consumer protection organisations, etc. etc. We need regulation with legal penalties - as exist for airlines, for example - for software firms that fail to meet minimal standards for quality - which must be defined to include security (using demonstrated linkages to existing legislation as a catalyst - i.e., non-secure software makes it impossible to be HIPPA, FISMA, SOX, PCI, etc. compliant). We need a system of evaluation (like Good Housekeeping seal of approval, but NOT like Common Criteria) for consumers to be able to easily determine which software meets the minimum standards for "goodness". We need the insurance firms that are now offering security and CIP related products to add software security criteria to their definitions, so that their customers who buy demonstrably secure software get breaks on their premiums, and those that willfully engage in risky behaviours - i.e., persisting in use of bad software - are penalised by higher premiums or, ultimately, having their coverage dropped. We need to educate end users as we did with seatbelts and cigarettes - a series of really good public service advertisements that clearly and engagingly depict what happens as a result of AVOIDABLE (by developers) security-related failings in software. With outlets like YouTube, the budget to broadcast such advertisements would be significantly smaller than it would have been when only the media outlets were big commercial networks. Just some ideas - no doubt some better than others. The real message is "Yes, we need to change consumer behaviour" - but that alone won't get us where we need to go. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews [andrews at rbacomm.com] Sent: Friday, August 21, 2009 12:08 PM To: sc-l at securecoding.org Subject: [SC-L] Customer Demand While no customer is likely to say they don't care about software working now that we are past Y2K, they don't think about it at all and are unlikely to allow any schedule slippage to allow for making sure that is true. Customers only really care about the things they will pay for. Many companies claim they "can't stand" poor software or services, but they still pay for them, so they will keep getting them. Until we convince them that good security really is important and that they must demand and pay for it, we won't make the progress we want to make. How many companies wouldn't even be doing the PCI level of effort if they weren't forced to do so? How many strictly limit it to their "PCI environment" rather than looking at the risk to the whole enterprise? Even major breaches don't help since the "it can't happen here" attitude is common all over, in spite of the fact it is a risky stance. While part of this is just a cynical rant, I think the base point is that we have a whole lot more selling to do on the need for software security before we can properly place it throughout the curriculum. That sales job is hard. The fact a few people have "gotten it" doesn't mean most have or that we are completely ready for the next step. I realize many here may not be saying that, but that is the message I get stepping back. And I am a dreamer/visionary. I like to think well ahead of things, but focusing too much there makes us likely to continue to be a niche area, leaving lots of vulnerabilities. Wouldn't a better focus be on the customer demand end? Stirring that up will do more to advance secure development than any number of maturity models. Unfortunately, it is a much more difficult task. I would bet it is also not as conceptually interesting to many. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Martin Gilje Jaatun : > His stance on this > is that "if security were important to the customer, the customer would > provide and prioritize security requirements". To me, this is a bit like > saying "If the customer doesn't explicitly state that the software > should be Y2k-proof, he/she is not really bothered about it". _______________________________________________ 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 jjchryan at gwu.edu Fri Aug 21 16:05:41 2009 From: jjchryan at gwu.edu (Julie J.C.H. Ryan, D.Sc.) Date: Fri, 21 Aug 2009 16:05:41 -0400 Subject: [SC-L] Grading Secure Programs In-Reply-To: <20090821111811.dxezejwoz4s8c00s@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <2f1215010908210802v79e79bd1lf468f075998f1ca5@mail.gmail.com> <20090821111811.dxezejwoz4s8c00s@webmail.rbacomm.com> Message-ID: <6D291B98-F7C3-4650-BB29-A013402091B9@gwu.edu> On Aug 21, 2009, at 12:18 PM, Brad Andrews wrote: > > This brings up a great point. How can we grade a program's security > level? Is it just a checkoff list? Which elements should be in > that checkoff list? > You may be interested in reading: Teaching Secure Programming IEEE Security and Privacy archive Volume 3 , Issue 5 (September 2005) table of contents Pages: 54 - 56 Year of Publication: 2005 ISSN:1540-7993 Authors Matt Bishop University of California, Davis Deborah A. Frincke Pacific Northwest National Laboratory Publisher IEEE Educational Activities Department Piscataway, NJ, USA From andrews at rbacomm.com Fri Aug 21 16:11:13 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 15:11:13 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <06B9BA41-CCB9-43C5-BCF5-7BE5ACCE4FD9@disi.unitn.it> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <06B9BA41-CCB9-43C5-BCF5-7BE5ACCE4FD9@disi.unitn.it> Message-ID: <20090821151113.ldn29mu6g4wokwk8@webmail.rbacomm.com> I was thinking of a beginner-level programming class. I have and it can be a challenge, especially if they don't have the "programming mindset". Even if they do, you don't have the time for the things you spoke about. You are focusing on basic coding constructs first. :) -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Stephan Neuhaus : > > On Aug 21, 2009, at 17:51, Brad Andrews wrote: > >> Has anyone who holds to this taught a beginning level programming class? > > I have. I taught a security class to undergrads. It was easier than I > thought, at least the basics were. I got them excited by a "let's try > to break things" attitude. They wrote buffer overflow exploits (using > freely available shellcode), they cracked linear congruential PRNGs, > they subverted insecure protocols. As far as I can tell, they had a > good time, since I had the highest retention rate for optional courses > in that year: 40 signed up for the course and 39 took the final exam. > > Once they understood that the right mind-set is not "oh come on, what > can possibly go wrong?" but "okay, let's see what *can* go wrong", they > were on their way. > > Stephan From goertzel_karen at bah.com Fri Aug 21 16:24:05 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Fri, 21 Aug 2009 16:24:05 -0400 Subject: [SC-L] What is the size of this list? In-Reply-To: <20090821104127.di7eute4m8gowsgo@webmail.rbacomm.com> References: Your message of Thu, 20 Aug 2009 09:41:11 -0700, , <20090821104127.di7eute4m8gowsgo@webmail.rbacomm.com> Message-ID: Actually, we can't prove programs are bug free if by "bug" we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt G?del with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything "right" in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews [andrews at rbacomm.com] Sent: Friday, August 21, 2009 11:41 AM To: sc-l at securecoding.org Subject: Re: [SC-L] What is the size of this list? I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can "prove" programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a "flawless" piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI [snippety snip] From andrews at rbacomm.com Fri Aug 21 16:18:09 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 15:18:09 -0500 Subject: [SC-L] Functional Correctness In-Reply-To: References: Message-ID: <20090821151809.s5cc5u5jc0gwwwc4@webmail.rbacomm.com> Now that you mention it.... I was listening to the CERT podcast where you and a couple of others discussed the BSIMM (probably a while back since I am well behind on those). You made a statement along these lines and I immediately thought that I disagreed! :) I don't think software security is as simple as that. I do agree that companies can (and should) do far more than they do and that many things could be eliminated with very mechanical fixes, but I don't think that gives a good long-term perspective. I also think that it will set management's expectation at a level that will ultimately be harmful. After all, we can just "implement this maturity model and eliminate all our security problems, at least in the application, right?" That is likely to end up resulting in even more resistance in the future when management questions why they need to keep spending more for software security, a secure architecture, etc. Don't people learn what they need to know at some point? I don't think we will ever be static. As soon as we remove the low hanging fruit, the fruit higher up the tree will be the problem. This isn't to say a maturity model is useless, but I remain skeptical that it will live up to the "hype" (low key now, but there) it is being presented with. I am sure this is not as smoothly presented as it needs to be, but I am fairly certain of the general thrust of my conviction. I suppose 20+ in software development helps. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Gary McGraw : > Software security is an intensely practical problem that will > require a practical approach. By studying organizations that are > doing a decent job, perhaps we can draw some practical lessons. > That's precisely what we're up to with the BSIMM . From andrews at rbacomm.com Fri Aug 21 16:24:07 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 15:24:07 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> Message-ID: <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> But we are not talking about separate classes. The assertion (which I probably clipped, sorry) was that it should be woven into the curriculum. I was noting where and how to do so, starting in the intro level classes. Just telling a starting programmer to properly check input length is all well and good, but falls far short of making a secure programmer. I have no doubt that you can teach some new developers the principles in a short time and make them more productive than those who have been programming longer term. They don't have to unlearn anything! But this will not work for everyone. Some will sit through a class with glazed eyes and no understanding. Also remember we will have to get outside those with a fairly high level of motivation (internal or external) for learning the material to be successful. I also would like to see how you would teach secure development, with minimal extra time load, in a basic programming sequence, possibly even at a non-traditional or lower tier school. We won't make significant progress until we can do that, and it still leaves out the "self taught." -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Gunnar Peterson : >> I am sure some things could be put into a basic class, but the >> ideas are a bit deeper. Security at the "Hello World!" or Mortgage >> Calculator program level seems quite difficult. >> > > I am not so sure. Granted an entry level programmer is going to be an > expert, but they can be pretty effective. I have taught App Security > classes where there were people with 20+ years of programming > experience and people with 3 months of OJT programming experience. At > the end of the two day class they each had the exact same amount of App > Security training. > > The basic concepts of AAA and so on are not so hard to understand. My > guess is its much harder to start with Hello World, with no security, > add layers and layers of stuff on top of that over the decades and then > have to go back and question every single thing... > > Someone who spent 20 years building cars with no brakes would have a > different experience than someone who was taught from the get go that > all cars have brakes and here is how you design/build them. From jim at manico.net Fri Aug 21 16:28:20 2009 From: jim at manico.net (Jim Manico) Date: Fri, 21 Aug 2009 16:28:20 -0400 Subject: [SC-L] Functional Correctness In-Reply-To: <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> <4A8DA7EE.5000006@sislab.no> <2D3692016CCD2D4AA33741E25925EA7102EFBB08@BUDMLVEM06.e2k.ad.ge.com> <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> Message-ID: <9BED64B4-2195-47B2-91BA-1E67CEC71C09@manico.net> We are approaching huge industry-wide application security critical mass for the first time. Now is the time to strike. If all we teach is input validation+canonicalization, query parameterization, and output encoding, we stop xss and sqli via education Jim Manico On Aug 21, 2009, at 11:54 AM, Brad Andrews wrote: > > I completely agree, though how are we really going to reach this > point? We have been talking about this at least since I got into > development in the early 1980s. We are not anywhere closer, though > we have lots of neat tools that do lots of neat stuff. > Unfortunately, our programs are also a lot more complicated, making > the "correct" proof much more difficult. > > Can we really believe it is "just around the corner" to prove this? > > -- > > Brad Andrews > RBA Communications > CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI > > > Quoting "Cassidy, Colin (GE Infra, Energy)" : > >> Martin Gilje Jaatun wrote: >> >>> Karen, Matt & all, >>> >>> Goertzel, Karen [USA] wrote: >>> > I'm more devious. I think what needs to happen is that we >>> need to redefine what we mean by "functionally correct" or >>> "quality" code. > _______________________________________________ > 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 andrews at rbacomm.com Fri Aug 21 16:35:39 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 15:35:39 -0500 Subject: [SC-L] Customer Demand In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <21c655860908200857pfe5e6c8pb08ae777f15c8389@mail.gmail.com> <4A8DA7EE.5000006@sislab.no>, <20090821110832.8lk2au0ijo4gs4kk@webmail.rbacomm.com> Message-ID: <20090821153539.52z68gii0488gskg@webmail.rbacomm.com> Regulation will never be as effective as we need and I believe will ultimately be counterproductive as many companies use "compliant" as an excuse to stop. (It may get them to start, but once started, we need them to go farther.) In regards to cigarettes, they are still a huge problem in many places. Many become hooked all the time, in spite of all the education and efforts. It has been far from effective. Sure it isn't hip to smoke in some circles, but not all circles feel that way. The analogy would be interesting to explore. - Writing insecure code does give an addictive rush - you can do it faster! (Smoking produces a positive experience, at least at some point.) - Peer support is there - since most of a developer's peers are unlikely to develop securely. (Peers push smoking, regardless of the messages "society" sends.) - Taxing it won't eliminate it - both will become a "cost of doing business" for some. As to seatbelts - the same problem persists. We wouldn't need programs like "click-it or ticket" if past communications were successful. I could go into details, but I don't want to argue the seatbelt issue. The main factor is that I don't trust government to push much of anything successfully. It may do some things, but it is incredibly inefficient most of the time. :) Your point about insurance is reasonable, though insurance companies will have to decide they are going to do that for their own self-interest before it is effective. Even then, we may end up with something like the modern health care system (including lots of unnecessary tests) rather than security nirvana. I agree that changing consumer behavior is not sufficient, but it is necessary. The other stuff will not work without it. Look at our modern "war on drugs" (including tobacco). Changing demand is key, not supply. People will write secure code when those who drive them (ultimately the customer) demand it. Even if I am an enlightened CEO, I am not going to survive and thrive writing secure code if doing so makes me cost more than a competitor without giving me a clear, fairly immediate business advantage - that same demand. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Goertzel, Karen [USA]" : > I think we need a multifaceted approach that includes supply side, > demand side, insurance companies, consumer protection organisations, > etc. etc. > > We need regulation with legal penalties - as exist for airlines, for > example - for software firms that fail to meet minimal standards > for quality - which must be defined to include security (using > demonstrated linkages to existing legislation as a catalyst - i.e., > non-secure software makes it impossible to be HIPPA, FISMA, SOX, > PCI, etc. compliant). > > We need a system of evaluation (like Good Housekeeping seal of > approval, but NOT like Common Criteria) for consumers to be able to > easily determine which software meets the minimum standards for > "goodness". > > We need the insurance firms that are now offering security and CIP > related products to add software security criteria to their > definitions, so that their customers who buy demonstrably secure > software get breaks on their premiums, and those that willfully > engage in risky behaviours - i.e., persisting in use of bad software > - are penalised by higher premiums or, ultimately, having their > coverage dropped. > > We need to educate end users as we did with seatbelts and cigarettes > - a series of really good public service advertisements that > clearly and engagingly depict what happens as a result of AVOIDABLE > (by developers) security-related failings in software. With outlets > like YouTube, the budget to broadcast such advertisements would be > significantly smaller than it would have been when only the media > outlets were big commercial networks. > > Just some ideas - no doubt some better than others. The real message > is "Yes, we need to change consumer behaviour" - but that alone > won't get us where we need to go. From andrews at rbacomm.com Fri Aug 21 16:50:44 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Fri, 21 Aug 2009 15:50:44 -0500 Subject: [SC-L] What is the size of this list? In-Reply-To: References: Your message of Thu, 20 Aug 2009 09:41:11 -0700, , <20090821104127.di7eute4m8gowsgo@webmail.rbacomm.com> Message-ID: <20090821155044.imou76h484c4404c@webmail.rbacomm.com> Great points Karen! We can't prove a program is "secure" in the same vein. The danger I am spouting off about is the idea that we would solve the software security problem if we just take a more "scientific" or "mature" (or whatever) approach. I think those can definitely reduce the risk, but I don't think it will reach the goal. I am all for getting 50% of the way there. That is a lot better than being 0% or even 25% of the way there! I am just VERY concerned that if we try to sell management the idea that we are now taking a "scientific" approach (or whatever the term), we will end up with implied promises that will lead them to expect perfection, which won't come. They will likely ignore all our disclaimers that we are only seeking a partial solution to what we can solve, at least in the current state of thinking. Getting them to even take any action is a challenge in many companies, so some could argue my concerns are foolish. I think they are important because you want to make sure any buy-in you eventually get expects the right things. If you don't do this, you will end up in an even worse position down the road. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Goertzel, Karen [USA]" : > Actually, we can't prove programs are bug free if by "bug" we also > mean all possible anomalous behaviours. My colleagues keep pointing > this out to me when I suggest that we should start leveraging the > computational power of computing grids to analyze complex software > the same way other researchers are using grids to develop models of > the natural world, the human genome, etc. They keep quoting that > bloke Kurt G?del with his pesky little incompletness theorem as > proof that 100% complete analysis of software cannot be done. > Frankly, I'm beginning to think this is their excuse for not even > trying to get me to the 50%. But the point is, even if you can do > everything "right" in terms of building software to be > vulnerability-free and behaviourally-benign, you apparently cannot > achieve 100% verification that you've done so. Ergo, assurance can > never be 100%. From James.McGovern at thehartford.com Fri Aug 21 17:20:57 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Fri, 21 Aug 2009 17:20:57 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu>, <4A8E903F.1030007@comcast.net> Message-ID: Are there any industry metrics that indicate what percentage of full-time software developers actually learned coding in a university setting? I actually learned in high-school, focused on business administration in college (easiest major on the planet) and learned/matured on the job. Likewise, I also am surrounded by many folks who have been in IT for say 30 or so years that learned coding from those infomercial type schools you see on TV late at night. So, the question of whether trade schools should teach secure coding should be asked as well. ************************************************************ 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 mlyman-cissp at comcast.net Fri Aug 21 19:13:50 2009 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Fri, 21 Aug 2009 18:13:50 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <490a979e0908210823m2a1b28cdj672f973315794d58@mail.gmail.com> References: <4A8C6B78.2080608@uci.edu> <490a979e0908210823m2a1b28cdj672f973315794d58@mail.gmail.com> Message-ID: <4A8F2A2E.4070907@comcast.net> Andy Steingruebl wrote: > I think our real question isn't just how to reach the "professional" > programmer trained via formal training programs, but also how to reach > the "amateur" programmer trained via books, trial+error, etc. > > One area here is making sure examples are done correctly. The database examples that connected to an MS SQL server with userid=SA;password="" used to drive me crazy. "The sample code does it that way so I better do it that way." It makes for more complicated sample code but it may be the only way to reach these self taught folks. -- Mike Lyman mlyman at west-point.org From mlyman-cissp at comcast.net Fri Aug 21 19:26:49 2009 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Fri, 21 Aug 2009 18:26:49 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> Message-ID: <4A8F2D39.3040305@comcast.net> Brad Andrews wrote: > Has anyone who holds to this taught a beginning level programming > class? Getting students to understand what a loop is can be hard > enough, given limited time. Diving into exploits and buffer overflows > can be much more difficult. Getting into exploits at this level is probably more than many can handle but it's not a bad time to teach proper bounds checking and making sure any math operations don't result in overflows. Part of the lesson might even be to create loops with math that cause these errors deliberately if students are no longer taught how numbers are represented in memory and what happens when you exceed the limits directly. Might not be a bad idea though to step back on basic courses and rather than dive in to programing concepts right away start with some demonstrations of what happens with bad code and follow up with refreshers periodically through the course. Nothing in great depth unless the students can handle it but showing them what happens after coding errors might raise awareness and start them thinking what happens when this breaks rather than strictly focusing on how do it get it to work. I cringe at the thought of what I used to do in code based on the habits that started in high school and college. > I am sure some things could be put into a basic class, but the ideas > are a bit deeper. Security at the "Hello World!" or Mortgage > Calculator program level seems quite difficult. > > This bears some thinking through, but the security risks seem to be: > > - Make sure the input amount is in dollars. > - Make sure the term is numeric and within "reasonable" ranges. > - Make sure that interest rate is in the form of XX.XX. That's a great start at getting them to think about how they have to treat input and validate it. I don't recall any of my instructors ever focusing on making sure the input to anything is what was expected. I'm sure some did but I don't recall it. Even if the students don't always get it right at this point, get them started thinking about it. > Where do you inject security there? Sure, you can note the importance > of checking the data, but just because someone checks the input here > doesn't mean they will have a clue on checking the input on a web form > for an SQL injection attempt. You might not touch on this until you get to those type applications. If they were taught to question input all along though, by time you get to something like this the habit might be forming. -- Mike Lyman mlyman at west-point.org From colin.cassidy at ge.com Sat Aug 22 10:52:54 2009 From: colin.cassidy at ge.com (Cassidy, Colin (GE Infra, Energy)) Date: Sat, 22 Aug 2009 16:52:54 +0200 Subject: [SC-L] Functional Correctness In-Reply-To: <20090821151809.s5cc5u5jc0gwwwc4@webmail.rbacomm.com> References: <20090821151809.s5cc5u5jc0gwwwc4@webmail.rbacomm.com> Message-ID: <2D3692016CCD2D4AA33741E25925EA7102EFBB0C@BUDMLVEM06.e2k.ad.ge.com> Brad Andrews Writes: > After all, we can just "implement this maturity model and eliminate > all our security problems, at least in the application, > right?" That > is likely to end up resulting in even more resistance in the future > when management questions why they need to keep spending more for > software security, a secure architecture, etc. Don't people learn > what they need to know at some point? I don't thinks that's ever been the case that you can just apply your model and all will be well Microsoft didn`t release their SDL and said "there all our software will now be secure", they're constantly evolving their processes. Also some of the activities within the BSIMM are about constant improvement and keeping up with the latest trends, so even just following the BSIMM your processes are never static. > I don't think we will ever be static. As soon as we remove the low > hanging fruit, the fruit higher up the tree will be the problem. Or, the fruit on another tree :) who's attacking the OS now when the apps are so easy to attack > This isn't to say a maturity model is useless, but I remain > skeptical > that it will live up to the "hype" (low key now, but there) it is > being presented with. I think that the models (both BSIMM and OSAMM) help to provide a framework and a direction to those that have no real security practices at all. Or allow a measurement of existing process and see where their weaknesses are. That and the senior management like the pretty graphs even if they don't know what it means :D CJC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4427 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20090822/f16d7438/attachment.bin From mlyman-cissp at comcast.net Sat Aug 22 11:25:37 2009 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Sat, 22 Aug 2009 10:25:37 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> Message-ID: <4A900DF1.8070202@comcast.net> Brad Andrews wrote: > But we are not talking about separate classes. The assertion (which I > probably clipped, sorry) was that it should be woven into the > curriculum. I was noting where and how to do so, starting in the > intro level classes. Just telling a starting programmer to properly > check input length is all well and good, but falls far short of making > a secure programmer. Sorry if this comes across as a misread of the above but it touches on a pet peeve of mine in this business. Falls far short or that doesn't fix the problem is used quite a bit to dismiss steps we could be taking. Since we cannot create truly secure systems or software, we need to embrace efforts that still improve things as long as the cost of the effort is appropriate for the gain in security. Instead of "properly check input length is all well and good, but falls far short of making a secure programmer" I prefer to think of all the security bugs we could have avoided if most programmers has a well ingrained habit of doing just that. We'd still have a lot of problems left to address but we'd have avoided a lot of pain if this little thing had been taught better or even taught at all. (When I do secure development intro type classes, my if you only take one thing away from today, make it Don't Trust Input. You'll learn the rest later but that one thing will fix many problems.) I went to a different type college than most people. It exists to train officers for the US Army. Most of the military training focuses on basic soldier skills and the things we needed to know to lead small units at the lieutenant level with platoons and captain level with companies if we had to. We knew enough of the higher level skills to be able to put what we were doing into context and maybe, if we got into a really bad spot, we could, for a time, command a battalion or brigade until somebody else could get there to take over. We weren't ready to be generals yet but we were reasonably ready for where we were in our careers for the first several years and most knew there was still a lot we had to learn and practice to really be good lieutenants even though we'd spent four years preparing for the job. > Some will sit through a class with glazed eyes and no understanding. We'll always have that. The old doctor joke about 50% of the doctors out there graduated in the bottom half of their class applies to our industry as well with the added burden of plenty doing what we do with no formal training at all. There are reasons we do peer reviews, formal code reviews and testing. This is just a small piece of the puzzle that has not been addressed well enough but it is just a piece. -- Mike Lyman mlyman at west-point.org From list-spam at secureconsulting.net Mon Aug 24 20:35:35 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Mon, 24 Aug 2009 17:35:35 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> Message-ID: <4A9331D7.5050001@secureconsulting.net> Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced. Riffing on Brad's comments, it seems irrational to think that you can jump straight from structural basics with which many students struggle (OO anybody?) directly to concepts that bridge computer architecture, code structure, and various other problems. Second, as long as "the right way" is not the same as "the easy way" then there will always be a disconnect. Perhaps this means that the language itself needs to require strong type checking that enforce appropriate secure coding behavior? Or maybe this is even enforced at the compiler level? (there have, of course, been problems with compilers, too, particularly in optimization mode) cheers, -ben Brad Andrews wrote: > > But we are not talking about separate classes. The assertion (which I > probably clipped, sorry) was that it should be woven into the > curriculum. I was noting where and how to do so, starting in the intro > level classes. Just telling a starting programmer to properly check > input length is all well and good, but falls far short of making a > secure programmer. > > I have no doubt that you can teach some new developers the principles in > a short time and make them more productive than those who have been > programming longer term. They don't have to unlearn anything! But this > will not work for everyone. Some will sit through a class with glazed > eyes and no understanding. > > Also remember we will have to get outside those with a fairly high level > of motivation (internal or external) for learning the material to be > successful. > > I also would like to see how you would teach secure development, with > minimal extra time load, in a basic programming sequence, possibly even > at a non-traditional or lower tier school. We won't make significant > progress until we can do that, and it still leaves out the "self taught." > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Moore's Law: "The number of transistors on an integrated circuit will double in about 18 months." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From chandra at list.org Mon Aug 24 22:37:15 2009 From: chandra at list.org (Pravir Chandra) Date: Mon, 24 Aug 2009 21:37:15 -0500 Subject: [SC-L] Functional Correctness In-Reply-To: <2D3692016CCD2D4AA33741E25925EA7102EFBB0C@BUDMLVEM06.e2k.ad.ge.com> References: <20090821151809.s5cc5u5jc0gwwwc4@webmail.rbacomm.com> <2D3692016CCD2D4AA33741E25925EA7102EFBB0C@BUDMLVEM06.e2k.ad.ge.com> Message-ID: Well, this topic gets muddy pretty quickly since I agree with many of the comments made on this thread. We have to be careful with hype and claims made by new models (BSIMM and OpenSAMM in particular) since depending on how the 'rest of the world' sees them speaks directly to our credibility as industry experts. I've tried hard when presenting OpenSAMM to fully claim that the model is chocked full of value judgements about what organizations SHOULD be doing to make a justified argument (qualitatively) that the software they produce has a degree of assurance built-in. Is it a guarantee? No. Is it still valuable? Absolutely. Before, we had no ability to make an apples-to-apples comparison between two organizations, and the model helps that. We also didn't know how to quantify iterative improvement very well or explain the breadth of the software security problem to people either, and OpenSAMM helps that too. I disagree with the remark that maturity models are only useful to companies starting with nothing, because I've seen firsthand how OpenSAMM has helped people (already doing a lot for assurance) think through aspects of the software security problem that fell outside their tunnel-vision. Now, on to the sticky topic of value judgements. Based on how I've seen the BSIMM presented, one might think that at face value, it is somehow more free of author/contributor value judgements than OpenSAMM or other secure SDLC models (I've read several articles referring to these as 'alchemy'). This is simply not true. I, for one, agree with Brad that claims of a scientific nature need to be extremely carefully qualified. At the end of the day, we don't yet know enough about practical methods for improving software security that have much justification beyond what experts think amounts to a 'good thing' (excepting formal methods, of course, but I did say practical :). This is the case for both BSIMM and OpenSAMM. I welcome comments/questions/flames. p. On 8/22/09, Cassidy, Colin (GE Infra, Energy) wrote: > > > Brad Andrews Writes: > >> After all, we can just "implement this maturity model and eliminate >> all our security problems, at least in the application, >> right?" That >> is likely to end up resulting in even more resistance in the future >> when management questions why they need to keep spending more for >> software security, a secure architecture, etc. Don't people learn >> what they need to know at some point? > > I don't thinks that's ever been the case that you can just apply your model > and all will be well Microsoft didn`t release their SDL and said "there all > our software will now be secure", they're constantly evolving their > processes. > > Also some of the activities within the BSIMM are about constant improvement > and keeping up with the latest trends, so even just following the BSIMM your > processes are never static. > >> I don't think we will ever be static. As soon as we remove the low >> hanging fruit, the fruit higher up the tree will be the problem. > > Or, the fruit on another tree :) who's attacking the OS now when the apps > are so easy to attack > >> This isn't to say a maturity model is useless, but I remain >> skeptical >> that it will live up to the "hype" (low key now, but there) it is >> being presented with. > > I think that the models (both BSIMM and OSAMM) help to provide a framework > and a direction to those that have no real security practices at all. Or > allow a measurement of existing process and see where their weaknesses are. > That and the senior management like the pretty graphs even if they don't > know what it means :D > > CJC > -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From jim at manico.net Mon Aug 24 23:28:43 2009 From: jim at manico.net (James Manico) Date: Mon, 24 Aug 2009 23:28:43 -0400 Subject: [SC-L] OWASP Podcast August Update Message-ID: Hello SC-L! The OWASP Podcast Series continues to accelerate! We released 5 podcasts this month which I hope you find to be of value. 39August 25, 2009Listen Now | Show Notes Interview with Gunnar Peterson (Webservices)38August 25, 2009Listen Now | Show Notes Interview with the OWASP Global Education Committee37August 22, 2009*Listen Now * | Show Notes Interview with Jason Lam and Johannes Ullrich (SANS Institute)36August 15, 2009Listen Now | Show Notes May 2009 News Commentary Recorded July 23 with Boaz Gelbord, Andre Gironda, Jason Lam, Jim Manico, Alex Smolen, Ben Tomhave, Andrew van der Stock and Jeff Williams (part 2)35August 4, 2009Listen Now | Show Notes Interview with Anton Chuvakin, Ph.D (PCI) Faster than a speeding bullet *winks*, the OWASP Podcast Seriesis bringing on 2 additional hosts, is spawning a Spanish AppSec podcast series, and will be releasing interviews from Andy Steingruebl (PayPal), David Rice (Geekonomics), and the DC AppSec crowd (Acronyms) in September. Ken, please forgive me for ignoring your advice to slow down. ;D Aloha to all of SC-L and thank you for listening. -- Jim Manico jim.manico at aspectsecurity.com jim.manico at owasp.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090824/2c042cb8/attachment.htm From Stephan.Neuhaus at disi.unitn.it Tue Aug 25 07:09:42 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Tue, 25 Aug 2009 13:09:42 +0200 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9331D7.5050001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: On Aug 25, 2009, at 02:35, Benjamin Tomhave wrote: > First, security in the software development concept is at least an > intermediate concept, if not advanced. Not at all. That would be like saying that correctness is also an advanced concept, because it gets in the way of coding. Security is about exploiting assumptions (often hidden) that we make when we write and deploy software. I see no reason why teaching to think about assumptions should be deferred. You teach math students how to do proofs right from the beginning for essentially the same reasons :-) > Perhaps this means that the > language itself needs to require strong type checking that enforce > appropriate secure coding behavior? Unfortunately, security assumptions are rarely written down so I don't see how they can be enforced at the language or compiler level. Best, Stephan From goertzel_karen at bah.com Tue Aug 25 10:26:43 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Tue, 25 Aug 2009 10:26:43 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9331D7.5050001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com>, <4A9331D7.5050001@secureconsulting.net> Message-ID: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other "-ilities" ("goodness" properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond "just get the bloody thing to work" are also intermediate-to-advanced concepts. In other words, teach the "goodness" properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Great strategy! Our hacker friends will love it. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave [list-spam at secureconsulting.net] Sent: Monday, August 24, 2009 8:35 PM To: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced.... From list-spam at secureconsulting.net Tue Aug 25 11:25:50 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 25 Aug 2009 08:25:50 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com>, <4A9331D7.5050001@secureconsulting.net> Message-ID: <4A94027E.2080704@secureconsulting.net> It's a catch-22, and there's certainly no need to be snarky about it. You cannot teach advanced grammar to a student with no language skills. Similarly, to think you can teach secure coding to a student with no coding skills is follow. I think James McGovern's suggestion is probably the best alternative, having students evaluate and analyze the difference between good and bad code. However, I think the utility in that approach will quickly deteriorate as the students gain more skill in writing their own code. The lazy coder will win out in the end when there are deadlines to be met. As for our hacker friends, if we want to go down that path, then I submit that this war is already very much lost. Hanging out with some of the crews at Defcon this year was an eye-opening experience. We are so far behind the curve that it is irrational to think that we will ever catch-up unless the entire battlefield is changed, and the rules of engagement along with them. So many mistakes have been made in generations before mine that we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure. This is not, incidentally, FUD - it's fact, to which not nearly enough people have direct exposure. -ben Goertzel, Karen [USA] wrote: > For consistency's sake, I hope you agree that if security is an > intermediate-to-advanced concept in software development, then all > the other "-ilities" ("goodness" properties, if you will), such as > quality, reliability, usability, safety, etc. that go beyond "just > get the bloody thing to work" are also intermediate-to-advanced > concepts. > > In other words, teach the "goodness" properties to developers only > after they've inculcated all the bad habits they possibly can, and > then, when they are out in the marketplace and never again > incentivised to actually unlearn those bad habits, TRY desperately to > change their minds using nothing but F.U.D. and various other > psychological means of dubious effectiveness. > > Great strategy! Our hacker friends will love it. > > Karen Mercedes Goertzel, CISSP Associate 703.698.7454 > goertzel_karen at bah.com ________________________________________ From: > sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On > Behalf Of Benjamin Tomhave [list-spam at secureconsulting.net] Sent: > Monday, August 24, 2009 8:35 PM To: sc-l at securecoding.org Subject: > Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > > Two quick comments in catching up on the thread... > > First, security in the software development concept is at least an > intermediate concept, if not advanced.... > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "If at first you don't succeed, failure might be your thing." Warren Miller, Impact From list-spam at secureconsulting.net Tue Aug 25 11:35:20 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 25 Aug 2009 08:35:20 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: <4A9404B8.20001@secureconsulting.net> Stephan Neuhaus wrote: > > and deploy software. I see no reason why teaching to think about > assumptions should be deferred. You teach math students how to do proofs > right from the beginning for essentially the same reasons :-) > You don't teach proofs - not really. The elementary and junior high curriculum generally does not contain anything about proofs (if it does, then that program is rare - especially in the NCLB era - unless you're considering use of manipulatives to be a "proof" with which I would disagree as it's merely empirical). You have to teach the basic constructs. You have to ingrain the fundamentals. The same is true for coding. The good news, perhaps, is that you're not generally teaching 1st graders how to write code. So you can go into more advanced topics with high school or college students. Nonetheless, these programs rarely resemble anything in real life. You talk about assumptions - this is one of the biggest - that CompSci curricula actually teaches much of anything relevant to enterprise life. Anyway. I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science. It increasingly makes sense given the failures up to this point. Though, at the same time, I stick with my original 2nd point, which is that as soon as coders can take short-cuts, they will, because deadlines rule the day. > Unfortunately, security assumptions are rarely written down so I don't > see how they can be enforced at the language or compiler level. > Here you make a patently bad assumption yourself. It should be possible for the compiler to automatically protect against overflows, as an example. Safe input validation and output encoding could also be forced at a given level. Compiler/interpreter - it doesn't matter, as long as you're not expecting a human coder to do extra work under deadlines and duress to "do things right" (especially when it conflicts with "doing the right thing" which is getting the job done and keeping one's boss happy). We should be seeking to innovate outside the box - change the rules of the game dramatically - rather than trying to work within the arbitrary constructs we've placed around ourselves. -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Sturgeon's Revelation: "Ninety percent of everything is crud." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From Stephan.Neuhaus at disi.unitn.it Tue Aug 25 12:04:54 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Tue, 25 Aug 2009 18:04:54 +0200 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9404B8.20001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A9404B8.20001@secureconsulting.net> Message-ID: On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote: > You don't teach proofs - not really. The elementary and junior high > curriculum generally does not contain anything about proofs I was talking about college students because that's when I was properly taught programming. That may no longer be true. But in maths, I *was* taught how to do proper proofs in high school (from 7th grade on, when we had Geometry). I may have been unusually lucky. > I again come back to James McGovern's suggestion, which is treating > coding as an art rather than a science. It increasingly makes sense > given the failures up to this point. The problem then is that every Joe, Dick, and Harry out there who can get hello world to compile think they're artists. Seriously, unlike art, programming is usually not a vehicle for one's creative urges, but a tool to get a job done, as you yourself say. (I hesitate to use the word "science" as an antonym to "art" here, perhaps "craft" would be better.) >> Unfortunately, security assumptions are rarely written down so I >> don't >> see how they can be enforced at the language or compiler level. >> > Here you make a patently bad assumption yourself. It should be > possible > for the compiler to automatically protect against overflows, as an > example. Sure, for certain languages and certain classes of well-understood problems, compiler or language support can be engineered. But my point stands: security assumptions are rarely written down. This is because they are taken to be self-evident and not in need of explicit formulation. Also, they depend on the domain. If I express a hospital drug disbursal system in any of the common general-purpose programming languages, the assumption that one cannot be a doctor and a nurse at the same time is usually implicit. I challenge you to develop Java or C ++ support that will capture any flaw in the implementation of this particular RBAC *without* having to make that assumption explicit. > Safe input validation and output encoding could also be forced > at a given level. Really? I'd be interested in hearing about such techniques that cannot be short-cut (which, as you state, is one big factor for security defects in software). Best, Stephan From steingra at gmail.com Tue Aug 25 12:07:31 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Tue, 25 Aug 2009 09:07:31 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: <490a979e0908250907pc927033x6027e4012a317f69@mail.gmail.com> On Tue, Aug 25, 2009 at 4:09 AM, Stephan Neuhaus wrote: > > On Aug 25, 2009, at 02:35, Benjamin Tomhave wrote: > >> First, security in the software development concept is at least an >> intermediate concept, if not advanced. > > Not at all. That would be like saying that correctness is also an advanced > concept, because it gets in the way of coding. Security is about exploiting > assumptions (often hidden) that we make when we write and deploy software. I > see no reason why teaching to think about assumptions should be deferred. > You teach math students how to do proofs right from the beginning for > essentially the same reasons :-) really? First graders are learning to do math proofs instead of basic addition? I'm quite surprised by this. We're missing I think the point I raised earlier. Not everyone learns to program in high school or college. And, even learning the basics of what an algorithm are is tricky, much less learning defensive programming, etc. So, yes, it is an "advanced" concept for the majority of beginning programmers. -- Andy Steingruebl steingra at gmail.com From Stephan.Neuhaus at disi.unitn.it Tue Aug 25 12:15:54 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Tue, 25 Aug 2009 18:15:54 +0200 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <490a979e0908250907pc927033x6027e4012a317f69@mail.gmail.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <490a979e0908250907pc927033x6027e4012a317f69@mail.gmail.com> Message-ID: On Aug 25, 2009, at 18:07, Andy Steingruebl wrote: > really? First graders are learning to do math proofs instead > of basic addition? I'm quite surprised by this. Yeah, sorry. When I wrote about "students" I meant "college students". I don't know, is that a difference between British English (pupils) and American English (students)? Anyway, my bad. > We're missing I think the point I raised earlier. Not everyone learns > to program in high school or college. And, even learning the basics > of what an algorithm are is tricky, much less learning defensive > programming, etc. But the topic of the thread is "Where Does Secure Coding Belong In the Curriculum?" and I maintain that when someone is intellectually mature enough so that you can teach them how to program and at the same time really know what they're doing, you can teach them about correctness and security too. Best, Stephan From bishop at cs.ucdavis.edu Tue Aug 25 11:55:39 2009 From: bishop at cs.ucdavis.edu (Matt Bishop) Date: Tue, 25 Aug 2009 08:55:39 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9331D7.5050001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: Ben, > First, security in the software development concept is at least an > intermediate concept, if not advanced. Riffing on Brad's comments, it > seems irrational to think that you can jump straight from structural > basics with which many students struggle (OO anybody?) directly to > concepts that bridge computer architecture, code structure, and > various > other problems. I agree and I disagree. If I walked into an ECS 10 (Intro to Programming class) and began "We use the waterfall model to provide a moderate level of assurance ..." about 75% of the students would be out the door. That's one problem with teaching security per se: you need to describe *what* your security requirements are, and when you're struggling to learn how to write a "for" loop, being asked to implement security requirements as such is intimidating. Instead, what you can do is frame the issues as "good programming". When teaching for loops, teach the idea of a "limit" (upper and lower bounds). Then when you get to arrays, it's natural to discuss bounds checking in the context of iteration (I don't phrase it that way, of course). When you grade, you check for it. Presto! Now you have taught what is commonly considered a security requirement without ever mentioning the word "security". I find the distinction between "robust" and "secure" is useful, although often the two are interchangeable. By "robust", I mean the more nebulous requirement that the program not crash (although it may terminate gracefully :-)) and that it handle unexpected inputs reasonably, and so forth. By "secure", I mean meeting a specific set of requirements that describe what "security" means; for example, unexpected inputs may require specific actions (in which case handling them is both robust and secure :-)). Note: I'm not sure the distinction here is too meaningful, so please don't ask me to define a boundary. But in introductory classes, I tend to focus on what I am calling "robust" above; when I teach software security, I focus on both, as I consider robustness part of security. By the way, you can do this very effectively in a beginning programming class. When I taught Python, as soon as the students got to basic structures like control loops (for which they had to do simple reading), I showed them how to catch exceptions so that they could handle input errors. When they did functions, we went into exceptions in more detail. They were told that if they didn't handle exceptions in their assignments, they would lose points -- and the graders gave inputs that would force exceptions to check that they did. Most people got it quickly. Matt From peter.werner at gmail.com Tue Aug 25 12:39:40 2009 From: peter.werner at gmail.com (Pete Werner) Date: Wed, 26 Aug 2009 02:39:40 +1000 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: <6378f48a0908250939s56dfa913xb6d3fb7b64a9346a@mail.gmail.com> The "just get the bloody thing to work" is usually an attitude foisted on developers by the business side. I work in an internal application security function for a large enterprise and i'm yet to meet a developer who wasn't concerned about security. Developer education is very important and we have a lot of it available for out developers, some of it even compulsory. However, unless there is the will of the business behind it, developer concerns are oft pushed aside in the interest of expediency. I find the business side usually does have a genuine interest in "security" and "quality", however they are concepts that remain largely unquantifiable, and in the case of security you only need to mess up once to end up with a nasty situation. It's can be a tough sell getting time to focus on these things, given they can be so vague. In the case of my organisation, business side support comes from both internal advocacy of security practises by our function and externally imposed legal requirements. Mostly the latter ;) Filtering inputs is NOT hard, and most developers are getting better at things like that. However, the problems of application security go beyond the developer level, and it's important not to lose sight of that fact. If there were an easy solution everything would already be perfectly secure. Pete On Wed, Aug 26, 2009 at 12:26 AM, Goertzel, Karen [USA] wrote: > For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other "-ilities" ("goodness" properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond "just get the bloody thing to work" are also intermediate-to-advanced concepts. > > In other words, teach the "goodness" properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. > > Great strategy! Our hacker friends will love it. > > Karen Mercedes Goertzel, CISSP > Associate > 703.698.7454 > goertzel_karen at bah.com > ________________________________________ > From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave [list-spam at secureconsulting.net] > Sent: Monday, August 24, 2009 8:35 PM > To: sc-l at securecoding.org > Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > > Two quick comments in catching up on the thread... > > First, security in the software development concept is at least an > intermediate concept, if not advanced.... > _______________________________________________ > 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 Stephan.Neuhaus at disi.unitn.it Tue Aug 25 13:05:11 2009 From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus) Date: Tue, 25 Aug 2009 19:05:11 +0200 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A94027E.2080704@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com>, <4A9331D7.5050001@secureconsulting.net> <4A94027E.2080704@secureconsulting.net> Message-ID: <9E84B749-D344-40FC-AA8D-6E0FF416B6E0@disi.unitn.it> On Aug 25, 2009, at 17:25, Benjamin Tomhave wrote: > You cannot teach advanced grammar to a student with no language > skills. I have excellent language skills (after my gaffe with the word "student" on this very list, I should perhaps add "in my mother tongue"), but you still couldn't teach me grammar. I just don't get it. On the other hand, I have known people who couldn't hold write a short essay if it saved their lives, yet they were brilliant in taking sentences apart. > Similarly, to think you can teach secure coding to a student with no > coding skills is follow. I wouldn't teach "secure coding". I'd teach what Karen has termed "goodness properties" along with the other coding stuff like variables, loops and so on. Even if you teach total beginners, you will usually approach programming as a problem-solving exercise. But in order to solve an exercise, you must have at least some notion of what constitutes a valid solution. So even complete beginners have a notion of what it means for the program to produce the desired result. And from that basic understanding of correctness to "the program should not behave in any unexpected way, even when attacked" it is not that far. Best, Stephan From steingra at gmail.com Tue Aug 25 13:14:41 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Tue, 25 Aug 2009 10:14:41 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA] wrote: > For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other "-ilities" ("goodness" properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond "just get the bloody thing to work" are also intermediate-to-advanced concepts. > > In other words, teach the "goodness" properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? Maybe we're still having that pupil/student discussion? In engineering disciplines we split courses into different areas of concern but still make everyone take all of the classes whether they are beginner or advanced. Or, physics for example. Or maybe something like music lessons? Maybe we should teach all kids about vibrato and complex rhythms from day-1, or maybe before they have even picked up an instrument we should make them study music theory? I'm just having a hard time understanding why we're trying to invent this from scratch when plenty of other disciplines, how people learn other skills, etc. all start from basics and then get more advanced. -- Andy Steingruebl steingra at gmail.com From gem at cigital.com Tue Aug 25 13:35:16 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 25 Aug 2009 13:35:16 -0400 Subject: [SC-L] informIT: attack categories Message-ID: hi sc-l, If you listened recently to the latest episode of Silver Bullet with Fred Schneider from Cornell , one of the ideas Fred and I discussed was the notion of attack categories and anticipating large scale trends in attack space. Hopefully you guys all recall that I am a strong proponent of understanding the attacker's perspective (see, for example Exploiting Software from way back in 2004 where Hoglund and I coined the term "attack pattern" ). This month's informIT article is about the notion of long term attack categories and is meant to inform software security research: Software [In]security: Attack Categories and History Prediction http://www.informit.com/articles/article.aspx?p=1393066 BTW, shout outs for the OWASP top 10 and CWE in the article may surprise the usual nay sayers. Feedback is most welcome. (Thanks to Ken and Sammy for helping me make this article slightly more coherent.) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/justiceleague book www.swsec.com From goertzel_karen at bah.com Tue Aug 25 13:40:04 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Tue, 25 Aug 2009 13:40:04 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> Message-ID: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with "grim reality", we give examples that illustrate exactly WHY they needed to know those things. But that doesn't mean we wait until the kids are 11 or 12 to tell them shouldn't play in traffic. There has to be some way to start introducing the idea even to the rawest of raw beginning programming students that "good" is much more desirable than "expedient", and then to introduce the various properties that collectively constitute "good" - including security. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: Andy Steingruebl [steingra at gmail.com] Sent: Tuesday, August 25, 2009 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA] wrote: > For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other "-ilities" ("goodness" properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond "just get the bloody thing to work" are also intermediate-to-advanced concepts. > > In other words, teach the "goodness" properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? ... From James.McGovern at thehartford.com Tue Aug 25 14:09:30 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Tue, 25 Aug 2009 14:09:30 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> Message-ID: There are several perspectives missing from the dialog: - Before we even talk about secure coding, we need a course on secure thinking. Most folks are indoctrinated into thinking positive which blinds them from seeing vulnerabilities right in front of them. A prereq on being antisocial might be a good start - For those who work in large enterprises, the positive thinking is even further reinforced where even functional delivery takes a back seat to perception management. In order for secure coding to mature, folks need the ability for someone to not get offended so easily. A good first step may be figuring out a way to tell someone that their code sucks without ending up in HR (observed but not personal) - Taking this one step further, how can we convince professors who don't teach secure coding to not accept insecure code from their students. Professors seed the students thinking by accepting anything that barely works at the last minute. Universities need to be consistent amongst their own teaching/thinking. ************************************************************ 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 coley at linus.mitre.org Tue Aug 25 14:23:53 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 25 Aug 2009 14:23:53 -0400 (EDT) Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9404B8.20001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A9404B8.20001@secureconsulting.net> Message-ID: On Tue, 25 Aug 2009, Benjamin Tomhave wrote: > We should be seeking to innovate outside the box - change the rules of > the game dramatically - rather than trying to work within the arbitrary > constructs we've placed around ourselves. Insert obligatory OWASP ESAPI praise here. The Enterprise Security API project is trying to build an API that makes it easier for application developers to fold in security. If you need crypto, use the crypto API. If you need authentication, use the authentication API. I think ESAPI (or similar APIs) have the potential to be game-changers. One primary benefit is that programmers aren't trying to implement security themselves. One potential selling point to developers would be saving time - rather than wasting days/weeks/months implementing your own authentication scheme, use the API. Obviously there are limitations in its applicability, but it seems to be off to a great start. http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API This kind of thing could be extended to non-web applications, or possibly introduced to programmers fairly early in education. Disclaimer: I've participated in the project here and there. Another way to change the game (besides languages) is to define and adopt more secure protocols. Given how slow DNSSEC and IPv6 have been in terms of adoption, and how rapidly AJAX has grown, I'm not too optimistic for success in this area without serious customer demand. Even requiring the use of non-proprietary, well-documented protocols and data formats, with strict conformance by implementations, could go a long way - because then you can develop extensive test suites against these standards and use a whitelist-based approach of refusing anything that does not conform. Unfortunately, I'm not too optimistic in this regard, either. - Steve From andrews at rbacomm.com Tue Aug 25 16:23:04 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Tue, 25 Aug 2009 15:23:04 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A9404B8.20001@secureconsulting.net> Message-ID: <20090825152304.rijf663z9wo4kcsk@webmail.rbacomm.com> I had proofs in junior high Geometry too, though I do not recall using them outside that class. I went all the way through differential equations, matrix algebra and probability/statistics and I don't recall much focus on proofs. This was in the early 1980s in a good school (Illinois), so it wasn't just modern teaching methods that were too blame. I am not sure that the proofs were all that useful for understanding some things either, though the logic they taught has value that I missed a bit of since I did hit some modern techniques. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Stephan Neuhaus : > > On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote: > >> You don't teach proofs - not really. The elementary and junior high >> curriculum generally does not contain anything about proofs > > I was talking about college students because that's when I was properly > taught programming. That may no longer be true. But in maths, I *was* > taught how to do proper proofs in high school (from 7th grade on, when > we had Geometry). I may have been unusually lucky. From andrews at rbacomm.com Tue Aug 25 16:27:33 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Tue, 25 Aug 2009 15:27:33 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <490a979e0908250907pc927033x6027e4012a317f69@mail.gmail.com> Message-ID: <20090825152733.c3nnzzvwgw8g8cck@webmail.rbacomm.com> While part of me agrees with that in principle, I am not so sure in practice. I have found many of the students I have struggle with just getting the basic structures down, not anything fancy. The class is not taught at an elite university, but more "for the masses" though, but isn't that who really needs to be targeted? While the elite definitely need to understand the importance of development security and how to do it, so do the masses. The latter are going to be much harder to reach. It is kind of like general computer user security. The power users need to know the subject, but so do the occasional users. Most programmers are not power users in the programming field, unfortunately or not. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Stephan Neuhaus : > I maintain that when someone is intellectually mature > enough so that you can teach them how to program and at the same time > really know what they're doing, you can teach them about correctness > and security too. From andrews at rbacomm.com Tue Aug 25 16:32:28 2009 From: andrews at rbacomm.com (Brad Andrews) Date: Tue, 25 Aug 2009 15:32:28 -0500 Subject: [SC-L] Inherently Secure Code? In-Reply-To: <4A94027E.2080704@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com>, <4A9331D7.5050001@secureconsulting.net> <4A94027E.2080704@secureconsulting.net> Message-ID: <20090825153228.72fyx4fa00kw4c4w@webmail.rbacomm.com> I am not sure I agree that this is any more achievable than claiming a bank building should allow all valid customers in, but keep out all thieves. While we can and should make great strides, we will always have some exposure because we have to let some things through. The only way we can have perfectly secure code is to not allow someone to use it. The same is true of bug free code, but that is another argument. :) Isn't this kind of like wanting the "evil bit" to be set in all malicious packets? Great idea, but not achievable. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Benjamin Tomhave : > we are now trapped in a box of our own > making that has us squabbling over academic minutiae like how to teach > secure coding when we should not have to consider this topic at all - > the code itself should be inherently secure. From amurren at gmail.com Tue Aug 25 17:45:51 2009 From: amurren at gmail.com (Andy Murren) Date: Tue, 25 Aug 2009 17:45:51 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <6378f48a0908250939s56dfa913xb6d3fb7b64a9346a@mail.gmail.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <6378f48a0908250939s56dfa913xb6d3fb7b64a9346a@mail.gmail.com> Message-ID: <346e8fa30908251445m785b8498p5dde57980b0a3f5c@mail.gmail.com> Personally I think secure coding should be included in the entire curriculum irrespective of the level. People learn habits early on that they tend to carry for as long as they are programmers. How many programmers that learned the K&R style of indentation for example continue to use it as their default style even when they have learned new languages. Having just done a quick survey of the programming books on my shelves I don't find security or secure coding covered much if at all. I doubt that is because some business guy came down to the author and told him to excise security from the book. If basic security and secure coding practices are not integrated into programming from the beginning it is an add on, and hence not a natural component of the (art|science) of programming and much easier to skip. I have started teaching my 12 year old son C programming at home. We started off with a basic "Hello World", then added his name as a variable, then a loop to print different names, then added the ability to take the name as input from the command line. At each step we added in a bit of exception handling, and once we got to user input data we added basic data and input validation. Each new version of the program had a test plan and had to handle exceptions. This is a very simple example and is not something production ready, but every step showed him how to program without leaving security out. In my opinion, any educational program that deals with computers or networks should have security and secure coding woven into it. The amount and type of secure coding depends on the subject. A management class that calculates costs and ROI of a project should have metrics for the cost of security or robustness failures. Networking classes should have secure configuration integrated. Software engineering/design would need to have appropriate modules on encryption, identity management, etc, etc. In the end I think the question should be: "Is there a place where does security and secure coding NOT belong in a curriculum?" From coley at linus.mitre.org Tue Aug 25 18:36:09 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 25 Aug 2009 18:36:09 -0400 (EDT) Subject: [SC-L] informIT: attack categories In-Reply-To: References: Message-ID: Gary, You said in the article: >The next category of attacks to expect are attacks that target defects in >design and architecture - which I call flaws. I think it's already happening. I fully expect to see this reflected in the updated CVE vulnerability trends for 2007/2008, which (fingers crossed) will be released in the next month or so (OK, most of the flaws will be in web apps, but still...) >we lack a taxonomy of flaws such as the ones we have for bugs (see the >Seven pernicious kingdoms and the CWE). CWE is not just a bug parade, it's also a flaw parade ;-) Although the parts related to flaws don't have the depth or specificity that exists for bugs/faults. The "weaknesses introduced during design" view CWE-701 actually lists 353 entries. http://cwe.mitre.org/data/lists/701.html ... although there are a lot of weaknesses that you could argue are bugs. For example, is path traversal a bug or a flaw? It probably depends on how file handling is performed within a specific application. Actually, I think the lines between flaws and bugs/faults can get pretty fuzzy. We do want to address CWE's relative lack of depth for flaws, however. The hierarchy in the research view (CWE-1000) may be the best way to peruse where CWE stands. I'd love to hear from others who are working in classification at the flaw level. Current areas of promise under CWE are CWE-227 ("API Abuse" which has been borrowed from Seven Pernicious Kingdoms and given a little more structure), resource lifecycle issues and control spheres (CWE-664), external control of critical data/variables/systems/clients (CWE-642), protection mechanism failures (CWE-693), and even many of the classic Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental that these areas still need some work, and any/all input is welcome. Use the "graph" tab on the individual CWE pages to see the sub-hierarchies. Interestingly (or perhaps not), implementation bugs and design/architecture flaws may share some of the same underlying fundamental properties. For example, a bug-level action of setting a variable declaration to "public" instead of "private" has some of the same properties as a flaw-level action of creating an open socket that anybody can connect to - you're unintentionally exposing a resource to somebody who shouldn't have any access to that resource at all. Or, as an example of a resource lifecycle problem, a use-after-free implementation bug isn't so different than the flaw in which you continue to use a certificate after it has expired. I suspect that design/architecture level taxonomies will be very challenging to build. For one part, there's a lot less research in the area than implementation bugs (at least the research that I'm aware of), and certainly a lot less public vuln data to draw from (e.g. CVE). There's a lot of stuff on design but not in any easily-packaged form to build a taxonomy, and it's often tied to specific technologies. For another, you have a lot more different perspectives at play. We can look at an unbounded strcpy and say "well that's clearly a bug" but at the design level, is the problem "use of a language that supports arbitrary indexing of arbitrary pointers" or "use of a risky API function that doesn't perform its own bounds-checking" or "use of a data structure [string] that does not have expliticly-stated length as a separate field from the buffer" or "failure to validate input"? (The answer may be "all of the above" or "it depends on your perspective," but that's where taxonomy construction gets really hard.) I, for one, can't wait. - Steve From goertzel_karen at bah.com Tue Aug 25 19:31:33 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Tue, 25 Aug 2009 19:31:33 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> , Message-ID: Not so much anti-social as untrusting, supicious, and paranoid. Actually, being highly social could provide an excellent "cover" to fool the bad guys into thinking one is a lot less security-savvy than one actually is. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F (HTSC, IT) [James.McGovern at thehartford.com] Sent: Tuesday, August 25, 2009 2:09 PM To: Secure Code Mailing List Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? There are several perspectives missing from the dialog: - Before we even talk about secure coding, we need a course on secure thinking. Most folks are indoctrinated into thinking positive which blinds them from seeing vulnerabilities right in front of them. A prereq on being antisocial might be a good start From Kevin.Wall at qwest.com Tue Aug 25 19:48:56 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Tue, 25 Aug 2009 18:48:56 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <20090821105456.sa2pb5w9wkkggosc@webmail.rbacomm.com> Message-ID: James McGovern wrote... > - Taking this one step further, how can we convince > professors who don't > teach secure coding to not accept insecure code from their students. > Professors seed the students thinking by accepting anything > that barely > works at the last minute. Universities need to be consistent amongst > their own teaching/thinking. Well, actually, I think that what Matt Bishop wrote in his response to Benjamin Tomhave is the key: > But in introductory classes, I tend to focus on what I am calling > "robust" above; when I teach software security, I focus on > both, as I consider robustness part of security. > > By the way, you can do this very effectively in a beginning > programming class. When I taught Python, as soon as the students got > to basic structures like control loops (for which they had to do > simple reading), I showed them how to catch exceptions so that they > could handle input errors. When they did functions, we went into > exceptions in more detail. They were told that if they didn't handle > exceptions in their assignments, they would lose points -- and the > graders gave inputs that would force exceptions to check that > they did. > > Most people got it quickly. That is, Matt suggested a direct reward / punishment. Specifically, if the students don't account for bad input via exceptions or some other suitable mechanism, the simply loose points. Matt's right. If it boils down to grades, most students will get it, and fast. And whether we call this secure-coding, robustness, or simply correctness, it's a start. I think that too many people when they hear that we need to start teaching security at every level of CS are thinking of more complicated things like encryption, authentication protocols, Bell-LaPadula, etc. but I don't think that was where the thrust of this thread was leading. -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 From u3902 at siliconkeep.com Tue Aug 25 20:16:17 2009 From: u3902 at siliconkeep.com (Olin Sibert) Date: Tue, 25 Aug 2009 20:16:17 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.co m> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> Message-ID: <0MKpCa-1Mg6Ba3kfx-000D9O@mrelay.perfora.net> I'm mostly a lurker here, and I'm a practitioner rather than a professional educator, but there's a viewpoint I haven't seem much of that I want to support, namely: Exploits are FUN. Teach from that angle, and I think you'll get more traction. I've given a fair number of "basic security" talks to commercial audiences. Invariably, a significant fraction of the audience, whether they are professional programmers, inexperienced interns, marketing types, managers, etc., end up wanting to understand how exploits actually work and how they are prevented. I can't help thinking that this would be true of even the freshest of programming/compsci students. Heck, I've even gotten that reaction from some of my kids' high school friends. Not everyone thinks that way, but I think if we can get students to think "hey, that's pretty clever" instead of teaching security as something you _must_ do because it's good for you even though it's not obviously related to getting the job done, odds for success are higher. Rigor needs to come eventually, but I think it is absolutely appropriate to include some exploit-based entertainment even at the earliest stages of education. We should be selling sizzling steak, not cod liver oil. Olin Sibert Oxford Systems, Inc. From gem at cigital.com Tue Aug 25 20:39:05 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 25 Aug 2009 20:39:05 -0400 Subject: [SC-L] informIT: attack categories In-Reply-To: Message-ID: hi sc-l, Fred sent me some email today and reminded me that he has written about this idea himself in IEEE Security & Privacy magazine. We already had a link to his article on the Silver Bullet website, but here's a direct link: "The Monoculture Risk Put in Context" IEEE Security and Privacy 7, 1 (January/February 2009), 14-17. Fred Schneider and Ken Birman. http://www.cs.cornell.edu/fbs/publications/IEEEspMonoculture.pdf gem On 8/25/09 1:35 PM, "gem" wrote: hi sc-l, If you listened recently to the latest episode of Silver Bullet with Fred Schneider from Cornell , one of the ideas Fred and I discussed was the notion of attack categories and anticipating large scale trends in attack space. Hopefully you guys all recall that I am a strong proponent of understanding the attacker's perspective (see, for example Exploiting Software from way back in 2004 where Hoglund and I coined the term "attack pattern" ). This month's informIT article is about the notion of long term attack categories and is meant to inform software security research: Software [In]security: Attack Categories and History Prediction http://www.informit.com/articles/article.aspx?p=1393066 BTW, shout outs for the OWASP top 10 and CWE in the article may surprise the usual nay sayers. Feedback is most welcome. (Thanks to Ken and Sammy for helping me make this article slightly more coherent.) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast 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 gem at cigital.com Tue Aug 25 20:46:36 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 25 Aug 2009 20:46:36 -0400 Subject: [SC-L] informIT: attack categories In-Reply-To: Message-ID: hi steve, The bugs/flaw continuum is, in fact, a continuum. It's great that you guys have begun to collect and publish information about flaws in the CWE. I agree completely with your statement "I suspect that design/architecture level taxonomies will be very challenging to build." Part of what Fred is trying to spark with his work is some research funding for that area. gem On 8/25/09 6:36 PM, "Steven M. Christey" wrote: Gary, You said in the article: >The next category of attacks to expect are attacks that target defects in >design and architecture - which I call flaws. I think it's already happening. I fully expect to see this reflected in the updated CVE vulnerability trends for 2007/2008, which (fingers crossed) will be released in the next month or so (OK, most of the flaws will be in web apps, but still...) >we lack a taxonomy of flaws such as the ones we have for bugs (see the >Seven pernicious kingdoms and the CWE). CWE is not just a bug parade, it's also a flaw parade ;-) Although the parts related to flaws don't have the depth or specificity that exists for bugs/faults. The "weaknesses introduced during design" view CWE-701 actually lists 353 entries. http://cwe.mitre.org/data/lists/701.html ... although there are a lot of weaknesses that you could argue are bugs. For example, is path traversal a bug or a flaw? It probably depends on how file handling is performed within a specific application. Actually, I think the lines between flaws and bugs/faults can get pretty fuzzy. We do want to address CWE's relative lack of depth for flaws, however. The hierarchy in the research view (CWE-1000) may be the best way to peruse where CWE stands. I'd love to hear from others who are working in classification at the flaw level. Current areas of promise under CWE are CWE-227 ("API Abuse" which has been borrowed from Seven Pernicious Kingdoms and given a little more structure), resource lifecycle issues and control spheres (CWE-664), external control of critical data/variables/systems/clients (CWE-642), protection mechanism failures (CWE-693), and even many of the classic Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental that these areas still need some work, and any/all input is welcome. Use the "graph" tab on the individual CWE pages to see the sub-hierarchies. Interestingly (or perhaps not), implementation bugs and design/architecture flaws may share some of the same underlying fundamental properties. For example, a bug-level action of setting a variable declaration to "public" instead of "private" has some of the same properties as a flaw-level action of creating an open socket that anybody can connect to - you're unintentionally exposing a resource to somebody who shouldn't have any access to that resource at all. Or, as an example of a resource lifecycle problem, a use-after-free implementation bug isn't so different than the flaw in which you continue to use a certificate after it has expired. I suspect that design/architecture level taxonomies will be very challenging to build. For one part, there's a lot less research in the area than implementation bugs (at least the research that I'm aware of), and certainly a lot less public vuln data to draw from (e.g. CVE). There's a lot of stuff on design but not in any easily-packaged form to build a taxonomy, and it's often tied to specific technologies. For another, you have a lot more different perspectives at play. We can look at an unbounded strcpy and say "well that's clearly a bug" but at the design level, is the problem "use of a language that supports arbitrary indexing of arbitrary pointers" or "use of a risky API function that doesn't perform its own bounds-checking" or "use of a data structure [string] that does not have expliticly-stated length as a separate field from the buffer" or "failure to validate input"? (The answer may be "all of the above" or "it depends on your perspective," but that's where taxonomy construction gets really hard.) I, for one, can't wait. - Steve From chandra at list.org Tue Aug 25 21:10:01 2009 From: chandra at list.org (Pravir Chandra) Date: Tue, 25 Aug 2009 18:10:01 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> Message-ID: The "playing in traffic" example is one extreme end of the spectrum. A good analogy for the other end might be physics where you just teach Newtonian theory it as if it were 100% accurate and then, if the student decides to take a relativistic physics class, you teach them on day 1 that everything they know isn't right. It seems teaching secure programming must lie somewhere between these two ends of the spectrum. Perhaps a more useful exercise (rather than debating where in the gradient through metaphor) is to try to enumerate the variables that play into what draws a topic toward one end or the other. Such variables might include: * "stickiness" of the bias/habits acquired as you learn more * impetus to learn more * ability/access to learn more Just a thought. p. On 8/25/09, Goertzel, Karen [USA] wrote: > We teach toddlers from the time they can walk that they shouldn't play in > traffic. A year or two later, we teach them to look both ways before > crossing the street. Even later - usually when they're approaching their > teens, and can deal with "grim reality", we give examples that illustrate > exactly WHY they needed to know those things. > > But that doesn't mean we wait until the kids are 11 or 12 to tell them > shouldn't play in traffic. > > There has to be some way to start introducing the idea even to the rawest of > raw beginning programming students that "good" is much more desirable than > "expedient", and then to introduce the various properties that collectively > constitute "good" - including security. > > Karen Mercedes Goertzel, CISSP > Associate > 703.698.7454 > goertzel_karen at bah.com > ________________________________________ > From: Andy Steingruebl [steingra at gmail.com] > Sent: Tuesday, August 25, 2009 1:14 PM > To: Goertzel, Karen [USA] > Cc: Benjamin Tomhave; sc-l at securecoding.org > Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > > On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen > [USA] wrote: >> For consistency's sake, I hope you agree that if security is an >> intermediate-to-advanced concept in software development, then all the >> other "-ilities" ("goodness" properties, if you will), such as quality, >> reliability, usability, safety, etc. that go beyond "just get the bloody >> thing to work" are also intermediate-to-advanced concepts. >> >> In other words, teach the "goodness" properties to developers only after >> they've inculcated all the bad habits they possibly can, and then, when >> they are out in the marketplace and never again incentivised to actually >> unlearn those bad habits, TRY desperately to change their minds using >> nothing but F.U.D. and various other psychological means of dubious >> effectiveness. > > Seriously? We're going to teach kids in 5th grade who are just > learning what an algorithm is how to protect against malicious inputs, > how to make their application fast, handle all exception conditions, > etc? > > ... > _______________________________________________ > 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 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From jim at manico.net Tue Aug 25 23:17:23 2009 From: jim at manico.net (Jim Manico) Date: Tue, 25 Aug 2009 23:17:23 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9404B8.20001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A9404B8.20001@secureconsulting.net> Message-ID: > I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim On Aug 25, 2009, at 11:35 AM, Benjamin Tomhave wrote: > I again come back to James McGovern's suggestion, which is treating > coding as an art rather than a science -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090825/2970c739/attachment.htm From list-spam at secureconsulting.net Wed Aug 26 00:23:38 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 25 Aug 2009 21:23:38 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: <4A94B8CA.90103@secureconsulting.net> Matt Bishop wrote: > > Instead, what you can do is frame the issues as "good programming". When > teaching for loops, teach the idea of a "limit" (upper and lower > bounds). Then when you get to arrays, it's natural to discuss bounds > checking in the context of iteration (I don't phrase it that way, of > course). When you grade, you check for it. Presto! Now you have taught > what is commonly considered a security requirement without ever > mentioning the word "security". > I would agree with this, as I think it again syncs with what James McGovern talked about earlier, too. A graduated approach to "secure coding" (for whatever definition we might insert) is the only logical progression. However, as you conceded, we have to be very careful just how much we introduce and when. I remember the disconnect in the mid-90s when the CompSci curriculum switched to OO. Some of us got caught in the blender where our first CS class was non-OO and our 2nd class was suddenly all OO and we didn't know what the heck was going on. It seems we're perhaps still in this transitional state to a large part. > By the way, you can do this very effectively in a beginning programming > class. When I taught Python, as soon as the students got to basic > structures like control loops (for which they had to do simple reading), > I showed them how to catch exceptions so that they could handle input > errors. When they did functions, we went into exceptions in more detail. > They were told that if they didn't handle exceptions in their > assignments, they would lose points -- and the graders gave inputs that > would force exceptions to check that they did. > Let's just hope that the code isn't compiled with -O3 or similar, creating an unintended bug. :) http://isc.sans.org/diary.html?storyid=6820 > Most people got it quickly. > Getting it and applying it IRL are of course two completely different things. I still find it somewhat absurd that we even need to have this discussion still after how many decades of curriculum development? :) -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "Reading is to the mind what exercise is to the body." Sir Richard Steele From list-spam at secureconsulting.net Wed Aug 26 00:27:30 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 25 Aug 2009 21:27:30 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> Message-ID: <4A94B9B2.7060900@secureconsulting.net> Goertzel, Karen [USA] wrote: > We teach toddlers from the time they can walk that they shouldn't > play in traffic. A year or two later, we teach them to look both ways > before crossing the street. Even later - usually when they're > approaching their teens, and can deal with "grim reality", we give > examples that illustrate exactly WHY they needed to know those > things. > Actually, I'm not teaching my 1 yo toddler much of anything about traffic right now. I'm more playing guardian when she runs around the house and making sure she doesn't get into situations for which she would be completely and totally unprepared (and in serious danger). She lacks the language skills to even marginally understand basic concepts like "street" let alone "don't play in the street." I think this rather proves my point that secure coding is not itself a fundamental concept, but rather an intermediate-to-advanced concept. Matt Bishop's comments are great, but they've also been applied in a context of higher ed., and recognize the limits of student understanding at different phases of development. -ben > But that doesn't mean we wait until the kids are 11 or 12 to tell > them shouldn't play in traffic. > > There has to be some way to start introducing the idea even to the > rawest of raw beginning programming students that "good" is much more > desirable than "expedient", and then to introduce the various > properties that collectively constitute "good" - including security. > > Karen Mercedes Goertzel, CISSP Associate 703.698.7454 > goertzel_karen at bah.com ________________________________________ From: > Andy Steingruebl [steingra at gmail.com] Sent: Tuesday, August 25, 2009 > 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; > sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding > Belong In the Curriculum? > > On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen > [USA] wrote: >> For consistency's sake, I hope you agree that if security is an >> intermediate-to-advanced concept in software development, then all >> the other "-ilities" ("goodness" properties, if you will), such as >> quality, reliability, usability, safety, etc. that go beyond "just >> get the bloody thing to work" are also intermediate-to-advanced >> concepts. >> >> In other words, teach the "goodness" properties to developers only >> after they've inculcated all the bad habits they possibly can, and >> then, when they are out in the marketplace and never again >> incentivised to actually unlearn those bad habits, TRY desperately >> to change their minds using nothing but F.U.D. and various other >> psychological means of dubious effectiveness. > > Seriously? We're going to teach kids in 5th grade who are just > learning what an algorithm is how to protect against malicious > inputs, how to make their application fast, handle all exception > conditions, etc? > > ... > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "That which has always been accepted by everyone, everywhere, is almost certain to be false." Paul Valery From list-spam at secureconsulting.net Wed Aug 26 01:46:37 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 25 Aug 2009 22:46:37 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <1F5D9655-C7AE-4AD6-B594-E870A6ADAA06@cs.ucdavis.edu> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A94B8CA.90103@secureconsulting.net> <1F5D9655-C7AE-4AD6-B594-E870A6ADAA06@cs.ucdavis.edu> Message-ID: <4A94CC3D.3040509@secureconsulting.net> Matt Bishop wrote: > > And that's an artifact of a lack of resources for the type of grading. > Give classes the support to do this, and I suspect you'd see people get > in the habit of writing better code. Better, use students and people > from industry who know this stuff to staff a clinic analogous to a > writing clinic for English and law schools -- that would reinforce it > not just for the students, but for the clinic staff as well. > This sounds like an excellent extension for OWASP. :) -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "I hope if dogs ever take over the world and they choose a king, they don't just go by size, because I bet there are some Chihuahuas with some good ideas." Deep Thoughts by Jack Handy From bishop at cs.ucdavis.edu Wed Aug 26 01:42:12 2009 From: bishop at cs.ucdavis.edu (Matt Bishop) Date: Tue, 25 Aug 2009 22:42:12 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A94B8CA.90103@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A94B8CA.90103@secureconsulting.net> Message-ID: <1F5D9655-C7AE-4AD6-B594-E870A6ADAA06@cs.ucdavis.edu> Ben, > Let's just hope that the code isn't compiled with -O3 or similar, > creating an unintended bug. :) > http://isc.sans.org/diary.html?storyid=6820 Brings back memories -- the first day on the job as a summer intern I had to track down a bug in a UNIX device driver. Turned out the optimizer was clobbering a jump -- the driver worked fine unoptimized. I quit believing tools like compilers were flaw-free after that! >> Most people got it quickly. >> > Getting it and applying it IRL are of course two completely different > things. I still find it somewhat absurd that we even need to have this > discussion still after how many decades of curriculum development? :) Oh, I don't -- I think it's all too understandable. A story first, to provide some background. One of my grad students (a security type, of course :-)) was my TA for the undergraduate operating systems class. We had the students form teams, and each team modified a kernel. The TA then graded interactively, asking the students about what they did and why, as he went through their code. My TA was appalled at the poor quality of the code of most teams -- it worked, but was not robust and was sloppy. So, he told each group that if they turned in code that poor the next time, he'd deduct 20% on general principles. So what do students do in that case? Right -- complain to the professor (me). I said something to the effect that I strongly disagreed with the TA, and felt he should have handled the situation differently; but since he said he'd only take off 20%, instead of the 40% I would have taken off, I'd support his decision. The students got the message. On the next assignment (and for the res of the class), the code was much better. This suggests to me the problem is not so much a failure to teach robustness; in fact, I suspect most intro to programming teachers do mention it (although to different degrees of thoroughness and probably not using that name). The *real* problem is that we don't keep reinforcing it throughout the student's career. And that's an artifact of a lack of resources for the type of grading. Give classes the support to do this, and I suspect you'd see people get in the habit of writing better code. Better, use students and people from industry who know this stuff to staff a clinic analogous to a writing clinic for English and law schools -- that would reinforce it not just for the students, but for the clinic staff as well. Anyone who's interested in this idea can read about a small experiment I did in a paper at http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/ The results of having students use such a clinic, on a very small scale, led to some pretty good improvements in their code. The problem, of course, is that supporting such a clinic requires a lot of people time, and getting people to donate their time, or the resources (read: cash) to pay for it, isn't easy. Matt From Jason.Bennett at thales-esecurity.com Wed Aug 26 05:03:20 2009 From: Jason.Bennett at thales-esecurity.com (Bennett, Jason) Date: Wed, 26 Aug 2009 10:03:20 +0100 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? Message-ID: "So many mistakes have been made in generations before mine that we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure." This is the comment that agrees with my own belief. When teaching "how to program" secure coding should be seen as inherent in this and not as some sort of optional add that is only required if the code is supposed to "secure". Many of the techniques are just making the code more robust and this covers a considerable amount of the problems with code today. I see no reason that this shouldn't be taught as part of any programming course. Does this cover all secure coding, no of course not, but unless the foundations of secure implementation is inherent then more advance issues ar the least of the communities worries. 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". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20090826/08bdddd1/attachment.htm From Kevin.Wall at qwest.com Wed Aug 26 07:33:13 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Wed, 26 Aug 2009 06:33:13 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090825152304.rijf663z9wo4kcsk@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net><20090821105155.7dcm3dd68048sccw@webmail.rbac omm.com><200908211524 07.rz13o82dfcwk8skw@webmail.rbacomm.com><4A9331D7.5050001@secureconsulting. net><4A9404B8.20001@sec ureconsulting.net>, <20090825152304.rijf663z9wo4kcsk@webmail.rbacomm.com> Message-ID: Brad Andrews writes... > I had proofs in junior high Geometry too, though I do not recall using > them outside that class. I went all the way through differential > equations, matrix algebra and probability/statistics and I don't > recall much focus on proofs. This was in the early 1980s in a good > school (Illinois), so it wasn't just modern teaching methods that were > too blame. I am not sure that the proofs were all that useful for > understanding some things either, though the logic they taught has > value that I missed a bit of since I did hit some modern techniques. This may be heading slightly OT, but I don't think your experience is really that unusual. My BS was a double major in math and physics and my MS was in CS. We used "proofs" in most of my math classes, many of my physics classes, and several of my CS classes. Besides the frequency, what varied in each of these was the level of rigor expected. The proofs in math were extremely rigorous, the ones in physics less so, and the ones in most of my CS classes would have been classified as only so much "hand waving" if they would have been done in my math classes. But an important thing to note in all of these courses was, with the exception of very few advanced (senior & grad level) math classes such as "advanced calculus" and "abstract algebra" and "number theory", the use of 'proofs' wasn't the end, but only a means to the end. But still 'proofs' were utilized throughout much of this very diverse coursework to add to the rigor of the logic and presumably to reinforce understanding and learning. In the same way, I think that 'security' (or 'robustness' or 'correctness' or whatever you wish to call it) needs to be CONSISTENTLY blended into the college and possibly even high school CS curriculum so some element of it is touched upon in each of the classes and as one progresses it is discussed more and more. So just as 'proofs' are sprinkled into math, physics, CS, etc. we need to sprinkle in basic security / robustness concepts such as: + An understanding of what input may be 'trusted' and what inputs cannot be trusted leading to the concept of trust boundaries. + The concept of correctness extends merely past handling 'correct' input and needs to somehow gracefully handle incorrect input as well. + Understanding the concept of risk, eventually leading to an understanding of risk analysis in upper level CS courses + Having an adversarial testing mindset, always thinking "how can I 'break' this program or system?". (BTW, sad to say, this has probably been the hardest thing to teach my colleagues. Some of them seem to get it, and some of them never do.) There are probably others--this is by no means a complete list--but we need to emphasize that to those instructing CS that this is not going to take up a significant portion of their coursework nor require a significant amount of time or effort on there part. Rather it needs to be folded into the mix as appropriate. I think back to my days in elementary mathematics. I recall learning at a very early age, when learning division, that you can't divide by 0. The explanation given by the teach wasn't in depth, it was more like "you are just not permitted to do that", or occasionally "it's undefined" without telling us WHY it's undefined. In a similar manner, we can teach "don't blindly accept unchecked input", etc. And then if that is reinforced in the grading process I do think it will come through. Surely if we could just do that much, it would be a good start. But my observation, based on my CS colleagues that I've taught with and before that, the CS courses that I've taken at the graduate level, is that other than the obligatory half hour mention of security in my operating systems course, I can barely recall it ever even coming up. And I also seldom recall that instructors would every toss your programs truly malformed input either. By comparison, when I had an opportunity to teach a masters level CS course on distributed systems (the Tannenbaum book), I tossed in matters of security throughout, not just in the chapters about security. Of course, I don't think until we got to the chapters about security that the students realized that's what I was teaching them, but that's OK too. The subliminal methods sometimes work as well. -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME From prasad.shenoy at gmail.com Wed Aug 26 08:06:37 2009 From: prasad.shenoy at gmail.com (Prasad Shenoy) Date: Wed, 26 Aug 2009 08:06:37 -0400 Subject: [SC-L] informIT: attack categories In-Reply-To: References: Message-ID: <43c6c8500908260506y7497abaasbaecbee8475cb264@mail.gmail.com> Gary, Great article and since you used attacks and categories in the same :) sentence I am tempted to ask if you looked at WASC Threat Classification project? On Tuesday, August 25, 2009, Steven M. Christey wrote: > > Gary, > > You said in the article: > >>The next category of attacks to expect are attacks that target defects in >>design and architecture - which I call flaws. > > I think it's already happening. ?I fully expect to see this reflected in > the updated CVE vulnerability trends for 2007/2008, which (fingers > crossed) will be released in the next month or so (OK, most of the flaws > will be in web apps, but still...) > >>we lack a taxonomy of flaws such as the ones we have for bugs (see the >>Seven pernicious kingdoms and the CWE). > > CWE is not just a bug parade, it's also a flaw parade ;-) ?Although the > parts related to flaws don't > have the depth or specificity that exists for bugs/faults. ?The > "weaknesses introduced during design" view CWE-701 actually lists 353 > entries. > > ?http://cwe.mitre.org/data/lists/701.html > > ... although there are a lot of weaknesses that you could argue are bugs. > For example, is path traversal a bug or a flaw? ?It probably depends on > how file handling is performed within a specific application. ?Actually, I > think the lines between flaws and bugs/faults can get pretty fuzzy. > > We do want to address CWE's relative lack of depth for flaws, however. > The hierarchy in the research view (CWE-1000) may be the best way to > peruse where CWE stands. ?I'd love to hear from others who are working in > classification at the flaw level. > > Current areas of promise under CWE are CWE-227 ("API Abuse" which has been > borrowed from Seven Pernicious Kingdoms and given a little more > structure), resource lifecycle issues and control spheres (CWE-664), > external control of critical data/variables/systems/clients (CWE-642), > protection mechanism failures (CWE-693), and even many of the classic > Saltzer-and-Schroeder design principles (CWE-657). ?It is not coincidental > that these areas still need some work, and any/all input is welcome. ?Use > the "graph" tab on the individual CWE pages to see the sub-hierarchies. > > Interestingly (or perhaps not), implementation bugs and > design/architecture flaws may share some of the same underlying > fundamental properties. ?For example, a bug-level action of setting a > variable declaration to "public" instead of "private" has some of the same > properties as a flaw-level action of creating an open socket that anybody > can connect to - you're unintentionally exposing a resource to somebody > who shouldn't have any access to that resource at all. ?Or, as an example > of a resource lifecycle problem, a use-after-free implementation bug isn't > so different than the flaw in which you continue to use a certificate > after it has expired. > > I suspect that design/architecture level taxonomies will be very > challenging to build. ?For one part, there's a lot less research in the > area than implementation bugs (at least the research that I'm aware of), > and certainly a lot less public vuln data to draw from (e.g. CVE). There's > a lot of stuff on design but not in any easily-packaged form to build a > taxonomy, and it's often tied to specific technologies. ?For another, you > have a lot more different perspectives at play. ?We can look at an > unbounded strcpy and say "well that's clearly a bug" but at the design > level, is the problem "use of a language that supports arbitrary indexing > of arbitrary pointers" or "use of a risky API function that doesn't > perform its own bounds-checking" or "use of a data structure [string] that > does not have expliticly-stated length as a separate field from the > buffer" or "failure to validate input"? ?(The answer may be "all of the > above" or "it depends on your perspective," but that's where taxonomy > construction gets really hard.) > > I, for one, can't wait. > > - 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. > _______________________________________________ > -- Thanks & Regards, Prasad N. Shenoy From ken at krvw.com Wed Aug 26 08:51:18 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Wed, 26 Aug 2009 08:51:18 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <0MKpCa-1Mg6Ba3kfx-000D9O@mrelay.perfora.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> <0MKpCa-1Mg6Ba3kfx-000D9O@mrelay.perfora.net> Message-ID: On Aug 25, 2009, at 8:16 PM, Olin Sibert wrote: > Exploits are FUN. I agree, at least to a point. Whenever I work exploits into my workshops, the results are right on the mark. So long as the exploits are balanced with just the right amount of remediations, it works great. The key is to hook the students with the exploits, and then sprinkle in a "now here's how to do it _right_" discussion while they're still paying attention. ;-) And FWIW, I've found OWASP's WebGoat to be phenomenally effective at doing just that. There are other similar tools out there as well, but the point is to give the class a safe sandbox to play in. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- 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/20090826/cbbbf29a/attachment-0001.bin From ljknews at mac.com Wed Aug 26 08:53:38 2009 From: ljknews at mac.com (ljknews) Date: Wed, 26 Aug 2009 08:53:38 -0400 Subject: [SC-L] informIT: attack categories In-Reply-To: References: Message-ID: At 6:36 PM -0400 8/25/09, Steven M. Christey wrote: > Gary, > > You said in the article: > >>The next category of attacks to expect are attacks that target defects in >>design and architecture - which I call flaws. > > I think it's already happening. I think it has been happening for years. I use Microsoft Word V5.1a from 1992, because Microsoft followed that with Word 6.0 which introduced the design defect allowing Macro Viruses. Of course this was not actually an innovation, as IBM had previously introduced _and_withdrawn_ a similar vulnerability in their CMS operating environment (the mail program would automatically call a text formatter which could call the operating system under the direction of the sender. Those who do not study history are condemned to repeat it. -- Larry Kilgallen From neumann at csl.sri.com Wed Aug 26 09:48:55 2009 From: neumann at csl.sri.com (Peter G. Neumann) Date: Wed, 26 Aug 2009 6:48:55 PDT Subject: [SC-L] Inherently Secure Code? In-Reply-To: Your message of Tue, 25 Aug 2009 15:32:28 -0500 Message-ID: I don't much like INHERENTLY SECURE CODE. Software components by themselves are not secure. Security (and trustworthiness that encompasses security, reliability, survivability, etc.) is an emergent property of the entire system or enterprise. To say that a component is secure is rather fatuous. See my DARPA report on composable trustworthy architectures for starters. http://www.csl.sri.com/neumann/chats4.pdf or .html From goertzel_karen at bah.com Wed Aug 26 09:49:34 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 26 Aug 2009 09:49:34 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A94B9B2.7060900@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> , <4A94B9B2.7060900@secureconsulting.net> Message-ID: Your example is spurious as a refutation of what I was trying to say (as I suspect you already know). Obviously you're not going to try to teach a not-yet-verbal infant a self-preservation concept that requires even the most rudimentary reasoning. That said, I'll be interested to hear from you in, say, a year and a half from now. And I still maintain that the intellectual maturity of a two-and-a-half-year-old hardly constitutes "intermediate-to-advanced" EXCEPT possibly when compared with that of a one-year-old. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: Benjamin Tomhave [list-spam at secureconsulting.net] Sent: Wednesday, August 26, 2009 12:27 AM To: Goertzel, Karen [USA] Cc: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Goertzel, Karen [USA] wrote: > We teach toddlers from the time they can walk that they shouldn't > play in traffic. A year or two later, we teach them to look both ways > before crossing the street. Even later - usually when they're > approaching their teens, and can deal with "grim reality", we give > examples that illustrate exactly WHY they needed to know those > things. > Actually, I'm not teaching my 1 yo toddler much of anything about traffic right now. I'm more playing guardian when she runs around the house and making sure she doesn't get into situations for which she... From goertzel_karen at bah.com Wed Aug 26 09:55:16 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 26 Aug 2009 09:55:16 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <20090825152304.rijf663z9wo4kcsk@webmail.rbacomm.com> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A9404B8.20001@secureconsulting.net> , <20090825152304.rijf663z9wo4kcsk@webmail.rbacomm.com> Message-ID: I too remember learning proofs in Jr. High. And I also believe the main objective was to teach 12 and 13 year olds that it is possible to apply a repeatable, disciplined process to how they approach problem solving. Certainly not a worthless lesson, even if the mathematics involved are never used again. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Brad Andrews [andrews at rbacomm.com] Sent: Tuesday, August 25, 2009 4:23 PM To: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I had proofs in junior high Geometry too, though I do not recall using them outside that class. I went all the way through differential equations, matrix algebra and probability/statistics and I don't recall much focus on proofs. This was in the early 1980s in a good school (Illinois), so it wasn't just modern teaching methods that were too blame. I am not sure that the proofs were all that useful for understanding some things either, though the logic they taught has value that I missed a bit of since I did hit some modern techniques. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI From goertzel_karen at bah.com Wed Aug 26 10:09:05 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 26 Aug 2009 10:09:05 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <0MKpCa-1Mg6Ba3kfx-000D9O@mrelay.perfora.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com>, <0MKpCa-1Mg6Ba3kfx-000D9O@mrelay.perfora.net> Message-ID: I see your point. On the other hand, there are times I worry that "teach the hacker mentality" approach to secure development training smacks a bit too much teaching future policemen the delights of robbery, rape, torture, and murder in order to prepare the to defend the public against robbers, rapists, torturers, and murders. Definitely teach - with examples - what it is about software that makes it so easy to exploit and violate. But stop short of handing the students detailed blueprints and instructions, reinforced by lots of hands-on lab time. I'm just untrusting enough of human nature to worry that once some of them discover how much more fun it is to hack than to defend against hacking, what you'll end up with is not the next Bob Seacord but the next Kevin Mitnick. At the very least, make psychological exams a prerequisite of acceptance into your class, so you can weed out the likely psychopaths and sociopaths. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Olin Sibert [u3902 at siliconkeep.com] Sent: Tuesday, August 25, 2009 8:16 PM To: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I'm mostly a lurker here, and I'm a practitioner rather than a professional educator, but there's a viewpoint I haven't seem much of that I want to support, namely: Exploits are FUN. Teach from that angle, and I think you'll get more traction.... From mlyman-cissp at comcast.net Wed Aug 26 10:15:03 2009 From: mlyman-cissp at comcast.net (Mike Lyman) Date: Wed, 26 Aug 2009 09:15:03 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A9331D7.5050001@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> Message-ID: <4A954367.6000708@comcast.net> Benjamin Tomhave wrote: > First, security in the software development concept is at least an > intermediate concept, if not advanced. Riffing on Brad's comments, it > seems irrational to think that you can jump straight from structural > basics with which many students struggle (OO anybody?) directly to > concepts that bridge computer architecture, code structure, and various > other problems. > Like most technical skills, there is a range of skills that play into secure software. When you are teaching hello world, you are not coving program architecture and requirements management. In a similar way you are not going to get into advanced secure software concepts when you are teaching hello world. You teach the appropriate skill levels at the appropriate time and some of these are going to be skills that play into secure programming. For students at perhaps the high school level and above, you can probably even begin to introduce them as things that impact security even if the focus is mainly on doing things right. Bad habits develop early and we need to prevent them as early as possible. Earlier I related how I had college instructors tell us not to worry about extras like error handling but to concentrate on the lesson he was trying to teach us. Clearly many of us were able to worry about error handling, we were trying to do it. We tried to do user friendly interfaces (command line at the time) and respond to incorrect input, don't bother with that, just concentrate on the lesson. The wrong lessons were taught those days. Forget the implied requirements, just get the job done as quickly as possible. Wrong lesson. Early on, way back in high school, I learned about problems with dividing by zero and learned to check for it even if it wasn't explicitly in the code. That was the beginning of input validation. Early on I learned the limits of integer types on computers (also in high school), that was the beginning of learning about integer overflow problems. Secure coding needs to be injected into the entire curriculum to keep the bad habits from developing early but it needs to be done at a skills appropriate level. We're not going to teach people to do a threat modeling when they are doing hello world. We can't teach people to validate input when they have not had any lessons on comparison operators, if statements or case statements etc. Once they've had those though, some basic input validation becomes a great programming assignment to test their understanding of those skills. -- Mike Lyman mlyman at west-point.org From goertzel_karen at bah.com Wed Aug 26 10:28:35 2009 From: goertzel_karen at bah.com (Goertzel, Karen [USA]) Date: Wed, 26 Aug 2009 10:28:35 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com> <20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsulting.net> <4A9404B8.20001@secureconsulting.net>, Message-ID: Your Picasso - or, perhaps, Frank Lloyd Wright would be a better analogy - definitely has a role in software development. I want his creativity up front in the specification and high-level design of the building (the software system). But when it comes to detailed design and testing, I'm going to call in the engineers, and when it comes to coding, no-one does it better than skilled construction workers who have mastered the use of hammers, saws, adzes, etc. So yes - the coders are craftsmen. But the problem is that in software development, the roles are seldom so clearcut, especially not in Agile development. So one does find far too many craftsmen attempting the engineers' and architects' jobs without anything like the necessary training and certification of their competence to perform those functions. Or maybe, if we accept the "software development as an art" analogy, our problem is we have way too many architects trying to code successfully. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_karen at bah.com ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Jim Manico [jim at manico.net] Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim From Kevin.Wall at qwest.com Wed Aug 26 11:33:56 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Wed, 26 Aug 2009 10:33:56 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A94B9B2.7060900@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rba comm.com> <200908211 52407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsult ing.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> <4A94B9B2.7060900@secureconsulting.net> Message-ID: > Actually, I'm not teaching my 1 yo toddler much of anything about > traffic right now. I'm more playing guardian when she runs around the > house and making sure she doesn't get into situations for which she > would be completely and totally unprepared (and in serious > danger). She lacks the language skills to even marginally > understand basic concepts like "street" let alone "don't play > in the street." I think this rather proves my point that > secure coding is not itself a fundamental concept, > but rather an intermediate-to-advanced concept. Matt Bishop's comments > are great, but they've also been applied in a context of > higher ed., and recognize the limits of student understanding > at different phases of development. I don't mean to split hairs here, but I think "fundamental concept" vs "intermediate-to-advanced concept" is a red herring. In your case of you teaching a 1 yr old toddler, "NO" is about the only thing they understand at this point. That doesn't imply that concepts like "street" are intermediate-to-advanced. It's all a matter of perspective. If you are talking to someone with a Ph.D. in physics about partial differential equations, PDEs *are* a fundamental concept at that level (and much earlier in fact). The point is, not to argue semantics, but rather to teach LEVEL-APPROPRIATE concepts. -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 From James.McGovern at thehartford.com Wed Aug 26 11:46:42 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Wed, 26 Aug 2009 11:46:42 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net><20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com><20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com><4A9331D7.5050001@secureconsulting.net><4A9404B8.20001@secureconsulting.net> Message-ID: OK, do you really think the folks who pay our bills even understand the difference between art and craftmanship? Imagine me building a house out of 2x2 because I can save money on the 2x4s. If I can entertain (manage perception) the clients such that they won't look (aka CIO) and can distract the rogue inspector with some other finding (you always have to let them find something) then I can frame your home and sheetrock it before you even notice. We are not craftsmen nor are customers willing to pay for it. For the last 30 or so years, they have been taking our output regardless of quality and using it. They are more happy with disclaimers and the appearance of goodness than actual goodness. Enterprises might be happier with a secure coding process that creates the appearance of security than the actual heavy lifting of writing secure code. We live in a world where everyone desires process to be a substitute for competence. ________________________________ From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim On Aug 25, 2009, at 11:35 AM, Benjamin Tomhave wrote: I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science ************************************************************ 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: From list-spam at secureconsulting.net Wed Aug 26 11:59:46 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 26 Aug 2009 08:59:46 -0700 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rba comm.com> <200908211 52407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@secureconsult ing.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> <4A94B9B2.7060900@secureconsulting.net> Message-ID: <4A955BF2.4020908@secureconsulting.net> Wall, Kevin wrote: > > I don't mean to split hairs here, but I think "fundamental concept" > vs "intermediate-to-advanced concept" is a red herring. In your case > of you teaching a 1 yr old toddler, "NO" is about the only thing > they understand at this point. That doesn't imply that concepts like > "street" are intermediate-to-advanced. It's all a matter of perspective. > If you are talking to someone with a Ph.D. in physics about partial > differential equations, PDEs *are* a fundamental concept at that level > (and much earlier in fact). The point is, not to argue semantics, but > rather to teach LEVEL-APPROPRIATE concepts. > I think you do mean to split hairs, and I think you're right to do so. Context is very important. For example, all this talk about where to fit secure coding into the curriculum is great, but it also ignores the very large population of self-taught coders out there, as well as those who learn their craft in a setting other than a college or university. Ergo, it still seems like we're talking at ends about an issue that, while important, is still only at best a partial solution. -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Fitts' Law: "The time to acquire a target is a function of the distance to and the size of the target." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From Kevin.Wall at qwest.com Wed Aug 26 17:30:21 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Wed, 26 Aug 2009 16:30:21 -0500 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: <4A955BF2.4020908@secureconsulting.net> References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net> <20090821105155.7dcm3dd68048sccw@webmail.rb a comm.com> <2009082 11 52407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@securecons ult ing.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> <4A94B9B2.7060900@secureconsulting.net> <4A955BF2.4020908@secureconsulting.net> Message-ID: Ben Tomhave wrote: > Wall, Kevin wrote: > > > > I don't mean to split hairs here, but I think "fundamental concept" > > vs "intermediate-to-advanced concept" is a red herring. In your case > > of you teaching a 1 yr old toddler, "NO" is about the only thing > > they understand at this point. That doesn't imply that concepts like > > "street" are intermediate-to-advanced. It's all a matter of perspective. > > If you are talking to someone with a Ph.D. in physics about partial > > differential equations, PDEs *are* a fundamental concept at that level > > (and much earlier in fact). The point is, not to argue semantics, but > > rather to teach LEVEL-APPROPRIATE concepts. > > > I think you do mean to split hairs, and I think you're right to do so. > Context is very important. For example, all this talk about > where to fit secure coding into the curriculum is great, but it also > ignores the very arge population of self-taught coders out there, > as well as those who learn their craft in a setting other than a > college or university. Ergo, it still seems like we're talking at > ends about an issue that, while important, is still only at best a > partial solution. Of course it's only a partial solution and I think you raise some very valid concerns. Normally, I wouldn't consider the "self-taught" in a discussion of where does secure coding belong in the CURRICULUM, but we can't ignore that 800 lb gorilla either. That of course is a much harder challenge. I suppose in some sense we should expect / hope that these same concepts that we've been discussing are addressed in the numerous books, periodicals, web sites, etc. where most of this learning happens. But that's probably much more difficult sitation to change...more of a wild, wild west in comparison to academia. Ultimately, most sane people act in accordance with that they are rewarded for doing things correct and disciplined for doing wrong. In academia, we can do this with grades for students, pay and/or tenure or other perks for professors / lecturers, etc. But once we get into books and magazines realm, we have to look for the publishers to reward / discipline appropriately and IMO they don't necessarily have the same drivers as to academia. Many publishers seem to be more concerned with just making a quick $$ rather than being accurate or thoroughly training people to do things correctly. (How else can you explain books explain tabloids, unless you subscribe to the MiB theory. And IMHO, there are plenty of "tabloid"-like publishers writing books in the programming field, but I digress.) Getting back to my point, you don't have that less "control" for someone putting up their own educational web pages that profess to teach programming to which many of the self-educated seem to rely on. There are plenty good ones, but most I've seen seem to be oblivious to secure coding practice (w/ exception of security-related sites such as OWASP, etc.) So it's only things like reputation, and ultimately market pressures that force any corrective actions in regards to publishers of written and web material. Add to that the problem that BECAUSE these people are self-taught, the generally don't have someone to provide guidance to separate the wheat from the chaff like instructors hopefully do with their students. But if self-taught programmers are the 800 pound gorilla, then corporate business is the 4 ton elephant. If anything, I would say that addressing the pressures that seem to be on corporate programmers that come to bear _against_ secure coding practice (although unintentionally) is the MUCH BIGGER problem. (Most people go into CS to move into industry after all, not to stay and teach/research in academia.) Most businesses rate secure code as a very low need and to emphasize time-to-market (which presumably has a direct correlation to market share, or so we've been told) over everything else. IMHO, that leads to more slip-shod code than any other single factor. Adding defensive code to make it more robust against attacks takes additional time, which on large projects can be quite significant. To make matters worse, many IT shops in the USA seem to reward the "how fast can you crank out code" (no matter how insecure) over the "how good of quality do you deliver" mentality. What is rewarded in IT shops is quantity of LOC cranked out each week (wrongly widely perceived as equivalent to productivity) over quality (less buggy code, which I believe correlates well less vulnerabilities). I have no sour grapes here--never wanted to move into management--yet over my 30+ years in industry (mostly telecom), I've seen the "fast" get rewarded, transfer to another project before things crash-and-burn, and then go on to get promoted to some management position. And then they continue to act this was as managers because that's what got them there. Let's face it, the IT industry in the USA is one huge dysfunctional family. So, I think *that's* why we've been focusing on formal education. There is a chance, a glimmer of hope even in the most cynical of us, that if we reach a critical mass there (and trust me, my mass is more critical than most), we can perhaps reach a tipping point and get things turned around. Until then, in our own circle of influence, we try the best we can to teach others the whys and hows of secure coding. Often, that's one developer at a time, and occassionaly, you might get the opportunity to teach a small class. By the cynic in me says that unless we address the pressures in business that business brings to bear (usually unintentionally) against secure coding, we are fighting a battle that we will never win because those forces will cause people to unlearn / forget everything that they have been properly taught in their CS curriculum about secure coding (if we assume for the moment we can get to that point someday, which I think we can). Wow, how was that for a rant? :) --- 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 From James.McGovern at thehartford.com Thu Aug 27 10:06:21 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Thu, 27 Aug 2009 10:06:21 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net><20090821105155.7dcm3dd68048sccw@webmail.rb a comm.com> <2009082 1152407.rz13o82dfcwk8skw@webmail.rbacomm.com> <4A9331D7.5050001@securecons ulting.net> , <490a979e0908251014i77b9d55cyf1bc6c120a4347fa@mail.gmail.com> <4A94B9B2.7060900@secureconsulting.net><4A955BF2.4020908@secureconsulting.net> Message-ID: Yet another perspective. I believe that this question may be somewhat flawed as it doesn't take into consideration certain demographic challenges. Right now the model seems to be based on either being academic (sitting through a semester of some old fog with no real-world experience blabbering theory) or in the professional world and their ability to bring in consultants to perform in-house training (in a highly constrained time crunch). So, if you are an employee of a small software company, how do you learn to write secure code? Academia hasn't yet adjusted to the modern world of professionals where education needs to be a component in work/life balance and not an impediment to it and therefore this isn't really an option for the masses. Likewise, if you aren't employed by a large enterprise with a training budget that can hire all these training firms that want to do onsite classes for dozens of employees, you are left with reading lots of books on your free time, a few OWASP TV videos and google. One of the more interesting experiences that I had was that a professor at RPI uses one of the books I am the lead author for in his class. If I wanted to be a guest lecturer, this would be no problem, yet if I wanted to get credit for the course, I would actually have to sit through the entire thing which would be as interesting as watching paint dry. I have on several occasions made the offer that I will pay for all fees for a given course upfront and I want to take the final exam. If I did not score 100% you could fail me and still no university would take my offer. We got to find a balance between one-day train the world in corporate America and months upon months of mind-numbling indoctrination that universities push if we are to truly conquer the challenge of secure coding. ************************************************************ 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 Thu Aug 27 10:17:56 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Thu, 27 Aug 2009 10:17:56 -0400 Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? In-Reply-To: References: <4A8C6B78.2080608@uci.edu> <4A8E903F.1030007@comcast.net><20090821105155.7dcm3dd68048sccw@webmail.rbacomm.com><20090821152407.rz13o82dfcwk8skw@webmail.rbacomm.com><4A9331D7.5050001@secureconsulting.net><4A9404B8.20001@secureconsulting.net>, Message-ID: We are NOT craftsmen by any stretch of the imagination. If you have ever worked in a large enterprise, the ability to change roles and be fluid in one's career is rewarding yet has unintended consequences. If I went to my boss tomorrow and said that I no longer want to be an architect and instead want some experience managing a project, what training do you think I will be afforded before I actually get to project manage a large initiative? For that matter I am an architect, what training do you think I have received? Much of my daily job is art where all of about ten minutes requires craftsmanship. We need to stop being delusional and thinking that us IT folks are bound by ANY principle. If you find a single principle taught in a university setting that hasn't been waived in a corporate environment at one time or another, I sure would love to know what that is. We are artists. End of discussion... ________________________________________ From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Jim Manico [jim at manico.net] Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l at securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim _______________________________________________ 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. _______________________________________________ ************************************************************ 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 list-spam at secureconsulting.net Thu Aug 27 11:47:31 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Thu, 27 Aug 2009 08:47:31 -0700 Subject: [SC-L] Inherently Secure Code? In-Reply-To: References: Message-ID: <4A96AA93.1070301@secureconsulting.net> To be sure, "inherently secure code" is a misnomer. However, that being said, my original contention was that certain common vulnerabilities should be automatically managed these days rather than relying on explicit code to catch them. Should any sort of overflow really be allowed? I have to believe there are ways to safely trap those - perhaps they result in an abend, but at least not in a manner that achieves the goals of a compromise attempt. Similarly, it seems that there should be ways to force the deserialization and parsing of data that could be safer than allowing raw, unvalidated input to be acted upon. I wonder, too, if part of the error in the curriculum thread is focusing too low-level - that is, instead of focusing just on coding skills, maybe there should also be a larger discussion of publishing frameworks, development environments, etc., that introduce a lot of these security capabilities as inherited properties/functions? Done properly, it would lead to inherently better properties. fwiw. -ben Peter G. Neumann wrote: > I don't much like INHERENTLY SECURE CODE. > Software components by themselves are not secure. > Security (and trustworthiness that encompasses security, reliability, > survivability, etc.) is an emergent property of the entire system > or enterprise. To say that a component is secure is rather fatuous. > > See my DARPA report on composable trustworthy architectures for > starters. > http://www.csl.sri.com/neumann/chats4.pdf or .html > > _______________________________________________ > 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. > _______________________________________________ > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "We can't solve problems by using the same kind of thinking we used when we created them." Albert Einstein From ljknews at mac.com Thu Aug 27 17:12:47 2009 From: ljknews at mac.com (ljknews) Date: Thu, 27 Aug 2009 17:12:47 -0400 Subject: [SC-L] Inherently Secure Code? In-Reply-To: <4A96AA93.1070301@secureconsulting.net> References: <4A96AA93.1070301@secureconsulting.net> Message-ID: At 8:47 AM -0700 8/27/09, Benjamin Tomhave wrote: > Should any sort of overflow really be allowed? It is not, except by management decision (in choosing an unsafe language). -- Larry Kilgallen From gem at cigital.com Thu Sep 10 16:32:36 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 10 Sep 2009 16:32:36 -0400 Subject: [SC-L] Reality Check: Vmware's Kris Inglis Message-ID: hi sc-l, Turns out lots of different kinds of enterprises are spearheading large scale software security initiatives. VMware has an extensive software security initiative that has leveraged and evolved the EMC approach. Kris Inglis runs the product security group at VMware (what I would term their software security group). We talk about Vmware's approach in episode 8 of Reality Check: http://www.cigital.com/realitycheck/show-008/ Reality Check is syndicated by CSO magazine. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From eric_dalci at yahoo.fr Wed Sep 16 14:53:18 2009 From: eric_dalci at yahoo.fr (Eric Dalci) Date: Wed, 16 Sep 2009 11:53:18 -0700 (PDT) Subject: [SC-L] OWASP Session - Fortify 360 - Thursday, September 17, 2009 (webex available) In-Reply-To: References: Message-ID: <273766.77533.qm@web28603.mail.ukl.yahoo.com> SC-L, ??? The Owasp Northern Virginia chapter is pleased to invite you to its next session on Thursday September 17th. We will be hosting a presentation, demo and hands on session of Fortify 360 (http://www.fortify.com). Fortify 360 includes Fortify SCA (Source Code Analyzer) and the Fortify 360 Server which is Fortify's solution for an enterprise deployment of SCA. ? The session will start with a presentation by Eric Klein (Fortify), followed by a demo and finally a hands on session where the audience will be free to install Fortify SCA on their machine and scan the Webgoat application. The audience will also be introduced with the Fortify 360 Server and try some of the enterprise level features such as collaborative code review, metrics and so on. Bring your laptop if you want to try Fortify 360! ? For the hands on, bring your laptop, the install takes about 10-15 minutes. We'll have installation files for Windows, Mac and Linux. ? You can also follow via webex (see below for links) The target audience is anyone interested in Secure Code Review with a Static Analysis tool at the desktop level and/or enterprise level. We will need to register visitors before hand...please email wade.woolwine at owasp.org for registration and confirm attendance. Pizza and refreshments will be served. http://www.owasp.org/index.php/Virginia_%28Northern_Virginia%29#tab=Schedule Location: 22260 Pacific blvd, Sterling, VA. 20166 (AOL Office) Topic: OWASP Session - Fortify 360 Date: Thursday, September 17, 2009 Time: 6:00 pm, Eastern Daylight Time (GMT -04:00, New York) Meeting Number: 487 746 568 Meeting Password: Owasp1 Please click the link below to see more information, or to join the meeting. ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://cigital.webex.com/cigital/j.php?ED=126987157&UID=0&PW=f26e92a72b1b0a151a5d 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 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf ------ _______________________________________________ Owasp-wash_dc_va mailing list Owasp-wash_dc_va at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_va _______________________________________________ Owasp-wash_dc_va mailing list Owasp-wash_dc_va at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_va -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken at krvw.com Thu Sep 17 02:06:46 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 17 Sep 2009 08:06:46 +0200 Subject: [SC-L] Unicode Security : Microsoft releases BinScope and MiniFuzz to the public Message-ID: <819DCDF4-C088-4DAB-98DA-C37026EC0A6A@krvw.com> FYI, a couple of interesting developments in the software security tool space: http://www.lookout.net/2009/09/16/microsoft-releases-binscope-and-minifuzz-to-the-public/ Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com SC-L Moderator -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available URL: From dinis at ddplus.net Thu Sep 17 18:54:14 2009 From: dinis at ddplus.net (Dinis Cruz) Date: Thu, 17 Sep 2009 23:54:14 +0100 Subject: [SC-L] OWASP Session - Fortify 360 - Thursday, September 17, 2009 (webex available) In-Reply-To: <273766.77533.qm@web28603.mail.ukl.yahoo.com> References: <273766.77533.qm@web28603.mail.ukl.yahoo.com> Message-ID: <701fd6b60909171554i150348d8v506f51e729f5cf3e@mail.gmail.com> I posted an lengthy email to the owasp-leaders list about this event which you can read on my blog: http://diniscruz.blogspot.com/2009/09/fortify-hands-on-demosession-at.html(in there you can also see a couple more ideas that come up of that owasp-leaders email thread) Let me know if (after reading my post) you have further comments, ideas or worries about this OWASP 'activity' :) Dinis Cruz OWASP Board Member On Wed, Sep 16, 2009 at 7:53 PM, Eric Dalci wrote: > SC-L, > > > The Owasp Northern Virginia chapter is pleased to invite you to its > next session on *Thursday September 17th*. We will be hosting a > presentation, demo and hands on session of Fortify 360 ( > http://www.fortify.com). > Fortify 360 includes Fortify SCA (Source Code Analyzer) and the Fortify 360 > Server which is Fortify's solution for an enterprise deployment of SCA. > > > > The session will start with a presentation by Eric Klein (Fortify), > followed by a demo and finally a hands on session where the audience will be > free to install Fortify SCA on their machine and scan the Webgoat > application. The audience will also be introduced with the Fortify 360 > Server and try some of the enterprise level features such as collaborative > code review, metrics and so on. Bring your laptop if you want to try Fortify > 360! > > > > For the hands on, bring your laptop, the install takes about 10-15 minutes. > We'll have installation files for Windows, Mac and Linux. > > > > You can also follow via *webex* (see below for links) > > The target audience is anyone interested in Secure Code Review with a > Static Analysis tool at the desktop level and/or enterprise level. We will > need to register visitors before hand...please email > wade.woolwine at owasp.org for registration and confirm attendance. Pizza and > refreshments will be served. > > > http://www.owasp.org/index.php/Virginia_%28Northern_Virginia%29#tab=Schedule > > > > *Location*: 22260 Pacific blvd, Sterling, VA. 20166 (AOL Office) > > Topic: OWASP Session - Fortify 360 > *Date: Thursday, September 17, 2009* > Time: 6:00 pm, Eastern Daylight Time (GMT -04:00, New York) > > Meeting Number: 487 746 568 > Meeting Password: Owasp1 > > Please click the link below to see more information, or to join the > meeting. > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to > https://cigital.webex.com/cigital/j.php?ED=126987157&UID=0&PW=f26e92a72b1b0a151a5d > 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 > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > ------ > > _______________________________________________ > Owasp-wash_dc_va mailing list > Owasp-wash_dc_va at lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_va > > _______________________________________________ > Owasp-wash_dc_va mailing list > Owasp-wash_dc_va at lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_va > > _______________________________________________ > 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: From gem at cigital.com Thu Sep 17 13:15:01 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 17 Sep 2009 13:15:01 -0400 Subject: [SC-L] Silver Bullet transcript Message-ID: <41945506397C0C4886A8C5BFF089B5CA3AFA312920@va-mailhub.cigital.com> hi sc-l, A partial transcript for Bob Blakely's silver bullet episode will be published in IEEE Security & Privacy magazine in the upcoming issue. You can read a copy yourself here: http://www.cigital.com/silverbullet/shows/silverbullet-040-bblakely.pdf gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com From list-spam at secureconsulting.net Tue Sep 22 15:25:49 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 22 Sep 2009 12:25:49 -0700 Subject: [SC-L] OT: suddenly out of work Message-ID: <4AB924BD.6020602@secureconsulting.net> Hi folks! Sorry for the off-topic traffic, but I find myself suddenly without a job today, without warning or severance. I'm currently based in Phoenix, AZ, but am open to travel or relocation. I've been published, including as the cover story for this month's ISSA Journal, have speaking experience, and have been doing this work for nigh on 15 years. Full resume is available here: http://falcon.secureconsulting.net/resume/Ben_Tomhave.pdf Thank you, and again apologies for interloping here, -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "The greatest challenge to any thinker is stating the problem in a way that will allow a solution." Bertrand Russell From gem at cigital.com Thu Sep 24 10:40:46 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 24 Sep 2009 10:40:46 -0400 Subject: [SC-L] BSIMM Begin (please take the survey today) Message-ID: hi sc-l, Today we launched BSIMM Begin, a web-based study focused on the most basic (and pervasive) BSIMM activities. The Building Security In Maturity Model (BSIMM) was released in March 2009. Since March, the BSIMM has evolved and expanded in several ways. Most importantly, the BSIMM study has added data for fourteen companies to the original nine, bringing the study total to twenty-three (with three further efforts underway). These data indicate the model as originally devised is robust enough to retain its utility well into the future. The new data include a number of companies that are also household names in verticals branching from ISVs and financial services into insurance and pharmaceuticals. Later this year, these data will be released under the Creative Commons as BSIMM II. BSIMM Europe is a study of nine large-scale European software security initiatives. Comparing the European market for software security tools and services to the US market has traditionally involved some guesswork. Data as gathered and reported in BSIMM Europe will shed plenty of light on the complexities of the real situation. We are interested in increasing the number of observations covering software security initiatives that are just getting started. To do that, we introduce BSIMM Begin, a Web-based study focused on 40 of the 110 activities covered in the full BSIMM. Even if your organization is just getting started with a software security initiative, we hope that you will participate in the BSIMM Begin study yourself. Not only will you help make the study more thorough, you'll also come away with some idea of how your basic software security activities stack up against those practiced by others. Take the survey now... http://bsi-mm.com/begin/ In fact, do what you can to get your friends and colleagues in other companies to take it too. The more data we gather the better off we'll all be. Note that BSIMM Begin does not take the place of a full BSIMM assessment in any way. The full study focuses on activities that can be used to measure and compare fairly mature, large-scale software security initiatives. By contrast, BSIMM Begin focuses on new initiatives that are just getting off the ground. BSIMM Begin data will be segregated in a separate set of results and analyzed accordingly. For more about the BSIMM Begin study, see this month's informIT article ("BSIMM Begin" http://www.informit.com/articles/article.aspx?p=1397805). This survey is best completed by someone with a working knowledge of the spectrum of software security activities actually being performed within a firm. BSIMM progress in the form of BSIMM Begin, BSIMM II, and BSIMM Europe is particularly good news for the observation-based model, which is based directly on hard data observed from the field. The more data we gather, the more we can say with confidence about the state of software security in the world. We're looking forward to the time (coming soon) when our data set reaches a size where statistically significant trends can be measured and reported. As always, your feedback is welcome. Thanks in advance for your help! 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 Sep 24 12:02:51 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Thu, 24 Sep 2009 12:02:51 -0400 Subject: [SC-L] Another WAF in town Message-ID: <9038190E-F62F-4327-BFB1-3277A61A355C@krvw.com> FYI, some activity in the open source WAF space: http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=220100630 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: 2252 bytes Desc: not available URL: From James.McGovern at thehartford.com Thu Sep 24 12:27:52 2009 From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT)) Date: Thu, 24 Sep 2009 12:27:52 -0400 Subject: [SC-L] Another WAF in town In-Reply-To: <9038190E-F62F-4327-BFB1-3277A61A355C@krvw.com> References: <9038190E-F62F-4327-BFB1-3277A61A355C@krvw.com> Message-ID: Interesting approach. Curious to know if this will satisfy a PCI auditor as a compensating control (section 6) -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Thursday, September 24, 2009 12:03 PM To: Secure Coding Subject: [SC-L] Another WAF in town FYI, some activity in the open source WAF space: http://www.darkreading.com/security/app-security/showArticle.jhtml?artic leID=220100630 Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator ************************************************************ 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 Kevin.Wall at qwest.com Thu Sep 24 16:46:47 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Thu, 24 Sep 2009 15:46:47 -0500 Subject: [SC-L] Another WAF in town In-Reply-To: References: <9038190E-F62F-4327-BFB1-3277A61A355C@krvw.com> Message-ID: > Interesting approach. Curious to know if this will satisfy a > PCI auditor as a compensating control (section 6) I think that's presently untested and therefore likely unknown. I would guess it depends on the auditor's perspective. On one had, having a separate WAF appliance provides you with separation of duties so it's harder for a dev team to configure the WAF so it accepts everything (much like I've seem some folks use a regex of ".*" for things in Struts validators that they haven't gotten around to thinking more deeply about). On the other hand, the dev team is in a much better position to truly customize the rule set to use an actual whitelist approach. The mod_security WAF approach generally leads to a signature-based, black-list approach. So I can see pros and cons to each. But for a clueful dev team, this could be a big asset if they are willing to take the time to do things right. -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 From list-spam at secureconsulting.net Thu Sep 24 17:00:50 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Thu, 24 Sep 2009 14:00:50 -0700 Subject: [SC-L] Another WAF in town In-Reply-To: References: <9038190E-F62F-4327-BFB1-3277A61A355C@krvw.com> Message-ID: <4ABBDE02.2010605@secureconsulting.net> Define "firewall" in this context, I guess, right? Something that controls network and application access, separate from the application itself? I don't recall it being defined in PCI DSS itself, so I'm sure it'll be fine so long as one can properly explain it to the QSA. :) -ben McGovern, James F (HTSC, IT) wrote: > Interesting approach. Curious to know if this will satisfy a PCI > auditor as a compensating control (section 6) > > -----Original Message----- From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk > Sent: Thursday, September 24, 2009 12:03 PM To: Secure Coding > Subject: [SC-L] Another WAF in town > > FYI, some activity in the open source WAF space: > > http://www.darkreading.com/security/app-security/showArticle.jhtml?artic > leID=220100630 > > Cheers, > > Ken > > ----- Kenneth R. van Wyk SC-L Moderator > > ************************************************************ 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. > _______________________________________________ > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "Perhaps in time the so-called Dark Ages will be thought of as including our own." Georg Christoph Lichtenberg From ivan.ristic at gmail.com Thu Sep 24 19:05:21 2009 From: ivan.ristic at gmail.com (Ivan Ristic) Date: Fri, 25 Sep 2009 00:05:21 +0100 Subject: [SC-L] Another WAF in town In-Reply-To: References: <9038190E-F62F-4327-BFB1-3277A61A355C@krvw.com> Message-ID: <1f9222b70909241605v76e48fdcpfd4b9a53017c544c@mail.gmail.com> On Thu, Sep 24, 2009 at 9:46 PM, Wall, Kevin wrote: >> Interesting approach. Curious to know if this will satisfy a >> PCI auditor as a compensating control (section 6) > > I think that's presently untested and therefore likely unknown. > I would guess it depends on the auditor's perspective. On one > had, having a separate WAF appliance provides you with separation > of duties so it's harder for a dev team to configure the WAF so > it accepts everything (much like I've seem some folks use a regex > of ".*" for things in Struts validators that they haven't gotten > around to thinking more deeply about). On the other hand, the > dev team is in a much better position to truly customize the rule > set to use an actual whitelist approach. The problem with that approach (giving developers control over WAFs) is that virtual patching and secure coding are conflicting requirements. Asking the same team to do both is only asking for trouble. I'd rather see developers focusing on the application code, with other teams handling virtual patching. Isn't the whole point of WAFs that you don't need developers to use them? > The mod_security WAF > approach generally leads to a signature-based, black-list approach. I will agree that most people use it that way, but that's only because it's the low hanging fruit: signatures catch worms and automated exploits and tools, and some offenders with minimal effort. But there's nothing fundamentally different in a Servlet filter-approach (not that I've seen this particular tool) from what ModSecurity already does. Writing white lists in ModSecurity is generally easy, and many people use them for their virtual patches. It's not the tool, it's the user who's deciding what to do. Perhaps ModSecurity is not a good representative of the WAF space for the purpose of this discussion. It was specifically designed to allow experienced users to do whatever they liked. In my experience, other WAFs don't typically offer that. From that point of view, being able to write some external-to-application Java code to fix a problem may be very tempting indeed. Still, I would be worried because if the WAF is too close to the application, the two are bound to gel over time. > -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 > > > _______________________________________________ > 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. > _______________________________________________ > -- Ivan Ristic Security assessment of your SSL servers https://www.ssllabs.com/ssldb/ From gem at cigital.com Mon Sep 28 10:08:11 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 28 Sep 2009 10:08:11 -0400 Subject: [SC-L] Silver Bullet 42: Gillian Hayes Message-ID: hi sc-l, I'm pleased to announce episode 42 of Silver Bullet---a conversation with Professor Gillian Hayes. Gillian is an informatics professor whose work focuses on the human aspects of technology, including surveillance, usability and security, and the psychology of 20-somethings. Have a listen: http://www.cigital.com/silverbullet/show-042/ Silver Bullet is a joint production of Cigital and IEEE Security & Privacy magazine. It is also syndicated by informIT. Your questions, comments and feedback on the website are welcome. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Mon Sep 28 14:35:28 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Mon, 28 Sep 2009 14:35:28 -0400 Subject: [SC-L] Automatic Generation of Control Flow Hijacking, Exploits for Software Vulnerabilities References: <4ABF2B2B.9020106@cymru.com> Message-ID: Hi SC-L, I figured the referenced dissertation below would be of some interest here. Interesting reading, IMHO. Cheers, Ken van Wyk Begin forwarded message: > From: Ian Cook > Date: September 27, 2009 5:06:51 AM EDT > Subject: [1st NEWS] [DNB] Automatic Generation of Control Flow > Hijacking, Exploits for Software Vulnerabilities > > Title: Automatic Generation of Control Flow Hijacking > Exploits for Software Vulnerabilities > Author: Sean Heelan > Source: University of Oxford > Date Published: 3rd September 2009 > > Excerpt: > > '.... > > Software bugs that result in memory corruption are a common and > dangerous feature of systems developed in certain programming > languages. Such bugs are security vulnerabilities if they can be > leveraged by an attacker to trigger the execution of malicious code. > Determining if such a possibility exists is a time consuming process > and requires technical expertise in a number of areas. Often the > only way to be sure that a bug is in fact exploitable by an attacker > is to build a complete exploit. It is this process that we seek to > automate. > > We present a novel algorithm that integrates data-flow analysis and > a decision procedure with the aim of automatically building > exploits. The exploits we generate are constructed to hijack the > control flow of an application and redirect it to malicious code. > Our algorithm is designed to build exploits for three common classes > of security vulnerability; stack-based buffer overflows that corrupt > a stored instruction pointer, buffer overflows that corrupt a > function pointer, and buffer overflows that corrupt the destination > address used by instructions that write to memory. For these > vulnerability classes we present a system capable of generating > functional exploits in the presence of complex arithmetic > modification of inputs and arbitrary constraints. Exploits are > generated using dynamic data-flow analysis in combination with a > decision procedure. To the best of our knowledge the resulting > implementation is the first to demonstrate exploit generation using > such techniques. We illustrate its effectiveness on a number > of benchmarks including a vulnerability in a large, real-world > server application......' > > To read the complete article see: > http://seanhn.files.wordpress.com/2009/09/thesis1.pdf > > For more Security News see: www.team-cymru.org/News > www.team-cymru.org/News/secnews.rss > > The opinions expressed in the posted news items do not > necessarily reflect the views of Team Cymru. > > The appearance of hyperlinks does not constitute endorsement > by Team Cymru of an external Web site, or any commercial > company, information, products or services contained therein. > > Dragon News Bytes is a Private and Restricted mailing > list. > > To subscribe to this mailing list, please signup at > https://cymru.com/mailman/listinfo/ians_dragon_newsbytes and > then send an email to: outreach at cymru.com providing some personal > background and two references, preferably from FIRST.ORG > www.first.org/members/teams > > > _ //` `\ > _,-"\% // /``\`\ > ~^~ >__^ |% // / } `\`\ Team Cymru > ) )%// / } } }`\`\ Dragon News Bytes > / (%/`/.\_/\_/\_/\`/ > ( ` `-._` > \ , ( \ _`-.__.- %> > /_`\ \ `\ \." `-..- ` > ``` /_/`"-=-``/_/ > ``` ``` > > For more Security News see: > www.team-cymru.org/News > www.youtube.com/teamcymru > http://twitter.com/teamcymru > > _____________________________________________________ > > Ian Cook > Security Evangelist > Team Cymru > www.cymru.com/contact.html > > 'To communicate simply you must understand profoundly' -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available URL: From secse-chair at sislab.no Mon Sep 28 15:39:02 2009 From: secse-chair at sislab.no (Martin Gilje Jaatun) Date: Mon, 28 Sep 2009 21:39:02 +0200 Subject: [SC-L] Deadline extended to Oct. 7 - SecSE 2010 Message-ID: <4AC110D6.6020404@sislab.no> We've extended the submission deadline of the Fourth International Workshop on Secure Software Engineering (in conjunction with ARES 2010) to October 7th. For more information, see http://sintef.org/secse From jeremy.j.epstein at gmail.com Tue Sep 29 09:49:11 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Tue, 29 Sep 2009 09:49:11 -0400 Subject: [SC-L] NSA comparison of source code analysis tools Message-ID: (Apologies if I already sent this to the group; I don't think I did.) There's an interesting presentation at http://www.iarpa.gov/stonesoup_Merced_DHSAWGbrief.pdf about a study done by the US NSA (National Security Agency) of C and Java source code analysis tools. They developed a synthetic test suite, and then ran six tools against the Java version and five tools against the C version (the specific tools and versions used are identified in the presentation). None of the tools found all of the problems, and 40% of the problems weren't found by any of the tools. Even where the problems were found, there was a surprising level of inconsistency among the tools. Unfortunately, there's not much detail in the presentation. There's a report that's been written, but so far not approved for release (or so I'm told). I don't know whether the issue is classification (they don't want the bad guys to know what sort of things can sneak past their detectors), or proprietary information, or just bureaucracy. It would be interesting to hear comments from vendors on the list as to the limitations on such a test (certainly using synthetic programs isn't realistic), as well as whether they've adapted the tools to find more of these types of problems. --Jeremy P.S. The report is undated, but I believe it's fairly recent. From colin.cassidy at ge.com Tue Sep 29 10:27:04 2009 From: colin.cassidy at ge.com (Cassidy, Colin (GE Infra, Energy)) Date: Tue, 29 Sep 2009 16:27:04 +0200 Subject: [SC-L] NSA comparison of source code analysis tools In-Reply-To: References: Message-ID: <2D3692016CCD2D4AA33741E25925EA7102EFBB8E@BUDMLVEM06.e2k.ad.ge.com> The document properties suggests June 2009, and it's a shame that there isn't much details as we are looking to evaluate 3 of the code analysis tools for our development here. CJC > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jeremy Epstein > Sent: 29 September 2009 14:49 > To: sc-l > Subject: [SC-L] NSA comparison of source code analysis tools > > (Apologies if I already sent this to the group; I don't think I did.) > > There's an interesting presentation at > http://www.iarpa.gov/stonesoup_Merced_DHSAWGbrief.pdf about a study > done by the US NSA (National Security Agency) of C and Java source > code analysis tools. They developed a synthetic test suite, and then > ran six tools against the Java version and five tools against the C > version (the specific tools and versions used are identified in the > presentation). None of the tools found all of the problems, and 40% > of the problems weren't found by any of the tools. Even where the > problems were found, there was a surprising level of inconsistency > among the tools. > > Unfortunately, there's not much detail in the presentation. There's a > report that's been written, but so far not approved for release (or so > I'm told). I don't know whether the issue is classification (they > don't want the bad guys to know what sort of things can sneak past > their detectors), or proprietary information, or just bureaucracy. > > It would be interesting to hear comments from vendors on the list as > to the limitations on such a test (certainly using synthetic programs > isn't realistic), as well as whether they've adapted the tools to find > more of these types of problems. > > --Jeremy > > P.S. The report is undated, but I believe it's fairly recent. > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4427 bytes Desc: not available URL: From Kevin.Wall at qwest.com Thu Oct 1 17:33:44 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Thu, 1 Oct 2009 16:33:44 -0500 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: Thought there might be several on this list who might appreciate this, at least from a theoretical perspective but had not seen it. (Especially Larry Kilgallen, although he's probably already seen it. :) In http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html, "Professor Gernot Heiser, the John Lions Chair in Computer Science in the School of Computer Science and Engineering and a senior principal researcher with NICTA, said for the first time a team had been able to prove with mathematical rigour that an operating-system kernel -- the code at the heart of any computer or microprocessor -- was 100 per cent bug-free and therefore immune to crashes and failures." In a new item at NICTA it mentions this proof was the effort of 6 people over 5 years (not quite sure if it was full-time) and that "They have successfully verified 7,500 lines of C code [there's the problem! -kww] and proved over 10,000 intermediate theorems in over 200,000 lines of formal proof". The proof is "machine-checked using the interactive theorem-proving program Isabelle". Also the same site mentions: The scientific paper describing this research will appear in the 22nd ACM Symposium on Operating Systems Principles (SOSP) http://www.sigops.org/sosp/sosp09/. Further details about NICTA's L4.verified research project can be found at http://ertos.nicta.com.au/research/l4.verified/. My $.02... I don't think this approach is going to catch on anytime soon. Spending 30 or so staff years verifying a 7500 line C program is not going to be seen as cost effective by most real-world managers. But interesting research nonetheless. -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 From jeremy.j.epstein at gmail.com Fri Oct 2 09:37:33 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Fri, 2 Oct 2009 09:37:33 -0400 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: This was discussed a few months ago on several other lists I read. The consensus is that it's interesting, and is further than anyone else has gone in recent years to do proofs, but not practically useful. Additionally, there are a lot of caveats on the proof (which I don't recall, but are well documented on their web site) that make it clear it's not really as useful as it might sound. --Jeremy On Thu, Oct 1, 2009 at 5:33 PM, Wall, Kevin wrote: > Thought there might be several on this list who might appreciate > this, at least from a theoretical perspective but had not seen > it. (Especially Larry Kilgallen, although he's probably already seen it. :) > > In http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html, > > ? ?"Professor Gernot Heiser, the John Lions Chair in Computer Science in > ? ?the School of Computer Science and Engineering and a senior principal > ? ?researcher with NICTA, said for the first time a team had been able to > ? ?prove with mathematical rigour that an operating-system kernel -- the > ? ?code at the heart of any computer or microprocessor -- was 100 per cent > ? ?bug-free and therefore immune to crashes and failures." > > In a new item at NICTA > > > it mentions this proof was the effort of 6 people over 5 years (not quite > sure if it was full-time) and that "They have successfully verified 7,500 > lines of C code [there's the problem! -kww] and proved over 10,000 > intermediate theorems in over 200,000 lines of formal proof". The proof is > "machine-checked using the interactive theorem-proving program Isabelle". > > Also the same site mentions: > ? ?The scientific paper describing this research will appear in the 22nd > ? ?ACM Symposium on Operating Systems Principles (SOSP) > ? ? ? ?http://www.sigops.org/sosp/sosp09/. > ? ?Further details about NICTA's L4.verified research project can be found > ? ?at http://ertos.nicta.com.au/research/l4.verified/. > > My $.02... I don't think this approach is going to catch on anytime soon. > Spending 30 or so staff years verifying a 7500 line C program is not going > to be seen as cost effective by most real-world managers. But interesting > research nonetheless. > > -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 > > _______________________________________________ > 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 colin.cassidy at ge.com Fri Oct 2 09:47:53 2009 From: colin.cassidy at ge.com (Cassidy, Colin (GE Infra, Energy)) Date: Fri, 2 Oct 2009 15:47:53 +0200 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: <2D3692016CCD2D4AA33741E25925EA7102EFBBA7@BUDMLVEM06.e2k.ad.ge.com> I have a few concerns with formal proofs particularly applying them in a non-academic environment (some of which may be my own na?ve lack of understanding and my feeble memory of my university years studying formal methods). Firstly whilst the code provably does what you said that it would do, that does not mean that what you said the code should do is necessarily correct. As Gary McGraw has pointed out 50% of security issues are bugs, 50% are design flaws. So we have only removed 50% of the problem. Secondly, as you pointed out, that is an awful lot of effort in terms of man years for what is essentially a small program and I don?t think it will scale well Thirdly, I suspect this is one of those processes that is easier to apply to greenfield development, I don?t think many developers will have that luxury. In conclusion, it seems an awful effort to fix half the problem, I'd expect, though cant prove, that a combination of other secure development processes working together will get better results with less overall effort. CJC > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Wall, Kevin > Sent: 01 October 2009 22:34 > To: Secure Code Mailing List > Subject: [SC-L] Provably correct microkernel (seL4) > > Thought there might be several on this list who might appreciate > this, at least from a theoretical perspective but had not seen > it. (Especially Larry Kilgallen, although he's probably > already seen it. :) > > In > http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_ > breakthrough.html, > > "Professor Gernot Heiser, the John Lions Chair in > Computer Science in > the School of Computer Science and Engineering and a > senior principal > researcher with NICTA, said for the first time a team had > been able to > prove with mathematical rigour that an operating-system > kernel -- the > code at the heart of any computer or microprocessor -- > was 100 per cent > bug-free and therefore immune to crashes and failures." > > In a new item at NICTA > > > it mentions this proof was the effort of 6 people over 5 > years (not quite > sure if it was full-time) and that "They have successfully > verified 7,500 > lines of C code [there's the problem! -kww] and proved over 10,000 > intermediate theorems in over 200,000 lines of formal proof". > The proof is > "machine-checked using the interactive theorem-proving > program Isabelle". > > Also the same site mentions: > The scientific paper describing this research will appear > in the 22nd > ACM Symposium on Operating Systems Principles (SOSP) > http://www.sigops.org/sosp/sosp09/. > Further details about NICTA's L4.verified research > project can be found > at http://ertos.nicta.com.au/research/l4.verified/. > > My $.02... I don't think this approach is going to catch on > anytime soon. > Spending 30 or so staff years verifying a 7500 line C program > is not going > to be seen as cost effective by most real-world managers. But > interesting > research nonetheless. > > -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 > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4427 bytes Desc: not available URL: From ljknews at mac.com Fri Oct 2 09:46:09 2009 From: ljknews at mac.com (ljknews) Date: Fri, 02 Oct 2009 09:46:09 -0400 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: At 4:33 PM -0500 10/1/09, Wall, Kevin wrote: > "Professor Gernot Heiser, the John Lions Chair in Computer Science in > the School of Computer Science and Engineering and a senior principal > researcher with NICTA, said for the first time a team had been able to > prove with mathematical rigour that an operating-system kernel -- the > code at the heart of any computer or microprocessor -- was 100 per cent > bug-free and therefore immune to crashes and failures." Reading nothing beyond what was posted, the problem I see is to provide a complete specification against which to prove correctness. -- Larry Kilgallen From yo at secappdev.org Fri Oct 2 12:50:55 2009 From: yo at secappdev.org (Johan Peeters) Date: Fri, 2 Oct 2009 18:50:55 +0200 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: <25b6e5cf0910020950p19c12059h491e6b190e902ddc@mail.gmail.com> > My $.02... I don't think this approach is going to catch on anytime soon. > Spending 30 or so staff years verifying a 7500 line C program is not going > to be seen as cost effective by most real-world managers. But interesting > research nonetheless. maybe not as crazy as it sounds: this is a micro kernel and hence a security chokepoint. The other stuff running on top do not need the same level of assurance. kr, Yo -- Johan Peeters http://johanpeeters.com From ddefigue at adobe.com Fri Oct 2 12:54:21 2009 From: ddefigue at adobe.com (Dimitri DeFigueiredo) Date: Fri, 2 Oct 2009 09:54:21 -0700 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: There is a proof for a whole kernel I can use today. How's that not practically useful? Is it not practically useful because there are caveats on the proof? I don't we can just dismiss this one without further reasoning or because we don't know how to apply it to our own problems. Dimitri -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jeremy Epstein Sent: Friday, October 02, 2009 6:38 AM To: Wall, Kevin Cc: Secure Code Mailing List Subject: Re: [SC-L] Provably correct microkernel (seL4) This was discussed a few months ago on several other lists I read. The consensus is that it's interesting, and is further than anyone else has gone in recent years to do proofs, but not practically useful. Additionally, there are a lot of caveats on the proof (which I don't recall, but are well documented on their web site) that make it clear it's not really as useful as it might sound. --Jeremy On Thu, Oct 1, 2009 at 5:33 PM, Wall, Kevin wrote: > Thought there might be several on this list who might appreciate > this, at least from a theoretical perspective but had not seen > it. (Especially Larry Kilgallen, although he's probably already seen it. :) > > In http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html, > > ? ?"Professor Gernot Heiser, the John Lions Chair in Computer Science in > ? ?the School of Computer Science and Engineering and a senior principal > ? ?researcher with NICTA, said for the first time a team had been able to > ? ?prove with mathematical rigour that an operating-system kernel -- the > ? ?code at the heart of any computer or microprocessor -- was 100 per cent > ? ?bug-free and therefore immune to crashes and failures." > > In a new item at NICTA > > > it mentions this proof was the effort of 6 people over 5 years (not quite > sure if it was full-time) and that "They have successfully verified 7,500 > lines of C code [there's the problem! -kww] and proved over 10,000 > intermediate theorems in over 200,000 lines of formal proof". The proof is > "machine-checked using the interactive theorem-proving program Isabelle". > > Also the same site mentions: > ? ?The scientific paper describing this research will appear in the 22nd > ? ?ACM Symposium on Operating Systems Principles (SOSP) > ? ? ? ?http://www.sigops.org/sosp/sosp09/. > ? ?Further details about NICTA's L4.verified research project can be found > ? ?at http://ertos.nicta.com.au/research/l4.verified/. > > My $.02... I don't think this approach is going to catch on anytime soon. > Spending 30 or so staff years verifying a 7500 line C program is not going > to be seen as cost effective by most real-world managers. But interesting > research nonetheless. > > -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 > > _______________________________________________ > 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 jeremy.j.epstein at gmail.com Fri Oct 2 13:01:28 2009 From: jeremy.j.epstein at gmail.com (Jeremy Epstein) Date: Fri, 2 Oct 2009 13:01:28 -0400 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: Caveats on the proofs, as I recall. I'll try to dig up the details. It's been pretty extensively discussed elsewhere... On Fri, Oct 2, 2009 at 12:54 PM, Dimitri DeFigueiredo wrote: > There is a proof for a whole kernel I can use today. How's that not practically useful? Is it not practically useful because there are caveats on the proof? I don't we can just dismiss this one without further reasoning or because we don't know how to apply it to our own problems. > > Dimitri > > -----Original Message----- > From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jeremy Epstein > Sent: Friday, October 02, 2009 6:38 AM > To: Wall, Kevin > Cc: Secure Code Mailing List > Subject: Re: [SC-L] Provably correct microkernel (seL4) > > This was discussed a few months ago on several other lists I read. > The consensus is that it's interesting, and is further than anyone > else has gone in recent years to do proofs, but not practically > useful. ?Additionally, there are a lot of caveats on the proof (which > I don't recall, but are well documented on their web site) that make > it clear it's not really as useful as it might sound. > > --Jeremy > > On Thu, Oct 1, 2009 at 5:33 PM, Wall, Kevin wrote: >> Thought there might be several on this list who might appreciate >> this, at least from a theoretical perspective but had not seen >> it. (Especially Larry Kilgallen, although he's probably already seen it. :) >> >> In http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html, >> >> ? ?"Professor Gernot Heiser, the John Lions Chair in Computer Science in >> ? ?the School of Computer Science and Engineering and a senior principal >> ? ?researcher with NICTA, said for the first time a team had been able to >> ? ?prove with mathematical rigour that an operating-system kernel -- the >> ? ?code at the heart of any computer or microprocessor -- was 100 per cent >> ? ?bug-free and therefore immune to crashes and failures." >> >> In a new item at NICTA >> >> >> it mentions this proof was the effort of 6 people over 5 years (not quite >> sure if it was full-time) and that "They have successfully verified 7,500 >> lines of C code [there's the problem! -kww] and proved over 10,000 >> intermediate theorems in over 200,000 lines of formal proof". The proof is >> "machine-checked using the interactive theorem-proving program Isabelle". >> >> Also the same site mentions: >> ? ?The scientific paper describing this research will appear in the 22nd >> ? ?ACM Symposium on Operating Systems Principles (SOSP) >> ? ? ? ?http://www.sigops.org/sosp/sosp09/. >> ? ?Further details about NICTA's L4.verified research project can be found >> ? ?at http://ertos.nicta.com.au/research/l4.verified/. >> >> My $.02... I don't think this approach is going to catch on anytime soon. >> Spending 30 or so staff years verifying a 7500 line C program is not going >> to be seen as cost effective by most real-world managers. But interesting >> research nonetheless. >> >> -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 >> >> _______________________________________________ >> 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 Fri Oct 2 15:21:24 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Fri, 2 Oct 2009 14:21:24 -0500 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: <2D3692016CCD2D4AA33741E25925EA7102EFBBA7@BUDMLVEM06.e2k.ad.ge.com> References: <2D3692016CCD2D4AA33741E25925EA7102EFBBA7@BUDMLVEM06.e2k.ad.ge.com> Message-ID: > > design flaws. So we have only removed 50% of the problem. for my part there have been many, many days when I would settle for solving 50% of a problem -gunnar From coley at linus.mitre.org Fri Oct 2 16:15:53 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 2 Oct 2009 16:15:53 -0400 (EDT) Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: I wonder what would happen if somebody offered $10000 to the first applied researcher to find a fault or security error. According to http://ertos.nicta.com.au/research/l4.verified/proof.pml, buffer overflows, memory leaks, and other issues are not present. Maybe people would give up if they don't gain some quick results, but it seems like you'd want to sanity-check the claims using alternate techniques. - Steve From b.g.miller at gmail.com Fri Oct 2 16:59:48 2009 From: b.g.miller at gmail.com (Bobby Miller) Date: Fri, 2 Oct 2009 13:59:48 -0700 Subject: [SC-L] Provably correct microkernel (seL4) Message-ID: <14dfe02d0910021359l15269b74hd4c2d13333adf424@mail.gmail.com> I might argue that it may fix problems that aren't fixable otherwise. My experience in this area is very old, but I found that the biggest benefit of formal methods was not so much the proof but the flaws discovered and fixed on the way to the proof. > In conclusion, it seems an awful effort to fix half the problem, I'd > expect, > though cant prove, that a combination of other secure development processes > working together will get better results with less overall effort. > > CJC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Wall at qwest.com Fri Oct 2 17:20:27 2009 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Fri, 2 Oct 2009 16:20:27 -0500 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: , Message-ID: Steve Christy wrote... > I wonder what would happen if somebody offered $10000 to the first applied > researcher to find a fault or security error. According to > http://ertos.nicta.com.au/research/l4.verified/proof.pml, buffer > overflows, memory leaks, and other issues are not present. Maybe people > would give up if they don't gain some quick results, but it seems like > you'd want to sanity-check the claims using alternate techniques. I was actually wondering how they could make that statement unless they can somehow ensure that other components running in kernel mode (e.g., maybe devices doing DMA or device drivers, etc.) can't overwrite the microkernel's memory address space. It's been 20+ years since I've done any kernel hacking, but back in the day, doing something like that with the MMU I think would have been prohibitively expensive in terms of resources. I've not read through the formal proof (figuring I probably wouldn't understand most of it anyhow; it's been 30+ years since my last math class so those brain cells are a bit crusty ;-) but maybe that was one of the "caveats" that Colin Cassidy referred to. In the real world though, that doesn't seem like a very reasonable assumption. Maybe today's MMUs support this somehow or perhaps the seL4 microkernel runs in kernel mode and the rest of the OS and any DMA devices run in a different address space such as a "supervisory" mode. Can anyone who has read the nitty-gritty details explain it to someone whose brain cells in these areas have suffered significant bit rot? -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME From cwysopal at Veracode.com Fri Oct 2 19:51:11 2009 From: cwysopal at Veracode.com (Chris Wysopal) Date: Fri, 2 Oct 2009 19:51:11 -0400 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: <2D3692016CCD2D4AA33741E25925EA7102EFBBA7@BUDMLVEM06.e2k.ad.ge.com> Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD01F7787548@orbital.Veracode.local> And presumably before they spent many man years proving implementation correctness they could have spent a fraction of that on design review and subsequent design corrections. -Chris -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson Sent: Friday, October 02, 2009 3:21 PM To: Cassidy, Colin (GE Infra, Energy) Cc: Secure Code Mailing List Subject: Re: [SC-L] Provably correct microkernel (seL4) > > design flaws. So we have only removed 50% of the problem. for my part there have been many, many days when I would settle for solving 50% of a problem -gunnar _______________________________________________ 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 yo at secappdev.org Sat Oct 3 11:19:06 2009 From: yo at secappdev.org (Johan Peeters) Date: Sat, 3 Oct 2009 17:19:06 +0200 Subject: [SC-L] Provably correct microkernel (seL4) In-Reply-To: References: Message-ID: <25b6e5cf0910030819i99cbadfi5382276f18727b4d@mail.gmail.com> It is my understanding that only the micro-kernel runs in kernel mode, but not having read the nitty-gritty either, I'll stand to be corrected. kr, Yo On Fri, Oct 2, 2009 at 11:20 PM, Wall, Kevin wrote: > Steve Christy wrote... > >> I wonder what would happen if somebody offered $10000 to the first applied >> researcher to find a fault or security error. ?According to >> http://ertos.nicta.com.au/research/l4.verified/proof.pml, buffer >> overflows, memory leaks, and other issues are not present. ?Maybe people >> would give up if they don't gain some quick results, but it seems like >> you'd want to sanity-check the claims using alternate techniques. > > I was actually wondering how they could make that statement unless they > can somehow ensure that other components running in kernel mode (e.g., > maybe devices doing DMA or device drivers, etc.) can't overwrite the > microkernel's memory address space. It's been 20+ years since I've done > any kernel hacking, but back in the day, doing something like that with > the MMU I think would have been prohibitively expensive in terms of > resources. I've not read through the formal proof (figuring I probably > wouldn't understand most of it anyhow; it's been 30+ years since my > last math class so those brain cells are a bit crusty ;-) but maybe that > was one of the "caveats" that Colin Cassidy referred to. In the real world though, > that doesn't seem like a very reasonable assumption. Maybe today's MMUs > support this somehow or perhaps the seL4 microkernel runs in kernel mode > and the rest of the OS and any DMA devices run in a different address > space such as a "supervisory" mode. Can anyone who has read the nitty-gritty > details explain it to someone whose brain cells in these areas have > suffered significant bit rot? > > -kevin > -- > Kevin W. Wall ? 614.215.4788 ? ? ? ? ? ?Application Security Team / Qwest IT > "The most likely way for the world to be destroyed, most experts agree, > is by accident. That's where we come in; we're computer professionals. > We cause accidents." ? ? ? ?-- Nathaniel Borenstein, co-creator of MIME > _______________________________________________ > 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 tomb at owasp.org Sat Oct 3 12:37:04 2009 From: tomb at owasp.org (Tom Brennan - OWASP) Date: Sat, 3 Oct 2009 12:37:04 -0400 Subject: [SC-L] OWASP Summit / Elections Message-ID: The next global summit for OWASP Foundation Inc (www.owasp.org) will be held on November 11th 2009 (Veterans Day in the USA) in Washington, DC., USA As is customary at our summits we will govern by rough consensus and collaborate face to face town hall style for our professional associations direction. http://www.owasp.org/index.php/Summit_2009 Just one of the many shaping activities that will take place will be, the first democratic ELECTION of a OWASP Board Member by the membership.? Eligible individuals have already volunteered time, served as a project leader and or chapter leader and have have demonstrated global leadership acumen as a current and active member of a Global Committee.?? You will hear from each of these candidates during the town hall session of why they are the best person for the role. If you have never attended a OWASP Summit (such as Portugal 2008 http://www.owasp.org/index.php/OWASP_EU_Summit_2008 ) you will not want to miss this event - when you get passion filled OWASP people together we come together as a community to set the direction for the next 6,12,24 months and we need you to get involved to continue our mission. Semper Fi, Tom Brennan OWASP Foundation 973.506.9303 About OWASP - http://www.owasp.org/index.php/About_OWASP - 2009 OWASP Summit http://www.owasp.org/index.php/Summit_2009 From karger at watson.ibm.com Mon Oct 5 08:56:30 2009 From: karger at watson.ibm.com (karger at watson.ibm.com) Date: Mon, 05 Oct 2009 08:56:30 -0400 Subject: [SC-L] Provably correct microkerne Message-ID: <20091005125630.BB7DB36E513@gsal-1.watson.ibm.com> Bobby Miller writes: > >I might argue that it may fix problems that aren't fixable otherwise. >My experience in this area is very old, but I found that the biggest benefit >of formal methods was not so much the proof but the flaws discovered and >fixed on the way to the proof. > > > >> In conclusion, it seems an awful effort to fix half the problem, I'd >> expect, >> though cant prove, that a combination of other secure development processes >> working together will get better results with less overall effort. >> >> CJC >> >> The significance of this result has to be understood in the context of building high-assurance software. In no way are proofs of correctness the end of the story on the security of a particular piece of software. After all, even proofs can and do have bugs. If you look at how the Orange Book, the ITSEC, and the Common Criteria approach high-assurance security, formal methods are just one part of the solution. My own experience can confirm that just constructing the formal specifications without even a single proof can turn up serious problems. I've seen this multiple times on completely different high-assurance systems. Achieving a high degree of confidence in the attack-resistance of a particular piece of software requires MANY kinds of efforts - careful design, careful written specifications, strong coding practices, extensive testing and penetration analysis, formal modeling, formal specification, proofs of specs back to modules, and what NICTA has demonstrated, proof of code back to specifications. No one of these techniques by itself is the magic bullet. You need to apply ALL of them. Note that this is also why I question the validity of so-called "proof carrying code". This approach places ALL reliance on the proofs, and as I said, proofs often have bugs! The Common Criteria approach of using proofs in conjunction with lots of other software engineering techniques seems much stronger to me. The point of proving a microkernel is that if you can show that the microkernel is secure, then you don't have to prove many properties about software that runs on top of it. But even that doesn't mean that you don't have to prove anything about upper level software. If the micro-kernel security policy is sufficient to meet all your security needs, then that is sufficient. In particular, protection of secret information is a policy that can be enforced by a microkernel, or (using the term that I prefer) a security kernel. The Bell and LaPadula model is such a policy that can be completely enforced by such a security kernel (modulo covert and side channels, of course). On the other hand, a security kernel cannot enforce a security policy that requires application correctness, such as protection of financial transactions. To do that, you have to prove properties about the transactions themselves. (At the least, that if you add 2 + 2, that you actually get 4.) Clark and Wilson showed that distinction in their classic paper. Clark, D.D. and D.R. Wilson. A Comparison of Commercial and Military Computer Security Policies. in 1987 IEEE Symposium on Security and Privacy. 27-29 April 1987, Oakland, CA: IEEE Computer Society. p. 184-194. What the folks at NICTA have accomplished is very significant - the first time that a full microkernel has been proven at the code level. Earlier such proofs were all at the formal specification level. This type of code proof is what the original Orange Book talked about as "beyond A1". The most interesting next step would be to take the seL4 microkernel (with its proofs) and conduct an EAL7 Common Criteria evaluation of it in a real system context, and to determine what new requirements could be met in a future EAL8 evaluation. Paul Karger From listas at sapao.net Tue Oct 6 18:46:12 2009 From: listas at sapao.net (Lucas Ferreira) Date: Tue, 6 Oct 2009 19:46:12 -0300 Subject: [SC-L] AppSec Brasil 2009 - Call for participation In-Reply-To: <245770850909261105j516004f2j1be47c8bf237cbf1@mail.gmail.com> References: <245770850909261105j516004f2j1be47c8bf237cbf1@mail.gmail.com> Message-ID: <245770850910061546w584556a4y669e848196cf05d3@mail.gmail.com> *AppSec Brasil 2009 * *Call for Participation * *International Conference on Application Security,* sponsored by TI-Controle Community and the Brazilian Chamber of Deputies, in partnership with OWASP and support from the University of Bras?lia, UnB. The Computing Centre of the Brazilian Chamber of Deputies and TI-Controle invite all interest parties to attend AppSec Brasil 2009, which will happen in Bras?lia, Brazil, from October 27th to October 30th 2009. The Conference comprises training sessions on October 27th and 28th, followed by plenary sessions on October 29th and 30th 2009. *Keynotes* Dr. Gary McGraw, CTO, Cigital Inc. *The Building Security In Maturity Model(BSIMM)* Jason Li, Aspect Security *Agile and Secure: Can we do both?* Dinis Cruz, OWASP Board *OWASP* Project Overview Kuai Hinojosa, NY University e OWASP *Implementing Secure Web Applications using OWASP Resources* *Selected talks* The Conference will have several technical talks on several aspects of Application Security. Some of the subjects are: - Web Application Security - Security expenses optimaization - SQL Ownage - Tools *Trianing Sessions* The Conference will also present 5 training sessions: - Gest?o de Riscos de Seguran?a Aplicada a Web Services (in Portuguese) - Seguran?a Web: T?cnicas para Programa??o Segura de Aplica??es (in Portuguese) - Seguran?a Computacional no Desenvolvimento de Web Services (in Portuguese) - Tecnologias de Seguran?a em Web Services (in Portuguese) - Hands on Web Application Testing using the OWASP Testing Guide (in English) *Location* The conference will be at the Brazilian Chamber of Deputies, in Bras?lia. The plenary sessions will occur at Audit?rio Nereu Ramos, Anexo II. The training sessions will be at the Centro de Forma??o, Treinamento e Aperfei?oamento. *Registration* Thanks to the sponsors, there will be no fee to attend the Conference, but registration will be required to avoid overcrowding the auditorium. Registration will be open beginning September 29th, 2009, at the URL: http://www.camara.gov.br/appsecbrasil2009 *More Information* For more information, please consult the web sites listed below or write to appsec.brasil at camara.gov.br Registration and general information: http://www.camara.gov.br/appsecbrasil2009 TI-Controle Community: http://www.ticontrole.gov.br Chamber of Deputies: http://www.camara.gov.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From gem at cigital.com Thu Oct 8 15:06:33 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 8 Oct 2009 15:06:33 -0400 Subject: [SC-L] Reality Check 9: The Hartford Message-ID: hi sc-l, This time a familiar sc-l/OWASP face, James McGovern from the Hartford, is the Reality Check victim. Actually, he tag teams the show with Bob Briggs also from the Hartford. We discuss the Hartford's approach to enterprise software security. You may recall that a few Silver Bullet episodes ago James interviewed me. This time it was my turn to ask the questions: http://www.cigital.com/realitycheck/show-009/ In other news, we're ramping up the push on BSIMM Begin. Please take the survey today and ask your colleagues in other companies to do the same. James wins the prize for being the first person to complete the survey! Thank you James. http://bsi-mm.com Press release: http://www.cigital.com/news/index.php?pg=art&artid=163 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 Oct 12 12:55:02 2009 From: gunnar at arctecgroup.net (Gunnar Peterson) Date: Mon, 12 Oct 2009 11:55:02 -0500 Subject: [SC-L] Genotypes and Phenotypes Message-ID: <5DACC237-B8D0-40F8-94FE-FE1877302435@arctecgroup.net> Its been awhile since there was a bugs vs flaws debate, so here is a snippet from Jaron Lanier Q: What's wrong with the way we create software today? A: I think the whole way we write and think about software is wrong. If you look at how things work right now, it's strange -- nobody -- and I mean nobody -- can really create big programs in a reliable way. If we don't find a different way of thinking about and creating software, we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become. [After publication of this interview, Jaron Lanier realized that his sentence should read: "bigger than about 20 to 30 million lines of code...".] This current lack of scalability is a universal burden. There are monopolies in our industry because it's so difficult for anyone to even enter the competition; it's so hard to write large software applications. And that's strange to me. If you look at other things that people build, like oil refineries, or commercial aircraft, we can deal with complexity much more effectively than we can with software. The problem with software is that we've never learned how to control the side effects of choices, which we call bugs. We shouldn't be complacent about that. I still believe that there are ideas waiting to be created, and that someday we will have new ways of writing software that will overcome these problems. And that's my principal professional interest. I want to make a contribution to making bugs go away. Q:Aren't bugs just a limitation of human minds? A: No, no, they're not. What's the difference between a bug and a variation or an imperfection? If you think about it, if you make a small change to a program, it can result in an enormous change in what the program does. If nature worked that way, the universe would crash all the time. Certainly there wouldn't be any evolution or life. There's something about the way complexity builds up in nature so that if you have a small change, it results in sufficiently small results; it's possible to have incremental evolution. Right now, we have a little bit -- not total -- but a little bit of linearity in the connection between genotype and phenotype, if you want to speak in those terms. But in software, there's a chaotic relationship between the source code (the "genotype") and the observed effects of programs -- what you might call the "phenotype" of a program. And that chaos is really what gets us. I don't know if I'll ever have a good idea about how to fix that. I'm working on some things, but you know, what most concerns me is what amounts to a lack of faith among programmers that the problem can even be addressed. There's been a sort of slumping into complacency over the last couple of decades. More and more, as new generations of programmers come up, there's an acceptance that this is the way things are and will always be. Perhaps that's true. Perhaps there's no avoiding it, but that's not a given. To me, this complacency about bugs is a dark cloud over all programming work. -gunnar From b.g.miller at gmail.com Tue Oct 13 12:22:22 2009 From: b.g.miller at gmail.com (Bobby Miller) Date: Tue, 13 Oct 2009 09:22:22 -0700 Subject: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) Message-ID: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> The obvious difference is "parts". In manufacturing, things are assembled from well-known, well-specified, tested parts. Hmmm.... > ... If you look at other things > that people build, like oil refineries, or commercial aircraft, we can > deal with complexity much more effectively than we can with software. > The problem with software is that we've never learned how to control > the side effects of choices, which we call bugs. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurwein at gmail.com Tue Oct 13 15:52:11 2009 From: saurwein at gmail.com (=?ISO-8859-1?Q?Andreas_Saurwein_Franci_Gon=E7alves?=) Date: Tue, 13 Oct 2009 16:52:11 -0300 Subject: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) In-Reply-To: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> References: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> Message-ID: Thats the idea of libraries. Well known, well specified, well tested parts. Well, whatever. 2009/10/13 Bobby Miller > The obvious difference is "parts". In manufacturing, things are assembled > from well-known, well-specified, tested parts. Hmmm.... > > >> ... If you look at other things >> that people build, like oil refineries, or commercial aircraft, we can >> deal with complexity much more effectively than we can with software. >> The problem with software is that we've never learned how to control >> the side effects of choices, which we call bugs. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From secureCoding2dave at davearonson.com Wed Oct 14 07:36:52 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Wed, 14 Oct 2009 07:36:52 -0400 Subject: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) In-Reply-To: References: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> Message-ID: <3f4922c70910140436g2226ef24w5608fe2d40349bcb@mail.gmail.com> Andreas Saurwein Franci Gon?alves wrote (rearranged into correct order): > 2009/10/13 Bobby Miller >> >> The obvious difference is "parts". In manufacturing, things are assembled >> from well-known, well-specified, tested parts. Hmmm.... > Thats the idea of libraries. Well known, well specified, well tested parts. > Well, whatever. Ideally, yes. However, programmers love to reinvent the wheel. It's MUCH easier, both to do and to get away with, in software than in hardware... and often necessary. Need a bolt of at least a given length and strength, less than a given diameter? There are standard thread sizes, and people make bolts of most common threadings and lengths, for purchase at reasonable prices, at places easily found, and you can be fairly certain that any given one of them will do the job quite well. Need a function for your program? If it's as common as a bolt, it's probably already built into the very language. If it's nearly as common, maybe there's a fairly standard library for it... and if you're very lucky, it's not too buggy or brittle. Otherwise, it's probably going to be much cheaper (which is all your management probably cares about) to just code the damn thing yourself, than to research who makes such a thing, which ones there are, who says which one is how reliable, which ones have licensing terms your company finds palatable, and justifying your choice to management. Lord help you if it requires money, because then you have to justify it to a higher degree, get the beancounters involved, budgetary authority from possibly multiple layers of manglement, and spend the rest of your days filling out purchase orders. If you do wind up coding it yourself, is the company then going to make that piece of functionality available to the world separately, whether for profit or open source? N times out of N+1, for very large values of N, no way! Will they at least make it available *internally*, so that *they* don't have to reinvent the wheel *next* time? Again, N times out of N+1, for almost as large values of N, no. -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. From saurwein at gmail.com Wed Oct 14 09:48:57 2009 From: saurwein at gmail.com (=?ISO-8859-1?Q?Andreas_Saurwein_Franci_Gon=E7alves?=) Date: Wed, 14 Oct 2009 10:48:57 -0300 Subject: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) In-Reply-To: <3f4922c70910140436g2226ef24w5608fe2d40349bcb@mail.gmail.com> References: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> <3f4922c70910140436g2226ef24w5608fe2d40349bcb@mail.gmail.com> Message-ID: 2009/10/14 SC-L Reader Dave Aronson > Andreas Saurwein Franci Gon?alves wrote > (rearranged into correct order): > > > 2009/10/13 Bobby Miller > >> > >> The obvious difference is "parts". In manufacturing, things are > assembled > >> from well-known, well-specified, tested parts. Hmmm.... > > > Thats the idea of libraries. Well known, well specified, well tested > parts. > > Well, whatever. > > Ideally, yes. However, programmers love to reinvent the wheel. It's > MUCH easier, both to do and to get away with, in software than in > hardware... and often necessary. > > Need a bolt of at least a given length and strength, less than a given > diameter? There are standard thread sizes, and people make bolts of > most common threadings and lengths, for purchase at reasonable prices, > at places easily found, and you can be fairly certain that any given > one of them will do the job quite well. > > Need a function for your program? If it's as common as a bolt, it's > probably already built into the very language. If it's nearly as > common, maybe there's a fairly standard library for it... and if > you're very lucky, it's not too buggy or brittle. Otherwise, it's > probably going to be much cheaper (which is all your management > probably cares about) to just code the damn thing yourself, than to > research who makes such a thing, which ones there are, who says which > one is how reliable, which ones have licensing terms your company > finds palatable, and justifying your choice to management. Lord help > you if it requires money, because then you have to justify it to a > higher degree, get the beancounters involved, budgetary authority from > possibly multiple layers of manglement, and spend the rest of your > days filling out purchase orders. > > If you do wind up coding it yourself, is the company then going to > make that piece of functionality available to the world separately, > whether for profit or open source? N times out of N+1, for very large > values of N, no way! > > Will they at least make it available *internally*, so that *they* > don't have to reinvent the wheel *next* time? Again, N times out of > N+1, for almost as large values of N, no. > > -Dave > Exactly thats the point. Going a bit further, for every piece of hardware engineering, there is almost always a legal, worldwide or at least national standard to follow. This is inexistent in software. As long as anybody with at least one healthy finger is allowed to write and sell software, the current situation will not change. Make software development an engineering discipline with all the rights and obligations of other engineering sciences. No more coding without a license. Point. This would change the landscape of bits and bytes in a dramatic way. But it requires the support of the governments worldwide. My 2 cents (me too would have to get back to college and study some more, although having 25+ years of software development experience) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwysopal at Veracode.com Thu Oct 15 17:11:49 2009 From: cwysopal at Veracode.com (Chris Wysopal) Date: Thu, 15 Oct 2009 17:11:49 -0400 Subject: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) In-Reply-To: References: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> <3f4922c70910140436g2226ef24w5608fe2d40349bcb@mail.gmail.com> Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD01FAEFFC5A@orbital.Veracode.local> This seems to boil down to an economics problem. Notice how quickly the bean counters showed up after the thread began with a discussion of bugs and complexity. It is just too inexpensive to create new code and there isn't enough economic pain when it fails for anything to change for most software. In certain cases like aircraft where the economic pain of failure is high you get DO-178B, Software Considerations in Airborne Systems and Equipment Certification. For that type of software you might see the purchase of highly reliable libraries that have also met that certification. -Chris From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Andreas Saurwein Franci Gon?alves Sent: Wednesday, October 14, 2009 9:49 AM To: Secure Coding List Subject: Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) 2009/10/14 SC-L Reader Dave Aronson > Andreas Saurwein Franci Gon?alves > wrote (rearranged into correct order): > 2009/10/13 Bobby Miller > >> >> The obvious difference is "parts". In manufacturing, things are assembled >> from well-known, well-specified, tested parts. Hmmm.... > Thats the idea of libraries. Well known, well specified, well tested parts. > Well, whatever. Ideally, yes. However, programmers love to reinvent the wheel. It's MUCH easier, both to do and to get away with, in software than in hardware... and often necessary. Need a bolt of at least a given length and strength, less than a given diameter? There are standard thread sizes, and people make bolts of most common threadings and lengths, for purchase at reasonable prices, at places easily found, and you can be fairly certain that any given one of them will do the job quite well. Need a function for your program? If it's as common as a bolt, it's probably already built into the very language. If it's nearly as common, maybe there's a fairly standard library for it... and if you're very lucky, it's not too buggy or brittle. Otherwise, it's probably going to be much cheaper (which is all your management probably cares about) to just code the damn thing yourself, than to research who makes such a thing, which ones there are, who says which one is how reliable, which ones have licensing terms your company finds palatable, and justifying your choice to management. Lord help you if it requires money, because then you have to justify it to a higher degree, get the beancounters involved, budgetary authority from possibly multiple layers of manglement, and spend the rest of your days filling out purchase orders. If you do wind up coding it yourself, is the company then going to make that piece of functionality available to the world separately, whether for profit or open source? N times out of N+1, for very large values of N, no way! Will they at least make it available *internally*, so that *they* don't have to reinvent the wheel *next* time? Again, N times out of N+1, for almost as large values of N, no. -Dave Exactly thats the point. Going a bit further, for every piece of hardware engineering, there is almost always a legal, worldwide or at least national standard to follow. This is inexistent in software. As long as anybody with at least one healthy finger is allowed to write and sell software, the current situation will not change. Make software development an engineering discipline with all the rights and obligations of other engineering sciences. No more coding without a license. Point. This would change the landscape of bits and bytes in a dramatic way. But it requires the support of the governments worldwide. My 2 cents (me too would have to get back to college and study some more, although having 25+ years of software development experience) -------------- next part -------------- An HTML attachment was scrubbed... URL: From secureCoding2dave at davearonson.com Fri Oct 16 08:21:26 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Fri, 16 Oct 2009 08:21:26 -0400 Subject: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) In-Reply-To: <5A9D3476391AD649B24ED4F9FDA2A8DD01FAEFFC5A@orbital.Veracode.local> References: <14dfe02d0910130922y14fa4f0fm809ae823c6e09cc9@mail.gmail.com> <3f4922c70910140436g2226ef24w5608fe2d40349bcb@mail.gmail.com> <5A9D3476391AD649B24ED4F9FDA2A8DD01FAEFFC5A@orbital.Veracode.local> Message-ID: <3f4922c70910160521n1ef2b8a9ncd724db62d7f0260@mail.gmail.com> Chris Wysopal wrote: > In certain cases like aircraft where the economic pain of failure > is high you get DO-178B, Software Considerations in Airborne Systems and > Equipment Certification. For that type of software you might see the > purchase of highly reliable libraries that have also met that certification. Good point! That's like how my former employer (BAE Systems) relied for sales on those who NEEDED a data guard (or whatever) to be on a platform that passed high levels of common criteria evaluation. If it weren't for that, similar software would have run just fine under Linux (even without SE) or even Windows. -Dave -- Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII -------------------------------------+ Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From secureCoding2dave at davearonson.com Fri Oct 16 08:24:31 2009 From: secureCoding2dave at davearonson.com (SC-L Reader Dave Aronson) Date: Fri, 16 Oct 2009 08:24:31 -0400 Subject: [SC-L] new job! Message-ID: <3f4922c70910160524q6cd5cfb9oda3dac1262de1c63@mail.gmail.com> Since the Power that Be let me post my plea for job help, I figured I'd let y'all know the outcome. Long story short, I have accepted a position at Comcast, in the National Engineering and Technical Operations group, in Herndon VA (possibly moving to Reston VA soonish), starting in probably a week or two. I will no longer be in a position related to security, but will still participate here, and in the broader secure coding community, as time allows -- and keep trying to spread the gospel. ;-) Thanks for all your help, Dave -- Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII -------------------------------------+ Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From list-spam at secureconsulting.net Sat Oct 17 16:10:39 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Sat, 17 Oct 2009 13:10:39 -0700 Subject: [SC-L] new job! In-Reply-To: <3f4922c70910160524q6cd5cfb9oda3dac1262de1c63@mail.gmail.com> References: <3f4922c70910160524q6cd5cfb9oda3dac1262de1c63@mail.gmail.com> Message-ID: <4ADA24BF.9090003@secureconsulting.net> Ditto on the new job for me, too! (thanks for reminder Dave) I've taken a position with Foreground Security and will also be moving back to NoVA. I start Monday and the movers come next Saturday. :) Looks like Dave and I need to put our heads together and host a NoVA-based "thank you" happy hour. :) -ben SC-L Reader Dave Aronson wrote: > Since the Power that Be let me post my plea for job help, I figured > I'd let y'all know the outcome. > > Long story short, I have accepted a position at Comcast, in the > National Engineering and Technical Operations group, in Herndon VA > (possibly moving to Reston VA soonish), starting in probably a week or > two. I will no longer be in a position related to security, but will > still participate here, and in the broader secure coding community, as > time allows -- and keep trying to spread the gospel. ;-) > > Thanks for all your help, > Dave > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "Practice does not make perfect. Only perfect practice makes perfect." Vince Lombardi From steingra at gmail.com Sun Oct 18 11:28:32 2009 From: steingra at gmail.com (Andy Steingruebl) Date: Sun, 18 Oct 2009 08:28:32 -0700 Subject: [SC-L] Genotypes and Phenotypes In-Reply-To: <5DACC237-B8D0-40F8-94FE-FE1877302435@arctecgroup.net> References: <5DACC237-B8D0-40F8-94FE-FE1877302435@arctecgroup.net> Message-ID: <490a979e0910180828r17f0992euecee59679fca0b4c@mail.gmail.com> On Mon, Oct 12, 2009 at 9:55 AM, Gunnar Peterson wrote: > Its been awhile since there was a bugs vs flaws debate, so here is a snippet > from Jaron Lanier > A: No, no, they're not. What's the difference between a bug and a variation > or an imperfection? If you think about it, if you make a small change to a > program, it can result in an enormous change in what the program does. If > nature worked that way, the universe would crash all the time. Certainly > there wouldn't be any evolution or life. There's something about the way > complexity builds up in nature so that if you have a small change, it > results in sufficiently small results; it's possible to have incremental > evolution. Right now, we have a little bit -- not total -- but a little bit > of linearity in the connection between genotype and phenotype, if you want > to speak in those terms. But in software, there's a chaotic relationship > between the source code (the "genotype") and the observed effects of > programs -- what you might call the "phenotype" of a program. Is this really true though? A small change in libc doesn't change the whole look and feel of a word processing program. It looks exactly the same, but maybe behaves very slightly differently over a small range of inputs, etc. And, while not being an expert in biology, I'm quite certain that there are very minor mutations in certain key places that result in complete system failure or almost entirely fatal diseases, conditions, etc. Is the complexity and expression of it really the key piece here? Or is it general resilience against failure, complexity spread out so that the common enemies (transcription errors in one place) aren't fatal. The system is designed against different threat models. -- Andy Steingruebl steingra at gmail.com From gem at cigital.com Wed Oct 21 17:36:59 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 21 Oct 2009 17:36:59 -0400 Subject: [SC-L] Silver Bullet 43: /Hoff (cloud security) Message-ID: hi sc-l, The technology buzzword of the year has to be "the cloud," and "cloud security" is not far behind. There's plenty of nonsense and silliness to wade through in cloud security (I've seen more than one completely vacuous talk on the topic delivered by pretend security experts). One voice of sanity in the wilderness belongs to /Hoff whose excellent blog postings have gone viral for good reason. /Hoff is victim Silver Bullet victim 43. Much fun was had by all. http://www.cigital.com/silverbullet/show-043/ As always, your feedback on the podcast is welcome. I met a bunch of listeners in Pittsburgh last week when I visited Cylab and in Charlotte this week at UNCC. They have courses specifically on software security at UNCC btw. Cool. BSIMM Begin is cranking, but we're not quite up to 100 companies yet. Maybe I need to make one of those thermometer things? Help us out! http://bsi-mm.com/begin gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Thu Oct 22 12:34:14 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 22 Oct 2009 12:34:14 -0400 Subject: [SC-L] informIT: startup lessons Message-ID: hi sc-l, My October informIT column was sparked by a visit to Alf Weaver's Electronic Commerce Technologies class at the University of Virginia. Alf's mix of grads and undergrads wanted to hear about startups, and that got me thinking about what working for Cigital since 1995 has taught me (sometimes the hard way). Read the results here: http://www.informit.com/articles/article.aspx?p=1403996 http://www.cigital.com/justiceleague/ There's plenty of room for more startups in software security! It's been informative and fascinating watching both Fortify and Cigital grow. gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck book www.swsec.com From James.McGovern at thehartford.com Thu Oct 22 15:18:46 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Thu, 22 Oct 2009 15:18:46 -0400 Subject: [SC-L] Podcasts In-Reply-To: References: Message-ID: Has anyone know of a mutually exclusive completely exhaustive lists of podcasts that touch upon the various perspectives of secure coding? ************************************************************ 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 dwheeler at ida.org Mon Nov 2 11:16:44 2009 From: dwheeler at ida.org (Wheeler, David A) Date: Mon, 2 Nov 2009 11:16:44 -0500 Subject: [SC-L] Fully Countering Trusting Trust through Diverse Double-Compiling Message-ID: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C492@EXCH07-4850.ida.org> All - As you know, in the "trusting trust" attack, compilers can be subverted to insert malicious Trojan horses into critical software... including themselves. This turns out to be a nasty attack that's not easy to counter. I've just released my draft PhD dissertation, "Fully Countering Trusting Trust through Diverse Double-Compiling" (DDC), that describes how to counter the "trusting trust" attack. More details, including the dissertation, are here: http://www.dwheeler.com/trusting-trust On November 23, 2009, 1-3pm, I will be giving a public defense of this dissertation. If you're interested, please come! It will be at George Mason University, Fairfax, Virginia, Innovation Hall, room 105. This 2009 dissertation significantly extends my previous 2005 ACSAC paper. For example, I now have a formal proof that DDC is effective (the ACSAC paper only had an informal justification). I also have additional demonstrations, including one with GCC (to show that it scales up) and one with a maliciously corrupted compiler (to show that it really does detect them in the real world). The dissertation is also more general; the ACSAC paper only considered the special case of a "self-parenting" compiler, while the dissertation eliminates that assumption. --- David A. Wheeler From gem at cigital.com Mon Nov 2 14:24:31 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 2 Nov 2009 14:24:31 -0500 Subject: [SC-L] Lifestyle Hackers Message-ID: <41945506397C0C4886A8C5BFF089B5CA3AFA31297E@va-mailhub.cigital.com> hi sc-l, Jim Routh (once the CSO of DTCC, always a major software security booster, and now the CSO of KPMG) and I wrote an article published in CSO's October issue. The article is about "lifestyle hackers" and ponders what happens when 20-somethings used to social networking foo are confronted with corporate security controls that disallow such. http://www.csoonline.com/article/506309/Lifestyle_Hackers Anybody running into this phenomenon in their work? (James??) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck book www.swsec.com From James.McGovern at thehartford.com Tue Nov 3 10:13:59 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Tue, 3 Nov 2009 10:13:59 -0500 Subject: [SC-L] Lifestyle Hackers In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3AFA31297E@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA3AFA31297E@va-mailhub.cigital.com> Message-ID: Myspace and Facebook blocked (we have presence) Twitter not blocked. One should separate out the following: - Sites that display images vs those who just display links - The ability to filter exactly what you read based on where you are - While 20-somethings is a predictor, it is also stereotypical. Us 40-somethings in many ways leverage social networking to competitive advantage over those who are less mature -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Monday, November 02, 2009 2:25 PM To: SC-L at securecoding.org Cc: dslater at cxo.com; James M. Routh (jrouth at dtcc.com) Subject: [SC-L] Lifestyle Hackers hi sc-l, Jim Routh (once the CSO of DTCC, always a major software security booster, and now the CSO of KPMG) and I wrote an article published in CSO's October issue. The article is about "lifestyle hackers" and ponders what happens when 20-somethings used to social networking foo are confronted with corporate security controls that disallow such. http://www.csoonline.com/article/506309/Lifestyle_Hackers Anybody running into this phenomenon in their work? (James??) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck 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 ge at linuxbox.org Tue Nov 3 19:57:35 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 04 Nov 2009 02:57:35 +0200 Subject: [SC-L] Fully Countering Trusting Trust through Diverse Double-Compiling In-Reply-To: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C492@EXCH07-4850.ida.org> References: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C492@EXCH07-4850.ida.org> Message-ID: <4AF0D17F.60707@linuxbox.org> Wheeler, David A wrote: > All - > > As you know, in the "trusting trust" attack, compilers can be subverted to insert malicious Trojan horses into critical software... including themselves. This turns out to be a nasty attack that's not easy to counter. > > I've just released my draft PhD dissertation, "Fully Countering Trusting Trust through Diverse Double-Compiling" (DDC), that describes how to counter the "trusting trust" attack. More details, including the dissertation, are here: > http://www.dwheeler.com/trusting-trust > > On November 23, 2009, 1-3pm, I will be giving a public defense of this dissertation. If you're interested, please come! It will be at George Mason University, Fairfax, Virginia, Innovation Hall, room 105. > > This 2009 dissertation significantly extends my previous 2005 ACSAC paper. For example, I now have a formal proof that DDC is effective (the ACSAC paper only had an informal justification). I also have additional demonstrations, including one with GCC (to show that it scales up) and one with a maliciously corrupted compiler (to show that it really does detect them in the real world). The dissertation is also more general; the ACSAC paper only considered the special case of a "self-parenting" compiler, while the dissertation eliminates that assumption. > David, this is very cool indeed. Thank you for sharing, and a lot of luck! I'd like to note in a semi-related fashion that the concept of trusting trust, while in the original paper limited to the compiler case, is a generic concept in security and could go on up and down the chain of trust forever (beyond the compiler), until at some point you take something on blind faith. Gadi. > --- David A. Wheeler > > > _______________________________________________ > 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. > _______________________________________________ > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From dwheeler at ida.org Wed Nov 4 10:08:18 2009 From: dwheeler at ida.org (Wheeler, David A) Date: Wed, 4 Nov 2009 10:08:18 -0500 Subject: [SC-L] Fully Countering Trusting Trust through Diverse Double-Compiling In-Reply-To: <4AF0D17F.60707@linuxbox.org> References: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C492@EXCH07-4850.ida.org> <4AF0D17F.60707@linuxbox.org> Message-ID: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C553@EXCH07-4850.ida.org> Gadi Evron said: > David, this is very cool indeed. Thank you for sharing, and a lot of luck! Thanks! > I'd like to note in a semi-related fashion that the concept of trusting > trust, while in the original paper limited to the compiler case, is a > generic concept in security and could go on up and down the chain of > trust forever (beyond the compiler), until at some point you take > something on blind faith. Actually, I talk about that in the dissertation. First, it is perfectly reasonable to redefine the word "compiler" to include all sorts of components that you might traditionally define as part of the "environment". For example, you could include the entire operating system as well as what we would traditionally define as "compiler". Of course, now you need all of ITS source code, as a different trusted compiler that's able to compile it, as well as time to make it work. The good news is that, once you did that, you'd have then verified that ALL of those executables correspond to their source code. Second, I do not agree that this is BLIND faith. I agree that you must eventually accept SOME set of components as being sufficiently trustworthy. But the idea is to use a separate trusted compiler/environment to verify your original items. At that point, I don't think it's BLIND at all; you hope the original components are okay, but you've also performed a verification step to increase your confidence that this is so. The phrase "trust, but verify" comes to mind :-). --- David A. Wheeler From ge at linuxbox.org Wed Nov 4 10:43:58 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 04 Nov 2009 17:43:58 +0200 Subject: [SC-L] Fully Countering Trusting Trust through Diverse Double-Compiling In-Reply-To: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C553@EXCH07-4850.ida.org> References: <9F8E44BC27E22046B84EC1B9364C66A182D4A3C492@EXCH07-4850.ida.org> <4AF0D17F.60707@linuxbox.org> <9F8E44BC27E22046B84EC1B9364C66A182D4A3C553@EXCH07-4850.ida.org> Message-ID: <4AF1A13E.1060705@linuxbox.org> Wheeler, David A wrote: > Gadi Evron said: >> David, this is very cool indeed. Thank you for sharing, and a lot of luck! > > Thanks! > >> I'd like to note in a semi-related fashion that the concept of trusting >> trust, while in the original paper limited to the compiler case, is a >> generic concept in security and could go on up and down the chain of >> trust forever (beyond the compiler), until at some point you take >> something on blind faith. > > Actually, I talk about that in the dissertation. > > First, it is perfectly reasonable to redefine the word "compiler" to include all sorts of components that you might traditionally define as part of the "environment". For example, you could include the entire operating system as well as what we would traditionally define as "compiler". Of course, now you need all of ITS source code, as a different trusted compiler that's able to compile it, as well as time to make it work. The good news is that, once you did that, you'd have then verified that ALL of those executables correspond to their source code. > > Second, I do not agree that this is BLIND faith. I agree that you must eventually accept SOME set of components as being sufficiently trustworthy. But the idea is to use a separate trusted compiler/environment to verify your original items. At that point, I don't think it's BLIND at all; you hope the original components are okay, but you've also performed a verification step to increase your confidence that this is so. The phrase "trust, but verify" comes to mind :-). Exactly, it is an endless process of trust, as you trust the second system/environment to be secure, or at least without a backdoor. But while I really like the discussion, I don't want to take away from the value of your work. Thanks again for sharing! Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From James.McGovern at thehartford.com Wed Nov 4 10:38:12 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Wed, 4 Nov 2009 10:38:12 -0500 Subject: [SC-L] Question on ISACA Message-ID: John Morency of Gartner just finished giving a presentation to our IT executives and one of the observations is that IT auditors have zero clue as to how to audit a secure coding practice. IT audit right now is limited to simply looking at "control" documents and viewing things through the lens of "infrastructure". Is there something we as a community should be doing to make auditors smarter? ************************************************************ 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: From James.McGovern at thehartford.com Wed Nov 4 14:13:13 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Wed, 4 Nov 2009 14:13:13 -0500 Subject: [SC-L] [Owasp-leaders] Question on ISACA In-Reply-To: <5BF7B83C-C763-43D5-97AB-F8E860C5A774@owasp.org> References: <5BF7B83C-C763-43D5-97AB-F8E860C5A774@owasp.org> Message-ID: My thought was a little different than thinking of this as an educational activity. My thinking says this is more about how groups such as OWASP should "JOINTLY" publish with groups such as ISACA. On the radar of most enterprisey types are emerging legislation such as Mass Privacy will have audit-specific criteria within the legislation. In the same sense that OWASP had a win by having PCI mention us, we could accomplish something similar by working with the audit community. -----Original Message----- From: owasp-leaders-bounces at lists.owasp.org [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of kuai hinojosa Sent: Wednesday, November 04, 2009 11:18 AM To: owasp-leaders at lists.owasp.org Cc: sc-l at securecoding.org Subject: Re: [Owasp-leaders] Question on ISACA On Nov 4, 2009, at 11:11 AM, Dan Cornell wrote: > I've worked with a number of IT auditors in the past and that is a > fair characterization, based on my experiences. Most of the folks in > that job function I have worked with are, at best, infrastructure > security folks who have moved to IT audit, but many are CPAs by > background or have other non-IT experience bases. > > The majority of the time I have worked with IT auditors it has been > helping them to translate their audit requirement into reasonable > technical measures that can be taken that meet those requirements and > then helping them to interpret the results of Threat Models, code and > application scans, etc so they can determine if they feel comfortable > that their audit requirements have been met. > > As for what OWASP can do I think the manager-focused documentation for > the OWASP Top 10, etc is helpful in translating fairly technical > information to the level of business risk. There was work done a > while back on ISO 17799 mappings and resurrecting that and providing > further application-level guidance for these compliance/audit regimes > might be helpful. I believe this is one of the initiatives of the Global Education Committee, we are planning on structuring and "translating" documents for different target audience, managers being one. > > Have other folks on the list fielded questions from IT auditors who > were looking for further direction? > > Thanks, > > Dan > ________________________________________ > From: owasp-leaders-bounces at lists.owasp.org > [owasp-leaders-bounces at lists.owasp.org > ] On Behalf Of McGovern, James F. (eBusiness) > [James.McGovern at thehartford.com ] > Sent: Wednesday, November 04, 2009 9:38 AM > To: owasp-leaders at lists.owasp.org; sc-l at securecoding.org > Subject: [Owasp-leaders] Question on ISACA > > John Morency of Gartner just finished giving a presentation to our IT > executives and one of the observations is that IT auditors have zero > clue as to how to audit a secure coding practice. IT audit right now > is limited to simply looking at "control" documents and viewing things > through the lens of "infrastructure". Is there something we as a > community should be doing to make auditors smarter? > > ************************************************************ > 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. > ************************************************************ > > > > _______________________________________________ > OWASP-Leaders mailing list > OWASP-Leaders at lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-leaders _______________________________________________ OWASP-Leaders mailing list OWASP-Leaders at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-leaders ************************************************************ 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 Wed Nov 4 14:15:58 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Wed, 4 Nov 2009 14:15:58 -0500 Subject: [SC-L] [Owasp-leaders] Question on ISACA In-Reply-To: References: Message-ID: Eoin, I think your take on SAMM is interesting. I think the difference is not to look for evidence but to measure against controls. Auditors use the notion of controls to figure out good vs bad and is less fluid / abstract that simply seeking evidence. I wonder if Pravir or others that thought about expanding SAMM to include audit language. ________________________________ From: owasp-leaders-bounces at lists.owasp.org [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Eoin Sent: Wednesday, November 04, 2009 11:07 AM To: owasp-leaders at lists.owasp.org Cc: sc-l at securecoding.org Subject: Re: [Owasp-leaders] Question on ISACA Re understanding what secure codeing is: Taking a look at the OWASP development guides and Code review guide is a start: The intro sections cover what a secure SDLC whould look like etc. Looking at SAMM can indicate what is required also by examining the domains and mapping onto the SDLC Re auditing: (it's not just secure coding, its the whole kahuna) Evidence of developer training is a good start Evidence Secure coding guidelines are nice to see, event better if they have a review history (looked used!). A generic secure application development policy could be used which can be linked to technolofy specific guidelines Evidence of review and adherence to them. Evidence of negative testing, negative use cases anti patterns & threat modeling but there is more....... 2009/11/4 McGovern, James F. (eBusiness) John Morency of Gartner just finished giving a presentation to our IT executives and one of the observations is that IT auditors have zero clue as to how to audit a secure coding practice. IT audit right now is limited to simply looking at "control" documents and viewing things through the lens of "infrastructure". Is there something we as a community should be doing to make auditors smarter? ************************************************************ 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. ************************************************************ _______________________________________________ OWASP-Leaders mailing list OWASP-Leaders at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-leaders -- Eoin Keary OWASP Code Review Guide Lead Author OWASP Ireland Chapter Lead OWASP Global Committee Member (Industry) http://asg.ie/ https://twitter.com/EoinKeary ************************************************************ 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: From chandra at list.org Wed Nov 4 17:07:23 2009 From: chandra at list.org (Pravir Chandra) Date: Wed, 4 Nov 2009 17:07:23 -0500 Subject: [SC-L] Question on ISACA In-Reply-To: References: Message-ID: For SAMM, each level for each security practice has an 'Objective' that I tried to write in a way that would allow it to double as a 'Control Statement' in an audit context. So, hopefully, SAMM is fairly auditor friendly since you could use the deliverables produced by each of the underlying Activities to demonstrate evidence for meeting the Control Statement. Also, Nick Coblentz produced a SAMM interview checklist that includes a list of 'Assertions' that are being made by answering yes to the questions on the SAMM assessment worksheets. Those might also be useful from and audit perspective. For those that haven't seen it, the link to Nick's interview template is: http://nickcoblentz.blogspot.com/2009/06/samm-inteview-template-version-10.html Does that address the goals of audit tie-ins or were folks looking for something more explicit? There's always opportunities to add it to the next SAMM version if its useful :) p. On 11/4/09, McGovern, James F. (eBusiness) wrote: > Eoin, I think your take on SAMM is interesting. I think the difference > is not to look for evidence but to measure against controls. Auditors > use the notion of controls to figure out good vs bad and is less fluid / > abstract that simply seeking evidence. I wonder if Pravir or others that > thought about expanding SAMM to include audit language. > > ________________________________ > > From: owasp-leaders-bounces at lists.owasp.org > [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Eoin > Sent: Wednesday, November 04, 2009 11:07 AM > To: owasp-leaders at lists.owasp.org > Cc: sc-l at securecoding.org > Subject: Re: [Owasp-leaders] Question on ISACA > > > Re understanding what secure codeing is: > > Taking a look at the OWASP development guides and Code review guide is a > start: The intro sections cover what a secure SDLC whould look like etc. > Looking at SAMM can indicate what is required also by examining the > domains and mapping onto the SDLC > > Re auditing: (it's not just secure coding, its the whole kahuna) > > Evidence of developer training is a good start > > Evidence Secure coding guidelines are nice to see, event better if they > have a review history (looked used!). > A generic secure application development policy could be used which can > be linked to technolofy specific guidelines > > Evidence of review and adherence to them. > > Evidence of negative testing, negative use cases anti patterns & threat > modeling > > but there is more....... > > > > > > > > > > 2009/11/4 McGovern, James F. (eBusiness) > > > > John Morency of Gartner just finished giving a presentation to > our IT executives and one of the observations is that IT auditors have > zero clue as to how to audit a secure coding practice. IT audit right > now is limited to simply looking at "control" documents and viewing > things through the lens of "infrastructure". Is there something we as a > community should be doing to make auditors smarter? > > ************************************************************ > 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. > ************************************************************ > > _______________________________________________ > OWASP-Leaders mailing list > OWASP-Leaders at lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-leaders > > > > > > > -- > Eoin Keary > > OWASP Code Review Guide Lead Author > OWASP Ireland Chapter Lead > OWASP Global Committee Member (Industry) > > http://asg.ie/ > https://twitter.com/EoinKeary > > ************************************************************ > 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. > ************************************************************ > -- ~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~ Pravir Chandra chandralistorg PGP: CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ From ccpalmer at dartmouth.edu Thu Nov 5 08:29:08 2009 From: ccpalmer at dartmouth.edu (Charles C Palmer) Date: Thu, 5 Nov 2009 08:29:08 -0500 Subject: [SC-L] DEsigning a Secure Systems Development Competition Workshop March 2010 Message-ID: <9F566F3C-CFD5-4BB4-B3C8-202AE1581EF2@dartmouth.edu> DESSEC: DEsigning a Secure Systems Engineering Competition A Workshop March 30-April 1, 2010 (Tentative) at the Washington Duke Inn in Durham, North Carolina Call for Proposals and Participation If we want to have a cyber infrastructure that can both resist attacks and be safely extended with new technology, we have to learn how to build it. In effect, we are asking for practical, composable security, at scale. One way to teach ourselves this lesson might be to conduct a series of competitive development efforts that encourage diverse means of realizing some specified system with some specified security properties. Take a few minutes to look at the attached Call for Proposals and begin to think about how we can really change the way we build systems. Please share this email with your colleagues who might have new approaches to this challenge. We hope to see you in Durham, North Carolina in March 2010. The I3P www.thei3p.org Charles C. Palmer Senior Technical Advisor I3P (http://www.thei3p.org) 914-954-2466 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dessec.pdf Type: application/pdf Size: 62255 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gem at cigital.com Thu Nov 5 20:38:34 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 5 Nov 2009 20:38:34 -0500 Subject: [SC-L] Reality Check: nokia Message-ID: hi sc-l, The November edition of Reality Check is a conversation with Nokia. Nokia's software security initiative is eight years old. Lots of good things to hear. Janne and Antti tell all: http://www.cigital.com/realitycheck/show-010/ BSIMM Europe will be released on Tuesday next week. Perhaps Nokia was involved in that?! Great results. Stay tuned. gem p.s. 67 responses so far for BSIMM Begin. We still need your help http://bsi-mm.com/begin/ company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/justiceleague book swsec.com From shadown at gmail.com Fri Nov 6 04:03:08 2009 From: shadown at gmail.com (Sergio 'shadown' Alvarez) Date: Fri, 6 Nov 2009 10:03:08 +0100 Subject: [SC-L] Reality Check: nokia In-Reply-To: References: Message-ID: <4E24155C-A6EA-43DF-BB4A-3F228F3BC27D@gmail.com> Hi gem, I've been listening the podcast because Symbian is something I've been playing a bit with. What security are you guys talking about? That thing gets broken just by staring at it! Cheers, Sergio On Nov 6, 2009, at 2:38 AM, Gary McGraw wrote: > hi sc-l, > > The November edition of Reality Check is a conversation with Nokia. > Nokia's software security initiative is eight years old. Lots of > good things to hear. Janne and Antti tell all: > http://www.cigital.com/realitycheck/show-010/ > > BSIMM Europe will be released on Tuesday next week. Perhaps Nokia > was involved in that?! Great results. Stay tuned. > > gem > > p.s. 67 responses so far for BSIMM Begin. We still need your help http://bsi-mm.com/begin/ > > company www.cigital.com > podcast www.cigital.com/silverbullet > podcast www.cigital.com/justiceleague > book 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 craigh at symbian.org Fri Nov 6 12:26:05 2009 From: craigh at symbian.org (Craig Heath) Date: Fri, 6 Nov 2009 17:26:05 +0000 Subject: [SC-L] SC-L Digest, Vol 5, Issue 158 In-Reply-To: References: Message-ID: <921558290911060926n4c8cdera6c190620bde4bda@mail.gmail.com> > Date: Fri, 6 Nov 2009 10:03:08 +0100 > From: "Sergio 'shadown' Alvarez" > I've been listening the podcast because Symbian is something I've been > playing a bit with. > What security are you guys talking about? That thing gets broken just > by staring at it! That's a challenging point of view! We'd be very happy for you to work with the Symbian community to improve it. Some of the ways you can participate are: Report vulnerabilities in the bug tracker: http://developer.symbian.org/bugs/ Discuss improvements to the security architecture and functionality: http://developer.symbian.org/forum/forumdisplay.php?f=41 Help define the way Symbian should work with security researchers: http://developer.symbian.org/wiki/index.php/Security_Strategy_Working_Group - Craig Heath, Chief Security Technologist, Symbian Foundation. From gem at cigital.com Fri Nov 6 16:48:21 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 6 Nov 2009 16:48:21 -0500 Subject: [SC-L] podcast: dennis fisher interviews me Message-ID: hi sc-l, It's a quick turnaround universe. This podcast was recorded this afternoon by Dennis Fisher for threatpost: http://threatpost.com/en_us/blogs/gary-mcgraw-software-security-bsimm-model-and-critical-thinking-110609 We discuss the BSIMM, BSIMM Europe (launches next Tuesday), BSIMM Begin (we still need your help), "Monkeys Eat Bananas" and other aspects of software security. Theme music by my band Where's Aubrey. Off to Europe again... gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From ken at krvw.com Sat Nov 7 08:42:46 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Sat, 7 Nov 2009 08:42:46 -0500 Subject: [SC-L] OWASP AppSec DC this coming week! Message-ID: <7024C18C-EFE3-47AE-A0E6-B579550750FA@krvw.com> Greetings SC-Lers, This next week is OWASP's AppSec DC conference. I imagine quite a few SC-L subscribers will be there. I'll only be there one day (Thurs) due to a client engagement, but I hope to see a few SC-L friends there. If you're in town and care to meet up for a chat/beer (after my session...), just drop me a line. 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: 2252 bytes Desc: not available URL: From list-spam at secureconsulting.net Mon Nov 9 09:27:17 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Mon, 09 Nov 2009 09:27:17 -0500 Subject: [SC-L] tweetup Thurs PM for AppSec DC? Message-ID: <4AF826C5.7050902@secureconsulting.net> Just a quick note, for those coming into DC for AppSec DC, rumor has it that a social gathering is brewing for Thurs PM. Let's hope so as I'd love to put faces with names! :) If I hear details, I'll be sure to pass along (feel free to ping me or reply with the 411) -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "I have no special talent. I am only passionately curious." Albert Einstein From James.McGovern at thehartford.com Mon Nov 9 09:23:21 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Mon, 9 Nov 2009 09:23:21 -0500 Subject: [SC-L] OpenSAMM vs BSIMM Message-ID: One take on the differences between OpenSAMM vs BSIMM is the work that Cigital and Fortify did to validate BSIMM with real-world enterprises such as DTCC. If folks on this list had the ultimate "influence" card they could pull out and throw at Gartner, Forrester, Burton Group, etc, would OpenSAMM at the end of the day appear more credible if the analyst firms measured large enterprises against OpenSAMM in terms of published research? ************************************************************ 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: From ken at krvw.com Tue Nov 10 06:23:04 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 10 Nov 2009 06:23:04 -0500 Subject: [SC-L] Microsoft releases security guidelines for Agile - agile, Microsoft, security, software development - CIO Message-ID: Hey, now you agile folks can't any longer feel left out by the various security development processes that bypass you: http://www.cio.com.au/article/325501/microsoft_releases_security_guidelines_agile?eid=-1050 On a somewhat related note, a client of mine referred to their process recently as "scrummerfall"... That certainly drew a few laughs. Cheers, Ken ----- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: not available URL: From ken at krvw.com Tue Nov 10 06:27:09 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Tue, 10 Nov 2009 06:27:09 -0500 Subject: [SC-L] tweetup Thurs PM for AppSec DC? In-Reply-To: <4AF826C5.7050902@secureconsulting.net> References: <4AF826C5.7050902@secureconsulting.net> Message-ID: On Nov 9, 2009, at 9:27 AM, Benjamin Tomhave wrote: > Just a quick note, for those coming into DC for AppSec DC, rumor has > it > that a social gathering is brewing for Thurs PM. Let's hope so as I'd > love to put faces with names! :) If I hear details, I'll be sure to > pass > along (feel free to ping me or reply with the 411) Well, I got a few responses to my note about meeting up there (although I doubt I'd ever use the word "tweetup" except in the context of saying I wouldn't use it...). :-) In any case, I'm not sure of the lay of the land at the conference site, but I'm betting there's a bar in or near the site. Let's plan on meeting up there immediately following the day's sessions on Thursday. As soon as I can pinpoint the actual bar name/location, I'll post it here. Hope to see some SC-L folks there. 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: 2252 bytes Desc: not available URL: From gem at cigital.com Wed Nov 11 01:09:22 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 11 Nov 2009 01:09:22 -0500 Subject: [SC-L] BSIMM Europe In-Reply-To: Message-ID: hi sc-l, Today we officially launch BSIMM Europe, a study of 9 EU firms' software security initiatives. We continue to focus our work on large-scale software security initiatives at major software firms. Firms in the study included: Nokia, Standard Life, SWIFT, Telecom Italia, and Thomson Reuters. An informIT article can be found here: http://www.informit.com/articles/article.aspx?p=1405841 The article describes our findings regarding European software security by contrast with the original BSIMM. We have tripled the size of the BSIMM study to 27 firms with several more under way. We hope to reach 30 firms by year end. We released BSIMM v1.5 as part of the BSIMM Europe push. The document (released under the Creative Commons) is available for download and now includes and appendix about BSIMM Europe http://www.bsi-mm.com/europe/. The original document has been translated into Italian (by Minded Security) and German (by Virtual Forge). We are very excited about BSIMM progress and look forward to sharing more real data with the community. No more faith based software security! gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From parttimesecurityguy at googlemail.com Wed Nov 11 06:56:44 2009 From: parttimesecurityguy at googlemail.com (Colin Cassidy) Date: Wed, 11 Nov 2009 11:56:44 +0000 Subject: [SC-L] BSIMM Europe In-Reply-To: References: Message-ID: Gary, Well done to you and your team for working on this, I've read the article and was interested in something that actually didn`t appear. There was a lot of comparisions between the activities that all the european sites performed, and the activities that were not performed w.r.t. the BSIMM activities and the american founders. However there was no mention of any activities that were unique to the european sites, was this studied at all, and will it be incorporated into BSIMM 2? CJC On Wed, Nov 11, 2009 at 6:09 AM, Gary McGraw wrote: > > > hi sc-l, > > Today we officially launch BSIMM Europe, a study of 9 EU firms' software security initiatives. ?We continue to focus our work on large-scale software security initiatives at major software firms. ?Firms in the study included: Nokia, Standard Life, SWIFT, Telecom Italia, and Thomson Reuters. > > An informIT article can be found here: http://www.informit.com/articles/article.aspx?p=1405841 > > The article describes our findings regarding European software security by contrast with the original BSIMM. ?We have tripled the size of the BSIMM study to 27 firms with several more under way. ?We hope to reach 30 firms by year end. > > We released BSIMM v1.5 as part of the BSIMM Europe push. ?The document (released under the Creative Commons) is available for download and now includes and appendix about BSIMM Europe http://www.bsi-mm.com/europe/. ?The original document has been translated into Italian (by Minded Security) and German (by Virtual Forge). > > We are very excited about BSIMM progress and look forward to sharing more real data with the community. ?No more faith based software security! > > 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 gem at cigital.com Wed Nov 11 07:37:33 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 11 Nov 2009 07:37:33 -0500 Subject: [SC-L] BSIMM Europe In-Reply-To: Message-ID: Hi Colin, Good question. We did not observe any activities in European initiatives that were not in the model. We would have added them to the model had we made such observations. We followed the same data collection protocol as in the first BSIMM, using interviews that were open (driven by the SSF) and not asking about particular activities. The one delta that you likely noticed in the study is that the "things that everybody does" in Europe differ from those in the US. There is some discussion of that in the article. We hope to have BSIMM II out near the end of the year. Our analysis then should feature some statistical insight. gem http://www.cigital.com/~gem On 11/11/09 6:56 AM, "Colin Cassidy" wrote: Gary, Well done to you and your team for working on this, I've read the article and was interested in something that actually didn`t appear. There was a lot of comparisions between the activities that all the european sites performed, and the activities that were not performed w.r.t. the BSIMM activities and the american founders. However there was no mention of any activities that were unique to the european sites, was this studied at all, and will it be incorporated into BSIMM 2? CJC On Wed, Nov 11, 2009 at 6:09 AM, Gary McGraw wrote: > > > hi sc-l, > > Today we officially launch BSIMM Europe, a study of 9 EU firms' software security initiatives. We continue to focus our work on large-scale software security initiatives at major software firms. Firms in the study included: Nokia, Standard Life, SWIFT, Telecom Italia, and Thomson Reuters. > > An informIT article can be found here: http://www.informit.com/articles/article.aspx?p=1405841 > > The article describes our findings regarding European software security by contrast with the original BSIMM. We have tripled the size of the BSIMM study to 27 firms with several more under way. We hope to reach 30 firms by year end. > > We released BSIMM v1.5 as part of the BSIMM Europe push. The document (released under the Creative Commons) is available for download and now includes and appendix about BSIMM Europe http://www.bsi-mm.com/europe/. The original document has been translated into Italian (by Minded Security) and German (by Virtual Forge). > > We are very excited about BSIMM progress and look forward to sharing more real data with the community. No more faith based software security! > > 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 ken at krvw.com Fri Nov 13 08:20:58 2009 From: ken at krvw.com (Kenneth Van Wyk) Date: Fri, 13 Nov 2009 08:20:58 -0500 Subject: [SC-L] tweetup Thurs PM for AppSec DC? In-Reply-To: References: <4AF826C5.7050902@secureconsulting.net> Message-ID: On Nov 10, 2009, at 6:27 AM, Kenneth Van Wyk wrote: > In any case, I'm not sure of the lay of the land at the conference site, but I'm betting there's a bar in or near the site. Let's plan on meeting up there immediately following the day's sessions on Thursday. As soon as I can pinpoint the actual bar name/location, I'll post it here. OK, so I did fail at getting the word out--sorry. However, it was nice to see at least a few SC-Lers notice the sponsored cocktail hour on the conference agenda. Great to meet some of you face to face. And thanks to Cenzic for hosting the cocktail hour, by the way. For those of you who weren't there, if you work with web apps at all, you really ought to put OWASP on your radar. Great community of people, and these events are a fabulous time to chat with some of the brightest software security people on the planet. Thanks, OWASP! 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: From James.McGovern at thehartford.com Mon Nov 16 09:16:57 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Mon, 16 Nov 2009 09:16:57 -0500 Subject: [SC-L] Static Analysis Findings Message-ID: I spent some time over the weekend looking at the Ounce Findings file (OZASMT) and wonder if the community at large should push Ounce, Fortify, Klocwork, Coverity, etc to come up with an interoperable XML-based way of exchanging findings? ************************************************************ 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: From sbarnum at cigital.com Mon Nov 16 12:25:13 2009 From: sbarnum at cigital.com (Sean Barnum) Date: Mon, 16 Nov 2009 12:25:13 -0500 Subject: [SC-L] SC-L Digest, Vol 5, Issue 163 In-Reply-To: References: Message-ID: <41945506397C0C4886A8C5BFF089B5CA3AFA6F3CFD@va-mailhub.cigital.com> James, There is such an effort currently underway called the Software Assurance Findings Expression Schema (SAFES). It is currently sponsored by the NSA Center for Assured Software and aims to unify reporting not only of static analysis findings but the broader set of software assurance analysis findings reporting including dynamic analysis, web app scanning, data security analysis, etc. There is a Review Candidate 1 release going out for review today to a limited audience of the 20 or so tool and service vendors who acted as sources for this initial effort. The first public release is targeted for sometime in January. So far, the effort has received overwhelmingly positive reaction and involvement from the community. I briefed on it week before last at the Software Assurance Forum and at the NIST SAMATE Static Analysis Tool Exposition (SATE). Keep your eyes peeled and ears open. Hopefully, brighter days are ahead for all of us in the software assurance community. Sean Message: 1 Date: Mon, 16 Nov 2009 09:16:57 -0500 From: "McGovern, James F. (eBusiness)" To: Subject: [SC-L] Static Analysis Findings Message-ID: Content-Type: text/plain; charset="us-ascii" I spent some time over the weekend looking at the Ounce Findings file (OZASMT) and wonder if the community at large should push Ounce, Fortify, Klocwork, Coverity, etc to come up with an interoperable XML-based way of exchanging findings? ************************************************************ 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 dinis at ddplus.net Mon Nov 16 16:31:25 2009 From: dinis at ddplus.net (Dinis Cruz) Date: Mon, 16 Nov 2009 21:31:25 +0000 Subject: [SC-L] Static Analysis Findings In-Reply-To: References: Message-ID: <701fd6b60911161331o342df95at5b96016fbb7100f3@mail.gmail.com> The OWASP O2 Platform (see http://www.owasp.org/index.php/OWASP_O2_Platformand http://www.o2-ounceopen.com/ ) already is able to import into its internal Findings format (defined by the C# interfaces IO2Finding and IO2Trace (see OWASP_O2_Platform/Docs/O2Findings_Schema)) artifacts from: - Ounce Labs *.ozasmt format version 5.x and 6.x - Ounce Labs *.ozasmt format version 7.x - AppScan Developer Edition (latest version) - Cat.NET v1.0 (not the version released last week, but the one before) - FindBugs - CodeCrawler - Fortify *.fvdl v1.3 format (very basic mapping from the only sample assessment file I could find on google (stunnel.fvdl)) - WebScarab logs (the main release not the NG one) Note that most of the 'converters' above were written as PoC to show O2's interoperability, and they really need some users of those tools to take a good look at the conversion and provide feedback on the best way to represent/convert that data. The key factor of the O2 Platform, is that it was designed to make it easy and fast to add new filters. For XML formats, my process is usually: - step 1) grab the XSD (if not available use Visual Studio to create it), and use the XSD.EXE tool (Visual Studio SDK) to create a C# object representation of it - step 2) Use C# Serializer to convert the source file into this C# object - step 3) figure out how the XML file works and write a transformation C# script into the O2 Findings format - step 4) I usually write steps 1 to 3 using the O2 Tool - Scriptsmodule (since that allows for easy interaction with other O2 controls (like the Findings Viewer)) and when the script is mature, I add it as a core O2 feature (usually to the O2_ImportExport_Misc project) I'm pushing the O2 Platform to support as many file formats as possible, and *my plan is to eventually cover ALL OWASP tools and ALL major WebAppSec and Network tools. * In the short term, I (or other O2 developers) can write these converters (since all we need is an XSD and somebody who knows how that file works), but ideally, *in the future, each tool developed should be responsible for maintaining and updating their O2 Converters (since we will need to support ALL published versions of their tools).* And if you don't like to write in C#, you can write it in Python ( O2_Tool_Python ) or in Java (O2_Tool_JavaExecution ) For reference I added to http://www.owasp.org/index.php/O2#tab=O2_Documentation WIKI pages, a copy of the current O2 Import functions and schemas (XSD). Here are the main links: - OWASP_O2_Platform/Docs/O2Findings_Schema - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssessmentLoad_OunceV6 - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssessmentLoad_OunceV6_1 - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssesmentLoad_AppScanDE - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssesmentLoad_CodeCrawler - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssesmentLoad_FindBugs - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssesmentLoad_Fortify - OWASP_O2_Platform/Docs/O2Findings_Schema/O2AssesmentLoad_WebScarab I have swapped several times ideas with John Steven from Cigital and he is doing an similar effort internally (at Cigital) which is very similar to O2's approach. The idea (when John is able to publish his stuff) is to create a number of open standards which would merge our ideas (and others from the community) into a bunch of unified schemas: - OFs - Open Findings schema - ORs - Open Rules schema - OCRs - Open Code Representation schema - OAWs - Open Assessment Workflow schema Finally, since the cat is finally out of the bag with O2, * I would like to formally invite the other vendors in this space (**Fortify, Klocwork, Coverity, HPl, Cenzic, etc...) to embrace O2, and write the converters from/to their file formats.* Thanks Dinis Cruz On Mon, Nov 16, 2009 at 2:16 PM, McGovern, James F. (eBusiness) < James.McGovern at thehartford.com> wrote: > I spent some time over the weekend looking at the Ounce Findings file > (OZASMT) and wonder if the community at large should push Ounce, Fortify, > Klocwork, Coverity, etc to come up with an interoperable XML-based way of > exchanging findings? > > ************************************************************ > 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. > _______________________________________________ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From James.McGovern at thehartford.com Fri Nov 20 09:34:26 2009 From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness)) Date: Fri, 20 Nov 2009 09:34:26 -0500 Subject: [SC-L] Question on Static Analysis Message-ID: Noodling the value proposition of static analysis and wonder if vendors in this space are doing the right thing. For example, Gary McGraw was one of the first to point out insecure APIs within Java such as readLine not having a parameter to indicate max read. Is there merit in vendors figuring out how to perform same function within commercial products? For example, there are insecure APIs in IBM MQ/Series, Struts, Spring, etc. Is there merit in collecting this type of information as a new OWASP project? ************************************************************ 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: From gem at cigital.com Thu Nov 26 09:22:08 2009 From: gem at cigital.com (Gary McGraw) Date: Thu, 26 Nov 2009 09:22:08 -0500 Subject: [SC-L] Silver Bullet: Steve Kent Message-ID: hi sc-l, Happy Thanksgiving to US subscribers. My turkey is roasting (4 hours to go), so there's time to hop on the net and announce the 44th episode of Silver Bullet---an interview with Dr. Steve Kent. Steve has been doing Internet security for approximately forever. Steve became involved with the Internet in 1978 as an MIT grad student when he was asked to work on security aspects of early protocols. We talk about that, about BGP (and the famous "take the Internet down in 30 minutes" claim), and of course about software security. Steve has had a very interesting view from the BBN catbird seat. http://www.cigital.com/silverbullet/show-044/ As always, your feedback on Silver Bullet is welcome. The number of listeners continues to grow. In 2010, I hope to exceed 8000 listeners per episode (on average). Ross Anderson's episode still holds the Silver Bullet record with 22,500 downloads. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From john.wilander at owasp.org Mon Nov 30 09:28:26 2009 From: john.wilander at owasp.org (John Wilander) Date: Mon, 30 Nov 2009 15:28:26 +0100 Subject: [SC-L] CFP: OWASP AppSec Research 2010 (Stockholm, Sweden) In-Reply-To: <5cd1beb90911300252x623cf5bcv3a0049bf0dc144ed@mail.gmail.com> References: <5cd1beb90911300252x623cf5bcv3a0049bf0dc144ed@mail.gmail.com> Message-ID: <5cd1beb90911300628o7b5e05bam453d64ed340ae4fe@mail.gmail.com> *** OWASP APPSEC RESEARCH 2010, 2nd CALL FOR PAPERS *** Submission is now open for the upcoming OWASP AppSec Research conference, June 21-24, 2010 in Stockholm, Sweden -- http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden . * TOPICS OF INTEREST * We encourage the publication and presentation of new tools, new methods, empirical data, novel ideas, and lessons learned in the following areas: ? ? ?Web application security ? ? ?Security aspects of new/emerging web technologies/paradigms (mashups, web 2.0, offline support, etc) ? ? ?Security in web services, REST, and service oriented architectures ? ? ?Security in cloud-based services ? ? ?Security of frameworks (Struts, Spring, ASP.Net MVC etc) ? ? ?New security features in platforms or languages ? ? ?Next-generation browser security ? ? ?Security for the mobile web ? ? ?Secure application development (methods, processes etc) ? ? ?Threat modeling of applications ? ? ?Vulnerability analysis (code review, pentest, static analysis etc) ? ? ?Countermeasures for application vulnerabilities ? ? ?Metrics for application security ? ? ?Application security awareness and education * TYPES OF SUBMISSION * 1. Publish or Perish. Peer-reviewed 12 page papers to be published in formal proceedings by Springer-Verlag (Lecture Notes in Computer Science, LNCS). Presentation slides and video takes will be posted on the OWASP wiki after the conference. 2. Demo or Die. A demo proposal should consist of a pdf with a 1 page abstract summarizing the matter proposed by the speaker(s) and 1 page containing demo screenshot(s). Presentation slides and video takes will be posted on the OWASP wiki after the conference. 3. Present or Repent. A presentation proposal should consist of a 2 page extended abstract representing the essential matter proposed by the speaker(s). Presentation slides and video takes will be posted on the OWASP wiki after the conference. Full instructions can be found on the conference webpage http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=CFP. If you have any questions regarding submissions etc, please email john.wilander at owasp.org. * IMPORTANT DATES * Submission deadline: February 7th 23:59 (Apia, Samoa time). Decision notification: April 7th Conference: June 21st - 24th * PROGRAM COMMITTEE * ? John Wilander, Omegapoint and Link?ping University (chair) ? Alan Davidson, Stockholm University/Royal Institute of Technology (co-host) ? Lieven Desmet, Katholieke Universiteit Leuven ? ?lfar Erlingsson, Reykjav?k University and Microsoft Research ? Martin Johns, University of Passau ? Christoph Kern, Google ? Engin Kirda, Institute Eurecom ? Ulf Lindqvist, SRI International ? Benjamin Livshits, Microsoft Research ? Sergio Maffeis, Imperial College London ? John Mitchell, Stanford University ? William Robertson, UC Berkeley ? Andrei Sabelfeld, Chalmers UT A warm welcome from the OWASP community! ? Regards, John Wilander *** About OWASP The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org. From gem at cigital.com Fri Dec 18 10:48:36 2009 From: gem at cigital.com (Gary McGraw) Date: Fri, 18 Dec 2009 10:48:36 -0500 Subject: [SC-L] Silver Bullet 45: Lorrie Cranor Message-ID: hi sc-l, Privacy is an aspect of software security often overlooked by practitioners (especially in the US). The BSIMM Europe results showed us exactly how far ahead of the US the EU when it comes to privacy. One of the best privacy practitioners in the field is Lorrie Cranor. Lorrie is a professor at CMU who became an academic after several years in research at AT&T Labs. We talk all about privacy, liberty, and security in Silver Bullet 45. Have a listen: http://www.cigital.com/silverbullet/show-045/ As always, we thank IEEE Security & Privacy magazine for their co-sponsorship of Silver Bullet (along with Cigital). Your feedback on the podcast is welcome as are suggestions for future victims. Merry New Year sc-l. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com From gem at cigital.com Mon Dec 21 08:24:11 2009 From: gem at cigital.com (Gary McGraw) Date: Mon, 21 Dec 2009 08:24:11 -0500 Subject: [SC-L] InformIT: You need an SSG Message-ID: hi sc-l, This list is made up of a bunch of practitioners (more than a thousand from what Ken tells me), and we collectively have many different ways of promoting software security in our companies and our clients. The BSIMM study focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed in the BSIMM was that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities. I wrote about our observations around SSGs in this month's informIT article: http://www.informit.com/articles/article.aspx?p=1434903 Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We're still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.) Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception, we've helped plan, staff, and carry out ten large software security initiatives in customer firms. One of the most important first tasks is establishing an SSG. Merry New Year everybody. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com From mike.boberski at gmail.com Mon Dec 21 19:01:37 2009 From: mike.boberski at gmail.com (Mike Boberski) Date: Mon, 21 Dec 2009 19:01:37 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: References: Message-ID: <22290cd80912211601x3032f482nb91fb6e0664347e4@mail.gmail.com> Hi Gary. To play devil's advocate: Current organizational practices aside, I would say that organizations really need more and better toolkits and standards for developers to use, than they need more and better committees. A toolkit example that comes to mind, to keep this email short: the highly-matrixed environment (and actually also the smaller environment, now that I think about it) where developers fly on and off projects. Toolkits that enforce coding standards, and that are treated like any other module of the application in terms of care and feeding, are the only things that give security a fighting chance in environments like those. Best, Mike B. On Mon, Dec 21, 2009 at 8:24 AM, Gary McGraw wrote: > hi sc-l, > > This list is made up of a bunch of practitioners (more than a thousand from > what Ken tells me), and we collectively have many different ways of > promoting software security in our companies and our clients. The BSIMM > study focuses attention on software security in large > organizations and just at the moment covers the work of 1554 full time > employees working every day in 26 software security initiatives. One > phenomenon we observed in the BSIMM was that every large initiative has a > Software Security Group (SSG) to carry out and lead software security > activities. > > I wrote about our observations around SSGs in this month's informIT > article: > > http://www.informit.com/articles/article.aspx?p=1434903 > > Simply put, an SSG is a critical part of a software security initiative in > all companies with more than 100 developers. (We're still not sure about > SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 > firms) may be revealing.) > > Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as > founding members). Since its inception, we've helped plan, staff, and carry > out ten large software security initiatives in customer firms. One of the > most important first tasks is establishing an SSG. > > Merry New Year everybody. > > 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: From mike.boberski at gmail.com Mon Dec 21 20:22:05 2009 From: mike.boberski at gmail.com (Mike Boberski) Date: Mon, 21 Dec 2009 20:22:05 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3AFA7BE8D8@va-mailhub.cigital.com> References: <41945506397C0C4886A8C5BFF089B5CA3AFA7BE8D8@va-mailhub.cigital.com> Message-ID: <22290cd80912211722y623cf189y4c7948c56885e0ec@mail.gmail.com> I dunno, the concept of "SSG" seems overly broad to me. Looking at security libraries as a feature or a module eliminates the us vs. them paradox. Adding a new second security group is just twice as confrontational to the still single development team. Mike On Mon, Dec 21, 2009 at 7:20 PM, Gary McGraw wrote: > Hi mike, > > The BSIMM calls out "security features and design" explicitly, and covers > that good idea. (Though watch out for generic one-size-fits-all solutions.) > An SSG helps with creation, review, and roll out of such. > > Calling an SSG a "committee" is pretty hilarious. I doubt any of the 100 > microsoft SSG members think they are a committee. Hey ladd, how goes the SDL > committee? > > gem > > ------------------------------ > *From*: Mike Boberski > *To*: Gary McGraw > *Cc*: Secure Code Mailing List ; Dustin Sullivan > *Sent*: Mon Dec 21 19:01:37 2009 > *Subject*: Re: [SC-L] InformIT: You need an SSG > Hi Gary. > > To play devil's advocate: > > Current organizational practices aside, I would say that organizations > really need more and better toolkits and standards for developers to use, > than they need more and better committees. > > A toolkit example that comes to mind, to keep this email short: the > highly-matrixed environment (and actually also the smaller environment, now > that I think about it) where developers fly on and off projects. > > Toolkits that enforce coding standards, and that are treated like any other > module of the application in terms of care and feeding, are the only things > that give security a fighting chance in environments like those. > > Best, > > Mike B. > > > On Mon, Dec 21, 2009 at 8:24 AM, Gary McGraw wrote: > >> hi sc-l, >> >> This list is made up of a bunch of practitioners (more than a thousand >> from what Ken tells me), and we collectively have many different ways of >> promoting software security in our companies and our clients. The BSIMM >> study focuses attention on software security in large >> organizations and just at the moment covers the work of 1554 full time >> employees working every day in 26 software security initiatives. One >> phenomenon we observed in the BSIMM was that every large initiative has a >> Software Security Group (SSG) to carry out and lead software security >> activities. >> >> I wrote about our observations around SSGs in this month's informIT >> article: >> >> http://www.informit.com/articles/article.aspx?p=1434903 >> >> Simply put, an SSG is a critical part of a software security initiative in >> all companies with more than 100 developers. (We're still not sure about >> SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 >> firms) may be revealing.) >> >> Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as >> founding members). Since its inception, we've helped plan, staff, and carry >> out ten large software security initiatives in customer firms. One of the >> most important first tasks is establishing an SSG. >> >> Merry New Year everybody. >> >> 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: From mike.boberski at gmail.com Mon Dec 21 20:46:13 2009 From: mike.boberski at gmail.com (Mike Boberski) Date: Mon, 21 Dec 2009 20:46:13 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <1F6BBD827AE12941A53317576A6943C80CECC730@TK5EX14MBXC123.redmond.corp.microsoft.com> References: <41945506397C0C4886A8C5BFF089B5CA3AFA7BE8D8@va-mailhub.cigital.com> <22290cd80912211722y623cf189y4c7948c56885e0ec@mail.gmail.com> <1F6BBD827AE12941A53317576A6943C80CECC730@TK5EX14MBXC123.redmond.corp.microsoft.com> Message-ID: <22290cd80912211746s73725dd9o2432018920b73d31@mail.gmail.com> I think, MS is more an example of an ideal, than what the comparatively everyman organization can realistically hope to achieve, basically given resource constraints. Mike On Mon, Dec 21, 2009 at 8:37 PM, David Ladd wrote: > To be clear - we do both. We automate and standardize to the extent > possible, then advise/adjudicate as necessary for situations that don?t fit > the norm. > > > > Dave > > > > *From:* Mike Boberski [mailto:mike.boberski at gmail.com] > *Sent:* Monday, December 21, 2009 5:22 PM > *To:* Gary McGraw > *Cc:* David Ladd; SC-L at securecoding.org; dustin.sullivan at informit.com > > *Subject:* Re: [SC-L] InformIT: You need an SSG > > > > I dunno, the concept of "SSG" seems overly broad to me. Looking at security > libraries as a feature or a module eliminates the us vs. them paradox. > Adding a new second security group is just twice as confrontational to the > still single development team. > > Mike > > On Mon, Dec 21, 2009 at 7:20 PM, Gary McGraw wrote: > > Hi mike, > > The BSIMM calls out "security features and design" explicitly, and covers > that good idea. (Though watch out for generic one-size-fits-all solutions.) > An SSG helps with creation, review, and roll out of such. > > Calling an SSG a "committee" is pretty hilarious. I doubt any of the 100 > microsoft SSG members think they are a committee. Hey ladd, how goes the SDL > committee? > > gem > ------------------------------ > > *From*: Mike Boberski > *To*: Gary McGraw > *Cc*: Secure Code Mailing List ; Dustin Sullivan > *Sent*: Mon Dec 21 19:01:37 2009 > *Subject*: Re: [SC-L] InformIT: You need an SSG > > Hi Gary. > > To play devil's advocate: > > Current organizational practices aside, I would say that organizations > really need more and better toolkits and standards for developers to use, > than they need more and better committees. > > A toolkit example that comes to mind, to keep this email short: the > highly-matrixed environment (and actually also the smaller environment, now > that I think about it) where developers fly on and off projects. > > Toolkits that enforce coding standards, and that are treated like any other > module of the application in terms of care and feeding, are the only things > that give security a fighting chance in environments like those. > > Best, > > Mike B. > > On Mon, Dec 21, 2009 at 8:24 AM, Gary McGraw wrote: > > hi sc-l, > > This list is made up of a bunch of practitioners (more than a thousand from > what Ken tells me), and we collectively have many different ways of > promoting software security in our companies and our clients. The BSIMM > study focuses attention on software security in large > organizations and just at the moment covers the work of 1554 full time > employees working every day in 26 software security initiatives. One > phenomenon we observed in the BSIMM was that every large initiative has a > Software Security Group (SSG) to carry out and lead software security > activities. > > I wrote about our observations around SSGs in this month's informIT > article: > > http://www.informit.com/articles/article.aspx?p=1434903 > > Simply put, an SSG is a critical part of a software security initiative in > all companies with more than 100 developers. (We're still not sure about > SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 > firms) may be revealing.) > > Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as > founding members). Since its inception, we've helped plan, staff, and carry > out ten large software security initiatives in customer firms. One of the > most important first tasks is establishing an SSG. > > Merry New Year everybody. > > 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: From mike.boberski at gmail.com Mon Dec 21 21:48:02 2009 From: mike.boberski at gmail.com (Mike Boberski) Date: Mon, 21 Dec 2009 21:48:02 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <1F6BBD827AE12941A53317576A6943C80CECC839@TK5EX14MBXC123.redmond.corp.microsoft.com> References: <41945506397C0C4886A8C5BFF089B5CA3AFA7BE8D8@va-mailhub.cigital.com> <22290cd80912211722y623cf189y4c7948c56885e0ec@mail.gmail.com> <1F6BBD827AE12941A53317576A6943C80CECC730@TK5EX14MBXC123.redmond.corp.microsoft.com> <22290cd80912211746s73725dd9o2432018920b73d31@mail.gmail.com> <1F6BBD827AE12941A53317576A6943C80CECC839@TK5EX14MBXC123.redmond.corp.microsoft.com> Message-ID: <22290cd80912211848r14369575j94408f9e4d504324@mail.gmail.com> But, do those require a second security group to execute(?) Mike On Mon, Dec 21, 2009 at 9:41 PM, David Ladd wrote: > A lot of people look at what has been published from Microsoft about the > SDL ? most notably the MSDN guidance > http://msdn.microsoft.com/en-us/library/84aed186-1d75-4366-8e61-8d258746bopq.aspxand Michael Howard/Steve Lipner?s SDL book - and walk away thinking that it > is the SDL. It?s not. It?s the SDL as its practiced *at Microsoft.* It > outlines the practices necessary for a multinational organization that ships > hundreds of applications, to 100+ countries worldwide (each with their own > regulatory regime), on a half dozen or more different hardware platforms. > Given that, I would say that it?s our responsibility to apply the SDL in > this fashion. > > > > The book and the guidance have been published and maintained in the > interest of process transparency - to allow third parties to take a peek at > what we do in a variety of different contexts, it is not implementation > advice. > > > > I will concede that security ?SME-dom? can be a rare commodity and > sometimes you have to go outside an org to get help, but a significant > portion of the practices in the SDL (and the BSIMM for that matter) can be > achieved at little to no cost. (e.g. Point a fuzzer (pick a free one - > Minifuzz, Peach, whatever) at an application and set it: ?Run to infinity ? > alert when problem found?) > > > > If you remove the regional/hardware plat/software plat/regulatory goo out > of the SDL at MS picture, you?re left with a series of proven security > practices that can be performed at organizations of any size. Security > requirements, quality gates, threat modeling, static code analysis, dynamic > analysis, etc. aren?t concepts that apply to, or only work in large orgs, > and certainly aren?t proprietary to Microsoft. > > > > Dave > > > > *From:* Mike Boberski [mailto:mike.boberski at gmail.com] > *Sent:* Monday, December 21, 2009 5:46 PM > *To:* David Ladd > *Cc:* Gary McGraw; SC-L at securecoding.org; dustin.sullivan at informit.com > > *Subject:* Re: [SC-L] InformIT: You need an SSG > > > > I think, MS is more an example of an ideal, than what the comparatively > everyman organization can realistically hope to achieve, basically given > resource constraints. > > Mike > > On Mon, Dec 21, 2009 at 8:37 PM, David Ladd > wrote: > > To be clear - we do both. We automate and standardize to the extent > possible, then advise/adjudicate as necessary for situations that don?t fit > the norm. > > > > Dave > > > > *From:* Mike Boberski [mailto:mike.boberski at gmail.com] > *Sent:* Monday, December 21, 2009 5:22 PM > *To:* Gary McGraw > *Cc:* David Ladd; SC-L at securecoding.org; dustin.sullivan at informit.com > > > *Subject:* Re: [SC-L] InformIT: You need an SSG > > > > I dunno, the concept of "SSG" seems overly broad to me. Looking at security > libraries as a feature or a module eliminates the us vs. them paradox. > Adding a new second security group is just twice as confrontational to the > still single development team. > > Mike > > On Mon, Dec 21, 2009 at 7:20 PM, Gary McGraw wrote: > > Hi mike, > > The BSIMM calls out "security features and design" explicitly, and covers > that good idea. (Though watch out for generic one-size-fits-all solutions.) > An SSG helps with creation, review, and roll out of such. > > Calling an SSG a "committee" is pretty hilarious. I doubt any of the 100 > microsoft SSG members think they are a committee. Hey ladd, how goes the SDL > committee? > > gem > ------------------------------ > > *From*: Mike Boberski > *To*: Gary McGraw > *Cc*: Secure Code Mailing List ; Dustin Sullivan > *Sent*: Mon Dec 21 19:01:37 2009 > *Subject*: Re: [SC-L] InformIT: You need an SSG > > Hi Gary. > > To play devil's advocate: > > Current organizational practices aside, I would say that organizations > really need more and better toolkits and standards for developers to use, > than they need more and better committees. > > A toolkit example that comes to mind, to keep this email short: the > highly-matrixed environment (and actually also the smaller environment, now > that I think about it) where developers fly on and off projects. > > Toolkits that enforce coding standards, and that are treated like any other > module of the application in terms of care and feeding, are the only things > that give security a fighting chance in environments like those. > > Best, > > Mike B. > > On Mon, Dec 21, 2009 at 8:24 AM, Gary McGraw wrote: > > hi sc-l, > > This list is made up of a bunch of practitioners (more than a thousand from > what Ken tells me), and we collectively have many different ways of > promoting software security in our companies and our clients. The BSIMM > study focuses attention on software security in large > organizations and just at the moment covers the work of 1554 full time > employees working every day in 26 software security initiatives. One > phenomenon we observed in the BSIMM was that every large initiative has a > Software Security Group (SSG) to carry out and lead software security > activities. > > I wrote about our observations around SSGs in this month's informIT > article: > > http://www.informit.com/articles/article.aspx?p=1434903 > > Simply put, an SSG is a critical part of a software security initiative in > all companies with more than 100 developers. (We're still not sure about > SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 > firms) may be revealing.) > > Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as > founding members). Since its inception, we've helped plan, staff, and carry > out ten large software security initiatives in customer firms. One of the > most important first tasks is establishing an SSG. > > Merry New Year everybody. > > 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: From lists at ticm.com Mon Dec 21 23:24:39 2009 From: lists at ticm.com (Bret Watson) Date: Tue, 22 Dec 2009 12:24:39 +0800 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <22290cd80912211601x3032f482nb91fb6e0664347e4@mail.gmail.co m> References: <22290cd80912211601x3032f482nb91fb6e0664347e4@mail.gmail.com> Message-ID: <4b304ac9.6202be0a.5b12.5bb6@mx.google.com> At 08:01 AM 22/12/2009, Mike Boberski wrote: >Hi Gary. > >To play devil's advocate: > >Current organizational practices aside, I would say that >organizations really need more and better toolkits and standards for >developers to use, than they need more and better committees. I'd have to agree - whilst SSG is probably a great opportunity for a management consultant, it rarely delivers anything directly useful. In fact I would go as far as to say that if a SSG delivers something useful, the organisation was already ready to deliver the changes. Committees rarely take direct ownership of a problem. Toolsets may or may not deliver results - depending on if there are ways around them - too often you hear the excuse "we can't waste time with that - the business won't wait" However toolset will work if you have a good properly supported securty mgmt function :) Cheers Bret From gem at cigital.com Tue Dec 22 07:01:44 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 22 Dec 2009 07:01:44 -0500 Subject: [SC-L] FW: InformIT: You need an SSG In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA3AFA7BE8E1@va-mailhub.cigital.com> Message-ID: I accidentally hijacked this thread with S/MIME last night. Mailman can't do base64 encoding. Oops.... ________________________________ From: Gary McGraw To: 'mike.boberski at gmail.com' ; 'daveladd at microsoft.com' Cc: 'SC-L at securecoding.org' ; 'dustin.sullivan at informit.com' Sent: Mon Dec 21 19:20:18 2009 Subject: Re: [SC-L] InformIT: You need an SSG Hi mike, The BSIMM calls out "security features and design" explicitly, and covers that good idea. (Though watch out for generic one-size-fits-all solutions.) An SSG helps with creation, review, and roll out of such. Calling an SSG a "committee" is pretty hilarious. I doubt any of the 100 microsoft SSG members think they are a committee. Hey ladd, how goes the SDL committee? gem ________________________________ From: Mike Boberski To: Gary McGraw Cc: Secure Code Mailing List ; Dustin Sullivan Sent: Mon Dec 21 19:01:37 2009 Subject: Re: [SC-L] InformIT: You need an SSG Hi Gary. To play devil's advocate: Current organizational practices aside, I would say that organizations really need more and better toolkits and standards for developers to use, than they need more and better committees. A toolkit example that comes to mind, to keep this email short: the highly-matrixed environment (and actually also the smaller environment, now that I think about it) where developers fly on and off projects. Toolkits that enforce coding standards, and that are treated like any other module of the application in terms of care and feeding, are the only things that give security a fighting chance in environments like those. Best, Mike B. On Mon, Dec 21, 2009 at 8:24 AM, Gary McGraw wrote: hi sc-l, This list is made up of a bunch of practitioners (more than a thousand from what Ken tells me), and we collectively have many different ways of promoting software security in our companies and our clients. The BSIMM study focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed in the BSIMM was that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities. I wrote about our observations around SSGs in this month's informIT article: http://www.informit.com/articles/article.aspx?p=1434903 Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We're still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.) Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception, we've helped plan, staff, and carry out ten large software security initiatives in customer firms. One of the most important first tasks is establishing an SSG. Merry New Year everybody. 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. _______________________________________________ ------ End of Forwarded Message From secureCoding2dave at davearonson.com Tue Dec 22 08:19:21 2009 From: secureCoding2dave at davearonson.com (Dave Aronson) Date: Tue, 22 Dec 2009 08:19:21 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <22290cd80912211601x3032f482nb91fb6e0664347e4@mail.gmail.com> References: <22290cd80912211601x3032f482nb91fb6e0664347e4@mail.gmail.com> Message-ID: <3f4922c70912220519r5680b8d4ifd7e10eaae4b27e8@mail.gmail.com> Mike Boberski wrote: > A toolkit example that comes to mind, to keep this email short: the > highly-matrixed environment (and actually also the smaller environment, now > that I think about it) where developers fly on and off projects. I don't quite grok what you're saying here. The syntax looks like you're saying that matrix management is a tool or toolkit, which doesn't make sense to me. Your next paragraph: > Toolkits that enforce coding standards, and that are treated like any other > module of the application in terms of care and feeding, are the only things > that give security a fighting chance in environments like those. seems more like you're saying it's an environment conducive to bad security. Now that I can agree with, and would extend it to quality in general. A typical large-company matrix management environment seems very conducive instead to an attitude of "who gives a flying fig, all I have to do is make it work well enough to get the customer to sign off." A given worker is unlikely to ever work on that same project again, so the usual "write it well so that you can read it well later" doesn't apply, and there's little to no other reward to "write it well to be nice to the next poor sod who has to read it". All the more so in the typical Beltway Bandit (DC-speak for government contractors, especially defense) environment, where they'll probably be laid off in a few years anyway, so they won't be pestered by colleagues with questions, As for the tools, again absolutely agreed, though I'd place less emphasis on some of the pickier aspects of "coding standards" (like do block-opening braces get their own line, and do you put a space before the opening paren of a function call's argument list), and more on any automagically detectable security (or other types of quality) flaws. A couple years ago I was on a project where I was trying desperately to get the company to buy some kind of static analyzer, so we could use it as part of our CM process and have Subversion automagically reject changesets that introduced flaggable flaws. I did at least manage to set up the makefiles so that it would warn if any module had no unit tests, and fail to build if any unit tests failed.... On the other claw, I still don't grok what you mean by "treated like any other module of the application". Maybe it's just a matter of preferred phrasing, but "like any other *aspect*" is closer to at least my own thoughts on it. IOW, they usually ask "does it do the job right" (verification) and maybe "does it do the right job" (validation), but should also ask (for security) "does it Do The Right Thing (whatever that may be) in the face of all forseeable types of attacks", and (for quality) "diDTRT(wtmb)itfoafto *errors*" (including those forced by an attack!) and "is it maintainable". -Dave -- Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII -------------------------------------+ Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web From gem at cigital.com Tue Dec 22 09:12:53 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 22 Dec 2009 09:12:53 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <4b304ac9.6202be0a.5b12.5bb6@mx.google.com> Message-ID: hi bret and mike, While you guys are certainly entitled to your opinion, I think it is important to acknowledge facts when you state an argument. Please take a few minutes to read the article I posted on SSG's (this "committee" language you're both using is very humorous BTW...thanks for the laugh). After you've read the article, lets have an informed debate. Here's the URL again: http://www.informit.com/articles/article.aspx?p=1434903 The article draws conclusions based on observations from 26 companies (Microsoft is only 1 of the 26). The data I based my SSG claims on are provided in analyzed form. Just for the record, the article also states that we're not sure whether the data described in the BSIMM are relevant for SMB (small and medium sized businesses), something I repeated in my sc-l post yesterday. We have plans to find out using real data (again). We will not draw any conclusions without gathering data and publishing it. Your opinion that an SSG "rarely delivers anything useful" certainly does not apply to the 26 companies we studied (so far) in the BSIMM, nor does it cohere with my fifteen years of experience in the field. What observations are you basing your argument on? Can you show us some data? I'm afraid your toolset argument teeters precariously on opinion and falls into a familiar pattern that goes something like this in BNF: = {, ,,,,} Software security can be solved by because I said so. While it is true that you said so, I'm pretty sure you're going to need a more convincing argument. Unless we rely on data and evidence when we do our work, we'll end up looking just as silly as those people who disagree with evolution and global warming. It's science time. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 12/21/09 11:24 PM, "Bret Watson" wrote: At 08:01 AM 22/12/2009, Mike Boberski wrote: >Hi Gary. > >To play devil's advocate: > >Current organizational practices aside, I would say that >organizations really need more and better toolkits and standards for >developers to use, than they need more and better committees. I'd have to agree - whilst SSG is probably a great opportunity for a management consultant, it rarely delivers anything directly useful. In fact I would go as far as to say that if a SSG delivers something useful, the organisation was already ready to deliver the changes. Committees rarely take direct ownership of a problem. Toolsets may or may not deliver results - depending on if there are ways around them - too often you hear the excuse "we can't waste time with that - the business won't wait" However toolset will work if you have a good properly supported securty mgmt function :) Cheers Bret From list-spam at secureconsulting.net Tue Dec 22 10:11:50 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 22 Dec 2009 10:11:50 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: References: Message-ID: <4B30E1B6.8080305@secureconsulting.net> I think the short-term assertion is sound (setup a group to make a push in training, awareness, and integration with SOP), but I'm not convinced the long-term assertion (that is, maintaining the group past the initial push) is in fact meritorious. I think there's a danger in setting up dedicated security groups of almost any sort as it provides a crutch to organizations that then leads to a failure to integrate security practices into general SOP. What is advocated seems to be consistent with how we've approached security as an industry for the past couple decades (or longer), and I don't see this as having the long-term benefit that was desired or intended. It seems that when you don't make people directly responsible and liable for doing the right things, they then fail at the ask and let others do it instead. It's the old "lazy sysadmin" axiom that we script repeatable tasks because it's easier in the long run. The question, then, comes down to one of psychology and people management. How do we make people responsible for their actions such that they begin to adopt better practices? The basic response should be to enact consequences, and I think that now is probably an optimal time for businesses to get very hard-nosed about these sorts of things (high unemployment means lots of people looking for work means employers have the advantage). This perhaps sounds very ugly and nasty, and obviously it will be if taken to an extreme, but we have a serious problem culturally in that non-security people still don't seem to think, on average, that security is in their job description. Solve that problem, and all this other stuff becomes a footnote. fwiw. -ben Gary McGraw wrote: > hi sc-l, > > This list is made up of a bunch of practitioners (more than a > thousand from what Ken tells me), and we collectively have many > different ways of promoting software security in our companies and > our clients. The BSIMM study focuses attention > on software security in large organizations and just at the moment > covers the work of 1554 full time employees working every day in 26 > software security initiatives. One phenomenon we observed in the > BSIMM was that every large initiative has a Software Security Group > (SSG) to carry out and lead software security activities. > > I wrote about our observations around SSGs in this month's informIT > article: > > http://www.informit.com/articles/article.aspx?p=1434903 > > Simply put, an SSG is a critical part of a software security > initiative in all companies with more than 100 developers. (We're > still not sure about SSGs in smaller organizations, but the BSIMM > Begin data (now hovering at 75 firms) may be revealing.) > > Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me > as founding members). Since its inception, we've helped plan, staff, > and carry out ten large software security initiatives in customer > firms. One of the most important first tasks is establishing an SSG. > > > Merry New Year everybody. > > 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. > _______________________________________________ > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "The only source of knowledge is experience." Albert Einstein From gem at cigital.com Tue Dec 22 12:09:26 2009 From: gem at cigital.com (Gary McGraw) Date: Tue, 22 Dec 2009 12:09:26 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <4B30E1B6.8080305@secureconsulting.net> Message-ID: hi ben, You may be right. We have observed that the longer an initiative is underway (we have one in the study that checks in at 14 years old), the more actual activity tends to get pushed out to dev. You may recall from the BSIMM that we call this the satellite. Microsoft has an extensive satellite with 300 or so people embedded throughout their huge company (recall that their SSG is 100). Because the notion of satellite is not as common a phenomenon in our data, we can't draw conclusions as clear as the ones we can draw regarding an SSG. Think of the SSG and the Satellite as "coaches" and "mentors" who are tasked with helping development get it right (not simply cleaning up their messes). I agree that we have spent too much effort over the past decade simply trying to assess the mess and not enough getting dev to change their behavior. The companies we studied in the BSIMM are trying to change dev. As a particular example of where I agree with you that we go off track as a discipline, consider training. Teaching developers about the OWASP top 10 in training may be exciting, but it is nowhere near as important or as effective as teaching defensive programming. (And this from the guy who wrote "Exploiting Software.") Developers need to know how to do it right, not just what bugs look like on TV. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 12/22/09 10:11 AM, "Benjamin Tomhave" wrote: I think the short-term assertion is sound (setup a group to make a push in training, awareness, and integration with SOP), but I'm not convinced the long-term assertion (that is, maintaining the group past the initial push) is in fact meritorious. I think there's a danger in setting up dedicated security groups of almost any sort as it provides a crutch to organizations that then leads to a failure to integrate security practices into general SOP. What is advocated seems to be consistent with how we've approached security as an industry for the past couple decades (or longer), and I don't see this as having the long-term benefit that was desired or intended. It seems that when you don't make people directly responsible and liable for doing the right things, they then fail at the ask and let others do it instead. It's the old "lazy sysadmin" axiom that we script repeatable tasks because it's easier in the long run. The question, then, comes down to one of psychology and people management. How do we make people responsible for their actions such that they begin to adopt better practices? The basic response should be to enact consequences, and I think that now is probably an optimal time for businesses to get very hard-nosed about these sorts of things (high unemployment means lots of people looking for work means employers have the advantage). This perhaps sounds very ugly and nasty, and obviously it will be if taken to an extreme, but we have a serious problem culturally in that non-security people still don't seem to think, on average, that security is in their job description. Solve that problem, and all this other stuff becomes a footnote. fwiw. -ben Gary McGraw wrote: > hi sc-l, > > This list is made up of a bunch of practitioners (more than a > thousand from what Ken tells me), and we collectively have many > different ways of promoting software security in our companies and > our clients. The BSIMM study focuses attention > on software security in large organizations and just at the moment > covers the work of 1554 full time employees working every day in 26 > software security initiatives. One phenomenon we observed in the > BSIMM was that every large initiative has a Software Security Group > (SSG) to carry out and lead software security activities. > > I wrote about our observations around SSGs in this month's informIT > article: > > http://www.informit.com/articles/article.aspx?p=1434903 > > Simply put, an SSG is a critical part of a software security > initiative in all companies with more than 100 developers. (We're > still not sure about SSGs in smaller organizations, but the BSIMM > Begin data (now hovering at 75 firms) may be revealing.) > > Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me > as founding members). Since its inception, we've helped plan, staff, > and carry out ten large software security initiatives in customer > firms. One of the most important first tasks is establishing an SSG. > > > Merry New Year everybody. > > 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. > _______________________________________________ > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "The only source of knowledge is experience." Albert Einstein From boberski_michael at bah.com Tue Dec 22 16:27:54 2009 From: boberski_michael at bah.com (Boberski, Michael [USA]) Date: Tue, 22 Dec 2009 16:27:54 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: References: <4B30E1B6.8080305@secureconsulting.net> Message-ID: <21D3693DA55EF14BB72DCC18FB65B2910233644571@ASHBMBX04.resource.ds.bah.com> "but it is nowhere near as important or as effective as teaching defensive programming" I.e., arming developers with toolkits that perform expected security checks and that result in expected security effects, and making sure they can use them. Not a sermon just a thought, as the local radio station ad goes. Best, Mike B. -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw Sent: Tuesday, December 22, 2009 12:09 PM To: list-spam at secureconsulting.net; Secure Code Mailing List Subject: Re: [SC-L] InformIT: You need an SSG hi ben, You may be right. We have observed that the longer an initiative is underway (we have one in the study that checks in at 14 years old), the more actual activity tends to get pushed out to dev. You may recall from the BSIMM that we call this the satellite. Microsoft has an extensive satellite with 300 or so people embedded throughout their huge company (recall that their SSG is 100). Because the notion of satellite is not as common a phenomenon in our data, we can't draw conclusions as clear as the ones we can draw regarding an SSG. Think of the SSG and the Satellite as "coaches" and "mentors" who are tasked with helping development get it right (not simply cleaning up their messes). I agree that we have spent too much effort over the past decade simply trying to assess the mess and not enough getting dev to change their behavior. The companies we studied in the BSIMM are trying to change dev. As a particular example of where I agree with you that we go off track as a discipline, consider training. Teaching developers about the OWASP top 10 in training may be exciting, but it is nowhere near as important or as effective as teaching defensive programming. (And this from the guy who wrote "Exploiting Software.") Developers need to know how to do it right, not just what bugs look like on TV. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 12/22/09 10:11 AM, "Benjamin Tomhave" wrote: I think the short-term assertion is sound (setup a group to make a push in training, awareness, and integration with SOP), but I'm not convinced the long-term assertion (that is, maintaining the group past the initial push) is in fact meritorious. I think there's a danger in setting up dedicated security groups of almost any sort as it provides a crutch to organizations that then leads to a failure to integrate security practices into general SOP. What is advocated seems to be consistent with how we've approached security as an industry for the past couple decades (or longer), and I don't see this as having the long-term benefit that was desired or intended. It seems that when you don't make people directly responsible and liable for doing the right things, they then fail at the ask and let others do it instead. It's the old "lazy sysadmin" axiom that we script repeatable tasks because it's easier in the long run. The question, then, comes down to one of psychology and people management. How do we make people responsible for their actions such that they begin to adopt better practices? The basic response should be to enact consequences, and I think that now is probably an optimal time for businesses to get very hard-nosed about these sorts of things (high unemployment means lots of people looking for work means employers have the advantage). This perhaps sounds very ugly and nasty, and obviously it will be if taken to an extreme, but we have a serious problem culturally in that non-security people still don't seem to think, on average, that security is in their job description. Solve that problem, and all this other stuff becomes a footnote. fwiw. -ben Gary McGraw wrote: > hi sc-l, > > This list is made up of a bunch of practitioners (more than a thousand > from what Ken tells me), and we collectively have many different ways > of promoting software security in our companies and our clients. The > BSIMM study focuses attention on software security > in large organizations and just at the moment covers the work of 1554 > full time employees working every day in 26 software security > initiatives. One phenomenon we observed in the BSIMM was that every > large initiative has a Software Security Group > (SSG) to carry out and lead software security activities. > > I wrote about our observations around SSGs in this month's informIT > article: > > http://www.informit.com/articles/article.aspx?p=1434903 > > Simply put, an SSG is a critical part of a software security > initiative in all companies with more than 100 developers. (We're > still not sure about SSGs in smaller organizations, but the BSIMM > Begin data (now hovering at 75 firms) may be revealing.) > > Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me > as founding members). Since its inception, we've helped plan, staff, > and carry out ten large software security initiatives in customer > firms. One of the most important first tasks is establishing an SSG. > > > Merry New Year everybody. > > 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. > _______________________________________________ > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "The only source of knowledge is experience." Albert Einstein _______________________________________________ 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 Dec 22 20:56:23 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Tue, 22 Dec 2009 20:56:23 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: References: Message-ID: <4B3178C7.40000@secureconsulting.net> Hi Gary, I've worked with organizations that have taken a similar approach with incident response management. You have a core IR team (within the security dept) and then you designate IR contacts within specific ops teams. This approach seems to work ok, but coordination gets to be problematic, causing me to question scalability and management. Basically, a lot of effort for an impact that seems to follow a logarithmic growth pattern. The more it grows, the more it costs to manage with not as much cost-effectiveness as when the program started. What I wonder is this: how to do we get from heavy use of "security" SMEs to where "security" is simply SOP? Moreover, is this even a good idea, or particularly realistic? From a CMM perspective, it's akin to our being at Level 0 or 1 right now, with Level 5 being the disappearance of dedicated security personnel because there's no longer a need (achievability aside). It's kind of like dissolving large sugar crystals into water... at first you see the sugar and the water separately... then over time you just see the solution without being able to differentiate sugar from water. Anyway... -ben Gary McGraw wrote: > hi ben, > > You may be right. We have observed that the longer an initiative is > underway (we have one in the study that checks in at 14 years old), > the more actual activity tends to get pushed out to dev. You may > recall from the BSIMM that we call this the satellite. Microsoft has > an extensive satellite with 300 or so people embedded throughout > their huge company (recall that their SSG is 100). Because the > notion of satellite is not as common a phenomenon in our data, we > can't draw conclusions as clear as the ones we can draw regarding an > SSG. > > Think of the SSG and the Satellite as "coaches" and "mentors" who are > tasked with helping development get it right (not simply cleaning up > their messes). I agree that we have spent too much effort over the > past decade simply trying to assess the mess and not enough getting > dev to change their behavior. The companies we studied in the BSIMM > are trying to change dev. > > As a particular example of where I agree with you that we go off > track as a discipline, consider training. Teaching developers about > the OWASP top 10 in training may be exciting, but it is nowhere near > as important or as effective as teaching defensive programming. (And > this from the guy who wrote "Exploiting Software.") Developers need > to know how to do it right, not just what bugs look like on TV. > > gem > > company www.cigital.com podcast www.cigital.com/silverbullet blog > www.cigital.com/justiceleague book www.swsec.com > > > On 12/22/09 10:11 AM, "Benjamin Tomhave" > wrote: > > I think the short-term assertion is sound (setup a group to make a > push in training, awareness, and integration with SOP), but I'm not > convinced the long-term assertion (that is, maintaining the group > past the initial push) is in fact meritorious. I think there's a > danger in setting up dedicated security groups of almost any sort as > it provides a crutch to organizations that then leads to a failure to > integrate security practices into general SOP. > > What is advocated seems to be consistent with how we've approached > security as an industry for the past couple decades (or longer), and > I don't see this as having the long-term benefit that was desired or > intended. It seems that when you don't make people directly > responsible and liable for doing the right things, they then fail at > the ask and let others do it instead. It's the old "lazy sysadmin" > axiom that we script repeatable tasks because it's easier in the long > run. > > The question, then, comes down to one of psychology and people > management. How do we make people responsible for their actions such > that they begin to adopt better practices? The basic response should > be to enact consequences, and I think that now is probably an optimal > time for businesses to get very hard-nosed about these sorts of > things (high unemployment means lots of people looking for work means > employers have the advantage). This perhaps sounds very ugly and > nasty, and obviously it will be if taken to an extreme, but we have a > serious problem culturally in that non-security people still don't > seem to think, on average, that security is in their job description. > Solve that problem, and all this other stuff becomes a footnote. > > fwiw. > > -ben > > Gary McGraw wrote: >> hi sc-l, >> >> This list is made up of a bunch of practitioners (more than a >> thousand from what Ken tells me), and we collectively have many >> different ways of promoting software security in our companies and >> our clients. The BSIMM study focuses attention >> on software security in large organizations and just at the moment >> covers the work of 1554 full time employees working every day in >> 26 software security initiatives. One phenomenon we observed in >> the BSIMM was that every large initiative has a Software Security >> Group (SSG) to carry out and lead software security activities. >> >> I wrote about our observations around SSGs in this month's informIT >> article: >> >> http://www.informit.com/articles/article.aspx?p=1434903 >> >> Simply put, an SSG is a critical part of a software security >> initiative in all companies with more than 100 developers. (We're >> still not sure about SSGs in smaller organizations, but the BSIMM >> Begin data (now hovering at 75 firms) may be revealing.) >> >> Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and >> me as founding members). Since its inception, we've helped plan, >> staff, and carry out ten large software security initiatives in >> customer firms. One of the most important first tasks is >> establishing an SSG. >> >> >> Merry New Year everybody. >> >> 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. >> _______________________________________________ >> >> > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: > http://www.secureconsulting.net/ Twitter: > http://twitter.com/falconsview Photos: > http://photos.secureconsulting.net/ Web: > http://falcon.secureconsulting.net/ LI: > http://www.linkedin.com/in/btomhave > > [ Random Quote: ] "The only source of knowledge is experience." > Albert Einstein > > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Hoare's Law of Large Programs: "Inside every large problem is a small problem struggling to get out." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From gem at cigital.com Wed Dec 23 09:05:01 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 23 Dec 2009 09:05:01 -0500 Subject: [SC-L] InformIT: You need an SSG In-Reply-To: <4B3178C7.40000@secureconsulting.net> Message-ID: Hi ben, I would be very much interested in Steve Lipner's opinion here, because Steve ran the IR program at Microsoft a decade ago before he was recruited to lead the SSG. Steve, if you would, please take a look at this thread and let us know what your thinking is RE integrating an IR group and/or an SSG completely and almost invisibly into the mother organization after it has matured. I suspect that some core SSG will always remain even after much of the heavy lifting has been distributed throughout the mother organization by way of satellite. A ratio of 3:1 (satellite:SSG) is what we observe. SWIFT also has a long-lived SSG (14 years). Alain, any insight on this thread you can offer? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 12/22/09 8:56 PM, "Benjamin Tomhave" wrote: Hi Gary, I've worked with organizations that have taken a similar approach with incident response management. You have a core IR team (within the security dept) and then you designate IR contacts within specific ops teams. This approach seems to work ok, but coordination gets to be problematic, causing me to question scalability and management. Basically, a lot of effort for an impact that seems to follow a logarithmic growth pattern. The more it grows, the more it costs to manage with not as much cost-effectiveness as when the program started. What I wonder is this: how to do we get from heavy use of "security" SMEs to where "security" is simply SOP? Moreover, is this even a good idea, or particularly realistic? From a CMM perspective, it's akin to our being at Level 0 or 1 right now, with Level 5 being the disappearance of dedicated security personnel because there's no longer a need (achievability aside). It's kind of like dissolving large sugar crystals into water... at first you see the sugar and the water separately... then over time you just see the solution without being able to differentiate sugar from water. Anyway... -ben Gary McGraw wrote: > hi ben, > > You may be right. We have observed that the longer an initiative is > underway (we have one in the study that checks in at 14 years old), > the more actual activity tends to get pushed out to dev. You may > recall from the BSIMM that we call this the satellite. Microsoft has > an extensive satellite with 300 or so people embedded throughout > their huge company (recall that their SSG is 100). Because the > notion of satellite is not as common a phenomenon in our data, we > can't draw conclusions as clear as the ones we can draw regarding an > SSG. > > Think of the SSG and the Satellite as "coaches" and "mentors" who are > tasked with helping development get it right (not simply cleaning up > their messes). I agree that we have spent too much effort over the > past decade simply trying to assess the mess and not enough getting > dev to change their behavior. The companies we studied in the BSIMM > are trying to change dev. > > As a particular example of where I agree with you that we go off > track as a discipline, consider training. Teaching developers about > the OWASP top 10 in training may be exciting, but it is nowhere near > as important or as effective as teaching defensive programming. (And > this from the guy who wrote "Exploiting Software.") Developers need > to know how to do it right, not just what bugs look like on TV. > > gem > > company www.cigital.com podcast www.cigital.com/silverbullet blog > www.cigital.com/justiceleague book www.swsec.com > > > On 12/22/09 10:11 AM, "Benjamin Tomhave" > wrote: > > I think the short-term assertion is sound (setup a group to make a > push in training, awareness, and integration with SOP), but I'm not > convinced the long-term assertion (that is, maintaining the group > past the initial push) is in fact meritorious. I think there's a > danger in setting up dedicated security groups of almost any sort as > it provides a crutch to organizations that then leads to a failure to > integrate security practices into general SOP. > > What is advocated seems to be consistent with how we've approached > security as an industry for the past couple decades (or longer), and > I don't see this as having the long-term benefit that was desired or > intended. It seems that when you don't make people directly > responsible and liable for doing the right things, they then fail at > the ask and let others do it instead. It's the old "lazy sysadmin" > axiom that we script repeatable tasks because it's easier in the long > run. > > The question, then, comes down to one of psychology and people > management. How do we make people responsible for their actions such > that they begin to adopt better practices? The basic response should > be to enact consequences, and I think that now is probably an optimal > time for businesses to get very hard-nosed about these sorts of > things (high unemployment means lots of people looking for work means > employers have the advantage). This perhaps sounds very ugly and > nasty, and obviously it will be if taken to an extreme, but we have a > serious problem culturally in that non-security people still don't > seem to think, on average, that security is in their job description. > Solve that problem, and all this other stuff becomes a footnote. > > fwiw. > > -ben > > Gary McGraw wrote: >> hi sc-l, >> >> This list is made up of a bunch of practitioners (more than a >> thousand from what Ken tells me), and we collectively have many >> different ways of promoting software security in our companies and >> our clients. The BSIMM study focuses attention >> on software security in large organizations and just at the moment >> covers the work of 1554 full time employees working every day in >> 26 software security initiatives. One phenomenon we observed in >> the BSIMM was that every large initiative has a Software Security >> Group (SSG) to carry out and lead software security activities. >> >> I wrote about our observations around SSGs in this month's informIT >> article: >> >> http://www.informit.com/articles/article.aspx?p=1434903 >> >> Simply put, an SSG is a critical part of a software security >> initiative in all companies with more than 100 developers. (We're >> still not sure about SSGs in smaller organizations, but the BSIMM >> Begin data (now hovering at 75 firms) may be revealing.) >> >> Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and >> me as founding members). Since its inception, we've helped plan, >> staff, and carry out ten large software security initiatives in >> customer firms. One of the most important first tasks is >> establishing an SSG. >> >> >> Merry New Year everybody. >> >> 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. >> _______________________________________________ >> >> > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: > http://www.secureconsulting.net/ Twitter: > http://twitter.com/falconsview Photos: > http://photos.secureconsulting.net/ Web: > http://falcon.secureconsulting.net/ LI: > http://www.linkedin.com/in/btomhave > > [ Random Quote: ] "The only source of knowledge is experience." > Albert Einstein > > > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Hoare's Law of Large Programs: "Inside every large problem is a small problem struggling to get out." http://globalnerdy.com/2007/07/18/laws-of-software-development/ From gem at cigital.com Wed Dec 23 10:18:38 2009 From: gem at cigital.com (Gary McGraw) Date: Wed, 23 Dec 2009 10:18:38 -0500 Subject: [SC-L] Reality Check: Thomson Reuters Message-ID: hi sc-l, Thomson Reuters participated in the BSIMM Europe study released this fall. Tom Lawton has put together a very successful software security initiative which is focused squarely on the business. We discuss Tom's SSG, and the Thomson Reuters approach to software security in episode 11 of Reality Check: http://www.cigital.com/realitycheck/show-011/ Of note, each of the 11 firms covered in Reality Check has a formal SSG. If you want to know more about how these real world SSGs approach software security, simply have a listen. Reality Check, which debuted this year, has covered an impressive list of companies from many different verticals so far: Microsoft, DTCC, EMC, Adobe, Wells Fargo, Paypal, Intuit, Vmware, The Hartford, Nokia, and Thomson Reuters. CSO Magazine syndicates Reality Check. Your feedback on the podcast is welcome. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleage book www.swsec.com