Re: [SC-L] Perspectives on Code Scanning
On Thu, 7 Jun 2007, Michael Silk wrote: and that's the problem. the accountability for insecure coding should reside with the developers. it's their fault [mostly]. The customers have most of the power, but the security community has collectively failed to educate customers on how to ask for more secure software. There are pockets of success, but a whole lot more could be done. From a developer-focused perspective, we need to deal with (1) ensuring that developers KNOW how to produce secure code (or interpret tool results), but then (2) actually produce the secure code within given deadlines. I know that (2) is a common topic on this list, but deadlines won't change until customers force the issue, which currently requires weaning them from featuritis, which has such low prospects of success that it's starting to depress me, so I'll stop and we've talked about this before anyway. It would seem to be that tools that developers plug into their IDE should be free since the value proposition should reside elsewhere. I personally love this sentiment, but that's not how the current market is working, and I'm not sure how it would shift to that point. There might be lessons from the anti-virus community's long history (nowadays mostly covering the same stuff usin a subscription model, but they still compete on speed more than quality of information to the end user). I don't know what the vuln scanning tool indusry is up to these days (Nessus, Retina, etc.) but I do know that management-friendly reporting was the bane of that technology's existence for years. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] SC-L Digest, Vol 3, Issue 102
Hi Ken, welcome back from your sunny vacation. I wanted to reply to your 'invitation' on my thoughts for the next big thing: One technological problem I have with secure programming is testing. I cannot seem to stay on top of the latest methods of attacks and yet ask for more billable time whenever a new one pops-up. For example, I thought my application was safe from XSS until I ran into JavaScript Hijacking after the testing phase (thanks Brian Chess). It seems like our testing abilities are still up to the sophistication of the human element. I would like to see a push for more compliance testing from tools that will scan code (including jar files) for the latest attacks and certify that baseline. That way, I can take a lot of my dependence from the human element and use more automation to drive my testing techniques. The current generation of security tools doesn't give me the warm and fuzzies yet. Jason Grembi Web Developer On 6/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Send SC-L mailing list submissions to sc-l@securecoding.org To subscribe or unsubscribe via the World Wide Web, visit http://krvw.com/mailman/listinfo/sc-l or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of SC-L digest... Today's Topics: 1. Who's To Blame For Insecure Software? Maybe You (Kenneth Van Wyk) 2. What's the next tech problem to be solved in software security? (Kenneth Van Wyk) 3. Re: What's the next tech problem to be solved in software security? (Michael Silk) 4. Re: What's the next tech problem to be solved in software security? (Wietse Venema) 5. IBM to catch Watchfire security technology | Tech News on ZDNet (Kenneth Van Wyk) 6. FW: What's the next tech problem to be solved in softwaresecurity? (Michael S Hines) 7. Re: What's the next tech problem to be solved in softwaresecurity? (Michael S Hines) -- Message: 1 Date: Tue, 5 Jun 2007 22:09:58 -0400 From: Kenneth Van Wyk [EMAIL PROTECTED] Subject: [SC-L] Who's To Blame For Insecure Software? Maybe You To: Secure Coding SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Some interesting (IMHO) stats coming out of Gartner security summit. One that jumped off the page at me was that 57% of the attendees believe that independent security research labs are providing a useful and valuable service. Whether you agree or not, the article below is an interesting read. http://www.informationweek.com/security/showArticle.jhtml? articleID=199901402pgno=1queryText= Cheers, Ken P.S. I'm surprised to say that I've so far had no takers on my question yesterday -- what is the next technology hurdle for us to clear? Perhaps everyone is off enjoying their summer breaks like I was last week... - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com -- next part -- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2454 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20070605/acd5114f/attachment-0001.bin -- Message: 2 Date: Wed, 6 Jun 2007 06:05:26 -0400 From: Kenneth Van Wyk [EMAIL PROTECTED] Subject: [SC-L] What's the next tech problem to be solved in software security? To: Secure Coding SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hi SC-L, [Hmmm, this didn't make it out to the list as I'd expected, so here's a 2nd try. Apologies for any duplicates. KRvW] At the SC-L BoF sessions held to date (which admittedly is not exactly a huge number, but I'm doing my best to see them continue), I like to ask those that attend what we can be doing to make SC-L more useful and meaningful to the subscribers. Of course, as with all mailing lists, SC-L will always be what its members make of it. However, at one recent SC-L BoF session, it was suggested that I pose periodic questions/issues for comment and discussion. As last week was particularly quiet here with my hiatus and all, this seems like a good opportunity to give that a go, so... What do you think is the _next_ technological problem for the software security community to solve? PLEASE, let's NOT go down the rat hole of senior management buy-in, use [this language], etc. (In fact, be warned that I will /dev/null any responses in this thread that go there.) So, what technology could/would make life easier for a secure software developer? Better source code analysis? High(er) level languages to help automate design reviews? Better security testing tools? To any of these, *better* in what ways, specifically? Any takers?
Re: [SC-L] Perspectives on Code Scanning
and that's the problem. the accountability for insecure coding should reside with the developers. it's their fault [mostly]. The customers have most of the power, but the security community has collectively failed to educate customers on how to ask for more secure software. There are pockets of success, but a whole lot more could be done. --- the software should work and be secure (co-requirements). The user community has been educated to accept CTL-ALT-DEL and wait as an acceptable method of computing (and when things are really haywire - resintall the OS and loose all your work). We've got a long way to go for them to expect software to also be secure, since they now accept that it doesn't work right as SOP. Mike Hines [EMAIL PROTECTED] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Perspectives on Code Scanning
McGovern, James F \(HTSC, IT\) [mailto:[EMAIL PROTECTED] writes: the value of tools in this space are not really targeted at developers but should be targeted at executives who care about overall quality and security folks who care about risk. While developers are the ones to remediate, the accountability for secure coding resides elsewhere. Sort of. There are multiple levels of accountability. As has been said here many times: the developers should be held accountable for producing secure software, but the management must give them the time and tools to do so, and management usually places far higher priority on things like ease of use and especially on time to market. It would seem to be that tools that developers plug into their IDE should be free since the value proposition should reside elsewhere. Many of these tools provide audit functionality and allow enterprises to gain a view into their portfolio that they previously had zero clue about and this is where the value should reside. Heh. Yeah, I'd like to see some executive dashboard saying things like whose code currently generates the most warnings, especially if those warnings are from security analysis tools. B-) Of course, most executives won't bother looking at something that techy, let alone understand the significance. B-( If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get vendors to ignore developer specific licensing and instead focus on enterprise concerns? Unfortunately, that often means that ANY license at all for it will be horrendously expensive, so that small shops are totally cut out. -Dave -- Dave Aronson Specialization is for insects. -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Perspectives on Code Scanning
--- the software should work and be secure (co-requirements). And already we have trouble, because this immediately raises not only the question what does `work' mean? but also secure against what?. And answering that correctly requires input from the customer. Which we (TINW) won't have until customers recognize a need for security and get enough clue to know what they want to be secure against. And we all know how likely customers are to have clue (of just about any sort). (Actually, there are markets where the customer usually is clued. Oddly enough, they also tend to be markets wherein software isn't security Swiss cheese. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Perspectives on Code Scanning
And answering that correctly requires input from the customer. Which we (TINW) won't have until customers recognize a need for security and get enough clue to know what they want to be secure against. I can't exactly agree with this as there is a distinction (or should be IMO) between security features and security of the code. If you are asserting that the customer must tell you how many security features to implement based on their requirements. I'll agree 100%. Stuff like, I don't need 3 types of military grade encryption added, I'm just doing recipe sorting. That kind of stuff. However if you are waiting around for the customer to request software that isn't subject to buffer overflows or can't be hijacked by input validation I think you are missing the point. That level of security comes out of the quality of the dev team, process, and company producing the software, not out of customer requirements. Customer expect this level of security implicitly just like they expect their toasters won't burst into flames every time they try to toast a bagel. They have learned to accept less by the craptastic quality of code from many vendors for many years, but would happily revert to the initial expectation of I just want it to work and not provide additional risk to my organization. It remains (weakly) arguable that IF the customer really wanted secure software they'd have stronger legal agreements with suppliers that allow recourse and compensation for failed security, but that brings in yet another of the often technically clueless, Lawyers. I do believe that the focal point of getting change from where we stand now is at the feet of the customer, because it starts out as an economic problem first. If you pay more to get secure code or pay to buy weak security but fast to market code, then you somewhat get what you paid for. Vendors will produce the lowest quality for the highest price if the market lets them. PS - speaking of lawyers... :) The views expressed here are my own, not those of my company ... etc etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of der Mouse Sent: Thursday, June 07, 2007 8:07 AM To: SC-L@securecoding.org Subject: Re: [SC-L] Perspectives on Code Scanning --- the software should work and be secure (co-requirements). And already we have trouble, because this immediately raises not only the question what does `work' mean? but also secure against what?. And answering that correctly requires input from the customer. Which we (TINW) won't have until customers recognize a need for security and get enough clue to know what they want to be secure against. And we all know how likely customers are to have clue (of just about any sort). (Actually, there are markets where the customer usually is clued. Oddly enough, they also tend to be markets wherein software isn't security Swiss cheese. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Perspectives on Code Scanning
And answering that [secure against what?] correctly requires input from the customer. Which we (TINW) won't have until customers recognize a need for security and get enough clue to know what they want to be secure against. If you are asserting that the customer must tell you how many security features to implement based on their requirements. I'll agree 100%. Stuff like, I don't need 3 types of military grade encryption added, I'm just doing recipe sorting. That kind of stuff. Well, I was thinking more like, needs to withstand potentially hostile user input on this input channel, but not on that one. As a simple example, a webserver usually needs to withstand potentially hostile input from the network, but not from its config file. (If it *can* handle a hostile config file without crashing, great. But if there's a choice to be made, I'd put the brain cycles into hardening the network interface before the config-file interface.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Perspectives on Code Scanning
inline On 6/6/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I really hope that this email doesn't generate a ton of offline emails and hope that folks will talk publicly. It has been my latest thinking that the value of tools in this space are not really targeted at developers but should be targeted at executives who care about overall quality and security folks who care about risk. While developers are the ones to remediate, the accountability for secure coding resides elsewhere. Nice email James. These conversations are always enlightening. The responses tend to illuminate who has what experience types, between (a) university software experience, (b) government software-project experience, and (c) enterprise software experience. That makes a lot of difference in these discussions. Most enterprise /and/ small ISV developers I know, the good ones, either take pride in their quality of code and self-manage security issues, or are fast and productive and don't give a crap. And why should they give a crap? It's not their problem domain. The armchair software-security pundits: Shame on you. You didn't properly transcode these Hebrew and Latin code pages to avoid XSS attacks, dummy. The fast effective developer: I delivered your functional specifications to the letter, on time, and the transcoding engine is FAST. What's the problem here? It would seem to be that tools that developers plug into their IDE should be free since the value proposition should reside elsewhere. Many of these tools provide audit functionality and allow enterprises to gain a view into their portfolio that they previously had zero clue about and this is where the value should reside. So of tools that plug into the IDE, let's distinguish between *source-code* and *run-time* scanners. Source scanners I suspect will die a slow death, because sooner or later they are going to integrate into the IDE and per-seat value will plummet. They will be a given feature of IDEs. Sooner or later the IDE vendors will either buy integrate, or come out with their own tools. Take Compuware, the quality is pretty low, but if I were a betting man I would bet that the bar gets set at low-quality included-functionality rather than set at $50k per-seat amazing quality source code analzyer. I believe this is different from run-time or human design analysis, largely because of different business case. For example: I have some clients that really like their Fortify tools, but they really don't like all the time and critical development resources it takes to use them, and how expensive they are. Cool tools, sexy technology, but they are hard to align with the business case and business goals for software development on multiple levels. Run-time analysis is different. Run-time scanner IDE-plugins as a concept is laughable, at best. Seriously -- who thinks that run-time scanners for developers is a viable idea? Run-time analysis's strengths are different too. It is easier at run-time to discover and analyze fundamental design flaws (note: I did not say find them all, but definitely find indication of them), and to identify emergent behaviors. At best IDE plugins can perform some form of unit testing, but beyond verification of basic data-typing and IFOF/IFOE type issues, meh, not very useful. Not to mentioned entirely outside of the IDE problem-domain. Conclusion: two sets of problems, source analysis, and run-time analysis. I think there is a good-enough bar for source analysis that will get set fairly low and wind up baked into IDEs... similar to the Viz Studio /GS switch. I've already seen a pretty effective one that will probably wind up in one of the next releases of Visual Studio. It's actually better than some of the commercial offerings today, and baked in. Spot on James. Human source analysis for Design Pattern issues, I think, this will always be needed. Same for run-time analysis. Different problem-domains they solve for though. If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get vendors to ignore developer specific licensing and instead focus on enterprise concerns? So some marketing guy one day grokked there are only n-number of security people per organization that scan run scanners, but there are Multiplier(n * 33.5) number of developers per organizationwow! We could sell all those developers scanners!!! Ka-Ching. That sort of thinking is pretty cool, leads to some cool sales growth graphs and profitability projections. Need board-room meeting material, fits perfectly into that circular-arrow graph everyone has with TCO and Lifecycle Management and ROI and how it all loops together and saves everyone big bags of money after they spend up front. This circular lifecycle-management graph is labeled Security in the SDLC and shows how you can buy a lot of developer/IDE-scanners and have even the cheapest developers scan their code up front, and you'll save big in
[SC-L] JSON of Ajax -or- Little Web 2.0 bugs versus big Web 2.0 flaws: darkreading
Hi sc-l, This month's installment of my darkreading.com column focuses some much needed attention on the bug/flaw distinction that I think we need to pay more attention to. In particular, many of you will recall the discussion of Javascript hijacking that Brian Chess posted to this list in March. I found that work an interesting generalization of the Gmail/JSON problem. However, I think that instead of focusing so much attention on the particulars of Javascript transport we need to focus on ***trust boundaries***. Read all about it here: http://www.darkreading.com/document.asp?doc_id=125931 Please crosspost responses here and to the darkreading website. I am interested in your opinion of the current bug parade problem we have in 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What's the next tech problem to be solved in software security?
On Wed, 6 Jun 2007, Wietse Venema wrote: more and more people, with less and less experience, will be programming computer systems. The challenge is to provide environments that allow less experienced people to program computer systems without introducing gaping holes or other unexpected behavior. I completely agree with this. This is a grand challenge for software security, so maybe it's not the NEXT problem. There's a lot of tentative work in this area - safe strings in C, SafeInt, StackGuard/FormatGuard/etc., non-executable data segments, security patterns, and so on. But these are bolt-on methods on top of the same old languages or technologies, and some of these require developer awareness. I know there's been some work in secure languages but I'm not up-to-date on it. More modern languages advertise security but aren't necessarily catch-alls. I remember one developer telling me how his application used Ruby on Rails, so he was confident he was secure, but it didn't stop his app from having an obvious XSS in core functionality. An example is the popular PHP language. Writing code is comparatively easy, but writing secure code is comparatively hard. I'm working on the second part, but I don't expect miracles. PHP is an excellent example, because it's clearly lowered the bar for programming and has many features that are outright dangerous, where it's understandable how the careless/clueless programmer could have introduced the issue. Web programming in general, come to think of it. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What's the next tech problem to be solved in software
On Wed, 6 Jun 2007, Wietse Venema wrote: more and more people, with less and less experience, will be programming computer systems. The challenge is to provide environments that allow less experienced people to program computer systems without introducing gaping holes or other unexpected behavior. I completely agree with this. This is a grand challenge for software security, so maybe it's not the NEXT problem. There's a lot of tentative work in this area - safe strings in C, SafeInt, StackGuard/FormatGuard/etc., non-executable data segments, security patterns, and so on. But these are bolt-on methods on top of the same old languages or technologies, and some of these require developer awareness. I know there's been some work in secure languages but I'm not up-to-date on it. You may find this interesting as this is a subject I feel strongly about myself. http://www.qasec.com/cycle/securityframeworks.shtml - Robert http://www.cgisecurity.com/ http://www.qasec.com/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What's the next tech problem to be solved in software security?
I've recently been working on providing better secure programming defaults. There's a great opportunity for doing so for applications written on top of frameworks/libraries. See our paper Towards Security by Construction for Web 2.0 Applications at a recent W2SP workshop. -Ben On 6/7/07, Steven M. Christey [EMAIL PROTECTED] wrote: On Wed, 6 Jun 2007, Wietse Venema wrote: more and more people, with less and less experience, will be programming computer systems. The challenge is to provide environments that allow less experienced people to program computer systems without introducing gaping holes or other unexpected behavior. I completely agree with this. This is a grand challenge for software security, so maybe it's not the NEXT problem. There's a lot of tentative work in this area - safe strings in C, SafeInt, StackGuard/FormatGuard/etc., non-executable data segments, security patterns, and so on. But these are bolt-on methods on top of the same old languages or technologies, and some of these require developer awareness. I know there's been some work in secure languages but I'm not up-to-date on it. More modern languages advertise security but aren't necessarily catch-alls. I remember one developer telling me how his application used Ruby on Rails, so he was confident he was secure, but it didn't stop his app from having an obvious XSS in core functionality. An example is the popular PHP language. Writing code is comparatively easy, but writing secure code is comparatively hard. I'm working on the second part, but I don't expect miracles. PHP is an excellent example, because it's clearly lowered the bar for programming and has many features that are outright dangerous, where it's understandable how the careless/clueless programmer could have introduced the issue. Web programming in general, come to think of it. - Steve ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-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, -Ben ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
