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. _______________________________________________