Re: [SC-L] Perspectives on Code Scanning
[Apologies for this reply being a bit behind the discussion - I originally submitted it from a different e-mail account than the one I subscribed with, and so it sailed off to /dev/null.] On Wed Jun 6 18:59 , Michael Silk [EMAIL PROTECTED] sent: On 6/7/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. and that's the problem. the accountability for insecure coding should reside with the developers. it's their fault [mostly]. I started to look through the ACM Code Of Ethics (COE) to see what it says about this. ACM has a general COE: http://www.acm.org/constitution/code.html and one for Software Engineering and Professional Practice: http://www.acm.org/serving/se/code.htm I glanced through them fairly quickly, but neither appears to specifically address secure coding. Reading through both it seems to me that the spirit of both of these COE documents is that everyone involved in the production of software (including developers and managers) has an obligation to ensure the quality/reliability/safety of the software. (It would be interesting to look at other professional organizations' COEs too.) This makes sense to me. If only developers are held responsible, then it is too easy for management to make the work environment difficult for developers who sweat code security, and then wash their hands of it. Similarly, if only the managers are responsible, the developers can take shortcuts to meet deadlines and avoid responsibility if the software breaks. If everybody has a stake in the security of the software, maybe it will happen. ___ 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
James, and all list please apologies for my bad english usage. Looking at your reply I understood I espressed my thoghuts playing bad with words. By saying that vendors has to follow developer licensing, I intended that in my opinion is good that vendors still build tool to aid developers not only executives as some mail in this thread would suggest. I do agree that tool designed to assist developers in writing secure code has to be free and open. I'm writing one of this tool, indeed it's a framework to build such tools but it's not an important different in this topic. I think that an open source approach is the winning here not just for saving money in buying tools but for the widespread knowledge shared among developers and security experts writing the tool itself. Sorry for my firmer mail that doesn't show correctly what is my opinion. The framework for code review tool I'm writing is an owasp project, hosted at sourceforge: http://orizon.sourceforge.net Ciao ciao thesp0nge On 6/8/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: In a previous thread someone appropriately commented that perspectives in this space differ depending upon whether you are a software vendor, government customer or enterprise. I do not disagree that developers need to know how to fix their code. What I am saying is that tools to assist developers in writing better could should be free. Your quote *imho* vendor has to follow developer licensing is where I think it will harm the goals of secure coding at large. Consider the trend within the industry that tools for software development are essentially becoming free. No one pays for IDEs (rare exceptions) when things like Eclipse and Visual Studio have free versions. Enterprise folks however will pay lots of money for tools in the auditing space that help them to quantify risk. The ability to scan large multiple code bases is a different product/problem than scanning while writing code in an IDE. I am saying that more money could be had if folks focus on the first and not the later. Vendors who get it twisted by focusing on the number of developers are dillusional and should ask themselves why aren't but a select few of any enterprise pervasively deploying tools to developers. Give away the developer tools in the same way Microsoft does and you will accelerate your potential sales from the bottom up. Not all sales within places are driven top down... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paolo Perego Sent: Friday, June 08, 2007 5:40 AM To: McGovern, James F (HTSC, IT) Cc: Secure Coding Subject: Re: [SC-L] Perspectives on Code Scanning Hi there, I found this thread very interesting. It's true that developers are the ones who remediate to code insecurity and executives care about how much effort has to be spent over closing branches. Indeed I think the two categories needs a tool approaching the same problem (tell if a code follows security best practices or not) showing results in 2 different languages. Developers need how to know how to fix their code. Executives need to know how much these fixes cost, who will attend them and in how many time fixes will be committed. *imho* vendor has to follow developer licensing... since developer do knows ho to write code but he has to be helped in writing it in a secure way. Safe coding is a concern for both developers than executives. My 2 euro cents Ciao ciao thesp0nge -- Owasp Orizon leader orizon.sourceforge.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. ___ * 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service
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] 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] Perspectives on Code Scanning
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. 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. 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? * 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-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
On 6/7/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. and that's the problem. the accountability for insecure coding should reside with the developers. it's their fault [mostly]. 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. 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? * 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ -- mike 68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c 20 68 65 78 20 64 65 63 6f 64 65 72 2e ___ 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. ___
