Re: [SC-L] How do we improve s/w developer awareness?
George Capehart wrote: Yes, assuming management cares . . . and that's *my* broken record . . . :) If the tone of my comments was a bit harsh, it is most emphatically not intended to be directed at your thoughts. It is only because of my intense frustration with the situation. When Management wants software systems to be secure, they will be. Not perfectly so, but within published limits. Management will see to it that the appropriate policies and processes are in place to assure it. Management will see to it that delivering a product that passes the certification process is more important than delivering a product by a certain date. Management will require that a security architecture be in place before the design process starts, etc., etc., etc. The board will hold Management accountable for the risk that the use of the system entails. When that happens, Management will come to realize that security is *their* problem, *not* InfoSec's problem. /Until/ that happens, changing frameworks, development tools, methodologies or whatever will not solve the problem. The Problem just isn't in IT. As Dennis Miller says: But that's just my opinion. I could be wrong. Which brings up the next broken record. Management will not care until it affects the bottom line not to care. As long as it costs money to care (missed deadlines, more tools and training, etc.) and it doesn't cost anything not to care, then they *shouldn't* care. Either the consumers have to care so that security problems cost sales, or the liability laws need to change so that security problems result in financial penalties. Consumers in general are too diverse a group to really change what they want. It would be very difficult to educate the entire consumer base to the collateral costs of poor security in products and to set valid expectations about what is and is not possible. The all software has bugs mantra is now very ingrained. Changing liability laws on the other hand is a simple solution. This will force managers to do the proper due diligence just to CYA. Sure, there will be increased litigation costs, but a couple high profile cases and the whole process of development will change. And I don't buy the programming is too hard, there will always be bugs argument. Maybe there will always be bugs, but I don't think we have reached the point where we can really make a call about how hard it really is. We call programmers engineers, but very, very few software engineers deserve the title. Would you accept it was too hard to do a stress analysis from the engineer designing a bridge? -- blu It is bafflingly paradoxical that the United States is by far the world's leading scientific nation while simultaneously housing the most scientifically illiterate populace outside the Third World. - Richard Dawkins Brian Utterback - OP/N1 Revenue Product Engineering, Sun Microsystems Ph/VM: 877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
RE: [SC-L] How do we improve s/w developer awareness?
I've been trying to get IT Auditors and the Audit community in general to apply the same due dilligence to operating systems (infrastructure or general controls) that they apply to applications systems testing. I'm not aware of anyone in the IT Audit community doing OS audits - to verify that the systems work as advertised and do not fail where they should not. I become quite aware of this a few years ago when I was in a group doing Penetraiton Testing of an OS and discovered many flaws. Why don't auditors audit the OS? I, frankly, don't know. But Auditors do have the ear of upper management and they could be the ones indicating the weaknessed in the infrastructure that puts the organization at risk. We wouldn't put in a new payroll system without verifying that it works properly. Yet we're more than willing to unpackage and plug in a desktop computer without the same due dilligence. Why?It's beyond me. Perhaps if more people were asking the right questions to the right people ... ? Why we've come to accept the CTL_ALT_DEL 'three finger salute' as SOP is beyond me. Of course the issues above aren't limited to one particular OS. There are plenty of problems to go around. (see the work done at Univ of Wisconsin - the Fuzz Testing project http://www.cs.wisc.edu/~bart/fuzz/fuzz.html ) Mike Hines --- Michael S Hines [EMAIL PROTECTED]
RE: [SC-L] How do we improve s/w developer awareness?
FYI this is part of a notice that went out to financial institutions recently. Complete Financial Institution Letter: http://www.fdic.gov/news/news/financial/2004/fil12104.html Highlights: Management is responsible for ensuring that commercial off-the-shelf (COTS) software packages and vendor-supplied in-house computer system solutions comply with all applicable laws and regulations. The guidance contained in this financial institution letter will assist management in developing an effective computer software evaluation program to accomplish this objective. An effective computer software evaluation program will mitigate many of the risks - including failure to be regulatory compliant - that are associated with software products throughout their life cycle. Management should use due diligence in assessing the quality and functionality of COTS software packages and vendor-supplied in-house computer system solutions. Distribution: FDIC-Supervised Banks (Commercial and Savings) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greenarrow 1 Sent: Monday, November 29, 2004 6:08 PM To: George Capehart Subject: Re: [SC-L] How do we improve s/w developer awareness? Words could not be spoken better. This is my argument from the get go. I, to, am tired of seeing everyone blame it on the Dev department when the orders from above are I want this now and fast. Maybe, we can focus and convince upper level management that security is as important as the greed, money, bells, whistles. But while I support Dev I still do not understand how some companies development departments can include tight secured coding in a short time frame and others seem to provide excuses or just do not care. Customers are now looking at the security of programs. Slowly, consumers are finally looking at security flaws mainly because of the media coverage that computer softwares are creating. While it may only be top contenders in the software field customers are now questioning other programs they have which I support fully. I can see this in the rise of subscribers to certain Security Flaw Alerts which has risen over 71% within the last 3 months. Just a word of warning as consumers become more aware of security in the softwares they purchase companies that do not secure will start showing a downslide in purchases. It is happening to one major company as we email each other on issues. Regards, George Greenarrow1 InNetInvestigations-Forensics - Original Message - From: George Capehart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 28, 2004 5:18 PM Subject: Re: [SC-L] How do we improve s/w developer awareness? On Thursday 11 November 2004 10:26, Kenneth R. van Wyk allegedly wrote: Greetings, In my business travels, I spend quite a bit of time talking with Software Developers as well as IT Security folks. One significant different that I've found is that the IT Security folks, by and large, tend to pay a lot of attention to software vulnerability and attack information while most of the Dev folks that I talk to are blissfully unaware of the likes of Full-Disclosure, Bugtraq, PHRACK, etc. I haven't collected any real stats, but it seems to me to be at least a 90/10% and 10/90% difference. (Yes, I know that this is a gross generalization and there are no doubt significant exceptions, but...) I believe that this presents a significant hurdle to getting Dev folks to care about Software Security issues. Books like Gary McGraw's Exploiting Software do a great job at explaining how software can be broken, which is a great first step, but it's only a first step. Apologies for the two-week latency in this reply. I don't have as much time for the lists as I used to. I have read the rest of this thread, and I didn't see any comments that address a dimension that is, for me, the most salient. I feel like a broken record because this topic crops up on one security-related list or another at least once a quarter and I end up saying the same thing every time. I'm going to say it again, though, because I really believe that it is important . . . Dev folks will care about security when their managers care about security. If time-to-market and bells and whistles are more important to management than security is, that's where dev folks will spend their time. It is their job to do what their managers tell them to do. When management decides that it is more important to deliver a product that is based on a robust security architecture and which is built and tested with security in mind, it will be. Until then, it won't. At one time or another in my career, I have held just about every position in the software development food chain. I have had the president of the company tell me: I don't care what it takes, you /*will*/ have this project done and delivered in four months! Well, we delivered a
Re: [SC-L] How do we improve s/w developer awareness?
Changing liability laws on the other hand is a simple solution. But at what price? It would kill off open source completely, as far as I can see, in the jurisdiction(s) in question. (How many open source projects could afford to defend a liability suit even if they (a) wanted to and (b) had a won case?) Of course, if you don't mind that, go right ahead. You don't say where you are, but looking over your message I see reason to thin it's the USA, and I long ago wrote off the USA as a place to write code. I think it could be a very good thing for the USA to try such laws; it would give us hard data about what their effect is, rather than the speculation (however well-informed) that's all we have to go on now - and it quite likely would have the pleasant side effect of pushing most open source projects out into the free (or at least freer) world. /~\ The ASCIIder 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
Re: [SC-L] How do we improve s/w developer awareness? [Virus Checked]
I have to say I find your comparison between bridge engineers and software engineers rather troubling. In response to your question: 'Would you accept it was too hard to do a stress analysis from the engineer designing a bridge?' I think, regrettably, we probably would do these days. Remember that little incident in 2000 when the London millennium bridge was closed immediately after opening due to excessive wobbling when people walked across it? I can't guarantee that my recollection is accurate, but I'm sure they were trying to put this down to that software classic, a 'Design feature'. Seems that far from Software Engineers taking the bridge engineers approach, we may be seeing the exact reverse happening. :-) -- Graham Coles. Brian Utterback Brian.Utterback@To: George Capehart [EMAIL PROTECTED] Sun.COM cc: [EMAIL PROTECTED] Sent by: Subject: Re: [SC-L] How do we improve s/w developer awareness? [Virus Checked] [EMAIL PROTECTED] coding.org 02/12/2004 13:25 George Capehart wrote: Yes, assuming management cares . . . and that's *my* broken record . . . :) If the tone of my comments was a bit harsh, it is most emphatically not intended to be directed at your thoughts. It is only because of my intense frustration with the situation. When Management wants software systems to be secure, they will be. Not perfectly so, but within published limits. Management will see to it that the appropriate policies and processes are in place to assure it. Management will see to it that delivering a product that passes the certification process is more important than delivering a product by a certain date. Management will require that a security architecture be in place before the design process starts, etc., etc., etc. The board will hold Management accountable for the risk that the use of the system entails. When that happens, Management will come to realize that security is *their* problem, *not* InfoSec's problem. /Until/ that happens, changing frameworks, development tools, methodologies or whatever will not solve the problem. The Problem just isn't in IT. As Dennis Miller says: But that's just my opinion. I could be wrong. Which brings up the next broken record. Management will not care until it affects the bottom line not to care. As long as it costs money to care (missed deadlines, more tools and training, etc.) and it doesn't cost anything not to care, then they *shouldn't* care. Either the consumers have to care so that security problems cost sales, or the liability laws need to change so that security problems result in financial penalties. Consumers in general are too diverse a group to really change what they want. It would be very difficult to educate the entire consumer base to the collateral costs of poor security in products and to set valid expectations about what is and is not possible. The all software has bugs mantra is now very ingrained. Changing liability laws on the other hand is a simple solution. This will force managers to do the proper due diligence just to CYA. Sure, there will be increased litigation costs, but a couple high profile cases and the whole process of development will change. And I don't buy the programming is too hard, there will always be bugs argument. Maybe there will always be bugs, but I don't think we have reached the point where we can really make a call about how hard it really is. We call programmers engineers, but very, very few software engineers deserve the title. Would you accept it was too hard to do a stress analysis from the engineer designing a bridge? -- blu It is bafflingly paradoxical that the United States is by far the world's leading scientific nation while
[no subject]
[EMAIL PROTECTED] Subject: Re: [SC-L] How do we improve s/w developer awareness? Date: Thu, 2 Dec 2004 12:52:35 -0800 Sender: [EMAIL PROTECTED] Precedence: bulk Mailing-List: contact [EMAIL PROTECTED] ; run by MajorDomo List-Id: Secure Coding Mailing List sc-l.securecoding.org List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.securecoding.org/list/ List-Unsubscribe: http://www.securecoding.org/list/ List-Help: http://www.securecoding.org/list/charter.php List-Archive: http://lists.virus.org Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] I think we also have to realize that bridge building has had centuries of time to evolve, and learn from its mistakes. Secure software engineering as a discipline is still in its infancy. I would love to see the quality of bridges in its first 50 years of development. That's of course no excuse for the current state of software development. But comparisons like this are like statistics... 86.12345% of them are made up, or have no sane correlation. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 02, 2004 8:25 AM Subject: Re: [SC-L] How do we improve s/w developer awareness? I have to say I find your comparison between bridge engineers and software engineers rather troubling. In response to your question: 'Would you accept it was too hard to do a stress analysis from the engineer designing a bridge?' I think, regrettably, we probably would do these days. Remember that little incident in 2000 when the London millennium bridge was closed immediately after opening due to excessive wobbling when people walked across it? I can't guarantee that my recollection is accurate, but I'm sure they were trying to put this down to that software classic, a 'Design feature'. Seems that far from Software Engineers taking the bridge engineers approach, we may be seeing the exact reverse happening. :-) -- Graham Coles.
