[SC-L] OWASP DEVELOPMENT GUIDE NEWS/CALL FOR CONTRIBUTORS
News Release/Call For Contributors OWASP Development Guide Project begins work on next Guide version The Guide is a manual for designing, developing, and deploying secure web applications OWASP Development Guide Project MCLEAN February 10, 2010 MCLEAN, Feb. 10 /OWASP Development Guide Projecthttp://www.owasp.org/index.php/Category:OWASP_Guide_Project/ -- After many months of planning and preparation, the OWASP Development Guide project announced today that it is ready to begin work on the next revision of the Guide, and that that the project is looking for volunteers to do the work, both individuals and organizations. The OWASP Development Guide is aimed at architects, developers, consultants and auditors and is a comprehensive manual for designing, developing and deploying secure web applications. The original OWASP Development Guide has become a staple diet for many web security professionals. Since 2002, the initial version was downloaded over 2 million times. Today, the Development Guide is referenced by many leading government, financial, and corporate standards and is the Gold standard for Web Application and Web Service security. The next version of the OWASP Development Guide will be in effect the detailed design guide for the requirements of the OWASP Application Security Verification Standard (ASVS), which can be found here: http://www.owasp.org/index.php/ASVS. Key features of the next Guide will include use of the new OWASP common numbering scheme. The new numbering scheme will be common across OWASP Guides and References, more information can be found here: http://www.owasp.org/index.php/Common_OWASP_Numbering. Additional key features will be the inclusion of worksheets and checklists, such as the sample input validation worksheet which can be found here: http://code.google.com/p/owasp-development-guide/wiki/WebAppSecDesignGuide_D5_2_1_1 For more information, and for more information if you are interested in volunteering, please see: http://owasp-development-guide.googlecode.com/files/development-guide-contributing.pdf Please forward this email as you think appropriate. Got buddies and want to work on a section or two as a team? Professional project management will be a key feature of the next release of the Guide and can help to facilitate such arrangements. Here is what the work streams will look like: http://owasp-development-guide.googlecode.com/files/guide-org-chart.pdf. And, the Guide project is always on the lookout for volunteers. If you think you might have availability in the future, please do reach out at that time. For more information, email the OWASP Development Guide project manager Mike Boberski at mike.bober...@owasp.orgmailto:mike.bober...@owasp.org. About OWASP The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license at http://www.owasp.org SOURCE: OWASP Development Guide Project Web site: http://www.owasp.org/index.php/Category:OWASP_Guide_Project ___ 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] win win for owasp and television spots
My #1 rule is to avoid jargon and to speak in as conversational a way as possible, targeting (and retargeting as the conversation progresses) the level of detail/abstraction to the targeted audience, whether it's one person or a bunch. Start broad, then narrow it down, change direction as the flow of the conversation dictates. E.g., Is your application this secure (hand gesture) or T--H--I--S secure (bigger hand gesture)? This is what application security is all about. Application security can perhaps be thought of in terms of buying, building, and breaking software.BLAH BLAH..[buy=OWASP legal project's contract annex, build=OWASP ESAPI, break=OWASP ASVS]..[awareness=OWASP Top 10]...[injecting security into development cycles=OWASP SAMM].. To explain further, to put all of this together...While most people are familiar with passwords, and people like to say firewall!, authentication, encryption and digital signatures, and logging are only the beginning, in terms of application security. Additional technical security controls are necessary to write applications that can (or should) be trusted by the customer not to spill data regardless of environment, from private networks to clouds, given modern-day threats.BLAH BLAH..China! Google! .BLAH BL! AH.. FWIW, Best, Mike B. -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Matt Parsons Sent: Friday, January 22, 2010 5:40 AM To: 'Secure Code Mailing List' Subject: Re: [SC-L] win win for owasp and television spots Ladies and Gentlemen, I am starting to get approached by a few television stations to talk about application security. I would like to promote Owasp in these talks. What would be the best way to do it professionally and competently? See below news story. Thanks, Matt http://www.the33tv.com/news/kdaf-password-security-jim,0,3650695.story Matt Parsons, MSM, CISSP 315-559-3588 Blackberry 817-294-3789 Home office mailto:mparsons1...@gmail.com http://www.parsonsisconsulting.com http://www.o2-ounceopen.com/o2-power-users/ http://www.linkedin.com/in/parsonsconsulting http://parsonsisconsulting.blogspot.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. ___ ___ 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] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog
To expand upon But you need A ESAPI for your organization briefly, From a certain point of view, just as application can be PK-enabled, they can be ES-enabled. Instead of a PKI toolkit, one uses an Enterprise Security API toolkit. Instead of signature functions, think input validation functions, where security checks and effects are performed and result according to a given organization's/application's security policy. Note that crypto should also be wrapped, but trying not to overcomplicate things in this note. The toolkit may be an OWASP version, or it may be one of any number of flavors described below, where security functions are logically and/or physically grouped into an organization/application-specific ESAPI. The OWASP ones just happen to exist and are free. Then, developers are trained/instructed/etc. to use them depending on their own life cycle best practices. I have more to say, but let us start here. Best, Mike B. -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Jim Manico Sent: Thursday, January 07, 2010 10:56 AM To: John Steven Cc: Secure Coding Subject: Re: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog John, You do not need OWASP ESAPI to secure an app. But you need A ESAPI for your organization in order to build secure Apps, in my opinion. OWASP ESAPI may help you get started down that path. An ESAPI is no silver bullet, there is no such thing as that in AppSec. But it will help you build secure apps. Jim Manico On Jan 6, 2010, at 6:20 PM, John Steven jste...@cigital.com wrote: All, With due respect to those who work on ESAPI, Jim included, ESAPI is not the only way to make a secure app even remotely possible. And I believe that underneath their own pride in what they've done--some of which is very warranted--they understand that. It's hard not to become impassioned in posting. I've seen plenty of good secure implementations within organizations' own security toolkits. I'm not the only one that's noticed: the BSIMM SSF calls out three relevant activities to this end: SDF 1.1 Build/publish security features (*1) SDF 2.1 Find/publish mature design patterns from the organization (similar URL) SDF 2.3 Build secure-by-design middleware frameworks/common libraries (similar URL) Calling out three activities within the SSF means that it can't just be John Steven's top client (whatever that means) that's doing this either. I've formally reviewed some of these toolkits and I'd pit them against ESAPI and expect favorable results. Plenty of organizations are doing a great job building stuff on top of profoundly broken platforms, frameworks, and toolkits... and they're following a 'secure SDL' to get there. ESAPI can not be said to have adhered to that rigor (*2). Organizations care about this risk regardless of the pedigree and experience of those who are building it. Is the right answer for everyone to drop everything and build their own secure toolkit? I don't think so. I like that the OWASP community is taking a whack at something open and free to share. These same people have attempted to improve Java's security through the community process--and though often correct, diligent, friendly, and well-intentioned, their patience has often been tested to or beyond the breaking point: those building the platforms and frameworks simply aren't listening that well yet. That is very sad. One thing I've seen a lot of is organizations assessing, testing, hardening, documenting, and internally distributing their own versions of popular Java EE toolkits (the secure struts phenomenon). I've seen some organizations give their developers training and write SAST rules to automatically verify correct use of such toolkits. I like this idea a hell of a lot as an alternative to an ESAPI-like approach. Why? A few reasons: 1) Popularity - these toolkits appeal to developers: their interfaces have been voted on by their adopting user population-- not conceived and lamented principally by security folk. No one forces developers to go from Struts to Spring they do it because it saves them time, makes their app faster, or some combination of important factors. 2) Changes App Infrastructure - MVC frameworks, especially, make up the scaffolding (hence the name 'Struts') of an application. MVC code often touches user input before developer's see it and gets the last chance to encode output before a channel (user or otherwise) receives it. Focusing on an application's scaffolding allows in some cases, a best-chance of touching all input/out and true invisibility relative to developer generated code. Often, its configuration is declarative in nature as well--keeping security from cluttering up the Java code. Note that this approach is fundamentally different from Firewalls
Re: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog
Regarding PKI, we travel in different circles when it comes to that, perhaps best to leave that one there. Anywho... All sorts of apples and oranges are being mixed up here. There is the security of a targeted app, of the components in the environment that it depends on to run, of the environment itself, and of the whole mess when everything's up and running. ESAPI is intended to be used by the targeted app. The overall security will then be dragged up or down depending on the components in the environment and the operation and the development of the app in the first place. Different strategies and whatnot can then be applied to claw one's way back up to a targeted level of assurance. Your comments below span these areas, when we're really just trying to talk about one. Hooray for ESAPI for helping out with the piece of the puzzle that it can. You bet that we're going to explain and promote its use, as people who have contributed to its development and adoption. The documentation and whatnot is being worked on. We could use a hand if you've got some cycles! I wrote a first draft of a design patterns guide not too long ago, please feel free to review and provide comments, it's on the project page. The project presentation also speaks to a number of the items below. Threat models, white papers, all good, if you (or anyone) wish to contribute! Best, Mike B. -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of John Steven Sent: Thursday, January 07, 2010 1:03 PM To: Secure Coding Subject: Re: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Jim, Yours was the predicted response. The ref-impl. to API side-step does not fix the flaw in the argument though. No, you do not need A ESAPI to build secure apps. Please re-read my email carefully. Alternatives: 1) Some organizations adopt OWASP ESAPI's ref-impl. 2) Others build their own do agree and see the value; yes #1 and #2 agree with your position. 3) Some secure their toolkits (again, a la secure struts) Indicating such a secure struts is an organization's ESAPI perverts the ESAPI concept far too greatly to pass muster. Indeed, were it to, it would violate properties 3 and 4 (and very likely 2) within my previous email's advantage list. Mr. Boberski, you too need to re-read my email. I advise you strongly not to keep saying that ESAPI is like PK-enabling an APP. I don't think many people got a good feeling about how much they spent on, or how effective their PKI implementation was ;-). Please consider how you'd ESAPI-enable the millions of lines of underlying framework code beneath the app. 4) Policy + Standards, buttressed with a robust assurance program Some organizations have sufficiently different threat models and deployment scenarios within their 'four walls' that they opt for specifying an overarching policy and checking each sub-organization's compliance--commensurate with their risk tolerance and each app deployment's threat model. Each sub-organization may-or-may-not choose to leverage items one and two from this list. I doubt, however, you'd argue that more formal methods of verification don't suffice to perform 'as well' as ESAPI in securing an app (BTW, I have seen commercial implementations opt for such verification as an alternative to a security toolkit approach). Indeed, an single security API would likely prove a disservice if crammed down the throats of sub-organizations that differ too greatly. At best, the implicit ESAPI or the highway campaign slogan applies to only 50% of the alternatives I've listed. And since the ESAPI project doesn't have documented and publicly available good, specific, actionable requirements, mis-use cases, or a threat model from which it's working, the OWASP ESAPI project doesn't do as much as it could for the #2 option above. Jim, Mike, I see your posts all-througout the the blog-o-sphere and mailing lists. Two-line posts demanding people adopt ESAPI or forgo all hope can off-put. It conjures close-minded religion to me. Rather: * Consider all four of the options above, one might be better than OWASP ESAPI within the context of the post * Consider my paragraph following Point #4. Create: * An ESAPI mis-use case guide, back out security policy it manifests, or requirements it implements (and don't point me to the unit tests--I've read them) * Document an ESAPI threat model (For which apps will developers have their expectations met adopting ESAPI? Which won't?) * A document describing experiment results: before and after ESAPI: how many results does a pen-test find?, 'Code review? * Write an adoption guide. Apps are only created in a green-field once. Then they live in maintenance forever. How do you apply ESAPI to a real-world app already
Re: [SC-L] InformIT: You need an SSG
but it is nowhere near as important or as effective as teaching defensive programming I.e., arming developers with toolkits that perform expected security checks and that result in expected security effects, and making sure they can use them. Not a sermon just a thought, as the local radio station ad goes. Best, Mike B. -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw Sent: Tuesday, December 22, 2009 12:09 PM To: list-s...@secureconsulting.net; Secure Code Mailing List Subject: Re: [SC-L] InformIT: You need an SSG hi ben, You may be right. We have observed that the longer an initiative is underway (we have one in the study that checks in at 14 years old), the more actual activity tends to get pushed out to dev. You may recall from the BSIMM that we call this the satellite. Microsoft has an extensive satellite with 300 or so people embedded throughout their huge company (recall that their SSG is 100). Because the notion of satellite is not as common a phenomenon in our data, we can't draw conclusions as clear as the ones we can draw regarding an SSG. Think of the SSG and the Satellite as coaches and mentors who are tasked with helping development get it right (not simply cleaning up their messes). I agree that we have spent too much effort over the past decade simply trying to assess the mess and not enough getting dev to change their behavior. The companies we studied in the BSIMM are trying to change dev. As a particular example of where I agree with you that we go off track as a discipline, consider training. Teaching developers about the OWASP top 10 in training may be exciting, but it is nowhere near as important or as effective as teaching defensive programming. (And this from the guy who wrote Exploiting Software.) Developers need to know how to do it right, not just what bugs look like on TV. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 12/22/09 10:11 AM, Benjamin Tomhave list-s...@secureconsulting.net wrote: I think the short-term assertion is sound (setup a group to make a push in training, awareness, and integration with SOP), but I'm not convinced the long-term assertion (that is, maintaining the group past the initial push) is in fact meritorious. I think there's a danger in setting up dedicated security groups of almost any sort as it provides a crutch to organizations that then leads to a failure to integrate security practices into general SOP. What is advocated seems to be consistent with how we've approached security as an industry for the past couple decades (or longer), and I don't see this as having the long-term benefit that was desired or intended. It seems that when you don't make people directly responsible and liable for doing the right things, they then fail at the ask and let others do it instead. It's the old lazy sysadmin axiom that we script repeatable tasks because it's easier in the long run. The question, then, comes down to one of psychology and people management. How do we make people responsible for their actions such that they begin to adopt better practices? The basic response should be to enact consequences, and I think that now is probably an optimal time for businesses to get very hard-nosed about these sorts of things (high unemployment means lots of people looking for work means employers have the advantage). This perhaps sounds very ugly and nasty, and obviously it will be if taken to an extreme, but we have a serious problem culturally in that non-security people still don't seem to think, on average, that security is in their job description. Solve that problem, and all this other stuff becomes a footnote. fwiw. -ben Gary McGraw wrote: hi sc-l, This list is made up of a bunch of practitioners (more than a thousand from what Ken tells me), and we collectively have many different ways of promoting software security in our companies and our clients. The BSIMM study http://bsi-mm.com focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed in the BSIMM was that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities. I wrote about our observations around SSGs in this month's informIT article: http://www.informit.com/articles/article.aspx?p=1434903 Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We're still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.) Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception,
