Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Yet another perspective. I believe that this question may be somewhat flawed as it doesn't take into consideration certain demographic challenges. Right now the model seems to be based on either being academic (sitting through a semester of some old fog with no real-world experience blabbering theory) or in the professional world and their ability to bring in consultants to perform in-house training (in a highly constrained time crunch). So, if you are an employee of a small software company, how do you learn to write secure code? Academia hasn't yet adjusted to the modern world of professionals where education needs to be a component in work/life balance and not an impediment to it and therefore this isn't really an option for the masses. Likewise, if you aren't employed by a large enterprise with a training budget that can hire all these training firms that want to do onsite classes for dozens of employees, you are left with reading lots of books on your free time, a few OWASP TV videos and google. One of the more interesting experiences that I had was that a professor at RPI uses one of the books I am the lead author for in his class. If I wanted to be a guest lecturer, this would be no problem, yet if I wanted to get credit for the course, I would actually have to sit through the entire thing which would be as interesting as watching paint dry. I have on several occasions made the offer that I will pay for all fees for a given course upfront and I want to take the final exam. If I did not score 100% you could fail me and still no university would take my offer. We got to find a balance between one-day train the world in corporate America and months upon months of mind-numbling indoctrination that universities push if we are to truly conquer the challenge of secure coding. 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] Where Does Secure Coding Belong In the Curriculum?
We are NOT craftsmen by any stretch of the imagination. If you have ever worked in a large enterprise, the ability to change roles and be fluid in one's career is rewarding yet has unintended consequences. If I went to my boss tomorrow and said that I no longer want to be an architect and instead want some experience managing a project, what training do you think I will be afforded before I actually get to project manage a large initiative? For that matter I am an architect, what training do you think I have received? Much of my daily job is art where all of about ten minutes requires craftsmanship. We need to stop being delusional and thinking that us IT folks are bound by ANY principle. If you find a single principle taught in a university setting that hasn't been waived in a corporate environment at one time or another, I sure would love to know what that is. We are artists. End of discussion... From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jim Manico [...@manico.net] Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim ___ 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. ___ 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] Where Does Secure Coding Belong In the Curriculum?
Are there any industry metrics that indicate what percentage of full-time software developers actually learned coding in a university setting? I actually learned in high-school, focused on business administration in college (easiest major on the planet) and learned/matured on the job. Likewise, I also am surrounded by many folks who have been in IT for say 30 or so years that learned coding from those infomercial type schools you see on TV late at night. So, the question of whether trade schools should teach secure coding should be asked as well. 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] Where Does Secure Coding Belong In the Curriculum?
Here is where my enterpriseyness will show. I believe the answer to the question of where secure coding belongs in the curiculum is somewhat flawed and requires addressing the curiculum holistically. If you go to art school, you are required to study the works of the masters. You don't attempt to paint a Picasso in the first semester, yet us IT folks think it is OK to write code before studying the differences between good code and bad code. If a student never learns good from bad and over time develops bad habits, then teaching security at ANY stage later in life is the wrong answer. We need to remix the way IT is taught in Universities and revisit the fundamentals of how to approach IT as a whole. My second and conflicting opinion says that Universities shouldn't be teaching secure code as they won't get it right. Students should understand the business/economic impact that lack of secure coding causes. If this is left strictly to Universities, it will most certainly feel academic (in the bad sense). A person doesn't become a real IT professional until they have a few years of real-world experience under their belts and therefore maybe this is best left to their employers as part of professional development and/or Master's programs that are IT-focused but not about the traditional computer-science/software engineering way of thinking... http://twitter.com/mcgoverntheory 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] Work in the Secure Development/Secure Code Review Area?
The market for doing freelance writing has all but disappeared. You could consider writing a book but you would probably earn more money working at MacDonalds bagging fries than writing. In terms of presentations, most conferences/events also do not pay. If you managed to however put together training courses, there is some possibility. Being involved in OWASP will help you network with others who actually have money to spend on your services. Many OWASP meetings are held in space of major corporations (e.g. http://www.owasp.org/index.php/Hartford) -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews Sent: Thursday, June 18, 2009 6:04 PM To: sc-l@securecoding.org Subject: [SC-L] Work in the Secure Development/Secure Code Review Area? What kinds of positions/work are available in this area now? Could someone make a living doing freelance research/articles/presentations in this area? I will be leaving my company at the end of August and I am actively planning my future now. If you have some good thoughts or ideas, please let me know. I have plenty of ideas, but I thought this list might have some people who would know things I might not have thought about. I plan on being more active in OWASP, but that won't pay anything, so I need to find a way to make enough to support work like that. I would also like to put anything I find into an article/paper/something because I figure the career question is of interest to a lot of people. :) -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI ___ 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. ___ 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. ___
[SC-L] OWASP Hartford: Scott Ambler - Agility and Security: Two Great Tastes Which Go Great Together
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-05.00) Eastern Time (US Canada) X-MICROSOFT-CDO-TZID:10 BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20090330T143451Z DTSTART;TZID=(GMT-05.00) Eastern Time (US Canada):20090413T16 SUMMARY:OWASP Hartford: Scott Ambler - Agility and Security: Two Great Tast es Which Go Great Together UID:04008200E00074C5B7101A82E00800C2F6766DA1C901000 01000B14FB087881D2045868040C7C5345AF0 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Secure Co ding:MAILTO:SC-L@securecoding.org ORGANIZER;CN=McGovern, James F (HTSC, IT):MAILTO:james.mcgov...@thehartfo rd.com LOCATION:The Hartford: 55 Farmington Avenue\, The Great Room DTEND;TZID=(GMT-05.00) Eastern Time (US Canada):20090413T18 DESCRIPTION:The Hartford Chapter of OWASP is pleased to announce Scott Ambl er as our first speaker of the year. This event is 100% free to attend. Se ating is limited. We will be starting promptly at 4pmâ¦\N\NAgility and Se curity: Two Great Tastes Which Go Great Together\N\NSecurity is usually an afterthought on software development projects\, regardless of the paradig m being followed\, but it doesn't have to be this way. Traditional approac hes would have you add a lot of additional bureaucracy to your process and the agile extremists will tell you to write up some stories on index card s. Good luck with those strategies. Disciplined agile teams\, particularly those working at scale\, have discovered ways to address enterprise issue s such as security in effective manners which gets the job done without un necessary bureaucracy\, albeit with more sophisticated tools than a stack of index cards. This presentation overviews the Agile Process Maturity Mod el (APMM)\, what it means to scale agile approaches to meet your real-worl d needs\, and strategies for addressing security concerns in a disciplined agile manner.\NScott W. Ambler is the Practice Leader for Agile Developme nt at IBM Corporation. He works in the IBM Methods group developing proces s materials and travels the world helping clients to understand and adopt software processes that are right for them. A prolific author\, Scott has received awards for several books\, including those focused on the Unified Process\, agile software development\, Unified Modeling Language\, and de velopment based on the CMM (Capability Maturity Model). A widely recognize d expert on Agile Process\, he is a regular speaker at international IT co nferences and a senior contributing editor for Dr. Dobbâs Journal. Scott also writes the Agile Software Development at Scale blog on IBM Developer Works.\N\NPrior to working for IBM\, Scott led the development of several software processes\, including Agile Modeling (AM)\, Agile Data (AD)\, Ent erprise Unified Process (EUP)\, and Agile Unified Process (AUP). He holds a BSC in computer science and a MS in information science from the Univers ity of Toronto. \N SEQUENCE:1 PRIORITY:5 CLASS: CREATED:20090413T133809Z LAST-MODIFIED:20090413T133809Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-735365159 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20090413T121631Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20090330T143451Z END:VEVENT END:VCALENDAR ___ 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] OWASP interviews McGraw (oh my)
Some questions that I would have asked: 1. The trend towards offshoring software development is increasing. When do you think customers will be able to have confidence in the ability of outsourcing vendors to develop secure software without it being considered a special service? 2. Do you think industry analysts and the media at large are doing a good enough job of helping raise awareness? What do you think magazines such as InformationWeek, CIO and Forbes should be doing that they aren't? 3. While you are an employee of Cigital, what other security firms do you think offer high quality consulting services in this space? 4. Many organizations no longer budget for developer tools. Do you think that static analysis will fail economically if funding for development has shifted away from developer activities? 5. What are the gaps that OWASP and other security-oriented communities aren't yet thinking about? 6. Name some examples of Fortune enterprises whom you think are thinking about software security correctly? 7. Microsoft is the industry whipping boy and if we acknowledge that customers may not want them to be more secure as core changes may break backward compatibility, is software security always doomed to mediocrity? 8. To become a competent software security professional, what do you think the ideal career path looks like? 9. What bloggers do you think can bring insight into understanding secure coding practices? 10. Any opinions on whether Sun, EMC, Oracle and CA are making adequate progress towards software security being built into their products? -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw Sent: Monday, January 26, 2009 12:59 PM To: Secure Code Mailing List Subject: [SC-L] OWASP interviews McGraw (oh my) hi sc-l, OWASP just posted an interview with me as part of their budding podcast series. It's nice to have the tables turned after doing all the Silver Bullet (and Reality Check) interviews! It's also nice to be able to answer some of the questions that OWASP types have about Cigital's approach to software security. Download the podcast here: https://www.owasp.org/index.php/Podcast_5 The OWASP interviewer is Jim Manico, and he did a great job. He was a little worried about some of the questions he asked. In fact, off the record he kept saying he was sorry and telling me that I did not have to address certain questions. Personally, I enjoyed the questions he asked immensely. Though some of his questions were loaded, I do hope that my answers may serve to clarify our position and eliminate OWASP concerns. Here are a few of the many more questions I address in the podcast: * Why do you insist on use of the term software security as opposed to application security? * What is static analysis good for and what is it no good for? * What is the exact relationship between Cigital and Fortify? * Why do you think your top 19 is any better than the OWASP top 10 or the CWE top 25? (Special note, the 19 Sins work is Mike Howard's and John Viega's...I was not involved.) * Why does Cigital have a proprietary approach to IP? * What makes the Touchpoints any better than the SDL or CLASP? * What is your relationship with Allan Paller and SANS? * Who picked the porn music theme for Silver Bullet? As an extra bonus, the theme music for this episode is a song written and recorded by my band Where's Aubrey. Anyway, enjoy the podcast, and let me know what you think about my answers! gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___ 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
Re: [SC-L] FW: How Can You Tell It Is Written Securely?
Asking about security in terms of an RFP is a big joke and reminds me of tactics I used in sixth grade when I used to figure out creative ways of answering a question by turning the question into an answer. One has to acknowledge that RFPs are not authoratative and are usually completed by sales teams who don't have adequate detail. So, instead of focusing on comprehensive documentation, you need to be agile and think more about working software. I believe that penetration tests are sadly too late in the process in order to be meaningful and only have value in scenarios where you can mandate that the presses be stopped and that they fix immediately before you give them a single penny. Avoid the contract stuff as well as you can't really put meaningful things into agreements. You have to acknowledge that if I were successful in putting say a clause into our next EMC agreement requiring all document management software to support XACML and be OWASP Top Ten free, do you think that a developer on the other end would even have a chance to read it and address going forward? Way too many degrees of separation between those who write contracts and those who implement software. Again, I think you need to measure developers and their participation in groups such as OWASP since it is observable and measurable without requiring a lot of effort. It is not a guarantee but can be a predictor... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herman Stevens Sent: Monday, December 01, 2008 1:55 PM To: Marcin Wielgoszewski Cc: SC-L@securecoding.org Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? Hello Marcin, I agree with your statement that many companies have some requirements in their SLA's with outsourced development firms. However, if these are really F-100 businesses they usually have all non-core processes out-sourced (because a Big4 company told them that would reduce costs), the relationship management with the outsourced companies is also out-sourced (probably to the same Big4). This means after a few years all knowledge has left the company and if a Request For Proposal needs to be written (e.g. for a new application supporting their core business functions) this is outsourced again to the same Big4 since the company itself does not even have the required knowledge to write its own RFPs .. I really doubt that anything that goes in that RFP (and ultimately in the contracts) will have any _real_ security value. Using penetration tests and vulnerability requirements might be part of the acceptance process, but I do not call these tests _security_ requirements. They are acceptance requirements ... The original request asked for how can someone determine if an application is written in a secure manner. My reasoning is that this is the wrong question (the application must _be_ secure and for this there is no direct link with coding practices). And even if one can proof the application is written in a secure manner, this will not be enough to be secure (e.g. about 99% of all security relevant features are nowadays in the configuration, the customer will never issue a change request for a new java library of javascript library yet in many of my penetration tests I 'break' the application because of old libs, ...). I do not think that penetration tests and vulnerability assessments are a 'proof' that an application is written securely. I've seen many applications that were written horrendously but were very secure (in the sense that they abided to all security-relevant business requirements) and I have seen many applications written using the 'best practices' in coding and developed with very mature processes that could be hacked in minutes. So, are there any studies that proof that a company that performs some tests (e.g. pen-tests) or include security requirements in the contracts ultimately is better off than a company that does not do what we consider 'best practices'? And if we don't have that proof, shouldn't we be very prudent in what we advise to our customers? Please note that my company sells security related software and performs vulnerability assessments, so I'm not saying that these are useless (:)), but maybe there are better methods than penetrate patch or enforcing very heavy processes on innocent development teams... So, this is question to this list: Are we on the right track? Is application security really improving? Do we measure the correct things and in the correct way? My point of view is that only certain vulnerabilities are less common than in the early days just because of more mature frameworks, but not due to better processes or after the fact testing. Does this mean all efforts were vain? Or did the threat landscape change? And yes, there are many vendor driven statistics floating around but they really cannot be considered unbiased ... Lots of questions, maybe not all relevant for the Secure Coding list, but Secure
Re: [SC-L] FW: How Can You Tell It Is Written Securely?
I am of the belief that the examples you provided are more requirements for your own staff. For example, shouldn't your business analysts define regular expressions and include them as functional requirements where the firm simply calls them? If you want regex's externalized into properties files, shouldn't this be more about specifying acceptance criteria for the overall design vs waiting to measure it against code. For number three, you would have to think about such a clause as it is an out if performance isn't met. If you work for a large enterprise, I would think that number 4 would be encompassed into asking them to align with consistent DB access practices where you hand them your coding standards. It is different to have coding standards and having clauses that ask others to adhere to them vs embedding coding type requirements into the contracts themselves. -Original Message- From: Jim Manico [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 4:44 PM To: McGovern, James F (HTSC, IT) Cc: SC-L@securecoding.org Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? I think adding clear security requirements at the contractual level is *fundamental and necessary* when yes? yesworking with vendors who are writing software for you. Don't we talk about software security as being just another integrated part of writing software, not as an external activity? I'm not talking about foolish general requirements like Be OWASP top 10 free that does not help anyone. I'm talking about clear, somewhat undebatable requirements like: 1) Add in CSRF protection by using a form nonce 2) Make every field maps to a unique regular expression. Ensure that this regular expression exists in a properties file so it can be configured without needing to recompile code. 3) Ensure that every piece of user-driven data is encoded via HTML Entity Encoding before it is displayed to any user. 4) Use only prepared statements and binding of variables when selecting from a database Etc. Sure, we want our vendors to be security educated (good luck finding them these days). But really, we need to get the job done. We need to hire vendors. It's likely that software development vendors are not super security educated since software security is so new. We need to communicate contractual requirements anyways and those agreements do indeed matter. Our best bet is to add in clear functional security requirements to our contractual agreements if we have any hope of them being built in in a cost effective manner. - Jim Asking about security in terms of an RFP is a big joke and reminds me of tactics I used in sixth grade when I used to figure out creative ways of answering a question by turning the question into an answer. One has to acknowledge that RFPs are not authoratative and are usually completed by sales teams who don't have adequate detail. So, instead of focusing on comprehensive documentation, you need to be agile and think more about working software. I believe that penetration tests are sadly too late in the process in order to be meaningful and only have value in scenarios where you can mandate that the presses be stopped and that they fix immediately before you give them a single penny. Avoid the contract stuff as well as you can't really put meaningful things into agreements. You have to acknowledge that if I were successful in putting say a clause into our next EMC agreement requiring all document management software to support XACML and be OWASP Top Ten free, do you think that a developer on the other end would even have a chance to read it and address going forward? Way too many degrees of separation between those who write contracts and those who implement software. Again, I think you need to measure developers and their participation in groups such as OWASP since it is observable and measurable without requiring a lot of effort. It is not a guarantee but can be a predictor... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herman Stevens Sent: Monday, December 01, 2008 1:55 PM To: Marcin Wielgoszewski Cc: SC-L@securecoding.org Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely? Hello Marcin, I agree with your statement that many companies have some requirements in their SLA's with outsourced development firms. However, if these are really F-100 businesses they usually have all non-core processes out-sourced (because a Big4 company told them that would reduce costs), the relationship management with the outsourced companies is also out-sourced (probably to the same Big4). This means after a few years all knowledge has left the company and if a Request For Proposal needs to be written (e.g. for a new application supporting their core business functions) this is outsourced again to the same Big4 since the company itself does not even have the required
Re: [SC-L] FW: How Can You Tell It Is Written Securely?
Some other thoughts that I haven't heard others mention? 1. OK, if you find that they didn't meet all the security requirements, will your business customers still want you to put it into production anyway? If the answer is yes, do you still want them to support it? How do we quantify who is responsible if a breach happens and you gave them a waiver. 2. security clauses have a side effect in contracts that others need to noodle. If you have a clause that can only be measured over a longer timespan, it tickers with revenue recognition. So, how long do you want folks to certify that things are secure. 3. I like secure coding as much as the next guy and checking for CSRF is a good thing. How about noodling requirements around logging such that if they didn't get it right upfront that you at least have something forensically useful for after the fact? 4. While we are all developers, do you think there is merit in addressing roles of vendors especially non-development? For example, is it valuable to have them have on staff a security architect with lots of credentials that is separate from the development lifecycle (distinct from being totally ivory tower or hands-off)? 5. How much more are folks willing to pay to build security in? This kinda doesn't align with going offshore to get cheapest resource. It is in their best interest to be an impediment to this goal and you need to define things in a more friendly manner. Coming out of the gate by throwing others under the bus probably will not get you what you desire (of course, it is a tactic I use way too much) 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] Language agnostic secure coding guidelines/standards?
Awhile back, I got asked the same question and realized that at some level the question is flawed. Many large enterprises have standards documents that sit on the shelf and the need to create more didn't feel right. Instead, we feel to the posture that we should inverse the problem and instead find a tool that automates the code review process (aka static analysis) where we can not only measure compliance to the standard but get the standards off the shelf. In terms of products, check out Ounce Labs, Coverity, Klocwork, etc. Most will have coverage for C, Java, .NET, etc. The challenge with some of the other languages you have is that pretty much no one in the security community has ever spent much time analyzing the weaknesses in COBOL. There is some stuff out there, but it is light when compared to Java... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Werner Sent: Wednesday, November 12, 2008 7:22 PM To: Secure Coding Subject: [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 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] (fwd) informIT: A Software Security Framework
The framework that Pravir put together is pretty good. Brian and I did have a conversation awhile back regarding donating it to OWASP for continuation. I plan on making our firm one of the public case studies once they contribute. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk Sent: Wednesday, October 15, 2008 8:32 AM To: Secure Coding Subject: [SC-L] (fwd) informIT: A Software Security Framework [Posted on behalf of Gary McGraw, who is without comms right now but wanted this to go out today. KRvW] hi sc-l, Brian Chess and I have been working hard on a software security framework that we are using in a scientific study of many of the top software security initiatives. Our plan of action is to interview the people running the top ten large-scale software security initiatives over the next few weeks and then build a maturity model with the resulting data. That's right, we're actually using real data from real software security programs. Brian and I co-authored my informIT column this month, which just so happens to be about the software security framework. Please check it out, we're interested to know what you think! http://www.informit.com/articles/article.aspx?p=1271382 gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com * 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. ___
[SC-L] OWASP: The Application Security Desk Reference
OWASP needs your help with a new important project. We're creating the OWASP Application Security Desk Reference (ASDR) to capture and organize all the foundational knowledge in application security. Like the Physicians' Desk Reference for doctors, this book is a well-organized reference work that anyone working in application security will want on their desk. The OWASP ASDR covers application security principles, threat agents, attacks, vulnerabilities, controls, technical impacts, and business impacts. A 900-page alpha draft is available for your review. We need your help to get a final version created by August 25, 2008! Here is a link to the draft: http://www.lulu.com/content/2538516 * 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. ___
[SC-L] Secure Coding in the Hartford CT Area
I am launching the Hartford CT area chapter of OWASP and figured I would ask if anyone on this list is from my side of town. Likewise, if you know of others that would like to attend our users group, have them subscribe to our mailing list: http://www.owasp.org/index.php/Hartford I am pretty well connected to the enterprisey folks but tend to not run across the local startups, small shops, the university professor crowd, game development companies, etc. * 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] OWASP Publicity
The vast majority of IT executives are unfamiliar with all of the principles of security, firewalls, coding, whatever. Are they unfamiliar because of background or they feel that their staff has a handle on it and therefore don't need to pay much atention to it. Both have different characteristics in terms of getting the word out. The important thing to understand is that such principles are below their granularity; then are *right* to not care about such principles, because they can't do anything about them. Their granularity of decision making is which products to buy, which strategies to adopt, which managers to hire and fire. Suppose they did understand the principles of secure coding; how then would they use that to decide between firewalls? Web servers? Application servers? Executives don't need to care about the details but they can care enough to embrace the notion of procuring secure software. They can care about the fact that much of their code that they outsource doesn't have any metrics attached to them and that acceptance shouldn't be on meeting functionality alone. If anything, the idea that needs to be pitched to IT executives is to pay more attention to quality than to shiny buttons features. But there's the rub, what is quality and how can an IT executive measure it? The best way for IT executives to measure things are metrics that indicate a trend. Regardless of what they decide to measure, it should trend positive. I have lots of informal metrics that I use to measure quality, but they largely amount to synthesized reputation capital, derived from reading bugtraq and the like with respect to how many vulnerabilities I see with respect to a given product, e.g. Qmail and Postifx are extremely secure, Pidgin not so much :) But as soon as we formalize anything like this kind of metric, and get executives to start buying according to it, then vendors start gaming the system. They start developing aiming at getting the highest whatever-metric score they can, rather than for actual quality. This happens because metrics that approximate quality are always cheaper to achieve than actual quality. This is a very, very hard problem, and sad to say, but pitching articles articles on principles to executives won't solve it. My notion wasn't just pitching to them as this is what has occured to date. I was also suggesting that the media take on secure coding has to go well beyond the frequent consultant and vendor types that post here. If you think for a moment about other successful marketing campaigns in IT such as CMMi, ITIL, etc, the vast majority of executives know and embrace it but can't tell you who even invented it as the community let it grow past the founding members. We haven't yet came to same realization here... Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work * 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. ___
[SC-L] OWASP Publicity
I have observed an interesting behavior in that the vast majority of IT executives still haven't heard about the principles behind secure coding. My take says that we are publishing information in all the wrong places. IT executives don't really read ACM, IEEE or other the sporadic posting from bloggers but they do read CIO, Wall Street Journal and most importantly listen to each other. What do folks on this list think about asking the magazines and newspapers to publish? I am willing to gather contact information of news reporters and others within the media if others are willing to amplify the call to action in terms of contacting them. * 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] IT industry creates secure coding advocacy group
I publicly support Gunnar's assertion that folks in large enterprises need to get together as a collective to drive secure coding practices. If you know of others, please do not hesitate to have them connect to me via LinkedIn (I am bad with managing contact information) and I will most certainly take the lead... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gunnar Peterson Sent: Tuesday, October 23, 2007 3:08 PM To: Kenneth van Wyk; Secure Mailing List Subject: Re: [SC-L] IT industry creates secure coding advocacy group Hi Ken, I thought the driving force was your book, after all they named their initiative after it. Anyhow, I'll reiterate here what I blogged: It would be very interesting to see an equivalent initiative from the customer side (who are the lucky recipients who have to pay for all the security vulns created by the above). I know as a consultant there are many large companies struggling with similar secure coding issues exacerbated by outsourcing to some degree, and a lot could be gained by a shared effort. The analyst community like the vendors has more or less Fortune 500s out in the dark, so this may be an area where a half dozen or so motivated security architects and CISOs at Fortune 500s could band together to create a group to help drive change. None of the other big players (analysts, vendors, big consulting firms) seem to be doing it. Why not bootstrap a Fortune 500 Secure Coding Initiative to drive better products, services and share best practices in the software security space? -gp On 10/23/07 1:55 PM, Kenneth Van Wyk [EMAIL PROTECTED] wrote: Saw this story via Gunnar's blog (thanks!): http://www.gcn.com/online/vol1_no1/45286-1.html Any thoughts on new group, which is calling itself SAFEcode? Anyone here involved in its formation and care to share with us what's the driving force behind it? Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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. ___ On 10/23/07 1:55 PM, Kenneth Van Wyk [EMAIL PROTECTED] wrote: Saw this story via Gunnar's blog (thanks!): http://www.gcn.com/online/vol1_no1/45286-1.html Any thoughts on new group, which is calling itself SAFEcode? Anyone here involved in its formation and care to share with us what's the driving force behind it? Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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. ___ -- Gunnar Peterson, Managing Principal, Arctec Group http://www.arctecgroup.net Blog: http://1raindrop.typepad.com ___ 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. ___ * 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. ___
[SC-L] Mainframe Security
I was thinking that there is an opportunity for us otherwise lazy enterprisey types to do our part in order to promote secure coding in an open source way. Small vendors tend to be filled with lots of folks that know C, Java and .NET but may not have anyone who knows COBOL. Minimally, they probably won't have access to a mainframe or a large code base. Being an individual who is savage about being open and participating in a community, I would like to figure out why my particular call to action is. What questions should I be asking myself regarding our mainframe, how to exploit, etc so that I can make this type of knowledge open source such that all the static analysis tools can start to incorporate? * 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 process improvement produces secure software?
One thing that I am firm in my belief is that process is not a substitute for competence. Imagine taking lots of overweight IT guys and training them to ride a horse. That doesn't mean that they will go on to become successful horse jockeys and you would be dumb to bet on them. In terms of CMMi, my thought says that buyers of consulting services and enterprise software need an independent way of quantifying what they are buying from a security perspective. While the logic used in outsourcing is flawed, buyers still prefer outsourcing firms that have higher levels of CMMI than those that don't. In the same way this listserv attempts to help folks write secure software, we need a way to help folks also procure secure software and stealing some aspects of CMMi while compromising some level of integrity will have lift in the long run. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goertzel, Karen Sent: Tuesday, August 07, 2007 9:39 AM To: sc-l@securecoding.org Subject: Re: [SC-L] Software process improvement produces secure software? I've always had a question about this as well; specifically, what is really meant by adding security to a CMM? I've always felt that the level at which the software (or system) process is defined by a CMM is too high and too abstract for the addition of security activities to be particularly meaningful. My feeling is that a CMM is best used as a means of ensuring that the more detailed life cycle process is implemented in a disciplined manner, and that the amount of benefit, in terms of improvement of whatever property one is trying to improve - quality, reliability, security, safety - of the system/software that results from the process can be measured. Where the actual security activities need to be defined and added are to the life cycle methodology. At best, adding security to a CMM can provide a very high level framework for helping someone who is shopping for a life cycle methodology know what to look for in that methodology. Is a CMM necessary for that purpose? I'm not convinced that it is. I think what is likely to be more effective is a change in outlook by the practitioners who will be using the life cycle methodology. Their outlook needs to change so that a single question is asked before any choice or decision is made: What are the security implications of the choice/decision? Of course, there's much more to it than just asking that question. And that's the reason we need to train developers, testers, etc. to (1) understand what security means, both at the software and system levels; (2) visualise and recognise the possible impact(s) each of their choices/decisions could have on the security of the system they are building (before the fact); (3) recognise the impacts each of their choices/decisions has had on the security of the system they have built (after the fact). Tools and techniques to help developers do the second and third of these are proliferating (e.g., threat modeling, attack trees, etc. for before-the-fact; analysis and testing tools for after-the-fact). But in the end, I believe the #1 factor that will contribute to the increased security of software is the developer's mentality. A security-aware...and more importantly, a security-*concerned...developer is more likely to (1) avoid making bad choices and decisions, and (2) to take an interest in, and pursue becoming, knowledgeable enough to correct bad choices that he/she did not avoid making earlier. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.902.6981 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] on behalf of Francisco Nunes Sent: Tue 07-Aug-07 07:01 To: sc-l@securecoding.org Subject: [SC-L] Software process improvement produces secure software? Dear list members. In june 2007, I had an interesting conversation with Mr. Will Hayes from SEI during the Brazilian Symposium on Software Quality. It was a great experience and I am very grateful for this. During our conversation, I made a question to Mr. Hayes similar to this: Is it possible that only software development process improvements can produce secure software? The scenario was only based on CMMI without security interference. His answer to this question was YES. My answer was I DO NOT THINK SO. His answer made me confuse and I had no arguments, mainly, because my professional experience in software process does not compare to Mr. Haye's experience. Unfortunately, I also haven't found any statistics which could answer this question. Please, if there is one, let me know! So, how about you, list members? What are your answers to the question above? I will try to organize your answers and present the final result. Thank you. Yours faithfully, Francisco José Barreto Nunes. Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/
Re: [SC-L] Security Testing track: Software Testing Conference:Washington DC
Upon reading this, I had several thoughts come to mind: 1. If we are to truly solve the last mile, we need to also choose more mainstream conferences such as STPCon (http://www.stpcon.com) since they also have an associated magazine (Software Test and Performance) which may stimulate more magazine articles on the topic. I did a quick run upstairs to our QA folks and asked them what magazines do they read as well as awareness of certain conferences. 2. What do you think we can do as a unified group of individuals in terms of a listserv to encourage various industry analyst firms such as Gartner, Forrester and The Burton Group to talk about Secure Software Testing as a research area? Many CIOs and other IT executives put lots of value into what they say. We need more top down. 3. What would it take to get more speaker diversity? We have to figure out how to get more end-customers telling their own stories vs vendors and consulting firms -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paco Hope Sent: Thursday, August 16, 2007 1:41 PM To: Secure Coding Subject: [SC-L] Security Testing track: Software Testing Conference:Washington DC Hey folks, One of my strong beliefs is that we're never going to close the loop on Building Security In until we get the QA side of the house involved in security. To that end, I'm co-chairing VERIFY 2007, a software testing conference where we have a security testing track. (In addition to more typical QA issues like test automation) I thought some folks on this list may be interested in attending, or passing it on to your colleagues in QA organizations. Conference web site is http://verifyconference.com/ and you can get a 2-page Conference in a Nutshell PDF here: http://verifyconference.com/images/verify/verify2007.pdf Please help me spread the word. Thanks, Paco -- Paco Hope, CISSP Co-Chair, VERIFY 2007 http://verifyconference.com/ * +1.703.606.1905 * 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
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] how far we still need to go
Many folks have talked about certification of individuals but is there merit in noodling the notion of a security maturity model? What if end-customers could rank their software vendors in a transparent manner in the same way that outsourcing firms pursue CMMi? The notion of third-party assessors that determine this form of certification could be supplemental revenue for those who are employed by consulting firms. Could be similar to SCRUMAlliance certification if you prefer something lighter weight. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ljknews Sent: Wednesday, July 25, 2007 10:23 PM To: SC-L@securecoding.org Subject: Re: [SC-L] how far we still need to go At 2:03 AM +0100 7/26/07, Dinis Cruz wrote: It's a simple economics problem. The moment these companies and developers lose sales (or market share) because their products require admin / root privileges to run, is the moment they start to REALLY support it. For Windows that day might be when they have to run under the new US federal government standard Windows configuration, due out any month now. -- Larry Kilgallen * 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] Resources to fix vulns
I wish formulas were the solution to your question. The problem is that the answer is heavily dependent upon the background of the C-level executive. Some C-Level executives have an analytical background where their backgrounds could have been actuarial, IT, statistics, etc where they would understand intuitively that not all vulnerabilities are equal and that the solution would feel more like describing a design pattern. If your C-Level executive is a process weenie then you have to then get into prioritization and the psychology of dealing with low-hanging fruit vs severity vs occurences and so on. If you C-Level executive is perception-oriented and frequently uses the phrase perception is reality then your answer is simply to grab industry quotes from Gartner or similar entity... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M Sent: Wednesday, July 18, 2007 11:54 AM To: sc-l@securecoding.org Subject: [SC-L] Resources to fix vulns What do you tell a C-level exec in terms of h/c and time it will take to fix web app vulnerabilities discovered in a website? X number of vulnerabilities = Y h/c and Z time. Of course there's a host of factors/variables involved that could wind up looking like actuarial tables or DNA sequences (!), but what we'd like to be able to do is sum it up as an initial swag and let the app owners use it as a factor in calculating the actual time to remediate. Anyone done this or like to take a swipe? 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] Resources to fix vulns
I would actually recommend AGAINST using prior track records for fixing previous vulnerabilities because in all honestly they probably don't track it. Most enterprises prioritize any type of defect based on the importance as declared by business users whom traditionally would prioritize a spelling error on a web page of higher importance than a buffer overflow. Security stuff may get addressed while the developer has the patient open and therefore there is no real transparency in terms of the numbers. Likewise, if you wanted to think of security as a system quality and wanted to compare it to things like performance and scalability, those things haven't been always solved by changing code where the behavior was more like throwing lots of hardware at it. Security has done some of this as well but this will not uncover what you seek. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ljknews Sent: Wednesday, July 18, 2007 3:42 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Resources to fix vulns At 8:53 AM -0700 7/18/07, McCown, Christian M wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C7C953.D03CBE5C What do you tell a C-level exec in terms of h/c and time it will take to fix web app vulnerabilities discovered in a website? X number of vulnerabilities = Y h/c and Z time. Of course there's a host of factors/variables involved that could wind up looking like actuarial tables or DNA sequences (!), but what we'd like to be able to do is sum it up as an initial swag and let the app owners use it as a factor in calculating the actual time to remediate. Look at the track record for _that_organization_ fixing previous vulnerabilities. -- Larry Kilgallen * 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. ___
[SC-L] Instead of the next frontier, how about another frontier
I was thinking, Instead of the next frontier, how about another frontier? Many software vendors pretend that the entire world is either Java or .NET without acknowledging that all of the really good data in many enterprises is sitting on a big ugly mainframe running COBOL, IMS, PL/1, etc. It is assumed at this level that most folks in this space have zero knowledge of these platforms and hence the reason their tools don't support. It is my current thought that us folks in enterprises could do several things. First, we have the environment that others may not have access to. Second, we have employees that can help write specifications for detecting some aspects (they are not secure coding oriented but do understand things like buffer overflows) in PL1, COBOL, Assembler, etc. If the later is of value, we would of course like to figure out how to make this happen with one effort where every vendor could potentially consume and not do it for a single vendor. * 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] The Next Frontier
Would Fortify consider making their schema open source and donating it to OWASP? Likewise, would Ouncelabs, coverity and others be willing to adapt their product to it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paco Hope Sent: Wednesday, June 27, 2007 4:38 PM To: Secure Coding Subject: Re: [SC-L] The Next Frontier On 6/26/07 5:00 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Would there be value in terms of defining an XML schema that all tools could emit audit information to? You might want to take a look at what the Fortify guys already do. Their FVDL (Fortify Vulnerability Description Language) is XML written to a specific schema. Here's a snippet: ?xml version=1.0 encoding=UTF-8? FVDL xmlns=xmlns://www.fortifysoftware.com/schema/fvdl xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.5 xsi:type=FVDL CreatedTS xmlns=xmlns://www.fortifysoftware.com/schema/fvdl date=2007-06-27 time=16:27:37/ Build xmlns=xmlns://www.fortifysoftware.com/schema/fvdl BuildIDcurl-7.11.1/BuildID NumberFiles42/NumberFiles LOC23572/LOC SourceBasePath/Users/paco/Documents/Fortify/curl-7.11.1/lib/SourceBas ePath SourceFiles File size=20098 timestamp=1079527605000connect.c/File File size=11584 timestamp=1077710136000krb4.c/File [..snip..] Vulnerability xmlns=xmlns://www.fortifysoftware.com/schema/fvdl ClassInfo ClassID28424EC3-FFAC-40C0-94D9-3D8283B2F57C/ClassID KingdomInput Validation and Representation/Kingdom TypeBuffer Overflow/Type AnalyzerNamedataflow/AnalyzerName DefaultSeverity4.0/DefaultSeverity /ClassInfo InstanceInfo InstanceID005542ED81D54F3C72BF3669EA8D130A/InstanceID InstanceSeverity4.0/InstanceSeverity Confidence3.4/Confidence /InstanceInfo [..snip..] Some of their XML seems quite reusable to me, and some of it seems pretty proprietary. It doesn't seem like they share a DTD or a schema publicly. Perhaps a little coaxing would get them to release it. Paco -- Paco Hope, CISSP Technical Manager, Cigital, Inc http://www.cigital.com/ * +1.703.585.7868 Software Confidence. Achieved. ___ 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. ___ * 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. ___
[SC-L] Comparing Software Vendors
Jerry Leichter commented on flaws in scanning tools but I have a different question. Lots of folks love to attack MS while letting other vendors off the hook.Is there merit in terms of comparing vendor offerings within a particular product line. For example is EMC's Documentum product more secure than say an open source ECM vendor such as Alfresco? The industry analysts tend not to actually touch tools and rely on others. There is some value in terms of quantifying which products are more secure than others, so shouldn't we as a community help them figure this out? * 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's the next tech problem to be solved in softwaresecurity?
The next problem to be solved is moving higher up the food chain by teaching architects secure architecture principles. Would love to see Gary McGraw tackle this subject in his next book... From: [EMAIL PROTECTED] on behalf of Kenneth Van Wyk Sent: Sun 6/10/2007 9:37 AM To: Secure Coding Subject: Re: [SC-L] What's the next tech problem to be solved in softwaresecurity? First off, many thanks to all who've contributed to this thread. The responses and range of opinions I find fascinating, and I hope that others have found value in it as well. Great stuff, keep it coming. That said, I see us going towards that favorite of rat-holes here, namely the my programming language is better than yours, nyeah! path. Let's please avoid that. I'm confident that we've seen it enough times to know that it ends with no clear winners (but plenty of losers). Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com * 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. ___
[SC-L] Perspectives on Code Scanning
I really hope that this email doesn't generate a ton of offline emails and hope that folks will talk publicly. It has been my latest thinking that the value of tools in this space are not really targeted at developers but should be targeted at executives who care about overall quality and security folks who care about risk. While developers are the ones to remediate, the accountability for secure coding resides elsewhere. It would seem to be that tools that developers plug into their IDE should be free since the value proposition should reside elsewhere. Many of these tools provide audit functionality and allow enterprises to gain a view into their portfolio that they previously had zero clue about and this is where the value should reside. If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get vendors to ignore developer specific licensing and instead focus on enterprise concerns? * 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] Tools: Evaluation Criteria
I think my thinking was a little different. I would also expect criteria that shows how it integrates into the entire lifecycle. For example, scanning source code that is already extracted is a little different than scanning a PVCS repository. Likewise, taking a list of vulnerabilities and understanding who created them, connecting to the identity stored in version control and then having the ability to feed tools such as JIRA, PVCS Tracker, etc would be powerful. Good to see that folks are expanding the criteria in terms of what it scans for, but criteria as to how it integrates is also equally useful. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steven M. Christey Sent: Tuesday, May 22, 2007 12:53 PM To: McGovern, James F (HTSC, IT) Cc: SC-L@securecoding.org Subject: Re: [SC-L] Tools: Evaluation Criteria On Tue, 22 May 2007, McGovern, James F (HTSC, IT) wrote: We will shortly be starting an evaluation of tools to assist in the secure coding practices initiative and have been wildly successful in finding lots of consultants who can assist us in evaluating but absolutely zero in terms of finding RFI/RFPs of others who have travelled this path before us. Would especially love to understand stretch goals that we should be looking for beyond simple stuff like finding buffer overflows in C, OWASP checklists, etc. semi-spam: With over 600 nodes in draft 6, the Common Weakness Enumeration (CWE) at http://cwe.mitre.org is the most comprehensive list of vulnerability issues out there, and it's not just implementation bugs. That might help you find other areas you want to test. In addition, many code analysis tool vendors are participating in CWE. In my travels, it feels as if folks are simply choosing tools in this space because they are the market leader, incumbent vendor or simply asking an industry analyst but none seem to have any deep criteria. I guess at some level, choosing any tool will move the needle, but investments really should be longer term. Preliminary CWE analyses have shown a lot less overlap across the tools than expected, so even baased on vulnerabilities tested, this is an important consideration. You might also want to check out the SAMATE project (samate.nist.gov), which is working towards evaluation and understanding of tools, although it's a multi-year program. Finally, Network Computing did a tool comparison: http://www.networkcomputing.com/article/printFullArticle.jhtml?articleID=198900460 - 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. ___ * 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. ___
[SC-L] Tools: Evaluation Criteria
We will shortly be starting an evaluation of tools to assist in the secure coding practices initiative and have been wildly successful in finding lots of consultants who can assist us in evaluating but absolutely zero in terms of finding RFI/RFPs of others who have travelled this path before us. Would especially love to understand stretch goals that we should be looking for beyond simple stuff like finding buffer overflows in C, OWASP checklists, etc. In my travels, it feels as if folks are simply choosing tools in this space because they are the market leader, incumbent vendor or simply asking an industry analyst but none seem to have any deep criteria. I guess at some level, choosing any tool will move the needle, but investments really should be longer term. * 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] Darkreading: Secure Coding Certification
I agree. The two that I feel should be next in terms of developing certifications around are: - How to describe misuse case and dangerous ommissions for people writing functional specifications: This is highly applicable in outsourcing environments including the Federal Government - Strong Software Design Patterns for Software Architects/Lead Developers: This is where if security were properly addressed, would be pretty cheap to handle and have a better ROI than dealing with it at coding time. http://www.theimf.com/events_detail.aspx?ID=164 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arian J. Evans Sent: Wednesday, May 16, 2007 4:05 PM To: SC-L@securecoding.org Subject: Re: [SC-L] Darkreading: Secure Coding Certification I don't understand this thread. These are different sets of issues. Often, they are different sets of people. Organizational size is a factor. A three-man startup is going to have a lot of hat overlap, where a monolithic enterprise is going to have broad distribution of hats. The spirit of this thread seems to have a well-meaning but misguided swaping of ANDs and ORs. The arm-chair quarterbacking of a very useful, overdue effort, is a bit silly. We need these efforts. As I mentioned previously, we need multiple tests: + How to write and implement code that isn't weak to bit-fiddling (e.g. don't concatenate strings, strongly type data, encode output safe for user agent, don't use LIKE queries with weak authorization models, blah blah; this is how you make XSS and SQLi and BoF/HoFs go away.) -- Check. That's the first thing thing SANS (err, SSI) is addressing. We still need: + Non-dangerous requirements-gathering for Product Evangelists/Owners (no, the customer does not really want that) + Strong Software Design Principles for Business Owners (weak secrets often reduce short-term costs, customer service, etc., but...) + Strong Software Design Patterns for Software Architects/Lead Developers (yeah, your authorization model is Borked man. What were you drinking? In fact, why do you even have roles in your application? Might as well just use Trust.) + How to describe mis-use case and dangerous omissions for people writing functional specifications (So Rob should run Rob's reports. Should Rob be able to run Sally's report(s)?? yes|no ) These are all different actions... often taken by different actors. At minimum it is while a given actor is performing different tasks. I'd love to see SSI collect a body of knowledge and make tests for all of these. I see no reason to debate ORs in here. chow Arian Evans * 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] Darkreading: Secure Coding Certification
As someone who has read your books, I am in full agreement that we should use much of the material contained to create an exam around design. Instead of making it a later thing, what would it take for folks on this list to have some sense of urgency and blast SANS to do it sooner? If any members here will also be in attendance at the TechForum in NYC (http://www.techforum.com/sf2007_1/index.html) would love to hook up for lunch. -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 4:26 PM To: McGovern, James F (HTSC, IT); 'SC-L@securecoding.org' Subject: RE: [SC-L] Darkreading: Secure Coding Certification Hi all, I like this idea. There is plenty of non-code material to master in our field. I think a bunch of it is covered in detail in Software Security...but I am biased. I would like to see coverage of common attack patterns, coverage of risk analysis basics, and coverage of both positive and negative design patterns. gem P.S. I plan to respond soon to previous posts. Too much time on airplanes lately. company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com Sent from my treo. -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 03:08 PM Eastern Standard Time To: SC-L@securecoding.org Subject:[SC-L] Darkreading: Secure Coding Certification Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level? If we follow the trend of IT at large, we would understand that lots of coding is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first. * 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. ___ ___ 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] How big is the market?
I just conducted a super-official study of what my peers are reading by walking a total of five aisles within a very large building. Here are a list of magazines on folks desk: - Infoworld - Java Developers Journal - Insurance Technology - DMReview - Intelligent Enterprise - CIO - Insurance Networking News Likewise, I asked several folks as to whether they subscribe to Dr. Dobbs and the answer was zero. Interestingly enough, I also checked with other folks and there seems to be more memberships in our architecture group with the ACM over IEEE. -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 11:24 AM To: McGovern, James F (HTSC, IT) Cc: SC-L@securecoding.org Subject: RE: [SC-L] How big is the market? Got it. I like dr. dobbs OK. Do you see that one around? It has software security content every once in a while. What others do you think would be a good target? What do the rest of you guys think? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 11:17 AM To: Gary McGraw Cc: SC-L@securecoding.org Subject: RE: [SC-L] How big is the market? Gary, I do at some level agree in terms of quality of publication. My perspective though is from an large enterprise perspective whose primary business model isn't about technology and the magazines that folks do read especially in the development community. A quick informal survey tells me that absolutely zero of my peers read IEEE (note I am a subscriber). Part of the problem may be the fact that us enterprise folks are bombarded with free magazines and cannot justify spending money to subscribe to ones such as the IEEE. I am merely suggesting some diversification for folks that don't pay for magazines. -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 10:50 AM To: McGovern, James F (HTSC, IT) Cc: SC-L@securecoding.org Subject: RE: [SC-L] How big is the market? I'm sorry James, but I have to respectfully disagree about the vendor thing. Perhaps the tools vendors target the information protection people, but at Cigital we sell services to software execs (in huge companies) who are way up the food chain. Software security is small, and we need to emphasize the growth and get people interested. This goes for everyone who reads this list. To continue our impressive growth as a field, we need to continue to build. I do agree with you that people need to write more for developers (but I hope they pick better places than JDJ to publish in). Toward that end, check out the Building Security In department in IEEE Security Privacy magazine http://www.computer.org/portal/site/security/. Also check out Brian Chess's new book Secure Programming with Static Analysis when it comes out in June. However, for the most part, it's critical to understand that workaday developers can't wrangle enough budget to tackle software security. BTW, I posted a reprise to the darkreading column on justice league today: http://www.cigital.com/justiceleague/ http://www.darkreading.com/document.asp?doc_id=122253WT.svl=column1_1 All told, I am very optimistic about our field, but don't think we can rest on our laurels at all yet. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com * 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. ___
[SC-L] NYC Security
FYI. Awhile back I mentioned the Technology Managers Forum in which I am a participant. The agenda is finalized and secure coding practices was the number one topic: http://www.techforum.com/sf2007_1/index.html For product vendors and consulting firms that want access to key decision makers, this would be a great opportunity to get a booth. Anyway, hope to run across folks from this list here. Nothing is better than face-to-face conversations... * 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] Silver Bullet: Ross Anderson
Would it be possible for upcoming episodes to have an individual who is directly employed by a Fortune enterprise whose primary business model isn't technology? Way too many software vendors, consultants and folks from academia. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gary McGraw Sent: Friday, April 13, 2007 5:33 PM To: Mailing List, Secure Coding Cc: Clark-Fisher, Kathy; Anderson,Ross Subject: [SC-L] Silver Bullet: Ross Anderson Hi all, A faithful reader of sc-l (and a long time silver bullet listener) suggested that I interview Ross Anderson for an episode. By popular demand, here's Ross: http://www.cigital.com/silverbullet/show-013/ This episode will appear in an upcoming issue of IEEE Security Privacy magazine. SP co-sponsors Silver Bullet along with Cigital. As usual, there is some talk about software security in this episode. Your feedback is welcome! gem company www.cigital.com blog www.cigital.com/justiceleague book www.swsec.com Sent from my treo. * 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] How big is the market?
One thing that I can say is that vendors sometimes are doing themselves a disservice in terms of getting software security to grow even faster. Currently anything that has the word security in it automatically gets redirected to information protection types in large enterprises who usually are degrees away from those who actually write source code. A method should be to reach out to the development community via publications such as Java Developers Journal and similar forums. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gary McGraw Sent: Friday, April 20, 2007 4:17 PM To: SC-L@securecoding.org Subject: [SC-L] How big is the market? Hi sc-lers, At s3con this week I gave a keynote about the state of the practice in software security. Some of what I said is captured in my darkreading column this month: http://www.darkreading.com/document.asp?doc_id=122253WT.svl=column1_1 There are a couple of things worth noting. First of all, the article has some numbers in it that show how the market is growing. I believe we attained a $200-275 million level in 2006. Things look like they are continuing to grow as well. Second, this article discusses a few ways for a corporation to get started with software security, from the kinds of full blown initiatives that we recommend at Cigital to easier baby steps with badness-ometers like SPI Dynamics and Watchfire. Please do what you can to spread the word about this article so that people outside of our specialty get a feeling for what is happening. Software security is growing, and the growth is strong and consistent. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___ * 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. ___
[SC-L] Foundations of Security: What Every Programmer Needs to Know
http://www.bookpool.com/sm/1590597842 Any thoughts positive and negative on this book? * 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] Darkreading: compliance
Gary, may I suggest an alternative response to application firewalls and the notion that it is hair-brained? Of course this is true but this list is missing a major opportunity to finally calculate an ROI model. If you ask yourself, what types of firewalls are pervasively deployed, you would find that application-firewalls aren't. This would then mean that folks would either need to replace their existing firewall (very risky that no one would ever consider), add multiple firewalls which introduce operational complexity, etc. You are probably aware that Cisco Pix, Checkpoint, etc aren't app-level which says that incumbent vendors aren't the solution. Likewise, you are probably aware that for other than common protocols, you probably will have to pay big bucks to vendors to develop custom plugins to their closed source offerings and the procurement cycle times around this are lengthy at best. For many shops, having another type of firewall could cost millions whereas putting tools in the hands of developers may actually be cheaper. We as a community may be better served by encouraging application firewalls and letting the financial model for complying work in our favor... -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 10:01 AM To: McGovern, James F (HTSC, IT); SC-L@securecoding.org Subject: RE: [SC-L] Darkreading: compliance Hi all, Another big momentum machine for software security (and data security) is PCI compliance. There is a challenge, though, and that is figuring out where the credit card data that you want to protect are. We've found in our practice at cigital that the data are literally scattered all over the enterprise. Because of this, hair-brained solutions like application firewalls (something called out in the PCI standards) often don't help. I think PCI compliance is doing for data security and data risk what SOX did for software security and sofware risk. They both help with problem awareness. To answer your question directly, we see lots of large enterprises working hard on PCI these days. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. * 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. ___
[SC-L] FW: Need Sec Forum speakers-let us know by Wed. if interested
Awhile back, I mentioned the Technology forum in NYC and they are seeking speakers. Of course there are some constraints to whom may sign up. A sponsor may serve on a panel but otherwise, the speakers need to be from end-customer enterprises and not from software vendors or consulting firms. If you know of folks that can speak on their successes, they should definetely be encouraged to participate. NOTE: There is strong demand for Secure Coding Practices... -Original Message- From: Victoria Adams-TechForum [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 5:10 PM To: McGovern, James F (HTSC, IT) Subject: Need Sec Forum speakers-let us know by Wed. if interested TechForum members: Need speakers for panels-please let us know by Wednesday afternoon Dear Members of Technology Managers Forum : Based on your votes, we've narrowed down the topics for the May 17th http://www.techforum.com/sf2007_1/index.html Security Forum and are now looking for TF member speakers for the panels, or your recommendations for a colleague at your company. Please take a look at the topics below and let us know which ones, if any, you would be willing and able to speak on. We would like to hear back from you by Wednesday afternoon if possible. Also, let us know if you have anyone to recommend from your firm. Here are the top ranked topics (we will distill the topics into 4 panels eventually). Please let us know which topics you would be able to speak on--your first and second choice. If you have been on a panel very recently, we definitely still want you to volunteer, but we may ask you to be backup for a panel since we also like to give new members a chance to participate. (One note: Human Engineering: Is Information Security a Social Problem? was the top-ranked topic, but we thought we'd address this question within the context of every panel). 1: Secure Coding Practices Strategic Applications: Which Comes First? 2:Enterprise Security and Individual Privacy: When Two Worlds Collide 3: The Forensic Edge: Will Security Event Monitoring Pay for Itself? 4: Risk Management: Is Information Security the Whole Sandwich? 5:Encryption: For some of the data, all of the time 6: Friendly Fire: Protecting the Network from its Own Endpoints 7: Secure Voice Video: Miles to Go Before We Sleep 8: Security Is as Security Does: Dealing with the Insider Threat * 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] Economics of Software Vulnerabilities
Kevin, I would love to see open source communities embrace secure coding practices with stronger assistance from software vendors in this space. This of course requires going beyond audit capability and figuring out ways to get the tools into developers hands. As a contributor to open source projects, I struggle with introducing security as I already contribute my time with the support/blessing of my significant other but she wouldn't let me spend hard cash on tools for contributing to open source. I wish there was a better answer for us all in this seat. Generally speaking, many of my peers outside of work contribute to open source with the rationale that it a safer place from a political perspective to try things out, kinda like a POC where the outcome doesn't have to be successful and it won't show up on your annual review. Lately, I haven't figured out how to reduce my own exposure... -Original Message- From: Wall, Kevin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 9:16 PM To: McGovern, James F (HTSC, IT) Cc: sc-l@securecoding.org Subject: RE: [SC-L] Economics of Software Vulnerabilities James McGovern apparently wrote... The uprising from customers may already be starting. It is called open source. The real question is what is the duty of others on this forum to make sure that newly created software doesn't suffer from the same problems as the commercial closed source stuff... While I agree that the FOSS movement is an uprising, it: 1) it's being pushed by customers so much as IT developers 2) the uprising isn't so much as being an outcry against security as it is against not being able to have the desired features implemented in a manner desired. At least that's how I see it. With rare exceptions, in general, I do not find that the open source community is that much more security consciousness than those producing closed source. Certainly this seems true if measured in terms of vulnerabilities and we measure across the board (e.g., take a random sampling from SourceForge) and not just our favorite security-related applications. Where I _do_ see a remarkable difference is that the open source community seems to be in general much faster in getting security patches out once they are informed of a vulnerability. I suspect that this has to do as much with the lack of bureaucracy in open source projects as it does the fear of loss of reputation to their open source colleagues. However, this is just my gut feeling, so your gut feeling my differ. (But my 'gut' is probably bigger than yours, so feeling prevails. ;-) Does anyone have any hard evidence to back up this intuition. I thought that Ross Anderson had done some research along those lines. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. * 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] How is secure coding sold within enterprises?
Thanks for the response. I already own the book and understand how to engage vendors. Where I am seeking assistance is all the work that goes on within a large enterprise before these two things occur. The ideal situation for me would be to get my hands on the five to ten page Powerpoint slide deck that others who have blazed this path before me have used to sell the notion to their executives. -Original Message- From: Andrew van der Stock [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 5:06 PM To: McGovern, James F (HTSC, IT) Cc: SC-L Subject: Re: [SC-L] How is secure coding sold within enterprises? In terms of creating a SDLC, pop out to Borders and get Howard and Lipner's The Security Development Lifecycle ISBN 9780735622142 http://www.microsoft.com/mspress/books/8753.aspx It is simply the best text I've read in a long time. You may be interested in the work Mark Curphey et al is doing at his new start up. They launched an ISM portal a couple of weeks back. http://www.ism-community.org/ If you're just after ideas on how to engage vendors, check out Curphey's blog for some nice insider posts: http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application-pen-testers/ http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-reviewers/ http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-security-folks/ He ran Foundstone's services for a while, and built up a pretty good consultancy. The sort of metrics you're after are notoriously hard to find out in the wild. There's some folks capturing screenshots of enterprise dashboards. This may or may not help at all. http://dashboardspy.com/ Thanks, Andrew On 3/19/07 4:12 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I agree with your assessment of how things are sold at a high-level but still struggling in that it takes more than just graphicalizing of your points to sell, hence I am still attempting to figure out a way to get my hands on some PPT that are used internal to enterprises prior to consulting engagements and I think a better answer will emerge. PPT may provide a sense of budget, timelines, roles and responsibilities, who needed to buy-in, industry metrics, quotes from noted industry analysts, etc that will help shortcut my own work so I can start moving towards the more important stuff. -Original Message- From: Andrew van der Stock [ mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 2:50 PM To: McGovern, James F (HTSC, IT) Cc: SC-L Subject: Re: [SC-L] How is secure coding sold within enterprises? There are two major methods: 1. Opportunity cost / competitive advantage (the Microsoft model) 2. Recovery cost reductions (the model used by most financial institutions) Generally, opportunity cost is where an organization can further its goals by a secure business foundation. This requires the CIO/CSO to be able to sell the business on this model, which is hard when it is clear that many businesses have been founded on insecure foundations and do quite well nonetheless. Companies that choose to be secure have a competitive advantage, an advantage that will increase over time and will win conquest customers. For example (and this is my humble opinion), Oracle's security is a long standing unbreakable joke, and in the meantime MS ploughed billions into fixing their tattered reputation by making it a competitive advantage, and thus making their market dominance nearly complete. Oracle is now paying for their CSO's mistake in not understanding this model earlier. Forward looking financial institutions are now using this model, such as my old bank's (with its SMS transaction authentication feature) winning many new customers by not only promoting themselves as secure, but doing the right thing and investing in essentially eliminating Internet Banking fraud. It saves them money, and it works well for customers. This is the best model, but the hardest to sell. The second model is used by most financial institutions. They are mature risk managers and understand that a certain level of risk must be taken in return for doing business. By choosing to invest some of the potential or known losses in reducing the potential for massive losses, they can reduce the overall risk present in the corporate risk register, which plays well to shareholders. For example, if you invest $1m in securing a cheque clearance process worth (say) $10b annually to the business, and that reduces check fraud by $5m per year and eliminates $2m of unnecessary overhead every year, security is an easy sell with obvious targets to improve profitability. A well managed operational risk group will easily identify the riskiest aspects of a mature company's activities, and it's easy to justify improvements in those areas. The FUD model (used by many vendors - do this or the SOX
[SC-L] Question on User Groups
Quick question for folks here. I participate in multiple user-groups and the topic of secure coding practices has never appeared. What would it take for a software vendor on this list to present to the CT OO Users Group ( www.cooug.org). These events are well attended. Likewise, I am also a member of the advisory board for the Technology Managers Forum in NYC ( www.techforum.com) where we are working on an upcoming agenda. I would like to see secure coding practices become a panel topic here as well. Likewise, for folks who want to establish booths, sponsorship opportunities are also available. Between these two events, you could have the opportunity to work with lots of Fortune enterprises in the Northeast. Besides, we are more interesting than the usual government stuff :-) * 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. ___
[SC-L] How is secure coding sold within enterprises?
I am attempting to figure out how other Fortune enterprises have went about selling the need for secure coding practices and can't seem to find the answer I seek. Essentially, I have discovered that one of a few scenarios exist (a) the leadership chain was highly technical and intuitively understood the need (b) the primary business model of the enterprise is either banking, investments, etc where the risk is perceived higher if it is not performed (c) it was strongly encouraged by a member of a very large consulting firm (e.g. McKinsey, Accenture, etc). I would like to understand what does the Powerpoint deck that employees of Fortune enterprises use to sell the concept PRIOR to bringing in consultants and vendors to help them fulfill the need. Has anyone ran across any PPT that best outlines this for demographics where the need is real but considered less important than other intiatives? * 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] 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. ___
[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. ___
[SC-L] What defines an InfoSec Professional?
If you have two individuals, one of which has been practicing secure coding practices and encouraging others to do so for years while another individual was involved with firewalls, intrusion detection, information security policies and so on, are they both information security professionals or just the later? * 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?
Traditionally InfoSec folks defined themselves as being knowledgable in firewalls, policies, etc. Lately, many enterprises are starting to recognize the importance of security within the software development lifecycle where even some have acknowledged that software is a common problem space for those things traditionally thought of as infrastructure. The harder part is not in terms of recognizing the trend but in terms of folks from the old world acknowledging folks from the new world (software development) also as security professionals. I haven't seen many folks make this transition. I do suspect that some of it is tied to the romance of 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. Would be intriguing for folks here that blog to discuss ways for folks to transition / acknowledge respect not as just software developers with a specialization in security but in being true security professionals and treat them like peers all working on one common goal. -Original Message- From: Shea, Brian A [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 2:07 PM To: Gunnar Peterson; McGovern, James F (HTSC, IT) Cc: SC-L@securecoding.org Subject: RE: [SC-L] What defines an InfoSec Professional? The right answer is both IMO. You need the thinkers, integrators, and operators to do it right. The term Security Professional at its basic level simply denotes someone who works to make things secure. You can't be secure with only application security any more than you can be secure with only firewalls or NIDs. The entire ecosystem and lifecycle must be risk managed and that is accomplished by security professionals. Each professional may have a specialty due to the breadth of topics covered by Security (let's not forget our Physical Security either), but all would be expected to act as professionals. Professionals in this definition being people who are certified and expected to operate within specified standards of quality and behavior much like CISSP, CPA, MD, etc. * 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. ___
[SC-L] Magazines
I learned through the grapevine that folks from Network Computing will be doing an upcoming article and comparison of tools in the secure coding space. If you are a vendor, it would be wise to make sure your marketing folks are participating. The funny thing is that I wouldn't expect it to appear in such a publication. Having in the past written for Java Developers Journal, I wouldn't be against pitching the writing of a similar story if vendors here would be game as well. * 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] Building Security In vs Auditing
Gary, I would love a little refinement of the benefits to badnessometers. Let's say I get a tool to tell me something I already suspect is wrong, what percentage of the population are better than they expected? The reason why I ask this question is that in our culture if I have a sense something is wrong, it usually isn't that difficult to find metrics as to why it is bad and therefore may have the perception of crying wolf as there are lots of bad things in all IT systems. Sometimes, going from good to great is a better approach than fixing bad and going to good. Is it better to do such a badness test by doing a POC with one of the tool vendors in this space or do I get additional lift by going with a consulting firm in this regard (other than an opportunity to be smoozed regarding subsequent engagements and reused powerpoints and collateral from other gigs)? What would it take to get some industry analyst coverage in this space? Lots of folks may be of the belief that it is a waste of time bothering but I would love to at least know if any of the firms here have at least made the effort. -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 1:35 PM To: McGovern, James F (HTSC, IT); sc-l@securecoding.org Subject: RE: [SC-L] Building Security In vs Auditing Hi all, Very good questions. I think a service like the one you describe would be useful mostly as a way of identifying the depth of the problem. Simply wielding a tool as a consultant does nothing to train the guys creating bugs not to do so in the future...and so the market will correct that over time in an efficient way. But the fact remains that many potential customers and users of static analysis tools have no idea how much of a mess they have. An outsourcing approach could help with that. They'll find out they need em. I believe so strongly in the do anything to get started thing that I also endorse the use of (really amazingly silly) application security testing tools. I call these badnessometers (see chapter 1 of software security...and ken's slides for that matter). But knowing that your web code sucks is better than remaining completely clueless. In the end, tool integration *into dev* is the key to success with static analysis. Many of our customers are having huge enterprise-wide success because they are learning to use, feed, tune, and train dev about these tools. The best are recycling the things they learn about their code back into training (and into better rules to enforce). gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com. * 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] Compilers
I think my perspective is not just about overlap in terms of an abstract syntax tree but more in terms of usability. Security warnings should appear inline with other types of warnings from a developers perspective. When the information is presented separately, it will be an opportunity to ignore. It is harder to ignore compiler output. Likewise, one of the lifecycle oriented things I have seen in several shops is that source code gets moved through environments and gets recompiled. So if I check in code to the integration environment, the build tool will extract and compile. Likewise, when code gets promoted to say QA environment, the code is extracted again and recompiled. This allows for build tools that emit metrics and track warnings in a centralized place to take advantage of security considerations as well. Of course, some shops when they promote code move binaries which invalidates the above. -Original Message- From: Temin, Aaron L. [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 1:38 PM To: McGovern, James F (HTSC, IT); Secure Coding Subject: RE: [SC-L] Compilers It would be worth knowing more about the basis you use for drawing the conclusion, but if it's just the overlap between compilers and static analyzers represented by the abstract syntax tree, I don't think that's enough to warrant building one into the other (it might argue for having a shared parser, but I don't think parsers are hard enough to build to make that worthwhile). I would also suggest that looking for security weaknesses fits more into the unit testing part of development rather than the compiling part. As for standalone, I think Jtest is built as an Eclipse plug-in; I don't know if you'd consider that standalone or not, but at least the developer doens't have to start up another shell to run it. Also, depending on the customer's organization, it might not be the developer who is running the security static analysis. I was talking with an organization that was thinking of having the security group run the static analysis, as part of the acceptance phase of an iteration. - Aaron _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, December 21, 2006 10:31 AM To: Secure Coding Subject: [SC-L] Compilers I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * 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. ___
[SC-L] Building Security In vs Auditing
I read a recent press release in which a security vendor (names removed to both protect the innocent along with the fact that it doesn't matter for this discussion ) partnered with a prominent outsourcing firm. The press release was carefully worded but if you read into what wasn't said, it was in my opinion encouraging something that folks here tend to fight against. The outsourcing firm would use this tool in an auditing capacity for whatever client asked for another service but it would not become part of the general software development lifecycle for all projects. - It didn't mention any notion of all developers within the outsourcing firm having tools on their desktop to audit as they develop - It didn't mention any notion of training all developers within the outsourcing firm on secure coding practices - It did hint that one time periodic audits from a metrics perspective would be useful to clients that wanted this new service but didn't say how developers would be able to iterate on the code and reduce bugs. I would think that any offering that removes developers from the feedback loop while developing code and instead focusing on management-oriented (non-developer metrics) is generally a bad idea. - It didn't mention even how many folks from their security practice were to receive training in secure coding practices - Should we think of security as an extra service or something that should be incorporated into the SDLC in a consistent sustainable manner? I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his wonderful training course by thinking that this type of initiative does more harm than good? * 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] RE: Comparing Scanning Tools
Title: Re: [SC-L] RE: Comparing Scanning Tools I think I should have been more specific in my first post. I should have phrased it as I have yet to find a large enterprise whose primary business isn't software or technology that has made a significant investment in such tools. Likewise, a lot of large enteprrises are shifting away from building inhouse to either outsourcing and/or buying which means that secure coding practices should also be enforced via procurement agreements. Has anyone here ran across contract clauses that assist in this regard? -Original Message-From: Gunnar Peterson [mailto:[EMAIL PROTECTED]Sent: Friday, June 09, 2006 8:48 AMTo: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)Subject: Re: [SC-L] RE: Comparing Scanning ToolsRight, because their customers (are starting to) demand more secure code from their technology. In the enterprise space the financial, insurance, healthcare companies who routinely lose their customers data and provide their customers with vulnerability-laden apps have not yet seen the same amount of customer demand for this, but 84 million public lost records later ( http://www.privacyrights.org/ar/ChronDataBreaches.htm) this may begin to change.-gpOn 6/9/06 1:45 AM, "Brian Chess" [EMAIL PROTECTED] wrote: McGovern, James F wrote: I have yet to find a large enterprise that has made a significant investment in such tools. Ill give you pointers to two. Theyre two of the three largest software companies in the world.http://news.com.com/2100-1002_3-5220488.htmlhttp://news.zdnet.com/2100-3513_22-6002747.htmlBrian ___Secure Coding mailing list (SC-L)SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php * 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
RE: [SC-L] Comparing Scanning Tools
Several thoughts: 1. I love it when industry analysts are perceived as being credible by throwing out financial costs for things they really don't have visibility into. 2. The VA lost data not do secure coding techniques but an employee not following the rules on what data to take out of the building. 3. No industry analyst has ever attempted to quantify cost vs benefit of secure coding when compared to other constraints. The quantification to date has only been the cliche: it is cheaper to fix X earlier in the lifecycle rather than later in which X could be pretty much any system quality. -Original Message- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 9:28 AM To: McGovern, James F (HTSC, IT) Cc: Secure Mailing List Subject: Re: [SC-L] Comparing Scanning Tools Hi James, I think you are right to look at it as economic issue, but the other factor to add into your model is not just the short term impact to developer productivity (which is non-trivial), but also the long term effects of making decisions *not* to deal with finding bugs. Cleaning up data breach costs more than encryption Protecting customer records is a much less expensive than paying for cleanup after a data breach or massive records loss, research company Gartner said. Gartner analyst Avivah Litan testified on identity theft at a Senate hearing held after the Department of Veterans Affairs lost 26.5 million vet identities. A company with at least 10,000 accounts to protect can spend, in the first year, as little as $6 per customer account for just data encryption, or as much as $16 per customer account for data encryption, host-based intrusion prevention, and strong security audits combined, Litan said. Compare [that] with an expenditure of at least $90 per customer account when data is compromised or exposed during a breach, she added. Litan recommended encryption as the first step enterprises and government agencies should take to protect customer/citizen data. If that's not feasible, organizations should deploy host-based intrusion prevention systems, she said, and/or conduct security audits to validate that the company or agency has satisfactory controls in place. http://www.techweb.com/wire/security/188702019 Or, Brian Chess once pointed out: My favorite historical analogy this month is from medicine: it took *decades* between the time that researchers knew that fewer people died if surgeons washed their hands and the time that antisepsis was common in the medical community. That lag was entirely due to social factors: if it's 1840 you've been successfully practicing medicine for decades, why would you want to change your routine? And yet imagine a modern day surgeon who says I'm really busy today, so I'm going to save time by not scrubbing in before I start the operation. It's simply unthinkable. Hopefully software development is headed in the same direction, but on an accelerated timetable. -gp * 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
RE: [SC-L] Comparing Scanning Tools
Thanks for the response. One of the things that I have been struggling to understand is not the importance of using such a tool as I believe they provide value but more of the fact that these tools may not be financial sustainable. Many large enterprises nowadays outsource development to third parties. Likewise, the mindset in terms of budgeting tends to eschew per developer seat tool purchases. Nowadays, it is rare to find an enterprise not using free tools such as Eclipse and not paying for IDEs I have yet to find a large enterprise that has made a significant investment in such tools. I wonder if budgets and the tools themselves are really causing more harm than helping in that enterprises will now think about trading off such tools vs the expense they cost. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 4:34 PM To: McGovern, James F (HTSC, IT) Cc: sc-l@securecoding.org Subject: Re: [SC-L] Comparing Scanning Tools | Date: Mon, 5 Jun 2006 16:50:17 -0400 | From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] | To: sc-l@securecoding.org | Subject: [SC-L] Comparing Scanning Tools | | The industry analyst take on tools tends to be slightly different than | software practitioners at times. Curious if anyone has looked at Fortify and | has formed any positive / negative / neutral opinions on this tool and | others... We evaluated a couple of static code scanning tools internally. The following is an extract from an analysis I did. I've deliberately omitted comparisons - you want to know about Fortify, not how it compares to other products (which raises a whole bunch of other issues), and included the text below. Standard disclaimers: This is not EMC's position, it's my personal take. Caveats: This analysis is based on a 3-hour vendor presentation. The presenter may have made mistakes, and I certainly don't claim that my recall of what he said is error-free. A later discussion with others familiar with Fortify indicated that the experience we had is typical, but is not necessarily the right way to evaluate the tool. Effective use of Fortify requires building a set of rules appropriate to a particular environment, method of working, constraints, etc., etc. This takes significant time (6 months to a year) and effort, but it was claimed that once you've put in the effort, Fortify is a very good security scanner. I am not in a position to evaluate that claim myself. BTW, one thing not called out below is that Fortify can be quite slow. Our experience in testing was that a Fortify scan took about twice as long as a C++ compile/link cycle, unless you add data flow analysis - in which case the time is much, much larger. The brief summary: In my personal view, Fortify is a worthwhile tool, but it would not be my first choice. (Given the opportunity to choose two tools, it would probably be my second.) Others involved in the evaluation reached the opposite conclusion, and rated Fortify first. -- Jerry Fortify * 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] Comparing Scanning Tools
The industry analyst take on tools tends to be slightly different than software practitioners at times. Curious if anyone has looked at Fortify and has formed any positive / negative / neutral opinions on this tool and others... * 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] Secure Application Protocol Design
Would love to see Gary address a couple of behaviors I have seen in my travel amongst architect types in corporate America especially the practice of secure application protocol design that isn't so secure. Is anyone writing/blogging deeply on this aspect? Likewise, there are many folks in corporate America that have not yet acknowledged that they shouldn't be playing part-time cryptographer and don't have the competency to design cryptographic primitives such as hash functions and algorithms to protect data. Does anyone know of any friendly articles that speak to this problem space? * 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
