Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
Hi Gunnar, I apologize to everybody if I have come across as being harsh. From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her lose face. The responsibility of secure software is not at the developer level in most cases, which is why I've spoken at regional IASA events (www.iasahome.org), with overwhelming positive responses, and will continue to try to reach the decision makers (as an OWASP representative) because trying to engage developers directly at this point in time at the maturity level of software security in APAC is not the most effective way to go about it. I'm sure, though, that at financial institutions they get it, but almost all of my clients are government and media/communications companies. Also, sorry to everybody for taking this thread off-topic. Stephen On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: stephen i spend at least half my time working directly with developers. for some reason i have not communicated as well as i should to you, what i am saying is that the job is too hard for developers *because* the security industry has let them down by sending them on a fool's errand of least privilege. the problem or target in your words IS with security people NOT developers. they have other problems just not an endless quixotic quest for least privilege. i am not repeat not throwing developers under the bus in this argument. i am ready, willing and possibly able to be proven wrong on this point and maybe there is a cost effective way to deploy least privilege in the real world just want to make sure that i communicate my argument. -gunnar (who is now letting go) On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: I can't let this go. Gary, you are self-professed working with financial institutions and high-end customers. Gunnar, you are the same, at least what I gather from your Silver Bullet podcast when talking about the difference between SOA (top down) and Web 2.0 (bottom up). No flame war intended, but a healthy discussion should be in order. So please don't talk about developers as targets. They/we are the lowest on the totem pole. Direct your arrows at the people that you deal with. Plain and simple. Cheers, Stephen On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: look, i am a consultant. i work in lots of different companies. lots of different projects. i don't see these distinctions in black and white. sometimes the cto and managers are best positioned to help companies develop more secure software, sometimes architects, sometimes auditors, and many many times in my experience developers are best positioned. but i really, truly do not care who does it. my only goal is more effective security mechanisms and some pragmatic roadmap to get there. we are in the infancy of this industry (think automotive safety circa 1942, all seat belts and brakes), we are in no position to turn away help from anyone who can help. every company and every project is different, if your organization is set up so that developers are not empowered, but managers and CTOs are then by all means work with them. but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the too hard pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. -gunnar On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: It's a real cop-out for you guys, as titans in the industry, to go after developers. I'm disappointed in both of you. And Gary, you said One of the main challenges is that developers have a hard time thinking about the principle of least privilege . Developers are NEVER asked to think about the principle of least privilege. Or your world of software security must be very very very different from mine (and I think my world at least equals yours but by about 2 billion people more, which might be irrelevant now but a little more relevant in the future :-) With the greatest, deepest respect to both of you, Stephen On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans [EMAIL PROTECTED] wrote:
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
With all due respect, I think this is where the process of secure coding fails. I think it stems from poor education, but its compounded by an arrogant cop out that developers have no power. Your view is not alone. I hear it a lot. And I think its an easy out. I agree with you that buy in for designing secure code must come from the top down. It has to start at the senior management level and work its way down the line. However, there are certain day-to-day actions that a developer completely has control over. With tight deadlines and lack of resources its easy to sacrifice good principles and practices to get code out. No one denies that. But there are certain things developers CAN and SHOULD be doing. They should be thinking more defensively about their code. If you consider the criticality of many design flaws of today, a lot of it can be controlled by better understanding how the data traverses the systems, and more importantly how to address it as it crosses trust boundaries. By understanding this, its easier to see the entry points that matter most that an adversary may use, and allows the developer to decide how to deal with the code as it fails. This has very little to do with management. This is the difference between strategic and tactical decisions on project development. A developer doesn't need to ask his boss if he can or should use exception handling correctly. To validate all untrusted user input. To check return codes when calling functions. Sadly... in this day and age... most developers don't even do that correctly. And thats a simple example of this entire problem. Until we stop blaming others and take responsibility in the code we write, things won't change. As Gary mentioned... there is an attitude from many developers that they can abdocate responsibility in what they are doing. Its hard to get them to even SAY security. Never mind actually making an effort to do something about it. I appreciate your opinion that you need to approach and work with the decision makes. You are absolutely correct. That's a strategic component of writing secure code. However the tactical approach to actually DO IT fall on developers. It shouldn't BE a special process. It should be part of their day-to-day thinking, attitude and function in their field of work. Guess where this all starts? By educating the developer. Which is why we squarely need to reflect on them to tactically do it. -- Regards, Dana Epp Microsoft Security MVP On Tue, Nov 25, 2008 at 9:01 AM, Stephen Craig Evans [EMAIL PROTECTED] wrote: Gunnar, Developers have no power. You should be talking to the decision makers. As an example, to instill the importance of software security, I talk to decision makers: project managers, architects, CTOs (admittedly, this is a blurred line - lots of folks call themselves architects). If I go to talk about software security to developers, I know from experience that I am probably wasting my time. Even if they do care, they have no effect overall. Your target and blame is wrong; that's all that I am saying. Stephen On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: Sorry I didn't realize developers is an offensive ivory tower in other parts of the world, in my world its a compliment. -gunnar On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: HI, maybe the problem with least privilege is that it requires that developers:... IMHO, your US/UK ivory towers don't exist in other parts of the world. Developers have no say in what they do. Nor, do they care about software security and why should they care? So, at least, change your nomenclature and not say developers. It offends me because you are putting the onus of knowing about software security on the wrong people. Cheers, Stephen On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson [EMAIL PROTECTED] wrote: maybe the problem with least privilege is that it requires that developers: 1. define the entire universe of subjects and objects 2. define all possible access rights 3. define all possible relationships 4. apply all settings 5. figure out how to keep 1-4 in synch all the time do all of this before you start writing code and oh and there are basically no tools that smooth the adoption of the above. i don't think us software security people are helping anybody out in 2008 by doing ritual incantations of a paper from the mid 70s that may or may not apply to modern computing and anyhow is riddled with ideas that have never been implemented in any large scale systems compare these two statements Statement 1. Saltzer and Schroeder: f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
At 9:32 PM -0800 11/25/08, Brian Chess wrote: Larry, I'm not sure I get your meaning. You say you don't think it's a dry well, but then you say programmers ignore the privilege management facilities at their disposal. I mean they ignore it until security overseers (800.53a, PCI DSS, 8500.2 evaluators) come by and force them to fix it. At 10:57 AM -0800 11/25/08, Andy Steingruebl wrote: On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson mailto:[EMAIL PROTECTED][EMAIL PROTECTED]mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the too hard pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. Certainly it is not a dry well. For the operating system I deal with, application programmers _consistently_ ignore the facility provided for fine-grained access to files and leave users with coarse-grained access as their only recourse. So attempting to apply it is not a dry well and not too hard - just typically done as a retrofit due to political rather than techical circumstance. I had a friend who was working on software where multi-million dollar accounts failed to balance correctly. That defect got considerable management attention. The same _could_ be done for security. -- Larry Kilgallen ___ 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. ___
[SC-L] Regional differences in software security
Hi Stephen (et al), I think this idea of regional differences is worth exploring a bit. In my work at cigital I have come to believe that there is a difference in approach between the east coast of the US and the west coast. The east coast led by financial services firms in NY and Boston has moved well past the bug parade and penetration testing to a more strategic approach to the problem. These firms approach software security as a people, process, technology problem that involves cultural change. They have made some impressive progress (about which more in late December). It's true that regulation plays a big role in moving the general approach forward, starting with SOX up through the FFIEC and OCC guidance. By contrast, many (but not all) ISVs on the west coast are still relying on penetration testing to check the software security box. That's because the prevailing attitude out west seems to be something like software security is important, but our code is WAY better than that example code you're waving around. Pen testing may be a necessity to disavow people of this belief. Incidentally, the west coast approach is currently much more about code, code, code and less about business risk, training, architecture, white box testing and the like. That said, the west coast approach seems to be tracking the east coast with a lag of 12-18 months. So all told this is good news for the field. Just so you know, I am aware of 22 large scale programs underway, 9 of which we're closely studying in the Maturity Model effort. I am interested to hear your impressions of AsiaPAC and software security. Thanks for cluing us in. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/26/08 3:05 AM, Stephen Craig Evans [EMAIL PROTECTED] wrote: Hi Gunnar, I apologize to everybody if I have come across as being harsh. From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her lose face. The responsibility of secure software is not at the developer level in most cases, which is why I've spoken at regional IASA events (www.iasahome.org), with overwhelming positive responses, and will continue to try to reach the decision makers (as an OWASP representative) because trying to engage developers directly at this point in time at the maturity level of software security in APAC is not the most effective way to go about it. I'm sure, though, that at financial institutions they get it, but almost all of my clients are government and media/communications companies. Also, sorry to everybody for taking this thread off-topic. Stephen On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: stephen i spend at least half my time working directly with developers. for some reason i have not communicated as well as i should to you, what i am saying is that the job is too hard for developers *because* the security industry has let them down by sending them on a fool's errand of least privilege. the problem or target in your words IS with security people NOT developers. they have other problems just not an endless quixotic quest for least privilege. i am not repeat not throwing developers under the bus in this argument. i am ready, willing and possibly able to be proven wrong on this point and maybe there is a cost effective way to deploy least privilege in the real world just want to make sure that i communicate my argument. -gunnar (who is now letting go) On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: I can't let this go. Gary, you are self-professed working with financial institutions and high-end customers. Gunnar, you are the same, at least what I gather from your Silver Bullet podcast when talking about the difference between SOA (top down) and Web 2.0 (bottom up). No flame war intended, but a healthy discussion should be in order. So please don't talk about developers as targets. They/we are the lowest on the totem pole. Direct your arrows at the people that you deal with. Plain and simple. Cheers, Stephen On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: look, i am a consultant. i work in lots of different companies. lots of different projects. i don't see these distinctions in black and white. sometimes the cto and managers are best positioned to help companies develop
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
There is a lot of USA firm coding done outside our shores. Thus the attitude you are reporting impacts the software I am buying both for my desktop as well as the upcoming cloud applications. This is the part that concerns me. As a consumer of code when it's in my possession I am then able to do what I can to augment the security of it. When it's in the cloud, I'm depending on the vendor of the cloud to have thought about security . We need to get to the place where you can come back in a few years and say that the culture has changed. IMHO don't apologize. It shows that we still need to get consumers/buyers of code to care that Developers are taught to care. We have work to do. Stephen Craig Evans wrote: Hi Gunnar, I apologize to everybody if I have come across as being harsh. From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her lose face. The responsibility of secure software is not at the developer level in most cases, which is why I've spoken at regional IASA events (www.iasahome.org), with overwhelming positive responses, and will continue to try to reach the decision makers (as an OWASP representative) because trying to engage developers directly at this point in time at the maturity level of software security in APAC is not the most effective way to go about it. I'm sure, though, that at financial institutions they get it, but almost all of my clients are government and media/communications companies. Also, sorry to everybody for taking this thread off-topic. Stephen On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: stephen i spend at least half my time working directly with developers. for some reason i have not communicated as well as i should to you, what i am saying is that the job is too hard for developers *because* the security industry has let them down by sending them on a fool's errand of least privilege. the problem or target in your words IS with security people NOT developers. they have other problems just not an endless quixotic quest for least privilege. i am not repeat not throwing developers under the bus in this argument. i am ready, willing and possibly able to be proven wrong on this point and maybe there is a cost effective way to deploy least privilege in the real world just want to make sure that i communicate my argument. -gunnar (who is now letting go) On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: I can't let this go. Gary, you are self-professed working with financial institutions and high-end customers. Gunnar, you are the same, at least what I gather from your Silver Bullet podcast when talking about the difference between SOA (top down) and Web 2.0 (bottom up). No flame war intended, but a healthy discussion should be in order. So please don't talk about developers as targets. They/we are the lowest on the totem pole. Direct your arrows at the people that you deal with. Plain and simple. Cheers, Stephen On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: look, i am a consultant. i work in lots of different companies. lots of different projects. i don't see these distinctions in black and white. sometimes the cto and managers are best positioned to help companies develop more secure software, sometimes architects, sometimes auditors, and many many times in my experience developers are best positioned. but i really, truly do not care who does it. my only goal is more effective security mechanisms and some pragmatic roadmap to get there. we are in the infancy of this industry (think automotive safety circa 1942, all seat belts and brakes), we are in no position to turn away help from anyone who can help. every company and every project is different, if your organization is set up so that developers are not empowered, but managers and CTOs are then by all means work with them. but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the too hard pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. -gunnar On Nov
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
On Nov 26, 2008, at 3:05 AM, Stephen Craig Evans wrote: Hi Gunnar, I apologize to everybody if I have come across as being harsh. From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her lose face. The responsibility of secure software is not at the developer level in most cases This has really important implications, and is worthy of thought and discussion. On the one hand, *right now*, it justifies the complaints about outsourcing: That you really can't trust software produced in Asia. On the other hand, the (relative) command-and-control nature of development in Asia means that, should management there decide that security is an important issue - and since given the nature of their business, they are very sensitive to customer demand, that would mean that their customers tell them unambiguously that it's what they'll be judged on *and actually act that way* - Asian outsourcers are likely to be much more effective at getting their organizations to focus on secure practices than we are here in the more free-wheeling West. -- Jerry ___ 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. ___
