Re: [SC-L] Application Insecurity --- Who is at Fault?
On Apr 7, 2005 12:43 PM, Blue Boar [EMAIL PROTECTED] wrote: Michael Silk wrote: See, you are considering 'security' as something extra again. This is not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you blew something. All before it hits beta. All of this is part of _programming_ though. To me it should be on the same level as, say, using an 'Array' at an appropriate point in a program. You won't say to management: Oh, I didn't use an array there because you didn't ask me to.. It's ridiculous to even consider. And so it should be with so-called 'Security' that is added to applications. Consider the bridge example brought up earlier. If your bridge builder finished the job but said: ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall. You would be panic stricken. Fear would overcome you, and you might either run for the hills, or attempt to strangle the builder... either way, you have a right to be incredibly upset by the lack of 'security' in your bridge. You WONT (as is the case now) sit back and go: Oh well, fair enough. I didn't ask you to implement that, I just said 'build a bridge'. Next time i'll ask. Or make sure the public specifically requests resistence to that angle of pushing. Hopefully my point is obvious... -- Michael Any solution that ends up with us having secure software will neccessarily need to address this step as well as all others. The right answer just might end up being suck it up, and take the resource hit. It might be switch to the language that lends itself to you coding securly at 75% the productivity rate of sloppy coding. I don't know enough about the languages involved to participate in that debate. Strangely enough, for the last year and a half or so, I've been sitting here being QA at a security product company. Doing software right takes extra resources. I are one. Ryan
Re: [SC-L] Application Insecurity --- Who is at Fault?
Michael Silk wrote: See, you are considering 'security' as something extra again. This is not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you blew something. All before it hits beta. Any solution that ends up with us having secure software will neccessarily need to address this step as well as all others. The right answer just might end up being suck it up, and take the resource hit. It might be switch to the language that lends itself to you coding securly at 75% the productivity rate of sloppy coding. I don't know enough about the languages involved to participate in that debate. Strangely enough, for the last year and a half or so, I've been sitting here being QA at a security product company. Doing software right takes extra resources. I are one. Ryan
Re: [SC-L] Application Insecurity --- Who is at Fault?
Michael Silk wrote: Consider the bridge example brought up earlier. If your bridge builder finished the job but said: ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall. All bridges have certain limits. There is difference between a footbridge and bridge that can be driven over with a tank. The difference is also reflected in cost. You are advocating always building tank bridge. Which is understandable attitude - this way you are mostly safe. However, in some cases it is *economically feasible* to just build a simpler bridge and accept the fact that it will break under some conditions. Ultimately it is a matter of economics. Sometimes releasing something earlier is worth more than the cost of later patches. And managers/customers are aware of it. -- Margus
Re: [SC-L] Application Insecurity --- Who is at Fault?
Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Greetings++, Another interesting article this morning, this time from eSecurityPlanet. (Full disclosure: I'm one of their columnists.) The article, by Melissa Bleasdale and available at http://www.esecurityplanet.com/trends/article.php/3495431, is on the general state of application security in today's market. Not a whole lot of new material there for SC-L readers, but it's still nice to see the software security message getting out to more and more people. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
RE: [SC-L] Application Insecurity --- Who is at Fault?
I think it's a matter of SHARED reponsibility. Yes, the programmers and their managers are directly responsible. But it's consumers who create demand, and consumers who, out of ignorance, continue to fail to make the connection between bad software security and the viruses, privacy, and other issues about which they are becoming increasingly concerned. The consumer can't be held responsible for his ignorance...at least not yet. Because practioners of safe software have not done a very good job of getting the message out in terms that consumers, vs. other software practioners and IT managers, can understand. I propose that the following is the kind of message that might make a consumer sit up and listen: We understand that you buy software to get your work or online recreation done as easily as possible. But being able to get that work done WITHOUT leaving yourself wide open to exploitation and compromise of YOUR computer and YOUR personal information is also important, isn't it? A number of software products, including some of the most popular ones, are full of bugs and other vulnerabilities that DO leave those programs wide open to being exploited by hackers so they can get at YOUR personal information, and take over YOUR computing resources. Why is such software allowed to be sold at all? Because no-one regulates the SECURITY of the software products that these the companies put out, least of all the programmers who write that software. And, more importantly, because you the consumer hasn't been told before that you can make a difference. You can vote with your feet. Demand that the software you use not be full of holes and 'undocumented features' that can be exploited by hackers. When you go out to buy a lawn mower, you wouldn't buy a model that has a well-published track record of its blades flying off. By the same token, you shouldn't buy a software package that has a well-documented track record of being successfully compromised by viruses, Trojan horses, and other hacker tricks. If we can start to raise consumer awareness in terms that consumers can understand (avoiding the arcane terminology of software practitioners), maybe we can start reducing demand for notoriously insecure software products, and increasing demand for software that is developed with security in mind. -- Karen Goertzel, CISSP Booz Allen Hamilton 703-902-6981 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk Sent: Wednesday, April 06, 2005 9:40 AM To: Kenneth R. van Wyk Cc: Secure Coding Mailing List Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Greetings++, Another interesting article this morning, this time from eSecurityPlanet. (Full disclosure: I'm one of their columnists.) The article, by Melissa Bleasdale and available at http://www.esecurityplanet.com/trends/article.php/3495431, is on the general state of application security in today's market. Not a whole lot of new material there for SC-L readers, but it's still nice to see the software security message getting out to more and more people. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
Re: [SC-L] Application Insecurity --- Who is at Fault?
And I couldn't disagree more with your perspective, except for your inclusion of managers in parenthesis. Developers take direction and instruction from management, they are not autonomous entities. If management doesn't make security a priority, then only so much secure/defensive code can be written before the developer is admonished for being slow/late/etc. While sloppy habits are one thing, it's entirely another to have management breathing down your neck, threatening to ship your job overseas, unless you get code out the door yesterday. It's an environment that fosters insecure habits and resultant products. I'm not talking about habits like using strncpy vs strcpy, I'm talking about validation of user input, ensuring a secure architecture to begin with, and the like. The later takes far more time to impliment than is given in many environments. The former requires sufficient specifications be given upfront - otherwise you have insufficient information to correctly use a function like strncpy. Kind Regards, -dsp Michael Silk wrote: Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael [...]
RE: [SC-L] Application Insecurity --- Who is at Fault?
Wonder what happens if we apply that same logic to building design or bridge design and contstruction? Those who don't place blame at the source are just trying to blame shift. Bad idea.. Mike Hines --- Michael S Hines [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk Sent: Wednesday, April 06, 2005 8:40 AM To: Kenneth R. van Wyk Cc: Secure Coding Mailing List Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Greetings++, Another interesting article this morning, this time from eSecurityPlanet. (Full disclosure: I'm one of their columnists.) The article, by Melissa Bleasdale and available at http://www.esecurityplanet.com/trends/article.php/3495431, is on the general state of application security in today's market. Not a whole lot of new material there for SC-L readers, but it's still nice to see the software security message getting out to more and more people. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
Re: [SC-L] Application Insecurity --- Who is at Fault?
I would think this might work, but I - if I ran a software development company - would be very scared about signing that contract... Even if I did everything right, who's to say I might not get blamed? Anyway, insurance would end up being the solution. What you *should* be scared of is a contract that's silent about security. Courts will have to interpret (make stuff up) to figure out what the two parties intended. I strongly suspect courts will read in terms like the software shall not have obvious security holes. They will probably rely on documents like the OWASP Top Ten to establish a baseline for trade practice. Contracts protect both sides. Have the discussion. Check out the OWASP Software Security Contract Annex for a template.(http://www.owasp.org/documentation/legal.html). --Jeff - Original Message - From: Michael Silk [EMAIL PROTECTED] To: Kenneth R. van Wyk [EMAIL PROTECTED] Cc: Secure Coding Mailing List SC-L@securecoding.org Sent: Wednesday, April 06, 2005 9:40 AM Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Greetings++, Another interesting article this morning, this time from eSecurityPlanet. (Full disclosure: I'm one of their columnists.) The article, by Melissa Bleasdale and available at http://www.esecurityplanet.com/trends/article.php/3495431, is on the general state of application security in today's market. Not a whole lot of new material there for SC-L readers, but it's still nice to see the software security message getting out to more and more people. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
Re: [SC-L] Application Insecurity --- Who is at Fault?
Jeff, On Apr 7, 2005 11:00 AM, Jeff Williams [EMAIL PROTECTED] wrote: I would think this might work, but I - if I ran a software development company - would be very scared about signing that contract... Even if I did everything right, who's to say I might not get blamed? Anyway, insurance would end up being the solution. What you *should* be scared of is a contract that's silent about security. If you're silent you can claim ignorance :D But of course, I agree. Security should be mentioned under the part of applications Working Right. What I meant I would be scared of, however, is that if the contract didn't fully specify what I would be taking responsibility for. I.e. I could be blamed if some misconfiguration on the server allowed a user to run my tool/component as admin and enter some information or do whatever. The contract would have to be specific (technical?) so-as to avoid problems like this. But I presume you have had far more experience with these issues than I have... can you share any w.r.t to problems like that? Because I can imagine [if I wasn't ethical] trying to blame a security problem in My Big Financial Website on a 3rd party tool if I could. Courts will have to interpret (make stuff up) to figure out what the two parties intended. I strongly suspect courts will read in terms like the software shall not have obvious security holes. They will probably rely on documents like the OWASP Top Ten to establish a baseline for trade practice. Contracts protect both sides. Have the discussion. Check out the OWASP Software Security Contract Annex for a template.(http://www.owasp.org/documentation/legal.html). Yes, I've read the before, and even discussed it with you! :) -- Michael --Jeff - Original Message - From: Michael Silk [EMAIL PROTECTED] To: Kenneth R. van Wyk [EMAIL PROTECTED] Cc: Secure Coding Mailing List SC-L@securecoding.org Sent: Wednesday, April 06, 2005 9:40 AM Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Greetings++, Another interesting article this morning, this time from eSecurityPlanet. (Full disclosure: I'm one of their columnists.) The article, by Melissa Bleasdale and available at http://www.esecurityplanet.com/trends/article.php/3495431, is on the general state of application security in today's market. Not a whole lot of new material there for SC-L readers, but it's still nice to see the software security message getting out to more and more people. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
Re: [SC-L] Application Insecurity --- Who is at Fault?
On Apr 7, 2005 1:16 AM, Goertzel Karen [EMAIL PROTECTED] wrote: I think it's a matter of SHARED reponsibility. Yes, the programmers and their managers are directly responsible. But it's consumers who create demand, and consumers who, out of ignorance, continue to fail to make the connection between bad software security and the viruses, privacy, and other issues about which they are becoming increasingly concerned. Quite frankly I don't think consumers need to care at all about this. Do you, when buying chips, ask how they were cooked? Do you go back and inspect the kitchen? Do you ask for a report on their compliance to local health laws? No. The most you might do is glance at a box with some ticks on it. Why should software be any different? Why place the burden on consumers to now evalutate the security of your products? Not only don't they care, nor do they have the time, they wouldn't know where to start! The consumer can't be held responsible for his ignorance... Exactly! Because practioners of safe software have not done a very good job of getting the message out in terms that consumers, vs. other software practioners and IT managers, can understand. I propose that the following is the kind of message that might make a consumer sit up and listen: We understand that you buy software to get your work or online recreation done as easily as possible. But being able to get that work done WITHOUT leaving yourself wide open to exploitation and compromise of YOUR computer and YOUR personal information is also important, isn't it? Answer: Duh. A number of software products, including some of the most popular ones, are full of bugs and other vulnerabilities that DO leave those programs wide open to being exploited by hackers so they can get at YOUR personal information, and take over YOUR computing resources. Answer: So? I need to use them. Why is such software allowed to be sold at all? Because no-one regulates the SECURITY of the software products that these the companies put out, least of all the programmers who write that software. And, more importantly, because you the consumer hasn't been told before that you can make a difference. You can vote with your feet. Answer: But how will I pay my GST next month if I can't use my accounting program? I don't want to waste time transferring all my data to another product... Demand that the software you use not be full of holes and 'undocumented features' that can be exploited by hackers. Answer: How? I buy my software at a department store. If we can start to raise consumer awareness It's easy to blame the consumer - it means we programmers/management/whatever don't need to do anything until they ask us. But they will _never_ be able to ask all the right questions. _Never_. So to put that requirement on them is just our 'easy way out' of the problem. -- Michael -- Karen Goertzel, CISSP Booz Allen Hamilton 703-902-6981 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk Sent: Wednesday, April 06, 2005 9:40 AM To: Kenneth R. van Wyk Cc: Secure Coding Mailing List Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: Greetings++, Another interesting article this morning, this time from eSecurityPlanet. (Full disclosure: I'm one of their columnists.) The article, by Melissa Bleasdale and available at http://www.esecurityplanet.com/trends/article.php/3495431, is on the general state of application security in today's market. Not a whole lot of new material there for SC-L readers
Re: [SC-L] Application Insecurity --- Who is at Fault?
Inline On Apr 7, 2005 1:06 AM, Dave Paris [EMAIL PROTECTED] wrote: And I couldn't disagree more with your perspective, except for your inclusion of managers in parenthesis. Developers take direction and instruction from management, they are not autonomous entities. If management doesn't make security a priority, See, you are considering 'security' as something extra again. This is not right. My point is that management shouldn't be saying 'Oh, and don't forget to add _Security_ to that!' The developers should be doing it by default. then only so much secure/defensive code can be written before the developer is admonished for being slow/late/etc. Then defend yourself ... ! Just as you would if the project was too large due to other reasons. Don't allow security to be 'cut off'. Don't walk in and say 'Oh, I was just adding security to it,'. A manager will immediately reply: Oh, we don't care about that Instead say: Still finishing it off... (This _has_ worked for me in the past, by the way...) While sloppy habits are one thing, it's entirely another to have management breathing down your neck, threatening to ship your job overseas, unless you get code out the door yesterday. Agreed. (Can't blame consumers for this issue, however..) I'm talking about validation of user input, This is something that all programmer should be doing in _ANY_ type of program. You need to handle input correctly for your app to function correctly, otherwise it will crash with a dopey user. ensuring a secure architecture to begin with, and the like. 'Sensible' architecture too, though. I mean, that's the whole point of a design - it makes sense. For example, an app may let a user update accounts based on ID's, but it doesn't check if the user actually owns the ID of the account they are updating. They assume it's true because they only _showed_ them ID's they own. You'd hope that your 'sensible' programmer would note that and confirm that they did, indeed, update the right account. Not only for security purposes, but for consistency of the _system_. The app just isn't doing what it was 'specified' to do if the user can update any account. It's _wrong_ - from a specification point of view - not just 'insecure'. You would, I guess, classify this as something the managers/consumers need to explicitly ask for. To me, it seems none of their business. As a manager, you don't want to be micromanaging all these concepts (but we are - CIO's...) they should be the sole responsibility of the programmer to get right. The later takes far more time to impliment than is given in many environments. The former requires sufficient specifications be given upfront Agreed. -- Michael Michael Silk wrote: Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about programming _correctly_! The article says it's a 'communal' problem (i.e: consumers should _ask_ for secure software!). This isn't exactly true, and not really fair. Insecure software or secure software can exist without consumers. They don't matter. It's all about the programmers. The problem is they are allowed to get away with their crappy programming habits - and that is the fault of management, not consumers, for allowing 'security' to be thought of as something seperate from 'programming'. Consumers can't be punished and blamed, they are just trying to get something done - word processing, emailing, whatever. They don't need to - nor should. really. - care about lower-level security in the applications they buy. The programmers should just get it right, and managers need to get a clue about what is acceptable 'programming' and what isn't. Just my opinion, anyway. -- Michael [...]
