Re: [SC-L] Software Security Training for Developers
My general observation of training firms in this area is that they all tend to use freelance trainers who float between the firms. The notion of customized courseware is something they sell as a feature but honestly feels more like a way to avoid actually developing consistent training approaches where they instead rely on the individual hired trainer and what they happen to feel comfortable teaching. The issue with training in the language/platform of choice gets more difficult depending upon what type of environment you reside. If you look inside the average Fortune enterprise whose primary business model isn't technology (e.g. Intel, IBM, Microsoft, etc) then you will tend to find lots of variety of languages used in production environments with no language (with the exception of possibly COBOL) being dominant. This simple fact causes enterprises who have a variety of languages when combined with the need for across the board training to make training non-specific to any particular language. Many of the tools also give feedback in a language-specific context while writing code, so at some level I do believe that language-specific training is not required. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M Sent: Thursday, August 16, 2007 7:23 PM To: sc-l@securecoding.org Subject: [SC-L] Software Security Training for Developers What are folks' experiences with software security training for developers? By this, I'm referring to teaching developers how to write secure code. Ex. things like how to actually code input validation routines, what evil functions and libraries to avoid, how to handle exceptions without divulging too much info, etc. Not how to hack applications. There are quality courses and training that show you how to break into apps--which are great, but my concern is that if you are a developer (vs. a security analyst, QA type, pen-tester, etc.),even when you know what could happen, unless you've been specifically taught how to implement these concepts in your language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting the most bang for the buck from them. What vendors teach it? How much does it cost? Actual impact realized? Tx Chris McCown, GSEC(Gold) Intel Corporation * (916) 377-9428 | * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * 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] Software Security Training for Developers
Hi James, I am not sure if my email was interpreted correctly. What I was saying is the things to do to customizing the training to fit your individual environment for example if you have specific policies and/or guidelines they are integrated into the training. For example: if you have a password policy for your web application saying that the passwords should be atleast 9 characters long alpha numeric, then when teaching a developers class this should be explicitly called out and shown or if you are required to be PCI compliant, often debug logs have credit card information or passwords or session id stored in them in clear text. This should be explicitly called out and developers need to be made aware of them. Hope this helps clarify what I was saying. Our class does cover generic policies and guidelines in terms of best practices and is part of course material. If you would like to know more about them, might I suggest talking offline and discussing it in more detail ? Regards, Nish. _ From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 10:22 AM To: Nish Bhalla Cc: sc-l@securecoding.org Subject: RE: [SC-L] Software Security Training for Developers One of the things that is somewhat frustrating as a customer to training and software vendors are statements such as some general policy and guidelines without any pointers to what they should specifically contain. Public URLs are greatly appreciated. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nish Bhalla Sent: Thursday, August 16, 2007 11:21 PM To: 'McCown, Christian M' Cc: sc-l@securecoding.org Subject: Re: [SC-L] Software Security Training for Developers Hi Chris, We at Security Compass have been doing that for developers for about 2 years now. We have done this type of training and also the training from the pen tester angle. Some of the things that we have seem make this training much more effective are [] If the direction for the training and security initiative is coming in from the top rather than just from one manager (not to say that having it from one manager doesn't help) [] If there are some general policy and guidelines to building secure software [] If there are general guidelines to build secure architecture [] if there are though processes in place for updating the existing SDLC with security in place to improve the overall direction of the company towards a more secure application development practice [] Finally if the training is developed around these kind of practices and customized to your specific environment. We also think providing different kinds of training for different levels of people is important, i.e. a training for managers, a training for architects, a training for QA/Security professionals and finally a training for developers. Each has a specific goal in mind and speaking in the individual language so to speak to each group. Hope this helps, If you would like to chat more just email me. Nish. * 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] Software Security Training for Developers
Hi Hollis, Thanks for the questions. I think this is the kind of information you're looking for and I've tried to keep my answers very non-salesy. - What languages/OS/environments are you developing in? Well, we're a consultancy, so we develop in whatever language the client desires. (:-) As for our defensive programming courses, we focused on JavaEE, core Java, .NET, and C/C++. We have had recent requests for COBOL, but not for PHP, Ruby, or Python, as examples. - Does your training address your language/OS/environment? If so, what percentage? If I understand correctly, the answer is most training addresses it. As odd as it may seem, the general market demand is for good defensive programming techniques in the native language. Many customers ask for customization based on their threat model and specific business objectives. A smaller percentage ask for course customization for general technologies (e.g., encryption) and a much smaller percentage ask for customization based on the frameworks they are using (e.g., Spring and Acegi). On the other had, they all hate seeing examples from frameworks they don't use. - How long is the/each course? We build most of our courses as 1-day modules that can be linked together (e.g., one group of lead architects and lead developers might get Fundamentals, then Architecture Risk Analysis, then Defensive Programming, while some QA folks might get Fundamentals, then Security Requirements and Abuse Cases, then Risk-Based Security Testing, and so on). A lot of organizations simply can't shut down development or testing for more than a day or two at a time. - did you go with inclass, self-paced, JIT or a combination. And which aspects to each? All our classes are initially developed as instructor-led training. Some are then re-cast as eLearning. - What is your audience size? And what percentage did you train? - Over what period of time? For Fundamentals classes, we can deal with larger class sizes (e.g., 30). For Defensive Programming, we try to cap at 20 due to the nature of the labs and the time it takes to get through the questions. For Architecture Risk Analysis, a smaller class size is a little better because it's so interactive. Between on-site classes, conference tutorials, some public training, and so on for analysts, architects, developers, and testers, we've trained thousands of individuals over the years - Was it mandatory? And to Sammy's point, at what management level was it loudly supported? Well, it was being paid for, so it was always mandatory. (:-) The more interesting question may be Did the students go willingly? Whenever we had time to work with management to craft a message appropriately tuned to the intended audience, we've had good, willing participation. The management level we've worked with has varied from head of engineering up to the CIO. --Sammy. -Original Message- From: Hollis via Rubicon Recluse [mailto:[EMAIL PROTECTED] Sent: Monday, August 20, 2007 2:09 PM To: Johan Peeters Cc: Sammy Migues; sc-l@securecoding.org Subject: Re: [SC-L] Software Security Training for Developers Hi Sammie and Yo, Tkx for the good highlevel insights. A few questions, I'm interested specifically for developer/designers, but I'm sure others are interested in other audiences: - What languages/OS/environments are you developing in? - Does your training address your language/OS/environment? If so, what percentage? - How long is the/each course? - did you go with inclass, self-paced, JIT or a combination. And which aspects to each? - What is your audience size? And what percentage did you train? - Over what period of time? - Was it mandatory? And to Sammy's point, at what management level was it loudly supported? Thanks for your insights, Hollis ___ 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] Software Security Training for Developers
On 8/20/07, Hollis via Rubicon Recluse [EMAIL PROTECTED] wrote: Hi Sammie and Yo, Tkx for the good highlevel insights. A few questions, I'm interested specifically for developer/designers, but I'm sure others are interested in other audiences: - What languages/OS/environments are you developing in? On the one hand, we would like to be technology-neutral, on the other, we want to teach people about real-world technologies and security issues, so we tend to cherry-pick technologies to suit the purposes of the principles we are trying to illustrate. For example, the access control module has tended to have a lot on Windows because their model is somewhat richer than the Unices'. Language-based security mechanisms discussions, on the other hand, have focused mainly on Java because of their seminal significance. - Does your training address your language/OS/environment? If so, what percentage? At the last presentation, 25-30%% of the time was spent on the infrastructure at the disposal of the developer, including language-based, OS, middleware and cryptography. - How long is the/each course? - did you go with inclass, self-paced, JIT or a combination. And which aspects to each? The secappdev courses take one week in-class, but, as I mentioned, recordings are mostly available on-line, giving the opportunity for self-paced or JIT study. Let me also clarify that secappdev.org only offers public courses, so, as an organization, we are not in a position to taylor content to the specific needs of a particular project though a number of the people on the secappdev faculty would take on such assignments. - What is your audience size? And what percentage did you train? I am not sure that I understand your question. We have limited the number of participants to 25 in the past. At the last presentation, all these seats were taken. We are now increasing the number of places offered to 50, but offering a dual track course so that, in a sell-out scenario, the average class size will again be 25. - Over what period of time? - Was it mandatory? And to Sammy's point, at what management level was it loudly supported? Thanks for your insights, Hollis At 11:51 AM 8/19/2007, Johan Peeters wrote: From my experience with secappdev.org (http://secappdev.org), a not-for-profit organization set up to create security awareness and improve skills in the developer community, I find myself in agreement with many of the points that Sammy raises. Development is not only about coding. secappdev tends to pay relatively little attention to coding; adoption of new technologies offering novel opportunities to shoot yourself in the foot is so rapid, platforms so varied and applications so different that we have found teaching secure software engineering principles to be a better investment for both students and teachers alike. While it is certainly true that what ultimately matters is the code, conventional wisdom has it that coding only accounts for about 20% of the development effort. The rest of the time is spent in specification, design, test, deployment and project management. We feel it is counter-productive to draw sharp distinctions between these various activities, they all need to be done well to deliver a succesful project. So we spend considerable time looking at their security implications. Apart from chiming in with Sammy, I would also like to point out that our target audience are application developers and their main focus is definitely not security, nor should it be: their job is to create value by adding functionality. Rather than teaching them to become security experts, we try to teach them strategies for getting away with as little security knowledge as possible so that they can focus on their core concerns. So one of the things we do is to make sure that participants have a good grasp of the security services offered by application platforms. An example of an architectural level discussion would be the choice of platform and its impact on security as well as how to mitigate the risks. Effective security teaching imparts a mindset, the body of knowledge is incidental. So we have a strong commitment to teach small groups with plenty of opportunity for interaction and immersion. At the next presentation, we are increasing the number of workshop sessions requiring participants to actively participate in problem-solving. So far, all secappdev.org presentations have been in Belgium and that may be a little out of the way for some/most of you. However, recordings of most of the last presentation are available from the web pages with the descriptions of individual sessions - mail me if you need fuller instructions. The next presentation is planned for the week starting March 3rd 2008. This will be a dual-track event. I hope to be able to publish the program very soon. kr, Yo On 8/17/07, Sammy Migues [EMAIL PROTECTED] wrote: Hi Chris,
Re: [SC-L] Software Security Training for Developers
From my experience with secappdev.org (http://secappdev.org), a not-for-profit organization set up to create security awareness and improve skills in the developer community, I find myself in agreement with many of the points that Sammy raises. Development is not only about coding. secappdev tends to pay relatively little attention to coding; adoption of new technologies offering novel opportunities to shoot yourself in the foot is so rapid, platforms so varied and applications so different that we have found teaching secure software engineering principles to be a better investment for both students and teachers alike. While it is certainly true that what ultimately matters is the code, conventional wisdom has it that coding only accounts for about 20% of the development effort. The rest of the time is spent in specification, design, test, deployment and project management. We feel it is counter-productive to draw sharp distinctions between these various activities, they all need to be done well to deliver a succesful project. So we spend considerable time looking at their security implications. Apart from chiming in with Sammy, I would also like to point out that our target audience are application developers and their main focus is definitely not security, nor should it be: their job is to create value by adding functionality. Rather than teaching them to become security experts, we try to teach them strategies for getting away with as little security knowledge as possible so that they can focus on their core concerns. So one of the things we do is to make sure that participants have a good grasp of the security services offered by application platforms. An example of an architectural level discussion would be the choice of platform and its impact on security as well as how to mitigate the risks. Effective security teaching imparts a mindset, the body of knowledge is incidental. So we have a strong commitment to teach small groups with plenty of opportunity for interaction and immersion. At the next presentation, we are increasing the number of workshop sessions requiring participants to actively participate in problem-solving. So far, all secappdev.org presentations have been in Belgium and that may be a little out of the way for some/most of you. However, recordings of most of the last presentation are available from the web pages with the descriptions of individual sessions - mail me if you need fuller instructions. The next presentation is planned for the week starting March 3rd 2008. This will be a dual-track event. I hope to be able to publish the program very soon. kr, Yo On 8/17/07, Sammy Migues [EMAIL PROTECTED] wrote: Hi Chris, My experience is that, like most engineers, most software developers want to improve their skills and that, as a group, they hate making easily-avoidable mistakes of any sort. Training that focuses on reinforcing their existing skills in design and development and then works methodically to give them the extra layer of knowledge to make the code not only function, but also behave with respect to security, is almost always well received. Any training that comes across as, You're doing it wrong, stop everything and do it this way will almost always be ignored. No one has time for that. Internal groups and others who are getting started in developer training tend to create bug parade kinds of materials. You'll see slide after slide of five-line code snippets while the instructor says That's wrong, don't do that. That kind of mistake detection is often so easily automatable these days, that buying or building training for it, and taking all your developers out of action for a day or two to run through it, may not be the best choice. As you alluded to, we need to teach developers how to actually write secure code. The problem, however, is that the march of development methods, languages, frameworks, architectures, and so on means there usually cannot be a single approach for, by way of example, coding input validation routines. On the whole, the industry is at the stage where we need to teach developers to recognize situations where security goes here, and give them the reasoning skills and prescriptive guidance to code their way out of the problem in their particular environment. This kind of defensive programming training seems to be most valuable these days and it takes real experience and real experts to create and deliver such material. Meanwhile, it takes more than educated developers to produce software that behaves appropriately in the face of attack. The requirements people also need some help and it's unlikely the business analysts, the architects, and the testers are sufficiently considering the non-functional security aspects of the thing they are trying to bring to life. Of cause, the operations folks also need to understand their part in the secure software lifecycle. In addition, executives need to understand how
Re: [SC-L] Software Security Training for Developers
Hi Chris, We at Security Compass have been doing that for developers for about 2 years now. We have done this type of training and also the training from the pen tester angle. Some of the things that we have seem make this training much more effective are [] If the direction for the training and security initiative is coming in from the top rather than just from one manager (not to say that having it from one manager doesn't help) [] If there are some general policy and guidelines to building secure software [] If there are general guidelines to build secure architecture [] if there are though processes in place for updating the existing SDLC with security in place to improve the overall direction of the company towards a more secure application development practice [] Finally if the training is developed around these kind of practices and customized to your specific environment. We also think providing different kinds of training for different levels of people is important, i.e. a training for managers, a training for architects, a training for QA/Security professionals and finally a training for developers. Each has a specific goal in mind and speaking in the individual language so to speak to each group. Hope this helps, If you would like to chat more just email me. Nish. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M Sent: Thursday, August 16, 2007 7:23 PM To: sc-l@securecoding.org Subject: [SC-L] Software Security Training for Developers What are folks' experiences with software security training for developers? By this, I'm referring to teaching developers how to write secure code. Ex. things like how to actually code input validation routines, what evil functions and libraries to avoid, how to handle exceptions without divulging too much info, etc. Not how to hack applications. There are quality courses and training that show you how to break into apps--which are great, but my concern is that if you are a developer (vs. a security analyst, QA type, pen-tester, etc.),even when you know what could happen, unless you've been specifically taught how to implement these concepts in your language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting the most bang for the buck from them. What vendors teach it? How much does it cost? Actual impact realized? Tx Chris McCown, GSEC(Gold) Intel Corporation * (916) 377-9428 | * mailto:[EMAIL PROTECTED] [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] Software Security Training for Developers
Hi Chris, My experience is that, like most engineers, most software developers want to improve their skills and that, as a group, they hate making easily-avoidable mistakes of any sort. Training that focuses on reinforcing their existing skills in design and development and then works methodically to give them the extra layer of knowledge to make the code not only function, but also behave with respect to security, is almost always well received. Any training that comes across as, You're doing it wrong, stop everything and do it this way will almost always be ignored. No one has time for that. Internal groups and others who are getting started in developer training tend to create bug parade kinds of materials. You'll see slide after slide of five-line code snippets while the instructor says That's wrong, don't do that. That kind of mistake detection is often so easily automatable these days, that buying or building training for it, and taking all your developers out of action for a day or two to run through it, may not be the best choice. As you alluded to, we need to teach developers how to actually write secure code. The problem, however, is that the march of development methods, languages, frameworks, architectures, and so on means there usually cannot be a single approach for, by way of example, coding input validation routines. On the whole, the industry is at the stage where we need to teach developers to recognize situations where security goes here, and give them the reasoning skills and prescriptive guidance to code their way out of the problem in their particular environment. This kind of defensive programming training seems to be most valuable these days and it takes real experience and real experts to create and deliver such material. Meanwhile, it takes more than educated developers to produce software that behaves appropriately in the face of attack. The requirements people also need some help and it's unlikely the business analysts, the architects, and the testers are sufficiently considering the non-functional security aspects of the thing they are trying to bring to life. Of cause, the operations folks also need to understand their part in the secure software lifecycle. In addition, executives need to understand how to govern and managers need to understand how to facilitate. By way of full disclosure, I've spent a great deal of time building such a cross-cutting curriculum at Cigital, which we've delivered to a variety of financial services, independent software vendor, and other organizations. As for pricing, I've seen everything from a few hundred dollars per person for material you could effectively download yourself to $12,000 or more per day for a few slides and one big exercise that may have nothing to do with a group's particular needs. I've also seen a few examples of some really good stuff that just speaks to me. Organizations must make sure they're getting an instructor that thoroughly understands the material and that they've worked with the training provider to ensure the material is appropriately customized to their needs. Effectiveness is in the eye of the beholder. The actual impact of developer training alone may take months to show up in even the most mature dashboard. More broad training across each of the key roles, appropriately supported by prescriptive guidance and automation, has historically shown a recognizable impact (e.g., finding many more security-related bugs much earlier in the SDLC) much more quickly. I recently put together some (long) thoughts on an approach for training. You can see them at http://www.cigital.com/justiceleague/2007/06/25/training-material-training-and-behavior-modification-part-1-of-3-%e2%80%93-training-material/. --Sammy. Sammy Migues Director, Knowledge Management and Training 703.404.5830 - http://www.cigital.comhttp://www.cigital.com/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M Sent: Thursday, August 16, 2007 7:23 PM To: sc-l@securecoding.org Subject: [SC-L] Software Security Training for Developers What are folks' experiences with software security training for developers? By this, I'm referring to teaching developers how to write secure code. Ex. things like how to actually code input validation routines, what evil functions and libraries to avoid, how to handle exceptions without divulging too much info, etc. Not how to hack applications. There are quality courses and training that show you how to break into apps--which are great, but my concern is that if you are a developer (vs. a security analyst, QA type, pen-tester, etc.),even when you know what could happen, unless you've been specifically taught how to implement these concepts in your language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting the most bang for the buck from them. What vendors teach it? How
