Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
The just get the bloody thing to work is usually an attitude foisted on developers by the business side. I work in an internal application security function for a large enterprise and i'm yet to meet a developer who wasn't concerned about security. Developer education is very important and we have a lot of it available for out developers, some of it even compulsory. However, unless there is the will of the business behind it, developer concerns are oft pushed aside in the interest of expediency. I find the business side usually does have a genuine interest in security and quality, however they are concepts that remain largely unquantifiable, and in the case of security you only need to mess up once to end up with a nasty situation. It's can be a tough sell getting time to focus on these things, given they can be so vague. In the case of my organisation, business side support comes from both internal advocacy of security practises by our function and externally imposed legal requirements. Mostly the latter ;) Filtering inputs is NOT hard, and most developers are getting better at things like that. However, the problems of application security go beyond the developer level, and it's important not to lose sight of that fact. If there were an easy solution everything would already be perfectly secure. Pete On Wed, Aug 26, 2009 at 12:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Great strategy! Our hacker friends will love it. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Monday, August 24, 2009 8:35 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced ___ 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] Language agnostic secure coding guidelines/standards?
Hi All Thank you for your replies, they have been very useful and will certainly help identifying things that need to appear in the standard. We're trying to make the standard something that is easily auditable, and have decided to further split items into two categories, those that should checked in development and those that should appear in the project documentation (e.g. things like definitions of log integrity/confidentiality requirements etc). I'm also happy to say that within our organisation we already have secure coding training available for developers, support channels for developers with queries, language specific guidance, automated tools that can be used to detect software flaws as well as an internal auditing and pentesting function. Needless to say it's been a big effort to get all this in place. The policy is an important piece of the puzzle which will hopefully help ensure the training and tools are utilised by developers. These things are all great, but from an organisational perspective one of the most important things for us is the ongoing risk management of identified issues. We have a lot of applications in various stages of development and production, and a lot of developers. Tracking known issues, remediation timelines, and who is responsible for what is also a very big part of it, especially in larger organisations. Again I'm happy to say we have an internally developed system for doing this. Rather than just giving myself a gold star on a mailing list, I would say to the vendors here interoperability is a big thing for us, as no one product does it all to the level we require (and it's unlikely they ever will). We are far more likely to buy things that play nicely with what we have already, and so far, most of the tools we use do. Gold stars all round. Anyway, thanks again for all the information. Cheers, Pete On Thu, Nov 20, 2008 at 8:00 AM, Gary McGraw [EMAIL PROTECTED] wrote: badness-ometer-pedia! most excellent descriptive phrase. You guys should change the official name! Incidentally, one of the best uses data like these can be put to is training. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/17/08 4:49 PM, Steven M. Christey [EMAIL PROTECTED] wrote: The CWE Research view (CWE-1000) is language-neutral at its higher-level nodes, and decomposes in some areas into language-specific constructs. Early experience suggests that this view is not necessarily developer-friendly, however, because it's not organized around the types of concepts that developers typically think in. http://cwe.mitre.org/data/definitions/1000.html (click the Graph tab on the top right of the page to see the breakdown) Obviously the CWE is a badness-ometer-pedia but suggests some areas that your guidelines would hopefully address. - 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. ___ ___ 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. ___
[SC-L] Language agnostic secure coding guidelines/standards?
Hi all I've been tasked with developing a secure coding standard for my employer. This will be a policy tool used to get developers to fix issues in their code after an audit, and also hopefully be of use to developers as they work to ensure they are compliant. The kicker is it needs to cover things ranging from cobol running on a mainframe, in house network monitoring software in c and perl through to web and desktop applications in java or .net. I've been doing some searching to see if there is anything similar online, but everything i've found is mostly focussed on web applications or language/platform specific. Does anyone know of something that may be what I'm looking for? It's basically going to be a checklist where every item will be something that can be audited, and the things that aren't relevant to a given application can be ignored. The broad sections I have so far are: Input/Output handling Session Control and Management Memory allocation and Management Authentication Management Authorisation Management Data Protection Logging and Auditing Application Errors and Exceptions Thanks in advance Pete ___ 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] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
On Dec 3, 2007 8:34 AM, silky [EMAIL PROTECTED] wrote: how does anyone know how to hire anyone for a job that they themselves aren't qualified for? well, you pay professionals to do it. recruitment agents. this should be part of their role. and absolutely agreed; most certification is useless, secure programming is no different. Um, have you ever dealt with a recruitment agent? How are they going to tell? The guy had secure coding on his CV? Ok A few points in general: 1 - I'm yet to meet a programmer who intentionally creates security problems in production code. Most developers I meet are very much interested in secure coding, so in that respect things are a lot better than they were 5 years ago when very few people knew, and even less cared. Penalizing developers for writing insecure code is not the answer, because as others have pointed out all it will do is encourage people to cover things up and never talk about security vulnerabilities. You have to take into account the environment in which they work, which is most likely not conductive to producing quality output, and also that even the best people will make mistakes. I've heard of some companies taking the attitude that code level security issues are OK, because it means they didn't waste too much money on higher quality outsourced developers ... and from a security vendor no less, whoda thunk ;-) 2 - Source code scanners still have a long way to go. I realize there are a lot of vested interests on this list, but based on my recent experiences with commercial scanners it is pure folly relying on them to secure your applications. They are useful tools with a real place, and better than previous generations, but overpriced and still of limited value. That they are sold as quality tools rather than security tools is telling. Running code through 3 different scanners is great, but a) who has the time, b) who can justify 3 different tools to management, c) who's going to wield the rod, and d) why do you think anyone would actually care about the rod? 3 - Taxes, government bodies, penalties, etc. all bullshit for now. When its possible to prove a program is correct, ok, but until then its way to fuzzy and wobbly to start throwing bureaucracy at. It would be good to see some form of self-regulation, ideally from a credible independent source, not a cert merchant or security services vendor. Yours in brevity, Pete ___ 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] re-writing college books - erm.. ahm...
On 11/7/06, Wall, Kevin [EMAIL PROTECTED] wrote: Developers have to cut corners somewhere, and since security issues are not paramount, that's often what gets overlooked. this is the biggest issue i think. it gets overlooked because management dont value it. partly because its expensive to do, and theres no real qualitative or quantitative measures of success. you cant go to your management and say i spent 20% of my time working on security issues, it cost us $x but it will save our customers $y, and security was improved by 15% or if you can, you're bullshitting, but will probably get a nice bonus :) i think a college level textbook would have limited benefit. there is plenty of information out there at the moment for those who are interested, both on the net and in book form. i suppose its nice to have a single point of reference though. however, most graduates aren't really good practical programmers. they know stuff like what a for loop is and how recursion works, which is great, but they learn the ins and outs of developing when they get their first real job. so they get their first job, and basically learn from the people they're working with. the people they're working with and learning from are busy, and working under time and budget constraints. they're just not going to focus on security, even if they had the knowledge to do it effectively, because other things are more important to the companies management. most managers (and developers too i guess) do care about security, but only in the way people care about global warming. they know global warming is bad, but oh gee what are we going to do, oh today i remembered to turn off my desk lamp when i left the office. great. same with security, you dont have to be a genius to work out security holes are bad, but oh gee what are you actually going to do about it? if organisations dont really care about software security, a security concious developer faces an uphill battle. if two devs are working on some code, one does it slower but more securely, the other does it quicker but less securely, who's going to look better, in a typical organisation? your fresh grad is going to learn quick enough what companies want from them. as time goes by, they become the ones breaking in the new developers, so the cycle continues. a book isnt going to help this, it probably wont hurt, but i dont think the lack of available literature is a big problem. a good organisation will focus on what its customers want. untill the customers start kicking up a storm about vulnerabilities, there's little impetus for management to devote resources to security. i think this is one of the things microsoft has done well, over the last few years they have started taking security seriously, and i can only assume its because their customers starting complaining. they still have a lot of security issues (an insuperable amount imo), but it shows that for companies to start taking software security seriously, it has to be something the customer wants. ___ 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
