Re: [SC-L] SearchSecurity: Dynamism
nice one, Gary. Finally something positive about agile and DevOps. A trick that you may have missed is immutable servers, see Docker and friends. They will be a leap forward for server security when they hit the mainstream. ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] security in open source components
I was very happy to see http://www.sonatype.com/Products/Sonatype-Insight/Why-Insight/Reduce-Security-Risk/Security-Brief. Finally some attention to the elephant in the room; what is the use of secure coding if your software depends on third party components with flaws? The paper makes some very good points on the general lack of governance for open source components. It mainly focuses on the lack of visibility and control of project dependencies. I.e. what does a build pull in? Are these trustworthy components? Does the build select component versions with flaws? Is any attention paid to security advisories and dependencies updated to versions with the flaws fixed? These points are important. However, I am also concerned about component distribution. How can I be sure that the binary component my build script retrieves from, say, Maven Central is the one released by the relevant open source project? I know there are checksums and such, but I remain to be convinced that this typically affords adequate protection or that it even could do so. If my fears are well-founded, current distribution mechanisms of open source components provide the ideal opportunity for installing back-doors on the server side. I hope I am just being paranoid and the authors neglected to talk about distribution because it is obviously secure. I certainly would have been happier if distribution had been analysed and found secure, or, even, not terribly insecure. Does anyone else share these concerns? Or can anyone allay my fears? kr, Yo -- Johan Peeters http://johanpeeters.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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Application Security Debt and Application Interest Rates
Security debt seems to me a very useful concept. Thanks, Chris. As I pointed out in my blog post (http://www.artima.com/weblogs/viewpost.jsp?thread=320875), I do not believe in quantitative models though. Clearly, it is interesting to try to nail the factors that contribute to the cost and to establish whether it is cheaper to pay back or service the debt, but to put numbers on these costs is smoke and mirrors imho. kr, Yo On Sun, Mar 6, 2011 at 6:19 PM, Sammy Migues smig...@cigital.com wrote: Just in case others have missed it, there’s a response from Russell Thomas on the New School blog at http://newschoolsecurity.com/2011/03/fixes-to-wysophal’s-application-security-debt-metric/. From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Chris Wysopal Sent: Friday, March 04, 2011 7:38 PM To: SC-L@securecoding.org Subject: [SC-L] Application Security Debt and Application Interest Rates I have a couple of blog posts modeling application vulnerabilities the way you might think of technical debt. Part I: Application Security Debt and Application Interest Rates http://www.veracode.com/blog/2011/02/application-security-debt-and-application-interest-rates/ Part II: A Financial Model for Application Security Debt http://www.veracode.com/blog/2011/03/a-financial-model-for-application-security-debt/ -Chris ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ -- Johan Peeters http://johanpeeters.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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] discounts for SecAppDev for independents and start-ups
No developer should deliver insecure applications because he or she cannot afford being trained. That is why secappdev.org distributes its top-notch secure development training material for free via its web site, http://secappdev.org. Nonetheless, you may find it cost-effective to attend our course in person and be immersed in application security. We want to make every effort to make it accessible to all developers and hence are extending our existing 50% discount to public servants to independents and start-ups. Contact me if you want to make use of this facility. The discount is discretionary and will be subject to evidence that the full cost would be prohibitive. Just in case you need reminding: SecAppDev 2011 will take place from February 28th to March 4th in the Faculty Club, Groot Begijnhof, Leuven, Belgium. Registration is available on http://secappdev.org/registrations/new, but do not hesitate to contact me if you have further questions. I hope to see you soon. Yo -- Johan Peeters Program Director http://secappdev.org ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] SecAppDev 2011
SecAppDev 2011 will take place from February 28th to March 4th in the Groot Begijnhof, Leuven, Belgium. SecAppDev is a series of intensive one-week courses on Secure Application Development, run by secappdev.org, a non-profit organization that aims to broaden security awareness in the development community and advance secure software engineering practices. Katholieke Universiteit Leuven and Solvay Brussels School of Economics and Management are founding partners. When we ran our first annual course in 2005, emphasis was on awareness and security basics, but as the field matured and a thriving security training market developed, we felt it was not appropriate to compete as a non-profit organization. Our focus has hence shifted to providing a platform for more leading-edge and experimental material. Our courses are taught by world-leading instructors from academia and industry. We look toward academics to provide research results that are ready to break into the mainstream and attract people with an industrial background to try out new content and formats. For the presentation in February-March 2011, we are proud to have once again attracted contributions from software security thought leaders such as - Prof. dr. ir. Bart Preneel who heads COSIC, the renowned crypto lab. - Ken van Wyk, the moderator of this list. - John Steven, a sought-after architect and technical lead for high-performance, scalable Java EE systems. - Prof. dr. Dan Wallach, Rice University's computer security lab head. - Gunnar Peterson, focused on distributed systems security for large mission critical systems. We do not target security experts nor developers of security products, but rather developers whose main focus not being security, nonetheless need to be sufficiently security-savvy to deliver reliable applications. We are trying to plug the security blind spot of many academic software engineering courses. We cover a wide range of facets of secure software engineering including - requirements analysis - development processes - project management - economic/business aspects - cryptography - identity and access control and management - architecture - design - coding - testing SecAppDev 2011 is the 7th edition of a widely acclaimed course, attended by an international audience from a broad range of industries including financial services, telecom, consumer electronics and media. The course is run in very pleasant surroundings, a UNESCO world heritage site dating back to the 13th century and we have a well-attended social program. For more information visit the web site: http://secappdev.org. Places are limited, so do not delay registering to avoid disappointment. Registration is on a first-come, first-served basis. A 25% Early Bird discount is available until December 31. Public servants receive a 50% discount. Kind regards, Yo -- Johan Peeters Program Director http://secappdev.org ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] Announcement SecAppDev 2010
SecAppDev 2010 is an intensive one-week course in secure application development organized by secappdev.org, a non-profit organization dedicated to improving security skills and awareness in the developer community. The course is a joint initiative with K.U. Leuven and Solvay Brussels School of Economics and Management. SecAppDev 2010 is the 6th edition of a widely acclaimed course, attended by an international audience from a broad range of industries including financial services, telecom, consumer electronics and media and taught by leading software security experts including - Dr. Gary McGraw, the software security champion and Cigital CTO. - Prof. dr. ir. Bart Preneel who heads COSIC, the renowned crypto lab. - Ken van Wyk, the moderator of this list. - Dr. Richard Clayton of the University of Cambridge Computer Laboratory's security group, well known for his research on security economics. The course takes place from February 22nd to 26th in the Groot Begijnhof, Leuven, Belgium, a UNESCO World Heritage site. For more information visit the web site: http://secappdev.org. Places are limited, so do not delay registering to avoid disappointment. Registration is on a first-come, first-served basis. A 25% Early Bird discount is available until January 15th. Public servants receive a 50% discount. Best Wishes for 2010, Yo -- Johan Peeters Program Director http://secappdev.org ___ 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] Provably correct microkernel (seL4)
It is my understanding that only the micro-kernel runs in kernel mode, but not having read the nitty-gritty either, I'll stand to be corrected. kr, Yo On Fri, Oct 2, 2009 at 11:20 PM, Wall, Kevin kevin.w...@qwest.com wrote: Steve Christy wrote... I wonder what would happen if somebody offered $1 to the first applied researcher to find a fault or security error. According to http://ertos.nicta.com.au/research/l4.verified/proof.pml, buffer overflows, memory leaks, and other issues are not present. Maybe people would give up if they don't gain some quick results, but it seems like you'd want to sanity-check the claims using alternate techniques. I was actually wondering how they could make that statement unless they can somehow ensure that other components running in kernel mode (e.g., maybe devices doing DMA or device drivers, etc.) can't overwrite the microkernel's memory address space. It's been 20+ years since I've done any kernel hacking, but back in the day, doing something like that with the MMU I think would have been prohibitively expensive in terms of resources. I've not read through the formal proof (figuring I probably wouldn't understand most of it anyhow; it's been 30+ years since my last math class so those brain cells are a bit crusty ;-) but maybe that was one of the caveats that Colin Cassidy referred to. In the real world though, that doesn't seem like a very reasonable assumption. Maybe today's MMUs support this somehow or perhaps the seL4 microkernel runs in kernel mode and the rest of the OS and any DMA devices run in a different address space such as a supervisory mode. Can anyone who has read the nitty-gritty details explain it to someone whose brain cells in these areas have suffered significant bit rot? -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein, co-creator of MIME ___ 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. ___ -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] Provably correct microkernel (seL4)
My $.02... I don't think this approach is going to catch on anytime soon. Spending 30 or so staff years verifying a 7500 line C program is not going to be seen as cost effective by most real-world managers. But interesting research nonetheless. maybe not as crazy as it sounds: this is a micro kernel and hence a security chokepoint. The other stuff running on top do not need the same level of assurance. kr, Yo -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25
What is a business rule? Something like If the customer has changed the shipment address from a previous order, we must re-request his or her credit card details? How would you implement *that* using input validation? The example I often use is 'equity can only be used as debt collateral, if it has a rating' :-) Before setting to work on your example, Florian, I would rephrase it as 'the date of entry of the shipment address must not be after the date of entry of credit card details'. I would then consider this an input validation problem. kr, Yo -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] quick question - SXSW
is integrating with dev processes and practices, making it better? Maybe I'm just too idealist. I'm curious what everyone else thinks. cheers, -ben ___ 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. ___ -- Johan Peeters http://johanpeeters.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. ___
[SC-L] secappdev 2008
secappdev.org organizes its annual course on secure application development in Leuven, Belgium, from March 3rd to 7th 2008. secappdev.org (http://secappdev.org) is a non-profit organization that aims to raise security awareness in the developer community and promote secure software engineering practices. In this course, we target experienced professional application developers. The course addresses a wide range of secure software engineering issues, so not only coding, but also requirements engineering, architecture and design, development processes and assurance. It does not focus on specific technologies, but uses them as examples to teach the underlying principles of software security. The faculty for the course are leading researchers and practitioners in software security and include - Bart Preneel, the head of COSIC, the renowned crypto lab that developed the AES. - Frank Piessens who pioneered application security teaching at university level. - Ken van Wyk, moderator of this excellent list and widely acclaimed author and lecturer. - Wietse Venema, the author of widely used, often seminal and erstwhile controversial, software such as the Postfix mail server, TCP Wrapper, an early host-based firewall, the Coroner's Toolkit, a forensics tool suite, and SATAN, a vulnerability scanner. There will be an opportunity to take the SANS GIAC Secure Software Programmer's (GSSP) exams at a sharply reduced price. The number of participants is limited. Register early to avoid disappointment. kr, Yo -- Johan Peeters http://secappdev.org http://johanpeeters.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. ___
Re: [SC-L] Mainframe Security
I have been looking at an IBM system. If I do something like this ... 01 txt PIC X(120) string '**' into txt end-string display txt I get to see ** on sysout followed by what appears to be selected contents of the data section. This strikes me as somewhat worrysome - it reminds me of the format string vulnerabilities in C. Am I just being paranoid? kr, Yo On 11/2/07, Paul Powenski [EMAIL PROTECTED] wrote: Cobol is highly structured and very difficult to just whip together a program. Your DATA section had to be specified EXACTLY as your design specifies. Any program which input data over the stated limit would give an exception. On the older mainframes your program would terminate. Do not have any experience with later mainframes. The whole operating environment for a mainframe is a charge based model with extensive resource control which, as a side effects, provides stronger program execution security. You can limit I/O access with a mainframe which is very difficult with our new generation of operating systems. Have not done anything with Cobol since the mid 80's. There are probably many variations since then which allow 'features' to extend its life and possibly loosen its strict structure. Using it on a Univac and Honeywell systems in batch mode your program had to be EXACT or the mainframe would not compile it. Paul Powenski ljknews [EMAIL PROTECTED] wrote: At 9:16 PM +0100 11/1/07, Johan Peeters wrote: I think this could do a great service to the community. Recently I was hired by a major financial institution as a lead developer. They said they needed me for some Java applications, but it turns out that the majority of code is in COBOL. As I have never before been anywhere near COBOL, this comes as a culture shock. I was surprised at the paucity of readily available information on COBOL vulnerabilities, yet my gut feeling is that there are plenty of security problems lurking there. Since so much of the financial services industry is powered by COBOL, I would have thought that someone would have done a thorough study of COBOL's security posture. I certainly have not found one. Anyone else? Can anyone point to stories about Cobol exploits ? I mean exploits that have to do with the nature of the language, not social engineering attacks that happened to take place against a Cobol shop. My limited exposure to Cobol makes me think it is as unlikely to have a buffer overflow as PL/I or Ada. -- Larry Kilgallen ___ 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. ___ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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. ___ -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] Mainframe Security
I think this could do a great service to the community. Recently I was hired by a major financial institution as a lead developer. They said they needed me for some Java applications, but it turns out that the majority of code is in COBOL. As I have never before been anywhere near COBOL, this comes as a culture shock. I was surprised at the paucity of readily available information on COBOL vulnerabilities, yet my gut feeling is that there are plenty of security problems lurking there. Since so much of the financial services industry is powered by COBOL, I would have thought that someone would have done a thorough study of COBOL's security posture. I certainly have not found one. Anyone else? kr, Yo On 11/1/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: 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. ___ -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] Software Security Training for Developers
On 8/20/07, Hollis via Rubicon Recluse [EMAIL PROTECTED] wrote: Hi Sammie and Yo, Tkx for the good highlevel insights. A few questions, I'm interested specifically for developer/designers, but I'm sure others are interested in other audiences: - What languages/OS/environments are you developing in? On the one hand, we would like to be technology-neutral, on the other, we want to teach people about real-world technologies and security issues, so we tend to cherry-pick technologies to suit the purposes of the principles we are trying to illustrate. For example, the access control module has tended to have a lot on Windows because their model is somewhat richer than the Unices'. Language-based security mechanisms discussions, on the other hand, have focused mainly on Java because of their seminal significance. - Does your training address your language/OS/environment? If so, what percentage? At the last presentation, 25-30%% of the time was spent on the infrastructure at the disposal of the developer, including language-based, OS, middleware and cryptography. - How long is the/each course? - did you go with inclass, self-paced, JIT or a combination. And which aspects to each? The secappdev courses take one week in-class, but, as I mentioned, recordings are mostly available on-line, giving the opportunity for self-paced or JIT study. Let me also clarify that secappdev.org only offers public courses, so, as an organization, we are not in a position to taylor content to the specific needs of a particular project though a number of the people on the secappdev faculty would take on such assignments. - What is your audience size? And what percentage did you train? I am not sure that I understand your question. We have limited the number of participants to 25 in the past. At the last presentation, all these seats were taken. We are now increasing the number of places offered to 50, but offering a dual track course so that, in a sell-out scenario, the average class size will again be 25. - Over what period of time? - Was it mandatory? And to Sammy's point, at what management level was it loudly supported? Thanks for your insights, Hollis At 11:51 AM 8/19/2007, Johan Peeters wrote: From my experience with secappdev.org (http://secappdev.org), a not-for-profit organization set up to create security awareness and improve skills in the developer community, I find myself in agreement with many of the points that Sammy raises. Development is not only about coding. secappdev tends to pay relatively little attention to coding; adoption of new technologies offering novel opportunities to shoot yourself in the foot is so rapid, platforms so varied and applications so different that we have found teaching secure software engineering principles to be a better investment for both students and teachers alike. While it is certainly true that what ultimately matters is the code, conventional wisdom has it that coding only accounts for about 20% of the development effort. The rest of the time is spent in specification, design, test, deployment and project management. We feel it is counter-productive to draw sharp distinctions between these various activities, they all need to be done well to deliver a succesful project. So we spend considerable time looking at their security implications. Apart from chiming in with Sammy, I would also like to point out that our target audience are application developers and their main focus is definitely not security, nor should it be: their job is to create value by adding functionality. Rather than teaching them to become security experts, we try to teach them strategies for getting away with as little security knowledge as possible so that they can focus on their core concerns. So one of the things we do is to make sure that participants have a good grasp of the security services offered by application platforms. An example of an architectural level discussion would be the choice of platform and its impact on security as well as how to mitigate the risks. Effective security teaching imparts a mindset, the body of knowledge is incidental. So we have a strong commitment to teach small groups with plenty of opportunity for interaction and immersion. At the next presentation, we are increasing the number of workshop sessions requiring participants to actively participate in problem-solving. So far, all secappdev.org presentations have been in Belgium and that may be a little out of the way for some/most of you. However, recordings of most of the last presentation are available from the web pages with the descriptions of individual sessions - mail me if you need fuller instructions. The next presentation is planned for the week starting March 3rd 2008. This will be a dual-track event. I hope to be able to publish the program very soon. kr, Yo On 8/17/07, Sammy Migues [EMAIL PROTECTED] wrote: Hi Chris
Re: [SC-L] Software Security Training for Developers
to govern and managers need to understand how to facilitate. By way of full disclosure, I've spent a great deal of time building such a cross-cutting curriculum at Cigital, which we've delivered to a variety of financial services, independent software vendor, and other organizations. As for pricing, I've seen everything from a few hundred dollars per person for material you could effectively download yourself to $12,000 or more per day for a few slides and one big exercise that may have nothing to do with a group's particular needs. I've also seen a few examples of some really good stuff that just speaks to me. Organizations must make sure they're getting an instructor that thoroughly understands the material and that they've worked with the training provider to ensure the material is appropriately customized to their needs. Effectiveness is in the eye of the beholder. The actual impact of developer training alone may take months to show up in even the most mature dashboard. More broad training across each of the key roles, appropriately supported by prescriptive guidance and automation, has historically shown a recognizable impact (e.g., finding many more security-related bugs much earlier in the SDLC) much more quickly. I recently put together some (long) thoughts on an approach for training. You can see them at http://www.cigital.com/justiceleague/2007/06/25/training-material-training-and-behavior-modification-part-1-of-3-%e2%80%93-training-material/. --Sammy. Sammy Migues Director, Knowledge Management and Training 703.404.5830 - http://www.cigital.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M Sent: Thursday, August 16, 2007 7:23 PM To: sc-l@securecoding.org Subject: [SC-L] Software Security Training for Developers What are folks' experiences with software security training for developers? By this, I'm referring to teaching developers how to write secure code. Ex. things like how to actually code input validation routines, what evil functions and libraries to avoid, how to handle exceptions without divulging too much info, etc. Not how to hack applications. There are quality courses and training that show you how to break into apps--which are great, but my concern is that if you are a developer (vs. a security analyst, QA type, pen-tester, etc.),even when you know what could happen, unless you've been specifically taught how to implement these concepts in your language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting the most bang for the buck from them. What vendors teach it? How much does it cost? Actual impact realized? Tx Chris McCown, GSEC(Gold) Intel Corporation ( (916) 377-9428 | * [EMAIL PROTECTED] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] Ajax one panel
I think Java would have been a better language with closures, but I am intrigued that you raise them here. Do you think closures present security benefits? Or is this a veiled reference to Ajax? I guess JavaScript has closures. kr, Yo Gary McGraw wrote: Ok...it was java one. But it seemed like ajax one on the show floor. I participated in a panel yesterday with superstar bill joy. I had a chance to talk to bill for a while after the gig and asked him why java did not have closure. Bill said he was on a committee of five, and got out-voted 2 to 3 on that one (and some other stuff too). You know the other pro vote had to be guy steele. Most interesting. Tyranny of the majority even in java. Btw, bill also said they tried twice to build an OS on java and failed both times. We both agree that a type safe OS will happen one day. Here's a blog entry from john waters that describes the panel from his point of view. http://www.adtmag.com/blogs/blog.aspx?a=18564 gem www.cigital.com www.swsec.com Sent from my treo. This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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 -- Johan Peeters program director http://www.secappdev.org +32 16 649000 ___ 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] Ajax one panel
thanks for the clarification, Gary. So I would like to restate my question as follows: do you know of any (atempts at) implementations of a sandbox based on closures? It seems to me that there are some tricky issues like how the permissions get into the closure or how privileged code is called. But that's probably due to the limitations on my imagination. Meanwhile, at Artima (http://www.artima.com/weblogs/viewpost.jsp?thread=161019) and ObjectMentor (http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal), people are also discussing the 'final kludge', calling for 'final' to become deprecated. It would be nice to think there is something that could take its place :-) kr, Yo Gary McGraw wrote: You guys are both right, but talking about different things. You can kludge pretend closure for a security critical section using the static final nonsense to make a hole on the unbound environment. I described this in some detail in a 1999 javaworld article. Havung closure would lead to a better sandbox. The luring attacks that john describes were not what I was getting at, but they lend more weight to the argument for closure. Yay, language arcana! gem -Original Message- From: Johan Peeters [mailto:[EMAIL PROTECTED] Sent: Sun May 21 09:08:14 2006 To: John Steven Cc: Gary McGraw; Mailing List, Secure Coding; SSG Subject:Re: [SC-L] Ajax one panel We may be at cross purposes. I understand your concern about luring attacks, John. I am sure you are right and they are feasible, but I interpreted Gary's comment as meaning 'closures can be used to build a more reliable sandbox'. But maybe this is not what is meant? kr, Yo John Steven wrote: Johan, Yes, the attacks are feasible. Please refer to the Java language spec. on inner/outer class semantics and fool around with simple test cases (and javap -c) to show yourself what's happening during the compile step. Attacks require getting code inside the victim VM but mine pass verification silently (even with verifier turned on). Calling the privileged class to lure it into doing your bidding requires only an open package (not signed and sealed -- again see spec.) and other fun- and-excitement can be had if the Developer hasn't been careful enough to define the PriviledgedAction subclass as an explicit top-level class and they've passed information to-and-fro using the inner class syntactic sugar--rather than explicit method calls defined pre- compile time. John Steven Technical Director; Principal, Software Security Group Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F http://www.cigital.com Software Confidence. Achieved. On May 21, 2006, at 8:23 AM, Johan Peeters wrote: That sounds like a very exciting idea, but I am not sure about the mechanics of getting that to work. I assume the permissions for the untrusted code would be in the closure's environment. Who would put them there? How would the untrusted code call privileged code? Has anyone done this? kr, Yo Gary McGraw wrote: Hi yo! Closure is very helpful when doing things like crossing trust boundaries. If you look at the craziness involved in properly invoking the doprivilege() stuff in java2, the need for closure is strikingly obvious. However, closure itself is not as important as type safety is.So the fact that javascript may (or may not) have closure fails in comparison to the fact that it is not type safe. Ajax is a disaster from a security perspective. gem -Original Message- From: Johan Peeters [mailto:[EMAIL PROTECTED] Sent:Sat May 20 15:44:46 2006 To:Gary McGraw Cc:Mailing List, Secure Coding; SSG Subject:Re: [SC-L] Ajax one panel I think Java would have been a better language with closures, but I am intrigued that you raise them here. Do you think closures present security benefits? Or is this a veiled reference to Ajax? I guess JavaScript has closures. kr, Yo Gary McGraw wrote: Ok...it was java one. But it seemed like ajax one on the show floor. I participated in a panel yesterday with superstar bill joy. I had a chance to talk to bill for a while after the gig and asked him why java did not have closure. Bill said he was on a committee of five, and got out-voted 2 to 3 on that one (and some other stuff too). You know the other pro vote had to be guy steele. Most interesting. Tyranny of the majority even in java. Btw, bill also said they tried twice to build an OS on java and failed both times. We both agree that a type safe OS will happen one day. Here's a blog entry from john waters that describes the panel from his point of view. http://www.adtmag.com/blogs/blog.aspx?a=18564 gem www.cigital.com www.swsec.com Sent from my treo. This electronic message
Re: [SC-L] Information Security Considerations for Use Case Modeling
This topic is very pertinent. I agree that the lack of attention paid to security in many development projects stems from an inability to track security requirements in the software development life cycle. By addressing security requirements in a use case model, I believe that traceability can be improved enormously. However, traditional use cases are not always adequate to express security requirements. For example, whereas it may be possible to say that a user needs to authenticate to perform an action, it is not possible to express that attackers must be prevented from executing their own code on the system. I therefore feel there is a strong case for extending the use case concept to abuse cases, as introduced by McDermott in C. Fox, Using Abuse Case Model for Security Requirements Analysis in 1999 (http://www.acsac.org). In agile ecologies, use cases have transmuted to user stories. I have proposed to also extend user stories to abuser stories (http://www.johanpeeters.com/papers/abuser stories.pdf). kr, Yo Gunnar Peterson wrote: I have published a new paper on integrating security into Use Case Modeling: http://www.arctecgroup.net/secusecase.htm -gp -- Johan Peeters http://www.johanpeeters.com +32 16 649000
