Re: [SC-L] Information Protection Policies
Ken, in terms of a previous response to your posting in terms of getting customers to ask for secure coding practices from vendors, wouldn't it start with figuring out how they could simply cut-and-paste InfoSec policies into their own? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, March 08, 2007 11:17 AM To: SC-L@securecoding.org Subject: [SC-L] Information Protection Policies Hopefully lots of the consultants on this list have been wildly successful in getting Fortune enterprises to embrace secure coding practices. I am curious to learn of those who have also been successful in getting these same Fortune enterprises to incorporate the notion of secure coding practices into an information protection policy and whether there are any publicly available examples. * 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] What defines an InfoSec Professional?
[EMAIL PROTECTED] writes: > certifications such as CISSP whereby the exams that > prove you are a security professional talk all about > physical security and network security but really don't > address software development in any meaningful way. Perhaps what is needed is a separate certification. It would be nice to know that someone knows how to write software in a secure manner, but it's not necessary that they know all about physical security, firewall rules, etc. It could even be done at multiple levels, like Sun's Java certs, to certify knowledge of secure design principles vs. secure *implementation* principles, maybe even going onward to principles of building security into the process. Something like, say, Certified Secure Programmer, Coder, and Software Engineer, respectively. > Would be intriguing for folks here that blog to discuss ways ...in their blogs? That's not discussion, that's pontificating. It also detracts from discussion, by fracturing it. Discussion is what we're having *here*, so whether someone blogs is irrelevant. -Dave ___ 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] What defines an InfoSec Professional?
I'm gonna have to go ahead and disagree with you, there, Michael. You're looking at things far too narrowly. And here's a very simple example: Small business. Single DMZ. Hosts DB and Web App on separate platforms. Web app needs to make back-end calls to DB. There's no reason whatsoever why the DB itself needs to be directly exposed to the Internet. Thus, you implement a firewall that restricts ingress access on ports 80/443 to the web server only. This scenario would exist irregardless of the quality of the underlying code, based on principles of default deny, defense in depth, segregation of duties, etc. In other words, don't put all your eggs in the "securely coded" basket. --- On the original topic... I don't think titles or certifications or even security-related actions make a security professional. I know personnel within security departments who perform access management tasks without a solid understanding of what all is contained within infosec. They don't know the security triad (C-I-A), they don't necessarily have a sound understanding of why they're doing what they do, etc. Yet they have "security" in their titles. Similarly, I've interviewed many a CISSP who I would not consider to be an infosec professional. Just because you can memorize a few facts within the 10 infosec domains does not mean you get it. I would even go so far as to say that just because a developer reads the OWASP Top 10 and then begins performing input validation does not make them an infosec professional. It makes them a better developer. Bottom line, then, is that a true infosec professional should be defined as someone working in a dedicated security role who distinguishes themselves by their level of knowledge, wisdom, and experience that can be demonstrably applied within the infosec genre. fwiw & tgif. cheers, -ben -- Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/profile?viewProfile=&key=1539292 Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ "We must scrupulously guard the civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization." -President Franklin Delano Roosevelt On Fri, March 9, 2007 7:54 am, Michael S Hines wrote: > I respectfully disagree. > > The need for a firewall or IDS is due to the poor coding of the receptor > of > network traffic - so you have to prevent bad things from reaching the > receptor (which is the TCP/IP stack and then the host operating system - > and > then the middleware and then the application). > > The reason you have to prevent bad things from reaching the receptor (OS) > is > because of poor coding practices in the receptor (OS). > > In terms of state diagrams - you have an undefied state in the code - > which > produces unpredictable actions. Technically speaking, it's undesireable > but > predictable actions - that's how the software can be used to gain > unauthorized entry. And once someone finds the hole - the very mechanism > used for protection (networks) is used to spread the story. Kind of like > the farmer eating his seed corn. :) > > Regarding roles - there are many who do Infosec - in many different roles. > Law makers, lawyers, Boards of Directors, management, policy staff, > technical staff, network engineers, programmers, quality assurance staff, > users, ethical hackers, unethical hackers, et al. > > I'm not sure we're moving the industry forward by trying to say "I am one" > but "You are not" - are we? > > Mike Hines > - > Michael S Hines > [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. > ___ > ___ 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] What defines an InfoSec Professional?
I respectfully disagree. The need for a firewall or IDS is due to the poor coding of the receptor of network traffic - so you have to prevent bad things from reaching the receptor (which is the TCP/IP stack and then the host operating system - and then the middleware and then the application). The reason you have to prevent bad things from reaching the receptor (OS) is because of poor coding practices in the receptor (OS). In terms of state diagrams - you have an undefied state in the code - which produces unpredictable actions. Technically speaking, it's undesireable but predictable actions - that's how the software can be used to gain unauthorized entry. And once someone finds the hole - the very mechanism used for protection (networks) is used to spread the story. Kind of like the farmer eating his seed corn. :) Regarding roles - there are many who do Infosec - in many different roles. Law makers, lawyers, Boards of Directors, management, policy staff, technical staff, network engineers, programmers, quality assurance staff, users, ethical hackers, unethical hackers, et al. I'm not sure we're moving the industry forward by trying to say "I am one" but "You are not" - are we? Mike Hines - Michael S Hines [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. ___
