From announcements at webappsec.org  Sun Jan  3 06:42:07 2010
From: announcements at webappsec.org (announcements at webappsec.org)
Date: Sun, 3 Jan 2010 06:42:07 -0500 (EST)
Subject: [SC-L] WASC Announcement: WASC Threat Classification v2.0 Published
Message-ID: <20100103114207.99032.qmail@cgisecurity.net>

The Web Application Security Consortium (WASC) is pleased to announce the long awaited release of the WASC 
Threat Classification v2.0. The Threat Classification is an effort to classify the weaknesses, and attacks 
that can lead to the compromise of a website, its data, or its users. This document's primarily purpose is 
to serve as a reference guide for common attacks and weaknesses.

Main goals
- Refine document scope, terminology, and purpose
- Update existing sections when applicable
- Add missing attacks and weaknesses
- Creation of a firm, scalable base foundation allowing for the introduction of data views allowing for various 
  forms of data representation
- Addition of attack and weakness reference identifiers (WASC-<xx>)
- Publication of two data views


WASC Threat Classification v2.0 Online
http://projects.webappsec.org/Threat-Classification

Using the Threat Classification
http://projects.webappsec.org/Using-the-Threat-Classification

Threat Classification Authors and Contributors
http://projects.webappsec.org/Threat-Classification-Authors

WASC Threat Classification FAQ
http://projects.webappsec.org/Threat-Classification-FAQ

WASC Reference Identifier Grid
http://projects.webappsec.org/Threat-Classification-Reference-Grid

Threat Classification Data Views
http://projects.webappsec.org/Threat-Classification-Views


We have already started scoping the next minor release of the Threat Classification, and are seeking contributors. 
If you are interested in participating in the next release of the WASC Threat Classification please contact us at
contact_at_ at webappsec.org with the subject 'WASC Threat Classification Contribution Inquiry'.

Questions can be directed to Robert Auger (contact_at_webappsec.org) with the subject 'WASC TC Inquiry'.


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:=20
http://www.webappsec.org/lists/websecurity/archive/


From yo at secappdev.org  Mon Jan  4 05:08:47 2010
From: yo at secappdev.org (Johan Peeters)
Date: Mon, 4 Jan 2010 11:08:47 +0100
Subject: [SC-L] Announcement SecAppDev 2010
Message-ID: <25b6e5cf1001040208t7ac00b69n8533c55ea51970ad@mail.gmail.com>

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

From list-spam at secureconsulting.net  Mon Jan  4 15:12:50 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 04 Jan 2010 15:12:50 -0500
Subject: [SC-L] seeking sponsors for SXSW Security BSides
Message-ID: <4B424BC2.3090002@secureconsulting.net>

Hi folks!

For those not familiar, a handful of security people kicked off an
unconference styled event during Black Hat this past July in Las Vegas
termed "Security BSides." The objective was to create a less formal
setting where top-notch security speakers/experts could have direct
conversations with people about topics of interest. The event was a huge
success. Please see http://www.securitybsides.com/ for more details.

Building on this success, a few more BSides events have started to
emerge. One such place where we hope to try this out as at SXSW
Interactive this coming March. Right now we are looking at hosting the
event on Saturday, March 13th. In keeping with the BSides tradition, the
idea is to find a venue that has adequate space for 100-200 people, as
well as lounge space to allow folks to hang out, chill out, socialize,
etc. In targeting SXSW, we're hoping to pull in attendees from the
conference (especially non-security developers, managers, etc.).

In order to make this happen, we need some help! We're looking for
sponsors (named or unnamed - up to you) to help underwrite the event.
BSides events do not charge attendees a fee in order to keep the format
and discussions open. Contributions of any size would be welcomed.
Support for past and future events includes monetary contributions,
materials, personnel, and transportation.

If you think you or your organization can help, please send email
directly to me (tomhave at secureconsulting.net) and we can get you more
information, discuss further, etc.

Thank you!

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"It's not whether you get knocked down, it's whether you get up."
Vince Lombardi

From ken at krvw.com  Tue Jan  5 09:59:13 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 5 Jan 2010 09:59:13 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security
	made simple ! | Core Security Patterns Weblog
Message-ID: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>

Happy new year SC-Lers.

FYI, interesting blog post on some of the new security features in Java EE 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.

http://www.coresecuritypatterns.com/blogs/?p=1622 


Cheers,

Ken

-----
Kenneth R. van Wyk
SC-L Moderator

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100105/93de97c5/attachment.bin>

From mparsons1980 at gmail.com  Tue Jan  5 15:30:00 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Tue, 5 Jan 2010 14:30:00 -0600
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
	Security	made simple ! | Core Security Patterns Weblog
In-Reply-To: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
Message-ID: <017201ca8e45$db4e4d70$91eae850$@com>

>From what I read it appears that this Java EE 6 could be a few rule
changers.   It looks like to me, java is checking for authorization and
authentication with this new framework.   If that is the case, I think that
static code analyzers could change their rule sets to check what normally is
a manual process in the code review of authentication and authorization.
Am I correct on my assumption?   

Thanks,
Matt


Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office 
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting






-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Kenneth Van Wyk
Sent: Tuesday, January 05, 2010 8:59 AM
To: Secure Coding
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security
made simple ! | Core Security Patterns Weblog

Happy new year SC-Lers.

FYI, interesting blog post on some of the new security features in Java EE
6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.

http://www.coresecuritypatterns.com/blogs/?p=1622 


Cheers,

Ken

-----
Kenneth R. van Wyk
SC-L Moderator



From coley at linus.mitre.org  Tue Jan  5 17:59:50 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 5 Jan 2010 17:59:50 -0500 (EST)
Subject: [SC-L] CWE/SANS Top 25 List - new for 2010
Message-ID: <Pine.GSO.4.64.1001051755390.28561@faron.mitre.org>


All,

At the risk of starting a flame war a month early: MITRE and SANS are 
going to release a new version of the Top 25 Most Dangerous Programming 
Errors (http://cwe.mitre.org/top25/).  The 2010 version will be released 
in about a month, but we are still welcoming any inputs.  I would be 
especially grateful for anyone who has quantitative data with respect to 
weaknesses or attacks, but that is not required.

Various improvements are planned to address a number of critiques of last 
year's effort.

If you are interested in contributing, please email me and Bob Martin 
(ramartin at mitre.org), and we will send you more information.


Thanks,

Steve Christey
CWE Technial Lead

From ken at krvw.com  Wed Jan  6 10:31:41 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 6 Jan 2010 10:31:41 -0500
Subject: [SC-L] FT.com / UK - 'Year 2010' software glitch hits German bank
	cards
Message-ID: <4F7DFB42-CB01-4CD9-9636-D7A4FEF19138@krvw.com>

Greetings SC-L,

There have been several reports in the last few days of various devices being hit with a so-called "year 2010" software glitch.  Several bank ATMs, mobile devices, etc., have reportedly been hit.  Below is a link to one such story.

My question for SC-L is: anyone here aware of the actual underlying software problems willing to share?  Source examples would be most appreciated.

http://www.ft.com/cms/s/0/00da0e24-fa63-11de-beed-00144feab49a.html?nclick_check=1 


Cheers,

Ken

-----
Kenneth R. van Wyk
SC-L Moderator

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100106/1cc345ab/attachment.bin>

From jim at manico.net  Wed Jan  6 16:36:09 2010
From: jim at manico.net (James Manico)
Date: Wed, 6 Jan 2010 16:36:09 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
	Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <017201ca8e45$db4e4d70$91eae850$@com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
Message-ID: <ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>

Hello Matt,

Java EE still has NO support for escaping and lots of other important
security areas. You need something like OWASP ESAPI to make a secure app
even remotely possible. I was once a Sun guy, and I'm very fond of Java and
Sun. But JavaEE 6 does very little to raise the bar when it comes to
Application Security.

- Jim

On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons <mparsons1980 at gmail.com> wrote:

> >From what I read it appears that this Java EE 6 could be a few rule
> changers.   It looks like to me, java is checking for authorization and
> authentication with this new framework.   If that is the case, I think that
> static code analyzers could change their rule sets to check what normally
> is
> a manual process in the code review of authentication and authorization.
> Am I correct on my assumption?
>
> Thanks,
> Matt
>
>
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
>
>
>
>
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Kenneth Van Wyk
> Sent: Tuesday, January 05, 2010 8:59 AM
> To: Secure Coding
> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security
> made simple ! | Core Security Patterns Weblog
>
> Happy new year SC-Lers.
>
> FYI, interesting blog post on some of the new security features in Java EE
> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
>
> http://www.coresecuritypatterns.com/blogs/?p=1622
>
>
> Cheers,
>
> Ken
>
> -----
> Kenneth R. van Wyk
> SC-L Moderator
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>



-- 
-- 
Jim Manico, Application Security Architect
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security?
Securing your applications at the source
http://www.aspectsecurity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100106/40c0954c/attachment.htm>

From jsteven at cigital.com  Wed Jan  6 18:20:43 2010
From: jsteven at cigital.com (John Steven)
Date: Wed, 6 Jan 2010 18:20:43 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web
	Application	Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
Message-ID: <8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>

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 and some dynamic patching because it's "in the app" (an argument made recently by others in the blogosphere).  

3) Top-to-Bottom Secure by Default - Declarative secure-by-default configuration of the hardened toolkit allows for securing those data flows that never make it out of the scaffolding into the app. If an organization wrote their own toolkit-unware security API, they'd have to not only assure their developers call it each-and-every place their it's needed but they'd also need to crack open the toolkits and make sure THEY call it too. Most of the time, one actively wants to avoid even having this visibility let along maintenance problem: it's a major headache.   

and, most importantly,

4) Less Integration points - Developers are already going to have to integrate against a MVC framework, so why force them to integrate against YA (yet-another) API? The MVC frameworks already contend with things like session management, input filtering, output-encoding, and authentication. Why not augment/improve that existing idiom rather than force developers to use it and an external security API?

The ESAPI team has plenty of responses to the last question... not the least of which is "...'cause [framework XXX] sucks." Fair. Out of the box, they often do. Fair, [framework team XXX] probably isn't listening to us security guys either. 

If you're an ESAPI shop--good. Careful adoption of a security API can help your security posture. Please remember to validate that the API (if you sucked in an external one rather than writing it) applies to your applications' threat model and ticks off all the elements of your security policy. Because, having hooked it into their apps, teams are going to want a fair amount of exoneration from normal processes (Some of which is OK, but a lot can be dangerous). Second, please make sure it's actually secure--it will be a fulcrum of your security controls' effectiveness. Make sure that assessment program proves your developers used it correctly, consistently, and thoroughly throughout their apps. What do I tell you about ESAPI and your MVC frameworks (Point #3 from above)? -sigh- That's a longer discussion. And, by all means, don't think you can let your guard down on your pen-testing. Is it a silver bullet? No. 

Is ESAPI the only approach? No. I submit that it's -A- way. I hope this email outlines that effectively. And viewed from a knowledgeable but separate perspective: the ESAPI approach has pluses and minuses just like all the others. 
 
----
John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.
 
(*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
(*2) During the AppSecDC summit, Jeff indicated the ESAPI project would later pilot SAMM but the global projects committee indicated that getting OWASP projects to follow some secure development touchpoints is too onerous/impossible. Dinis, I'll note is a huge proponent of adherence.


On Jan 6, 2010, at 4:36 PM, James Manico wrote:

> Hello Matt,
> 
> Java EE still has NO support for escaping and lots of other important security areas. You need something like OWASP ESAPI to make a secure app even remotely possible. I was once a Sun guy, and I'm very fond of Java and Sun. But JavaEE 6 does very little to raise the bar when it comes to Application Security.
> 
> - Jim
> 
> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons <mparsons1980 at gmail.com> wrote:
> >From what I read it appears that this Java EE 6 could be a few rule
> changers.   It looks like to me, java is checking for authorization and
> authentication with this new framework.   If that is the case, I think that
> static code analyzers could change their rule sets to check what normally is
> a manual process in the code review of authentication and authorization.
> Am I correct on my assumption?
> 
> Thanks,
> Matt
> 
> 
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Kenneth Van Wyk
> Sent: Tuesday, January 05, 2010 8:59 AM
> To: Secure Coding
> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security
> made simple ! | Core Security Patterns Weblog
> 
> Happy new year SC-Lers.
> 
> FYI, interesting blog post on some of the new security features in Java EE
> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
> 
> http://www.coresecuritypatterns.com/blogs/?p=1622
> 
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
> 
> 
> 
> -- 
> -- 
> Jim Manico, Application Security Architect
> jim.manico at aspectsecurity.com | jim at manico.net
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
> 
> Aspect Security?
> Securing your applications at the source
> http://www.aspectsecurity.com
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100106/0997ba0d/attachment.bin>

From ken at krvw.com  Thu Jan  7 09:45:22 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 7 Jan 2010 09:45:22 -0500
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian
Message-ID: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>

FYI, below is a link to an article with some additional impact details of the "2010 bug" that's been cropping up in various places.  Still no light being shed on the actual programming error, though.  I think it would make a fascinating case study, or at least discussion, here.

http://www.guardian.co.uk/world/2010/jan/06/2010-bug-millions-germans 


Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

(This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.)





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100107/03470902/attachment-0001.bin>

From jeremy.j.epstein at gmail.com  Thu Jan  7 10:11:05 2010
From: jeremy.j.epstein at gmail.com (Jeremy Epstein)
Date: Thu, 7 Jan 2010 10:11:05 -0500
Subject: [SC-L] "Checklist Manifesto" applicability to software security
Message-ID: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>

Greetings,

I was listening yesterday to an interview [1] on NPR with Dr. Atul
Gawande, author of "Checklist Manifesto" [2].  He describes the
problem that medical procedures (e.g., surgery) tend to have lots of
mistakes, mostly caused because of leaving out important steps.  He
claims that 2/3 of medical - or maybe surgical - errors can be avoided
by use of checklists.  Checklists aren't very popular among doctors,
because they don't like to see themselves as factory workers following
a procedure, because the human body is extremely complex, and because
every patient is unique.

So as I was listening, I was thinking that many of the same things
could be said about software developers and problems with software
security - every piece of software is unique, any non-trivial piece of
software is amazingly complex, developers tend to consider themselves
as artists creating unique works, etc.

Has anyone looked into the parallelisms before?  If so, I'd be
interested in chatting (probably offlist) about your thoughts.

--Jeremy

[1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280
[2] "The Checklist Manifesto: How to Get Things Right", Atul Gawande,
Metropolitan Books.

From brian at fortify.com  Thu Jan  7 10:49:33 2010
From: brian at fortify.com (Brian Chess)
Date: Thu, 07 Jan 2010 07:49:33 -0800
Subject: [SC-L] "Checklist Manifesto" applicability to software security
In-Reply-To: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
Message-ID: <C76B428D.1BEEB%brian@fortify.com>

I think it's a great analogy.  If you'd like to read more without ordering
the book, here's an article Gawande wrote for the New Yorker in 2007:

http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande

Brian

On 1/7/10 7:11 AM, "Jeremy Epstein" <jeremy.j.epstein at gmail.com> wrote:

> Greetings,
> 
> I was listening yesterday to an interview [1] on NPR with Dr. Atul
> Gawande, author of "Checklist Manifesto" [2].  He describes the
> problem that medical procedures (e.g., surgery) tend to have lots of
> mistakes, mostly caused because of leaving out important steps.  He
> claims that 2/3 of medical - or maybe surgical - errors can be avoided
> by use of checklists.  Checklists aren't very popular among doctors,
> because they don't like to see themselves as factory workers following
> a procedure, because the human body is extremely complex, and because
> every patient is unique.
> 
> So as I was listening, I was thinking that many of the same things
> could be said about software developers and problems with software
> security - every piece of software is unique, any non-trivial piece of
> software is amazingly complex, developers tend to consider themselves
> as artists creating unique works, etc.
> 
> Has anyone looked into the parallelisms before?  If so, I'd be
> interested in chatting (probably offlist) about your thoughts.
> 
> --Jeremy
> 
> [1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280
> [2] "The Checklist Manifesto: How to Get Things Right", Atul Gawande,
> Metropolitan Books.
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________


From list-spam at secureconsulting.net  Thu Jan  7 10:51:32 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Thu, 07 Jan 2010 10:51:32 -0500
Subject: [SC-L] "Checklist Manifesto" applicability to software security
In-Reply-To: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
References: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
Message-ID: <4B460304.6080208@secureconsulting.net>

I think there's lots of applicability. People - especially techies - cut
corners. The pressure is usually to get things done in a certain amount
of time, and then add on that people like to generally expend as little
energy as possible, and viola! you see the problem.

Of course, the flip side is that checklists in an area like IT can be
detrimental, too. PCI is a great example, where it never made a claim of
being comprehensive, yet is treated as such (and codified in State laws
for crying out loud), and then orgs still get hacked, leaving them to
wonder why the checklist didn't protect them.

Perhaps the key, then, is knowing that you need experience+procedures.
Procedures allow you to not screw up the mundane and routine, while
experience allows you to dynamically respond to issues that don't fit
the precise steps of the procedure. Part and parcel to this, then, is
needing to empower experienced professionals to be flexible and dynamic
in the vast of challenges rather than requiring them to rigidly adhere
to procedure in all instances.

Within appsec, QA and related security testing is probably a great
example. If all QA could be strictly proceduralized, then you could just
automate it all. However, testing doesn't always go as expected,
requiring a functioning brain to (hopefully) respond and adapt
accordingly. You probably need procedures for properly catching those
exceptions, but nonetheless, those procedures automatically create a
capacity for dynamic response.

Sorry, a bit rambly...

-ben

Jeremy Epstein wrote:
> Greetings,
> 
> I was listening yesterday to an interview [1] on NPR with Dr. Atul
> Gawande, author of "Checklist Manifesto" [2].  He describes the
> problem that medical procedures (e.g., surgery) tend to have lots of
> mistakes, mostly caused because of leaving out important steps.  He
> claims that 2/3 of medical - or maybe surgical - errors can be avoided
> by use of checklists.  Checklists aren't very popular among doctors,
> because they don't like to see themselves as factory workers following
> a procedure, because the human body is extremely complex, and because
> every patient is unique.
> 
> So as I was listening, I was thinking that many of the same things
> could be said about software developers and problems with software
> security - every piece of software is unique, any non-trivial piece of
> software is amazingly complex, developers tend to consider themselves
> as artists creating unique works, etc.
> 
> Has anyone looked into the parallelisms before?  If so, I'd be
> interested in chatting (probably offlist) about your thoughts.
> 
> --Jeremy
> 
> [1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280
> [2] "The Checklist Manifesto: How to Get Things Right", Atul Gawande,
> Metropolitan Books.
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Pareto Principle (a.k.a. ?The 80-20 Rule?): "For many phenomena, 80% of
consequences stem from 20% of the causes."
http://globalnerdy.com/2007/07/18/laws-of-software-development/

From jim at manico.net  Thu Jan  7 10:56:17 2010
From: jim at manico.net (Jim Manico)
Date: Thu, 7 Jan 2010 10:56:17 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web
	Application	Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
Message-ID: <1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>

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 <jsteven at 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 and some dynamic patching because it's "in the  
> app" (an argument made recently by others in the blogosphere).
>
> 3) Top-to-Bottom Secure by Default - Declarative secure-by-default  
> configuration of the hardened toolkit allows for securing those data  
> flows that never make it out of the scaffolding into the app. If an  
> organization wrote their own toolkit-unware security API, they'd  
> have to not only assure their developers call it each-and-every  
> place their it's needed but they'd also need to crack open the  
> toolkits and make sure THEY call it too. Most of the time, one  
> actively wants to avoid even having this visibility let along  
> maintenance problem: it's a major headache.
>
> and, most importantly,
>
> 4) Less Integration points - Developers are already going to have to  
> integrate against a MVC framework, so why force them to integrate  
> against YA (yet-another) API? The MVC frameworks already contend  
> with things like session management, input filtering, output- 
> encoding, and authentication. Why not augment/improve that existing  
> idiom rather than force developers to use it and an external  
> security API?
>
> The ESAPI team has plenty of responses to the last question... not  
> the least of which is "...'cause [framework XXX] sucks." Fair. Out  
> of the box, they often do. Fair, [framework team XXX] probably isn't  
> listening to us security guys either.
>
> If you're an ESAPI shop--good. Careful adoption of a security API  
> can help your security posture. Please remember to validate that the  
> API (if you sucked in an external one rather than writing it)  
> applies to your applications' threat model and ticks off all the  
> elements of your security policy. Because, having hooked it into  
> their apps, teams are going to want a fair amount of exoneration  
> from normal processes (Some of which is OK, but a lot can be  
> dangerous). Second, please make sure it's actually secure--it will  
> be a fulcrum of your security controls' effectiveness. Make sure  
> that assessment program proves your developers used it correctly,  
> consistently, and thoroughly throughout their apps. What do I tell  
> you about ESAPI and your MVC frameworks (Point #3 from above)? - 
> sigh- That's a longer discussion. And, by all means, don't think you  
> can let your guard down on your pen-testing. Is it a silver bullet?  
> No.
>
> Is ESAPI the only approach? No. I submit that it's -A- way. I hope  
> this email outlines that effectively. And viewed from a  
> knowledgeable but separate perspective: the ESAPI approach has  
> pluses and minuses just like all the others.
>
> ----
> John Steven
> Senior Director; Advanced Technology Consulting
> Desk: 703.404.9293 x1204 Cell: 703.727.4034
> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>
> Blog: http://www.cigital.com/justiceleague
> Papers: http://www.cigital.com/papers/jsteven
> http://www.cigital.com
> Software Confidence. Achieved.
>
> (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
> (*2) During the AppSecDC summit, Jeff indicated the ESAPI project  
> would later pilot SAMM but the global projects committee indicated  
> that getting OWASP projects to follow some secure development  
> touchpoints is too onerous/impossible. Dinis, I'll note is a huge  
> proponent of adherence.
>
>
> On Jan 6, 2010, at 4:36 PM, James Manico wrote:
>
>> Hello Matt,
>>
>> Java EE still has NO support for escaping and lots of other  
>> important security areas. You need something like OWASP ESAPI to  
>> make a secure app even remotely possible. I was once a Sun guy, and  
>> I'm very fond of Java and Sun. But JavaEE 6 does very little to  
>> raise the bar when it comes to Application Security.
>>
>> - Jim
>>
>> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons  
>> <mparsons1980 at gmail.com> wrote:
>>> From what I read it appears that this Java EE 6 could be a few rule
>> changers.   It looks like to me, java is checking for authorization  
>> and
>> authentication with this new framework.   If that is the case, I  
>> think that
>> static code analyzers could change their rule sets to check what  
>> normally is
>> a manual process in the code review of authentication and  
>> authorization.
>> Am I correct on my assumption?
>>
>> Thanks,
>> Matt
>>
>>
>> Matt Parsons, MSM, CISSP
>> 315-559-3588 Blackberry
>> 817-294-3789 Home office
>> mailto:mparsons1980 at gmail.com
>> http://www.parsonsisconsulting.com
>> http://www.o2-ounceopen.com/o2-power-users/
>> http://www.linkedin.com/in/parsonsconsulting
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: sc-l-bounces at securecoding.org [mailto:sc-l- 
>> bounces at securecoding.org]
>> On Behalf Of Kenneth Van Wyk
>> Sent: Tuesday, January 05, 2010 8:59 AM
>> To: Secure Coding
>> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application  
>> Security
>> made simple ! | Core Security Patterns Weblog
>>
>> Happy new year SC-Lers.
>>
>> FYI, interesting blog post on some of the new security features in  
>> Java EE
>> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
>>
>> http://www.coresecuritypatterns.com/blogs/?p=1622
>>
>>
>> Cheers,
>>
>> Ken
>>
>> -----
>> Kenneth R. van Wyk
>> SC-L Moderator
>>
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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.
>> _______________________________________________
>>
>>
>>
>> -- 
>> -- 
>> Jim Manico, Application Security Architect
>> jim.manico at aspectsecurity.com | jim at manico.net
>> (301) 604-4882 (work)
>> (808) 652-3805 (cell)
>>
>> Aspect Security?
>> Securing your applications at the source
>> http://www.aspectsecurity.com
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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 at 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.
> _______________________________________________


From stephencraig.evans at gmail.com  Thu Jan  7 11:43:52 2010
From: stephencraig.evans at gmail.com (Stephen Craig Evans)
Date: Thu, 7 Jan 2010 10:43:52 -0600
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
	Guardian
In-Reply-To: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
Message-ID: <930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>

Hi Ken,

Looks like there's another one:

Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager
http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bug-Hits-Endpoint-Protection-Manager-472518/?kc=EWKNLSTE01072010STR1

I am VERY curious to learn how these happened... Only using the last
digit of the year? Hard for me to believe. Maybe it's in a single API
and somebody tried to be too clever with some bit-shifting.

Stephen

-- 
http://www.linkedin.com/in/stephencraigevans

On Thu, Jan 7, 2010 at 8:45 AM, Kenneth Van Wyk <ken at krvw.com> wrote:
> FYI, below is a link to an article with some additional impact details of the "2010 bug" that's been cropping up in various places. ?Still no light being shed on the actual programming error, though. ?I think it would make a fascinating case study, or at least discussion, here.
>
> http://www.guardian.co.uk/world/2010/jan/06/2010-bug-millions-germans
>
>
> Cheers,
>
> Ken
>
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
>
> (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.)
>
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>
>


From jsteven at cigital.com  Thu Jan  7 13:02:35 2010
From: jsteven at cigital.com (John Steven)
Date: Thu, 7 Jan 2010 13:02:35 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web
	Application	Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
Message-ID: <B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>

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 in production without risk/regression?

* Generate an argument as to why ESAPI beats these alternatives. Is it cost? Speed-to-market? What?
* Finally, realize that it's OK that there's more than one way to do things. Revel in it. It's what makes software an exciting field. 

In the meantime, rest assured that those of us out there that have looked get that ESAPI can be a good thing.

----
John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.

On Jan 7, 2010, at 10:56 AM, Jim Manico wrote:

> 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 <jsteven at 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 and some dynamic patching because it's "in the  
>> app" (an argument made recently by others in the blogosphere).
>> 
>> 3) Top-to-Bottom Secure by Default - Declarative secure-by-default  
>> configuration of the hardened toolkit allows for securing those data  
>> flows that never make it out of the scaffolding into the app. If an  
>> organization wrote their own toolkit-unware security API, they'd  
>> have to not only assure their developers call it each-and-every  
>> place their it's needed but they'd also need to crack open the  
>> toolkits and make sure THEY call it too. Most of the time, one  
>> actively wants to avoid even having this visibility let along  
>> maintenance problem: it's a major headache.
>> 
>> and, most importantly,
>> 
>> 4) Less Integration points - Developers are already going to have to  
>> integrate against a MVC framework, so why force them to integrate  
>> against YA (yet-another) API? The MVC frameworks already contend  
>> with things like session management, input filtering, output- 
>> encoding, and authentication. Why not augment/improve that existing  
>> idiom rather than force developers to use it and an external  
>> security API?
>> 
>> The ESAPI team has plenty of responses to the last question... not  
>> the least of which is "...'cause [framework XXX] sucks." Fair. Out  
>> of the box, they often do. Fair, [framework team XXX] probably isn't  
>> listening to us security guys either.
>> 
>> If you're an ESAPI shop--good. Careful adoption of a security API  
>> can help your security posture. Please remember to validate that the  
>> API (if you sucked in an external one rather than writing it)  
>> applies to your applications' threat model and ticks off all the  
>> elements of your security policy. Because, having hooked it into  
>> their apps, teams are going to want a fair amount of exoneration  
>> from normal processes (Some of which is OK, but a lot can be  
>> dangerous). Second, please make sure it's actually secure--it will  
>> be a fulcrum of your security controls' effectiveness. Make sure  
>> that assessment program proves your developers used it correctly,  
>> consistently, and thoroughly throughout their apps. What do I tell  
>> you about ESAPI and your MVC frameworks (Point #3 from above)? - 
>> sigh- That's a longer discussion. And, by all means, don't think you  
>> can let your guard down on your pen-testing. Is it a silver bullet?  
>> No.
>> 
>> Is ESAPI the only approach? No. I submit that it's -A- way. I hope  
>> this email outlines that effectively. And viewed from a  
>> knowledgeable but separate perspective: the ESAPI approach has  
>> pluses and minuses just like all the others.
>> 
>> ----
>> John Steven
>> Senior Director; Advanced Technology Consulting
>> Desk: 703.404.9293 x1204 Cell: 703.727.4034
>> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>> 
>> Blog: http://www.cigital.com/justiceleague
>> Papers: http://www.cigital.com/papers/jsteven
>> http://www.cigital.com
>> Software Confidence. Achieved.
>> 
>> (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
>> (*2) During the AppSecDC summit, Jeff indicated the ESAPI project  
>> would later pilot SAMM but the global projects committee indicated  
>> that getting OWASP projects to follow some secure development  
>> touchpoints is too onerous/impossible. Dinis, I'll note is a huge  
>> proponent of adherence.
>> 
>> 
>> On Jan 6, 2010, at 4:36 PM, James Manico wrote:
>> 
>>> Hello Matt,
>>> 
>>> Java EE still has NO support for escaping and lots of other  
>>> important security areas. You need something like OWASP ESAPI to  
>>> make a secure app even remotely possible. I was once a Sun guy, and  
>>> I'm very fond of Java and Sun. But JavaEE 6 does very little to  
>>> raise the bar when it comes to Application Security.
>>> 
>>> - Jim
>>> 
>>> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons  
>>> <mparsons1980 at gmail.com> wrote:
>>>> From what I read it appears that this Java EE 6 could be a few rule
>>> changers.   It looks like to me, java is checking for authorization  
>>> and
>>> authentication with this new framework.   If that is the case, I  
>>> think that
>>> static code analyzers could change their rule sets to check what  
>>> normally is
>>> a manual process in the code review of authentication and  
>>> authorization.
>>> Am I correct on my assumption?
>>> 
>>> Thanks,
>>> Matt
>>> 
>>> 
>>> Matt Parsons, MSM, CISSP
>>> 315-559-3588 Blackberry
>>> 817-294-3789 Home office
>>> mailto:mparsons1980 at gmail.com
>>> http://www.parsonsisconsulting.com
>>> http://www.o2-ounceopen.com/o2-power-users/
>>> http://www.linkedin.com/in/parsonsconsulting
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: sc-l-bounces at securecoding.org [mailto:sc-l- 
>>> bounces at securecoding.org]
>>> On Behalf Of Kenneth Van Wyk
>>> Sent: Tuesday, January 05, 2010 8:59 AM
>>> To: Secure Coding
>>> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application  
>>> Security
>>> made simple ! | Core Security Patterns Weblog
>>> 
>>> Happy new year SC-Lers.
>>> 
>>> FYI, interesting blog post on some of the new security features in  
>>> Java EE
>>> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
>>> 
>>> http://www.coresecuritypatterns.com/blogs/?p=1622
>>> 
>>> 
>>> Cheers,
>>> 
>>> Ken
>>> 
>>> -----
>>> Kenneth R. van Wyk
>>> SC-L Moderator
>>> 
>>> 
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L at 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.
>>> _______________________________________________
>>> 
>>> 
>>> 
>>> -- 
>>> -- 
>>> Jim Manico, Application Security Architect
>>> jim.manico at aspectsecurity.com | jim at manico.net
>>> (301) 604-4882 (work)
>>> (808) 652-3805 (cell)
>>> 
>>> Aspect Security?
>>> Securing your applications at the source
>>> http://www.aspectsecurity.com
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L at 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 at 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.
>> _______________________________________________


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100107/3adfb37c/attachment.bin>

From steingra at gmail.com  Thu Jan  7 12:19:14 2010
From: steingra at gmail.com (Andy Steingruebl)
Date: Thu, 7 Jan 2010 09:19:14 -0800
Subject: [SC-L] "Checklist Manifesto" applicability to software security
In-Reply-To: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
References: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
Message-ID: <490a979e1001070919r5ccaae79rf7d344914889bbd3@mail.gmail.com>

On Thu, Jan 7, 2010 at 7:11 AM, Jeremy Epstein
<jeremy.j.epstein at gmail.com> wrote:
> Greetings,
>
> So as I was listening, I was thinking that many of the same things
> could be said about software developers and problems with software
> security - every piece of software is unique, any non-trivial piece of
> software is amazingly complex, developers tend to consider themselves
> as artists creating unique works, etc.
>
> Has anyone looked into the parallelisms before? ?If so, I'd be
> interested in chatting (probably offlist) about your thoughts.

I've had exceptionally good luck/results from checklists during the
development process, though nothing I could scientifically quantify.

That said, I wonder whether any of the academics on the list would be
willing to actually do a study.  Do some actual trials on defect rates
in things like student assignments when they have some students go
through a checklist to examine their code, and others not.  Might be
interesting to see exactly what types of checklist items really result
in a reduction in bugs...

-- 
Andy Steingruebl
steingra at gmail.com


From boberski_michael at bah.com  Thu Jan  7 12:38:47 2010
From: boberski_michael at bah.com (Boberski, Michael [USA])
Date: Thu, 7 Jan 2010 12:38:47 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6:
	Web	Application	Security made simple ! | Core Security
	Patterns Weblog
In-Reply-To: <1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
Message-ID: <21D3693DA55EF14BB72DCC18FB65B29102336DA1FB@ASHBMBX04.resource.ds.bah.com>

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-bounces at securecoding.org [mailto:sc-l-bounces at 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 <jsteven at 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 and 
> some dynamic patching because it's "in the app" (an argument made 
> recently by others in the blogosphere).
>
> 3) Top-to-Bottom Secure by Default - Declarative secure-by-default 
> configuration of the hardened toolkit allows for securing those data 
> flows that never make it out of the scaffolding into the app. If an 
> organization wrote their own toolkit-unware security API, they'd have 
> to not only assure their developers call it each-and-every place their 
> it's needed but they'd also need to crack open the toolkits and make 
> sure THEY call it too. Most of the time, one actively wants to avoid 
> even having this visibility let along maintenance problem: it's a 
> major headache.
>
> and, most importantly,
>
> 4) Less Integration points - Developers are already going to have to 
> integrate against a MVC framework, so why force them to integrate 
> against YA (yet-another) API? The MVC frameworks already contend with 
> things like session management, input filtering, output- encoding, and 
> authentication. Why not augment/improve that existing idiom rather 
> than force developers to use it and an external security API?
>
> The ESAPI team has plenty of responses to the last question... not the 
> least of which is "...'cause [framework XXX] sucks." Fair. Out of the 
> box, they often do. Fair, [framework team XXX] probably isn't 
> listening to us security guys either.
>
> If you're an ESAPI shop--good. Careful adoption of a security API can 
> help your security posture. Please remember to validate that the API 
> (if you sucked in an external one rather than writing it) applies to 
> your applications' threat model and ticks off all the elements of your 
> security policy. Because, having hooked it into their apps, teams are 
> going to want a fair amount of exoneration from normal processes (Some 
> of which is OK, but a lot can be dangerous). Second, please make sure 
> it's actually secure--it will be a fulcrum of your security controls' 
> effectiveness. Make sure that assessment program proves your 
> developers used it correctly, consistently, and thoroughly throughout 
> their apps. What do I tell you about ESAPI and your MVC frameworks 
> (Point #3 from above)? -
> sigh- That's a longer discussion. And, by all means, don't think you 
> can let your guard down on your pen-testing. Is it a silver bullet?
> No.
>
> Is ESAPI the only approach? No. I submit that it's -A- way. I hope 
> this email outlines that effectively. And viewed from a knowledgeable 
> but separate perspective: the ESAPI approach has pluses and minuses 
> just like all the others.
>
> ----
> John Steven
> Senior Director; Advanced Technology Consulting
> Desk: 703.404.9293 x1204 Cell: 703.727.4034 Key fingerprint = 4772 
> F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>
> Blog: http://www.cigital.com/justiceleague
> Papers: http://www.cigital.com/papers/jsteven
> http://www.cigital.com
> Software Confidence. Achieved.
>
> (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
> (*2) During the AppSecDC summit, Jeff indicated the ESAPI project 
> would later pilot SAMM but the global projects committee indicated 
> that getting OWASP projects to follow some secure development 
> touchpoints is too onerous/impossible. Dinis, I'll note is a huge 
> proponent of adherence.
>
>
> On Jan 6, 2010, at 4:36 PM, James Manico wrote:
>
>> Hello Matt,
>>
>> Java EE still has NO support for escaping and lots of other important 
>> security areas. You need something like OWASP ESAPI to make a secure 
>> app even remotely possible. I was once a Sun guy, and I'm very fond 
>> of Java and Sun. But JavaEE 6 does very little to raise the bar when 
>> it comes to Application Security.
>>
>> - Jim
>>
>> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons <mparsons1980 at gmail.com> 
>> wrote:
>>> From what I read it appears that this Java EE 6 could be a few rule
>> changers.   It looks like to me, java is checking for authorization  
>> and
>> authentication with this new framework.   If that is the case, I  
>> think that
>> static code analyzers could change their rule sets to check what 
>> normally is a manual process in the code review of authentication and 
>> authorization.
>> Am I correct on my assumption?
>>
>> Thanks,
>> Matt
>>
>>
>> Matt Parsons, MSM, CISSP
>> 315-559-3588 Blackberry
>> 817-294-3789 Home office
>> mailto:mparsons1980 at gmail.com
>> http://www.parsonsisconsulting.com
>> http://www.o2-ounceopen.com/o2-power-users/
>> http://www.linkedin.com/in/parsonsconsulting
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: sc-l-bounces at securecoding.org [mailto:sc-l- 
>> bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
>> Sent: Tuesday, January 05, 2010 8:59 AM
>> To: Secure Coding
>> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application 
>> Security made simple ! | Core Security Patterns Weblog
>>
>> Happy new year SC-Lers.
>>
>> FYI, interesting blog post on some of the new security features in 
>> Java EE 6, by Ramesh Nagappan.  Worth reading for all you Java folk, 
>> IMHO.
>>
>> http://www.coresecuritypatterns.com/blogs/?p=1622
>>
>>
>> Cheers,
>>
>> Ken
>>
>> -----
>> Kenneth R. van Wyk
>> SC-L Moderator
>>
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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.
>> _______________________________________________
>>
>>
>>
>> --
>> --
>> Jim Manico, Application Security Architect 
>> jim.manico at aspectsecurity.com | jim at manico.net
>> (301) 604-4882 (work)
>> (808) 652-3805 (cell)
>>
>> Aspect Security(tm)
>> Securing your applications at the source 
>> http://www.aspectsecurity.com 
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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 at 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 at 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.
_______________________________________________


From john.wilander at owasp.org  Thu Jan  7 13:50:09 2010
From: john.wilander at owasp.org (John Wilander)
Date: Thu, 7 Jan 2010 19:50:09 +0100
Subject: [SC-L] "Checklist Manifesto" applicability to software security
In-Reply-To: <4B460304.6080208@secureconsulting.net>
References: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
	<4B460304.6080208@secureconsulting.net>
Message-ID: <5cd1beb91001071050n45916bbep8f6ba5ce93411683@mail.gmail.com>

This is a question of great interest to me. Thanks for the links Jeremy and
Brian.

Atul Gawande points it out nicely in the interview: "The problem [for you as
an expert] is that the volume of knowledge exceeds the capacity of your
brain." When I give talks or training on software security I always include
a section on complexity. I'll give you the key points I usually cover ...


*** A. Complexity in software has five dimensions ***

1. Scale. More code means higher complexity. This is often hard to avoid
although code refactoring can reduce the code mass somewhat.

2. Diversity. The number of technologies, frameworks, languages, versions,
and even varying coding conventions -- they all drive complexity. This can
be handled with policies but developers often oppose a strict list of what
to use and what not.

3. Connectivity. On code level it's about coupling and cohesion. On a
systems level it's about architecture. Even higher it's about
interconnecting systems and services, perhaps cross-organization. In the
server room it boils down to cables. High connectivity means high
complexity. This too can be handled, but lack of communication between
people is often an obstacle. I've been to customers who were convinced for
years that their test system and production system were completely
separated. Then they changed outsourcing partner and discovered the truth.

4. Dynamics. Could the system even be described in a state diagram? On any
reasonable level? As the number of states the system can be grows, so does
its complexity. I'm not sure if we have the tools or skills to manage
software dynamics. Yet.

5. Refinement. Over time software get refined. If you go to a large bank and
check out their core systems you'll find years and years of refinement.
Understanding why things are done the way they are in a highly refined
product is complex. This kind of complexity can be lowered through
documentation, but not avoided.

I've attached the picture I use to explain these dimensions. Not a product
of art but it works :).


*** B. Be aware of the Complexity Barrier ***

The testing guru Boris Beizer has founded two interesting laws regarding
software bugs, testing, and complexity:

First law: The pesticide paradox. Every method you use to prevent or find
bugs leaves a residue of subtler bugs against which those methods are
ineffective.

Second law: The complexity barrier. Software complexity (and therefore that
of bugs) grows to the limits of our ability to manage that complexity.

I find the complexity barrier to be very interesting. We're not trying to
build the ultimate Notepad.exe over and over again (someone should though).
Instead we're diving headfirst into Rich Internet Applications as soon as
it's possible. That's human nature.


*** C. We need computers to analyze computers ***

The complexity of the systems we build is so big that we nowadays need
computers and software to understand them. This is where checklists come in.
We do use checklists all the time in the form of static analysis, both in
compilers and in tools. That's where many of our (low-level) checklists
belong. But we have to get developers to use them.


   Regards, John Wilander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100107/238f8b1d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: john_wilander_complexity_in_5_dimensions.png
Type: image/png
Size: 210022 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100107/238f8b1d/attachment-0001.png>

From ljknews at mac.com  Thu Jan  7 11:38:31 2010
From: ljknews at mac.com (ljknews)
Date: Thu, 07 Jan 2010 12:38:31 -0400
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
 Guardian
In-Reply-To: <930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
	<930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
Message-ID: <p05200f79c76bbd8ca0b2@[146.115.107.213]>

At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote:

> I am VERY curious to learn how these happened... Only using the last
> digit of the year? Hard for me to believe. Maybe it's in a single API
> and somebody tried to be too clever with some bit-shifting.

My wife says that in the lead-up to the year 2000 she caught
some programmers "fixing" Y2K bugs by continuing to store
year numbers in two digits and then just prefixing output
with 19 if the value was greater than some two digit number
and prefixing output with 20 if the value was less than or
equal to that two digit number.

Never underestimate programmer creativity.

Never overestimate programmer precision.
-- 
Larry Kilgallen

From coley at linus.mitre.org  Thu Jan  7 12:57:27 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 7 Jan 2010 12:57:27 -0500 (EST)
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
 Guardian
In-Reply-To: <930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
	<930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.1001071239450.28556@faron.mitre.org>


On Thu, 7 Jan 2010, Stephen Craig Evans wrote:

> I am VERY curious to learn how these happened...

My name is Steve.  I had a 2010 problem.

An internal CVE support program was "hit" by this issue.  Fortunately, 
there weren't any fatal results and it was only an annoyance.  However: I 
had an input validation routine that did a sanity-check on dates, which I 
wrote sometime around 2005.  The check would generate a specific complaint 
if a date was 2010 or later since, after all, it was 2005 - a time when 
resources for development were extremely low - and it worked back then. 
(Now I'm starting to rationalize that all my bad practices back then were 
"Agile" instead of "cheap hacks."  Yes, that was deliberately 
inflammatory.)

The regexp to check the year was something like /^(199\d|200\d)$/, and the 
informative error message would say that the year portion of the date 
appeared to be invalid.  There was a separate check that also made sure 
that a given date wasn't in the future, so this message was basically a 
secondary bit of detail.

Anyway, 5 years passed and I forgot about the limitation of that routine 
until it started generating informational error messages when CVE team 
members submitted new CVE content.

One could say that this was under the radar of my threat model when it 
should have been part of the threat model for these major vendors, but it 
was still a known bug/feature that never got fixed until it had to be 
fixed.

I'm sure I have a few other date-sensitive dependencies that are not a 
high priority to fix, given current conditions and practices. I'll 
probably be close to retirement age come 2038 when the Unix year bug shows 
up.  If CVE is still around then, and my code is still being used, well, 
it's gonna be someone else's problem.

Anybody else willing to admit their 2010 mistakes and the conditions that 
led to them?  Or was it just me and a couple huge companies?

- Steve

From Kevin.Wall at qwest.com  Thu Jan  7 14:03:36 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Thu, 7 Jan 2010 13:03:36 -0600
Subject: [SC-L] 2010 bug hits millions of Germans | World news |
	The	Guardian
In-Reply-To: <930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
	<930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD322A51822D@qtomaexmbm22.AD.QINTRA.COM>

Stephen Craig Evans wrote...

> Looks like there's another one:
>
> Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager
> http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bu
g-Hits-Endpoint-Protection-Manager-472518/?> kc=EWKNLSTE01072010STR1
>
> I am VERY curious to learn how these happened... Only using the last
> digit of the year? Hard for me to believe. Maybe it's in a single API
> and somebody tried to be too clever with some bit-shifting.

Just speculation, but perhaps all these systems are using the "fixed window"
technique to address these two digit year fields common on credit cards.
Depending on the "pivot point" year that is chosen determines whether
a 2 digit year field belongs to one century or the other. This could
just be a carry over from the Y2K fixes and the rather poor choice for
a pivot point. I worked next to a person who did some Y2K fixes for
lots of mainframes back in 1998-99, and he said that using 'windowing'
to address this was a pretty common technique because companies did not
want to expand all their databases and forms, etc. to allow for 4 digits.

For example, if 1980 was chosen as the pivot year, then 2 digit years
80 through 99 would be assigned '1900' as the century and 00 through 79
would be assigned '2000' as the century. So perhaps 1910 was chosen as
the pivot year (if DOB was a consideration, that would not be all that
unreasonable) so that 10 through 99 is interpreted as 1900s and
00 through 09 was considered as 2000 something. So we hit 2010 and
a credit card has a 2 digit year for it's expiration or transaction
date or whatever, and all of a sudden 01/10 or 01/07/10 is interpreted
as 1910.

Usually using such a fixed windowing technique (there is also a sliding
window technique that was a more expensive "fix") was only considered a
stop-gap measure with most organizations fixing things for real before
the pivot year gave them trouble. But we all know about how good intentions
work...or not.

Anyhow, like I said, this is only a GUESS of what might be going on. I have
no hard data to back it up.

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From gem at cigital.com  Thu Jan  7 15:17:20 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 7 Jan 2010 15:17:20 -0500
Subject: [SC-L] "Checklist Manifesto" applicability to software security
In-Reply-To: <ec51a3571001070711y52e15dfeu8099ee158039cee9@mail.gmail.com>
Message-ID: <C76BAB80.1D088%gem@cigital.com>

hi sc-l,

I am pretty sure that Brian Chess used to have this in his standard talk some many years ago.  Then again I am getting old.

Great analogy.  Note that checklists DO NOT take the place of the intensive care staff!

gem


On 1/7/10 10:11 AM, "Jeremy Epstein" <jeremy.j.epstein at gmail.com> wrote:

Greetings,

I was listening yesterday to an interview [1] on NPR with Dr. Atul
Gawande, author of "Checklist Manifesto" [2].  He describes the
problem that medical procedures (e.g., surgery) tend to have lots of
mistakes, mostly caused because of leaving out important steps.  He
claims that 2/3 of medical - or maybe surgical - errors can be avoided
by use of checklists.  Checklists aren't very popular among doctors,
because they don't like to see themselves as factory workers following
a procedure, because the human body is extremely complex, and because
every patient is unique.

So as I was listening, I was thinking that many of the same things
could be said about software developers and problems with software
security - every piece of software is unique, any non-trivial piece of
software is amazingly complex, developers tend to consider themselves
as artists creating unique works, etc.

Has anyone looked into the parallelisms before?  If so, I'd be
interested in chatting (probably offlist) about your thoughts.

--Jeremy

[1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280
[2] "The Checklist Manifesto: How to Get Things Right", Atul Gawande,
Metropolitan Books.
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________



From Kevin.Wall at qwest.com  Thu Jan  7 15:37:12 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Thu, 7 Jan 2010 14:37:12 -0600
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
 Guardian
In-Reply-To: <p05200f79c76bbd8ca0b2@[146.115.107.213]>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
	<930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
	<p05200f79c76bbd8ca0b2@[146.115.107.213]>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD322A518238@qtomaexmbm22.AD.QINTRA.COM>

Larry Kilgallen wrote...

> At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote:
>
> > I am VERY curious to learn how these happened... Only using the last
> > digit of the year? Hard for me to believe. Maybe it's in a
> single API
> > and somebody tried to be too clever with some bit-shifting.
>
> My wife says that in the lead-up to the year 2000 she caught
> some programmers "fixing" Y2K bugs by continuing to store
> year numbers in two digits and then just prefixing output
> with 19 if the value was greater than some two digit number
> and prefixing output with 20 if the value was less than or
> equal to that two digit number.
>
> Never underestimate programmer creativity.
>
> Never overestimate programmer precision.

While I never fixed any Y2K problems I worked next to someone
who did for about 6 months. What you refer to is pretty much what
I mentioned as the "fixed window" technique that was very common
to those developers who were addressing the problems at the time.

IIRC, it was a particularly popular approach for those who waited until
the last moment to address Y2K issues in there systems because it still
allowed for 2 digit year fields in all their forms and databases and output.

---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From ljknews at mac.com  Thu Jan  7 15:02:38 2010
From: ljknews at mac.com (ljknews)
Date: Thu, 07 Jan 2010 16:02:38 -0400
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
 Guardian
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD322A518238@qtomaexmbm22.AD.QINTRA.COM>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
	<930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
	<p05200f79c76bbd8ca0b2@[146.115.107.213]>
	<B8E4274903E6F64E8F9E5C21A96D83BD322A518238@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <p05200f7ac76beccdbaaa@[146.115.107.213]>

At 2:37 PM -0600 1/7/10, Wall, Kevin wrote:
> Larry Kilgallen wrote...
> 
>> At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote:
>>
>> > I am VERY curious to learn how these happened... Only using the last
>> > digit of the year? Hard for me to believe. Maybe it's in a
>> single API
>> > and somebody tried to be too clever with some bit-shifting.
>>
>> My wife says that in the lead-up to the year 2000 she caught
>> some programmers "fixing" Y2K bugs by continuing to store
>> year numbers in two digits and then just prefixing output
>> with 19 if the value was greater than some two digit number
>> and prefixing output with 20 if the value was less than or
>> equal to that two digit number.
>>
>> Never underestimate programmer creativity.
>>
>> Never overestimate programmer precision.
> 
> While I never fixed any Y2K problems I worked next to someone
> who did for about 6 months. What you refer to is pretty much what
> I mentioned as the "fixed window" technique that was very common
> to those developers who were addressing the problems at the time.
> 
> IIRC, it was a particularly popular approach for those who waited until
> the last moment to address Y2K issues in there systems because it still
> allowed for 2 digit year fields in all their forms and databases and output.

Going back to the original Y2K issue, within the past 5 years
my wife and I visited a friend of my late father.  This friend
had retired as somewhat of a bigwig at an industrial giant that
formerly was in the business of manufacturing their own line of
computers.  He admitted that "back in the day" they had set up
things to use two digits for storing year numbers, knowing that
before the year 2000 came around, _they_ would all be retired.
-- 
Larry Kilgallen

From boberski_michael at bah.com  Thu Jan  7 16:24:38 2010
From: boberski_michael at bah.com (Boberski, Michael [USA])
Date: Thu, 7 Jan 2010 16:24:38 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6:
	Web	Application	Security made simple ! | Core Security
	Patterns Weblog
In-Reply-To: <B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
	<B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>
Message-ID: <21D3693DA55EF14BB72DCC18FB65B29102336DA2F7@ASHBMBX04.resource.ds.bah.com>

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-bounces at securecoding.org [mailto:sc-l-bounces at 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 in production without risk/regression?

* Generate an argument as to why ESAPI beats these alternatives. Is it cost? Speed-to-market? What?
* Finally, realize that it's OK that there's more than one way to do things. Revel in it. It's what makes software an exciting field.

In the meantime, rest assured that those of us out there that have looked get that ESAPI can be a good thing.

----
John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034 Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.

On Jan 7, 2010, at 10:56 AM, Jim Manico wrote:

> 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 <jsteven at 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 and
>> some dynamic patching because it's "in the app" (an argument made
>> recently by others in the blogosphere).
>>
>> 3) Top-to-Bottom Secure by Default - Declarative secure-by-default
>> configuration of the hardened toolkit allows for securing those data
>> flows that never make it out of the scaffolding into the app. If an
>> organization wrote their own toolkit-unware security API, they'd have
>> to not only assure their developers call it each-and-every place
>> their it's needed but they'd also need to crack open the toolkits and
>> make sure THEY call it too. Most of the time, one actively wants to
>> avoid even having this visibility let along maintenance problem: it's
>> a major headache.
>>
>> and, most importantly,
>>
>> 4) Less Integration points - Developers are already going to have to
>> integrate against a MVC framework, so why force them to integrate
>> against YA (yet-another) API? The MVC frameworks already contend with
>> things like session management, input filtering, output- encoding,
>> and authentication. Why not augment/improve that existing idiom
>> rather than force developers to use it and an external security API?
>>
>> The ESAPI team has plenty of responses to the last question... not
>> the least of which is "...'cause [framework XXX] sucks." Fair. Out of
>> the box, they often do. Fair, [framework team XXX] probably isn't
>> listening to us security guys either.
>>
>> If you're an ESAPI shop--good. Careful adoption of a security API can
>> help your security posture. Please remember to validate that the API
>> (if you sucked in an external one rather than writing it) applies to
>> your applications' threat model and ticks off all the elements of
>> your security policy. Because, having hooked it into their apps,
>> teams are going to want a fair amount of exoneration from normal
>> processes (Some of which is OK, but a lot can be dangerous). Second,
>> please make sure it's actually secure--it will be a fulcrum of your
>> security controls' effectiveness. Make sure that assessment program
>> proves your developers used it correctly, consistently, and
>> thoroughly throughout their apps. What do I tell you about ESAPI and
>> your MVC frameworks (Point #3 from above)? -
>> sigh- That's a longer discussion. And, by all means, don't think you
>> can let your guard down on your pen-testing. Is it a silver bullet?
>> No.
>>
>> Is ESAPI the only approach? No. I submit that it's -A- way. I hope
>> this email outlines that effectively. And viewed from a knowledgeable
>> but separate perspective: the ESAPI approach has pluses and minuses
>> just like all the others.
>>
>> ----
>> John Steven
>> Senior Director; Advanced Technology Consulting
>> Desk: 703.404.9293 x1204 Cell: 703.727.4034 Key fingerprint = 4772
>> F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>>
>> Blog: http://www.cigital.com/justiceleague
>> Papers: http://www.cigital.com/papers/jsteven
>> http://www.cigital.com
>> Software Confidence. Achieved.
>>
>> (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
>> (*2) During the AppSecDC summit, Jeff indicated the ESAPI project
>> would later pilot SAMM but the global projects committee indicated
>> that getting OWASP projects to follow some secure development
>> touchpoints is too onerous/impossible. Dinis, I'll note is a huge
>> proponent of adherence.
>>
>>
>> On Jan 6, 2010, at 4:36 PM, James Manico wrote:
>>
>>> Hello Matt,
>>>
>>> Java EE still has NO support for escaping and lots of other
>>> important security areas. You need something like OWASP ESAPI to
>>> make a secure app even remotely possible. I was once a Sun guy, and
>>> I'm very fond of Java and Sun. But JavaEE 6 does very little to
>>> raise the bar when it comes to Application Security.
>>>
>>> - Jim
>>>
>>> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons
>>> <mparsons1980 at gmail.com> wrote:
>>>> From what I read it appears that this Java EE 6 could be a few rule
>>> changers.   It looks like to me, java is checking for authorization
>>> and
>>> authentication with this new framework.   If that is the case, I
>>> think that
>>> static code analyzers could change their rule sets to check what
>>> normally is
>>> a manual process in the code review of authentication and
>>> authorization.
>>> Am I correct on my assumption?
>>>
>>> Thanks,
>>> Matt
>>>
>>>
>>> Matt Parsons, MSM, CISSP
>>> 315-559-3588 Blackberry
>>> 817-294-3789 Home office
>>> mailto:mparsons1980 at gmail.com
>>> http://www.parsonsisconsulting.com
>>> http://www.o2-ounceopen.com/o2-power-users/
>>> http://www.linkedin.com/in/parsonsconsulting
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: sc-l-bounces at securecoding.org [mailto:sc-l-
>>> bounces at securecoding.org]
>>> On Behalf Of Kenneth Van Wyk
>>> Sent: Tuesday, January 05, 2010 8:59 AM
>>> To: Secure Coding
>>> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
>>> Security
>>> made simple ! | Core Security Patterns Weblog
>>>
>>> Happy new year SC-Lers.
>>>
>>> FYI, interesting blog post on some of the new security features in
>>> Java EE
>>> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
>>>
>>> http://www.coresecuritypatterns.com/blogs/?p=1622
>>>
>>>
>>> Cheers,
>>>
>>> Ken
>>>
>>> -----
>>> Kenneth R. van Wyk
>>> SC-L Moderator
>>>
>>>
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L at 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.
>>> _______________________________________________
>>>
>>>
>>>
>>> --
>>> --
>>> Jim Manico, Application Security Architect
>>> jim.manico at aspectsecurity.com | jim at manico.net
>>> (301) 604-4882 (work)
>>> (808) 652-3805 (cell)
>>>
>>> Aspect Security(tm)
>>> Securing your applications at the source
>>> http://www.aspectsecurity.com
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L at 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 at 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.
>> _______________________________________________




From c.mccown at intel.com  Thu Jan  7 16:33:56 2010
From: c.mccown at intel.com (McCown, Christian M)
Date: Thu, 7 Jan 2010 14:33:56 -0700
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
 Guardian
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD322A518238@qtomaexmbm22.AD.QINTRA.COM>
References: <236B4763-03D3-4DF2-81C0-78E84D3C41CD@krvw.com>
	<930fd0231001070843k47e00effq8ea35d51f4a1f23f@mail.gmail.com>
	<p05200f79c76bbd8ca0b2@[146.115.107.213]>
	<B8E4274903E6F64E8F9E5C21A96D83BD322A518238@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <8438CDA1F40C48409D5BBDC314F0CBB77F6E14B0@rrsmsx504.amr.corp.intel.com>

Anybody heard of Von Neumann probes?  Google it.  Then imagine what might happen if we (humans) employ the same (p*ss) poor programming discipline we do today into something like that.  Fun to ruminate on.


________
Chris McCown *
Intel Corp




-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Wall, Kevin
Sent: Thursday, January 07, 2010 12:37 PM
To: 'ljknews'; Secure Coding
Subject: Re: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian

Larry Kilgallen wrote...

> At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote:
>
> > I am VERY curious to learn how these happened... Only using the last
> > digit of the year? Hard for me to believe. Maybe it's in a
> single API
> > and somebody tried to be too clever with some bit-shifting.
>
> My wife says that in the lead-up to the year 2000 she caught
> some programmers "fixing" Y2K bugs by continuing to store
> year numbers in two digits and then just prefixing output
> with 19 if the value was greater than some two digit number
> and prefixing output with 20 if the value was less than or
> equal to that two digit number.
>
> Never underestimate programmer creativity.
>
> Never overestimate programmer precision.

While I never fixed any Y2K problems I worked next to someone
who did for about 6 months. What you refer to is pretty much what
I mentioned as the "fixed window" technique that was very common
to those developers who were addressing the problems at the time.

IIRC, it was a particularly popular approach for those who waited until
the last moment to address Y2K issues in there systems because it still
allowed for 2 digit year fields in all their forms and databases and output.

---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________


From neumann at csl.sri.com  Thu Jan  7 23:15:59 2010
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Thu, 7 Jan 2010 20:15:59 PST
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
 Guardian
In-Reply-To: Your message of Thu, 07 Jan 2010 16:02:38 -0400
Message-ID: <CMM.0.90.4.1262924159.neumann@chiron.csl.sri.com>

... and of course Multics solved the Y2K problem in 1965,
deferring the overflow for many additional decades.

From jim at manico.net  Fri Jan  8 00:57:50 2010
From: jim at manico.net (Jim Manico)
Date: Fri, 8 Jan 2010 00:57:50 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web
	Application	Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
	<B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>
Message-ID: <B0A49272-49F9-4058-8566-63071E7388AA@manico.net>

John,

Do you think we will reach a point where toolkits/frameworks will  
become so powerful that a developer will no longer require application  
security knowledge? I say no. Not now, not in 10 or 20 years. I  
encourage you to read my notes again. My comment was:

>>>> You need something like OWASP ESAPI to make a secure app even  
>>>> remotely possible


I think secure frameworks with built-in developer controls fits that  
very general statement, even though you clearly disagree.

I'm trying to get to a deeper issue here. I feel we need to empower  
developers with knowledge and the right APIs, and this thread includes  
my opinion that Java 6EE does little to move us in that direction. Of  
course, lower risk apps can sometimes tollerate less assurance. Of  
course legacy apps are much more difficult to secure. Ramming ESAPI  
into an existing app is often non-trivial, especially since we are  
still a young project and indeed need more documentation. In fact,  
ESAPI is no AppSec Jesus. I tried to make that clear below:

>> An ESAPI is no silver bullet, there is no such thing as that in
>> AppSec. But it will help build secure apps.

Adressing you other point, I've used regular expression multi-file- 
search-and-replace tricks across many million LOC applications to help  
lock down certain vulnerability classes, especially XSS. It's still a  
non trivial technique and requires significant regression testing, but  
it is possible in some cases for some security areas.

Last, if we make frameworks overly secure, we start to limit  
capabilities and innovation. We need to give developers some rope -  
and if they get some AppSec training and 50 or so functions specific  
to security controls - they might not hang themselves! :)

And this is not just a wild idea, I'm lucky to witness some of the  
largest institutions on the planet sucessfully implement ESAPI in the  
real world.

And sure, you can build a new secure app without an ESAPI. But libs  
like OWASP ESAPI will get you there faster and cheaper.

- Manico

On Jan 7, 2010, at 1:02 PM, John Steven <jsteven at cigital.com> wrote:

> 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 in production without risk/ 
> regression?
>
> * Generate an argument as to why ESAPI beats these alternatives. Is  
> it cost? Speed-to-market? What?
> * Finally, realize that it's OK that there's more than one way to do  
> things. Revel in it. It's what makes software an exciting field.
>
> In the meantime, rest assured that those of us out there that have  
> looked get that ESAPI can be a good thing.
>
> ----
> John Steven
> Senior Director; Advanced Technology Consulting
> Desk: 703.404.9293 x1204 Cell: 703.727.4034
> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>
> Blog: http://www.cigital.com/justiceleague
> Papers: http://www.cigital.com/papers/jsteven
> http://www.cigital.com
> Software Confidence. Achieved.
>
> On Jan 7, 2010, at 10:56 AM, Jim Manico wrote:
>
>> 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 build secure apps.
>>
>> Jim Manico
>>
>> On Jan 6, 2010, at 6:20 PM, John Steven <jsteven at 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 and some dynamic patching because it's "in the
>>> app" (an argument made recently by others in the blogosphere).
>>>
>>> 3) Top-to-Bottom Secure by Default - Declarative secure-by-default
>>> configuration of the hardened toolkit allows for securing those data
>>> flows that never make it out of the scaffolding into the app. If an
>>> organization wrote their own toolkit-unware security API, they'd
>>> have to not only assure their developers call it each-and-every
>>> place their it's needed but they'd also need to crack open the
>>> toolkits and make sure THEY call it too. Most of the time, one
>>> actively wants to avoid even having this visibility let along
>>> maintenance problem: it's a major headache.
>>>
>>> and, most importantly,
>>>
>>> 4) Less Integration points - Developers are already going to have to
>>> integrate against a MVC framework, so why force them to integrate
>>> against YA (yet-another) API? The MVC frameworks already contend
>>> with things like session management, input filtering, output-
>>> encoding, and authentication. Why not augment/improve that existing
>>> idiom rather than force developers to use it and an external
>>> security API?
>>>
>>> The ESAPI team has plenty of responses to the last question... not
>>> the least of which is "...'cause [framework XXX] sucks." Fair. Out
>>> of the box, they often do. Fair, [framework team XXX] probably isn't
>>> listening to us security guys either.
>>>
>>> If you're an ESAPI shop--good. Careful adoption of a security API
>>> can help your security posture. Please remember to validate that the
>>> API (if you sucked in an external one rather than writing it)
>>> applies to your applications' threat model and ticks off all the
>>> elements of your security policy. Because, having hooked it into
>>> their apps, teams are going to want a fair amount of exoneration
>>> from normal processes (Some of which is OK, but a lot can be
>>> dangerous). Second, please make sure it's actually secure--it will
>>> be a fulcrum of your security controls' effectiveness. Make sure
>>> that assessment program proves your developers used it correctly,
>>> consistently, and thoroughly throughout their apps. What do I tell
>>> you about ESAPI and your MVC frameworks (Point #3 from above)? -
>>> sigh- That's a longer discussion. And, by all means, don't think you
>>> can let your guard down on your pen-testing. Is it a silver bullet?
>>> No.
>>>
>>> Is ESAPI the only approach? No. I submit that it's -A- way. I hope
>>> this email outlines that effectively. And viewed from a
>>> knowledgeable but separate perspective: the ESAPI approach has
>>> pluses and minuses just like all the others.
>>>
>>> ----
>>> John Steven
>>> Senior Director; Advanced Technology Consulting
>>> Desk: 703.404.9293 x1204 Cell: 703.727.4034
>>> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>>>
>>> Blog: http://www.cigital.com/justiceleague
>>> Papers: http://www.cigital.com/papers/jsteven
>>> http://www.cigital.com
>>> Software Confidence. Achieved.
>>>
>>> (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
>>> (*2) During the AppSecDC summit, Jeff indicated the ESAPI project
>>> would later pilot SAMM but the global projects committee indicated
>>> that getting OWASP projects to follow some secure development
>>> touchpoints is too onerous/impossible. Dinis, I'll note is a huge
>>> proponent of adherence.
>>>
>>>
>>> On Jan 6, 2010, at 4:36 PM, James Manico wrote:
>>>
>>>> Hello Matt,
>>>>
>>>> Java EE still has NO support for escaping and lots of other
>>>> important security areas. You need something like OWASP ESAPI to
>>>> make a secure app even remotely possible. I was once a Sun guy, and
>>>> I'm very fond of Java and Sun. But JavaEE 6 does very little to
>>>> raise the bar when it comes to Application Security.
>>>>
>>>> - Jim
>>>>
>>>> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons
>>>> <mparsons1980 at gmail.com> wrote:
>>>>> From what I read it appears that this Java EE 6 could be a few  
>>>>> rule
>>>> changers.   It looks like to me, java is checking for authorization
>>>> and
>>>> authentication with this new framework.   If that is the case, I
>>>> think that
>>>> static code analyzers could change their rule sets to check what
>>>> normally is
>>>> a manual process in the code review of authentication and
>>>> authorization.
>>>> Am I correct on my assumption?
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>>
>>>> Matt Parsons, MSM, CISSP
>>>> 315-559-3588 Blackberry
>>>> 817-294-3789 Home office
>>>> mailto:mparsons1980 at gmail.com
>>>> http://www.parsonsisconsulting.com
>>>> http://www.o2-ounceopen.com/o2-power-users/
>>>> http://www.linkedin.com/in/parsonsconsulting
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: sc-l-bounces at securecoding.org [mailto:sc-l-
>>>> bounces at securecoding.org]
>>>> On Behalf Of Kenneth Van Wyk
>>>> Sent: Tuesday, January 05, 2010 8:59 AM
>>>> To: Secure Coding
>>>> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
>>>> Security
>>>> made simple ! | Core Security Patterns Weblog
>>>>
>>>> Happy new year SC-Lers.
>>>>
>>>> FYI, interesting blog post on some of the new security features in
>>>> Java EE
>>>> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
>>>>
>>>> http://www.coresecuritypatterns.com/blogs/?p=1622
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Ken
>>>>
>>>> -----
>>>> Kenneth R. van Wyk
>>>> SC-L Moderator
>>>>
>>>>
>>>> _______________________________________________
>>>> Secure Coding mailing list (SC-L) SC-L at 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.
>>>> _______________________________________________
>>>>
>>>>
>>>>
>>>> -- 
>>>> -- 
>>>> Jim Manico, Application Security Architect
>>>> jim.manico at aspectsecurity.com | jim at manico.net
>>>> (301) 604-4882 (work)
>>>> (808) 652-3805 (cell)
>>>>
>>>> Aspect Security?
>>>> Securing your applications at the source
>>>> http://www.aspectsecurity.com
>>>> _______________________________________________
>>>> Secure Coding mailing list (SC-L) SC-L at 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 at 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 at 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.
> _______________________________________________


From bishop at cs.ucdavis.edu  Fri Jan  8 13:02:56 2010
From: bishop at cs.ucdavis.edu (Matt Bishop)
Date: Fri, 8 Jan 2010 10:02:56 -0800
Subject: [SC-L] 2010 bug hits millions of Germans | World news | The
	Guardian
In-Reply-To: <CMM.0.90.4.1262924159.neumann@chiron.csl.sri.com>
References: <CMM.0.90.4.1262924159.neumann@chiron.csl.sri.com>
Message-ID: <323D999A-8D25-4C6C-B0C6-7DE0FF34933F@cs.ucdavis.edu>

It also solved the buffer overflow problem, and a number of others.

*sigh*

Matt

On Jan 7, 2010, at 8:15 PM, Peter G. Neumann wrote:

> ... and of course Multics solved the Y2K problem in 1965,
> deferring the overflow for many additional decades.
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________



From dinis.cruz at googlemail.com  Sat Jan  9 19:48:02 2010
From: dinis.cruz at googlemail.com (Dinis Cruz)
Date: Sun, 10 Jan 2010 00:48:02 +0000
Subject: [SC-L] Recommending ESAPI?
Message-ID: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>

Following the recent thread on Java 6 security and ESAPI, I just would like
to ask the following clarifications:

1) For an existing web application currently using a MVC framework (like
Spring or Struts) are we today (9th Jan 2009) officially recommending that
this web application development team adds OWASP's ESAPI.jar to the list of
'external' APIs (i.e. libs) they use, support and maintain?

2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL
they need to add? or are there other dependencies (i.e. jars) that also need to
be added, supported and maintained? (for example on the '*Dependencies'
section of the ESAPI Java
EE<http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE>
page
(i.e. Tab) it seems to imply that there are other *.jars needed)*
*
*
3) Where can I find detailed information about each of the 9 Security
Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access
control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography,
6) Error handling and logging, 7) Communication security, 8) HTTP security
and 9) Security configuration? (I took this list of controls from the
Introduction
to ESAPI pdf) <http://www.owasp.org/images/8/81/Esapi-datasheet.pdf>

*4) When adopting EASPI.jar, are we recommending that the developers should
adopt or retrofit their existing code on the areas affected by those 9
Security Controls? (i.e. code related to: Authentication, Access
control, Input validation, Output encoding/escaping, Cryptography, Error
handling and logging, Communication security, HTTP security and Security
configuration) *
*
*
*5) Should we recommend the adoption of ALL 9 Security Controls? or are
there some controls that are not ready today (9 Jan 2009) for production
environments and should not be recommended? (for example is the
'Authentication' control as mature as the 'Error handling and logging'
control?)*
*
*
*6) Are there commercial (i.e. paid) support services available for the
companies who want to add ESAPI.jar to they application?*
*
*
7) What is the version of ESAPI.jar that we should recommend? the version
1.4 (which looks like a stable release) or the version 2.0 rc4 (which looks
like it is a Release Candidate)

8) Where can I find the documentation of where and how ESAPI should be used?
More importantly, where can I find the information of how it CAN NOT or
SHOULD NOT be used (i.e. the cases where even when the EASPI.jar are used,
the application is still vulnerable)

9) if there list of companies that have currently added ESAPI.jar to their
applications and have deployed it? (i.e. real world usage of EASPI)

10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been through a security
review? and if so where can I read its report?

11) *when Jim says "... you can build a new secure app without an ESAPI. But
libs like OWASP ESAPI will get you there faster and cheaper....",  do we
have peer-reviewed data that suports this claim? *
*
*
*12) Is there a roadmap or how-to for companies that wish to adopt ESAPI.jar
on an a) new application or b) existing real-world application'?*
*
*
*13) What about the current implementations of ESAPI for the other
languages. Are we also recommending their use?*
*
*
*14) If a development team decides to use (for example) Spring and ESAPI
together in their (new or existing) application, what are the recommended
'parts' from each of those APIs (Spring and EASPI) that the developers
should be using? (for example: a) use Encoding from ESAPI, b) use
Authentication from Spring, c) use Authorization from ESAPI, d) use Error
Handling from Spring, e) use Logging from ESAPI, etc...)*
*
*
*Thanks*
*
*
*Dinis Cruz*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100110/a730039f/attachment.htm>

From kevin.w.wall at gmail.com  Sat Jan  9 23:38:59 2010
From: kevin.w.wall at gmail.com (Kevin W. Wall)
Date: Sat, 09 Jan 2010 23:38:59 -0500
Subject: [SC-L] [Esapi-user] Recommending ESAPI?
In-Reply-To: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>
References: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>
Message-ID: <4B4959E3.2030304@gmail.com>

Dinis Cruz wrote:
> Following the recent thread on Java 6 security and ESAPI, I just would like
> to ask the following clarifications:

Dinis... all really good questions. I'll comment on the ones I have some
some sense of and feel qualified to answer and punt on the others. (I'm
also going to delete those I'm not going to attempt to answer to shorten
the response.)

> 1) For an existing web application currently using a MVC framework (like
> Spring or Struts) are we today (9th Jan 2009) officially recommending that
> this web application development team adds OWASP's ESAPI.jar to the list of
> 'external' APIs (i.e. libs) they use, support and maintain?

I'm not aware of an *official* recommendation OWASP intends to make, but if they
do, I doubt it will be until sometime after ESAPI 2.0 is officially released.

> 2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL
> they need to add? or are there other dependencies (i.e. jars) that also need to
> be added, supported and maintained? (for example on the '*Dependencies'
> section of the ESAPI Java
> EE<http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE>
> page
> (i.e. Tab) it seems to imply that there are other *.jars needed)*

To a large degree, what jars are needed depends on what ESAPI security controls
are used by your application. (That what the "Dependencies" section on the URL
you referenced tries to clarify.)


Almost all the security controls use ESAPI logging which can be configured to
use either the Log4j or (Sun) Java logging. Log4j is the default, so if that is
used obviously a log4j jar is required.

All of the dependency jars are bundled with the ESAPI zip file, but which ones
you will actually needs depends on what ESAPI security controls are needed.

> *
> 3) Where can I find detailed information about each of the 9 Security
> Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access
> control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography,
> 6) Error handling and logging, 7) Communication security, 8) HTTP security
> and 9) Security configuration? (I took this list of controls from the
> Introduction
> to ESAPI pdf) <http://www.owasp.org/images/8/81/Esapi-datasheet.pdf>

Most of the detailed information--at least to the degree that we would like
it--is not yet completed. (I'm not even sure all the docs that are planned
have people to work on them yet. Some are awaiting developers to finish up
their stuff to pitch in and contribute. Mike Boberski is in charge of the
ESAPI documentation. He can fill you in on its status.)

> *4) <...snip...>
No comment.

> *5) Should we recommend the adoption of ALL 9 Security Controls? or are
> there some controls that are not ready today (9 Jan 2009) for production
> environments and should not be recommended? (for example is the
> 'Authentication' control as mature as the 'Error handling and logging'
> control?)*

My only comment on that is to *NOT* use the symmetric encryption in ESAPI 1.4.
It has lots of problems. One would be better off using encryption in the 2.0
release candidates (but even that is is a minor state of flux).

> *6) <...snip...>
No comment.

> 7) What is the version of ESAPI.jar that we should recommend? the version
> 1.4 (which looks like a stable release) or the version 2.0 rc4 (which looks
> like it is a Release Candidate)

Version 2.0 has some new features (e.g., WAF) that were not available in 1.4.
It also attempts to address some things that were broken in 2.0 (e.g., see
response to #4).  Ultimately this is probably one of those "it depends" answers.
I'll let Jim or Jeff provide a more official answer.

> 8) - 12) <...snip...>
No comment.

> *13) What about the current implementations of ESAPI for the other
> languages. Are we also recommending their use?*

IMO, doubtful. Most of the other languages are far behind the Java
implementation.

> *14) If a development team decides to use (for example) Spring and ESAPI
> together in their (new or existing) application, what are the recommended
> 'parts' from each of those APIs (Spring and EASPI) that the developers
> should be using? (for example: a) use Encoding from ESAPI, b) use
> Authentication from Spring, c) use Authorization from ESAPI, d) use Error
> Handling from Spring, e) use Logging from ESAPI, etc...)*

IMO, I think the ideal situation would be if we could get the Spring and Struts,
etc. development communities to integrate their frameworks so that they could
be used with the ESAPI interfaces. (In many of these cases, these
implementations would replace the ESAPI reference implementation.) However,
that is obviously going to take some time. I don't think that the ESAPI
dev team can do it all.

[Note: I am replying to both mailing lists. There may be policies against this.
If so, my apologies. However just wanted to make people aware of this; if they
Reply-All, they will need to be subscribed to both mailing lists from their
sending email address.]

-kevin
-- 
Kevin W. Wall
"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

From koved at us.ibm.com  Sun Jan 10 08:49:30 2010
From: koved at us.ibm.com (Larry Koved)
Date: Sun, 10 Jan 2010 08:49:30 -0500
Subject: [SC-L] W2SP 2010: Web 2.0 Security and Privacy 2010 CFP
Message-ID: <OF367F5FDC.B6DC1CD9-ON852576A7.004BE2F3-852576A7.004BF261@us.ibm.com>

The workshop chairs would like to invite you participate in the 4th annual 

workshop on Web 2.0 Security and Privacy.  Started in 2007, this 
successful 
series of workshops has attracted participation from both academia and 
industry, and participants from around the world.  This workshop is held
in conjunction with the 2010 IEEE Symposium on Security and Privacy. 




Workshop Call for Papers
W2SP 2010: Web 2.0 Security and Privacy 2010

Thursday, May 20
The Claremont Resort, Oakland, California
Web site: http://w2spconf.com/2010

The goal of this one day workshop is to bring together researchers and
practitioners from academia and industry to focus on understanding Web
2.0 security and privacy issues, and establishing new collaborations
in these areas.

Web 2.0 is about connecting people and amplifying the power of working
together. An ongoing explosion of new technology is powering
increasingly complex social and business interactions as well as
enabling an unprecedented level of unmediated information exchange and
horizontal organization. These interactions rely on composition of
content and services from multiple sources, commonly called mash-ups,
leading to systems with complex trust boundaries. This trend is likely
to continue because individuals, businesses, and other organizations
desire the simplicity, efficiency, and utility these technologies
offer.

Though these technologies have had many positive effects, they raise
issues about management of identities, personal safety, reputation,
privacy, anonymity, transient and long-term relationships, and
composition of function and content, both on the server and on the
client side (web browsers and mobile platforms). Although many of the
underlying security and privacy issues are not new, the use of these
technologies by very large and disparate populations raises new
questions. This workshop is intended to discuss the limitations of
current technologies and explore alternatives.

The scope of W2SP 2010 includes, but is not limited to:

Trustworthy cloud-based services
Usable security and privacy
Security and privacy as a service
Security for the mobile web
Identity management and psuedonymity
Web services/feeds/mashups
Security and privacy policies for composible content
Next-generation browser technology
Secure extensions and plug-ins
Advertisement and affiliate fraud

Potential workshop participants should submit a paper on topics
relevant to Web 2.0 security and privacy issues. We are seeking both
short position papers (2 - 4 pages) and refereed papers (a maximum of
8 pages, including references and appendices). Papers longer than 8
pages may be automatically rejected by the chair or workshop
committee. From the submissions, the program committee will strive to
balance participation between academia and industry and across topics.
Selected papers will appear on the workshop web site; W2SP has no
formal published proceedings.

For papers that focus primarily on the security and privacy of social
networks, we encourage authors to submit their paper to the Social
Network Security and Privacy (SNSP) workshop, which is concurrent and
co-located with W2SP. Submitted papers may be referred to the SNSP
program committee for consideration.

Workshop Co-Chairs
Larry Koved (IBM Research)
Dan S. Wallach (Rice University)

Program Chair
Collin Jackson (Carnegie Mellon University)

Program Committee
Ben Adida (Harvard University)
Dirk Balfanz (Google)
Adam Barth (UC Berkeley)
Konstantin (Kosta) Beznosov (University of British Columbia)
Suresh Chari (IBM Research)
Hao Chen (UC Davis)
Collin Jackson (Carnegie Mellon University)
Martin Johns (University of Passau)
Rob Johnson (Stony Brook University)
Engin Kirda (Institute Eurecom)
Larry Koved (IBM Research)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Dawn Song (UC Berkeley)
Dan S. Wallach (Rice University)
Helen Wang (Microsoft Research)

Important Dates

Paper submission deadline: Tuesday, March 23, 2010 (11:59pm US-Eastern)
Workshop acceptance notification date: April 11, 2010
Workshop date: Thursday, May 20, 2010

Registration: Workshop registration will be available via the 2010
IEEE Symposium on Security and Privacy conference web site.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100110/68000f3b/attachment-0001.htm>

From stephen at twisteddelight.org  Sun Jan 10 12:01:39 2010
From: stephen at twisteddelight.org (Stephen de Vries)
Date: Sun, 10 Jan 2010 18:01:39 +0100
Subject: [SC-L] [Esapi-user] Recommending ESAPI?
In-Reply-To: <4B4959E3.2030304@gmail.com>
References: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>
	<4B4959E3.2030304@gmail.com>
Message-ID: <F138D935-5705-4C90-B678-D21740B92CEF@twisteddelight.org>


On Jan 10, 2010, at 5:38 AM, Kevin W. Wall wrote:
> 
> IMO, I think the ideal situation would be if we could get the Spring and Struts,
> etc. development communities to integrate their frameworks so that they could
> be used with the ESAPI interfaces. (In many of these cases, these
> implementations would replace the ESAPI reference implementation.) However,
> that is obviously going to take some time. I don't think that the ESAPI
> dev team can do it all.

I think this is overestimating ESAPI's place in the pecking order.  Spring and J2E already have well established APIs for important security functions with a _lot_ of developers already invested in these APIs.  A better approach would be for ESAPI to adapt its API to suit Spring and the other frameworks.

To touch on one of Dinis' questions, my advise would be for developers to use the features from their existing frameworks and only use ESAPI for the gaps.

I confess to not having used ESAPI (just scanned the API), but from what I know of other frameworks some of the gaps that ESAPI might plug would be:

- Output encoding in funky places, like JavaScript and CSS (Some apps never need this)
- CSRF protection (Sometimes the pageflow/workflow features of a framework will already give you CSRF protection, if not, then ESAPI)
- Intrusion detection (if the level of assurance demanded by the application requires it)
- Some methods from the HttpUtilities class could be useful (e.g. setNoCacheHeaders, setSafeContentType)

For the overlapping functions, I think that existing frameworks already do an acceptable job of providing authentication, access control, data validation and logging, so unless there's a compelling feature that the application needs from ESAPI, I'd advise them to stick with their investment in their existing frameworks.
 

Stephen

From jim at manico.net  Sun Jan 10 14:45:42 2010
From: jim at manico.net (Jim Manico)
Date: Sun, 10 Jan 2010 09:45:42 -1000
Subject: [SC-L] [Esapi-user] Recommending ESAPI?
In-Reply-To: <F138D935-5705-4C90-B678-D21740B92CEF@twisteddelight.org>
References: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>	<4B4959E3.2030304@gmail.com>
	<F138D935-5705-4C90-B678-D21740B92CEF@twisteddelight.org>
Message-ID: <4B4A2E66.6070805@manico.net>

Stephen,

I think this is very important and sage advice.

Philosophically, we do not want to bring developers to ESAPI, we want to
bring ESAPI to developers. And that means working with where THEY are at
and moving form there.

I have not seen a large company use ESAPI directly in their code
(although others may have). Due to the maturity level of ESAPI, I
recommend that companies integrate ESAPI into their own corporate
library to fill in the gaps (wrap it!). Everyone has a different
nomenclature for function names, and I'm a fan of calling
ESAPI.encodeForHTML() instead of ESAPI.encoder().encodeForHTML() which
is what every "wrapper" has done so far,  from what I've seen.

>  For the overlapping functions, I think that existing frameworks
already do an acceptable job of _*providing authentication*_

I agree 100%. I do not see a big use case for ESAPI authentication in
most large organizations - they usually have something like SSO or at
least standard auth in place already. We need more maturity in this area.
_*
> , access control,*_

I think most frameworks get this wrong - in particular, I feel role
based access control is basically a design (or even security)
anti-pattern - and we need to move towards contextual/activity based
access control. I am not saying that ESAPI is there yet either, but
Access Control is an area that merits a great deal more research.
_*
> data validation*_

I mostly agree - but keep in mind that most frameworks do NOT do
canonicalization, a crucial validation step. ESAPI does this better than
the average bear.

_*> and logging,
*_
ESAPI provides something that log4j and others do not - security
specific logging. It's not groundbreaking - it's quite simple. But very
crucial, IMO.

logger.error(Logger.SECURITY_FAILURE, "Attempt to add unsafe data to
cookie (skip mode). Skipping cookie and continuing.");
*
> so unless there's a compelling feature that the application needs from
ESAPI, I'd advise them to stick with their investment in their existing
frameworks.*

I'd like to rephrase that a little  "Stick with your frameworks, but use
ESAPI to fill in the gaps"

Thanks for your thoughts, Stephen. I "get" where you are coming from,
and I think your head is in the right place. (About this topic, at least ;)

Regards,
- Jim

> On Jan 10, 2010, at 5:38 AM, Kevin W. Wall wrote:
>   
>> IMO, I think the ideal situation would be if we could get the Spring and Struts,
>> etc. development communities to integrate their frameworks so that they could
>> be used with the ESAPI interfaces. (In many of these cases, these
>> implementations would replace the ESAPI reference implementation.) However,
>> that is obviously going to take some time. I don't think that the ESAPI
>> dev team can do it all.
>>     
> I think this is overestimating ESAPI's place in the pecking order.  Spring and J2E already have well established APIs for important security functions with a _lot_ of developers already invested in these APIs.  A better approach would be for ESAPI to adapt its API to suit Spring and the other frameworks.
>
> To touch on one of Dinis' questions, my advise would be for developers to use the features from their existing frameworks and only use ESAPI for the gaps.
>
> I confess to not having used ESAPI (just scanned the API), but from what I know of other frameworks some of the gaps that ESAPI might plug would be:
>
> - Output encoding in funky places, like JavaScript and CSS (Some apps never need this)
> - CSRF protection (Sometimes the pageflow/workflow features of a framework will already give you CSRF protection, if not, then ESAPI)
> - Intrusion detection (if the level of assurance demanded by the application requires it)
> - Some methods from the HttpUtilities class could be useful (e.g. setNoCacheHeaders, setSafeContentType)
>
> For the overlapping functions, I think that existing frameworks already do an acceptable job of providing authentication, access control, data validation and logging, so unless there's a compelling feature that the application needs from ESAPI, I'd advise them to stick with their investment in their existing frameworks.
>  
>
> Stephen
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100110/c775e62c/attachment.htm>

From list-spam at secureconsulting.net  Mon Jan 11 12:55:51 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 11 Jan 2010 12:55:51 -0500
Subject: [SC-L] new post: The Three Domains of Application Security
Message-ID: <4B4B6627.5040907@secureconsulting.net>

Of interest, I hope...
http://www.secureconsulting.net/2010/01/the_three_domains_of_applicati.html

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"The unquestionable republicanism of the American mind will break
through the mist under which it has been clouded, and will oblige its
agents to reform the principles and practices of their administration."
Thomas Jefferson to Elbridge Gerry, 1799. ME 10:83

From gem at cigital.com  Mon Jan 11 15:11:13 2010
From: gem at cigital.com (Gary McGraw)
Date: Mon, 11 Jan 2010 15:11:13 -0500
Subject: [SC-L] FW: RSA Conference <forwarded spam>
In-Reply-To: <13046517.653.1263240159795.JavaMail.wingate@rsa.wingateservices.com>
Message-ID: <C770F013.1D23C%gem@cigital.com>

hi sc-l,

I don't care a whit about winning a Flip camera, but $200 off RSA registration sounds good.  Feel free to use this code if you were a newbie planning to come to RSA anyway.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
podcast www.cigital.com/realitycheck
blog www.cigital.com/justiceleague
book www.swsec.com

------ Forwarded Message
From: Sandra Toms-LaPedis <aszymanski at nthdegree.com>
Date: Mon, 11 Jan 2010 15:02:39 -0500
To: gem <gem at cigital.com>
Subject: RSA Conference - Refer a Friend and Win Prizes!

Thank you again for being a speaker at RSA? Conference 2010.

We believe you know potential delegates who can benefit from the education and training program RSA Conference provides, so new for 2010 we are introducing a Speaker Reward Program. The program includes a personal speaker discount registration code that you can send to your peers, colleagues and customers. This registration code offers a $200 savings off the current registration rate for new registrants*.

Simply pass the following discount registration code to your friends and the first 100 speakers to get five (5) new Delegates to register will receive a Flip camera - retail value $149.

Your personal speaker discount registration code*: PRMSE3959RNM

*Your personal speaker discount registration code cannot be combined with any other discounts and can only be used for new delegate registrations, not by someone who has already registered to attend RSA Conference 2010. The code is good until February 5, 2010.

To help you get started:

 *   Use the attached email template with suggested language to extend the invite to your friends.
 *   Promote yourself by adding the Conference email signature to your emails.
 *   Add the "I'm Speaking at RSA Conference 2010" icon to your company website, blog, etc.  Logos are available via the SRC <https://cm.rsaconference.com/US10/content/rsasso.do> .

Again, thank you for participating as a speaker and for supporting RSA Conference 2010!

Regards,
Sandra Toms LaPedis
Area Vice President/General Manager
RSA? Conference
------ End of Forwarded Message
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Template Letter.doc
Type: application/octet-stream
Size: 32768 bytes
Desc: Template Letter.doc
URL: <http://krvw.com/pipermail/sc-l/attachments/20100111/6692ff96/attachment-0001.obj>

From jsteven at cigital.com  Mon Jan 11 20:42:22 2010
From: jsteven at cigital.com (John Steven)
Date: Mon, 11 Jan 2010 20:42:22 -0500
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
 Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <B0A49272-49F9-4058-8566-63071E7388AA@manico.net>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
	<B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>
	<B0A49272-49F9-4058-8566-63071E7388AA@manico.net>
Message-ID: <B4F65854-916C-441A-B0D3-323C14BA8F54@cigital.com>

All,

Much has been said offline on this thread and so I'm going to say only things included herein to hopefully conclude my involvement in the SC-L topic. I hope I've provided useful direction for considering ESAPI adoption in this forum. 

For those interested, I'll be continuing the conversation with the appropriate folk within the ESAPI project on their lists. At least two OWASP board members see similar opportunities for maturing ESAPI and I'll confine that discussion in the audience that can be most productive with it.

See intermittent comments.

On Jan 8, 2010, at 12:57 AM, Jim Manico wrote:

> Do you think we will reach a point where toolkits/frameworks will
> become so powerful that a developer will no longer require application
> security knowledge? I say no. Not now, not in 10 or 20 years.

No, I don't think the frameworks will be "Secure". I don't believe apps will be "Secured" solely within the application code either. Both layers possess a non-negligable percentage of the executing (and vulnerable) code and each layer's abstractions have failed to isolate and provide security for the other layer. (IN)Security will continue to behave like the emergent property it is: and a focus on only part of the application's code base will ultimately fail to secure it (*1). 

Consider an 'application' as the whole stack of things when deployed. Software-centric application security practitioners (like myself, say) are often all-too-keen to think problems can be solved in the code written by that top crust of application developers or disregard benefits of WAFs and dynamic patching. Others over-rely on pen-testing an network security controls, while others focus on discovery tools, IDS/IPS, host hardening, and incident response.  

This list's moderator might tell you securing an app demands considering all the layers and getting all the right roles discussing the best solution to uncovered problems. We all need to keep each other honest in this pursuit because each of us will gravitate to a particular layer of the stack. For my own part, I'm hoping to lean on Mr. Van Wyk and Mr. Tomhave for that very service for the NoVA OWASP chapter: keep me honest on this one ;-)

>>>>> You need something like OWASP ESAPI to make a secure app even
>>>>> remotely possible
> 
> 
> I think secure frameworks with built-in developer controls fits that
> very general statement, even though you clearly disagree.

On the ESAPI Users mailing list, Wililams said the following(*2):

> It's always best if developers can work within their framework. The
> ESAPI project is trying to build some foundational security controls so
> that developers don't have to keep remaking the same mistakes over and
> over.  If your framework already provides a control already, great.  If
> your framework wants to use ESAPI and hide it from the developer, great.
> In some cases, the framework might want to expose ESAPI, and that's fine
> too.


I mentioned an adoption guide as advice to the ESAPI team. Architects within each organization will have to convince themselves that ESAPIs strengths and posture match their threat model and then lay out how they're going to want developers to interface with its security controls. Coverage of every framework is too much to ask but every organization has 2-3 commonly used MVC frameworks: that's where to start. 

It's wonderful when you can use the framework's declarative description to call out to things (like validators). Again, see Williams:

> If you want to use Struts Validators, for example, you can write a custom validator
> that delegates to an ESAPI validator.

Personally, I prefer the Struts abstraction (as it hides validation from developers as a matter of design... albeit abstraction is where Struts stops :-P)  You get validated input without the need to clutter the code (see my original email). I recommend this approach as the de facto integration strategy even for non-struts apps (though it requires some scaffolding).  But, if you can't pull this off, where does that leave us?

Manico nearly suggests(*3) another way to get the next lightest level of 'light touch' on the code when he discussed the notion of a cross-cutting concern. Using AspectJ you may be able to weave in such controls and not have to worry about hitting every entry point manually. If you're integrating an ESAPI -into- your framework code this approach might suit you: input validation aspects could be woven into application and framework code alike as part of a build / deploy process. While this approach has its own limitations I've been using it in the form of my own custom meta-class annotations when I can't bake the abstraction in tightly under the hood (for a Python object) to assure non-security properties (singleton pattern, monitor-lock, and others) are upheld in a very syntactically agreeable manner(*4). 

As a last resort, might I suggest using inheritance and encapsulation to stitch together framework-provided cut points and ESAPI code. For instance, one can simulate [the dreaded] 'multiple inheritance' of both Struts and ESAPI base classes by using the template method pattern within a sub-class of (say) the struts-provided class, which, implementing the template method pattern, would call security controls (such as validation or the largely vestigial ESAPI authentication checks) before handing off to end-application developer code that handles other controller functionality/business logic.

Personally, for me, the strategy of tacking ESAPI calls onto a developer's application code manually on a case-by-case basis without techniques described above is bound for failure. Developers simply won't be able to reach the total consistency required for robust defense in a large existing application. If you're going to walk this road though for the love of God please deploy SAST to make sure that something is sweeping through and looking for that ever-elusive consistency of application I describe.  
 
> And this is not just a wild idea, I'm lucky to witness some of the
> largest institutions on the planet sucessfully implement ESAPI in the
> real world.
> 
> And sure, you can build a new secure app without an ESAPI. But libs
> like OWASP ESAPI will get you there faster and cheaper.

I'd be very-much interested in data regarding faster and cheaper. With the exception of the input validation, canonicalization, and related functionality (*5) it seems like a lot of analysis and integration jobs remain when adopting ESAPI. I'd also like to know about bug rates relative to non-ESAPI code. I've been on the ESAPI mailing list for a while and can't discern from conversation much information regarding successful operationalization, though I hear rumblings of people working on this very problem. 

Cheers all,
----
John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.

(*1) This same argument scales down into the platform further: Java EE core, underlying OS / hypervisor... etc. 

(*2) Message dated: Jan 2010 00:04:49, ESAPI-Users Mailing list

(*3) Quoting Manico:
> I've used regular expression multi-file-search-and-replace tricks across many million LOC applications

In the case of (*3), I prefer AOP or SA to RegExp because of the provided type-safety of the two approaches and the option to log transforms. Though, for some cut-points, RegExp may be sufficient to accurately 'lock in' a cut-point.

(*4) Unlike the purely struts-based approach though, developers have to remember the annotation and change does necessitate recompilation and redeployment (be it Python, Java or .NET).

(*5) These areas appear to have received the lion share of attention to date (rightfully so, and to great avail) 

> On Jan 7, 2010, at 1:02 PM, John Steven <jsteven at cigital.com> wrote:
> 
>> 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 in production without risk/
>> regression?
>> 
>> * Generate an argument as to why ESAPI beats these alternatives. Is
>> it cost? Speed-to-market? What?
>> * Finally, realize that it's OK that there's more than one way to do
>> things. Revel in it. It's what makes software an exciting field.
>> 
>> In the meantime, rest assured that those of us out there that have
>> looked get that ESAPI can be a good thing.
>> 
>> ----
>> John Steven
>> Senior Director; Advanced Technology Consulting
>> Desk: 703.404.9293 x1204 Cell: 703.727.4034
>> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>> 
>> Blog: http://www.cigital.com/justiceleague
>> Papers: http://www.cigital.com/papers/jsteven
>> http://www.cigital.com
>> Software Confidence. Achieved.
>> 
>> On Jan 7, 2010, at 10:56 AM, Jim Manico wrote:
>> 
>>> 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 build secure apps.
>>> 
>>> Jim Manico
>>> 
>>> On Jan 6, 2010, at 6:20 PM, John Steven <jsteven at 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 and some dynamic patching because it's "in the
>>>> app" (an argument made recently by others in the blogosphere).
>>>> 
>>>> 3) Top-to-Bottom Secure by Default - Declarative secure-by-default
>>>> configuration of the hardened toolkit allows for securing those data
>>>> flows that never make it out of the scaffolding into the app. If an
>>>> organization wrote their own toolkit-unware security API, they'd
>>>> have to not only assure their developers call it each-and-every
>>>> place their it's needed but they'd also need to crack open the
>>>> toolkits and make sure THEY call it too. Most of the time, one
>>>> actively wants to avoid even having this visibility let along
>>>> maintenance problem: it's a major headache.
>>>> 
>>>> and, most importantly,
>>>> 
>>>> 4) Less Integration points - Developers are already going to have to
>>>> integrate against a MVC framework, so why force them to integrate
>>>> against YA (yet-another) API? The MVC frameworks already contend
>>>> with things like session management, input filtering, output-
>>>> encoding, and authentication. Why not augment/improve that existing
>>>> idiom rather than force developers to use it and an external
>>>> security API?
>>>> 
>>>> The ESAPI team has plenty of responses to the last question... not
>>>> the least of which is "...'cause [framework XXX] sucks." Fair. Out
>>>> of the box, they often do. Fair, [framework team XXX] probably isn't
>>>> listening to us security guys either.
>>>> 
>>>> If you're an ESAPI shop--good. Careful adoption of a security API
>>>> can help your security posture. Please remember to validate that the
>>>> API (if you sucked in an external one rather than writing it)
>>>> applies to your applications' threat model and ticks off all the
>>>> elements of your security policy. Because, having hooked it into
>>>> their apps, teams are going to want a fair amount of exoneration
>>>> from normal processes (Some of which is OK, but a lot can be
>>>> dangerous). Second, please make sure it's actually secure--it will
>>>> be a fulcrum of your security controls' effectiveness. Make sure
>>>> that assessment program proves your developers used it correctly,
>>>> consistently, and thoroughly throughout their apps. What do I tell
>>>> you about ESAPI and your MVC frameworks (Point #3 from above)? -
>>>> sigh- That's a longer discussion. And, by all means, don't think you
>>>> can let your guard down on your pen-testing. Is it a silver bullet?
>>>> No.
>>>> 
>>>> Is ESAPI the only approach? No. I submit that it's -A- way. I hope
>>>> this email outlines that effectively. And viewed from a
>>>> knowledgeable but separate perspective: the ESAPI approach has
>>>> pluses and minuses just like all the others.
>>>> 
>>>> ----
>>>> John Steven
>>>> Senior Director; Advanced Technology Consulting
>>>> Desk: 703.404.9293 x1204 Cell: 703.727.4034
>>>> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>>>> 
>>>> Blog: http://www.cigital.com/justiceleague
>>>> Papers: http://www.cigital.com/papers/jsteven
>>>> http://www.cigital.com
>>>> Software Confidence. Achieved.
>>>> 
>>>> (*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
>>>> (*2) During the AppSecDC summit, Jeff indicated the ESAPI project
>>>> would later pilot SAMM but the global projects committee indicated
>>>> that getting OWASP projects to follow some secure development
>>>> touchpoints is too onerous/impossible. Dinis, I'll note is a huge
>>>> proponent of adherence.
>>>> 
>>>> 
>>>> On Jan 6, 2010, at 4:36 PM, James Manico wrote:
>>>> 
>>>>> Hello Matt,
>>>>> 
>>>>> Java EE still has NO support for escaping and lots of other
>>>>> important security areas. You need something like OWASP ESAPI to
>>>>> make a secure app even remotely possible. I was once a Sun guy, and
>>>>> I'm very fond of Java and Sun. But JavaEE 6 does very little to
>>>>> raise the bar when it comes to Application Security.
>>>>> 
>>>>> - Jim
>>>>> 
>>>>> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons
>>>>> <mparsons1980 at gmail.com> wrote:
>>>>>> From what I read it appears that this Java EE 6 could be a few
>>>>>> rule
>>>>> changers.   It looks like to me, java is checking for authorization
>>>>> and
>>>>> authentication with this new framework.   If that is the case, I
>>>>> think that
>>>>> static code analyzers could change their rule sets to check what
>>>>> normally is
>>>>> a manual process in the code review of authentication and
>>>>> authorization.
>>>>> Am I correct on my assumption?
>>>>> 
>>>>> Thanks,
>>>>> Matt
>>>>> 
>>>>> 
>>>>> Matt Parsons, MSM, CISSP
>>>>> 315-559-3588 Blackberry
>>>>> 817-294-3789 Home office
>>>>> mailto:mparsons1980 at gmail.com
>>>>> http://www.parsonsisconsulting.com
>>>>> http://www.o2-ounceopen.com/o2-power-users/
>>>>> http://www.linkedin.com/in/parsonsconsulting
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: sc-l-bounces at securecoding.org [mailto:sc-l-
>>>>> bounces at securecoding.org]
>>>>> On Behalf Of Kenneth Van Wyk
>>>>> Sent: Tuesday, January 05, 2010 8:59 AM
>>>>> To: Secure Coding
>>>>> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
>>>>> Security
>>>>> made simple ! | Core Security Patterns Weblog
>>>>> 
>>>>> Happy new year SC-Lers.
>>>>> 
>>>>> FYI, interesting blog post on some of the new security features in
>>>>> Java EE
>>>>> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
>>>>> 
>>>>> http://www.coresecuritypatterns.com/blogs/?p=1622
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Ken
>>>>> 
>>>>> -----
>>>>> Kenneth R. van Wyk
>>>>> SC-L Moderator
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Secure Coding mailing list (SC-L) SC-L at 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.
>>>>> _______________________________________________
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> --
>>>>> Jim Manico, Application Security Architect
>>>>> jim.manico at aspectsecurity.com | jim at manico.net
>>>>> (301) 604-4882 (work)
>>>>> (808) 652-3805 (cell)
>>>>> 
>>>>> Aspect Security?
>>>>> Securing your applications at the source
>>>>> http://www.aspectsecurity.com
>>>>> _______________________________________________
>>>>> Secure Coding mailing list (SC-L) SC-L at 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 at 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 at 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.
>> _______________________________________________



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100111/d2d8e9f6/attachment-0001.bin>

From mparsons1980 at gmail.com  Tue Jan 12 11:44:23 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Tue, 12 Jan 2010 10:44:23 -0600
Subject: [SC-L] Blog skiiers versus snowboarders CISSPs vs programmers
In-Reply-To: <4B4B6627.5040907@secureconsulting.net>
References: <4B4B6627.5040907@secureconsulting.net>
Message-ID: <008301ca93a6$83772c00$8a658400$@com>

I wrote a blog in the state of software security using the analogy of skiers
versus snowboarder in the early 90's.  

Please let me know your thoughts and comments by replying to this list or my
blog.  

http://parsonsisconsulting.blogspot.com/

 

Thanks,
Matt



Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office 
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/






From rklists at gmail.com  Tue Jan 12 09:23:10 2010
From: rklists at gmail.com (Rohit Sethi)
Date: Tue, 12 Jan 2010 09:23:10 -0500
Subject: [SC-L] Secure Web Application Framework Manifesto
Message-ID: <fd72f3ed1001120623p26977c41kee1990d31939f514@mail.gmail.com>

Hi all,

Many of us have argued that the features of underlying web
applications frameworks will make a major impact on the security of
the individual applications built on top of them.

To that end, a few of my colleagues and myself have put together a
?Secure Web Application Framework Manifesto?. In many ways, this is
the inverse of the work that Arshan and the Intrinsic Security Working
Group did-  our emphasis is on providing a set of requirements for
frameworks to follow, rather than evaluating the frameworks
themselves. Ideally, frameworks will adhere to the manifesto and
publish a list of the features implemented. This helps developers make
intelligent decisions about the underlying security of the frameworks
they use, and should have the additional benefit of enhancing the
default security of web applications.

I?d like to propose turning this into an OWASP project, but wanted to
solicit feedback from the security community prior to turning it into
an official project.

Here?s the link to the paper:
http://labs.securitycompass.com/papers/secure-web-application-framework-manifesto-v0-05.pdf


-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com


From goertzel_karen at bah.com  Tue Jan 12 13:52:35 2010
From: goertzel_karen at bah.com (Goertzel, Karen [USA])
Date: Tue, 12 Jan 2010 13:52:35 -0500
Subject: [SC-L] Special Issue of IJSSE: Software Safety & Dependability -
 the Art of Engineering Trustworthy Software
Message-ID: <DC5EA49BAFF36B4A9134EFFD7BB0E17A1489A79CB4@ASHBMBX01.resource.ds.bah.com>

For those who might be interested. There are still a couple weeks until the submission deadline....


Karen Mercedes Goertzel, CISSP
Associate
Booz Allen Hamilton
703.698.7454
goertzel_karen at bah.com

---

Special Issue of IJSSE
Theme:  Software Safety & Dependability - the Art of Engineering Trustworthy Software 


1.	Guest Editors

Guest Editor:	         
         Dr. Lei Wu
         School of Science and Computer Engineering 
         University of Houston-Clear Lake, Houston, Texas, U.S.A
         Email:  wul at uhcl.edu
Co-Guest Editor:    
         Dr. Yi Feng
         Department of Computer Science and Mathematics, 
         Algoma University, Sault Ste. Marie, Ontario, Canada.
         Email:  Yi.Feng at algomau.ca 

2.	Important Dates
*	Submission of manuscripts: February 1, 2010
*	Notification of pre-acceptance/rejection: March 31, 2010
*	Submission of camera ready accepted papers: June 30 2010
*	Journal Special Issue Publication: January 2011

3.	Submission Guidelines

*	Submission guidelines through journal web site at:
        http://www.igi-global.com/ijsse
*	Inquiries, manuscripts and any supplementary material should be
        submitted to Guest Editor Dr. Lei Wu (wul at uhcl.edu), and Co-Guest
        Editor, Dr. Yi Feng (Yi.Feng at algomau.ca) through E-mail 

4.	Call for Paper Content

Software Safety is an element of the total safety program. It optimizes
system safety & dependability in the design, development, use, and
maintenance of software systems and their integration with safety
critical application systems in an operational environment. Increasing
size and complexity of software systems makes it harder to ensure their
dependability. At the same time, the issues of safety become more
critical as we more and more rely on software systems in our daily life.
These trends make it necessary to support software engineers with a set
of techniques and tools for developing dependable, trustworthy software.
Software safety cannot be allowed to function independently of the total
effort. Both simple and highly integrated multiple systems are
experiencing an extraordinary growth in the use of software to monitor
and/or control safety-critical subsystems or functions. A software
specification error, design flaw, or the lack of generic safety-critical
requirements can contribute to or cause a system failure or erroneous
human decision. To achieve an acceptable level of dependability goals
for software used in critical applications, software safety engineering
must be given primary emphasis early in the requirements definition and
system conceptual design process. Safety-critical software must then
receive continuous management emphasis and engineering analysis
throughout the development and operational lifecycles of the system.
In this special issue, we are seeking insights in how we can confront
the challenges of software safety & dependability issues in developing
dependable, trustworthy software systems.  

5.	Topics of Interests
This special issue is designed for software professionals and decision
makers to explore the state-of-the-art techniques of Secure Software
Engineering practices targeted at software safety & dependability
challenges. Some suggested areas include, but not limited to: 

*	Safety consistent with mission requirements 
*	Secure software engineering with software security & trustworthy
          software  development
*	State-of-arts literature review of technology dealing with
          software system security
*	Identify and analysis of safety-critical functionality of
          complex systems  
*	Intrusion detection,  security management , applied cryptography
*	Derive hazards and design safeguards for mitigations 
*	Safety-Critical functions design and preliminary hazards
          analysis
*	Identification, evaluation, and elimination techniques for
          hazards associated with the system and its software, throughout the
          lifecycle  
*	Complexity of safety critical interfaces, software components 
*	Sound secure software engineering principles that apply to the
          design of the software-user interface to minimize the probability of
          human error
*	Failure & hazard models, including hardware, software, human and
          system are addressed in the design of the software 
*	Software testing  techniques targeting at software safety issues
          at different levels of testing 



--
"Means should be taken to obviate one great objection -
at present felt with respect to sending private communi-
cations by telegraph - the violation of all secrecy."
- The Quarterly Review (UK), 1853

From arian.evans at anachronic.com  Tue Jan 12 15:06:54 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 12 Jan 2010 12:06:54 -0800
Subject: [SC-L] Blog skiiers versus snowboarders CISSPs vs programmers
In-Reply-To: <008301ca93a6$83772c00$8a658400$@com>
References: <4B4B6627.5040907@secureconsulting.net>
	<008301ca93a6$83772c00$8a658400$@com>
Message-ID: <cd1bdfdd1001121206g616a561dwb2ae4a830aa6a7f6@mail.gmail.com>

The software security problem is a huge problem. There are not enough
CISSPs to even think about solving this problem.

CISSPs probably should have a tactical role helping categorize,
classify, and facilitate getting things done. Scanner jockeys and
network security folk will lead the operational charge to WAF and
block and such. (good or bad, you're gonna need this stuff, the
problem is just too darn big)

I don't think many good devs who enjoy building are going to want to
change careers to do source code audits. That gets mind numbing
awfully fast.

Developers definitely have a role to play in solving a lot of the
basic syntax-attack stuffs, by proper selection and application of
modern frameworks, technologies, and gap-APIs (like ESAPI). Most
CISSPs lack the skill to provide much value here.

Design issues will always exist, unless users some day wake up and
decide they prefer security over usability. But I don't see that
happening any time soon. Heck, my password on all my work machines is
"password".

$0.02 USD.

---
Arian Evans
capitalist marksman. eats animals.



On Tue, Jan 12, 2010 at 8:44 AM, Matt Parsons <mparsons1980 at gmail.com> wrote:
> I wrote a blog in the state of software security using the analogy of skiers
> versus snowboarder in the early 90's.
>
> Please let me know your thoughts and comments by replying to this list or my
> blog.
>
> http://parsonsisconsulting.blogspot.com/
>
>
>
> Thanks,
> Matt
>
>
>
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> mailto:mparsons1980 at 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 at 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.
> _______________________________________________
>

From dinis.cruz at googlemail.com  Tue Jan 12 19:38:10 2010
From: dinis.cruz at googlemail.com (Dinis Cruz)
Date: Wed, 13 Jan 2010 00:38:10 +0000
Subject: [SC-L] [Esapi-dev] Recommending ESAPI?
In-Reply-To: <4B4D0288.6060708@owasp.org>
References: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>
	<4B4C62E7.4090200@owasp.org>
	<4348cbf91001121451w37b7599di2c1155f483b0d2bd@mail.gmail.com>
	<4B4D0288.6060708@owasp.org>
Message-ID: <51b4f5741001121638j2628b21cxbb00e2beca59aebd@mail.gmail.com>

My view is that the key to make this work is to create the ESTAPI, which is
the Enterprise Security *Testing* API

This way we would have (for every language):

   - *ESAPI Interfaces* - which describe the functionality that each
   security control should have
   - *ESTAPI* - Unit Tests that check the behaviour of the security controls
   - *ESAPI Reference Implementation(s) *- Which are (wherever possible)
   'production ready' versions of those security controls (and  in most cases a
   one-to-one mapping to the ESAPI Interfaces)
   - *Framework XYZ ESAPI 'connectors'* - Which wrap (or expose) the
   security controls defined in the ESAPI Interfaces in Framework XYZ

What I really like about this world, is that we (Application Security
Consultants) we start to create standards for how Security Controls should
behave. and (as important) are able to work with the Framework developers
without they felling that ESAPI is a 'competitor' to they Framework. After
all, the way we will really change the market is when the Frameworks used by
the majority of developers adopt ESAPI (or its principles)

Of course that the Framework developers are more than welcomed to grab large
parts (or even all) of the code provided by the ESAPI reference
implementation(s). But the key is that they (the framework developers) must:
a) take ownership of the code and b) respect the ESAPI Interfaces.

And hey, if the Framework developers decide NOT to implement a particular
security control, that is fine too.

BUT!

I would at least expect them to provide detailed information why they made
that decision and why they chose NOT to implement or support it (which would
allow us (Security community) to respectably agree or disagree with their
choices (hey for some Frameworks, being insecure is a feature :) )

Finally, In addition to all the advantages that we will have when frameworks
adopt these security controls, there is one that for me is probably the MOST
important one: *An 'ESAPI compliant app'* (which btw is a term we still have
to agree what exactly means),* is an app that is providing explicit
information about where they (the developers) think their (the app) security
controls are located*.

In another works, via the ESAPI Interfaces (and the ESTAPI tests) the
developers are actually telling us (the security consultants):
  a) what they think their application's attack surface is and
  b) what is the security behaviour that they have already tested for

Of course that they can game the system, which is why we (Security
Consultants) will still be needed (we will also need to make sure that they
implemented the security controls properly). But compare that to today's
(2009) world, were we are lucky to get an up-to-date application diagram and
a reasonable accurate description of how the application was actually coded
and behaves.

This would also (finally) give the application security tools (white, black,
glass, gray, pink, blue) a fighting change to automatically, or
operator-driven, understand what is going on and report back:
  - what it knows (security vulnerabilities) and (as important)
  - what it doesn't know / understand
(ok there is a lot more that these tools will provide us (for example ESTAPI
tests) but that is a topic for another post)

So, for me, the key added value of the ESAPI Interfaces, is that it will
provide us (Security Consultants) a way to understand how the app works
(from a security point of view) and to be able to finally be able to give
the clients what they want: Visibility, Assurance and the ability to make
'knowledgeable Risk-based decisions'.

Dinis Cruz

2010/1/12 Jim Manico <jim.manico at owasp.org>

>  Very well said.
>
> On this note, I think we may wish to consider formally splitting the
> interfaces from the reference implementation. We could then build a test
> framework that's tests those interfaces - so we can verify different
> implementations of ESAPI. Expand this out in a cross-language way, and we
> have some serious magic to work with.
>
> This is Dinis' idea, but I'm starting to see the light.
>
> - Jim
>
>
>
>
>
>
> An FYI from personal experience, be extra careful with the dependencies,
> particularly if you develop on an appserver that optimized for debug and
> production.
>
> You may need these libraries even if you are not using the area of the
> ESAPI RI that uses them.  The -Xverify:none JVM argument changes how the
> classloader pre-caches some classes, particularly Exceptions.  Despite not
> needing to use safe file upload capabilities, without that JVM arg is was
> looking for Exceptions found in the commons-uploads jar
>
>
>
> On Tue, Jan 12, 2010 at 6:54 AM, Jim Manico <jim.manico at owasp.org> wrote:
>
>> You know Dinis, when I first read your email I was bit offended. Same with
>> much of John Stevens' email.
>>
>> But you know? You are trying to help us. These kinds of pragmatic
>> questions need to be answered.
>>
>> So here goes.
>>
>>   Following the recent thread on Java 6 security and ESAPI, I just would
>> like to ask the following clarifications:
>>
>>  1) For an existing web application currently using a MVC framework (like
>> Spring or Struts) are we today (9th Jan 2009) officially recommending that
>> this web application development team adds OWASP's ESAPI.jar to the list of
>> 'external' APIs (i.e. libs) they use, support and maintain?
>>
>>
>>  I can personally attest for ESAPI 2.0 rc4 integration into Struts 1.3.x,
>> where I've used ESAPI for several years, from the early days. I'm not deeply
>> familiar with Spring. I would not say this is a trivial exercise, but it
>> certainly is possible.
>>
>>
>>  2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL
>> they need to add? or are there other dependencies (i.e. jars) that also need to
>> be added, supported and maintained? (for example on the '*Dependencies'
>> section of the ESAPI Java EE<http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE> page
>> (i.e. Tab) it seems to imply that there are other *.jars needed)*
>>
>>
>> ESAPI.jar has significant dependencies - something that is a problem, in
>> general, in the Java world. I'm optimistic about the new Java 7 component
>> framework - but that is a long way off.  In the meantime:
>>
>>  (from
>> http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE)
>>
>>
>>
>> *There are no dependencies on the ESAPI interfaces other than standard
>> Java EE. However, the reference implementation does have dependencies that
>> are detailed below. The reference implementation takes advantage of a few
>> existing libraries. This list may not be totally complete. *
>>
>>    - *DefaultAccessController needs? *
>>       - *Commons-Configuration 1.5 *
>>
>>
>>    - *DefaultValidator needs? *
>>        - *AntiSamy 1.2 (there may be a few transitive dependencies here)
>>       *
>>       - *NekoHTML 0.9.5 *
>>       - *Xerces 2.9.1 *
>>
>>
>>    - *Log4J Logger needs? *
>>       - *Log4j 1.2.12 *
>>
>>
>>    - *DefaultHTTPUtilities needs? *
>>       - *Commons-FileUpload 1.2 *
>>
>>
>>    - *WAF needs *
>>        - *XOM 1.0 (there may be a few transitive dependencies here) *
>>       - *Commons-FileUpload 1.2 *
>>
>>
>>  *
>> *
>> 3) Where can I find detailed information about each of the 9 Security
>> Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access
>> control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography,
>> 6) Error handling and logging, 7) Communication security, 8) HTTP security
>> and 9) Security configuration? (I took this list of controls from the Introduction
>> to ESAPI pdf) <http://www.owasp.org/images/8/81/Esapi-datasheet.pdf>
>>
>>
>>  Detailed from a marketing perspective? :) The best technical information
>> is our Javadoc pages at
>> http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.htmlwhich are not complete, but are fairly decent. We have also been very good
>> about answering questions, fast, on esapi-users and esapi-dev. But you are
>> right - docs are evolving, but we need more.
>>
>>   *4) When adopting EASPI.jar, are we recommending that the developers
>> should adopt or retrofit their existing code on the areas affected by those
>> 9 Security Controls? (i.e. code related to: Authentication, Access
>> control, Input validation, Output encoding/escaping, Cryptography, Error
>> handling and logging, Communication security, HTTP security and Security
>> configuration)
>> *
>>
>>  It really depends on the situation. But I get your point - I've seen the
>> Validator, Encoder, Utils and Error Handling modules used in retrofitting
>> situations successfully. I'm not so sure about the others.
>>
>> *
>> *
>>  *5) Should we recommend the adoption of ALL 9 Security Controls? or are
>> there some controls that are not ready today (9 Jan 2009) for production
>> environments and should not be recommended? (for example is the
>> 'Authentication' control as mature as the 'Error handling and logging'
>> control?)*
>>
>> I personally grade the reference 2.0 implementation as follows:
>>
>>  1) Authentication   C (Needs deeper enterprise integration)
>> 2) Access control   B- (This is just a really tough issue, and usually
>> requires deep application-specific context. Plus we have some good ideas on
>> the table from Beef that I'd like to consider)
>> 3) Input validation   A- (needs better messaging and internationalization
>> (thanks Sklarew for making us think in the right direction about this)
>> 4) Output encoding/escaping   A (Go Jeff, my only A. :) We do need a
>> performance tuning pass (easy) and DOM XSS encoding functions)
>> 5) Cryptography  A- (Great work Kevin, this is a huge huge improvement
>> from 1.4)
>>  6) Error handling and logging  B+ (Nice work on designing this from
>> Wichers)
>> 7) Communication security ?
>> 8) HTTP security B- (Great utilities! I'd like to see some of these
>> decoupled a bit more)
>> 9) Security configuration ?
>>
>> Digging deeper....
>>
>>  I personally use almost all of ESAPI. I've written my own Hibernate
>> Authentication layer - but it's very specific to my data model. It's very
>> difficult to decouple this from my app and would be difficult to donate it
>> to the project effectively. Same with access control. My data model is VERY
>> complex, and donating it without SQL scripts, hibernate configuration, and a
>> whole lot of other code - is a great challenge. (Not to mention that my
>> employer owns the code ;) The flat-file authenticator is just a proof of
>> concept and should never be used in a production environment of any kind,
>> IMO. The thread-local nature of the authenticator, while I use it and love
>> it, needs to be reconsidered since other classes, like the loggers, depend
>> on it. Error handling is fairly solid - and is only a thin layer on top of
>> known logging methods + security specific messaging. The encoder was handed
>> down from Gosling himself - given to Jeff - who gifted it to us. :) I want
>> the encoder to be a hard-coded part of ESAPI. :) The validator and encoder
>> can be dropped into any project fairly easy. Same with much of the HTTP
>> Utils. The Encryptor from 1.4 should be avoided, which impacts other
>> portions of the codebase.
>> http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html
>> . 2.0 is going to be a very big milestone; I'm pretty stoked about what I'm
>> seeing from the team.
>>
>>
>> Most importantly, it's easy to use the ESAPI configuration layer to
>> over-ride any of the reference implementation with your personal
>> authenticator or access controller (so long as you implement the ESAPI
>> interfaces), as I have for my projects.
>>
>>  *
>> *
>>  *6) Are there commercial (i.e. paid) support services available for the
>> companies who want to add ESAPI.jar to they application?*
>>
>>
>> I hesitate to mention this, and I'm not trying to pimp - but I'm
>> respectfully answering all of your questions. Aspect offers these services.
>> I've been working with Jeff on some of those efforts. It's working out well
>> for Aspects clients, I'd dare say. If someone else wishes to speak up on
>> this topic, please do. Open.
>>
>> *
>> *
>>  7) What is the version of ESAPI.jar that we should recommend? the
>> version 1.4 (which looks like a stable release) or the version 2.0 rc4
>> (which looks like it is a Release Candidate)
>>
>> ESAPI 1.4.1 is *very *far behind 2.0 rc4.  Java 4 is way past end of
>> lifecycle - but it's still in very wide use, so we plan to back-port all of
>> ESAPI 2.0 to 1.4. Or at least as much as we can. I'm making some changes
>> this week and plan on releasing 1.4.2 this week.
>>
>>
>>  8) Where can I find the documentation of where and how ESAPI should be
>> used? More importantly, where can I find the information of how it CAN NOT
>> or SHOULD NOT be used (i.e. the cases where even when the EASPI.jar are
>> used, the application is still vulnerable)
>>
>> Yea, Docs. We need more docs. Boberski has done incredible work in this
>> area.
>>
>>
>>  9) if there list of companies that have currently added ESAPI.jar to
>> their applications and have deployed it? (i.e. real world usage of EASPI)
>>
>> Under "users and adopters"
>> http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers
>>
>>
>>  10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been through a
>> security review? and if so where can I read its report?
>>
>>  Yes and see #8 sentence 2.
>>
>>
>>  11) *when Jim says "... you can build a new secure app without an ESAPI.
>> But libs like OWASP ESAPI will get you there faster and cheaper....",  do
>> we have peer-reviewed data that suports this claim?
>> *
>>
>> Nope. I'm shooting from the hip and I consider this as common sense. But I
>> agree, we REALLY need more assurance evidence that is published on the wiki
>> - perhaps we should run o2 against the ESAPI codebase for starters. Or maybe
>> someone can donate code review services and publish that report on our wiki.
>> I hear you. Assurance, published assurance, is fundamental.
>>
>> *
>> *
>>  *12) Is there a roadmap or how-to for companies that wish to adopt
>> ESAPI.jar on an a) new application or b) existing real-world application'?
>> *
>>
>> See #8 sentence 2.
>>
>> *
>> *
>> *13) What about the current implementations of ESAPI for the other
>> languages. Are we also recommending their use?*
>>
>>  Most are beta or alpha - with sparkles of 1.0. But I'd love to hear the
>> other language leaders chime in here. I focus on the Java version of ESAPI.
>>
>>  *
>> *
>> *14) If a development team decides to use (for example) Spring and ESAPI
>> together in their (new or existing) application, what are the recommended
>> 'parts' from each of those APIs (Spring and EASPI) that the developers
>> should be using? (for example: a) use Encoding from ESAPI, b) use
>> Authentication from Spring, c) use Authorization from ESAPI, d) use Error
>> Handling from Spring, e) use Logging from ESAPI, etc...)*
>>
>>
>>  I just don't know how to answer this question. I think for starters, the
>> completeness of our encoder helps stop XSS cold in a way that is a bit
>> better than the frameworks. And Jeff authorer a great cheat sheet to go
>> alongside it.
>> http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
>>
>> *
>> *
>> *Thanks*
>> *
>> *
>> *Dinis Cruz*
>>
>> *
>> *
>> I'm not going to shy away from these emails any longer. Is this all you
>> got, Dinis? John Steven? Bring it on, I'll do my best to answer as honestly
>> as I can.
>>
>> But let me tell you, Dinis. I would not consider building any Java app
>> without ESAPI. :) (please note the "I" statement - I've been deep in the
>> code for years, I'm not saying its easy - it requires significant investment
>> of time to use all of ESAPI as it stands today).
>>
>> Another 18 hour day - I need sleep. :)
>>
>> Regards,
>> - Jim
>>
>> _______________________________________________
>> Esapi-dev mailing list
>> Esapi-dev at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-dev
>>
>>
>
>
> --
> Jim Manico
> OWASP Podcast Host/Producerhttp://www.manico.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100113/7d96c480/attachment-0001.htm>

From jim.manico at owasp.org  Wed Jan 13 03:13:08 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Tue, 12 Jan 2010 22:13:08 -1000
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
 Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <B4F65854-916C-441A-B0D3-323C14BA8F54@cigital.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>	<017201ca8e45$db4e4d70$91eae850$@com>	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>	<B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>	<B0A49272-49F9-4058-8566-63071E7388AA@manico.net>
	<B4F65854-916C-441A-B0D3-323C14BA8F54@cigital.com>
Message-ID: <4B4D8094.6040604@owasp.org>

On 1/11/2010 3:42 PM, John Steven wrote:

> As a last resort, might I suggest using inheritance and encapsulation
to stitch together framework-provided cut points and ESAPI code.

This is where ESAPI will evolve. For starters, we need to get our base
controls right. :) This is the hallmark of complicated engineering
fields like robotics - start small, get it working and add complexity
over time.

> For instance, one can simulate [the dreaded] 'multiple inheritance' of
both Struts and ESAPI base classes by using the template method pattern
within a sub-class of (say) the struts-provided class, which,
implementing the template method pattern, would call security controls
(such as validation or the largely vestigial ESAPI authentication
checks) before handing off to end-application developer code that
handles other controller functionality/business logic.

Interesting. Keep in mind, template pattern implies some kind of shared
functionality. I would not call interfaces (ie: Java's substitution for
standard multiple-inheritance) dreaded when used appropriately.
Interfaces are "clean" and do not carry any baggage (ie: functionality).
It's my opinion that the ESAPI interfaces are ESAPI's gold - we are
trying to suggest a few (100 or so) methods that you organization needs
to have at the app level (in some form or another) in order to build
secure apps.  Template pattern might be more appropriate for a C+ ESAPI,
but not Java, IMO, in this specific case. Each language-specific version
of ESAPI will mandate different patterns. But once we start the
ESAPI-Struts and the ESAPI-Spring project, which will happen, template
will resurface.

Taking a step back - let's take the common notion that we live in a
"framework world" and dismiss it. The reality is, many large
organizations depend on completely heterogeneous software architectures.
I've seen one large org use multiple versions of struts, swing and
wicket, in addition to several custom architectures, in addition to old
school servlets, using several different servlet containers including
one in which they built their own servlet container from scratch and
continue to maintain it. This is where an ESAPI is ideal - a common set
of centrally maintained controls to pull from.

> Personally, for me, the strategy of tacking ESAPI calls onto a
developer's application code manually on a case-by-case basis without
techniques described above is bound for failure.

I think "bound for failure" is an almost dangerous exaggeration.
Difficult (at first) and even error prone? Possibly.  Deep framework
integration of all of these controls will take time. I originally wanted
to make ESAPI a struts project - and just go mad in submitting patches
to struts. After ESAPI reaches a measure of stability, I may do just
that (ESAPI-Struts!).

Also, (your) ESAPI should be part of a well balanced software
engineering life-cycle. You need to trust developers to some degree to
do the right thing. Trust but verify. This is where code guidelines,
code review (and I do not mean security code review, just plain ol
review of developers code to ensure they are writing to corporate
standards) and other non-security code quality and functionality review
techniques come into play.

> Developers simply won't be able to reach the total consistency
required for robust defense in a large existing application.

Well, that speaks of a larger problem - if your coders are all "coders
gone wild"- then you are in trouble even before the auditors arrive.
Consistency of your codebase is your organizations, architects and other
software leaders job.

> If you're going to walk this road though for the love of God please
deploy SAST to make sure that something is sweeping through and looking
for that ever-elusive consistency of application I describe.

SAST is a decent value, in some cases, when approaching very insecure
code-bases. Turnkey SAST is a waste of money on a mature code base -
without custom rules specific to your conventions and controls. And for
a very large company? I think *not *moving in the direction of some kind
of SAST technology - whether its off the shelf or custom built - is
crazy in this day in age. You need some measure of automated code
review, but doing it cost effectively can be illusive. Findbugs is a
great place to start in the Java world. A few RegEx's specific to YOUR
controls and styles go a long way. And if you can afford it, going whole
hog on one of the major commercial SAST players with custom rules is not
a terrible idea, if you have the AppSec FTE's or consultants available
to run and interpret the results. The open source world is behind but
will catch up.  I know I'm mixing ideas here, but you get the gist. And
these are loaded ideas, I'm curious to hear your response.

>  I'd be very-much interested in data regarding faster and cheaper.
With the exception of the input validation, canonicalization, and
related functionality (*5) it seems like a lot of analysis and
integration jobs remain when adopting ESAPI.

It took me about 8 hours to port the flat-file authenticator to a
high-performance hibernate solution. Perhaps another 16 hours of code
tweaking.  I'm not a fan of the ESAPI authenticator as it stands today
and I would like to see it evolve. But porting the reference
implementation forced me to do it "right" and it did not take long at
all. Calling it vestigial is certainly and exaggeration, IMO.

> I'd also like to know about bug rates relative to non-ESAPI code. I've
been on the ESAPI mailing list for a while and can't discern from
conversation much information regarding successful operationalization,
though I hear rumblings of people working on this very problem.

It difficult to do this without violating non disclosures with clients.
But I agree, we need these stats!

And I need to be careful here. The world is a very meaningless place if
you over-analyze it. I'm in the trenches trying to support the
developers who are donating their time to build open source security
libraries in order to make the world a better place in some small way.
My personal goal is to make the entire application security industry
disappear and/or shrink so AppSec is just a standard set on line items
on each software projects SOW. Communists? Maybe. But we are making a
difference.

These are all my opinions and do not necessarily represent the
"official" position of OWASP, if such a thing even exists (yet).

-- 
Jim Manico
OWASP Podcast Host/Producer
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100112/d49deab8/attachment.htm>

From mike.boberski at gmail.com  Tue Jan 12 19:46:50 2010
From: mike.boberski at gmail.com (Mike Boberski)
Date: Tue, 12 Jan 2010 19:46:50 -0500
Subject: [SC-L] [Esapi-user] [Esapi-dev] Recommending ESAPI?
In-Reply-To: <51b4f5741001121638j2628b21cxbb00e2beca59aebd@mail.gmail.com>
References: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com> 
	<4B4C62E7.4090200@owasp.org>
	<4348cbf91001121451w37b7599di2c1155f483b0d2bd@mail.gmail.com> 
	<4B4D0288.6060708@owasp.org>
	<51b4f5741001121638j2628b21cxbb00e2beca59aebd@mail.gmail.com>
Message-ID: <22290cd81001121646q17d0bf46h9c81148157b38a07@mail.gmail.com>

> we start to create standards for how Security Controls should behave [and
basically the rest of the post]

I submit ASVS for your consideration. If one is further concerned about
building blocks in the environment, check out Common Criteria and FIPS
140-2.

Also,

There have also been discussions about creating standardized test suites for
ESAPI implementations to ensure consistent security checks/effects across
ESAPI language implementations, but I don't think that's what you're getting
at.

It's not hard (with respect) to differentiate interfaces from reference
implementations from adapters (customized controls), please see the design
patterns doc I wrote that's posted to the project page. I'm not sure I see
advantages to further rearranging and splitting out the interfaces.

Best,

Mike


On Tue, Jan 12, 2010 at 7:38 PM, Dinis Cruz <dinis.cruz at googlemail.com>wrote:

> My view is that the key to make this work is to create the ESTAPI, which is
> the Enterprise Security *Testing* API
>
> This way we would have (for every language):
>
>    - *ESAPI Interfaces* - which describe the functionality that each
>    security control should have
>    - *ESTAPI* - Unit Tests that check the behaviour of the security
>    controls
>    - *ESAPI Reference Implementation(s) *- Which are (wherever possible)
>    'production ready' versions of those security controls (and  in most cases a
>    one-to-one mapping to the ESAPI Interfaces)
>    - *Framework XYZ ESAPI 'connectors'* - Which wrap (or expose) the
>    security controls defined in the ESAPI Interfaces in Framework XYZ
>
> What I really like about this world, is that we (Application Security
> Consultants) we start to create standards for how Security Controls should
> behave. and (as important) are able to work with the Framework developers
> without they felling that ESAPI is a 'competitor' to they Framework. After
> all, the way we will really change the market is when the Frameworks used by
> the majority of developers adopt ESAPI (or its principles)
>
> Of course that the Framework developers are more than welcomed to grab
> large parts (or even all) of the code provided by the ESAPI reference
> implementation(s). But the key is that they (the framework developers) must:
> a) take ownership of the code and b) respect the ESAPI Interfaces.
>
> And hey, if the Framework developers decide NOT to implement a particular
> security control, that is fine too.
>
> BUT!
>
> I would at least expect them to provide detailed information why they made
> that decision and why they chose NOT to implement or support it (which would
> allow us (Security community) to respectably agree or disagree with their
> choices (hey for some Frameworks, being insecure is a feature :) )
>
> Finally, In addition to all the advantages that we will have when
> frameworks adopt these security controls, there is one that for me is
> probably the MOST important one: *An 'ESAPI compliant app'* (which btw is
> a term we still have to agree what exactly means),* is an app that is
> providing explicit information about where they (the developers) think their
> (the app) security controls are located*.
>
> In another works, via the ESAPI Interfaces (and the ESTAPI tests) the
> developers are actually telling us (the security consultants):
>   a) what they think their application's attack surface is and
>   b) what is the security behaviour that they have already tested for
>
> Of course that they can game the system, which is why we (Security
> Consultants) will still be needed (we will also need to make sure that they
> implemented the security controls properly). But compare that to today's
> (2009) world, were we are lucky to get an up-to-date application diagram and
> a reasonable accurate description of how the application was actually coded
> and behaves.
>
> This would also (finally) give the application security tools (white,
> black, glass, gray, pink, blue) a fighting change to automatically, or
> operator-driven, understand what is going on and report back:
>   - what it knows (security vulnerabilities) and (as important)
>   - what it doesn't know / understand
> (ok there is a lot more that these tools will provide us (for example
> ESTAPI tests) but that is a topic for another post)
>
> So, for me, the key added value of the ESAPI Interfaces, is that it will
> provide us (Security Consultants) a way to understand how the app works
> (from a security point of view) and to be able to finally be able to give
> the clients what they want: Visibility, Assurance and the ability to make
> 'knowledgeable Risk-based decisions'.
>
> Dinis Cruz
>
> 2010/1/12 Jim Manico <jim.manico at owasp.org>
>
>>  Very well said.
>>
>> On this note, I think we may wish to consider formally splitting the
>> interfaces from the reference implementation. We could then build a test
>> framework that's tests those interfaces - so we can verify different
>> implementations of ESAPI. Expand this out in a cross-language way, and we
>> have some serious magic to work with.
>>
>> This is Dinis' idea, but I'm starting to see the light.
>>
>> - Jim
>>
>>
>>
>>
>>
>>
>> An FYI from personal experience, be extra careful with the dependencies,
>> particularly if you develop on an appserver that optimized for debug and
>> production.
>>
>> You may need these libraries even if you are not using the area of the
>> ESAPI RI that uses them.  The -Xverify:none JVM argument changes how the
>> classloader pre-caches some classes, particularly Exceptions.  Despite not
>> needing to use safe file upload capabilities, without that JVM arg is was
>> looking for Exceptions found in the commons-uploads jar
>>
>>
>>
>> On Tue, Jan 12, 2010 at 6:54 AM, Jim Manico <jim.manico at owasp.org> wrote:
>>
>>> You know Dinis, when I first read your email I was bit offended. Same
>>> with much of John Stevens' email.
>>>
>>> But you know? You are trying to help us. These kinds of pragmatic
>>> questions need to be answered.
>>>
>>> So here goes.
>>>
>>>   Following the recent thread on Java 6 security and ESAPI, I just would
>>> like to ask the following clarifications:
>>>
>>>  1) For an existing web application currently using a MVC framework
>>> (like Spring or Struts) are we today (9th Jan 2009) officially
>>> recommending that this web application development team adds OWASP's
>>> ESAPI.jar to the list of 'external' APIs (i.e. libs) they use, support and
>>> maintain?
>>>
>>>
>>>  I can personally attest for ESAPI 2.0 rc4 integration into Struts
>>> 1.3.x, where I've used ESAPI for several years, from the early days. I'm not
>>> deeply familiar with Spring. I would not say this is a trivial exercise, but
>>> it certainly is possible.
>>>
>>>
>>>  2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar
>>> ALL they need to add? or are there other dependencies (i.e. jars) that also
>>> need to be added, supported and maintained? (for example on the '*
>>> Dependencies' section of the ESAPI Java EE<http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE> page
>>> (i.e. Tab) it seems to imply that there are other *.jars needed)*
>>>
>>>
>>> ESAPI.jar has significant dependencies - something that is a problem, in
>>> general, in the Java world. I'm optimistic about the new Java 7 component
>>> framework - but that is a long way off.  In the meantime:
>>>
>>>  (from
>>> http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE)
>>>
>>>
>>>
>>> *There are no dependencies on the ESAPI interfaces other than standard
>>> Java EE. However, the reference implementation does have dependencies that
>>> are detailed below. The reference implementation takes advantage of a few
>>> existing libraries. This list may not be totally complete. *
>>>
>>>    - *DefaultAccessController needs? *
>>>       - *Commons-Configuration 1.5 *
>>>
>>>
>>>    - *DefaultValidator needs? *
>>>        - *AntiSamy 1.2 (there may be a few transitive dependencies here)
>>>       *
>>>       - *NekoHTML 0.9.5 *
>>>       - *Xerces 2.9.1 *
>>>
>>>
>>>    - *Log4J Logger needs? *
>>>       - *Log4j 1.2.12 *
>>>
>>>
>>>    - *DefaultHTTPUtilities needs? *
>>>       - *Commons-FileUpload 1.2 *
>>>
>>>
>>>    - *WAF needs *
>>>        - *XOM 1.0 (there may be a few transitive dependencies here) *
>>>       - *Commons-FileUpload 1.2 *
>>>
>>>
>>>  *
>>> *
>>> 3) Where can I find detailed information about each of the 9 Security
>>> Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access
>>> control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography,
>>> 6) Error handling and logging, 7) Communication security, 8) HTTP security
>>> and 9) Security configuration? (I took this list of controls from the Introduction
>>> to ESAPI pdf) <http://www.owasp.org/images/8/81/Esapi-datasheet.pdf>
>>>
>>>
>>>  Detailed from a marketing perspective? :) The best technical
>>> information is our Javadoc pages at
>>> http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.htmlwhich are not complete, but are fairly decent. We have also been very good
>>> about answering questions, fast, on esapi-users and esapi-dev. But you are
>>> right - docs are evolving, but we need more.
>>>
>>>   *4) When adopting EASPI.jar, are we recommending that the developers
>>> should adopt or retrofit their existing code on the areas affected by those
>>> 9 Security Controls? (i.e. code related to: Authentication, Access
>>> control, Input validation, Output encoding/escaping, Cryptography, Error
>>> handling and logging, Communication security, HTTP security and Security
>>> configuration)
>>> *
>>>
>>>  It really depends on the situation. But I get your point - I've seen
>>> the Validator, Encoder, Utils and Error Handling modules used in
>>> retrofitting situations successfully. I'm not so sure about the others.
>>>
>>> *
>>> *
>>>  *5) Should we recommend the adoption of ALL 9 Security Controls? or are
>>> there some controls that are not ready today (9 Jan 2009) for production
>>> environments and should not be recommended? (for example is the
>>> 'Authentication' control as mature as the 'Error handling and logging'
>>> control?)*
>>>
>>> I personally grade the reference 2.0 implementation as follows:
>>>
>>>  1) Authentication   C (Needs deeper enterprise integration)
>>> 2) Access control   B- (This is just a really tough issue, and usually
>>> requires deep application-specific context. Plus we have some good ideas on
>>> the table from Beef that I'd like to consider)
>>> 3) Input validation   A- (needs better messaging and internationalization
>>> (thanks Sklarew for making us think in the right direction about this)
>>> 4) Output encoding/escaping   A (Go Jeff, my only A. :) We do need a
>>> performance tuning pass (easy) and DOM XSS encoding functions)
>>> 5) Cryptography  A- (Great work Kevin, this is a huge huge improvement
>>> from 1.4)
>>>  6) Error handling and logging  B+ (Nice work on designing this from
>>> Wichers)
>>> 7) Communication security ?
>>> 8) HTTP security B- (Great utilities! I'd like to see some of these
>>> decoupled a bit more)
>>> 9) Security configuration ?
>>>
>>> Digging deeper....
>>>
>>>  I personally use almost all of ESAPI. I've written my own Hibernate
>>> Authentication layer - but it's very specific to my data model. It's very
>>> difficult to decouple this from my app and would be difficult to donate it
>>> to the project effectively. Same with access control. My data model is VERY
>>> complex, and donating it without SQL scripts, hibernate configuration, and a
>>> whole lot of other code - is a great challenge. (Not to mention that my
>>> employer owns the code ;) The flat-file authenticator is just a proof of
>>> concept and should never be used in a production environment of any kind,
>>> IMO. The thread-local nature of the authenticator, while I use it and love
>>> it, needs to be reconsidered since other classes, like the loggers, depend
>>> on it. Error handling is fairly solid - and is only a thin layer on top of
>>> known logging methods + security specific messaging. The encoder was handed
>>> down from Gosling himself - given to Jeff - who gifted it to us. :) I want
>>> the encoder to be a hard-coded part of ESAPI. :) The validator and encoder
>>> can be dropped into any project fairly easy. Same with much of the HTTP
>>> Utils. The Encryptor from 1.4 should be avoided, which impacts other
>>> portions of the codebase.
>>> http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html
>>> . 2.0 is going to be a very big milestone; I'm pretty stoked about what I'm
>>> seeing from the team.
>>>
>>>
>>> Most importantly, it's easy to use the ESAPI configuration layer to
>>> over-ride any of the reference implementation with your personal
>>> authenticator or access controller (so long as you implement the ESAPI
>>> interfaces), as I have for my projects.
>>>
>>>  *
>>> *
>>>  *6) Are there commercial (i.e. paid) support services available for the
>>> companies who want to add ESAPI.jar to they application?*
>>>
>>>
>>> I hesitate to mention this, and I'm not trying to pimp - but I'm
>>> respectfully answering all of your questions. Aspect offers these services.
>>> I've been working with Jeff on some of those efforts. It's working out well
>>> for Aspects clients, I'd dare say. If someone else wishes to speak up on
>>> this topic, please do. Open.
>>>
>>> *
>>> *
>>>  7) What is the version of ESAPI.jar that we should recommend? the
>>> version 1.4 (which looks like a stable release) or the version 2.0 rc4
>>> (which looks like it is a Release Candidate)
>>>
>>> ESAPI 1.4.1 is *very *far behind 2.0 rc4.  Java 4 is way past end of
>>> lifecycle - but it's still in very wide use, so we plan to back-port all of
>>> ESAPI 2.0 to 1.4. Or at least as much as we can. I'm making some changes
>>> this week and plan on releasing 1.4.2 this week.
>>>
>>>
>>>  8) Where can I find the documentation of where and how ESAPI should be
>>> used? More importantly, where can I find the information of how it CAN NOT
>>> or SHOULD NOT be used (i.e. the cases where even when the EASPI.jar are
>>> used, the application is still vulnerable)
>>>
>>> Yea, Docs. We need more docs. Boberski has done incredible work in this
>>> area.
>>>
>>>
>>>  9) if there list of companies that have currently added ESAPI.jar to
>>> their applications and have deployed it? (i.e. real world usage of EASPI)
>>>
>>> Under "users and adopters"
>>> http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers
>>>
>>>
>>>  10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been through a
>>> security review? and if so where can I read its report?
>>>
>>>  Yes and see #8 sentence 2.
>>>
>>>
>>>  11) *when Jim says "... you can build a new secure app without an
>>> ESAPI. But libs like OWASP ESAPI will get you there faster and
>>> cheaper....",  do we have peer-reviewed data that suports this claim?
>>> *
>>>
>>> Nope. I'm shooting from the hip and I consider this as common sense. But
>>> I agree, we REALLY need more assurance evidence that is published on the
>>> wiki - perhaps we should run o2 against the ESAPI codebase for starters. Or
>>> maybe someone can donate code review services and publish that report on our
>>> wiki. I hear you. Assurance, published assurance, is fundamental.
>>>
>>> *
>>> *
>>>  *12) Is there a roadmap or how-to for companies that wish to adopt
>>> ESAPI.jar on an a) new application or b) existing real-world application'?
>>> *
>>>
>>> See #8 sentence 2.
>>>
>>> *
>>> *
>>> *13) What about the current implementations of ESAPI for the other
>>> languages. Are we also recommending their use?*
>>>
>>>  Most are beta or alpha - with sparkles of 1.0. But I'd love to hear the
>>> other language leaders chime in here. I focus on the Java version of ESAPI.
>>>
>>>  *
>>> *
>>> *14) If a development team decides to use (for example) Spring and ESAPI
>>> together in their (new or existing) application, what are the recommended
>>> 'parts' from each of those APIs (Spring and EASPI) that the developers
>>> should be using? (for example: a) use Encoding from ESAPI, b) use
>>> Authentication from Spring, c) use Authorization from ESAPI, d) use Error
>>> Handling from Spring, e) use Logging from ESAPI, etc...)*
>>>
>>>
>>>  I just don't know how to answer this question. I think for starters, the
>>> completeness of our encoder helps stop XSS cold in a way that is a bit
>>> better than the frameworks. And Jeff authorer a great cheat sheet to go
>>> alongside it.
>>> http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
>>>
>>> *
>>> *
>>> *Thanks*
>>> *
>>> *
>>> *Dinis Cruz*
>>>
>>> *
>>> *
>>> I'm not going to shy away from these emails any longer. Is this all you
>>> got, Dinis? John Steven? Bring it on, I'll do my best to answer as honestly
>>> as I can.
>>>
>>> But let me tell you, Dinis. I would not consider building any Java app
>>> without ESAPI. :) (please note the "I" statement - I've been deep in the
>>> code for years, I'm not saying its easy - it requires significant investment
>>> of time to use all of ESAPI as it stands today).
>>>
>>> Another 18 hour day - I need sleep. :)
>>>
>>> Regards,
>>> - Jim
>>>
>>> _______________________________________________
>>> Esapi-dev mailing list
>>> Esapi-dev at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/esapi-dev
>>>
>>>
>>
>>
>> --
>> Jim Manico
>> OWASP Podcast Host/Producerhttp://www.manico.net
>>
>>
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100112/710664a2/attachment-0001.htm>

From Paco at cigital.com  Tue Jan 12 15:31:21 2010
From: Paco at cigital.com (Paco Hope)
Date: Tue, 12 Jan 2010 15:31:21 -0500
Subject: [SC-L] Secure Web Application Framework Manifesto
In-Reply-To: <fd72f3ed1001120623p26977c41kee1990d31939f514@mail.gmail.com>
References: <fd72f3ed1001120623p26977c41kee1990d31939f514@mail.gmail.com>
Message-ID: <C86A74E2-A412-482F-BED5-C551F37ECB77@cigital.com>


On Jan 12, 2010, at 9:23 AM, Rohit Sethi wrote:
> Many of us have argued that the features of underlying web
> applications frameworks will make a major impact on the security of
> the individual applications built on top of them.

This is timely, relative to John Steven's recent discussion (re: ESAPI) that it's not all in the code. There's a ton to be done in the code, but it's not all there.

> I?d like to propose turning this into an OWASP project, but wanted to
> solicit feedback from the security community prior to turning it into
> an official project.

I think this is an interesting start, but it seems unfocused. Some of the problems are broad (data confused as commands) and some are highly specific (getting down to the name of the researcher who discovered it). Some seem like they mention technology that's cool without describing the problem that the technology addresses and why that technology is the right answer to the problem.  Some seem like issues that a framework could offer (pluggable security) and others seem like they are operating system issues (security logs) while still others seem like they are application business logic (login forms and password requirements).

Providing some set of criteria and/or features that indicate compliance with certain best practices is a fine idea. Should you spend your time enumerating flaws and attacks, though, or spend time enumerating correct behavior? I say this because the criteria in this document do both. In some cases they are prescriptive: "use cryptographic random numbers." In other cases, they are untestable negatives: "don't accept illegal characters." 

I think each of these criteria should follow a formula. There needs to be some acceptance criteria for what makes the cut to be included in the manifesto, too.

I think each of your criteria should have the same qualities that good software requirements have. They're often remembered using the mnemonic "SMART". Different people assign slightly different names, but I would suggest that, for your purposes, you consider: Specific, Measurable, Achievable, Relevant, Testable.  I think you can admit criteria to your list that are weak in one of these areas, but if it is weak in two or more areas, it either needs to be expanded or removed (IMO).

You have good and bad examples for each of these, so let me try to demonstrate:

Specific: "illegal characters" is not specific, because what is illegal for one context is mandatory in another context. "Provide an encoding format for every page": that's specific.

Measurable: "Safe file upload" is not measurable (any more than secure web app framework is). Supporting configurable session timeouts is measurable.

Achievable: Safe interaction with unmanaged code is very hard to do. Not to say impossible, but achievability is going to be a key issue.  Turning on secure cookie flags is obviously achievable.

Relevant: I'm not sure if password policy and "login form" are relevant. If this is a framework we're talking about, application developers tend to manage this in their own business logic, not the underlying framework, right?  The rest of your list is pretty relevant.

Testable: I'm not sure if the arithmetic overflow protection is testable.  Other things, like cryptographic randomness is, but even then you have to be careful how you specify the tests.

Lastly, numerous people have created countless lists of flaws, defects, vulnerabilities, attack patterns, security patterns, programming mistakes, design mistakes, and so on. The security world is quite thick with them. I don't see hardly any referenced here, certainly none older than a year or two, despite software security being a 40-year-old field.  I like your fundamental idea, of having a checklist of capabilities that enables descriptions and comparisons of frameworks.  I just think it could use something else as its source material / organization.

Paco
--
Paco Hope, CISSP - CSSLP
Technical Manager, Cigital, Inc.
http://www.cigital.com/
Software Confidence. Achieved.



From rklists at gmail.com  Wed Jan 13 00:25:34 2010
From: rklists at gmail.com (Rohit Sethi)
Date: Wed, 13 Jan 2010 00:25:34 -0500
Subject: [SC-L] Secure Web Application Framework Manifesto
In-Reply-To: <C86A74E2-A412-482F-BED5-C551F37ECB77@cigital.com>
References: <fd72f3ed1001120623p26977c41kee1990d31939f514@mail.gmail.com>
	<C86A74E2-A412-482F-BED5-C551F37ECB77@cigital.com>
Message-ID: <fd72f3ed1001122125o5de8127esc9742e5e5ba41deb@mail.gmail.com>

Paco, these are really great comments and will be really useful for us
in improving the doc prior to release as an OWASP project.

One aspect of the paper that I noticed you referenced a few times is
the set of requirements for authentication. I agree this isn't
normally the kind of thing a framework provides, but we've started to
see frameworks like Django offer authentication out of the box by
default (http://www.djangobook.com/en/2.0/chapter14/). Maybe we should
revisit whether or not to still include these since they are
application specific.

As for some of the specific concerns you have, let me attempt to respond

>>Some of the problems are broad (data confused as commands) and some are highly >>specific (getting down to the name of the researcher who discovered it).

If you don't mind I'd like to connect off-list with you and get
information about the specific problems are you are outlining in this
sentence. In particular we don't want to miss out on crediting the
right people.

>>Some seem like they mention technology that's cool without describing the problem that >>the technology addresses and why that technology is the right answer to the problem.

An example or two would really help here. Perhaps you mean
requirements like "Automatic Content Security Policy (CSP) Header
Generation" and how we don't go into detail about Cross Site
Scripting. Would a link to the OWASP article on XSS help? As for
describing why CSP mitigates against XSS, we feel that's adequately
documented in the CSP link we provided. Basically we don't want to
saturate the document with descriptions of problems that have already
be written about in detail, but maybe we didn't link to these.

>>Some seem like issues that a framework could offer (pluggable security) and others seem l>>ike they are operating system issues (security logs) while still others seem like they are >>application business logic (login forms and password requirements).

We are in now way saying that you must use a framework to solve the
problem, but rather that a framework CAN solve the problem. I'd be
interested to hear how security logs only apply to operating systems
and not to broad application behavior as defined in AppSensor.

>> Providing some set of criteria and/or features that indicate compliance with certain best >>practices is a fine idea. Should you spend your time enumerating flaws and attacks, >>though, or spend time enumerating correct behavior? I say this because the criteria in this >>document do both. In some cases they are prescriptive: "use cryptographic random >>numbers." In other cases, they are untestable negatives: "don't accept illegal characters."

I would suggest that we are always enumerating correct behavior.
"Don't accept illegal characters" is not an untestable negative; we
can verify that only a set of specific, legal characters (e.g. valid
UTF-8 byte sequences) are allowed by the framework and all others are
discarded or generate an exception. Maybe the point you are making is
that we should always word things in the affirmative? I.e. "Only
accept legal characters for a given encoding format". I think that's a
good idea


>>I think each of your criteria should have the same qualities that good software >>requirements have. They're often remembered using the mnemonic "SMART". Different >>people assign slightly different names, but I would suggest that, for your purposes, you >>consider: Specific, Measurable, Achievable, Relevant, Testable.

This is a *really* good idea. We need to go through all of these and
see how they fit the SMART acronym. The one that I'm a bit confused on
is "Specific", since the nature of the advice is not for a specific
application (unlike traditional requirements). Should we drop the
"Disallow illegal characters / Only allow legal characters" because we
can't define what that set of characters is in this document? I
realize that not making it specific makes it difficult to measure and
test, but I also think it's fair to leave share some of that burden
with the framework developers themselves.

>>I just think it could use something else as its source material / organization.

That's a good point - any suggestions here? Again maybe we can connect
off-list about this point

Thanks again Paco!

Cheers,

Rohit

On Tue, Jan 12, 2010 at 3:31 PM, Paco Hope <Paco at cigital.com> wrote:
>
> On Jan 12, 2010, at 9:23 AM, Rohit Sethi wrote:
>> Many of us have argued that the features of underlying web
>> applications frameworks will make a major impact on the security of
>> the individual applications built on top of them.
>
> This is timely, relative to John Steven's recent discussion (re: ESAPI) that it's not all in the code. There's a ton to be done in the code, but it's not all there.
>
>> I?d like to propose turning this into an OWASP project, but wanted to
>> solicit feedback from the security community prior to turning it into
>> an official project.
>
> I think this is an interesting start, but it seems unfocused. Some of the problems are broad (data confused as commands) and some are highly specific (getting down to the name of the researcher who discovered it). Some seem like they mention technology that's cool without describing the problem that the technology addresses and why that technology is the right answer to the problem. ?Some seem like issues that a framework could offer (pluggable security) and others seem like they are operating system issues (security logs) while still others seem like they are application business logic (login forms and password requirements).
>
> Providing some set of criteria and/or features that indicate compliance with certain best practices is a fine idea. Should you spend your time enumerating flaws and attacks, though, or spend time enumerating correct behavior? I say this because the criteria in this document do both. In some cases they are prescriptive: "use cryptographic random numbers." In other cases, they are untestable negatives: "don't accept illegal characters."
>
> I think each of these criteria should follow a formula. There needs to be some acceptance criteria for what makes the cut to be included in the manifesto, too.
>
> I think each of your criteria should have the same qualities that good software requirements have. They're often remembered using the mnemonic "SMART". Different people assign slightly different names, but I would suggest that, for your purposes, you consider: Specific, Measurable, Achievable, Relevant, Testable. ?I think you can admit criteria to your list that are weak in one of these areas, but if it is weak in two or more areas, it either needs to be expanded or removed (IMO).
>
> You have good and bad examples for each of these, so let me try to demonstrate:
>
> Specific: "illegal characters" is not specific, because what is illegal for one context is mandatory in another context. "Provide an encoding format for every page": that's specific.
>
> Measurable: "Safe file upload" is not measurable (any more than secure web app framework is). Supporting configurable session timeouts is measurable.
>
> Achievable: Safe interaction with unmanaged code is very hard to do. Not to say impossible, but achievability is going to be a key issue. ?Turning on secure cookie flags is obviously achievable.
>
> Relevant: I'm not sure if password policy and "login form" are relevant. If this is a framework we're talking about, application developers tend to manage this in their own business logic, not the underlying framework, right? ?The rest of your list is pretty relevant.
>
> Testable: I'm not sure if the arithmetic overflow protection is testable. ?Other things, like cryptographic randomness is, but even then you have to be careful how you specify the tests.
>
> Lastly, numerous people have created countless lists of flaws, defects, vulnerabilities, attack patterns, security patterns, programming mistakes, design mistakes, and so on. The security world is quite thick with them. I don't see hardly any referenced here, certainly none older than a year or two, despite software security being a 40-year-old field. ?I like your fundamental idea, of having a checklist of capabilities that enables descriptions and comparisons of frameworks. ?I just think it could use something else as its source material / organization.
>
> Paco
> --
> Paco Hope, CISSP - CSSLP
> Technical Manager, Cigital, Inc.
> http://www.cigital.com/
> Software Confidence. Achieved.
>
>



-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com
twitter: rksethi


From list-spam at secureconsulting.net  Wed Jan 13 08:23:53 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 13 Jan 2010 08:23:53 -0500
Subject: [SC-L] Blog skiiers versus snowboarders CISSPs vs programmers
In-Reply-To: <cd1bdfdd1001121206g616a561dwb2ae4a830aa6a7f6@mail.gmail.com>
References: <4B4B6627.5040907@secureconsulting.net>	<008301ca93a6$83772c00$8a658400$@com>
	<cd1bdfdd1001121206g616a561dwb2ae4a830aa6a7f6@mail.gmail.com>
Message-ID: <4B4DC969.2080603@secureconsulting.net>

I'm not even sure why we're talking about CISSPs in this regard. Having
a CISSP proves nothing; it's merely a blind HR/recruiter checklist item.
I've personally met dozens of CISSPs who can't answer the most basic of
security questions.

The short-term comes down to what Gary talked about recently, which is
getting a software security group (or team) established and functioning
well. Over time, outreach and education run by the SSG then begins to
permeate the organization until, hopefully, some day, the SSG can shrink
or dissolve and let security stand on its own. We obviously have a long
way to go as an industry before we reach that point.

fwiw.

-ben

Arian J. Evans wrote:
> The software security problem is a huge problem. There are not enough
> CISSPs to even think about solving this problem.
> 
> CISSPs probably should have a tactical role helping categorize,
> classify, and facilitate getting things done. Scanner jockeys and
> network security folk will lead the operational charge to WAF and
> block and such. (good or bad, you're gonna need this stuff, the
> problem is just too darn big)
> 
> I don't think many good devs who enjoy building are going to want to
> change careers to do source code audits. That gets mind numbing
> awfully fast.
> 
> Developers definitely have a role to play in solving a lot of the
> basic syntax-attack stuffs, by proper selection and application of
> modern frameworks, technologies, and gap-APIs (like ESAPI). Most
> CISSPs lack the skill to provide much value here.
> 
> Design issues will always exist, unless users some day wake up and
> decide they prefer security over usability. But I don't see that
> happening any time soon. Heck, my password on all my work machines is
> "password".
> 
> $0.02 USD.
> 
> ---
> Arian Evans
> capitalist marksman. eats animals.
> 
> 
> 
> On Tue, Jan 12, 2010 at 8:44 AM, Matt Parsons <mparsons1980 at gmail.com> wrote:
>> I wrote a blog in the state of software security using the analogy of skiers
>> versus snowboarder in the early 90's.
>>
>> Please let me know your thoughts and comments by replying to this list or my
>> blog.
>>
>> http://parsonsisconsulting.blogspot.com/
>>
>>
>>
>> Thanks,
>> Matt
>>
>>
>>
>> Matt Parsons, MSM, CISSP
>> 315-559-3588 Blackberry
>> 817-294-3789 Home office
>> mailto:mparsons1980 at 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 at 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 at 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.
> _______________________________________________
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"I have no special talent. I am only passionately curious."
Albert Einstein

From list-spam at secureconsulting.net  Wed Jan 13 08:30:26 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 13 Jan 2010 08:30:26 -0500
Subject: [SC-L] InformIT: You need an SSG
In-Reply-To: <5B205300BAF07F4491E3F7BDF7A58E060EE77681@TK5EX14MBXC123.redmond.corp.microsoft.com>
References: <4B3178C7.40000@secureconsulting.net>
	<C7578DBD.1CB3B%gem@cigital.com>
	<DDB2518A6054844BA2A0CF24C77D047F0EDE41B8DB@BE-EXCHANGE-09.swift.corp>
	<5B205300BAF07F4491E3F7BDF7A58E060EE77681@TK5EX14MBXC123.redmond.corp.microsoft.com>
Message-ID: <4B4DCAF2.4080707@secureconsulting.net>

Thanks for that excellent and detailed response, Steve. A few follow-up
questions:
1) What sort of charter and executive support was/is necessary to
establish a group like SSG, and to continue building on it? In
particular, I wonder about how the mandate was established, and then
supported over the year(s)?

2) How long has it taken to go from no SSG to a well-functioning SSG?
What sort of ramp-up time was needed?

3) Is there a way to capture the SSG and IR approach into some sort of
copy-n-paste model or framework that could be used to expedite
replication within other orgs? Is it even realistic to think that this
approach can be easily replicated? (somewhat ties back into
mandate/support, I suppose)

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Any sufficiently advanced technology is indistinguishable from magic."
Arthur C. Clarke

Steve Lipner wrote:
> Thanks for looping me in Gary - this is an interesting topic and one
> that I do have an opinion about (no surprise).  (My apologies for the
> long delay responding - holidays and vacation rather than lack of
> interest).
> 
> Microsoft created a central IR group before I joined the company, and
> we feel very strongly that the IR model we have is the right one.  As
> things have evolved today, we centralize response policy, customer
> communications, security researcher (vulnerability finder)
> communications, press outreach, emergency response, vulnerability and
> fix security analysis, and response to complex (multi-product)
> vulnerabilities.    Individual product teams are responsible for
> building secure code, and if a vulnerability is found they're
> responsible for fixing it.  But we have central policies on update
> packaging and release so that we protect all customers in the same
> way and administrators don't have to learn a separate patching
> process for each product.
> 
> For IR, the central group lets us speak with one voice to communities
> who would be confused or bothered by having to deal with a batch of
> "different Microsofts."  It also allows us to build a team that can
> specialize in deep technical security analysis - how bad is the
> impact this bug, is it an instance of a broader pattern that we
> should be searching for, does the proposed fix in fact fix the
> underlying problem?  Answering those questions is specialized work,
> and it's unreasonable to expect that any but the biggest product
> groups could build or retain the necessary capability.  I could share
> horror stories from 2000 and 2001 when really competent developers
> told me that a vulnerability wasn't exploitable to run code and then
> we found that it was.  The competence to do that sort of analysis is
> a lot scarcer than the competence to write secure code - but
> vulnerabilities still arise, and the IR team needs the scarce kind of
> competence to plan the right response.
> 
> For secure development, as I said above, we expect product teams to
> design and build secure software.  But for a company like Microsoft
> with a central commitment to security, a central SSG allows us to
> develop and enforce common policies for what "secure" means.  That's
> part of achieving the accountability ("consequences") Ben refers to
> below.  The SSG is also the place where we update policies and
> requirements, and develop new tools and techniques.  The SDL tools
> (and guidance) that we've released at www.microsoft.com/sdl over the
> last year or so have all been developed in our SSG - most for our own
> in-house use.  The SSG serves as a consulting resource on secure
> design - an area where the "right" solution will vary from product to
> product, and where it's beneficial for product teams to be able to
> appeal to folks who are focused on security and see a lot of problems
> and solutions.  The final key role of the SSG is to provide the link
> back to vulnerability research (again something that only the biggest
> product teams could afford).  Our SSG (Microsoft Security Engineering
> Center or MSEC) is part of the same organization as our IR team
> (Microsoft Security Response Center or MSRC) and we work closely as
> we're analyzing new security vulnerabilities and working to build on
> them, find patterns, and identify and remove new classes of
> vulnerabilities.  The idea (I used to think it came from Earl Boebert
> but I believe he was quoting Rick Proto) is that theories of security
> come from theories of insecurity.
> 
> We fully understand the need to keep MSEC from getting too large.
> Our budget and planning process are part of our answer to doing that
> - we're essentially a support function, and nobody wants that to get
> too large.  We also avoid taking on tasks that should fall to product
> groups - I guess I could imagine a negative spiral where we did more
> and more of the work that product groups should do, and then had to
> get larger and larger as product teams did less and MSEC had to
> compensate.  But the culture of MSEC is to help the product groups
> with tools, training, consulting and process and hold them
> accountable - not to do their job.  And the product groups also want
> to control their own fates (and code) so they accept the
> responsibility that comes with that model.
> 
> Steve
> 
> -----Original Message----- From: DESAUSOI Alain
> [mailto:Alain.DESAUSOI at swift.com] Sent: Monday, January 04, 2010 7:23
> AM To: Gary McGraw; Secure Code Mailing List; Steve Lipner Cc:
> list-spam at secureconsulting.net; David Ladd Subject: RE: [SC-L]
> InformIT: You need an SSG
> 
> [now posted on sc-l]
> 
> I agree that in an ideal world, security would be naturally built-in
> by delivery and operational teams. They would transparently (?)
> report deviations/risks to central (ERM) team that would handle and
> escalate as appropriate.
> 
>> From my own experience, SWIFT's SSG helps ensure 'right the first
>> time' and 'continuous improvements' on security front. It provides
>> management transparency on risks as well as upstream assurance on
>> what and how things will be/are being done. And it only brings
>> value in as much there is tight 2-way cooperation with delivery and
>> operational teams.
> 
> With the support of senior executives, SSG allows a more natural
> cross fertilisation of risks, threats and solutions across the board,
> in terms of learning, need for infrastructure initiatives, ... Also,
> very much like using external penetration testers provides 'wilder'
> and more update testing techniques, having dedicated SSG helps having
> and outside look and keeping threat/risk management knowledge up to
> date.
> 
> Could the ideal world succeed ?  Probably so, assuming security
> governance, transparency, assurance and discipline.
> 
> I have no experience with large scale organisation (SWIFT is only 500
> developers - SSG is 5 staffs) and we already have the challenge of
> choosing our battles. So, even in those areas that we pamper less,
> the key values I preserve are (1) the ability to provide 'before the
> fact' security assurance on critical projects (critical in terms of
> businesses introducing new threats or arising security challenges)
> (2) sharing findings and lessons learned across the organisation (3)
> some level of assurance by keeping up with penetration testing as a
> motivator and (weak) indicator of alignment.
> 
> In favour of dissemination is the fact that, according to my own
> experience (I have been 15 years on the other side of the fence), SSG
> only really works if they are "on the field" and well accepted by
> delivery/operational teams. The flip side is the need for a strong
> (and harmonised) security culture as it might easily drift away
> according to different business unit leadership: I would think that
> this would be a real challenge for the CISO. This also reflects my
> own experience on the delivery side.
> 
> In summary, SSG provides down-the-earth facts and figures helping
> management making risk balance instead of leaving delivery teams on
> their own. It provides real meat for balancing security measures and
> learning as time goes. I think a reasonably-sized SSG with
> 'satellite' for granularity and scalability is the most appealing
> solution.
> 
>> -----Original Message----- From: Gary McGraw
>> [mailto:gem at cigital.com] Sent: Wednesday, December 23, 2009 3:05 PM
>>  To: Secure Code Mailing List; Steven Lipner; DESAUSOI Alain Cc:
>> list-spam at secureconsulting.net; David Ladd Subject: Re: [SC-L]
>> InformIT: You need an SSG
>> 
>> Hi ben,
>> 
>> I would be very much interested in Steve Lipner's opinion here,
>> because Steve ran the IR program at Microsoft a decade ago before
>> he was recruited to lead the SSG.  Steve, if you would, please take
>> a look at this thread and let us know what your thinking is RE
>> integrating an IR group and/or an SSG completely and almost
>> invisibly into the mother organization after it has matured.
>> 
>> I suspect that some core SSG will always remain even after much of
>> the heavy lifting has been distributed throughout the mother
>> organization by way of satellite.  A ratio of 3:1 (satellite:SSG)
>> is what we observe.
>> 
>> SWIFT also has a long-lived SSG (14 years).  Alain, any insight on
>> this thread you can offer?
>> 
>> gem
>> 
>> company www.cigital.com podcast www.cigital.com/silverbullet blog
>> www.cigital.com/justiceleague book www.swsec.com
>> 
>> 
>> On 12/22/09 8:56 PM, "Benjamin Tomhave"
>> <list-spam at secureconsulting.net> wrote:
>> 
>> Hi Gary,
>> 
>> I've worked with organizations that have taken a similar approach
>> with incident response management. You have a core IR team (within
>> the security dept) and then you designate IR contacts within
>> specific ops teams. This approach seems to work ok, but
>> coordination gets to be problematic, causing me to question
>> scalability and management. Basically, a lot of effort for an
>> impact that seems to follow a logarithmic growth pattern. The more
>> it grows, the more it costs to manage with not as much
>> cost-effectiveness as when the program started.
>> 
>> What I wonder is this: how to do we get from heavy use of
>> "security" SMEs to where "security" is simply SOP? Moreover, is
>> this even a good idea, or particularly realistic? From a CMM
>> perspective, it's akin to our being at Level 0 or 1 right now, with
>> Level 5 being the disappearance of dedicated security personnel
>> because there's no longer a need (achievability aside). It's kind
>> of like dissolving large sugar crystals into water... at first you
>> see the sugar and the water separately... then over time you just
>> see the solution without being able to differentiate sugar from
>> water. Anyway...
>> 
>> -ben
>> 
>> Gary McGraw wrote:
>>> 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-spam at 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, we've helped
>>>> plan, staff, and carry out ten large software security
>>>> initiatives in customer firms.  One of the most important first
>>>> tasks is establishing an SSG.
>>>> 
>>>> 
>>>> Merry New Year everybody.
>>>> 
>>>> 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 at 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. _______________________________________________
>>>> 
>>>> 
>>> -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog: 
>>> http://www.secureconsulting.net/ Twitter: 
>>> http://twitter.com/falconsview Photos: 
>>> http://photos.secureconsulting.net/ Web: 
>>> http://falcon.secureconsulting.net/ LI: 
>>> http://www.linkedin.com/in/btomhave
>>> 
>>> [ Random Quote: ] "The only source of knowledge is experience." 
>>> Albert Einstein
>>> 
>>> 
>>> 
>> -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net Blog:
>> http://www.secureconsulting.net/ Twitter:
>> http://twitter.com/falconsview Photos:
>> http://photos.secureconsulting.net/ Web:
>> http://falcon.secureconsulting.net/ LI:
>> http://www.linkedin.com/in/btomhave
>> 
>> [ Random Quote: ] Hoare's Law of Large Programs: "Inside every
>> large problem is a small problem struggling to get out." 
>> http://globalnerdy.com/2007/07/18/laws-of-software-development/
> 
> 
> 
> 

From list-spam at secureconsulting.net  Wed Jan 13 08:50:44 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 13 Jan 2010 08:50:44 -0500
Subject: [SC-L] [Esapi-user] [Esapi-dev] Recommending ESAPI?
In-Reply-To: <22290cd81001121646q17d0bf46h9c81148157b38a07@mail.gmail.com>
References: <51b4f5741001091648k324b4ae1u5e3fc9b7bb1787c4@mail.gmail.com>
	<4B4C62E7.4090200@owasp.org>	<4348cbf91001121451w37b7599di2c1155f483b0d2bd@mail.gmail.com>
	<4B4D0288.6060708@owasp.org>	<51b4f5741001121638j2628b21cxbb00e2beca59aebd@mail.gmail.com>
	<22290cd81001121646q17d0bf46h9c81148157b38a07@mail.gmail.com>
Message-ID: <4B4DCFB4.6080400@secureconsulting.net>

I don't think I follow, Mike... how do you think Common Criteria or FIPS
140-2 have anything to do with this topic? Accreditation programs are
useful, but only to the degree that they're underpinned by quality
standards, quality technical testing, and competent development programs
concerned with doing the right things in the right way(s).

Mike Boberski wrote:
>> we start to create standards for how Security Controls should behave
> [and basically the rest of the post]
> 
> I submit ASVS for your consideration. If one is further concerned about
> building blocks in the environment, check out Common Criteria and FIPS
> 140-2.
> 
> Also,
> 
> There have also been discussions about creating standardized test suites
> for ESAPI implementations to ensure consistent security checks/effects
> across ESAPI language implementations, but I don't think that's what
> you're getting at.
> 
> It's not hard (with respect) to differentiate interfaces from reference
> implementations from adapters (customized controls), please see the
> design patterns doc I wrote that's posted to the project page. I'm not
> sure I see advantages to further rearranging and splitting out the
> interfaces.
> 
> Best,
> 
> Mike
> 
> 
> On Tue, Jan 12, 2010 at 7:38 PM, Dinis Cruz <dinis.cruz at googlemail.com
> <mailto:dinis.cruz at googlemail.com>> wrote:
> 
>     My view is that the key to make this work is to create the ESTAPI,
>     which is the Enterprise Security *Testing* API
> 
>     This way we would have (for every language):
> 
>         * *ESAPI Interfaces* - which describe the functionality that
>           each security control should have
>         * *ESTAPI* - Unit Tests that check the behaviour of the security
>           controls
>         * *ESAPI Reference Implementation(s) *- Which are
>           (wherever possible) 'production ready' versions of those
>           security controls (and  in most cases a one-to-one mapping to
>           the ESAPI Interfaces)
>         * *Framework XYZ ESAPI 'connectors'* - Which wrap (or expose)
>           the security controls defined in the ESAPI Interfaces in
>           Framework XYZ
> 
>     What I really like about this world, is that we (Application
>     Security Consultants) we start to create standards for how Security
>     Controls should behave. and (as important) are able to work with the
>     Framework developers without they felling that ESAPI is a
>     'competitor' to they Framework. After all, the way we will really
>     change the market is when the Frameworks used by the majority of
>     developers adopt ESAPI (or its principles)
> 
>     Of course that the Framework developers are more than welcomed to
>     grab large parts (or even all) of the code provided by the ESAPI
>     reference implementation(s). But the key is that they (the framework
>     developers) must: a) take ownership of the code and b) respect the
>     ESAPI Interfaces.
> 
>     And hey, if the Framework developers decide NOT to implement a
>     particular security control, that is fine too. 
> 
>     BUT! 
> 
>     I would at least expect them to provide detailed information why
>     they made that decision and why they chose NOT to implement or
>     support it (which would allow us (Security community) to respectably
>     agree or disagree with their choices (hey for some Frameworks, being
>     insecure is a feature :) )
> 
>     Finally, In addition to all the advantages that we will have when
>     frameworks adopt these security controls, there is one that for me
>     is probably the MOST important one: *An 'ESAPI compliant app'*
>     (which btw is a term we still have to agree what exactly means),* is
>     an app that is providing explicit information about where they (the
>     developers) think their (the app) security controls are located*.
> 
>     In another works, via the ESAPI Interfaces (and the ESTAPI tests)
>     the developers are actually telling us (the security consultants): 
>       a) what they think their application's attack surface is and  
>       b) what is the security behaviour that they have already tested for
> 
>     Of course that they can game the system, which is why we (Security
>     Consultants) will still be needed (we will also need to make sure
>     that they implemented the security controls properly). But compare
>     that to today's (2009) world, were we are lucky to get an up-to-date
>     application diagram and a reasonable accurate description of how the
>     application was actually coded and behaves. 
> 
>     This would also (finally) give the application security tools
>     (white, black, glass, gray, pink, blue) a fighting change to
>     automatically, or operator-driven, understand what is going on and
>     report back: 
>       - what it knows (security vulnerabilities) and (as important) 
>       - what it doesn't know / understand
>     (ok there is a lot more that these tools will provide us (for
>     example ESTAPI tests) but that is a topic for another post)
> 
>     So, for me, the key added value of the ESAPI Interfaces, is that it
>     will provide us (Security Consultants) a way to understand how the
>     app works (from a security point of view) and to be able to finally
>     be able to give the clients what they want: Visibility, Assurance
>     and the ability to make 'knowledgeable Risk-based decisions'.
> 
>     Dinis Cruz
> 
>     2010/1/12 Jim Manico <jim.manico at owasp.org
>     <mailto:jim.manico at owasp.org>>
> 
>         Very well said.
> 
>         On this note, I think we may wish to consider formally splitting
>         the interfaces from the reference implementation. We could then
>         build a test framework that's tests those interfaces - so we can
>         verify different implementations of ESAPI. Expand this out in a
>         cross-language way, and we have some serious magic to work with.
> 
>         This is Dinis' idea, but I'm starting to see the light.
> 
>         - Jim
> 
> 
> 
> 
>          
>>         An FYI from personal experience, be extra careful with the
>>         dependencies, particularly if you develop on an appserver that
>>         optimized for debug and production.
>>          
>>         You may need these libraries even if you are not using the
>>         area of the ESAPI RI that uses them.  The -Xverify:none JVM
>>         argument changes how the classloader pre-caches some classes,
>>         particularly Exceptions.  Despite not needing to use safe file
>>         upload capabilities, without that JVM arg is was looking for
>>         Exceptions found in the commons-uploads jar
>>          
>>
>>          
>>         On Tue, Jan 12, 2010 at 6:54 AM, Jim Manico
>>         <jim.manico at owasp.org <mailto:jim.manico at owasp.org>> wrote:
>>
>>             You know Dinis, when I first read your email I was bit
>>             offended. Same with much of John Stevens' email.
>>
>>             But you know? You are trying to help us. These kinds of
>>             pragmatic questions need to be answered.
>>
>>             So here goes.
>>
>>>             Following the recent thread on Java 6 security and
>>>             ESAPI, I just would like to ask the following
>>>             clarifications: 
>>>
>>>             1) For an existing web application currently using a MVC
>>>             framework (like Spring or Struts) are we today (9th Jan
>>>             2009) officially recommending that this web application
>>>             development team adds OWASP's ESAPI.jar to the list of
>>>             'external' APIs (i.e. libs) they use, support and maintain?
>>
>>             I can personally attest for ESAPI 2.0 rc4 integration into
>>             Struts 1.3.x, where I've used ESAPI for several years,
>>             from the early days. I'm not deeply familiar with Spring.
>>             I would not say this is a trivial exercise, but it
>>             certainly is possible.
>>
>>>
>>>             2) When adopting the OWASP ESAPI's J2EE implementation,
>>>             is ESAPI.jar ALL they need to add? or are there other
>>>             dependencies (i.e. jars) that also need to be added,
>>>             supported and maintained? (for example on the
>>>             '*Dependencies' section of the ESAPI Java EE
>>>             <http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE> page
>>>             (i.e. Tab) it seems to imply that there are other *.jars
>>>             needed)*
>>
>>             ESAPI.jar has significant dependencies - something that is
>>             a problem, in general, in the Java world. I'm optimistic
>>             about the new Java 7 component framework - but that is a
>>             long way off.  In the meantime:
>>
>>             (from
>>             http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE)
>>
>>
>>
>>             /There are no dependencies on the ESAPI *interfaces* other
>>             than standard Java EE. However, the reference
>>             implementation does have dependencies that are detailed
>>             below. The reference implementation takes advantage of a
>>             few existing libraries. _*This list may not be totally
>>             complete.*_ /
>>
>>                 * /DefaultAccessController needs? /
>>                       o /Commons-Configuration 1.5 /
>>
>>                 * /DefaultValidator needs? /
>>                       o /AntiSamy 1.2 (there may be a few transitive
>>                         dependencies here) /
>>                       o /NekoHTML 0.9.5 /
>>                       o /Xerces 2.9.1 /
>>
>>                 * /Log4J Logger needs? /
>>                       o /Log4j 1.2.12 /
>>
>>                 * /DefaultHTTPUtilities needs? /
>>                       o /Commons-FileUpload 1.2 /
>>
>>                 * /WAF needs /
>>                       o /XOM 1.0 (there may be a few transitive
>>                         dependencies here) /
>>                       o /Commons-FileUpload 1.2 /
>>
>>
>>>             *
>>>             *
>>>             3) Where can I find detailed information about each of
>>>             the 9 Security Controls that ESAPI.jar currently
>>>             supports: 1) Authentication, 2) Access control, 3) Input
>>>             validation, 4) Output encoding/escaping, 5) Cryptography,
>>>             6) Error handling and logging, 7) Communication security,
>>>             8) HTTP security and 9) Security configuration? (I took
>>>             this list of controls from the Introduction to ESAPI pdf)
>>>             <http://www.owasp.org/images/8/81/Esapi-datasheet.pdf>
>>
>>             Detailed from a marketing perspective? :) The best
>>             technical information is our Javadoc pages at
>>             http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.html
>>             which are not complete, but are fairly decent. We have
>>             also been very good about answering questions, fast, on
>>             esapi-users and esapi-dev. But you are right - docs are
>>             evolving, but we need more.
>>
>>>             *4) When adopting EASPI.jar, are we recommending that the
>>>             developers should adopt or retrofit their existing code
>>>             on the areas affected by those 9 Security Controls? (i.e.
>>>             code related to: Authentication, Access control, Input
>>>             validation, Output encoding/escaping, Cryptography, Error
>>>             handling and logging, Communication security, HTTP
>>>             security and Security configuration)*
>>>             **
>>             It really depends on the situation. But I get your point -
>>             I've seen the Validator, Encoder, Utils and Error Handling
>>             modules used in retrofitting situations successfully. I'm
>>             not so sure about the others.
>>>             *
>>>             *
>>>             *5) Should we recommend the adoption of ALL 9 Security
>>>             Controls? or are there some controls that are not ready
>>>             today (9 Jan 2009) for production environments and should
>>>             not be recommended? (for example is the 'Authentication'
>>>             control as mature as the 'Error handling and logging'
>>>             control?)*
>>             I personally grade the reference 2.0 implementation as
>>             follows:
>>
>>             1) Authentication   C (Needs deeper enterprise integration)
>>             2) Access control   B- (This is just a really tough issue,
>>             and usually requires deep application-specific context.
>>             Plus we have some good ideas on the table from Beef that
>>             I'd like to consider)
>>             3) Input validation   A- (needs better messaging and
>>             internationalization (thanks Sklarew for making us think
>>             in the right direction about this)
>>             4) Output encoding/escaping   A (Go Jeff, my only A. :) We
>>             do need a performance tuning pass (easy) and DOM XSS
>>             encoding functions)
>>             5) Cryptography  A- (Great work Kevin, this is a huge huge
>>             improvement from 1.4)
>>             6) Error handling and logging  B+ (Nice work on designing
>>             this from Wichers)
>>             7) Communication security ?
>>             8) HTTP security B- (Great utilities! I'd like to see some
>>             of these decoupled a bit more)
>>             9) Security configuration ?
>>
>>             Digging deeper....
>>
>>             I personally use almost all of ESAPI. I've written my own
>>             Hibernate Authentication layer - but it's very specific to
>>             my data model. It's very difficult to decouple this from
>>             my app and would be difficult to donate it to the project
>>             effectively. Same with access control. My data model is
>>             VERY complex, and donating it without SQL scripts,
>>             hibernate configuration, and a whole lot of other code -
>>             is a great challenge. (Not to mention that my employer
>>             owns the code ;) The flat-file authenticator is just a
>>             proof of concept and should never be used in a production
>>             environment of any kind, IMO. The thread-local nature of
>>             the authenticator, while I use it and love it, needs to be
>>             reconsidered since other classes, like the loggers, depend
>>             on it. Error handling is fairly solid - and is only a thin
>>             layer on top of known logging methods + security specific
>>             messaging. The encoder was handed down from Gosling
>>             himself - given to Jeff - who gifted it to us. :) I want
>>             the encoder to be a hard-coded part of ESAPI. :) The
>>             validator and encoder can be dropped into any project
>>             fairly easy. Same with much of the HTTP Utils. The
>>             Encryptor from 1.4 should be avoided, which impacts other
>>             portions of the codebase.
>>             http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html 
>>             . 2.0 is going to be a very big milestone; I'm pretty
>>             stoked about what I'm seeing from the team.
>>
>>
>>             Most importantly, it's easy to use the ESAPI configuration
>>             layer to over-ride any of the reference implementation
>>             with your personal authenticator or access controller (so
>>             long as you implement the ESAPI interfaces), as I have for
>>             my projects.
>>
>>>             *
>>>             *
>>>             *6) Are there commercial (i.e. *paid) *support services
>>>             available for the companies who want to add ESAPI.jar to
>>>             they application?***
>>
>>             I hesitate to mention this, and I'm not trying to pimp -
>>             but I'm respectfully answering all of your questions.
>>             Aspect offers these services. I've been working with Jeff
>>             on some of those efforts. It's working out well for
>>             Aspects clients, I'd dare say. If someone else wishes to
>>             speak up on this topic, please do. Open.
>>>             *
>>>             *
>>>             7) What is the version of ESAPI.jar that we should
>>>             recommend? the version 1.4 (which looks like a stable
>>>             release) or the version 2.0 rc4 (which looks like it is a
>>>             Release Candidate)
>>             ESAPI 1.4.1 is *very *far behind 2.0 rc4.  Java 4 is way
>>             past end of lifecycle - but it's still in very wide use,
>>             so we plan to back-port all of ESAPI 2.0 to 1.4. Or at
>>             least as much as we can. I'm making some changes this week
>>             and plan on releasing 1.4.2 this week.
>>>
>>>             8) Where can I find the documentation of where and how
>>>             ESAPI should be used? More importantly, where can I find
>>>             the information of how it CAN NOT or SHOULD NOT be used
>>>             (i.e. the cases where even when the EASPI.jar are used,
>>>             the application is still vulnerable)
>>             Yea, Docs. We need more docs. Boberski has done incredible
>>             work in this area.
>>>
>>>             9) if there list of companies that have currently added
>>>             ESAPI.jar to their applications and have deployed it?
>>>             (i.e. real world usage of EASPI)
>>             Under "users and adopters"
>>             http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers
>>
>>
>>>
>>>             10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been
>>>             through a security review? and if so where can I read its
>>>             report?
>>             Yes and see #8 sentence 2.
>>>
>>>             11) /*when Jim says /"... you can build a new secure app
>>>             without an ESAPI. But libs like OWASP ESAPI will get you
>>>             there faster and cheaper....", / *do we have
>>>             peer-reviewed data that suports this claim?
>>>             /
>>             Nope. I'm shooting from the hip and I consider this as
>>             common sense. But I agree, we REALLY need more assurance
>>             evidence that is published on the wiki - perhaps we should
>>             run o2 against the ESAPI codebase for starters. Or maybe
>>             someone can donate code review services and publish that
>>             report on our wiki. I hear you. Assurance, published
>>             assurance, is fundamental.
>>>             /
>>>             /
>>>             /12) Is there a roadmap or how-to for companies that wish
>>>             to adopt ESAPI.jar on an a) new application or b)
>>>             existing real-world application'?/
>>             See #8 sentence 2.
>>>             /
>>>             /
>>>             /13) What about the current implementations of ESAPI for
>>>             the other languages. Are we also recommending their use?/
>>             Most are beta or alpha - with sparkles of 1.0. But I'd
>>             love to hear the other language leaders chime in here. I
>>             focus on the Java version of ESAPI.
>>
>>>             /
>>>             /
>>>             /14) If a development team decides to use (for example)
>>>             Spring and ESAPI together in their (new or existing)
>>>             application, what are the recommended 'parts' from each
>>>             of those APIs (Spring and EASPI) that the developers
>>>             should be using? (for example: a) use Encoding from
>>>             ESAPI, b) use Authentication from Spring, c)
>>>             use Authorization from ESAPI, d) use Error Handling from
>>>             Spring, e) use Logging from ESAPI, etc...)/
>>
>>             I just don't know how to answer this question. I think for
>>             starters, the completeness of our encoder helps stop XSS
>>             cold in a way that is a bit better than the frameworks.
>>             And Jeff authorer a great cheat sheet to go alongside it.
>>             http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
>>
>>>             /
>>>             /
>>>             /Thanks/
>>>             /
>>>             /
>>>             /Dinis Cruz/
>>             /
>>             /
>>             I'm not going to shy away from these emails any longer. Is
>>             this all you got, Dinis? John Steven? Bring it on, I'll do
>>             my best to answer as honestly as I can.
>>
>>             But let me tell you, Dinis. I would not consider building
>>             any Java app without ESAPI. :) (please note the "I"
>>             statement - I've been deep in the code for years, I'm not
>>             saying its easy - it requires significant investment of
>>             time to use all of ESAPI as it stands today).
>>
>>             Another 18 hour day - I need sleep. :)
>>
>>             Regards,
>>             - Jim
>>
>>             _______________________________________________
>>             Esapi-dev mailing list
>>             Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>>             https://lists.owasp.org/mailman/listinfo/esapi-dev
>>
>>
> 
> 
>         -- 
>         Jim Manico
>         OWASP Podcast Host/Producer
>         http://www.manico.net
> 
> 
> 
>     _______________________________________________
>     Esapi-user mailing list
>     Esapi-user at lists.owasp.org <mailto:Esapi-user at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/esapi-user
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"When will I learn? The answer to life's problems aren't at the bottom
of a bottle, they're on TV!"
Homer Simpson

From James.R.Lindley at irs.gov  Wed Jan 13 13:06:44 2010
From: James.R.Lindley at irs.gov (Lindley James R)
Date: Wed, 13 Jan 2010 13:06:44 -0500
Subject: [SC-L] Blog skiiers versus snowboarders CISSPs vs programmers
In-Reply-To: <4B4DC969.2080603@secureconsulting.net>
References: <4B4B6627.5040907@secureconsulting.net>	<008301ca93a6$83772c00$8a658400$@com><cd1bdfdd1001121206g616a561dwb2ae4a830aa6a7f6@mail.gmail.com>
	<4B4DC969.2080603@secureconsulting.net>
Message-ID: <64CB1CAFF7F54943AC711BFA52C54B770620B004@NCT0010CP3MB01.ds.irsnet.gov>

I am the designated certification hog (see sigblok) for my group, which
does source code security analysis and pen testing.  So I'm fairly
familiar with what goes into getting and keeping these certs.  And I
don't think that a CISSP is nearly specific enough for software source
code security

Now, I'm not too sure about skiers vs snowboarders, because I've never
done either (acrophobic and unwilling to fall down in slush), but I have
described what I do in source code analysis as "plumbing inspection",
because I have done plumbing.  So if I want to explain to people just
what my job entails, I generally read from the following gospel points.

* If there is one word I would remove from the lexicon of software
development, it is the word "developer", which has as much meaning in
the maturing disciplines of software architecture, engineering, and
construction as the word "scientist" now has in science.  The more
mature a discipline becomes, the more specialized (siloed?) is the
knowledge of the practitioners and the more specifically we have to
describe what they do in order to attain precision.  Joseph Priestly and
Ben Franklin may have been scientists, but no one today is a "chemist"
or even a "physicist", much less a "scientist" in that older sense.
Properly named, they may be an "organic chemist" or "theoretical
physicist specializing in string theory". When people say "developer" in
regard to software engineering, to whom are they referring.  Because
every phases of software development takes a person with a specific
psychological nature and skill set.

* The gregarious nature of a requirements engineer with good writing
skills to identify the stakeholders and use interviewing (and sometimes,
interrogation) techniques to tease out the stake holder's descriptions
of what they want and convert the stakeholders statements to well
written problem space requirements and then to help the project manager
get stakeholder buy-in. The requirements engineer produces the "problem
space".  The requirements engineer is a "people" person.

* The detail oriented nature and rigorous technical/mathematical skills
of the specification engineer, who turns the problem space statements
into mathematically resolvable solution space specifications, where the
boolean results of specification satisfaction generally depends on an
underlying arithmetic condition.  Because if a specification doesn't
resolve mathematically, you can't test it. (Sorry, married to a very
good QA Director.)  The specification writer (engineer) produces the
solution space.

* The visionary, generalist nature of a designer with broad knowledge of
the various technologies and components that will be able to satisfy the
specifications. Able to create detailed data schema and HIPO-type
functions charts, data item definitions, etc.  The architect.  In my
time, thoroughly familiar with James Martin graphics, now with UML and
other such representations.

* The code writer, very detail oriented and skilled in speaking and
writing a non-native language.  In a software construction comparison to
home construction, these are the bricklayers, electricians, carpenters,
plumbers. Able to turn the designer's work into source code.  A code
writer must be thought of as a craftsman at wordsmithery in a non-native
language.  The code writer produces the bricks and mortar of software
construction.  Usually not a people person?

* In far too many software construction enterprises that I have served
with, "giving the requirements to the developers" has meant
short-circuiting from requirements to code writing, which is like
gathering a carpenter, a plumber, an electrician, etc., on an acre lot
and saying, "I want a three bedroom, two bath house on this lot.  Build
me a house."

* Now, if what I do (source code security analysis) is plumbing
inspection, it means that 1) I MUST BE EITHER A MASTER PLUMBER or VERY
WELL VERSED in speaking and writing the same language as the code writer
(i.e., I have to know what good plumbing looks like), 2) I must be VERY
FAMILIAR with poorly constructed source code in that language (I have to
know what bad plumbing looks like), 3) I must know how to REPAIR bad
plumbing, and 4) I don't analyze or assess anything from the
architectural phases (requirements, specifications, design).  So my
plumbing inspector has the psychology and skill set of a code writer
PLUS an ability to teach (explain the results to both technical and
non-technical personnel).

* When it comes to certifications here, pretty much every certification
that I list below is irrelevant (I have an old unlisted C/C++ cert).
I'm looking for (and studying for) a Sun Certified Java Programmer
(SCJP) or a Microsoft Certified Software Developer (MCSD).  I can teach
a good plumber (code writer) how to inspect (analyze code security) in
six+ months at most.  But I don't have the time to teach them plumbing
(coding), especially since the security team DOESN'T plumb (write
programs).  If they aren't good plumbers when they get here, I don't
have the time to teach them the craft.

So, to conclude the rant, IMNSHO, source code security analysis is a
VERY SPECIALIZED sub-field of software construction and DEPTH of
knowledge of code writing is far more valuable than BREADTH of knowledge
of security.  And no tool will ever replace the human element here,
because great craftsmen produce works of art in software form.  And
appreciating a work of art requires a human mind.

JimL
James R Lindley
Senior Technical Analyst
CISSP-ISSAP/ISSEP/ISSMP, CSSLP, CISA, PMP, CHS-III, CNE, 
SSE-CMM Appraiser, MCSE, MCT, CNSS 4013, A+
Advanced Technical Analysis Team
Security Engineering
MITS Cybersecurity
OS:CIO:CS:SE:AA
Cube: NCFB C6-462
Cube: 202-283-1590
Cell: 410-703-4127
An unquenchable thirst for Pierian waters.
 

The information contained in this electronic message and any attachments
contains information that may be confidential and/or privileged.  If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of this information is strictly
prohibited.  If you have received this communication in error, please
notify James R. Lindley immediately by e-mail or by telephone at
202-283-1590, and destroy this communication.  Thank you.

 

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave
Sent: Wednesday, January 13, 2010 8:24 AM
To: Secure Coding
Subject: Re: [SC-L] Blog skiiers versus snowboarders CISSPs vs
programmers

I'm not even sure why we're talking about CISSPs in this regard. Having
a CISSP proves nothing; it's merely a blind HR/recruiter checklist item.
I've personally met dozens of CISSPs who can't answer the most basic of
security questions.

The short-term comes down to what Gary talked about recently, which is
getting a software security group (or team) established and functioning
well. Over time, outreach and education run by the SSG then begins to
permeate the organization until, hopefully, some day, the SSG can shrink
or dissolve and let security stand on its own. We obviously have a long
way to go as an industry before we reach that point.

fwiw.

-ben

Arian J. Evans wrote:
> The software security problem is a huge problem. There are not enough 
> CISSPs to even think about solving this problem.
> 
> CISSPs probably should have a tactical role helping categorize, 
> classify, and facilitate getting things done. Scanner jockeys and 
> network security folk will lead the operational charge to WAF and 
> block and such. (good or bad, you're gonna need this stuff, the 
> problem is just too darn big)
> 
> I don't think many good devs who enjoy building are going to want to 
> change careers to do source code audits. That gets mind numbing 
> awfully fast.
> 
> Developers definitely have a role to play in solving a lot of the 
> basic syntax-attack stuffs, by proper selection and application of 
> modern frameworks, technologies, and gap-APIs (like ESAPI). Most 
> CISSPs lack the skill to provide much value here.
> 
> Design issues will always exist, unless users some day wake up and 
> decide they prefer security over usability. But I don't see that 
> happening any time soon. Heck, my password on all my work machines is 
> "password".
> 
> $0.02 USD.
> 
> ---
> Arian Evans
> capitalist marksman. eats animals.
> 
> 
> 
> On Tue, Jan 12, 2010 at 8:44 AM, Matt Parsons <mparsons1980 at gmail.com>
wrote:
>> I wrote a blog in the state of software security using the analogy of

>> skiers versus snowboarder in the early 90's.
>>
>> Please let me know your thoughts and comments by replying to this 
>> list or my blog.
>>
>> http://parsonsisconsulting.blogspot.com/
>>
>>
>>
>> Thanks,
>> Matt
>>
>>
>>
>> Matt Parsons, MSM, CISSP
>> 315-559-3588 Blackberry
>> 817-294-3789 Home office
>> mailto:mparsons1980 at 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 at 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 at 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.
> _______________________________________________
> 
> 

--
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"I have no special talent. I am only passionately curious."
Albert Einstein
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________


From jim.manico at owasp.org  Fri Jan 15 04:31:32 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Thu, 14 Jan 2010 23:31:32 -1000
Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application
 Security made simple ! | Core Security Patterns Weblog
In-Reply-To: <864293E7-0E93-4C9F-B851-8E514679A5F9@cigital.com>
References: <EA94488A-520A-4194-9542-49D4CBCA3B0B@krvw.com>
	<017201ca8e45$db4e4d70$91eae850$@com>
	<ee8989c1001061336r1552c7e0n116e2f4b1b60df0e@mail.gmail.com>
	<8D3FF1FB-A872-477B-B8E8-C5B326A9577D@cigital.com>
	<1F921991-9B96-4C89-A87F-34A8FFA8F09D@manico.net>
	<B1CB2E52-8712-4206-91CB-20E25507775C@cigital.com>
	<B0A49272-49F9-4058-8566-63071E7388AA@manico.net>
	<B4F65854-916C-441A-B0D3-323C14BA8F54@cigital.com>
	<4B4D8094.6040604@owasp.org>
	<864293E7-0E93-4C9F-B851-8E514679A5F9@cigital.com>
Message-ID: <4B5035F4.3010901@owasp.org>


> Good comments man,
>
> I much prefer this level of discourse to what I saw previously.

Thank you, I appreciate that and I do value your input, John.

> I think you mistook my ultra-vague and in-specific template pattern
> reference. I made the same such reference at the 1.4 summit and no one
> seemed to bite. I'll have to find the time to write an example
> up... ...but Joel and I have had bigger fish to fry.

Yes, I hold you to a higher standard of clarity when talking about
something so crucial as specific design pattern recommendations. I know
you are very busy, but if you include even a few minutes of pseudo code
with your suggestions it will help us all. Ultra-vague references do not
help - nor do they even meet your own self-imposed criteria for
excellence which you describe below. ;)

> And note that even communists keep track of data. Prior to this google
> debacle, the Chinese did a very effective round of government reform
> based on data they'd culled from their populous regarding living
> standards, literacy, and public opinion.

And they completely misused that data. The Chinese "pulled the switch"
on 300 million citizens last year, giving them middle class benefits
right as the global economy failed. If you read foreign affairs
magazine, I can point you to primary sources.
>
> ...but you know I'm just pulling your chain on that. If I thought of
> OWASP as communists, I wouldn't hold them to the accord I hold my
> consultants and customers... of which I make the same demands for
> improvement.
>
> -jOHN
> ...and please rest assured, I hold myself to the highest standard.
> Currently, I self-assess my current project at 5-7% effectiveness. I'm
> not just a masochist though: current data, though conservative, bears
> this out. Whereas, the way my current clients evaluate me, they think
> I've been effective at providing a 40-70% improvement. I just
> understand their measurement is naive. I think the principal
> difference between myself and most of OWASP is this: I think it's OK
> to have only provided 5% value. 
>
> Altruism (volunteer army, open-source) doesn't cause me to grade on a
> curve. I understand that is an insanely unpopular stance to take
> within the group--and understand I will remain an outsider as a
> result. That doesn't change my feelings on the matter: 1) OWASP is
> immensely valuable and 2) OWASP needs immensely to improve.

Very well said. But you are missing the real the real way that OWASP
values it's members. Talk is cheap and you get very few points for an
idea. It's those that really dig in and try to help the community with
actual volunteerism and project help that are most valued in OWASP.
Outsiders who throw complaints without real solutions or research or
assistance are basically poison pills to the organization. But that
said, we need critique here at ESAPI central, and I will continue to
look for your counsel and advice.

And as a side note, I think many of your concerns are justified. I am
petitioning the ESAPI team to relabel different versions of ESAPI as
ALPHA/BETA where appropriate, an opinion that is sure to bring me heat
from many directions.

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net




>
> :-D
>
> On Jan 13, 2010, at 3:13 AM, Jim Manico wrote:
>
>> On 1/11/2010 3:42 PM, John Steven wrote:
>>
>> > As a last resort, might I suggest using inheritance and
>> encapsulation to stitch together framework-provided cut points and
>> ESAPI code.
>>
>> This is where ESAPI will evolve. For starters, we need to get our
>> base controls right. :) This is the hallmark of complicated
>> engineering fields like robotics - start small, get it working and
>> add complexity over time.
>>
>> > For instance, one can simulate [the dreaded] 'multiple inheritance'
>> of both Struts and ESAPI base classes by using the template method
>> pattern within a sub-class of (say) the struts-provided class, which,
>> implementing the template method pattern, would call security
>> controls (such as validation or the largely vestigial ESAPI
>> authentication checks) before handing off to end-application
>> developer code that handles other controller functionality/business
>> logic.
>>
>> Interesting. Keep in mind, template pattern implies some kind of
>> shared functionality. I would not call interfaces (ie: Java's
>> substitution for standard multiple-inheritance) dreaded when used
>> appropriately. Interfaces are "clean" and do not carry any baggage
>> (ie: functionality). It's my opinion that the ESAPI interfaces are
>> ESAPI's gold - we are trying to suggest a few (100 or so) methods
>> that you organization needs to have at the app level (in some form or
>> another) in order to build secure apps.  Template pattern might be
>> more appropriate for a C+ ESAPI, but not Java, IMO, in this specific
>> case. Each language-specific version of ESAPI will mandate different
>> patterns. But once we start the ESAPI-Struts and the ESAPI-Spring
>> project, which will happen, template will resurface.
>>
>> Taking a step back - let's take the common notion that we live in a
>> "framework world" and dismiss it. The reality is, many large
>> organizations depend on completely heterogeneous software
>> architectures. I've seen one large org use multiple versions of
>> struts, swing and wicket, in addition to several custom
>> architectures, in addition to old school servlets, using several
>> different servlet containers including one in which they built their
>> own servlet container from scratch and continue to maintain it. This
>> is where an ESAPI is ideal - a common set of centrally maintained
>> controls to pull from.
>>
>> > Personally, for me, the strategy of tacking ESAPI calls onto a
>> developer's application code manually on a case-by-case basis without
>> techniques described above is bound for failure.
>>
>> I think "bound for failure" is an almost dangerous exaggeration.
>> Difficult (at first) and even error prone? Possibly.  Deep framework
>> integration of all of these controls will take time. I originally
>> wanted to make ESAPI a struts project - and just go mad in submitting
>> patches to struts. After ESAPI reaches a measure of stability, I may
>> do just that (ESAPI-Struts!).
>>
>> Also, (your) ESAPI should be part of a well balanced software
>> engineering life-cycle. You need to trust developers to some degree
>> to do the right thing. Trust but verify. This is where code
>> guidelines, code review (and I do not mean security code review, just
>> plain ol review of developers code to ensure they are writing to
>> corporate standards) and other non-security code quality and
>> functionality review techniques come into play.
>>
>> > Developers simply won't be able to reach the total consistency
>> required for robust defense in a large existing application.
>>
>> Well, that speaks of a larger problem - if your coders are all
>> "coders gone wild"- then you are in trouble even before the auditors
>> arrive. Consistency of your codebase is your organizations,
>> architects and other software leaders job.
>>
>> > If you're going to walk this road though for the love of God please
>> deploy SAST to make sure that something is sweeping through and
>> looking for that ever-elusive consistency of application I describe.
>>
>> SAST is a decent value, in some cases, when approaching very insecure
>> code-bases. Turnkey SAST is a waste of money on a mature code base -
>> without custom rules specific to your conventions and controls. And
>> for a very large company? I think *not *moving in the direction of
>> some kind of SAST technology - whether its off the shelf or custom
>> built - is crazy in this day in age. You need some measure of
>> automated code review, but doing it cost effectively can be illusive.
>> Findbugs is a great place to start in the Java world. A few RegEx's
>> specific to YOUR controls and styles go a long way. And if you can
>> afford it, going whole hog on one of the major commercial SAST
>> players with custom rules is not a terrible idea, if you have the
>> AppSec FTE's or consultants available to run and interpret the
>> results. The open source world is behind but will catch up.  I know
>> I'm mixing ideas here, but you get the gist. And these are loaded
>> ideas, I'm curious to hear your response.
>>
>> >  I'd be very-much interested in data regarding faster and cheaper.
>> With the exception of the input validation, canonicalization, and
>> related functionality (*5) it seems like a lot of analysis and
>> integration jobs remain when adopting ESAPI.
>>
>> It took me about 8 hours to port the flat-file authenticator to a
>> high-performance hibernate solution. Perhaps another 16 hours of code
>> tweaking.  I'm not a fan of the ESAPI authenticator as it stands
>> today and I would like to see it evolve. But porting the reference
>> implementation forced me to do it "right" and it did not take long at
>> all. Calling it vestigial is certainly and exaggeration, IMO.
>>
>> > I'd also like to know about bug rates relative to non-ESAPI code.
>> I've been on the ESAPI mailing list for a while and can't discern
>> from conversation much information regarding successful
>> operationalization, though I hear rumblings of people working on this
>> very problem.
>>
>> It difficult to do this without violating non disclosures with
>> clients. But I agree, we need these stats!
>>
>> And I need to be careful here. The world is a very meaningless place
>> if you over-analyze it. I'm in the trenches trying to support the
>> developers who are donating their time to build open source security
>> libraries in order to make the world a better place in some small
>> way. My personal goal is to make the entire application security
>> industry disappear and/or shrink so AppSec is just a standard set on
>> line items on each software projects SOW. Communists? Maybe. But we
>> are making a difference.
>>
>> These are all my opinions and do not necessarily represent the
>> "official" position of OWASP, if such a thing even exists (yet).
>> -- 
>> Jim Manico
>> OWASP Podcast Host/Producer
>> http://www.manico.net
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100114/697d9503/attachment.htm>

From jim.manico at owasp.org  Mon Jan 18 01:44:03 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Sun, 17 Jan 2010 20:44:03 -1000
Subject: [SC-L] ESAPI for JavaScript!
Message-ID: <4B540333.2020502@owasp.org>

The newest version of ESAPI4JS is out! There are some significant new
features, namely i18n support and validation.

You can download the 0.1.2 distribution here:
http://code.google.com/p/owasp-esapi-js/downloads/detail?name=esapi4js-0.1.2.zip

As always, comments and questions are welcome and encouraged directly to
the projects author at chrisisbeef at gmail.com !

Other ESAPI resources:

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

Thanks all.

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100117/f0e209e5/attachment.htm>

From dinis.cruz at googlemail.com  Tue Jan 19 20:48:29 2010
From: dinis.cruz at googlemail.com (Dinis Cruz)
Date: Wed, 20 Jan 2010 01:48:29 +0000
Subject: [SC-L] OWASP for Charities: Haiti relief effort
In-Reply-To: <4b5620c7.47c1f10a.1ded.ffff8834@mx.google.com>
References: <4b5620c7.47c1f10a.1ded.ffff8834@mx.google.com>
Message-ID: <51b4f5741001191748w7b01e034m4f6e4fbf49151fac@mail.gmail.com>

Hi, there are days that I am really proud of being part of the OWASP
community, today is one of those days :)

The Haiti tragedy prompt the OWASP community to kickstart a project that we
have talked about several times in the past but never got around to do it:
the OWASP for Charities project.

You can read all about it in the email included below. This email was sent
to all our mailing-list subscribers (more than 10,000), and it looks like we
are on to something, since we already had some great responses. One in
particular was really good: *"...rebuild digital infrastructure ... there is
a need for IT infrastructure to support the  immediate relief efforts...
people to set up local networks and links between the diff countries (US,
France, Spain, etc) who are all working to aid but are not tied together....
 or help keep PCs/net work devices etc running, basic tech support..."*

I just wrote a blog entry with the email's content (
http://bit.ly/OWASP-Haiti) and I would really appreciate if you linked to
it, or just reused its content on your own blog, or redistributed it to your
internal/external mailing lists.

Lets use this opportunity to build a team that is focused on helping others,
since we never know where it will happen next.

Please join us at the OWASP for Charities project, and in the short term in
supporting the Haiti relief effort.

Thanks

Dinis Cruz
OWASP Board Member

---------- Forwarded message ----------
From: Kate Hartmann <kate.hartmann at owasp.org>
Date: 2010/1/19
Subject: OWASP for Charities: Haiti relief effort
To: Owasp-all at lists.owasp.org

OWASP Members and Supporters,

OWASP was founded, and is supported as a non-profit organization, by a group
of dedicated volunteers who believe that all applications should be secure
and trusted.  As our organization matures we have taken those beliefs
broader, and have started setting up ways for our members to donate to the
global community.  Among these initiatives are:

   - OWASP has an active Kiva lending team who have donated $9,125.00 to
   date.  http://www.kiva.org/community/viewTeam?team_id=522
   - OWASP in response to the need in Haiti has set up a secure and trusted
   way for those within the OWASP community to donate funds to help the people
   of Haiti. This allows our OWASP community to help another with a single
   global voice.  100% of the collected donations will be transferred directly
   to victims for disaster relief such as food and medical requirements.
   Please visit www.owasp.org and click the link for G33k-4-HAITI.  In a
   time of crisis, OWASP can help those who are in great need. The OWASP
   community can help organize, support , and promote efforts outside of
   application security.

OWASP is well aware there is a movement for phishers to utilize this tragedy
to get unsuspecting people to donate to a ?cause? without having a
legitimate business back end and ultimately funneling all the money directly
into their own pockets.  The OWASP community is uniquely qualified to help
protect from this type of attack and educate about attacks as well.

As the world becomes more dependent on technology and particularly web
applications, there are many who need protection who simply have no options
to protect themselves.  These include small companies, individuals,
charities, and others.  The OWASP community can help by connecting
qualified, trusted resources willing to volunteer their time to those
organizations which qualify. OWASP is setting up an outreach program, which
will be under the name project name of OWASP for Charities.

We hope you will support OWASPs efforts to make a difference  in any of the
above ways. We are also open to suggestions in regards to where you feel the
OWASP Community can be of service.

Regards,

Your OWASP Board

Kate Hartmann

OWASP Operations Director
9175 Guilford Road
Suite 300
Columbia, MD  21046
301-275-9403
kate.hartmann at owasp.org
Skype:  kate.hartmann1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100120/0cdb3fea/attachment.htm>

From gem at cigital.com  Thu Jan 21 15:14:55 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 21 Jan 2010 15:14:55 -0500
Subject: [SC-L] Webcast? and BSIMM goes statistical
Message-ID: <C77E1FEF.1D71B%gem@cigital.com>

hi sc-l,

I haven't done a webcast in at least 2 years, but through a communications SNAFU it looks like I am doing one tomorrow for SANS on the BSIMM?!  David Rice is the interviewer.  In case you care:
https://www.sans.org/webcasts/-impact-of-bsi-mm-in-software-development-programs-93194

In other news, the BSIMM now has 30 vectors (that is we have data collected form 30 firms) and we're crunching our statistically significant dataset now with the help of Betsy Nichols.  Results to be presented at RSA.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
podcast www.cigital.com/realitycheck
blog www.cigital.com/justiceleague
book www.swsec.com


From mparsons1980 at gmail.com  Fri Jan 22 05:39:32 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Fri, 22 Jan 2010 04:39:32 -0600
Subject: [SC-L] win win for owasp and television spots
In-Reply-To: <C77E1FEF.1D71B%gem@cigital.com>
References: <C77E1FEF.1D71B%gem@cigital.com>
Message-ID: <000201ca9b4f$3030d9f0$90928dd0$@com>

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:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/





From boberski_michael at bah.com  Fri Jan 22 09:41:24 2010
From: boberski_michael at bah.com (Boberski, Michael [USA])
Date: Fri, 22 Jan 2010 09:41:24 -0500
Subject: [SC-L] win win for owasp and television spots
In-Reply-To: <000201ca9b4f$3030d9f0$90928dd0$@com>
References: <C77E1FEF.1D71B%gem@cigital.com>
	<000201ca9b4f$3030d9f0$90928dd0$@com>
Message-ID: <21D3693DA55EF14BB72DCC18FB65B29102337B2398@ASHBMBX04.resource.ds.bah.com>

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

FWIW,

Best,
 
Mike B.

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at 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:mparsons1980 at 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 at 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.
_______________________________________________


From connectjunkie at gmail.com  Fri Jan 22 09:50:12 2010
From: connectjunkie at gmail.com (Justin Clarke)
Date: Fri, 22 Jan 2010 14:50:12 +0000
Subject: [SC-L] win win for owasp and television spots
In-Reply-To: <000201ca9b4f$3030d9f0$90928dd0$@com>
Message-ID: <C77F6BA4.1715D%connectjunkie@gmail.com>

Hi Matt,

What would be very good is if you can talk to the (newly created) OWASP
Connections Committee. I believe your best contact would be Lorna Alamri,
who is heading up our PR initiative.

Best regards

Justin


On 22/01/2010 10:39, "Matt Parsons" <mparsons1980 at gmail.com> wrote:

> 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:mparsons1980 at 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 at 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.
> _______________________________________________



From nmatatall at attinteractive.com  Fri Jan 22 18:52:14 2010
From: nmatatall at attinteractive.com (Neil Matatall)
Date: Fri, 22 Jan 2010 15:52:14 -0800
Subject: [SC-L] win win for owasp and television spots
In-Reply-To: <C77F6BA4.1715D%connectjunkie@gmail.com>
Message-ID: <C77F7A2E.79F%nmatatall@attinteractive.com>

Don?t forget to mention how individuals can get involved with OWASP ;)  Like
mailing lists, local chapter meetings and larger events such as AppSec 2010
(from 9/7-9/10) 

Neil

On 1/22/10 6:50 AM, "Justin Clarke" <connectjunkie at gmail.com> wrote:

> Hi Matt,
> 
> What would be very good is if you can talk to the (newly created) OWASP
> Connections Committee. I believe your best contact would be Lorna Alamri,
> who is heading up our PR initiative.
> 
> Best regards
> 
> Justin
> 
> 
> On 22/01/2010 10:39, "Matt Parsons" <mparsons1980 at gmail.com> wrote:
> 
>> > 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:mparsons1980 at 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 at 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 at 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.
> _______________________________________________
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100122/537e11ff/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4456 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100122/537e11ff/attachment.bin>

From chrisisbeef at gmail.com  Sun Jan 24 02:04:52 2010
From: chrisisbeef at gmail.com (Chris Schmidt)
Date: Sun, 24 Jan 2010 00:04:52 -0700
Subject: [SC-L] ESAPI4JS 0.1.3 Released
Message-ID: <f353a9561001232304n2d587fc2k6ec5273acc484b0e@mail.gmail.com>

The newest installment of ESAPI4JS (v0.1.3) is now available for download.

http://code.google.com/p/owasp-esapi-js/

As always, comments/thoughts/praise/insults are welcome. Please spread the
word.

And remember! "All your DOM Based XSS are belong to us"

version 0.1.3 (01/23/2010)
    General
        * More updates to distribution
        * Cleaned up subversion repository
        * Updated subversion to allow *online* testing

    Validation
        * Implemented i18n support for error messaging

    Logging
        * Fixed overwrite bug in Logging configuration

    Internationalization
        * Created ObjectResourceBundle
        * Moved messaging to a external resource file
        * Add configuration options to ESAPI Config

    HTTPUtils
        * Implemented Cookie-Jar Management
        * Implemented function to get parameters from a GET request


-- 
-- Chris

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

Coming soon OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/

Yet Another Developers Blog
http://yet-another-dev.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100124/9376cb0c/attachment.htm>

From gem at cigital.com  Wed Jan 27 11:48:49 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 27 Jan 2010 11:48:49 -0500
Subject: [SC-L] Silver Bullet 46: David Rice (Geekonomics)
Message-ID: <C785D9D3.1D98E%gem@cigital.com>

hi sc-l,

I'm sure most of you are aware of David Rice's book Geekonomics.  David and I discuss that book, information warfare, the software security market, and most importantly how the market needs to change in episode 46 of Silver Bullet.  I thoroughly enjoyed this conversation.

http://www.cigital.com/silverbullet/show-046/

David will host the SANS software security thing in San Francisco next week.  I am doing one of the keynotes and Michael Howard is giving the other.  Hope to see some of you there.

gem

company www.cigital.com
blog www.cigital.com/justiceleague
book www.swsec.com


From list-spam at secureconsulting.net  Thu Jan 28 13:48:18 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Thu, 28 Jan 2010 13:48:18 -0500
Subject: [SC-L] How a stray mouse click choked the NYSE & cost a bank $150K
Message-ID: <4B61DBF2.1080408@secureconsulting.net>

NYSE has come out with findings on a Credit Suisse initiated DOS
issue... something so small, yet so fundamentally flawed...

http://arstechnica.com/business/news/2010/01/how-a-stray-mouse-click-choked-the-nyse-cost-a-bank-150k.ars

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Science is facts; just as houses are made of stones, so is science made
of facts; but a pile of stones is not a house and a collection of facts
is not necessarily science."
Henri Poincare

From gem at cigital.com  Thu Jan 28 10:34:30 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 28 Jan 2010 10:34:30 -0500
Subject: [SC-L] BSIMM update (informIT)
Message-ID: <C78719EA.1DA9C%gem@cigital.com>

hi sc-l,

David Rice (author of Geekonomics) is chairing the SANS software security summit in San Francisco next week.  As part of the publicity leading up to that event we did a webcast last Friday.  For those of you who were not able to attend the webcast, we captured the audio and video and are hosting that here:

http://www.cigital.com/justiceleague/2010/01/28/bsimm-update/

Among other things, David and I discussed the difference between descriptive models like BSIMM and prescriptive models which purport to tell you what you should do.  I just wrote an article about that for informIT.  The title is

"Cargo Cult Computer Security: Why we need more description and less prescription."
http://www.informit.com/articles/article.aspx?p=1562220

Hope to see some of you in San Francisco.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


From coley at linus.mitre.org  Thu Jan 28 21:04:31 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 28 Jan 2010 21:04:31 -0500 (EST)
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <C78719EA.1DA9C%gem@cigital.com>
References: <C78719EA.1DA9C%gem@cigital.com>
Message-ID: <Pine.GSO.4.64.1001282024090.2536@faron.mitre.org>


Speaking of "top 25 tea leaves," the "bug parade boogeyman" just called 
and reminded me that the 2010 Top 25 is due to be released next Thursday, 
February 4.  Thanks for the plug.

A preview of some of the brand-new features:

1) Data-driven ranking with alternate metrics to feed the brain and
    stimulate wider discussion - featuring special guest star Elizabeth
    Nichols

2) Multiple focus profiles to avoid one-size-fits-all

3) Cross-cutting mitigations that expand far beyond the Top 25 - AND show
    which mitigations address which Top 25's

4) References to resources such as BSIMM (and even that controversial
    bad-boy ESAPI) to get people thinking even more about systematic
    software security

... and a few more tidbits.

This particular Cargo-Culting pseudoscientist has dutifully listened to 
his fellow islanders.  This year we've made shiny new airstrips and 
control towers, and apparently we've already started some fires.  The 
planes will TOTALLY come back!  Or maybe I'm just feeling a little 
whimsical.

- Steve

P.S.  I can't wait until software security becomes an actual science, 
because as we all know, scientists are much too rational to ever indulge 
in self-destructive infighting and name-calling that hinders opportunities 
for progress in their field.

From jim.manico at owasp.org  Sat Jan 30 23:47:18 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Sat, 30 Jan 2010 18:47:18 -1000
Subject: [SC-L] ESAPI 1.4.4 released!
Message-ID: <4B650B56.9000002@owasp.org>

I'm very pleased to announce the release of the OWASP Enterprise 
Security API Library (ESAPI) version 1.4.4 for Java version 1.4 and 
above! This is an open source project under the BSD license.

Changelog:  
http://owasp-esapi-java.googlecode.com/svn/branches/1.4/changelog.txt

Other important links:

    * You may download the complete .zip release at
      http://owasp-esapi-java.googlecode.com/files/ESAPI-1.4.4.zip
    * The ESAPI 1.4.4 Javadoc's can be found here:
      http://owasp-esapi-java.googlecode.com/svn/trunk_doc/1.4.4/index.html
    * ESAPI users may ask questions regarding ESAPI usage and
      configuration here:
      https://lists.owasp.org/mailman/listinfo/esapi-user
    * Developers interested in contributing to ESAPI may sign up for the
      ESAPI developers email list here:
      https://lists.owasp.org/mailman/listinfo/esapi-dev

Our sincere /Mahalo Nui Loa <http://en.wikipedia.org/wiki/Mahalo> /to 
all of the many developers and users who have contributed to the ESAPI 
project in some way.

Warm Regards,

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100130/4fcc0b6f/attachment.htm>

From Kevin.Wall at qwest.com  Tue Feb  2 12:30:27 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Tue, 2 Feb 2010 11:30:27 -0600
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <4B6819A9.5090701@gmail.com>
References: <4B6819A9.5090701@gmail.com>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>

On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:

> Among other things, David [Rice] and I discussed the difference between
> descriptive models like BSIMM and prescriptive models which purport to
> tell you what you should do.  I just wrote an article about that for
> informIT.  The title is
>
> "Cargo Cult Computer Security: Why we need more description and less
> prescription."
> http://www.informit.com/articles/article.aspx?p=1562220

First, let me say that I have been the team lead of a small Software
Security Group (specifically, an Application Security team) at a
large telecom company for the past 11 years, so I am writing this from
an SSG practitioner's perspective.

Second, let me say that I appreciate descriptive holistic approaches to
security such as BSIMM and OWASP's OpenSAMM. I think they are much
needed, though seldom heeded.

Which brings me to my third point. In my 11 years of experience working
on this SSG, it is very rare that application development teams are
looking for a _descriptive_ approach. Almost always, they are
looking for a _prescriptive_ one. They want specific solutions
to specific problems, not some general formula to an approach that will
make them more secure. To those application development teams, something
like OWASP's ESAPI is much more valuable than something like BSIMM or
OpenSAMM. In fact, I you confirm that you BSIMM research would indicate that
many companies' SSGs have developed their own proprietary security APIs
for use by their application development teams. Therefore, to that end,
I would not say we need less _prescriptive_ and more _descriptive_
approaches. Both are useful and ideally should go together like hand and
glove. (To that end, I also ask that you overlook some of my somewhat
overzealous ESAPI developer colleagues who in the past made claims that
ESAPI was the greatest thing since sliced beer. While I am an ardent
ESAPI supporter and contributor, I proclaim it will *NOT* solve our pandemic
security issues alone, nor for the record will it solve world hunger. ;-)

I suspect that this apparent dichotomy in our perception of the
usefulness of the prescriptive vs. descriptive approaches is explained
in part by the different audiences with whom we associate. Hang out with
VPs, CSOs, and executive directors and they likely are looking for advice on
an SSDLC or broad direction to cover their specifically identified
security gaps. However, in the trenches--where my team works--they want
specifics. They ask us "How can you help us to eliminate our specific
XSS or CSRF issues?", "Can you provide us with a secure SSO solution
that is compliant with both corporate information security policies and
regulatory compliance?", etc. If our SSG were to hand them something like
BSIMM, they would come away telling their management that we didn't help
them at all.

This brings me to my fourth, and likely most controversial point. Despite
the interesting historical story about Feynman, I question whether BSIMM
is really "scientific" as the BSIMM community claims. I would contend
that we are only fooling ourselves if we claim otherwise. And while
BSIMM is a refreshing approach opposed to the traditional FUD modus
operandi taken by most security vendors hyping their security products,
I would argue that BSIMM is no more scientific than the those
who gather common quality metrics of counting defects/KLOC. Certainly
there is some correlation there, but cause and effect relationships
are far from obvious and seem to have little predictive accuracy.

Sure, BSIMM _looks_ scientific on the outside, but simply collecting
specific quantifiable data alone does not make something a scientific
endeavor.  Yes, it is a start, but we've been collecting quantifiable
data for decades on things like software defects and I would contend
BSIMM is no more scientific than those efforts. Is BSIMM moving in
the right direction? I think so. But BSIMM is no more scientific
than most of the other areas of computer "science".

To study something scientifically goes _beyond_ simply gathering
observable and measurable evidence. Not only does data needs to be
collected, but it also needs to be tested against a hypotheses that offers
a tentative *explanation* of the observed phenomena;
i.e., the hypotheses should offer some predictive value. Furthermore,
the steps of the experiment must be _repeatable_, not just by
those currently involved in the attempted scientific endeavor, but by
*anyone* who would care to repeat the experiment. If the
steps are not repeatable, then any predictive value of the study is lost.

While I am certainly not privy to the exact method used to arrive at the
BSIMM data (I have read through the "BSIMM Begin" survey, but have not
been involved in a full BSIMM assessment), I would contend that the
process is not repeatable to the necessary degree required by science.
In fact, I would claim in most organizations, you could take any group
of BSIMM interviewers and have them question different people in the
organization using the exact same questions and arrive at different results.
In fact, I am willing to bet that the different members of my Application
Security team who have all worked together for about 8 years would
answer a significant number of the BSIMM Begin survey questions quite
differently. (My explanation for this phenomena is the general observation
that if you ask a group of N engineers for their opinion on something,
they will almost certainly arrive at N+1 different opinions. ;-)

I commend the BSIMM sponsors and leadership of releasing BSIMM under
a Creative Commons license, but at the same time, I challenge them
to put forth additional information explaining their data collection
process and in particular, describing how it
avoids unintentional bias. (E.g., Are assessment participants choose at
random? By whom?  How do you know you have a representative sample of
a company? Etc.)

I also challenge BSIMM to show their data collection is repeatable by
others following their process. The published BSIMM Begin survey is a
good start, but information regarding the full assessment seems to be
lacking.

I challenge BSIMM to put forth their hypotheses, plainly stated.
In your InformIT article, you wrote:

    "Another distinct advantage that descriptive models have over
    prescriptive models is the ability to compare current observations
    with past observations."

In my opinion, comparison of observations from two companies is not
worth the paper that is printed on UNLESS we can extrapolate from
this data and make accurate predictions based on past findings. Therefore,
I also would challenge BSIMM to publicly make some specific predictions
using their model and collected data so that their hypotheses can be
tested independently by others.

Finally, while I would like, as you did, to blame our Computer Security /
software security's "Cargo Cult" mentality on "its relative youth as
a field", I believe there is something deeper going on here. For one,
computer science / IT / whatever you want to call this much broader
field has the same issue. And while computer "science" is young as
measured against most other scientific disciplines, it is by no means an
immature field. (As a discipline, it is much older than I, and trust me,
I am no spring chicken. :)

After observing this field for 30+ years (ouch!), I have concluded that we
have not matured into a science because as a discipline we *do NOT
really want to!*  We can't even decide if we want this study of computers
/ information processing / etc. to be a "science", an "engineering
discipline", or a "craft". (And some even would like it to be an "art".)
Most of us--myself included--are too lazy to do the disciplined work
that true science requires, and that includes having enough guts to
challenge the academic culture and *demand* funding to do well-designed
scientific experiment in our discipline at our leading universities. IMO,
if we fail to do this, CS is doomed to always remain a science wannabe.

Some would say that because our broader field of study--whether you
call it Computer Science, Computer Engineering, Information Science,
whatever--is part science, part engineering, part craft, and part
something unique that humanity has never before encountered, attempts
to treat it as a science will not succeed. However, surely this does
not mean that we should not attempt to add some scientific rigor to
it as a discipline. To that end efforts such as BSIMM should be welcomed
by all.  But is also important for those who prefer _descriptive_ approaches
like BSIMM, to acknowledge the importance of _prescriptive_ approaches
such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
approaches to be successful.

Regards,
-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From coley at linus.mitre.org  Tue Feb  2 16:12:22 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 2 Feb 2010 16:12:22 -0500 (EST)
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
References: <4B6819A9.5090701@gmail.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <Pine.GSO.4.64.1002021544290.917@faron.mitre.org>


On Tue, 2 Feb 2010, Wall, Kevin wrote:

> To study something scientifically goes _beyond_ simply gathering
> observable and measurable evidence. Not only does data needs to be
> collected, but it also needs to be tested against a hypotheses that offers
> a tentative *explanation* of the observed phenomena;
> i.e., the hypotheses should offer some predictive value. Furthermore,
> the steps of the experiment must be _repeatable_, not just by
> those currently involved in the attempted scientific endeavor, but by
> *anyone* who would care to repeat the experiment. If the
> steps are not repeatable, then any predictive value of the study is lost.

I believe that the cross-industry efforts like BSIMM, ESAPI, top-n lists, 
SAMATE, etc. are largely at the beginning of the data collection phase. 
It shouldn't be much of a surprise that the many companies participate in 
two or more of these efforts (although simultaneously disconcerting, but 
that's probably what happens in brand-new areas).

Ultimately, I would love to see the kind of linkage between the collected 
data ("evidence") and some larger goal ("higher security" whatever THAT 
means in quantitative terms) but if it's out there, I don't see it, or 
it's in tiny pieces... and it may be a few years before we get to that 
point.  CVE data and trends have been used in recent years, or should I 
say abused or misused, because of inherent bias problems that I'm too lazy 
to talk about at the moment.

In CWE, one aspect of our research is to tie attacks to weaknesses, 
weaknesses to mitigations, etc. so that there is better understanding of 
all the inter-related pieces.  So when you look at the CERT C coding 
standard and its ties back to CWE, you see which rules directly 
reduce/affect which weaknesses, and which ones don't.  (Or, you *could*, 
if you wanted to look at it closely enough).

The 2010 OWASP Top 10 RC1 is more data-driven than previous versions; same 
with the 2010 Top 25 (whose release has been delayed to Feb 16, btw). 
Unlike last year's Top 25 effort, this time I received several sources of 
raw prevalence data, but unfortunately it wasn't in sufficiently 
consumable form to combine.

In tool analysis efforts such as SAMATE, we are still wrestling with the 
notion of what a "false positive" really means, not to mention the 
challenge of analyzing mountains of raw data, using tools that were 
intended for developers in a third-party consulting context, combined with 
the multitude of perspectives in how weaknesses are described (e.g., what 
do you do if there's a chain from weakness X to Y, and tool 1 reports X, 
and tool 2 reports Y?)

> In fact, I am willing to bet that the different members of my 
> Application Security team who have all worked together for about 8 years 
> would answer a significant number of the BSIMM Begin survey questions 
> quite differently.

Even surveys using much lower-level detailed questions - such as which 
weaknesses on a "nominee list" of 41 are the most important and prevalent 
- have had distinct responses from multiple people within the same 
organization. (I'll touch on this a little more when the 2010 Top 25 is 
released).  Arguably many of these differences in opinion come down to 
variations in context and experience, but unless and until we can model 
"context" in a way that makes our results somewhat shareable, we can't get 
beyond the data collection phase.

I for one am pretty satisfied with the rate at which things are 
progressing and am delighted to see that we're finally getting some raw 
data, as good (or as bad) as it may be.  The data collection process, 
source data, metrics, and conclusions associated with the 2010 Top 25 will 
probably be controversial, but at least there's some data to argue about. 
So in that sense, I see Gary's article not so much as a clarion call for 
action to a reluctant and primitive industry, but an early announcement of 
a shift that is already underway.

- Steve

From arian.evans at anachronic.com  Tue Feb  2 16:32:45 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 2 Feb 2010 13:32:45 -0800
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
References: <4B6819A9.5090701@gmail.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>

100% agree with the first half of your response, Kevin. Here's what
people ask and need:


Strategic folks (VP, CxO) most frequently ask:

+ What do I do next? / What should we focus on next? (prescriptive)

+ How do we tell if we are reducing risk? (prescriptive guidance again)

Initially they ask for descriptive information, but once they get
going they need strategic prescriptions.


Tactical folks tend to ask:

+ What should we fix first? (prescriptive)

+ What steps can I take to reduce XSS attack surface by 80%? (yes, a
prescriptive blacklist can work here)


 Implementation level folks ask:

+ What do I do about this specific attack/weakness?

+ How do I make my compensating control (WAF, IPS) block this specific attack?

etc.

BSIMM is probably useful for government agencies, or some large
organizations. But the vast majority of clients I work with don't have
the time or need or ability to take advantage of BSIMM. Nor should
they. They don't need a software security group.

They need a clear-cut tree of prescriptive guidelines that work in a
measurable fashion. I agree and strongly empathize with Gary on many
premises of his article - including that not many folks have metrics,
and tend to have more faith and magic.

But, as should be no surprise, I cateogrically disagree with the
entire concluding paragraph of the article. Sadly it's just more faith
and magic from Gary's end. We all can do better than that.

There are other ways to gather and measure useful metrics easily
without BSIMM. Black Box and Pen Test metrics, and Top(n) List metrics
are metrics, and highly useful metrics. And definitely better than no
metrics.

Pragmatically, I think Ralph Nader fits better than Feynman for this discussion.

Nader's Top(n) lists and Bug Parades earned us many safer-society
(cars, water, etc.) features over the last five decades.

Feynman didn't change much in terms of business SOP.

Good day then,

---
Arian Evans
capitalist marksman. eats animals.



On Tue, Feb 2, 2010 at 9:30 AM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
> On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
>
>> Among other things, David [Rice] and I discussed the difference between
>> descriptive models like BSIMM and prescriptive models which purport to
>> tell you what you should do. ?I just wrote an article about that for
>> informIT. ?The title is
>>
>> "Cargo Cult Computer Security: Why we need more description and less
>> prescription."
>> http://www.informit.com/articles/article.aspx?p=1562220
>
> First, let me say that I have been the team lead of a small Software
> Security Group (specifically, an Application Security team) at a
> large telecom company for the past 11 years, so I am writing this from
> an SSG practitioner's perspective.
>
> Second, let me say that I appreciate descriptive holistic approaches to
> security such as BSIMM and OWASP's OpenSAMM. I think they are much
> needed, though seldom heeded.
>
> Which brings me to my third point. In my 11 years of experience working
> on this SSG, it is very rare that application development teams are
> looking for a _descriptive_ approach. Almost always, they are
> looking for a _prescriptive_ one. They want specific solutions
> to specific problems, not some general formula to an approach that will
> make them more secure. To those application development teams, something
> like OWASP's ESAPI is much more valuable than something like BSIMM or
> OpenSAMM. In fact, I you confirm that you BSIMM research would indicate that
> many companies' SSGs have developed their own proprietary security APIs
> for use by their application development teams. Therefore, to that end,
> I would not say we need less _prescriptive_ and more _descriptive_
> approaches. Both are useful and ideally should go together like hand and
> glove. (To that end, I also ask that you overlook some of my somewhat
> overzealous ESAPI developer colleagues who in the past made claims that
> ESAPI was the greatest thing since sliced beer. While I am an ardent
> ESAPI supporter and contributor, I proclaim it will *NOT* solve our pandemic
> security issues alone, nor for the record will it solve world hunger. ;-)
>
> I suspect that this apparent dichotomy in our perception of the
> usefulness of the prescriptive vs. descriptive approaches is explained
> in part by the different audiences with whom we associate. Hang out with
> VPs, CSOs, and executive directors and they likely are looking for advice on
> an SSDLC or broad direction to cover their specifically identified
> security gaps. However, in the trenches--where my team works--they want
> specifics. They ask us "How can you help us to eliminate our specific
> XSS or CSRF issues?", "Can you provide us with a secure SSO solution
> that is compliant with both corporate information security policies and
> regulatory compliance?", etc. If our SSG were to hand them something like
> BSIMM, they would come away telling their management that we didn't help
> them at all.
>
> This brings me to my fourth, and likely most controversial point. Despite
> the interesting historical story about Feynman, I question whether BSIMM
> is really "scientific" as the BSIMM community claims. I would contend
> that we are only fooling ourselves if we claim otherwise. And while
> BSIMM is a refreshing approach opposed to the traditional FUD modus
> operandi taken by most security vendors hyping their security products,
> I would argue that BSIMM is no more scientific than the those
> who gather common quality metrics of counting defects/KLOC. Certainly
> there is some correlation there, but cause and effect relationships
> are far from obvious and seem to have little predictive accuracy.
>
> Sure, BSIMM _looks_ scientific on the outside, but simply collecting
> specific quantifiable data alone does not make something a scientific
> endeavor. ?Yes, it is a start, but we've been collecting quantifiable
> data for decades on things like software defects and I would contend
> BSIMM is no more scientific than those efforts. Is BSIMM moving in
> the right direction? I think so. But BSIMM is no more scientific
> than most of the other areas of computer "science".
>
> To study something scientifically goes _beyond_ simply gathering
> observable and measurable evidence. Not only does data needs to be
> collected, but it also needs to be tested against a hypotheses that offers
> a tentative *explanation* of the observed phenomena;
> i.e., the hypotheses should offer some predictive value. Furthermore,
> the steps of the experiment must be _repeatable_, not just by
> those currently involved in the attempted scientific endeavor, but by
> *anyone* who would care to repeat the experiment. If the
> steps are not repeatable, then any predictive value of the study is lost.
>
> While I am certainly not privy to the exact method used to arrive at the
> BSIMM data (I have read through the "BSIMM Begin" survey, but have not
> been involved in a full BSIMM assessment), I would contend that the
> process is not repeatable to the necessary degree required by science.
> In fact, I would claim in most organizations, you could take any group
> of BSIMM interviewers and have them question different people in the
> organization using the exact same questions and arrive at different results.
> In fact, I am willing to bet that the different members of my Application
> Security team who have all worked together for about 8 years would
> answer a significant number of the BSIMM Begin survey questions quite
> differently. (My explanation for this phenomena is the general observation
> that if you ask a group of N engineers for their opinion on something,
> they will almost certainly arrive at N+1 different opinions. ;-)
>
> I commend the BSIMM sponsors and leadership of releasing BSIMM under
> a Creative Commons license, but at the same time, I challenge them
> to put forth additional information explaining their data collection
> process and in particular, describing how it
> avoids unintentional bias. (E.g., Are assessment participants choose at
> random? By whom? ?How do you know you have a representative sample of
> a company? Etc.)
>
> I also challenge BSIMM to show their data collection is repeatable by
> others following their process. The published BSIMM Begin survey is a
> good start, but information regarding the full assessment seems to be
> lacking.
>
> I challenge BSIMM to put forth their hypotheses, plainly stated.
> In your InformIT article, you wrote:
>
> ? ?"Another distinct advantage that descriptive models have over
> ? ?prescriptive models is the ability to compare current observations
> ? ?with past observations."
>
> In my opinion, comparison of observations from two companies is not
> worth the paper that is printed on UNLESS we can extrapolate from
> this data and make accurate predictions based on past findings. Therefore,
> I also would challenge BSIMM to publicly make some specific predictions
> using their model and collected data so that their hypotheses can be
> tested independently by others.
>
> Finally, while I would like, as you did, to blame our Computer Security /
> software security's "Cargo Cult" mentality on "its relative youth as
> a field", I believe there is something deeper going on here. For one,
> computer science / IT / whatever you want to call this much broader
> field has the same issue. And while computer "science" is young as
> measured against most other scientific disciplines, it is by no means an
> immature field. (As a discipline, it is much older than I, and trust me,
> I am no spring chicken. :)
>
> After observing this field for 30+ years (ouch!), I have concluded that we
> have not matured into a science because as a discipline we *do NOT
> really want to!* ?We can't even decide if we want this study of computers
> / information processing / etc. to be a "science", an "engineering
> discipline", or a "craft". (And some even would like it to be an "art".)
> Most of us--myself included--are too lazy to do the disciplined work
> that true science requires, and that includes having enough guts to
> challenge the academic culture and *demand* funding to do well-designed
> scientific experiment in our discipline at our leading universities. IMO,
> if we fail to do this, CS is doomed to always remain a science wannabe.
>
> Some would say that because our broader field of study--whether you
> call it Computer Science, Computer Engineering, Information Science,
> whatever--is part science, part engineering, part craft, and part
> something unique that humanity has never before encountered, attempts
> to treat it as a science will not succeed. However, surely this does
> not mean that we should not attempt to add some scientific rigor to
> it as a discipline. To that end efforts such as BSIMM should be welcomed
> by all. ?But is also important for those who prefer _descriptive_ approaches
> like BSIMM, to acknowledge the importance of _prescriptive_ approaches
> such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
> approaches to be successful.
>
> Regards,
> -kevin
> ---
> Kevin W. Wall ? ? ? ? ? Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com ? ?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.
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>


From coley at linus.mitre.org  Tue Feb  2 19:23:32 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 2 Feb 2010 19:23:32 -0500 (EST)
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
References: <4B6819A9.5090701@gmail.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
	<cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.1002021904000.2035@faron.mitre.org>


On Tue, 2 Feb 2010, Arian J. Evans wrote:

> BSIMM is probably useful for government agencies, or some large
> organizations. But the vast majority of clients I work with don't have
> the time or need or ability to take advantage of BSIMM. Nor should
> they. They don't need a software security group.

I'm looking forward to what BSIMM Basic discovers when talking to small 
and mid-size developers.  Many of the questions in the survey PDF assume 
that the respondent has at least thought of addressing software security, 
but not all questions assume the presence of an SSG, and there are even 
questions about the use of general top-n lists vs. customized top-n lists 
that may be informative.

- Steve

From list-spam at secureconsulting.net  Tue Feb  2 22:18:54 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Tue, 02 Feb 2010 22:18:54 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
References: <4B6819A9.5090701@gmail.com>	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
	<cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
Message-ID: <4B68EB1E.4050003@secureconsulting.net>

<soapbox>While I can't disagree with this based on modern reality, I'm
increasingly hesitant to allow the conversation to bring in risk, since
it's almost complete garbage these days. Nobody really understands it,
nobody really does it very well (especially if we redact out financial
services and insurance - and even then, look what happened to Wall
Street risk models!), and more importantly, it's implemented so shoddily
that there's no real, reasonable way to actually demonstrate risk
remediation/reduction because talking about it means bringing in a whole
other range of discussions ("what is most important to the business?"
and "how are risk levels defined in business terms?" and "what role do
data and systems play in the business strategy?" and "how does data flow
into and out of the environment?" and so on). Anyway... the long-n-short
is this: let's stop fooling ourselves by pretending that risk has
anything to do with these conversations.</soapbox>

I think:
 - yes to prescriptive!
 - yes to legal/regulatory mandates!
 - caution: we need some sort of evolving maturity framework to which
the previous two points can be pegged!

cheers,

-ben

On 2/2/10 4:32 PM, Arian J. Evans wrote:
> 100% agree with the first half of your response, Kevin. Here's what
> people ask and need:
> 
> 
> Strategic folks (VP, CxO) most frequently ask:
> 
> + What do I do next? / What should we focus on next? (prescriptive)
> 
> + How do we tell if we are reducing risk? (prescriptive guidance again)
> 
> Initially they ask for descriptive information, but once they get
> going they need strategic prescriptions.
> 
> 
> Tactical folks tend to ask:
> 
> + What should we fix first? (prescriptive)
> 
> + What steps can I take to reduce XSS attack surface by 80%? (yes, a
> prescriptive blacklist can work here)
> 
> 
>  Implementation level folks ask:
> 
> + What do I do about this specific attack/weakness?
> 
> + How do I make my compensating control (WAF, IPS) block this specific attack?
> 
> etc.
> 
> BSIMM is probably useful for government agencies, or some large
> organizations. But the vast majority of clients I work with don't have
> the time or need or ability to take advantage of BSIMM. Nor should
> they. They don't need a software security group.
> 
> They need a clear-cut tree of prescriptive guidelines that work in a
> measurable fashion. I agree and strongly empathize with Gary on many
> premises of his article - including that not many folks have metrics,
> and tend to have more faith and magic.
> 
> But, as should be no surprise, I cateogrically disagree with the
> entire concluding paragraph of the article. Sadly it's just more faith
> and magic from Gary's end. We all can do better than that.
> 
> There are other ways to gather and measure useful metrics easily
> without BSIMM. Black Box and Pen Test metrics, and Top(n) List metrics
> are metrics, and highly useful metrics. And definitely better than no
> metrics.
> 
> Pragmatically, I think Ralph Nader fits better than Feynman for this discussion.
> 
> Nader's Top(n) lists and Bug Parades earned us many safer-society
> (cars, water, etc.) features over the last five decades.
> 
> Feynman didn't change much in terms of business SOP.
> 
> Good day then,
> 
> ---
> Arian Evans
> capitalist marksman. eats animals.
> 
> 
> 
> On Tue, Feb 2, 2010 at 9:30 AM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
>> On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
>>
>>> Among other things, David [Rice] and I discussed the difference between
>>> descriptive models like BSIMM and prescriptive models which purport to
>>> tell you what you should do.  I just wrote an article about that for
>>> informIT.  The title is
>>>
>>> "Cargo Cult Computer Security: Why we need more description and less
>>> prescription."
>>> http://www.informit.com/articles/article.aspx?p=1562220
>>
>> First, let me say that I have been the team lead of a small Software
>> Security Group (specifically, an Application Security team) at a
>> large telecom company for the past 11 years, so I am writing this from
>> an SSG practitioner's perspective.
>>
>> Second, let me say that I appreciate descriptive holistic approaches to
>> security such as BSIMM and OWASP's OpenSAMM. I think they are much
>> needed, though seldom heeded.
>>
>> Which brings me to my third point. In my 11 years of experience working
>> on this SSG, it is very rare that application development teams are
>> looking for a _descriptive_ approach. Almost always, they are
>> looking for a _prescriptive_ one. They want specific solutions
>> to specific problems, not some general formula to an approach that will
>> make them more secure. To those application development teams, something
>> like OWASP's ESAPI is much more valuable than something like BSIMM or
>> OpenSAMM. In fact, I you confirm that you BSIMM research would indicate that
>> many companies' SSGs have developed their own proprietary security APIs
>> for use by their application development teams. Therefore, to that end,
>> I would not say we need less _prescriptive_ and more _descriptive_
>> approaches. Both are useful and ideally should go together like hand and
>> glove. (To that end, I also ask that you overlook some of my somewhat
>> overzealous ESAPI developer colleagues who in the past made claims that
>> ESAPI was the greatest thing since sliced beer. While I am an ardent
>> ESAPI supporter and contributor, I proclaim it will *NOT* solve our pandemic
>> security issues alone, nor for the record will it solve world hunger. ;-)
>>
>> I suspect that this apparent dichotomy in our perception of the
>> usefulness of the prescriptive vs. descriptive approaches is explained
>> in part by the different audiences with whom we associate. Hang out with
>> VPs, CSOs, and executive directors and they likely are looking for advice on
>> an SSDLC or broad direction to cover their specifically identified
>> security gaps. However, in the trenches--where my team works--they want
>> specifics. They ask us "How can you help us to eliminate our specific
>> XSS or CSRF issues?", "Can you provide us with a secure SSO solution
>> that is compliant with both corporate information security policies and
>> regulatory compliance?", etc. If our SSG were to hand them something like
>> BSIMM, they would come away telling their management that we didn't help
>> them at all.
>>
>> This brings me to my fourth, and likely most controversial point. Despite
>> the interesting historical story about Feynman, I question whether BSIMM
>> is really "scientific" as the BSIMM community claims. I would contend
>> that we are only fooling ourselves if we claim otherwise. And while
>> BSIMM is a refreshing approach opposed to the traditional FUD modus
>> operandi taken by most security vendors hyping their security products,
>> I would argue that BSIMM is no more scientific than the those
>> who gather common quality metrics of counting defects/KLOC. Certainly
>> there is some correlation there, but cause and effect relationships
>> are far from obvious and seem to have little predictive accuracy.
>>
>> Sure, BSIMM _looks_ scientific on the outside, but simply collecting
>> specific quantifiable data alone does not make something a scientific
>> endeavor.  Yes, it is a start, but we've been collecting quantifiable
>> data for decades on things like software defects and I would contend
>> BSIMM is no more scientific than those efforts. Is BSIMM moving in
>> the right direction? I think so. But BSIMM is no more scientific
>> than most of the other areas of computer "science".
>>
>> To study something scientifically goes _beyond_ simply gathering
>> observable and measurable evidence. Not only does data needs to be
>> collected, but it also needs to be tested against a hypotheses that offers
>> a tentative *explanation* of the observed phenomena;
>> i.e., the hypotheses should offer some predictive value. Furthermore,
>> the steps of the experiment must be _repeatable_, not just by
>> those currently involved in the attempted scientific endeavor, but by
>> *anyone* who would care to repeat the experiment. If the
>> steps are not repeatable, then any predictive value of the study is lost.
>>
>> While I am certainly not privy to the exact method used to arrive at the
>> BSIMM data (I have read through the "BSIMM Begin" survey, but have not
>> been involved in a full BSIMM assessment), I would contend that the
>> process is not repeatable to the necessary degree required by science.
>> In fact, I would claim in most organizations, you could take any group
>> of BSIMM interviewers and have them question different people in the
>> organization using the exact same questions and arrive at different results.
>> In fact, I am willing to bet that the different members of my Application
>> Security team who have all worked together for about 8 years would
>> answer a significant number of the BSIMM Begin survey questions quite
>> differently. (My explanation for this phenomena is the general observation
>> that if you ask a group of N engineers for their opinion on something,
>> they will almost certainly arrive at N+1 different opinions. ;-)
>>
>> I commend the BSIMM sponsors and leadership of releasing BSIMM under
>> a Creative Commons license, but at the same time, I challenge them
>> to put forth additional information explaining their data collection
>> process and in particular, describing how it
>> avoids unintentional bias. (E.g., Are assessment participants choose at
>> random? By whom?  How do you know you have a representative sample of
>> a company? Etc.)
>>
>> I also challenge BSIMM to show their data collection is repeatable by
>> others following their process. The published BSIMM Begin survey is a
>> good start, but information regarding the full assessment seems to be
>> lacking.
>>
>> I challenge BSIMM to put forth their hypotheses, plainly stated.
>> In your InformIT article, you wrote:
>>
>>    "Another distinct advantage that descriptive models have over
>>    prescriptive models is the ability to compare current observations
>>    with past observations."
>>
>> In my opinion, comparison of observations from two companies is not
>> worth the paper that is printed on UNLESS we can extrapolate from
>> this data and make accurate predictions based on past findings. Therefore,
>> I also would challenge BSIMM to publicly make some specific predictions
>> using their model and collected data so that their hypotheses can be
>> tested independently by others.
>>
>> Finally, while I would like, as you did, to blame our Computer Security /
>> software security's "Cargo Cult" mentality on "its relative youth as
>> a field", I believe there is something deeper going on here. For one,
>> computer science / IT / whatever you want to call this much broader
>> field has the same issue. And while computer "science" is young as
>> measured against most other scientific disciplines, it is by no means an
>> immature field. (As a discipline, it is much older than I, and trust me,
>> I am no spring chicken. :)
>>
>> After observing this field for 30+ years (ouch!), I have concluded that we
>> have not matured into a science because as a discipline we *do NOT
>> really want to!*  We can't even decide if we want this study of computers
>> / information processing / etc. to be a "science", an "engineering
>> discipline", or a "craft". (And some even would like it to be an "art".)
>> Most of us--myself included--are too lazy to do the disciplined work
>> that true science requires, and that includes having enough guts to
>> challenge the academic culture and *demand* funding to do well-designed
>> scientific experiment in our discipline at our leading universities. IMO,
>> if we fail to do this, CS is doomed to always remain a science wannabe.
>>
>> Some would say that because our broader field of study--whether you
>> call it Computer Science, Computer Engineering, Information Science,
>> whatever--is part science, part engineering, part craft, and part
>> something unique that humanity has never before encountered, attempts
>> to treat it as a science will not succeed. However, surely this does
>> not mean that we should not attempt to add some scientific rigor to
>> it as a discipline. To that end efforts such as BSIMM should be welcomed
>> by all.  But is also important for those who prefer _descriptive_ approaches
>> like BSIMM, to acknowledge the importance of _prescriptive_ approaches
>> such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
>> approaches to be successful.
>>
>> Regards,
>> -kevin
>> ---
>> Kevin W. Wall           Qwest Information Technology, Inc.
>> Kevin.Wall at qwest.com    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.
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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 at 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.
> _______________________________________________
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Some of us will do our jobs well and some will not, but we will be
judged by only one thing-the result."
Vince Lombardi

From mike.boberski at gmail.com  Tue Feb  2 21:28:26 2010
From: mike.boberski at gmail.com (Mike Boberski)
Date: Tue, 2 Feb 2010 21:28:26 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
References: <4B6819A9.5090701@gmail.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
	<cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
Message-ID: <22290cd81002021828g28742ce6lbe64fb6ca9e9e2e8@mail.gmail.com>

Fun article. To try to be equally pithy in my response: the article reads to
me like a high-tech, application security-specific form of McCarthyism.

To explain...

The amount of reinvention and discussion about the problems in this space is
spectacular.

If one has something to start from which one can then tailor for one's own
purposes, why wouldn't one do this? Does one need to discover SQL injection
on one's own before deciding to do some escaping?

It's crazy in my opinion to think that the majority of the planet has the
expertise let alone the bandwidth (Agile, anyone?) to thoughtfully research
and derive anything that results in a net effect of a targeted, measurable,
comparable level of security.

To all the good folks out there, here is some advice for free: don't start
from scratch, whether it's at the program level, the project level, or the
toolkit level. Use the top x lists to make sure whatever you're doing is up
to date with the latest best practices and technologies. On the subject of
tools and products specifically since the article veers there very
specifically: if you're looking to build or buy a product that provides
security functions, go look into CC. If you're looking at a cryptomodule, go
look into FIPS 140. If you're looking at an enterprise app, go look into
ASVS. If you need a toolkit that validates form input data strings in PHP
using a whitelist because you're trying to provide a first layer of defense
against XSS and SQLi, use BSIMM. Just kidding. Yes, use ESAPI in those
cases.

FWIW,

Best,

Mike


On Tue, Feb 2, 2010 at 4:32 PM, Arian J. Evans
<arian.evans at anachronic.com>wrote:

> 100% agree with the first half of your response, Kevin. Here's what
> people ask and need:
>
>
> Strategic folks (VP, CxO) most frequently ask:
>
> + What do I do next? / What should we focus on next? (prescriptive)
>
> + How do we tell if we are reducing risk? (prescriptive guidance again)
>
> Initially they ask for descriptive information, but once they get
> going they need strategic prescriptions.
>
>
> Tactical folks tend to ask:
>
> + What should we fix first? (prescriptive)
>
> + What steps can I take to reduce XSS attack surface by 80%? (yes, a
> prescriptive blacklist can work here)
>
>
>  Implementation level folks ask:
>
> + What do I do about this specific attack/weakness?
>
> + How do I make my compensating control (WAF, IPS) block this specific
> attack?
>
> etc.
>
> BSIMM is probably useful for government agencies, or some large
> organizations. But the vast majority of clients I work with don't have
> the time or need or ability to take advantage of BSIMM. Nor should
> they. They don't need a software security group.
>
> They need a clear-cut tree of prescriptive guidelines that work in a
> measurable fashion. I agree and strongly empathize with Gary on many
> premises of his article - including that not many folks have metrics,
> and tend to have more faith and magic.
>
> But, as should be no surprise, I cateogrically disagree with the
> entire concluding paragraph of the article. Sadly it's just more faith
> and magic from Gary's end. We all can do better than that.
>
> There are other ways to gather and measure useful metrics easily
> without BSIMM. Black Box and Pen Test metrics, and Top(n) List metrics
> are metrics, and highly useful metrics. And definitely better than no
> metrics.
>
> Pragmatically, I think Ralph Nader fits better than Feynman for this
> discussion.
>
> Nader's Top(n) lists and Bug Parades earned us many safer-society
> (cars, water, etc.) features over the last five decades.
>
> Feynman didn't change much in terms of business SOP.
>
> Good day then,
>
> ---
> Arian Evans
> capitalist marksman. eats animals.
>
>
>
> On Tue, Feb 2, 2010 at 9:30 AM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
> > On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
> >
> >> Among other things, David [Rice] and I discussed the difference between
> >> descriptive models like BSIMM and prescriptive models which purport to
> >> tell you what you should do.  I just wrote an article about that for
> >> informIT.  The title is
> >>
> >> "Cargo Cult Computer Security: Why we need more description and less
> >> prescription."
> >> http://www.informit.com/articles/article.aspx?p=1562220
> >
> > First, let me say that I have been the team lead of a small Software
> > Security Group (specifically, an Application Security team) at a
> > large telecom company for the past 11 years, so I am writing this from
> > an SSG practitioner's perspective.
> >
> > Second, let me say that I appreciate descriptive holistic approaches to
> > security such as BSIMM and OWASP's OpenSAMM. I think they are much
> > needed, though seldom heeded.
> >
> > Which brings me to my third point. In my 11 years of experience working
> > on this SSG, it is very rare that application development teams are
> > looking for a _descriptive_ approach. Almost always, they are
> > looking for a _prescriptive_ one. They want specific solutions
> > to specific problems, not some general formula to an approach that will
> > make them more secure. To those application development teams, something
> > like OWASP's ESAPI is much more valuable than something like BSIMM or
> > OpenSAMM. In fact, I you confirm that you BSIMM research would indicate
> that
> > many companies' SSGs have developed their own proprietary security APIs
> > for use by their application development teams. Therefore, to that end,
> > I would not say we need less _prescriptive_ and more _descriptive_
> > approaches. Both are useful and ideally should go together like hand and
> > glove. (To that end, I also ask that you overlook some of my somewhat
> > overzealous ESAPI developer colleagues who in the past made claims that
> > ESAPI was the greatest thing since sliced beer. While I am an ardent
> > ESAPI supporter and contributor, I proclaim it will *NOT* solve our
> pandemic
> > security issues alone, nor for the record will it solve world hunger. ;-)
> >
> > I suspect that this apparent dichotomy in our perception of the
> > usefulness of the prescriptive vs. descriptive approaches is explained
> > in part by the different audiences with whom we associate. Hang out with
> > VPs, CSOs, and executive directors and they likely are looking for advice
> on
> > an SSDLC or broad direction to cover their specifically identified
> > security gaps. However, in the trenches--where my team works--they want
> > specifics. They ask us "How can you help us to eliminate our specific
> > XSS or CSRF issues?", "Can you provide us with a secure SSO solution
> > that is compliant with both corporate information security policies and
> > regulatory compliance?", etc. If our SSG were to hand them something like
> > BSIMM, they would come away telling their management that we didn't help
> > them at all.
> >
> > This brings me to my fourth, and likely most controversial point. Despite
> > the interesting historical story about Feynman, I question whether BSIMM
> > is really "scientific" as the BSIMM community claims. I would contend
> > that we are only fooling ourselves if we claim otherwise. And while
> > BSIMM is a refreshing approach opposed to the traditional FUD modus
> > operandi taken by most security vendors hyping their security products,
> > I would argue that BSIMM is no more scientific than the those
> > who gather common quality metrics of counting defects/KLOC. Certainly
> > there is some correlation there, but cause and effect relationships
> > are far from obvious and seem to have little predictive accuracy.
> >
> > Sure, BSIMM _looks_ scientific on the outside, but simply collecting
> > specific quantifiable data alone does not make something a scientific
> > endeavor.  Yes, it is a start, but we've been collecting quantifiable
> > data for decades on things like software defects and I would contend
> > BSIMM is no more scientific than those efforts. Is BSIMM moving in
> > the right direction? I think so. But BSIMM is no more scientific
> > than most of the other areas of computer "science".
> >
> > To study something scientifically goes _beyond_ simply gathering
> > observable and measurable evidence. Not only does data needs to be
> > collected, but it also needs to be tested against a hypotheses that
> offers
> > a tentative *explanation* of the observed phenomena;
> > i.e., the hypotheses should offer some predictive value. Furthermore,
> > the steps of the experiment must be _repeatable_, not just by
> > those currently involved in the attempted scientific endeavor, but by
> > *anyone* who would care to repeat the experiment. If the
> > steps are not repeatable, then any predictive value of the study is lost.
> >
> > While I am certainly not privy to the exact method used to arrive at the
> > BSIMM data (I have read through the "BSIMM Begin" survey, but have not
> > been involved in a full BSIMM assessment), I would contend that the
> > process is not repeatable to the necessary degree required by science.
> > In fact, I would claim in most organizations, you could take any group
> > of BSIMM interviewers and have them question different people in the
> > organization using the exact same questions and arrive at different
> results.
> > In fact, I am willing to bet that the different members of my Application
> > Security team who have all worked together for about 8 years would
> > answer a significant number of the BSIMM Begin survey questions quite
> > differently. (My explanation for this phenomena is the general
> observation
> > that if you ask a group of N engineers for their opinion on something,
> > they will almost certainly arrive at N+1 different opinions. ;-)
> >
> > I commend the BSIMM sponsors and leadership of releasing BSIMM under
> > a Creative Commons license, but at the same time, I challenge them
> > to put forth additional information explaining their data collection
> > process and in particular, describing how it
> > avoids unintentional bias. (E.g., Are assessment participants choose at
> > random? By whom?  How do you know you have a representative sample of
> > a company? Etc.)
> >
> > I also challenge BSIMM to show their data collection is repeatable by
> > others following their process. The published BSIMM Begin survey is a
> > good start, but information regarding the full assessment seems to be
> > lacking.
> >
> > I challenge BSIMM to put forth their hypotheses, plainly stated.
> > In your InformIT article, you wrote:
> >
> >    "Another distinct advantage that descriptive models have over
> >    prescriptive models is the ability to compare current observations
> >    with past observations."
> >
> > In my opinion, comparison of observations from two companies is not
> > worth the paper that is printed on UNLESS we can extrapolate from
> > this data and make accurate predictions based on past findings.
> Therefore,
> > I also would challenge BSIMM to publicly make some specific predictions
> > using their model and collected data so that their hypotheses can be
> > tested independently by others.
> >
> > Finally, while I would like, as you did, to blame our Computer Security /
> > software security's "Cargo Cult" mentality on "its relative youth as
> > a field", I believe there is something deeper going on here. For one,
> > computer science / IT / whatever you want to call this much broader
> > field has the same issue. And while computer "science" is young as
> > measured against most other scientific disciplines, it is by no means an
> > immature field. (As a discipline, it is much older than I, and trust me,
> > I am no spring chicken. :)
> >
> > After observing this field for 30+ years (ouch!), I have concluded that
> we
> > have not matured into a science because as a discipline we *do NOT
> > really want to!*  We can't even decide if we want this study of computers
> > / information processing / etc. to be a "science", an "engineering
> > discipline", or a "craft". (And some even would like it to be an "art".)
> > Most of us--myself included--are too lazy to do the disciplined work
> > that true science requires, and that includes having enough guts to
> > challenge the academic culture and *demand* funding to do well-designed
> > scientific experiment in our discipline at our leading universities. IMO,
> > if we fail to do this, CS is doomed to always remain a science wannabe.
> >
> > Some would say that because our broader field of study--whether you
> > call it Computer Science, Computer Engineering, Information Science,
> > whatever--is part science, part engineering, part craft, and part
> > something unique that humanity has never before encountered, attempts
> > to treat it as a science will not succeed. However, surely this does
> > not mean that we should not attempt to add some scientific rigor to
> > it as a discipline. To that end efforts such as BSIMM should be welcomed
> > by all.  But is also important for those who prefer _descriptive_
> approaches
> > like BSIMM, to acknowledge the importance of _prescriptive_ approaches
> > such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
> > approaches to be successful.
> >
> > Regards,
> > -kevin
> > ---
> > Kevin W. Wall           Qwest Information Technology, Inc.
> > Kevin.Wall at qwest.com    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<http://www.cs.utexas.edu/%7EEWD/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.
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L) SC-L at 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 at 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.
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100202/fb11eb05/attachment-0001.htm>

From mike.boberski at gmail.com  Tue Feb  2 21:30:19 2010
From: mike.boberski at gmail.com (Mike Boberski)
Date: Tue, 2 Feb 2010 21:30:19 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <Pine.GSO.4.64.1002021904000.2035@faron.mitre.org>
References: <4B6819A9.5090701@gmail.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
	<cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com> 
	<Pine.GSO.4.64.1002021904000.2035@faron.mitre.org>
Message-ID: <22290cd81002021830r76add2dalf27dfb54dc224a06@mail.gmail.com>

> But the vast majority of clients I work with don't have the time or need
or ability to take advantage of BSIMM

Mike's Top 5 Web Application Security Countermeasures:

1. Add a security guy or gal who has a software development background to
your application's software development team.

2. Turn SSL/TLS on for all connections (including both external and backend
connections) that are authenticated or that involve sensitive data or
functions.

3. Build an Enterprise Security API (a.k.a. an ESAPI, e.g. OWASP's several
different ESAPI toolkits) that is specific to your solution stack and
minimally provides input validation controls that use whitelists, output
encoding/escaping controls (optionally use parameterized interfaces for
SQL), and authentication controls. Build your ESAPI to target a specific
level of overall security when all of your security controls are viewed as a
whole (e.g. an OWASP Application Security Verification Standard (ASVS)
level).

4. Write a programming manual (i.e. a secure coding standard that is
specific to your solution stack that is organized by vulnerability type or
security requirement with before and after code snippets, e.g. a cookbook
that provides before and after code snippets and links to API documentation)
that contains step-by-step instructions for using your ESAPI to both
proactively guard against vulnerabilities, and to act as a quick reference
when the time comes to make fixes.

5. Gate releases of your ESAPI library (e.g. if it is being packaged in a
wrapper for subsequent use by other developers throughout the application)
with security functional tests that include sufficient negative test cases
to demonstrate the security controls are working using data that is specific
to your application. Gate releases of your application (ideally gate source
control checkins) with security-focused code reviews of all new or updated
application code produced during the release (looking out for where new or
updated security controls/security control configuration updates are
needed).

Mike


On Tue, Feb 2, 2010 at 7:23 PM, Steven M. Christey <coley at linus.mitre.org>wrote:

>
> On Tue, 2 Feb 2010, Arian J. Evans wrote:
>
>  BSIMM is probably useful for government agencies, or some large
>> organizations. But the vast majority of clients I work with don't have
>> the time or need or ability to take advantage of BSIMM. Nor should
>> they. They don't need a software security group.
>>
>
> I'm looking forward to what BSIMM Basic discovers when talking to small and
> mid-size developers.  Many of the questions in the survey PDF assume that
> the respondent has at least thought of addressing software security, but not
> all questions assume the presence of an SSG, and there are even questions
> about the use of general top-n lists vs. customized top-n lists that may be
> informative.
>
> - Steve
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100202/a324aac4/attachment.htm>

From James.McGovern at thehartford.com  Wed Feb  3 10:06:21 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Wed, 3 Feb 2010 10:06:21 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <4B68EB1E.4050003@secureconsulting.net>
References: <4B6819A9.5090701@gmail.com>	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM><cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
	<4B68EB1E.4050003@secureconsulting.net>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA02A@AD1HFDEXC312.ad1.prod>

While Wall Street's definition of risk collapsed, the insurance model of
risk stood the test of time :-)

Should we explore your question of "how are risk levels defined in
business terms" more deeply or can we simply say that if you don't have
your own industry-specific regulatory way of quantifying, a good
starting point may be to leverage the OWASP Risk Rating system?

I also would like to challenge and say NO to prescriptive. Security
people are not Vice Presidents of the NO department. Instead we need to
figure out how to align with other value systems (Think Agile
Manifesto). We can be secure without being prescriptive. One example is
to do business exercises such as Protection Poker.

Finally, we shouldn't say yes to regulatory mandates as most of them are
misses on the real risk at hand. The challenge here is that they always
mandate process but never competency. If a regulation said that I should
have someone with a fancy title overseeing a program, the business world
would immediately fill the slot with some non-technical resource who is
really good at PowerPoint but nothing else. In other words a figurehead.
Likewise, while regulations cause people to do things that they should
be doing independently, it has a negative side effect on our economy by
causing folks to spend money in non-strategic ways.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave
Sent: Tuesday, February 02, 2010 10:19 PM
To: Arian J. Evans
Cc: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM update (informIT)

<soapbox>While I can't disagree with this based on modern reality, I'm
increasingly hesitant to allow the conversation to bring in risk, since
it's almost complete garbage these days. Nobody really understands it,
nobody really does it very well (especially if we redact out financial
services and insurance - and even then, look what happened to Wall
Street risk models!), and more importantly, it's implemented so shoddily
that there's no real, reasonable way to actually demonstrate risk
remediation/reduction because talking about it means bringing in a whole
other range of discussions ("what is most important to the business?"
and "how are risk levels defined in business terms?" and "what role do
data and systems play in the business strategy?" and "how does data flow
into and out of the environment?" and so on). Anyway... the long-n-short
is this: let's stop fooling ourselves by pretending that risk has
anything to do with these conversations.</soapbox>

I think:
 - yes to prescriptive!
 - yes to legal/regulatory mandates!
 - caution: we need some sort of evolving maturity framework to which
the previous two points can be pegged!

cheers,

-ben
************************************************************
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.
************************************************************



From list-spam at secureconsulting.net  Wed Feb  3 11:07:15 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 03 Feb 2010 11:07:15 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA02A@AD1HFDEXC312.ad1.prod>
References: <4B6819A9.5090701@gmail.com>	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM><cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>	<4B68EB1E.4050003@secureconsulting.net>
	<BFD50E79FBE23A4FB6BE93572A6FE28702CCA02A@AD1HFDEXC312.ad1.prod>
Message-ID: <4B699F33.80108@secureconsulting.net>

I challenge the validity of any risk assessment/rating approach in use
today in infosec circles, whether it be OWASP or FAIR or IAM/ISAM or
whatever. They are all fundamentally flawed in that they are based on
qualitative values the introduce subjectivity, and they lack the
historical data seen in the actuarial science to make the probability
estimates even remotely reasonable. FAIR tries to compensate for this by
using Bayesian statistics, but the qualitative->quantitative conversion
is still highly problematic.

On prescriptive... the problem is this: businesses will not spend money
unless they're required to do so. Security will never succeed without at
least an initial increased spend. It is exceedingly difficult to make a
well-understood business case for proper security measures and spend. I
think this is something you guys in insurance (you, Chris Hayes, etc.)
perhaps take for granted. The other businesses - especially SMBs - don't
even understand what we're talking about, and they certainly don't have
any interest in dropping a penny on "security" without seeing a direct
benefit.

Do I trust regulators to do things right? Of course not, but that's only
one possible fork. The other possible fork is relying on the courts to
finally catch-up such that case law can develop around defining
"reasonable standard of care" and then evolving it over time. In either
case, you need to set a definitive mark that says "you must do THIS MUCH
or you will be negligent and held accountable." I hate standards like
PCI as much as the next guy because I hate being told how I should be
doing security, but in the short-to-mid-term it's the right approach
because it tells people the expectation for performance. If you never
set expectations for performance, then you shouldn't be disappointed
when people don't achieve them. The bottom line here is that we need to
get far more proactive in the regulatory space so that we can influence
sensible regulations that mandate change rather than relying on
businesses to "do the right thing" without understand the underlying
business value.

Conceptually, I agree with the idealist approach, but in reality I don't
find that it works well at all. I've worked with a half-dozen or more
companies of varying size in the last couple years and NONE of them
understood risk, risk management, current security theory, or how the
implicit AND explicit value of security changes. It's just not intuitive
to most people, not the least of which because bad behaviors are
generally divorced from tangible consequences. Anyway... :)

I can go on forever on this topic... :)

-ben

On 2/3/10 10:06 AM, McGovern, James F. (eBusiness) wrote:
> While Wall Street's definition of risk collapsed, the insurance model of
> risk stood the test of time :-)
> 
> Should we explore your question of "how are risk levels defined in
> business terms" more deeply or can we simply say that if you don't have
> your own industry-specific regulatory way of quantifying, a good
> starting point may be to leverage the OWASP Risk Rating system?
> 
> I also would like to challenge and say NO to prescriptive. Security
> people are not Vice Presidents of the NO department. Instead we need to
> figure out how to align with other value systems (Think Agile
> Manifesto). We can be secure without being prescriptive. One example is
> to do business exercises such as Protection Poker.
> 
> Finally, we shouldn't say yes to regulatory mandates as most of them are
> misses on the real risk at hand. The challenge here is that they always
> mandate process but never competency. If a regulation said that I should
> have someone with a fancy title overseeing a program, the business world
> would immediately fill the slot with some non-technical resource who is
> really good at PowerPoint but nothing else. In other words a figurehead.
> Likewise, while regulations cause people to do things that they should
> be doing independently, it has a negative side effect on our economy by
> causing folks to spend money in non-strategic ways.
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave
> Sent: Tuesday, February 02, 2010 10:19 PM
> To: Arian J. Evans
> Cc: Secure Code Mailing List
> Subject: Re: [SC-L] BSIMM update (informIT)
> 
> <soapbox>While I can't disagree with this based on modern reality, I'm
> increasingly hesitant to allow the conversation to bring in risk, since
> it's almost complete garbage these days. Nobody really understands it,
> nobody really does it very well (especially if we redact out financial
> services and insurance - and even then, look what happened to Wall
> Street risk models!), and more importantly, it's implemented so shoddily
> that there's no real, reasonable way to actually demonstrate risk
> remediation/reduction because talking about it means bringing in a whole
> other range of discussions ("what is most important to the business?"
> and "how are risk levels defined in business terms?" and "what role do
> data and systems play in the business strategy?" and "how does data flow
> into and out of the environment?" and so on). Anyway... the long-n-short
> is this: let's stop fooling ourselves by pretending that risk has
> anything to do with these conversations.</soapbox>
> 
> I think:
>  - yes to prescriptive!
>  - yes to legal/regulatory mandates!
>  - caution: we need some sort of evolving maturity framework to which
> the previous two points can be pegged!
> 
> cheers,
> 
> -ben
> ************************************************************
> 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 at 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.
> _______________________________________________
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Champions aren't made in gyms. Champions are made from something they
have deep inside them - a desire, a dream, a vision. They have to have
last-minute stamina, they have to be a little faster, they have to have
the skill and the will. But the will must be stronger than the skill."
Muhammad Ali

From James.McGovern at thehartford.com  Wed Feb  3 12:05:07 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Wed, 3 Feb 2010 12:05:07 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <4B699F33.80108@secureconsulting.net>
References: <4B6819A9.5090701@gmail.com>	<B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM><cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>	<4B68EB1E.4050003@secureconsulting.net>
	<BFD50E79FBE23A4FB6BE93572A6FE28702CCA02A@AD1HFDEXC312.ad1.prod>
	<4B699F33.80108@secureconsulting.net>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA24D@AD1HFDEXC312.ad1.prod>

OK, being the insurance enterprisey security guy I think you may be onto
something. One of the many reasons why actuarial science can work in
insurance is the fact that there is a lot more public data than in IT
security. If you smash your car into a wall, your chosen carrier doesn't
just pay the claim. This information is shared in what we refer to as
the CLUE database. Other carriers should you decide to switch carriers
will also know the characteristics of your loss. 

CLUE works because folks have figured out that sharing of negative
information can benefit the business. Likewise, CLUE did enough homework
to figure out the right taxonomy and metadata in order to make it
happen. Have security professionals ever figured out how to turn
something bad into something good for the same organization? Have
security professionals ever figured out even how to describe a security
"event" in a consistent enough way such that acturial type calculations
could occur...

FYI. Clue is successful and isn't done for regulatory reasons. It is
done for sound business practice. The same model we should operate
within...

-----Original Message-----
From: Benjamin Tomhave [mailto:list-spam at secureconsulting.net] 
Sent: Wednesday, February 03, 2010 11:07 AM
To: McGovern, James F. (P+C Technology)
Cc: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM update (informIT)

I challenge the validity of any risk assessment/rating approach in use
today in infosec circles, whether it be OWASP or FAIR or IAM/ISAM or
whatever. They are all fundamentally flawed in that they are based on
qualitative values the introduce subjectivity, and they lack the
historical data seen in the actuarial science to make the probability
estimates even remotely reasonable. FAIR tries to compensate for this by
using Bayesian statistics, but the qualitative->quantitative conversion
is still highly problematic.

On prescriptive... the problem is this: businesses will not spend money
unless they're required to do so. Security will never succeed without at
least an initial increased spend. It is exceedingly difficult to make a
well-understood business case for proper security measures and spend. I
think this is something you guys in insurance (you, Chris Hayes, etc.)
perhaps take for granted. The other businesses - especially SMBs - don't
even understand what we're talking about, and they certainly don't have
any interest in dropping a penny on "security" without seeing a direct
benefit.

Do I trust regulators to do things right? Of course not, but that's only
one possible fork. The other possible fork is relying on the courts to
finally catch-up such that case law can develop around defining
"reasonable standard of care" and then evolving it over time. In either
case, you need to set a definitive mark that says "you must do THIS MUCH
or you will be negligent and held accountable." I hate standards like
PCI as much as the next guy because I hate being told how I should be
doing security, but in the short-to-mid-term it's the right approach
because it tells people the expectation for performance. If you never
set expectations for performance, then you shouldn't be disappointed
when people don't achieve them. The bottom line here is that we need to
get far more proactive in the regulatory space so that we can influence
sensible regulations that mandate change rather than relying on
businesses to "do the right thing" without understand the underlying
business value.

Conceptually, I agree with the idealist approach, but in reality I don't
find that it works well at all. I've worked with a half-dozen or more
companies of varying size in the last couple years and NONE of them
understood risk, risk management, current security theory, or how the
implicit AND explicit value of security changes. It's just not intuitive
to most people, not the least of which because bad behaviors are
generally divorced from tangible consequences. Anyway... :)

I can go on forever on this topic... :)

-ben

On 2/3/10 10:06 AM, McGovern, James F. (eBusiness) wrote:
> While Wall Street's definition of risk collapsed, the insurance model 
> of risk stood the test of time :-)
> 
> Should we explore your question of "how are risk levels defined in 
> business terms" more deeply or can we simply say that if you don't 
> have your own industry-specific regulatory way of quantifying, a good 
> starting point may be to leverage the OWASP Risk Rating system?
> 
> I also would like to challenge and say NO to prescriptive. Security 
> people are not Vice Presidents of the NO department. Instead we need 
> to figure out how to align with other value systems (Think Agile 
> Manifesto). We can be secure without being prescriptive. One example 
> is to do business exercises such as Protection Poker.
> 
> Finally, we shouldn't say yes to regulatory mandates as most of them 
> are misses on the real risk at hand. The challenge here is that they 
> always mandate process but never competency. If a regulation said that

> I should have someone with a fancy title overseeing a program, the 
> business world would immediately fill the slot with some non-technical

> resource who is really good at PowerPoint but nothing else. In other
words a figurehead.
> Likewise, while regulations cause people to do things that they should

> be doing independently, it has a negative side effect on our economy 
> by causing folks to spend money in non-strategic ways.
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave
> Sent: Tuesday, February 02, 2010 10:19 PM
> To: Arian J. Evans
> Cc: Secure Code Mailing List
> Subject: Re: [SC-L] BSIMM update (informIT)
> 
> <soapbox>While I can't disagree with this based on modern reality, I'm

> increasingly hesitant to allow the conversation to bring in risk, 
> since it's almost complete garbage these days. Nobody really 
> understands it, nobody really does it very well (especially if we 
> redact out financial services and insurance - and even then, look what

> happened to Wall Street risk models!), and more importantly, it's 
> implemented so shoddily that there's no real, reasonable way to 
> actually demonstrate risk remediation/reduction because talking about 
> it means bringing in a whole other range of discussions ("what is most
important to the business?"
> and "how are risk levels defined in business terms?" and "what role do

> data and systems play in the business strategy?" and "how does data 
> flow into and out of the environment?" and so on). Anyway... the 
> long-n-short is this: let's stop fooling ourselves by pretending that 
> risk has anything to do with these conversations.</soapbox>
> 
> I think:
>  - yes to prescriptive!
>  - yes to legal/regulatory mandates!
>  - caution: we need some sort of evolving maturity framework to which 
> the previous two points can be pegged!
> 
> cheers,
> 
> -ben
> ************************************************************
> 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 at 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.
> _______________________________________________
> 
> 

--
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Champions aren't made in gyms. Champions are made from something they
have deep inside them - a desire, a dream, a vision. They have to have
last-minute stamina, they have to be a little faster, they have to have
the skill and the will. But the will must be stronger than the skill."
Muhammad Ali
************************************************************
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.
************************************************************



From James.McGovern at thehartford.com  Wed Feb  3 13:12:36 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Wed, 3 Feb 2010 13:12:36 -0500
Subject: [SC-L] NIST SP 800-37
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA33E@AD1HFDEXC312.ad1.prod>

NIST has created a draft document entitled: Guide for applying risk
management framework to federal information systems: a security
lifecycle approach. Curious to know if anyone has identified gaps,
differences in opinion, etc between NIST and how either SAMM or BSIMM
would define the same?
************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100203/8d3ba081/attachment.htm>

From ken at krvw.com  Wed Feb  3 16:07:53 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 3 Feb 2010 16:07:53 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <C78719EA.1DA9C%gem@cigital.com>
References: <C78719EA.1DA9C%gem@cigital.com>
Message-ID: <3B8BD8AE-DE4B-4867-9BF7-2E8CFF4A7356@krvw.com>

On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote:
> Among other things, David and I discussed the difference between descriptive models like BSIMM and prescriptive models which purport to tell you what you should do. 

Thought I'd chime in on this a bit, FWIW...  From my perspective, I welcome BSIMM and I welcome SAMM.  I don't see it in the least as a "one or the other" debate.

A decade(ish) since the first texts on various aspects of software security started appearing, it's great to have a BSIMM that surveys some of the largest software groups on the planet to see what they're doing.  What actually works.  That's fabulously useful.  On the other hand, it is possible that ten thousand lemmings can be wrong.  Following the herd isn't always what's best.

SAMM, by contrast, was written by some bright, motivated folks, and provides us all with a set of targets to aspire to.  Some will work, and some won't, without a doubt.

To me, both models are useful as guide posts to help a software group--an SSG if you will--decide what practices will work best in their enterprise.

But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves if we consider these to be standards or even maturity models.  Any other engineering discipline on the planet would laugh us all out of the room by the mere suggestion.  There's value to them, don't get me wrong.  But we're still in the larval mode of building an engineering discipline here folks.  After all, as a species, we didn't start (successfully) building bridges in a decade.

For now, my suggestion is to read up, try things that seem reasonable, and build a set of practices that work for _you_.  

Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100203/bd77d7e6/attachment.bin>

From list-spam at secureconsulting.net  Wed Feb  3 14:15:09 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 03 Feb 2010 14:15:09 -0500
Subject: [SC-L] NIST SP 800-37
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA33E@AD1HFDEXC312.ad1.prod>
References: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA33E@AD1HFDEXC312.ad1.prod>
Message-ID: <4B69CB3D.7040507@secureconsulting.net>

800-37 has been in release for a while, providing the basis for the C&A
process. My understanding is that C&A is evolving (and going the way of
the dinosaur) very soon as NIST works with CNSS/JTF on the next big
thing. I'm blanking on the rest of the details (not my space), but
pinging Mike Smith (@rybolov) or Dan Philpott (@danphilpott) on Twitter
would likely be a good starting point.

On 2/3/10 1:12 PM, McGovern, James F. (eBusiness) wrote:
> NIST has created a draft document entitled: Guide for applying risk 
> management framework to federal information systems: a security 
> lifecycle approach. Curious to know if anyone has identified gaps, 
> differences in opinion, etc between NIST and how either SAMM or
> BSIMM would define the same?
> 
> ************************************************************ 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 at 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. 
> _______________________________________________

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Opportunity is missed by most people because it is dressed in overalls
and looks like work."
Thomas A. Edison

From James.McGovern at thehartford.com  Wed Feb  3 15:45:21 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Wed, 3 Feb 2010 15:45:21 -0500
Subject: [SC-L] [SAMM] NIST SP 800-37
In-Reply-To: <70D4247CD05BD8439BDE923BA3215B7110D08E@S27GE2.office.ascure.com>
References: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA33E@AD1HFDEXC312.ad1.prod>
	<70D4247CD05BD8439BDE923BA3215B7110D08E@S27GE2.office.ascure.com>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702CCA5B6@AD1HFDEXC312.ad1.prod>

I like your take. Maybe the SAMM team could provide formal commentary to
NIST in this regard. I suspect that in not providing feedback, it will
be published and those who read it at a later date will get confused as
to the value proposition of each aka more disturbances in the force...

________________________________

From: samm-bounces at lists.owasp.org [mailto:samm-bounces at lists.owasp.org]
On Behalf Of Bart De Win
Sent: Wednesday, February 03, 2010 2:51 PM
To: Software Assurance Maturity Model (SAMM); SecureCode Mailing List
Subject: Re: [SAMM] NIST SP 800-37



James,

 

I'm not familiar (yet) with the details of SP800-37.

 

However, to add another NIST SP document to this discussion, SP 800-64
(R2 of October 2008) is definitely also worth looking at in the secure
development lifecycle context. Imho, from a bird's eye view, the main
differences between SP 800-64 and SAMM/BSIMM are:

-          The NIST model is a process model, while SAMM and BSIMM are
maturity models. This is a fundamentally different. In that sense, it is
more related to the SDL/CLASP/TouchPoint type of models.

-          In the same line of reasoning, the NIST model is
waterfall-based, while SAMM and BSIMM are actually process agnostic
(they can be applied to waterfall, agile and other types of processes)

-          NIST SP 800-64 focuses much more on deployment, operations
and disposal than any of the other models that I've seen so far.

 

I'd be also interested in hearing any other opinions about this one.

 

Best regards,

Bart.

 

------------
Bart De Win CSSLP
Principal Consultant, CC Leader Application Assurance
Tel.: +32 (0)9 243.10.20, Mob: +32 (0)479 46.79.57

"Ascure, demonstrating excellence in operational risk management"

Looking for world class education? Check-out www.ascureacademy.eu
<http://www.ascureacademy.eu/>  and www.bcmacademy.be
<http://www.ascureacademy.eu/> .

________________________________

This message may be confidential. It is also solely for the use of the
individual or group to whom it is addressed. If you have received it by
mistake, please let us know by e-mail reply. Ascure is not liable for
any direct or indirect damage arising from errors, inaccuracies or any
loss in the message, from unauthorized use, disclosure, copying or
alteration of it. 

For the complete version or other languages of this disclaimer see
http://www.ascure.com/disclaimer.htm
<http://www.ascure.com/disclaimer.htm>  

 

From: samm-bounces at lists.owasp.org [mailto:samm-bounces at lists.owasp.org]
On Behalf Of McGovern, James F. (eBusiness)
Sent: woensdag 3 februari 2010 19:13
To: Secure Code Mailing List; Software Assurance Maturity Model (SAMM)
Subject: [SAMM] NIST SP 800-37

 

NIST has created a draft document entitled: Guide for applying risk
management framework to federal information systems: a security
lifecycle approach. Curious to know if anyone has identified gaps,
differences in opinion, etc between NIST and how either SAMM or BSIMM
would define the same?

************************************************************
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.
************************************************************
************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100203/73053c5b/attachment-0001.htm>

From gem at cigital.com  Wed Feb  3 15:01:37 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Feb 2010 15:01:37 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD323526DE87@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <C78F1C78.1DD99%gem@cigital.com>

hi kevin (and sc-l),

Sorry for the delay responding to this.  I was skiing yesterday with my son Eli and just flew across the country for the SANS summit this morning (leaving behind 6 inches of new snow in VA).  Anyway, better late than never.

I'll interleave responses below.

On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
>> "Cargo Cult Computer Security: Why we need more description and less
>> prescription."  http://www.informit.com/articles/article.aspx?p=1562220

          >On 2/2/10 12:30 PM, "Wall, Kevin" <Kevin.Wall at qwest.com> wrote:
           > In my 11 years of experience working
>on this SSG, it is very rare that application development teams are
>looking for a _descriptive_ approach. Almost always, they are
>looking for a _prescriptive_ one. They want specific solutions
>to specific problems, not some general formula to an approach that will
          >make them more secure.

Absolutely.  I think as an SSG lead in a particular company environment you must have a prescriptive approach but that the approach you develop will be better if informed by data from a descriptive model like BSIMM.  (For the record, I see SAMM as a prescriptive model that tells you often in great detail what your initiative should be doing without knowing one whit about how your organization ticks.)   If you read the article carefully, there are two paragraphs that together should make this clear.

Here's the first:
"Prescriptive models purport to tell you what you should do.  Promulgators of such models say things more like, "the model is chocked full of value judgements [sic] about what organizations SHOULD be doing."   That's just dandy, as long as any prescriptive model only became prescriptive over time based on sufficient observation and testing."

And here's the second:
"Also worthy of mention in this section is the "one size fits all" problem that many prescriptive models suffer from.  The fact is, nobody knows your organizational culture like you do. A descriptive comparison allows you to gather descriptive data and adapt good ideas from others while taking your culture into account."

BSIMM is meant to be a tool for the people running and SSG (and for that matter, strategizing about a company's software security initiative).  The article is really about the differences between BSIMM and SAMM than anything else.  It's not really about the difference between BSIMM and ESAPI.  BSIMM and things like ESAPI fit together.

>Both are useful and ideally should go together like hand and glove.

Exactly right.

>I suspect that this apparent dichotomy in our perception of the
>usefulness of the prescriptive vs. descriptive approaches is explained
>in part by the different audiences with whom we associate.

Agreed.  See above.   BSIMM is a tool for executives to help build, measure, and maintain a software security initiative.

>If our SSG were to hand them something like
>BSIMM, they would come away telling their management that we didn't help
>them at all.

Please do NOT even think about handing the BSIMM to developers as a solution!  The BSIMM is a yardstick for an initiative, and it's meant for a guy like you.  The notion is to measure your own initiative and most importantly of all compare your initiative to your peers.

>This brings me to my fourth, and likely most controversial point. Despite
>the interesting historical story about Feynman, I question whether BSIMM
>is really "scientific" as the BSIMM community claims. I would contend
>that we are only fooling ourselves if we claim otherwise.

I think this is a valid criticism.  The only thing that makes BSIMM more scientific than other methodologies like the Touchoints, SDL, CLASP, or SAMM, is that the BSIMM uses real data and real measurement.  However the measurement technique is certainly not foolproof.  (Incidentally, I state that view pretty clearly in the article...computer science, and other fields with "science" in their name are usually not.)

>While I am certainly not privy to the exact method used to arrive at the
>BSIMM data (I have read through the "BSIMM Begin" survey, but have not
>been involved in a full BSIMM assessment), I would contend that the
>process is not repeatable to the necessary degree required by science.

This criticism holds some water, but you are shooting from the hip and it is pretty clear that you have not read the BSIMM itself.   That, and the first article we wrote about the BSIMM explain our methods pretty clearly. Please read those two things and lets continue this line of questioning.

>I challenge [the BSIMM team] to put forth additional information explaining their data collection
>process and in particular, describing how it avoids unintentional bias. (E.g., Are assessment participants choose >at random? By whom?  How do you know you have a representative sample of
>a company? Etc.)

This is pretty clearly explained in the BSIMM itself.

>In my opinion, comparison of observations from two companies is not
>worth the paper that is printed on UNLESS we can extrapolate from
>this data and make accurate predictions based on past findings.

Given the reaction to actual results from the 30 companies who have participated so far in the study, I'll respectfully call you out as incorrect on that one.  Turns out that most people who run large SSGs and initiatives are hungry for comparison with peers (and indeed want to meet and learn from the peers).  Experience in the field is bearing out the utility of the BSIMM, and the fact that the data we are gathering is supporting the model in important ways is no small potatoes either.

>After observing this field for 30+ years (ouch!), I have concluded that we [computer science]
>have not matured into a science because as a discipline we *do NOT
>really want to!*

Some of us do.  Others don't.  But I think a sea change is underway even in our little subfield of software security

>... efforts such as BSIMM should be welcomed
>by all.  But is also important for those who prefer _descriptive_ approaches
>like BSIMM, to acknowledge the importance of _prescriptive_ approaches

I concur.

Thanks for your carefully considered posting Kevin.  Hope this response is satisfying.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com




From gem at cigital.com  Wed Feb  3 15:01:42 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Feb 2010 15:01:42 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <22290cd81002021828g28742ce6lbe64fb6ca9e9e2e8@mail.gmail.com>
Message-ID: <C78F2A04.1DDA2%gem@cigital.com>

hi mike,

On 2/2/10 9:28 PM, "Mike Boberski" <mike.boberski at gmail.com> wrote:
>Fun article. To try to be equally pithy in my response: the article reads to me like a high-tech, application security-specific >form of McCarthyism.

As a die hard liberal, I take offense to the McCarthy comment (hah).  Anyway some interleaved thoughts...sorry for the delay...etc and so on.

>The amount of reinvention and discussion about the problems in this space is spectacular.  If one has >something to start from which one can then tailor for one's own purposes, why wouldn't one do this? Does one >need to discover SQL injection on one's own before deciding to do some escaping?

I am with you on this.

>It's crazy in my opinion to think that the majority of the planet has the expertise let alone the bandwidth (Agile, >anyone?) to thoughtfully research and derive anything that results in a net effect of a targeted, measurable, >comparable level of security.

Who is arguing that?  Is this supposed to be some straw man for the BSIMM?  I'm lost.  What the heck are you talking about?

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On Tue, Feb 2, 2010 at 4:32 PM, Arian J. Evans <arian.evans at anachronic.com> wrote:
100% agree with the first half of your response, Kevin. Here's what
people ask and need:


Strategic folks (VP, CxO) most frequently ask:

+ What do I do next? / What should we focus on next? (prescriptive)

+ How do we tell if we are reducing risk? (prescriptive guidance again)

Initially they ask for descriptive information, but once they get
going they need strategic prescriptions.


Tactical folks tend to ask:

+ What should we fix first? (prescriptive)

+ What steps can I take to reduce XSS attack surface by 80%? (yes, a
prescriptive blacklist can work here)


 Implementation level folks ask:

+ What do I do about this specific attack/weakness?

+ How do I make my compensating control (WAF, IPS) block this specific attack?

etc.

BSIMM is probably useful for government agencies, or some large
organizations. But the vast majority of clients I work with don't have
the time or need or ability to take advantage of BSIMM. Nor should
they. They don't need a software security group.

They need a clear-cut tree of prescriptive guidelines that work in a
measurable fashion. I agree and strongly empathize with Gary on many
premises of his article - including that not many folks have metrics,
and tend to have more faith and magic.

But, as should be no surprise, I cateogrically disagree with the
entire concluding paragraph of the article. Sadly it's just more faith
and magic from Gary's end. We all can do better than that.

There are other ways to gather and measure useful metrics easily
without BSIMM. Black Box and Pen Test metrics, and Top(n) List metrics
are metrics, and highly useful metrics. And definitely better than no
metrics.

Pragmatically, I think Ralph Nader fits better than Feynman for this discussion.

Nader's Top(n) lists and Bug Parades earned us many safer-society
(cars, water, etc.) features over the last five decades.

Feynman didn't change much in terms of business SOP.

Good day then,

---
Arian Evans
capitalist marksman. eats animals.



On Tue, Feb 2, 2010 at 9:30 AM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
> On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
>
>> Among other things, David [Rice] and I discussed the difference between
>> descriptive models like BSIMM and prescriptive models which purport to
>> tell you what you should do.  I just wrote an article about that for
>> informIT.  The title is
>>
>> "Cargo Cult Computer Security: Why we need more description and less
>> prescription."
>> http://www.informit.com/articles/article.aspx?p=1562220
>
> First, let me say that I have been the team lead of a small Software
> Security Group (specifically, an Application Security team) at a
> large telecom company for the past 11 years, so I am writing this from
> an SSG practitioner's perspective.
>
> Second, let me say that I appreciate descriptive holistic approaches to
> security such as BSIMM and OWASP's OpenSAMM. I think they are much
> needed, though seldom heeded.
>
> Which brings me to my third point. In my 11 years of experience working
> on this SSG, it is very rare that application development teams are
> looking for a _descriptive_ approach. Almost always, they are
> looking for a _prescriptive_ one. They want specific solutions
> to specific problems, not some general formula to an approach that will
> make them more secure. To those application development teams, something
> like OWASP's ESAPI is much more valuable than something like BSIMM or
> OpenSAMM. In fact, I you confirm that you BSIMM research would indicate that
> many companies' SSGs have developed their own proprietary security APIs
> for use by their application development teams. Therefore, to that end,
> I would not say we need less _prescriptive_ and more _descriptive_
> approaches. Both are useful and ideally should go together like hand and
> glove. (To that end, I also ask that you overlook some of my somewhat
> overzealous ESAPI developer colleagues who in the past made claims that
> ESAPI was the greatest thing since sliced beer. While I am an ardent
> ESAPI supporter and contributor, I proclaim it will *NOT* solve our pandemic
> security issues alone, nor for the record will it solve world hunger. ;-)
>
> I suspect that this apparent dichotomy in our perception of the
> usefulness of the prescriptive vs. descriptive approaches is explained
> in part by the different audiences with whom we associate. Hang out with
> VPs, CSOs, and executive directors and they likely are looking for advice on
> an SSDLC or broad direction to cover their specifically identified
> security gaps. However, in the trenches--where my team works--they want
> specifics. They ask us "How can you help us to eliminate our specific
> XSS or CSRF issues?", "Can you provide us with a secure SSO solution
> that is compliant with both corporate information security policies and
> regulatory compliance?", etc. If our SSG were to hand them something like
> BSIMM, they would come away telling their management that we didn't help
> them at all.
>
> This brings me to my fourth, and likely most controversial point. Despite
> the interesting historical story about Feynman, I question whether BSIMM
> is really "scientific" as the BSIMM community claims. I would contend
> that we are only fooling ourselves if we claim otherwise. And while
> BSIMM is a refreshing approach opposed to the traditional FUD modus
> operandi taken by most security vendors hyping their security products,
> I would argue that BSIMM is no more scientific than the those
> who gather common quality metrics of counting defects/KLOC. Certainly
> there is some correlation there, but cause and effect relationships
> are far from obvious and seem to have little predictive accuracy.
>
> Sure, BSIMM _looks_ scientific on the outside, but simply collecting
> specific quantifiable data alone does not make something a scientific
> endeavor.  Yes, it is a start, but we've been collecting quantifiable
> data for decades on things like software defects and I would contend
> BSIMM is no more scientific than those efforts. Is BSIMM moving in
> the right direction? I think so. But BSIMM is no more scientific
> than most of the other areas of computer "science".
>
> To study something scientifically goes _beyond_ simply gathering
> observable and measurable evidence. Not only does data needs to be
> collected, but it also needs to be tested against a hypotheses that offers
> a tentative *explanation* of the observed phenomena;
> i.e., the hypotheses should offer some predictive value. Furthermore,
> the steps of the experiment must be _repeatable_, not just by
> those currently involved in the attempted scientific endeavor, but by
> *anyone* who would care to repeat the experiment. If the
> steps are not repeatable, then any predictive value of the study is lost.
>
> While I am certainly not privy to the exact method used to arrive at the
> BSIMM data (I have read through the "BSIMM Begin" survey, but have not
> been involved in a full BSIMM assessment), I would contend that the
> process is not repeatable to the necessary degree required by science.
> In fact, I would claim in most organizations, you could take any group
> of BSIMM interviewers and have them question different people in the
> organization using the exact same questions and arrive at different results.
> In fact, I am willing to bet that the different members of my Application
> Security team who have all worked together for about 8 years would
> answer a significant number of the BSIMM Begin survey questions quite
> differently. (My explanation for this phenomena is the general observation
> that if you ask a group of N engineers for their opinion on something,
> they will almost certainly arrive at N+1 different opinions. ;-)
>
> I commend the BSIMM sponsors and leadership of releasing BSIMM under
> a Creative Commons license, but at the same time, I challenge them
> to put forth additional information explaining their data collection
> process and in particular, describing how it
> avoids unintentional bias. (E.g., Are assessment participants choose at
> random? By whom?  How do you know you have a representative sample of
> a company? Etc.)
>
> I also challenge BSIMM to show their data collection is repeatable by
> others following their process. The published BSIMM Begin survey is a
> good start, but information regarding the full assessment seems to be
> lacking.
>
> I challenge BSIMM to put forth their hypotheses, plainly stated.
> In your InformIT article, you wrote:
>
>    "Another distinct advantage that descriptive models have over
>    prescriptive models is the ability to compare current observations
>    with past observations."
>
> In my opinion, comparison of observations from two companies is not
> worth the paper that is printed on UNLESS we can extrapolate from
> this data and make accurate predictions based on past findings. Therefore,
> I also would challenge BSIMM to publicly make some specific predictions
> using their model and collected data so that their hypotheses can be
> tested independently by others.
>
> Finally, while I would like, as you did, to blame our Computer Security /
> software security's "Cargo Cult" mentality on "its relative youth as
> a field", I believe there is something deeper going on here. For one,
> computer science / IT / whatever you want to call this much broader
> field has the same issue. And while computer "science" is young as
> measured against most other scientific disciplines, it is by no means an
> immature field. (As a discipline, it is much older than I, and trust me,
> I am no spring chicken. :)
>
> After observing this field for 30+ years (ouch!), I have concluded that we
> have not matured into a science because as a discipline we *do NOT
> really want to!*  We can't even decide if we want this study of computers
> / information processing / etc. to be a "science", an "engineering
> discipline", or a "craft". (And some even would like it to be an "art".)
> Most of us--myself included--are too lazy to do the disciplined work
> that true science requires, and that includes having enough guts to
> challenge the academic culture and *demand* funding to do well-designed
> scientific experiment in our discipline at our leading universities. IMO,
> if we fail to do this, CS is doomed to always remain a science wannabe.
>
> Some would say that because our broader field of study--whether you
> call it Computer Science, Computer Engineering, Information Science,
> whatever--is part science, part engineering, part craft, and part
> something unique that humanity has never before encountered, attempts
> to treat it as a science will not succeed. However, surely this does
> not mean that we should not attempt to add some scientific rigor to
> it as a discipline. To that end efforts such as BSIMM should be welcomed
> by all.  But is also important for those who prefer _descriptive_ approaches
> like BSIMM, to acknowledge the importance of _prescriptive_ approaches
> such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
> approaches to be successful.
>
> Regards,
> -kevin
> ---
> Kevin W. Wall           Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com    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 <http://www.cs.utexas.edu/%7EEWD/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.
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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 at 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.
_______________________________________________




From gem at cigital.com  Wed Feb  3 15:02:09 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Feb 2010 15:02:09 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <22290cd81002021830r76add2dalf27dfb54dc224a06@mail.gmail.com>
Message-ID: <C78F2C49.1DDA5%gem@cigital.com>

Hi again Mike,

Yadda yadda, delay, and so on...

On 2/2/10 9:30 PM, "Mike Boberski" <mike.boberski at gmail.com> wrote:
<somebody eslse said> But the vast majority of clients I work with don't have the time or need or ability to >take advantage of BSIMM

 >>Mike's Top 5 Web Application Security Countermeasures:
>>1. Add a security guy or gal who has a software development background to your application's software >>development team.

Dang, this would have saved Microsoft lots of money.  With 30,000 developers that security gal would have been pretty busy though.

>>3. Build an Enterprise Security API (a.k.a. an ESAPI, e.g. OWASP's several different ESAPI toolkits) that is >>specific to your solution stack and minimally provides input validation controls that use whitelists, output >>encoding/escaping controls (optionally use parameterized interfaces for SQL), and authentication controls. >>Build your ESAPI to target a specific level of overall security when all of your security controls are viewed as >>a whole (e.g. an OWASP Application Security Verification Standard (ASVS) level).

Why do you believe that an ESAPI (which is a good idea) is the best place to start?  Why not training?  Why not pen testing by Mike?  Etc.  This was not "job 1" in any firm I have been involved with.

>>4. Write a programming manual (i.e. a secure coding standard that is specific to your solution stack that is >>organized by vulnerability type or security requirement with before and after code snippets, e.g. a >>cookbook that provides before and after code snippets and links to API documentation) that contains step->>by-step instructions for using your ESAPI to both proactively guard against vulnerabilities, and to act as a >>quick reference when the time comes to make fixes.

Again.  How does this fit into a bigger picture?  The notion of code guidelines is a good one.  See [CR2.1] in the BSIMM which 11 of 30 companies we observed carry out.  This was not "job 2" in any case I am aware of.  How about tying such guidance to code review technology.  We've helped multiple clients do that.

How many customers have followed Mike's Way?  What are their results?  How do the Mike's Way customers score with the BSIMM?

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On Tue, Feb 2, 2010 at 7:23 PM, Steven M. Christey <coley at linus.mitre.org> wrote:

On Tue, 2 Feb 2010, Arian J. Evans wrote:

BSIMM is probably useful for government agencies, or some large
organizations. But the vast majority of clients I work with don't have
the time or need or ability to take advantage of BSIMM. Nor should
they. They don't need a software security group.

I'm looking forward to what BSIMM Basic discovers when talking to small and mid-size developers.  Many of the questions in the survey PDF assume that the respondent has at least thought of addressing software security, but not all questions assume the presence of an SSG, and there are even questions about the use of general top-n lists vs. customized top-n lists that may be informative.

- Steve

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________




From gem at cigital.com  Wed Feb  3 15:04:43 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Feb 2010 15:04:43 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <Pine.GSO.4.64.1002021544290.917@faron.mitre.org>
Message-ID: <C78F410B.1DDA8%gem@cigital.com>

Hi Steve (and sc-l),

I'll invoke my skiing with Eli excuse again on this thread as well...

On Tue, 2 Feb 2010, Wall, Kevin wrote:
> To study something scientifically goes _beyond_ simply gathering
> observable and measurable evidence. Not only does data needs to be
> collected, but it also needs to be tested against a hypotheses that offers
> a tentative *explanation* of the observed phenomena;
> i.e., the hypotheses should offer some predictive value.

On 2/2/10 4:12 PM, "Steven M. Christey" <coley at linus.mitre.org> wrote:
>>I believe that the cross-industry efforts like BSIMM, ESAPI, top-n lists,
>>SAMATE, etc. are largely at the beginning of the data collection phase.

I agree 100%.  It's high time we gathered some data to back up our claims.  I would love to see the top-n lists do more with data.

Here's an example.  In the BSIMM,  10 of 30 firms have built top-N bug lists based on their own data culled from their own code.  I would love to see how those top-n lists compare to the OWASP top ten or the CWE-25.  I would also love to see whether the union of these lists is even remotely interesting.  One of my (many) worries about top-n lists that are NOT bound to a particular code base is that the lists are so generic as to be useless and maybe even unhelpful if adopted wholesale without understanding what's actually going on in a codebase. [see <http://www.informit.com/articles/article.aspx?p=1322398>].

Note for the record that "asking lots of people what they think should be in the top-10" is not quite the same as taking the union of particular top-n lists which are tied to particular code bases.  Popularity contests are not the kind of data we should count on.  But maybe we'll make some progress on that one day.

>Ultimately, I would love to see the kind of linkage between the collected
>data ("evidence") and some larger goal ("higher security" whatever THAT
>means in quantitative terms) but if it's out there, I don't see it

Neither do I, and that is a serious issue with models like the BSIMM that measure "second order" effects like activities.  Do the activities actually do any good?  Important question!

>The 2010 OWASP Top 10 RC1 is more data-driven than previous versions; same
>with the 2010 Top 25 (whose release has been delayed to Feb 16, btw).
>Unlike last year's Top 25 effort, this time I received several sources of
>raw prevalence data, but unfortunately it wasn't in sufficiently
>consumable form to combine.

I was with you up until that last part.  Combining the prevalence data is something you guys should definitely do.  BTW, how is the 2010 CWE-25 (which doesn't yet exist) more data driven??

>I for one am pretty satisfied with the rate at which things are
>progressing and am delighted to see that we're finally getting some raw
>data, as good (or as bad) as it may be.  The data collection process,
>source data, metrics, and conclusions associated with the 2010 Top 25 will
>probably be controversial, but at least there's some data to argue about.

Cool!

>So in that sense, I see Gary's article not so much as a clarion call for
>action to a reluctant and primitive industry, but an early announcement of
>a shift that is already underway.

Well put.

gem

company www.cigital.com
podcast www.cigital.com/~gem
blog www.cigital.com/justiceleague
book www.swsec.com



From gem at cigital.com  Wed Feb  3 15:05:08 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Feb 2010 15:05:08 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
Message-ID: <C78F4124.1DDA8%gem@cigital.com>

Hi Arian,

Some more particulars regarding your posting.  Sorry for the delay...

On 2/2/10 4:32 PM, "Arian J. Evans" <arian.evans at anachronic.com> wrote:
>Strategic folks (VP, CxO) ...Initially ...ask for descriptive information, but once they get
>going they need strategic prescriptions.

Please see my response to Kevin.  I hope it's clear what the BSIMM is for.  It's for measuring your initiative and comparing it to others.  Given some solid BSIMM data, I believe you can do a superior job with strategy...and results measurement.  It is a tool for strategic people to use to build an initiative that works.

>Tactical folks tend to ask:
>+ What should we fix first? (prescriptive)
>+ What steps can I take to reduce XSS attack surface by 80%?

The BSIMM is not for tactical folks.  But should you base your decision regarding "what to fix first" on goat sacrifice?  What should drive that decision?  Moon phase?

> Implementation level folks ask:
>+ What do I do about this specific attack/weakness?
>+ How do I make my compensating control (WAF, IPS) block this specific attack?

BSIMM != code review tool, top-n list, book, coding experience, ...

>BSIMM is probably useful for government agencies, or some large
>organizations. But the vast majority of clients I work with don't have
>the time or need or ability to take advantage of BSIMM. Nor should
>they. They don't need a software security group.

Where to start.  All I can say about BSIMM so far is that is appears to be useful for 30 large commercial organizations carrying out real software security initiatives.  We have studied 0 (count 'em...none) government organizations to date.  In my experience, the government is always lagging when it comes to software security.  I'm hoping to gather some government data forth with, starting with the US Air Force.  We shall see.

But what about SMB (small to medium sized business)?  Arian, who are your clients?  How many developers do they have?  Who do you report to as a consultant?  How do you help them make business decisions?

Regarding the existence of an SSG, see this article <http://www.informit.com/articles/article.aspx?p=1434903>.  Are your customers too small to have an SSG?  Are YOU the SSG?  Are your customers not mature enough for an SSG?  Data would be great.

>I agree and strongly empathize with Gary on many
>premises of his article - including that not many folks have metrics,
>and tend to have more faith and magic.

Sadly I think we're stuck with "second order" metrics like the BSIMM.  Heck, we even studied the metrics that real initiatives use in the BSIMM (bugs per square inch anyone?), but you know what?  Everyone has different metrics.  Really.

>But, as should be no surprise, I cateogrically disagree with the
>entire concluding paragraph of the article. Sadly it's just more faith
>and magic from Gary's end. We all can do better than that.

You guys and your personal attacks.  Yeesh.  I am pretty sure you meant the "next to last" paragraph, because Feynman wrote the entire last one.  Here is the next to last one:

As I have said before, the time has come to put away the bug parade boogeyman <http://www.informit.com/articles/article.aspx?p=1248057>, the top 25 tea leaves <http://www.informit.com/articles/article.aspx?p=1322398>, black box web app goat sacrifice, and the occult reading of pen testing entrails. It's science time.  And the more descriptive and data driven we are, the better.

Can you be more specific about your disagreements please?  Did you read articles at the end of the pointers?  Where am I wrong?  Better yet, why?

We'll just ignore the Nader > Feynman stuff.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On Tue, Feb 2, 2010 at 9:30 AM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
> On Thu, 28 Jan 2010 10:34:30 -0500, Gary McGraw wrote:
>
>> Among other things, David [Rice] and I discussed the difference between
>> descriptive models like BSIMM and prescriptive models which purport to
>> tell you what you should do.  I just wrote an article about that for
>> informIT.  The title is
>>
>> "Cargo Cult Computer Security: Why we need more description and less
>> prescription."
>> http://www.informit.com/articles/article.aspx?p=1562220
>
> First, let me say that I have been the team lead of a small Software
> Security Group (specifically, an Application Security team) at a
> large telecom company for the past 11 years, so I am writing this from
> an SSG practitioner's perspective.
>
> Second, let me say that I appreciate descriptive holistic approaches to
> security such as BSIMM and OWASP's OpenSAMM. I think they are much
> needed, though seldom heeded.
>
> Which brings me to my third point. In my 11 years of experience working
> on this SSG, it is very rare that application development teams are
> looking for a _descriptive_ approach. Almost always, they are
> looking for a _prescriptive_ one. They want specific solutions
> to specific problems, not some general formula to an approach that will
> make them more secure. To those application development teams, something
> like OWASP's ESAPI is much more valuable than something like BSIMM or
> OpenSAMM. In fact, I you confirm that you BSIMM research would indicate that
> many companies' SSGs have developed their own proprietary security APIs
> for use by their application development teams. Therefore, to that end,
> I would not say we need less _prescriptive_ and more _descriptive_
> approaches. Both are useful and ideally should go together like hand and
> glove. (To that end, I also ask that you overlook some of my somewhat
> overzealous ESAPI developer colleagues who in the past made claims that
> ESAPI was the greatest thing since sliced beer. While I am an ardent
> ESAPI supporter and contributor, I proclaim it will *NOT* solve our pandemic
> security issues alone, nor for the record will it solve world hunger. ;-)
>
> I suspect that this apparent dichotomy in our perception of the
> usefulness of the prescriptive vs. descriptive approaches is explained
> in part by the different audiences with whom we associate. Hang out with
> VPs, CSOs, and executive directors and they likely are looking for advice on
> an SSDLC or broad direction to cover their specifically identified
> security gaps. However, in the trenches--where my team works--they want
> specifics. They ask us "How can you help us to eliminate our specific
> XSS or CSRF issues?", "Can you provide us with a secure SSO solution
> that is compliant with both corporate information security policies and
> regulatory compliance?", etc. If our SSG were to hand them something like
> BSIMM, they would come away telling their management that we didn't help
> them at all.
>
> This brings me to my fourth, and likely most controversial point. Despite
> the interesting historical story about Feynman, I question whether BSIMM
> is really "scientific" as the BSIMM community claims. I would contend
> that we are only fooling ourselves if we claim otherwise. And while
> BSIMM is a refreshing approach opposed to the traditional FUD modus
> operandi taken by most security vendors hyping their security products,
> I would argue that BSIMM is no more scientific than the those
> who gather common quality metrics of counting defects/KLOC. Certainly
> there is some correlation there, but cause and effect relationships
> are far from obvious and seem to have little predictive accuracy.
>
> Sure, BSIMM _looks_ scientific on the outside, but simply collecting
> specific quantifiable data alone does not make something a scientific
> endeavor.  Yes, it is a start, but we've been collecting quantifiable
> data for decades on things like software defects and I would contend
> BSIMM is no more scientific than those efforts. Is BSIMM moving in
> the right direction? I think so. But BSIMM is no more scientific
> than most of the other areas of computer "science".
>
> To study something scientifically goes _beyond_ simply gathering
> observable and measurable evidence. Not only does data needs to be
> collected, but it also needs to be tested against a hypotheses that offers
> a tentative *explanation* of the observed phenomena;
> i.e., the hypotheses should offer some predictive value. Furthermore,
> the steps of the experiment must be _repeatable_, not just by
> those currently involved in the attempted scientific endeavor, but by
> *anyone* who would care to repeat the experiment. If the
> steps are not repeatable, then any predictive value of the study is lost.
>
> While I am certainly not privy to the exact method used to arrive at the
> BSIMM data (I have read through the "BSIMM Begin" survey, but have not
> been involved in a full BSIMM assessment), I would contend that the
> process is not repeatable to the necessary degree required by science.
> In fact, I would claim in most organizations, you could take any group
> of BSIMM interviewers and have them question different people in the
> organization using the exact same questions and arrive at different results.
> In fact, I am willing to bet that the different members of my Application
> Security team who have all worked together for about 8 years would
> answer a significant number of the BSIMM Begin survey questions quite
> differently. (My explanation for this phenomena is the general observation
> that if you ask a group of N engineers for their opinion on something,
> they will almost certainly arrive at N+1 different opinions. ;-)
>
> I commend the BSIMM sponsors and leadership of releasing BSIMM under
> a Creative Commons license, but at the same time, I challenge them
> to put forth additional information explaining their data collection
> process and in particular, describing how it
> avoids unintentional bias. (E.g., Are assessment participants choose at
> random? By whom?  How do you know you have a representative sample of
> a company? Etc.)
>
> I also challenge BSIMM to show their data collection is repeatable by
> others following their process. The published BSIMM Begin survey is a
> good start, but information regarding the full assessment seems to be
> lacking.
>
> I challenge BSIMM to put forth their hypotheses, plainly stated.
> In your InformIT article, you wrote:
>
>    "Another distinct advantage that descriptive models have over
>    prescriptive models is the ability to compare current observations
>    with past observations."
>
> In my opinion, comparison of observations from two companies is not
> worth the paper that is printed on UNLESS we can extrapolate from
> this data and make accurate predictions based on past findings. Therefore,
> I also would challenge BSIMM to publicly make some specific predictions
> using their model and collected data so that their hypotheses can be
> tested independently by others.
>
> Finally, while I would like, as you did, to blame our Computer Security /
> software security's "Cargo Cult" mentality on "its relative youth as
> a field", I believe there is something deeper going on here. For one,
> computer science / IT / whatever you want to call this much broader
> field has the same issue. And while computer "science" is young as
> measured against most other scientific disciplines, it is by no means an
> immature field. (As a discipline, it is much older than I, and trust me,
> I am no spring chicken. :)
>
> After observing this field for 30+ years (ouch!), I have concluded that we
> have not matured into a science because as a discipline we *do NOT
> really want to!*  We can't even decide if we want this study of computers
> / information processing / etc. to be a "science", an "engineering
> discipline", or a "craft". (And some even would like it to be an "art".)
> Most of us--myself included--are too lazy to do the disciplined work
> that true science requires, and that includes having enough guts to
> challenge the academic culture and *demand* funding to do well-designed
> scientific experiment in our discipline at our leading universities. IMO,
> if we fail to do this, CS is doomed to always remain a science wannabe.
>
> Some would say that because our broader field of study--whether you
> call it Computer Science, Computer Engineering, Information Science,
> whatever--is part science, part engineering, part craft, and part
> something unique that humanity has never before encountered, attempts
> to treat it as a science will not succeed. However, surely this does
> not mean that we should not attempt to add some scientific rigor to
> it as a discipline. To that end efforts such as BSIMM should be welcomed
> by all.  But is also important for those who prefer _descriptive_ approaches
> like BSIMM, to acknowledge the importance of _prescriptive_ approaches
> such as ESAPI, WAFs, anti-malware software, etc. We truly need *both*
> approaches to be successful.
>
> Regards,
> -kevin
> ---
> Kevin W. Wall           Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com    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.
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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 at 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.
_______________________________________________



From gem at cigital.com  Wed Feb  3 15:06:09 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Feb 2010 15:06:09 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <Pine.GSO.4.64.1002021904000.2035@faron.mitre.org>
Message-ID: <C78F4161.1DDA9%gem@cigital.com>

hi steve,

It's BSIMM Begin and we are delinquent looking into the data.  Hope to do that soon.  We have 75 partial vectors in the set (including some "control" vectors from full BSIMM participants).

Anyone who wants to help us "top off" the data...(I was hoping to gather 100 vectors)...click here:

http://bsi-mm.com/begin

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com



On 2/2/10 7:23 PM, "Steven M. Christey" <coley at linus.mitre.org> wrote:



On Tue, 2 Feb 2010, Arian J. Evans wrote:

> BSIMM is probably useful for government agencies, or some large
> organizations. But the vast majority of clients I work with don't have
> the time or need or ability to take advantage of BSIMM. Nor should
> they. They don't need a software security group.

I'm looking forward to what BSIMM Basic discovers when talking to small
and mid-size developers.  Many of the questions in the survey PDF assume
that the respondent has at least thought of addressing software security,
but not all questions assume the presence of an SSG, and there are even
questions about the use of general top-n lists vs. customized top-n lists
that may be informative.

- Steve
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________



From coley at linus.mitre.org  Thu Feb  4 00:05:14 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 4 Feb 2010 00:05:14 -0500 (EST)
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <C78F410B.1DDA8%gem@cigital.com>
References: <C78F410B.1DDA8%gem@cigital.com>
Message-ID: <Pine.GSO.4.64.1002032319060.7017@faron.mitre.org>


On Wed, 3 Feb 2010, Gary McGraw wrote:

> Popularity contests are not the kind of data we should count on.  But 
> maybe we'll make some progress on that one day.

That's my hope, too, but I'm comfortable with making baby steps along the 
way.

>> Ultimately, I would love to see the kind of linkage between the collected
>> data ("evidence") and some larger goal ("higher security" whatever THAT
>> means in quantitative terms) but if it's out there, I don't see it
>
> Neither do I, and that is a serious issue with models like the BSIMM 
> that measure "second order" effects like activities.  Do the activities 
> actually do any good?  Important question!

And one we can't answer without more data that comes from the developers 
who adopt any particular practice, and without some independent measure of 
what success means.  For example: I am a big fan of the attack surface 
metric originally proposed by Michael Howard and taken up by Jeanette Wing 
et al. at CMU (still need to find the time to read Manadhata's thesis, 
alas...)  It seems like common sense that if you reduce attack surface, 
you reduce the number of security problems, but how do you KNOW!?

>> The 2010 OWASP Top 10 RC1 is more data-driven than previous versions; same
>> with the 2010 Top 25 (whose release has been delayed to Feb 16, btw).
>> Unlike last year's Top 25 effort, this time I received several sources of
>> raw prevalence data, but unfortunately it wasn't in sufficiently
>> consumable form to combine.
>
> I was with you up until that last part.  Combining the prevalence data 
> is something you guys should definitely do.  BTW, how is the 2010 CWE-25 
> (which doesn't yet exist) more data driven??

I guess you could call it a more refined version of the "popularity 
contest" that you already referred to (with the associated limitations, 
and thus subject to some of the same criticisms as those pointed at 
BSIMM): we effectively conducted a survey of a diverse set of 
organizations/individuals from various parts of the software security 
industry, asking what was most important to them, and what they saw the 
most often.  This year, I intentionally designed the Top 25 under the 
assumption that we would not have hard-core quantitative data, recognizing 
that people WANTED hard-core data, and that the few people who actually 
had this data, would not want to share it.  (After all, as a software 
vendor you may know what your own problems are, but you might not want to 
share that with anyone else.)

It was a bit of a surprise when a handful of participants actually had 
real data - but, then the problem I'm referring to with respect to 
"consumable form" reared its ugly head.  One third-party consultant had 
statistics for a broad set of about 10 high-level categories representing 
hundreds of evaluations; one software vendor gave us a specific weakness 
history - representing dozens of different CWE entries across a broad 
spectrum of issues, sometimes at very low levels of detail and even 
branching into the GUI part of CWE which almost nobody pays attention to - 
but "only" for 3 products.  Another vendor rep evaluated the dozen or two 
publicly-disclosed vulnerabilities that were most severe according to 
associated CVSS scores.  Those three data sets, plus the handful of others 
based on some form of analysis of hard-core data, are not merge-able. 
The irony with CWE (and many of the making-security-measurable efforts) is 
that it brings sufficient clarity to recognize when there is no clarity... 
the "known unknowns" to quote Donald Rumsfeld.  I saw this in 1999 in the 
early days of CVE, too, and it's still going on - observers of the 
oss-security list see this weekly.

For data collection at such a specialized level, the situation is not 
unlike the breach-data problem faced by the Open Security Foundation in 
their Data Loss DB work - sometimes you have details, sometimes you don't. 
The Data Loss people might be able to say "well, based on this 100-page 
report we examined, we think it MIGHT have been SQL injection" but that's 
the kind of data we're dealing with right now.

Now, a separate exercise in which we compare/contrast the customized top-n 
lists of those who have actually progressed to the point of making them... 
that smells like opportunity to me.

>> I for one am pretty satisfied with the rate at which things are
>> progressing and am delighted to see that we're finally getting some raw
>> data, as good (or as bad) as it may be.  The data collection process,
>> source data, metrics, and conclusions associated with the 2010 Top 25 will
>> probably be controversial, but at least there's some data to argue about.
>
> Cool!

To clarify to others who have commented on this part - I'm talking 
specifically about the rate in which the software security industry seems 
to be maturing, independently of how quickly the threat landscape is 
changing.  That's a whole different, depressing problem.

- Steve

From mike.boberski at gmail.com  Wed Feb  3 18:00:48 2010
From: mike.boberski at gmail.com (Mike Boberski)
Date: Wed, 3 Feb 2010 18:00:48 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <C78F410B.1DDA8%gem@cigital.com>
References: <Pine.GSO.4.64.1002021544290.917@faron.mitre.org> 
	<C78F410B.1DDA8%gem@cigital.com>
Message-ID: <22290cd81002031500v4d876a54r3481c6bffc78cb24@mail.gmail.com>

>I for one am pretty satisfied with the rate at which things are
>progressing

I dunno...

Again, trying to keep it pithy: I for one welcome our eventual new [insert
hostile nation state here] overlords. </joke>

What I see from my vantage point is a majority of people who (1)should know
better given their leadership positions that don't or (2)who willingly
ignore security-related concerns to advance their personal business goals,
trusting in the availability of lawyers or the ability to punch out before
stuff hits the fan, speculating (perhaps) on motives.

Excuse me now while I get back go my Rosetta Stone lesson. </joke>

Mike


On Wed, Feb 3, 2010 at 3:04 PM, Gary McGraw <gem at cigital.com> wrote:

> Hi Steve (and sc-l),
>
> I'll invoke my skiing with Eli excuse again on this thread as well...
>
> On Tue, 2 Feb 2010, Wall, Kevin wrote:
> > To study something scientifically goes _beyond_ simply gathering
> > observable and measurable evidence. Not only does data needs to be
> > collected, but it also needs to be tested against a hypotheses that
> offers
> > a tentative *explanation* of the observed phenomena;
> > i.e., the hypotheses should offer some predictive value.
>
> On 2/2/10 4:12 PM, "Steven M. Christey" <coley at linus.mitre.org> wrote:
> >>I believe that the cross-industry efforts like BSIMM, ESAPI, top-n lists,
> >>SAMATE, etc. are largely at the beginning of the data collection phase.
>
> I agree 100%.  It's high time we gathered some data to back up our claims.
>  I would love to see the top-n lists do more with data.
>
> Here's an example.  In the BSIMM,  10 of 30 firms have built top-N bug
> lists based on their own data culled from their own code.  I would love to
> see how those top-n lists compare to the OWASP top ten or the CWE-25.  I
> would also love to see whether the union of these lists is even remotely
> interesting.  One of my (many) worries about top-n lists that are NOT bound
> to a particular code base is that the lists are so generic as to be useless
> and maybe even unhelpful if adopted wholesale without understanding what's
> actually going on in a codebase. [see <
> http://www.informit.com/articles/article.aspx?p=1322398>].
>
> Note for the record that "asking lots of people what they think should be
> in the top-10" is not quite the same as taking the union of particular top-n
> lists which are tied to particular code bases.  Popularity contests are not
> the kind of data we should count on.  But maybe we'll make some progress on
> that one day.
>
> >Ultimately, I would love to see the kind of linkage between the collected
> >data ("evidence") and some larger goal ("higher security" whatever THAT
> >means in quantitative terms) but if it's out there, I don't see it
>
> Neither do I, and that is a serious issue with models like the BSIMM that
> measure "second order" effects like activities.  Do the activities actually
> do any good?  Important question!
>
> >The 2010 OWASP Top 10 RC1 is more data-driven than previous versions; same
> >with the 2010 Top 25 (whose release has been delayed to Feb 16, btw).
> >Unlike last year's Top 25 effort, this time I received several sources of
> >raw prevalence data, but unfortunately it wasn't in sufficiently
> >consumable form to combine.
>
> I was with you up until that last part.  Combining the prevalence data is
> something you guys should definitely do.  BTW, how is the 2010 CWE-25 (which
> doesn't yet exist) more data driven??
>
> >I for one am pretty satisfied with the rate at which things are
> >progressing and am delighted to see that we're finally getting some raw
> >data, as good (or as bad) as it may be.  The data collection process,
> >source data, metrics, and conclusions associated with the 2010 Top 25 will
> >probably be controversial, but at least there's some data to argue about.
>
> Cool!
>
> >So in that sense, I see Gary's article not so much as a clarion call for
> >action to a reluctant and primitive industry, but an early announcement of
> >a shift that is already underway.
>
> Well put.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/~gem <http://www.cigital.com/%7Egem>
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100203/4a034ce5/attachment-0001.htm>

From James.McGovern at thehartford.com  Thu Feb  4 10:29:32 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Thu, 4 Feb 2010 10:29:32 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <3B8BD8AE-DE4B-4867-9BF7-2E8CFF4A7356@krvw.com>
References: <C78719EA.1DA9C%gem@cigital.com>
	<3B8BD8AE-DE4B-4867-9BF7-2E8CFF4A7356@krvw.com>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702D186D3@AD1HFDEXC312.ad1.prod>

When comparing BSIMM to SAMM are we suffering from the Mayberry Paradox? Did you know that Apple is more secure than Microsoft simply because there are more successful attacks on MS products? Of course, we should ignore the fact that the number of attackers doesn't prove that one product is more secure than another.

Whenever I bring in either vendors or consultancies to write about my organization, do I only publish the positives and only slip in a few negatives in order to maintain the fa?ade of integrity? Would BSIMM be a better approach if the audience wasn't so self-selecting? At no time did it include corporations who use Ounce Labs or Coverity or even other well-known security consultancies.

OWASP on the other hand received feedback from folks such as myself on not the things that work, but on a ton of stuff that didn't work for us. This type of filtering provides more value in that it helps other organizations avoid repeating things that we didn't do so well without necessarily encouraging others to do it the McGovern way.

Corporations are dynamic entities and what won't work vs what will is highly contextual. I prefer a list of things that could possibly work over the effort to simply pull something off the shelf that another organization got to work with a lot of missing context. The best security decisions are made when you can provide an enterprise with choice in recommendations and I think SAMM in this regard does a better job than other approaches.

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Wednesday, February 03, 2010 4:08 PM
To: Secure Coding
Subject: Re: [SC-L] BSIMM update (informIT)

On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote:
> Among other things, David and I discussed the difference between descriptive models like BSIMM and prescriptive models which purport to tell you what you should do. 

Thought I'd chime in on this a bit, FWIW...  From my perspective, I welcome BSIMM and I welcome SAMM.  I don't see it in the least as a "one or the other" debate.

A decade(ish) since the first texts on various aspects of software security started appearing, it's great to have a BSIMM that surveys some of the largest software groups on the planet to see what they're doing.  What actually works.  That's fabulously useful.  On the other hand, it is possible that ten thousand lemmings can be wrong.  Following the herd isn't always what's best.

SAMM, by contrast, was written by some bright, motivated folks, and provides us all with a set of targets to aspire to.  Some will work, and some won't, without a doubt.

To me, both models are useful as guide posts to help a software group--an SSG if you will--decide what practices will work best in their enterprise.

But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves if we consider these to be standards or even maturity models.  Any other engineering discipline on the planet would laugh us all out of the room by the mere suggestion.  There's value to them, don't get me wrong.  But we're still in the larval mode of building an engineering discipline here folks.  After all, as a species, we didn't start (successfully) building bridges in a decade.

For now, my suggestion is to read up, try things that seem reasonable, and build a set of practices that work for _you_.  

Cheers,

Ken

-----
Kenneth R. van Wyk
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.
************************************************************



From jim at manico.net  Thu Feb  4 12:50:37 2010
From: jim at manico.net (Jim Manico)
Date: Thu, 04 Feb 2010 07:50:37 -1000
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <Pine.GSO.4.64.1002032319060.7017@faron.mitre.org>
References: <C78F410B.1DDA8%gem@cigital.com>
	<Pine.GSO.4.64.1002032319060.7017@faron.mitre.org>
Message-ID: <4B6B08ED.1000004@manico.net>

Why are we holding up the statistics from Google, Adobe and Microsoft ( 
http://www.bsi-mm.com/participate/ ) in BDSIMM?

These companies are examples of recent "epic security failure". Probably 
the most financially damaging infosec attack, ever. Microsoft let a 
plain-vanilla 0-day slip through ie6 for years, Google has a pretty 
basic network segmentation and policy problem, and Adobe continues to be 
the laughing stock of client side security. Why are we holding up these 
companies as BDSIMM champions?

- Jim

>
> On Wed, 3 Feb 2010, Gary McGraw wrote:
>
>> Popularity contests are not the kind of data we should count on.  But 
>> maybe we'll make some progress on that one day.
>
> That's my hope, too, but I'm comfortable with making baby steps along 
> the way.
>
>>> Ultimately, I would love to see the kind of linkage between the 
>>> collected
>>> data ("evidence") and some larger goal ("higher security" whatever THAT
>>> means in quantitative terms) but if it's out there, I don't see it
>>
>> Neither do I, and that is a serious issue with models like the BSIMM 
>> that measure "second order" effects like activities.  Do the 
>> activities actually do any good?  Important question!
>
> And one we can't answer without more data that comes from the 
> developers who adopt any particular practice, and without some 
> independent measure of what success means.  For example: I am a big 
> fan of the attack surface metric originally proposed by Michael Howard 
> and taken up by Jeanette Wing et al. at CMU (still need to find the 
> time to read Manadhata's thesis, alas...)  It seems like common sense 
> that if you reduce attack surface, you reduce the number of security 
> problems, but how do you KNOW!?
>
>>> The 2010 OWASP Top 10 RC1 is more data-driven than previous 
>>> versions; same
>>> with the 2010 Top 25 (whose release has been delayed to Feb 16, btw).
>>> Unlike last year's Top 25 effort, this time I received several 
>>> sources of
>>> raw prevalence data, but unfortunately it wasn't in sufficiently
>>> consumable form to combine.
>>
>> I was with you up until that last part.  Combining the prevalence 
>> data is something you guys should definitely do.  BTW, how is the 
>> 2010 CWE-25 (which doesn't yet exist) more data driven??
>
> I guess you could call it a more refined version of the "popularity 
> contest" that you already referred to (with the associated 
> limitations, and thus subject to some of the same criticisms as those 
> pointed at BSIMM): we effectively conducted a survey of a diverse set 
> of organizations/individuals from various parts of the software 
> security industry, asking what was most important to them, and what 
> they saw the most often.  This year, I intentionally designed the Top 
> 25 under the assumption that we would not have hard-core quantitative 
> data, recognizing that people WANTED hard-core data, and that the few 
> people who actually had this data, would not want to share it.  (After 
> all, as a software vendor you may know what your own problems are, but 
> you might not want to share that with anyone else.)
>
> It was a bit of a surprise when a handful of participants actually had 
> real data - but, then the problem I'm referring to with respect to 
> "consumable form" reared its ugly head.  One third-party consultant 
> had statistics for a broad set of about 10 high-level categories 
> representing hundreds of evaluations; one software vendor gave us a 
> specific weakness history - representing dozens of different CWE 
> entries across a broad spectrum of issues, sometimes at very low 
> levels of detail and even branching into the GUI part of CWE which 
> almost nobody pays attention to - but "only" for 3 products.  Another 
> vendor rep evaluated the dozen or two publicly-disclosed 
> vulnerabilities that were most severe according to associated CVSS 
> scores.  Those three data sets, plus the handful of others based on 
> some form of analysis of hard-core data, are not merge-able. The irony 
> with CWE (and many of the making-security-measurable efforts) is that 
> it brings sufficient clarity to recognize when there is no clarity... 
> the "known unknowns" to quote Donald Rumsfeld.  I saw this in 1999 in 
> the early days of CVE, too, and it's still going on - observers of the 
> oss-security list see this weekly.
>
> For data collection at such a specialized level, the situation is not 
> unlike the breach-data problem faced by the Open Security Foundation 
> in their Data Loss DB work - sometimes you have details, sometimes you 
> don't. The Data Loss people might be able to say "well, based on this 
> 100-page report we examined, we think it MIGHT have been SQL 
> injection" but that's the kind of data we're dealing with right now.
>
> Now, a separate exercise in which we compare/contrast the customized 
> top-n lists of those who have actually progressed to the point of 
> making them... that smells like opportunity to me.
>
>>> I for one am pretty satisfied with the rate at which things are
>>> progressing and am delighted to see that we're finally getting some raw
>>> data, as good (or as bad) as it may be.  The data collection process,
>>> source data, metrics, and conclusions associated with the 2010 Top 
>>> 25 will
>>> probably be controversial, but at least there's some data to argue 
>>> about.
>>
>> Cool!
>
> To clarify to others who have commented on this part - I'm talking 
> specifically about the rate in which the software security industry 
> seems to be maturing, independently of how quickly the threat 
> landscape is changing.  That's a whole different, depressing problem.
>
> - Steve
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________


From brian at fortify.com  Thu Feb  4 14:11:29 2010
From: brian at fortify.com (Brian Chess)
Date: Thu, 04 Feb 2010 20:11:29 +0100
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE28702D186D3@AD1HFDEXC312.ad1.prod>
Message-ID: <C790DA71.1D379%brian@fortify.com>

> At no time did it include corporations who use Ounce Labs or Coverity

Bzzzt.  False.  While there are plenty of Fortify customers represented in
BSIMM, there are also plenty of participants who aren't Fortify customers.
I don't think there are any hard numbers on market share in this realm, but
my hunch is that BSIMM is not far off from a uniform sample in this regard.

Brian


> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
> Behalf Of Kenneth Van Wyk
> Sent: Wednesday, February 03, 2010 4:08 PM
> To: Secure Coding
> Subject: Re: [SC-L] BSIMM update (informIT)
> 
> On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote:
>> Among other things, David and I discussed the difference between descriptive
>> models like BSIMM and prescriptive models which purport to tell you what you
>> should do. 
> 
> Thought I'd chime in on this a bit, FWIW...  From my perspective, I welcome
> BSIMM and I welcome SAMM.  I don't see it in the least as a "one or the other"
> debate.
> 
> A decade(ish) since the first texts on various aspects of software security
> started appearing, it's great to have a BSIMM that surveys some of the largest
> software groups on the planet to see what they're doing.  What actually works.
> That's fabulously useful.  On the other hand, it is possible that ten thousand
> lemmings can be wrong.  Following the herd isn't always what's best.
> 
> SAMM, by contrast, was written by some bright, motivated folks, and provides
> us all with a set of targets to aspire to.  Some will work, and some won't,
> without a doubt.
> 
> To me, both models are useful as guide posts to help a software group--an SSG
> if you will--decide what practices will work best in their enterprise.
> 
> But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves
> if we consider these to be standards or even maturity models.  Any other
> engineering discipline on the planet would laugh us all out of the room by the
> mere suggestion.  There's value to them, don't get me wrong.  But we're still
> in the larval mode of building an engineering discipline here folks.  After
> all, as a species, we didn't start (successfully) building bridges in a
> decade.
> 
> For now, my suggestion is to read up, try things that seem reasonable, and
> build a set of practices that work for _you_.
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> 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 at 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.
> _______________________________________________


From gem at cigital.com  Thu Feb  4 14:18:08 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 4 Feb 2010 14:18:08 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE28702D186D3@AD1HFDEXC312.ad1.prod>
Message-ID: <C79088E6.1DF03%gem@cigital.com>

hi james,

I'm afraid you are completely wrong about this paragraph which you have completely fabricated.  Please check your facts.  This one borders on slander and I have no earthly idea why you believe what you said.

> Would BSIMM be a better approach if the audience wasn't so self-selecting? At no time did it include corporations who
> use Ounce Labs or Coverity or even other well-known security consultancies.

BSIMM covers many organizations who use Ounce, Appscan, SPI dev inspect, Coverity, Klocwork, Veracode, and a slew of consultancies including iSec, Aspect, Leviathan, Aitel, and so on.

gem


On 2/4/10 10:29 AM, "McGovern, James F. (eBusiness)" <James.McGovern at thehartford.com> wrote:

When comparing BSIMM to SAMM are we suffering from the Mayberry Paradox? Did you know that Apple is more secure than Microsoft simply because there are more successful attacks on MS products? Of course, we should ignore the fact that the number of attackers doesn't prove that one product is more secure than another.

Whenever I bring in either vendors or consultancies to write about my organization, do I only publish the positives and only slip in a few negatives in order to maintain the fa?ade of integrity? Would BSIMM be a better approach if the audience wasn't so self-selecting? At no time did it include corporations who use Ounce Labs or Coverity or even other well-known security consultancies.

OWASP on the other hand received feedback from folks such as myself on not the things that work, but on a ton of stuff that didn't work for us. This type of filtering provides more value in that it helps other organizations avoid repeating things that we didn't do so well without necessarily encouraging others to do it the McGovern way.

Corporations are dynamic entities and what won't work vs what will is highly contextual. I prefer a list of things that could possibly work over the effort to simply pull something off the shelf that another organization got to work with a lot of missing context. The best security decisions are made when you can provide an enterprise with choice in recommendations and I think SAMM in this regard does a better job than other approaches.

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Wednesday, February 03, 2010 4:08 PM
To: Secure Coding
Subject: Re: [SC-L] BSIMM update (informIT)

On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote:
> Among other things, David and I discussed the difference between descriptive models like BSIMM and prescriptive models which purport to tell you what you should do.

Thought I'd chime in on this a bit, FWIW...  From my perspective, I welcome BSIMM and I welcome SAMM.  I don't see it in the least as a "one or the other" debate.

A decade(ish) since the first texts on various aspects of software security started appearing, it's great to have a BSIMM that surveys some of the largest software groups on the planet to see what they're doing.  What actually works.  That's fabulously useful.  On the other hand, it is possible that ten thousand lemmings can be wrong.  Following the herd isn't always what's best.

SAMM, by contrast, was written by some bright, motivated folks, and provides us all with a set of targets to aspire to.  Some will work, and some won't, without a doubt.

To me, both models are useful as guide posts to help a software group--an SSG if you will--decide what practices will work best in their enterprise.

But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves if we consider these to be standards or even maturity models.  Any other engineering discipline on the planet would laugh us all out of the room by the mere suggestion.  There's value to them, don't get me wrong.  But we're still in the larval mode of building an engineering discipline here folks.  After all, as a species, we didn't start (successfully) building bridges in a decade.

For now, my suggestion is to read up, try things that seem reasonable, and build a set of practices that work for _you_.

Cheers,

Ken

-----
Kenneth R. van Wyk
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 at 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.
_______________________________________________



From James.McGovern at thehartford.com  Thu Feb  4 14:57:25 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Thu, 4 Feb 2010 14:57:25 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <C79088E6.1DF03%gem@cigital.com>
References: <BFD50E79FBE23A4FB6BE93572A6FE28702D186D3@AD1HFDEXC312.ad1.prod>
	<C79088E6.1DF03%gem@cigital.com>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702D18BD8@AD1HFDEXC312.ad1.prod>

Merely hoping to understand more about the thinking behind BSIMM. 

Here is a quote from the page: "Of the thirty-five large-scale software security initiatives we are aware of, we chose nine that we considered the most advanced" how can the reader tell why others were filtered?

When you visit the link: http://www.bsi-mm.com/participate/ it doesn't show any of the vendors you mentioned below? Should they be shown somewhere?

The BSIMM download link requires registration. Does this become a "lead" for some company?


-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com] 
Sent: Thursday, February 04, 2010 2:18 PM
To: McGovern, James F. (P+C Technology); Secure Code Mailing List
Subject: Re: [SC-L] BSIMM update (informIT)

hi james,

I'm afraid you are completely wrong about this paragraph which you have completely fabricated.  Please check your facts.  This one borders on slander and I have no earthly idea why you believe what you said.

> Would BSIMM be a better approach if the audience wasn't so 
> self-selecting? At no time did it include corporations who use Ounce Labs or Coverity or even other well-known security consultancies.

BSIMM covers many organizations who use Ounce, Appscan, SPI dev inspect, Coverity, Klocwork, Veracode, and a slew of consultancies including iSec, Aspect, Leviathan, Aitel, and so on.

gem


On 2/4/10 10:29 AM, "McGovern, James F. (eBusiness)" <James.McGovern at thehartford.com> wrote:

When comparing BSIMM to SAMM are we suffering from the Mayberry Paradox? Did you know that Apple is more secure than Microsoft simply because there are more successful attacks on MS products? Of course, we should ignore the fact that the number of attackers doesn't prove that one product is more secure than another.

Whenever I bring in either vendors or consultancies to write about my organization, do I only publish the positives and only slip in a few negatives in order to maintain the fa?ade of integrity? Would BSIMM be a better approach if the audience wasn't so self-selecting? At no time did it include corporations who use Ounce Labs or Coverity or even other well-known security consultancies.

OWASP on the other hand received feedback from folks such as myself on not the things that work, but on a ton of stuff that didn't work for us. This type of filtering provides more value in that it helps other organizations avoid repeating things that we didn't do so well without necessarily encouraging others to do it the McGovern way.

Corporations are dynamic entities and what won't work vs what will is highly contextual. I prefer a list of things that could possibly work over the effort to simply pull something off the shelf that another organization got to work with a lot of missing context. The best security decisions are made when you can provide an enterprise with choice in recommendations and I think SAMM in this regard does a better job than other approaches.

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Wednesday, February 03, 2010 4:08 PM
To: Secure Coding
Subject: Re: [SC-L] BSIMM update (informIT)

On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote:
> Among other things, David and I discussed the difference between descriptive models like BSIMM and prescriptive models which purport to tell you what you should do.

Thought I'd chime in on this a bit, FWIW...  From my perspective, I welcome BSIMM and I welcome SAMM.  I don't see it in the least as a "one or the other" debate.

A decade(ish) since the first texts on various aspects of software security started appearing, it's great to have a BSIMM that surveys some of the largest software groups on the planet to see what they're doing.  What actually works.  That's fabulously useful.  On the other hand, it is possible that ten thousand lemmings can be wrong.  Following the herd isn't always what's best.

SAMM, by contrast, was written by some bright, motivated folks, and provides us all with a set of targets to aspire to.  Some will work, and some won't, without a doubt.

To me, both models are useful as guide posts to help a software group--an SSG if you will--decide what practices will work best in their enterprise.

But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves if we consider these to be standards or even maturity models.  Any other engineering discipline on the planet would laugh us all out of the room by the mere suggestion.  There's value to them, don't get me wrong.  But we're still in the larval mode of building an engineering discipline here folks.  After all, as a species, we didn't start (successfully) building bridges in a decade.

For now, my suggestion is to read up, try things that seem reasonable, and build a set of practices that work for _you_.

Cheers,

Ken

-----
Kenneth R. van Wyk
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 at 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.
************************************************************



From coley at linus.mitre.org  Thu Feb  4 14:23:20 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 4 Feb 2010 14:23:20 -0500 (EST)
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <4B6B08ED.1000004@manico.net>
References: <C78F410B.1DDA8%gem@cigital.com>
	<Pine.GSO.4.64.1002032319060.7017@faron.mitre.org>
	<4B6B08ED.1000004@manico.net>
Message-ID: <Pine.GSO.4.64.1002041408010.8661@faron.mitre.org>


On Thu, 4 Feb 2010, Jim Manico wrote:

> These companies are examples of recent "epic security failure". Probably 
> the most financially damaging infosec attack, ever. Microsoft let a 
> plain-vanilla 0-day slip through ie6 for years

Actually, it was a not-so-vanilla use-after-free, which once upon a time 
was only thought of as a reliability problem, but lately, exploit and 
detection techniques have recently begun bearing fruit for the small 
number of people who actually know how to get code execution out of these 
bugs.  In general, Microsoft (and others) have gotten their software to 
the point where attackers and researchers have to spend a lot of time and 
$$$ to find obscure vuln types, then spend some more time and $$$ to work 
around the various protection mechanisms that exist in order to get code 
execution instead of a crash.

I can't remember the last time I saw a Microsoft product have a 
mind-numbingly-obvious problem in it.  It would be nice if statistics were 
available that measured how many person-hours and CPU-hours were used to 
find new vulnerabilities - then you could determine the ratio of 
level-of-effort to number-of-vulns-found.  That data's not available, 
though - we only have anecdotal evidence by people such as Dave Aitel and 
David Litchfield saying "it's getting more difficult and time-consuming."

- Steve

From gem at cigital.com  Thu Feb  4 14:32:37 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 4 Feb 2010 14:32:37 -0500
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <4B6B08ED.1000004@manico.net>
Message-ID: <C7908C55.1DF0F%gem@cigital.com>

hi jim,

We chose organizations that in our opinion are doing a superior job with software security.  You are welcome to disagree with our choices.

Microsoft has a shockingly good approach to software security that they are kind enough to share with the world through the SDL books and websites.  Google has a much different approach with more attention focused on open source risk and testing (and much less on code review with tools).  Adobe has a newly reinvigorated approach under new leadership that is making some much needed progress.

The three firms that you cited were all members of the original nine whose data allowed us to construct the model.  There are now 30 firms in the BSIMM study, and their BSIMM data vary as much as you might expect...about which more soon.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On 2/4/10 12:50 PM, "Jim Manico" <jim at manico.net> wrote:

Why are we holding up the statistics from Google, Adobe and Microsoft (
http://www.bsi-mm.com/participate/ ) in BDSIMM?

These companies are examples of recent "epic security failure". Probably
the most financially damaging infosec attack, ever. Microsoft let a
plain-vanilla 0-day slip through ie6 for years, Google has a pretty
basic network segmentation and policy problem, and Adobe continues to be
the laughing stock of client side security. Why are we holding up these
companies as BDSIMM champions?

- Jim

>
> On Wed, 3 Feb 2010, Gary McGraw wrote:
>
>> Popularity contests are not the kind of data we should count on.  But
>> maybe we'll make some progress on that one day.
>
> That's my hope, too, but I'm comfortable with making baby steps along
> the way.
>
>>> Ultimately, I would love to see the kind of linkage between the
>>> collected
>>> data ("evidence") and some larger goal ("higher security" whatever THAT
>>> means in quantitative terms) but if it's out there, I don't see it
>>
>> Neither do I, and that is a serious issue with models like the BSIMM
>> that measure "second order" effects like activities.  Do the
>> activities actually do any good?  Important question!
>
> And one we can't answer without more data that comes from the
> developers who adopt any particular practice, and without some
> independent measure of what success means.  For example: I am a big
> fan of the attack surface metric originally proposed by Michael Howard
> and taken up by Jeanette Wing et al. at CMU (still need to find the
> time to read Manadhata's thesis, alas...)  It seems like common sense
> that if you reduce attack surface, you reduce the number of security
> problems, but how do you KNOW!?
>
>>> The 2010 OWASP Top 10 RC1 is more data-driven than previous
>>> versions; same
>>> with the 2010 Top 25 (whose release has been delayed to Feb 16, btw).
>>> Unlike last year's Top 25 effort, this time I received several
>>> sources of
>>> raw prevalence data, but unfortunately it wasn't in sufficiently
>>> consumable form to combine.
>>
>> I was with you up until that last part.  Combining the prevalence
>> data is something you guys should definitely do.  BTW, how is the
>> 2010 CWE-25 (which doesn't yet exist) more data driven??
>
> I guess you could call it a more refined version of the "popularity
> contest" that you already referred to (with the associated
> limitations, and thus subject to some of the same criticisms as those
> pointed at BSIMM): we effectively conducted a survey of a diverse set
> of organizations/individuals from various parts of the software
> security industry, asking what was most important to them, and what
> they saw the most often.  This year, I intentionally designed the Top
> 25 under the assumption that we would not have hard-core quantitative
> data, recognizing that people WANTED hard-core data, and that the few
> people who actually had this data, would not want to share it.  (After
> all, as a software vendor you may know what your own problems are, but
> you might not want to share that with anyone else.)
>
> It was a bit of a surprise when a handful of participants actually had
> real data - but, then the problem I'm referring to with respect to
> "consumable form" reared its ugly head.  One third-party consultant
> had statistics for a broad set of about 10 high-level categories
> representing hundreds of evaluations; one software vendor gave us a
> specific weakness history - representing dozens of different CWE
> entries across a broad spectrum of issues, sometimes at very low
> levels of detail and even branching into the GUI part of CWE which
> almost nobody pays attention to - but "only" for 3 products.  Another
> vendor rep evaluated the dozen or two publicly-disclosed
> vulnerabilities that were most severe according to associated CVSS
> scores.  Those three data sets, plus the handful of others based on
> some form of analysis of hard-core data, are not merge-able. The irony
> with CWE (and many of the making-security-measurable efforts) is that
> it brings sufficient clarity to recognize when there is no clarity...
> the "known unknowns" to quote Donald Rumsfeld.  I saw this in 1999 in
> the early days of CVE, too, and it's still going on - observers of the
> oss-security list see this weekly.
>
> For data collection at such a specialized level, the situation is not
> unlike the breach-data problem faced by the Open Security Foundation
> in their Data Loss DB work - sometimes you have details, sometimes you
> don't. The Data Loss people might be able to say "well, based on this
> 100-page report we examined, we think it MIGHT have been SQL
> injection" but that's the kind of data we're dealing with right now.
>
> Now, a separate exercise in which we compare/contrast the customized
> top-n lists of those who have actually progressed to the point of
> making them... that smells like opportunity to me.
>
>>> I for one am pretty satisfied with the rate at which things are
>>> progressing and am delighted to see that we're finally getting some raw
>>> data, as good (or as bad) as it may be.  The data collection process,
>>> source data, metrics, and conclusions associated with the 2010 Top
>>> 25 will
>>> probably be controversial, but at least there's some data to argue
>>> about.
>>
>> Cool!
>
> To clarify to others who have commented on this part - I'm talking
> specifically about the rate in which the software security industry
> seems to be maturing, independently of how quickly the threat
> landscape is changing.  That's a whole different, depressing problem.
>
> - Steve
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________




From arian.evans at anachronic.com  Thu Feb  4 15:36:08 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Thu, 4 Feb 2010 12:36:08 -0800
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <C78F4124.1DDA8%gem@cigital.com>
References: <cd1bdfdd1002021332x170d4719ubf978e1b2f8c73f9@mail.gmail.com>
	<C78F4124.1DDA8%gem@cigital.com>
Message-ID: <cd1bdfdd1002041236w68e114e9k95b890f42727b63a@mail.gmail.com>

Hola Gary, inline:


On Wed, Feb 3, 2010 at 12:05 PM, Gary McGraw <gem at cigital.com> wrote:
>
>>Strategic folks (VP, CxO) ...Initially ...ask for descriptive information, but once they get
>>going they need strategic prescriptions.
>
> Please see my response to Kevin. ?I hope it's clear what the BSIMM is for.
> ?It's for measuring your initiative and comparing it to others. ?Given some
> solid BSIMM data, I believe you can do a superior job with strategy...and
> results measurement. ?It is a tool for strategic people to use to build an initiative that works.


My response was regarding what people need today. I think BSIMM is too
much for most organization's needs and interests.


>>Tactical folks tend to ask:
>>+ What should we fix first? (prescriptive)
>>+ What steps can I take to reduce XSS attack surface by 80%?
>
> The BSIMM is not for tactical folks.

That's too bad. Security is largely tactical, like it or not.


>?But should you base your decision regarding "what to fix first" on goat sacrifice?
>?What should drive that decision? ?Moon phase?


It doesn't take much thinking to move beyond "moon phase" to pragmatic
things like:

+ What is being attacked? (the most | or | targeting you)
+ What do I have the most of?
+ What issues present the most risk of impact or loss?
+ etc.

Definitely doesn't take Feynman. Or "moon phase" melodrama.


>> Implementation level folks ask:
>>+ What do I do about this specific attack/weakness?
>>+ How do I make my compensating control (WAF, IPS) block this specific attack?
>
> BSIMM != code review tool, top-n list, book, coding experience, ...

Sure. Again, I was sharing with folks on SC-L what people out in IRL
at what layers of an organization actually care about.


>>BSIMM is probably useful for government agencies, or some large
>>organizations. But the vast majority of clients I work with don't have
>>the time or need or ability to take advantage of BSIMM. Nor should
>>they. They don't need a software security group.
>
> Where to start. ?All I can say about BSIMM so far is that is appears
> to be useful for 30 large commercial organizations carrying out real
> software security initiatives.


BSIMM might be useful. I don't think it's necessary. More power to
BSIMM though. I think everyone on SC-L would appreciate more good
data, and BSIMM certainly can collect some interesting data.


> But what about SMB (small to medium sized business)?

I don't deal a lot with SMB, but certainly they don't need BSIMM. They
might make use of the metrics (?) though I doubt it. They want, and
probably need, Top(n) lists and prescriptive guidance.


> Arian, who are your clients?

Mostly fortune-listed (100/500/2000, etc.), but including a broad
spectrum from small online startups to east coast financial
institutions. Mostly people who do business on the Internet, and care
about that business, and security (to try and put them all in a
singular bucket).


>?How many developers do they have?

>From a handful to thousands, to tens of thousands. Why?


> ?Who do you report to as a consultant?

I haven't done consulting in years.


> ?How do you help them make business decisions?

With Math, mostly, and pragmatic prioritization so they can move on
and focus on their business, and get security out of the way as much
as possible.


> Regarding the existence of an SSG, see this article
> <http://www.informit.com/articles/article.aspx?p=1434903>.
> ?Are your customers too small to have an SSG? ?Are YOU the SSG?
> ?Are your customers not mature enough for an SSG? ?Data would be great.

Not many organizations need an SSG today, unless they have a TON of
developers and are an ISV, or a SaaS version of an old-school ISV
(Salesforce.com).

I do think they benefit highly from a developer-turned-SSP. But I
don't think there are enough of those to go around. So the network and
widget security folks, and even the policy wanks, are going to
probably play a role in software security.


>>But, as should be no surprise, I cateogrically disagree with the
>>entire concluding paragraph of the article. Sadly it's just more faith
>>and magic from Gary's end. We all can do better than that.
>
> You guys and your personal attacks. ?Yeesh.

Gary -- you've been a bit preachy and didactic lately; maybe Obama's
demagoguery has been inspiring you. So be prepared to duck. I'll
define my tomatoes below. Alternately you might consider ending your
articles with "Amen". :)


>?I am pretty sure you meant the "next to last" paragraph

You are correct.


> "As I have said before, the time has come to put away the bug parade boogeyman
> <http://www.informit.com/articles/article.aspx?p=1248057>,
> the top 25 tea leaves <http://www.informit.com/articles/article.aspx?p=1322398>,
> black box web app goat sacrifice, and the occult reading of pen testing entrails.
> It's science time. ?And the more descriptive and data driven we are, the better."
>
> Can you be more specific about your disagreements please?


Yes, I think, quite simply: that paragraph has a sign swinging over it
that says "out to lunch".


1. Bug Parades are great. They can include design flaws and such as
well. (Don't need a semantic debate about bug vs. flaw, please; we all
get it.)

It's time to refine our bug parades with more real world data and make
sure they reflect people's needs. If flawed design patterns need to be
in there, they can be.


2. Top25 has a very valuable place. It gets things done. It moves the
bar. It gets seatbelts installed.


3. Black Box testing is super valuable. It gives you a run-time
measuring stick to evaluate what works and what doesn't. Is developer
training working? Is your WAF working? Is your source code scanning
properly including the right libraries?

Not to mention BB gives you an immediate, essential attack surface you
need to know. And yes, I mean Need to Know.


4. Pen Testing is very valuable. It tells you what you absolutely,
positively, need to care about, at a minimum. There are many reasons
pen testing is valuable, and still sought-after, but that's for a
longer discussion.

I've been picking up Marcus Ranum detritus for over a decade by
helping people confused with his rants about how "penetrate and patch"
doesn't work, and how we need to start from the ground up and "build
secure networks" and "write secure code". Maybe Ranum sandbagged you
with one of his rants and it stuck?

Anyway -- I can help you out here if you want to discuss further.


5. What world of science do you live in?

Modern science is driven by statistics. I provide my customers math
and stats, and constantly work to improve this. I think, in fact, we
provide more stats than anyone on the planet today in the field of
webappsec.

The fundamental premise of science is that a hypothesis becomes a
theory when you have tests that can be performed by two or more
people, and publicly verified. So we're doing all of that above.
That's definitely science.

I'm not sure where the "It's science time" comes in. Is there a dance
that goes with that?



> We'll just ignore the Nader > Feynman stuff.

I did not say Nader > Feynman.

I said Nader fundamentally improved society by changing business SOP
and promoting safety controls that affected millions, through use of
bug parades and Top(n) lists, and awareness campaigns.

Feynman, not so much.

I'm not sure what your goal is.

Advance SoA: If it's to advance the state-of-the-art in software
security, then BSIMM may be a worthy, lofty goal, and rambling about
Feynman and "science" may be related.


Improve Immediate Quality: If it's to pragmatically improve the
quality of software security, then that's a different thing.

We could do some basic work on improving quantitative vs. qualitative
metrics definitions in software security, and improve focus on finding
out what is really attacked, and what attack surface is most
immediately at risk of compromise, and move the bar a meaningful
amount.

I guess I'm just not a fan of huge GW Bush style programs where you
mobilize a special task force and invade another country to count WMDs
before you can identify that you have a basic problem and take steps
to solve it. I'm not even sure big programs like that improve
security.

I think a couple of guns in a couple of hands of a couple of pilots
and, wow...we might not be in Afghanistan or Iraq.

I tend to lean more towards pragmatic solutions like that in software
security. I know most executives I deal with seem to lean in a similar
fashion.

I hear ESAPI makes a good gun these days. Whadda they call that thing?
ESAPI(waf)?

---
Arian J. Evans
"When a strong man, fully armed, guards his own homestead, his
possessions are undisturbed." Luke 11:21


From ken at krvw.com  Thu Feb  4 17:02:42 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 4 Feb 2010 17:02:42 -0500
Subject: [SC-L] Thread is dead -- Re:  BSIMM update (informIT)
In-Reply-To: <C7908C55.1DF0F%gem@cigital.com>
References: <C7908C55.1DF0F%gem@cigital.com>
Message-ID: <F9EFAC0F-FA0C-4982-8121-131A5A17EB8E@krvw.com>

OK, so this thread has heated up substantially and is on the verge of flare-up.  So, I'm declaring the thread to be dead and expunging the extant queue.

If anyone has any civil and value-added points to add, feel free to submit them, of course.  As always, I encourage free and open debate here, so long as it remains civil and on topic.

Cheers,

Ken

-----
Kenneth R. van Wyk
SC-L Moderator

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100204/a5c087eb/attachment-0001.bin>

From coley at linus.mitre.org  Fri Feb  5 01:46:08 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 5 Feb 2010 01:46:08 -0500 (EST)
Subject: [SC-L] BSIMM update (informIT)
In-Reply-To: <65058E0E-8D4D-4458-8293-E1018343D725@adobe.com>
References: <C7908C55.1DF0F%gem@cigital.com> <4B6B3773.40009@manico.net>
	<65058E0E-8D4D-4458-8293-E1018343D725@adobe.com>
Message-ID: <Pine.GSO.4.64.1002050114180.11413@faron.mitre.org>


On Thu, 4 Feb 2010, Brad Arkin wrote:

> As a result, the count per ISV of bugs submitted to the Tipping Point 
> program is more of an indicator of what technology is popular in the 
> research community rather than how secure a product is.

Using anecdotal evidence from about 40,000 [sic] published CVEs over 10 
years, I'd tend to agree - my impression is that the applied research 
community is fickle, inconsistent, unpredictable, prone to fads, and far 
from being a unified demographic.  (which in one way is a good thing 
'cause it keeps things interesting.)

Did people know that a single person is responsible for a massive spike in 
symlink discoveries in 2008?  Just 'cause he felt like looking for that 
kind of problem, and he used his trusty grep program against a zillion 
shell scripts in various Debian packages.  So, what we thought was a vuln 
type that was mostly gone, isn't, because some guy decided to look for 
'em.

Don't get me started on the 15-year-old kid who spent a maximum of 10 
minutes on every downloadable/demo program he could find back in 2005 and 
gave us vuln DB people nightmares during the winter of '05-'06, because 
even though he wasn't skilled, many of his reports were correct.  His blog 
post on his super-l33t method was illuminating, but it was a "r0tten" time 
altogether.  Thankfully, he burned out and decided to go underground and 
privately share his new findings instead of publishing them.

Once upon a time, people screamed about how Firefox was so much secure 
because it had almost no security vulns, then the product hit some kind of 
magic market-share number and suddenly they're releasing a couple dozen 
advisories a year.  Coincidence?  Must be.

No need to mention the Oracle "unbreakable" promise and the near-immediate 
counter-argument from a couple researchers.

I've heard more than once from some professional researchers that they 
wouldn't be caught dead publishing an advisory about some generic XSS. 
They only bother to publish stuff that's interesting.  I know there's some 
science-y term for that kind of "publish only new stuff" phenomenon but I 
forget what it is.

Format string vulns got identified and nearly wiped out in the course of a 
couple years.  They were easy to find and fix, and they were fun to 
exploit.  But that was 8 or 9 years ago so that's going back far enough.

You can't trust stats based on public vuln disclosures, period.

http://marc.info/?l=bugtraq&m=113650260502218&w=2

(I know, I know, it's more than 4 years old so that's ancient history in 
Internet time and thus not worth paying attention to because everything 
today is just so new and different! ;-))

My personal opinion, backed by no hard stats whatsoever, is to look at the 
types of vulns that are disclosed as a slightly more reliable indication 
of a vendor's maturity.  If you don't have a standard term for it and you 
haven't seen it a hundred times before, then either it's a really, really 
new technology that hasn't been explored by a lot of people, or the 
developer has shaken the security tree pretty hard and removed the 
low-hanging fruit.

- Steve

From James.McGovern at thehartford.com  Fri Feb  5 10:07:41 2010
From: James.McGovern at thehartford.com (McGovern, James F. (eBusiness))
Date: Fri, 5 Feb 2010 10:07:41 -0500
Subject: [SC-L] Metrics
In-Reply-To: <C78F410B.1DDA8%gem@cigital.com>
References: <Pine.GSO.4.64.1002021544290.917@faron.mitre.org>
	<C78F410B.1DDA8%gem@cigital.com>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28702D191C3@AD1HFDEXC312.ad1.prod>

> Here's an example.  In the BSIMM,  10 of 30 firms have built top-N bug
lists based on their >own data culled from their >own code.  I would
love to see how those top-n lists compare to the > OWASP top ten or the
CWE-25.  I would also love to see whether the union of these lists is
>even remotely interesting.  

One of the general patterns I noted while providing feedback to the
OWASP Top Ten listserv is that top ten lists do sort differently. Within
an enterprise setting, it is typical for enterprise applications to be
built on Java, .NET or other compiled languages where as if I were doing
an Internet startup I may leverage more scripting approaches. So, if
different demographics have different behaviors what would a converged
list or even a separate list tell us?

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



From jim.manico at owasp.org  Fri Feb  5 06:48:55 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Fri, 05 Feb 2010 01:48:55 -1000
Subject: [SC-L] OWASP Podcast Series
Message-ID: <4B6C05A7.3090200@owasp.org>

Hello SC-L,

We have released 3 OWASP podcasts over the last few days for your 
listening pleasure:

#60 Interview with Jeremiah Grossman and Robert Hansen (Google pays for 
vulns)
http://www.owasp.org/download/jmanico/owasp_podcast_60.mp3

#59 AppSec round table with Dan Cornell, Boaz Gelbord, Jim Manico, 
Andrew van der Stock, Ben Tomhave and Jeff Williams
http://www.owasp.org/download/jmanico/owasp_podcast_59.mp3

#58 Interview with Ron Gula
http://www.owasp.org/download/jmanico/owasp_podcast_58.mp3

I hope you enjoy.

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net


From arian.evans at anachronic.com  Fri Feb  5 11:50:37 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Fri, 5 Feb 2010 08:50:37 -0800
Subject: [SC-L] Metrics
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE28702D191C3@AD1HFDEXC312.ad1.prod>
References: <Pine.GSO.4.64.1002021544290.917@faron.mitre.org>
	<C78F410B.1DDA8%gem@cigital.com>
	<BFD50E79FBE23A4FB6BE93572A6FE28702D191C3@AD1HFDEXC312.ad1.prod>
Message-ID: <cd1bdfdd1002050850v59adc36fk1b4bfcafb5677b4d@mail.gmail.com>

In the web security world it doesn't seem to matter much. Top(n) Lists
are Top(n).

There is much ideological disagreement over what goes in those lists
and why, but the ratios of defects are fairly consistent. Both with
managed code and with "scripting" languages.

The WhiteHat Security statistics report provides some interesting
insights into this, particularly the last one. It's one of the only
public stats reports out there for webappsec that I know of.

I have observed what I've thought to be differences anecdotally, but
when we crunch the numbers on a large scale, they average out and
issue ratios are fairly consistent. Which shows you the dangerous
power of anecdotes, and statistically small samples, to be misleading.

---
Arian Evans
Software Security Statistician


On Fri, Feb 5, 2010 at 7:07 AM, McGovern, James F. (eBusiness)
<James.McGovern at thehartford.com> wrote:
>> Here's an example. ?In the BSIMM, ?10 of 30 firms have built top-N bug
> lists based on their >own data culled from their >own code. ?I would
> love to see how those top-n lists compare to the > OWASP top ten or the
> CWE-25. ?I would also love to see whether the union of these lists is
>>even remotely interesting.
>
> One of the general patterns I noted while providing feedback to the
> OWASP Top Ten listserv is that top ten lists do sort differently. Within
> an enterprise setting, it is typical for enterprise applications to be
> built on Java, .NET or other compiled languages where as if I were doing
> an Internet startup I may leverage more scripting approaches. So, if
> different demographics have different behaviors what would a converged
> list or even a separate list tell us?
>
> ************************************************************
> 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 at 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.
> _______________________________________________
>


From coley at linus.mitre.org  Fri Feb  5 10:59:34 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 5 Feb 2010 10:59:34 -0500 (EST)
Subject: [SC-L] Metrics
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE28702D191C3@AD1HFDEXC312.ad1.prod>
References: <Pine.GSO.4.64.1002021544290.917@faron.mitre.org>
	<C78F410B.1DDA8%gem@cigital.com>
	<BFD50E79FBE23A4FB6BE93572A6FE28702D191C3@AD1HFDEXC312.ad1.prod>
Message-ID: <Pine.GSO.4.64.1002051056270.11413@faron.mitre.org>


On Fri, 5 Feb 2010, McGovern, James F. (eBusiness) wrote:

> One of the general patterns I noted while providing feedback to the 
> OWASP Top Ten listserv is that top ten lists do sort differently. Within 
> an enterprise setting, it is typical for enterprise applications to be 
> built on Java, .NET or other compiled languages where as if I were doing 
> an Internet startup I may leverage more scripting approaches. So, if 
> different demographics have different behaviors what would a converged 
> list or even a separate list tell us?

A converged list is useful for general recommendations to people who 
haven't made their own custom lists.  The 2010 Top 25, due to be released 
Feb 16, also considers alternate "Focus Profiles" with different 
prioritizations to serve different use cases and get people thinking about 
how to do their own prioritization.

The general list, meanwhile, captures what patterns may exist across all 
participants - i.e., what everyone is most worried about.

- Steve

From boberski_michael at bah.com  Wed Feb 10 19:36:52 2010
From: boberski_michael at bah.com (Boberski, Michael [USA])
Date: Wed, 10 Feb 2010 19:36:52 -0500
Subject: [SC-L] OWASP DEVELOPMENT GUIDE NEWS/CALL FOR CONTRIBUTORS
Message-ID: <21D3693DA55EF14BB72DCC18FB65B2910240553123@ASHBMBX04.resource.ds.bah.com>

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 Project<http://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.boberski at owasp.org<mailto:mike.boberski at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100210/da3c2c58/attachment.htm>

From jeremy.j.epstein at gmail.com  Thu Feb 11 08:42:26 2010
From: jeremy.j.epstein at gmail.com (Jeremy Epstein)
Date: Thu, 11 Feb 2010 08:42:26 -0500
Subject: [SC-L] A massive change at DARPA
Message-ID: <ec51a3571002110542p1c82bdaeof92e40b255c0d53@mail.gmail.com>

OK, many of you don't care about DARPA, but here's something that
happened there you *should* care about.  DARPA funds research, and has
historically drawn its program managers from the ranks of academia and
occasionally the military.  This is a massive change in outlook....


http://news.cnet.com/8301-27080_3-10450552-245.html

 Peiter Zatko--a respected hacker known as "Mudge"--has been tapped to
be a program manager at DARPA, where he will be in charge of funding
research designed to help give the U.S. government tools needed to
protect against cyberattacks, CNET has learned.

Zatko will become a program manager in mid-March within the Strategic
Technologies Office at DARPA (Defense Advanced Research Projects
Agency), which is the research and development office for the
Department of Defense. His focus will be cybersecurity, he said in an
interview with CNET on Tuesday.

One of his main goals will be to fund researchers at hacker spaces,
start-ups, and boutiques who are most likely to develop technologies
that can leapfrog what comes out of large corporations. "I want
revolutionary changes. I don't want evolutionary ones," he said.

He's also hoping that giving a big push to research and development
will do more to advance the progress of cybersecurity than public
policy decisions have been able to do over the past few decades.

[...]

From list-spam at secureconsulting.net  Thu Feb 11 09:22:43 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Thu, 11 Feb 2010 09:22:43 -0500
Subject: [SC-L] A massive change at DARPA
In-Reply-To: <ec51a3571002110542p1c82bdaeof92e40b255c0d53@mail.gmail.com>
References: <ec51a3571002110542p1c82bdaeof92e40b255c0d53@mail.gmail.com>
Message-ID: <4B7412B3.1040008@secureconsulting.net>

I think it's a welcome change. It doesn't say so in this article clip,
but he is Dr. Zatko, and has worked in instruction and academia, so it's
not too far a leap for them. He's also been working in the federal space
quite a bit since the L0pht sold out and shutdown. Dan Geer did
something similar a couple years ago when he joined In-Q-Tel.

On 2/11/10 8:42 AM, Jeremy Epstein wrote:
> OK, many of you don't care about DARPA, but here's something that
> happened there you *should* care about.  DARPA funds research, and has
> historically drawn its program managers from the ranks of academia and
> occasionally the military.  This is a massive change in outlook....
> 
> 
> http://news.cnet.com/8301-27080_3-10450552-245.html
> 
>  Peiter Zatko--a respected hacker known as "Mudge"--has been tapped to
> be a program manager at DARPA, where he will be in charge of funding
> research designed to help give the U.S. government tools needed to
> protect against cyberattacks, CNET has learned.
> 
> Zatko will become a program manager in mid-March within the Strategic
> Technologies Office at DARPA (Defense Advanced Research Projects
> Agency), which is the research and development office for the
> Department of Defense. His focus will be cybersecurity, he said in an
> interview with CNET on Tuesday.
> 
> One of his main goals will be to fund researchers at hacker spaces,
> start-ups, and boutiques who are most likely to develop technologies
> that can leapfrog what comes out of large corporations. "I want
> revolutionary changes. I don't want evolutionary ones," he said.
> 
> He's also hoping that giving a big push to research and development
> will do more to advance the progress of cybersecurity than public
> policy decisions have been able to do over the past few decades.
> 
> [...]
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"What if everything is an illusion and nothing exists? In that case, I
definitely overpaid for my carpet."
Woody Allen

From list-spam at secureconsulting.net  Sun Feb 21 11:33:16 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Sun, 21 Feb 2010 11:33:16 -0500
Subject: [SC-L] a little coding humor...
In-Reply-To: <4B7412B3.1040008@secureconsulting.net>
References: <ec51a3571002110542p1c82bdaeof92e40b255c0d53@mail.gmail.com>
	<4B7412B3.1040008@secureconsulting.net>
Message-ID: <4B81604C.9070200@secureconsulting.net>

Slightly OT, but not by much... provided here for those who don't read
the Sunday comics... :)
http://www.gocomics.com/features/66/feature_items/493384

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"When will I learn? The answer to life's problems aren't at the bottom
of a bottle, they're on TV!"
Homer Simpson

From list-spam at secureconsulting.net  Mon Feb 22 09:17:09 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 22 Feb 2010 09:17:09 -0500
Subject: [SC-L] seeking hard numbers of bug fixes...
Message-ID: <4B8291E5.9020602@secureconsulting.net>

Howdy,

This request is a bit time critical as it's supporting a colleague's
upsell up the food chain tomorrow... we're looking for hard research or
numbers that covers the cost to catch bugs in code pre-launch and
post-launch. The notion being that the organization saves itself money
if it does a reasonable amount of QA (and security testing) up front vs
trying to chase things down after they've been identified (and possibly
exploited).

Any help?

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Imagination is everything. It is the preview of life's coming attractions."
Albert Einstein

From jeremy.j.epstein at gmail.com  Mon Feb 22 10:45:02 2010
From: jeremy.j.epstein at gmail.com (Jeremy Epstein)
Date: Mon, 22 Feb 2010 10:45:02 -0500
Subject: [SC-L] seeking hard numbers of bug fixes...
In-Reply-To: <4B8291E5.9020602@secureconsulting.net>
References: <4B8291E5.9020602@secureconsulting.net>
Message-ID: <ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>

Take a look at Mary Ann Davidson's keynote at ACSAC in Dec 2009.
http://www.acsac.org/2009/program/keynotes/davidson.pdf

On Mon, Feb 22, 2010 at 9:17 AM, Benjamin Tomhave
<list-spam at secureconsulting.net> wrote:
> Howdy,
>
> This request is a bit time critical as it's supporting a colleague's
> upsell up the food chain tomorrow... we're looking for hard research or
> numbers that covers the cost to catch bugs in code pre-launch and
> post-launch. The notion being that the organization saves itself money
> if it does a reasonable amount of QA (and security testing) up front vs
> trying to chase things down after they've been identified (and possibly
> exploited).
>
> Any help?
>
> Thank you,
>
> -ben
>
> --
> Benjamin Tomhave, MS, CISSP
> tomhave at secureconsulting.net
> Blog: http://www.secureconsulting.net/
> Twitter: http://twitter.com/falconsview
> LI: http://www.linkedin.com/in/btomhave
>
> [ Random Quote: ]
> "Imagination is everything. It is the preview of life's coming attractions."
> Albert Einstein
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>

From Kevin.Wall at qwest.com  Mon Feb 22 11:22:29 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Mon, 22 Feb 2010 10:22:29 -0600
Subject: [SC-L] seeking hard numbers of bug fixes...
In-Reply-To: <4B8291E5.9020602@secureconsulting.net>
References: <4B8291E5.9020602@secureconsulting.net>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD340D1C2E96@qtomaexmbm22.AD.QINTRA.COM>

Benjamin Tomhave wrote:
> ... we're looking for hard research or
> numbers that covers the cost to catch bugs in code pre-launch and
> post-launch. The notion being that the organization saves itself money
> if it does a reasonable amount of QA (and security testing)
> up front vs trying to chase things down after they've been identified
> (and possibly exploited).

Ben,

Not sure if this is what you are looking for or not, but back in the
mid- to late-1980s or so, John Musa, a DMTS at Bell Labs, wrote up a
couple of papers that showed this data, although this was in the more
general context of software quality assurance and not specific to
security testing.

I'm pretty sure that Musa published something in either one of the ACM
or IEEE CS journals and included some hard data, collected from a bunch
of (then AT&T) Bell Labs projects. IIRC, the main finding was something
like the cost was ~100 times more to catch and correct a bug during
the normal design / coding phase than it was to catch / correct it
after post-deployment.

Can't help you much more than that. I'm surprised I remembered that much! :)

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From list-spam at secureconsulting.net  Mon Feb 22 11:33:52 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 22 Feb 2010 11:33:52 -0500
Subject: [SC-L] seeking hard numbers of bug fixes...
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD340D1C2E96@qtomaexmbm22.AD.QINTRA.COM>
References: <4B8291E5.9020602@secureconsulting.net>
	<B8E4274903E6F64E8F9E5C21A96D83BD340D1C2E96@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <4B82B1F0.2000403@secureconsulting.net>

Ah, excellent - very helpful!

It appears that Laurie Williams at NCSU has inherited John Musa's
Software Reliability Engineering legacy, and is still active in the
field, and has a number of relevant security articles/papers listed
under Publications.
http://collaboration.csc.ncsu.edu/laurie/

On 2/22/10 11:22 AM, Wall, Kevin wrote:
> Benjamin Tomhave wrote:
>> ... we're looking for hard research or
>> numbers that covers the cost to catch bugs in code pre-launch and
>> post-launch. The notion being that the organization saves itself money
>> if it does a reasonable amount of QA (and security testing)
>> up front vs trying to chase things down after they've been identified
>> (and possibly exploited).
> 
> Ben,
> 
> Not sure if this is what you are looking for or not, but back in the
> mid- to late-1980s or so, John Musa, a DMTS at Bell Labs, wrote up a
> couple of papers that showed this data, although this was in the more
> general context of software quality assurance and not specific to
> security testing.
> 
> I'm pretty sure that Musa published something in either one of the ACM
> or IEEE CS journals and included some hard data, collected from a bunch
> of (then AT&T) Bell Labs projects. IIRC, the main finding was something
> like the cost was ~100 times more to catch and correct a bug during
> the normal design / coding phase than it was to catch / correct it
> after post-deployment.
> 
> Can't help you much more than that. I'm surprised I remembered that much! :)
> 
> -kevin
> ---
> Kevin W. Wall           Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com    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.
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Happiness makes up in height for what it lacks in length."
Robert Frost

From jammer at weak.org  Tue Feb 23 10:06:05 2010
From: jammer at weak.org (Jon McClintock)
Date: Tue, 23 Feb 2010 07:06:05 -0800
Subject: [SC-L] seeking hard numbers of bug fixes...
In-Reply-To: <ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>
References: <4B8291E5.9020602@secureconsulting.net>
	<ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>
Message-ID: <20100223150605.GN31701@weak.org>

On Mon, Feb 22, 2010 at 10:45:02AM -0500, Jeremy Epstein wrote:
> Take a look at Mary Ann Davidson's keynote at ACSAC in Dec 2009.
> http://www.acsac.org/2009/program/keynotes/davidson.pdf

This provides a pretty good examination of the costs of patching 
commercial software. Has anyone done a similar analysis for web 
applications? I'd expect the costs to be dramatically lower, given
thant you're typically producing a single patch for a handful of
homogenous systems.

-Jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://krvw.com/pipermail/sc-l/attachments/20100223/27d5779a/attachment.pgp>

From Paco at cigital.com  Wed Feb 24 10:46:56 2010
From: Paco at cigital.com (Paco Hope)
Date: Wed, 24 Feb 2010 10:46:56 -0500
Subject: [SC-L] web apps are homogenous?
In-Reply-To: <20100223150605.GN31701@weak.org>
References: <4B8291E5.9020602@secureconsulting.net>
	<ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>
	<20100223150605.GN31701@weak.org>
Message-ID: <679D9F0E-0191-48C9-96EA-172E166061B5@cigital.com>


On Feb 23, 2010, at 10:06 AM, Jon McClintock wrote:
> This provides a pretty good examination of the costs of patching 
> commercial software. Has anyone done a similar analysis for web 
> applications? I'd expect the costs to be dramatically lower, given
> thant you're typically producing a single patch for a handful of
> homogenous systems.

I don't think "webness" conveys any more homogeneity than, say "windowsness" or "linuxness."

What part of being a web application provides homogeneity in a way that makes patching cheaper?

Paco
--
Paco Hope, CISSP - CSSLP
Technical Manager, Cigital, Inc.
http://www.cigital.com/
Software Confidence. Achieved.



From jammer at weak.org  Thu Feb 25 01:56:06 2010
From: jammer at weak.org (Jon McClintock)
Date: Wed, 24 Feb 2010 22:56:06 -0800
Subject: [SC-L] web apps are homogenous?
In-Reply-To: <679D9F0E-0191-48C9-96EA-172E166061B5@cigital.com>
References: <4B8291E5.9020602@secureconsulting.net>
	<ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>
	<20100223150605.GN31701@weak.org>
	<679D9F0E-0191-48C9-96EA-172E166061B5@cigital.com>
Message-ID: <20100225065606.GU31701@weak.org>

On Wed, Feb 24, 2010 at 10:46:56AM -0500, Paco Hope wrote:
> I don't think "webness" conveys any more homogeneity than, say "windowsness" or "linuxness."
> 
> What part of being a web application provides homogeneity in a way that makes patching cheaper?

In a word, control. Let's compare two different organizations: a
commercial software development company, and a web commerce company.
They both develop software, but how the software is deployed and managed
is widely different.

Commercial software is created by one party, and consumed by multiple
other parties. Those parties may run it in widely different operating
environments, with different network, software and harware
configurations. They may be running old versions of the software, or
using it in novel ways.

If the commercial software development company has to patch a
vulnerability, they need to first determine which releases of the
software need to be patched, develop and test a patch for each supported
version, test it across the plethora different configurations their
customers may be running, develop release notes and a security advisory,
make the patch available, and support their customers while they are
patching.

For a web commerce company, however, the picture is entirely different. 
While their production fleet may comprise hundreds, or even thousands,
of servers, they're likely all running the exact same software and 
configuration, using a configuration management system to deploy the
website software and keep it in sync.

If the web commerce company identifies a vulnerability in their website,
they can debug the running stack, create a fix, test it against an
exact replica of the production stack, and use automated tools to 
deploy the patch to their entire fleet in one operation.

-Jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://krvw.com/pipermail/sc-l/attachments/20100224/4398b128/attachment.pgp>

From list-spam at secureconsulting.net  Thu Feb 25 06:42:44 2010
From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Thu, 25 Feb 2010 06:42:44 -0500
Subject: [SC-L] web apps are homogenous?
In-Reply-To: <20100225065606.GU31701@weak.org>
References: <4B8291E5.9020602@secureconsulting.net>	<ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>	<20100223150605.GN31701@weak.org>	<679D9F0E-0191-48C9-96EA-172E166061B5@cigital.com>
	<20100225065606.GU31701@weak.org>
Message-ID: <4B866234.6080707@secureconsulting.net>

Jon,

I think you're getting out of the scope of the costing exercise. The
research and estimates around "time to fix" are based on the cost
associated with developing the patch, not with deploying it. One could
argue that the cost of fixing bugs - particularly major ones - is much
higher for web applications given that they are more likely to be
rapidly deployed and that the discovery of the bug is more likely to be
widely publicized (especially if it leads to a breach). Everybody has a
reasonable expectation that widely deployed commercial software is going
to have various bugs over its life (e.g. Windows, Adobe products), while
people seem to still be generally surprised when holes pop-up in web apps.

Now, that being said, it is still a valid question as to if there is a
cost differential between fix classic compiled code and modern web code.
Toward that end, I would recommend looking into Laurie Williams' work at
NCSU. She has inherited John Musa's Software Reliability Engineering
legacy, is active in the field, and has published a number of articles
and papers potentially relevant to this field. See:
http://collaboration.csc.ncsu.edu/laurie/

fwiw.

-ben

On 2/25/10 1:56 AM, Jon McClintock wrote:
> On Wed, Feb 24, 2010 at 10:46:56AM -0500, Paco Hope wrote:
>> I don't think "webness" conveys any more homogeneity than, say
>> "windowsness" or "linuxness."
>> 
>> What part of being a web application provides homogeneity in a way
>> that makes patching cheaper?
> 
> In a word, control. Let's compare two different organizations: a 
> commercial software development company, and a web commerce company. 
> They both develop software, but how the software is deployed and
> managed is widely different.
> 
> Commercial software is created by one party, and consumed by
> multiple other parties. Those parties may run it in widely different
> operating environments, with different network, software and harware 
> configurations. They may be running old versions of the software, or 
> using it in novel ways.
> 
> If the commercial software development company has to patch a 
> vulnerability, they need to first determine which releases of the 
> software need to be patched, develop and test a patch for each
> supported version, test it across the plethora different
> configurations their customers may be running, develop release notes
> and a security advisory, make the patch available, and support their
> customers while they are patching.
> 
> For a web commerce company, however, the picture is entirely
> different. While their production fleet may comprise hundreds, or
> even thousands, of servers, they're likely all running the exact same
> software and configuration, using a configuration management system
> to deploy the website software and keep it in sync.
> 
> If the web commerce company identifies a vulnerability in their
> website, they can debug the running stack, create a fix, test it
> against an exact replica of the production stack, and use automated
> tools to deploy the patch to their entire fleet in one operation.
> 
> -Jon
> 
> 
> 
> _______________________________________________ Secure Coding mailing
> list (SC-L) SC-L at 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. 
> _______________________________________________

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Oh, so they have internet on computers now!"
Homer Simpson

From cwysopal at veracode.com  Fri Feb 26 11:15:25 2010
From: cwysopal at veracode.com (Chris Wysopal)
Date: Fri, 26 Feb 2010 11:15:25 -0500
Subject: [SC-L] web apps are homogenous?
In-Reply-To: <4B866234.6080707@secureconsulting.net>
References: <4B8291E5.9020602@secureconsulting.net>
	<ec51a3571002220745k33518ae1xc57eadd2576ec3a0@mail.gmail.com>
	<20100223150605.GN31701@weak.org>
	<679D9F0E-0191-48C9-96EA-172E166061B5@cigital.com>
	<20100225065606.GU31701@weak.org>
	<4B866234.6080707@secureconsulting.net>
Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD0229240F99@orbital.Veracode.local>


A large part of the cost of fixing a bug, especially late in the dev cycle after testing is complete, is the cost of regression testing.  The cost of regression testing of a patch for commercial software is much higher than the cost of a custom web application.  Think of an Oracle bug that spans 5 supported product revisions over 5 platforms.  That is 25 separate builds that need to be regression tested. Plus regression testing for commercial software needs to be more extensive because many different deployment scenarios need to be incorporated.  Mary Ann Davidson told me this could cost up to $1M in a worst case scenario. A bug in a custom enterprise web application may need to be fixed quicker do to exposure which may raise the cost slightly but this is nothing compared to the testing effort to validate the fix works and did not break anything. The cost of fixing a bug late in the dev cycle or once the software is deployed is much higher for commercial software than it is for a single instance web application.  The cost scales with number of supported revisions effected and the size and complexity of the installed base.

-Chris

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Benjamin Tomhave
Sent: Thursday, February 25, 2010 6:43 AM
To: Jon McClintock
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] web apps are homogenous?

Jon,

I think you're getting out of the scope of the costing exercise. The
research and estimates around "time to fix" are based on the cost
associated with developing the patch, not with deploying it. One could
argue that the cost of fixing bugs - particularly major ones - is much
higher for web applications given that they are more likely to be
rapidly deployed and that the discovery of the bug is more likely to be
widely publicized (especially if it leads to a breach). Everybody has a
reasonable expectation that widely deployed commercial software is going
to have various bugs over its life (e.g. Windows, Adobe products), while
people seem to still be generally surprised when holes pop-up in web apps.

Now, that being said, it is still a valid question as to if there is a
cost differential between fix classic compiled code and modern web code.
Toward that end, I would recommend looking into Laurie Williams' work at
NCSU. She has inherited John Musa's Software Reliability Engineering
legacy, is active in the field, and has published a number of articles
and papers potentially relevant to this field. See:
http://collaboration.csc.ncsu.edu/laurie/

fwiw.

-ben

On 2/25/10 1:56 AM, Jon McClintock wrote:
> On Wed, Feb 24, 2010 at 10:46:56AM -0500, Paco Hope wrote:
>> I don't think "webness" conveys any more homogeneity than, say
>> "windowsness" or "linuxness."
>> 
>> What part of being a web application provides homogeneity in a way
>> that makes patching cheaper?
> 
> In a word, control. Let's compare two different organizations: a 
> commercial software development company, and a web commerce company. 
> They both develop software, but how the software is deployed and
> managed is widely different.
> 
> Commercial software is created by one party, and consumed by
> multiple other parties. Those parties may run it in widely different
> operating environments, with different network, software and harware 
> configurations. They may be running old versions of the software, or 
> using it in novel ways.
> 
> If the commercial software development company has to patch a 
> vulnerability, they need to first determine which releases of the 
> software need to be patched, develop and test a patch for each
> supported version, test it across the plethora different
> configurations their customers may be running, develop release notes
> and a security advisory, make the patch available, and support their
> customers while they are patching.
> 
> For a web commerce company, however, the picture is entirely
> different. While their production fleet may comprise hundreds, or
> even thousands, of servers, they're likely all running the exact same
> software and configuration, using a configuration management system
> to deploy the website software and keep it in sync.
> 
> If the web commerce company identifies a vulnerability in their
> website, they can debug the running stack, create a fix, test it
> against an exact replica of the production stack, and use automated
> tools to deploy the patch to their entire fleet in one operation.
> 
> -Jon
> 
> 
> 
> _______________________________________________ Secure Coding mailing
> list (SC-L) SC-L at 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. 
> _______________________________________________

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Oh, so they have internet on computers now!"
Homer Simpson
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________


From gem at cigital.com  Mon Mar  1 21:31:22 2010
From: gem at cigital.com (Gary McGraw)
Date: Mon, 1 Mar 2010 21:31:22 -0500
Subject: [SC-L] BSIMM2: 15 things most firms do
Message-ID: <C7B1E2AA.1ED31%gem@cigital.com>

hi sc-l,

I just spent an excellent week in Leuven, Belgium at secappdev (our fearless moderator Ken was there as always).  If you've never been to secappdev, it is certainly something to do at least once, if not annually.

One of the five presentations I gave in Leuven was about BSIMM2 (the 30 firm version of BSIMM).  I wrote up an article with Brian Chess and Sammy Migues (my BSIMM co-creators) called "Software [In]security: What Works in Software Security --- Fifteen Common Activities from BSIMM2."  In addition to highlighting the fifteen most common BSIMM activities, the article also provides the 30 firm data for all 110 activities in public for the first time.

http://www.informit.com/articles/article.aspx?p=1569495

We're unveiling  some statistical results at RSA this week that will enhance and expand the dataset published in the article.  We'll do an official BSIMM2 launch within the next couple of months.

Hope to see some of you at the RSA show (probably in the hall track).

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


From gem at cigital.com  Wed Mar  3 10:06:09 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 3 Mar 2010 10:06:09 -0500
Subject: [SC-L] Silver Bullet: Greg Morrisett
Message-ID: <C7B3E511.1EE11%gem@cigital.com>

hi sc-l,

Greetings from RSA where the security hype is very hype-y indeed.  To counterbalance the nonsense, we just published Silver Bullet number 47, an interview with Harvard professor Greg Morrisett.  Greg and I grew up together in Kingsport, Tennessee and it has been a pleasure watching my first business partner get a PhD at CMU, become a Dean, and generally kick butt in programming languages.  Our conversation was a blast:

http://www.cigital.com/silverbullet/show-047/

Lots of discussion about programming languages in tis episode.  Sadly, we didn't reveal any of the ridiculous stories we can tell about each other from adolescence (something about mutually assured destruction).

As always, thanks to IEEE S&P magazine for co-sponsoring Silver Bullet with Cigital.   Your feedback is welcome.

gem

company www.cigital.com
blog www.cigital.com/justiceleague
book www.swsec.com


From koved at us.ibm.com  Fri Mar  5 13:12:07 2010
From: koved at us.ibm.com (Larry Koved)
Date: Fri, 5 Mar 2010 13:12:07 -0500
Subject: [SC-L] cfp: W2SP 2010: Web 2.0 Security and Privacy 2010 CFP - 2nd
	call
In-Reply-To: <OF367F5FDC.B6DC1CD9-ON852576A7.004BE2F3-852576A7.004BF1CD@LocalDomain>
References: <OF367F5FDC.B6DC1CD9-ON852576A7.004BE2F3-852576A7.004BF1CD@LocalDomain>
Message-ID: <OF944006F7.CD77F85F-ON852576DD.0063E788-852576DD.0063FDB0@us.ibm.com>

The workshop chairs would like to invite you participate in the 4th annual 

workshop on Web 2.0 Security and Privacy.  Started in 2007, this 
successful 
series of workshops has attracted participation from both academia and 
industry, and participants from around the world.  This workshop is held
in conjunction with the 2010 IEEE Symposium on Security and Privacy. 




Workshop Call for Papers
W2SP 2010: Web 2.0 Security and Privacy 2010

Thursday, May 20
The Claremont Resort, Oakland, California
Web site: http://w2spconf.com/2010

The goal of this one day workshop is to bring together researchers and
practitioners from academia and industry to focus on understanding Web
2.0 security and privacy issues, and establishing new collaborations
in these areas.

Web 2.0 is about connecting people and amplifying the power of working
together. An ongoing explosion of new technology is powering
increasingly complex social and business interactions as well as
enabling an unprecedented level of unmediated information exchange and
horizontal organization. These interactions rely on composition of
content and services from multiple sources, commonly called mash-ups,
leading to systems with complex trust boundaries. This trend is likely
to continue because individuals, businesses, and other organizations
desire the simplicity, efficiency, and utility these technologies
offer.

Though these technologies have had many positive effects, they raise
issues about management of identities, personal safety, reputation,
privacy, anonymity, transient and long-term relationships, and
composition of function and content, both on the server and on the
client side (web browsers and mobile platforms). Although many of the
underlying security and privacy issues are not new, the use of these
technologies by very large and disparate populations raises new
questions. This workshop is intended to discuss the limitations of
current technologies and explore alternatives.

The scope of W2SP 2010 includes, but is not limited to:

Trustworthy cloud-based services
Usable security and privacy
Security and privacy as a service
Security for the mobile web
Identity management and psuedonymity
Web services/feeds/mashups
Security and privacy policies for composible content
Next-generation browser technology
Secure extensions and plug-ins
Advertisement and affiliate fraud

Potential workshop participants should submit a paper on topics
relevant to Web 2.0 security and privacy issues. We are seeking both
short position papers (2 - 4 pages) and refereed papers (a maximum of
8 pages, including references and appendices). Papers longer than 8
pages may be automatically rejected by the chair or workshop
committee. From the submissions, the program committee will strive to
balance participation between academia and industry and across topics.
Selected papers will appear on the workshop web site; W2SP has no
formal published proceedings.

For papers that focus primarily on the security and privacy of social
networks, we encourage authors to submit their paper to the Social
Network Security and Privacy (SNSP) workshop, which is concurrent and
co-located with W2SP. Submitted papers may be referred to the SNSP
program committee for consideration.

Workshop Co-Chairs
Larry Koved (IBM Research)
Dan S. Wallach (Rice University)

Program Chair
Collin Jackson (Carnegie Mellon University)

Program Committee
Ben Adida (Harvard University)
Dirk Balfanz (Google)
Adam Barth (UC Berkeley)
Konstantin (Kosta) Beznosov (University of British Columbia)
Suresh Chari (IBM Research)
Hao Chen (UC Davis)
Collin Jackson (Carnegie Mellon University)
Martin Johns (SAP Research)
Rob Johnson (Stony Brook University)
Engin Kirda (Institute Eurecom)
Larry Koved (IBM Research)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Dawn Song (UC Berkeley)
Dan S. Wallach (Rice University)
Helen Wang (Microsoft Research)

Important Dates

Paper submission deadline: Tuesday, March 23, 2010 (11:59pm US-Eastern)
Workshop acceptance notification date: April 11, 2010
Workshop date: Thursday, May 20, 2010

Registration: Workshop registration will be available via the 2010
IEEE Symposium on Security and Privacy conference web site.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100305/ae3bc236/attachment.htm>

From tomhave at secureconsulting.net  Mon Mar  8 10:40:04 2010
From: tomhave at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 08 Mar 2010 10:40:04 -0500
Subject: [SC-L] sponsors still needed for BSides Austin
Message-ID: <4B951A54.4090309@secureconsulting.net>

Hi folks,

We need your help. We're still looking for sponsors for this weekend's
Security BSides Austin, which is set to occur the same day as the
kickoff for SxSW Interactive (a major developer conference). We have
official sponsorship from Astaro and Panda, plus a couple unofficial
sponsors. We'd love to see your organization involved, too!

Unconference details here:
http://www.securitybsides.com/BSidesAustin

Here are some benefits for sponsoring:
    * Being part of the media conversation: As people talk about us they
talk about you or at least see you.  Security B-Sides has been covered
in magazines, podcasts, videocasts, blogs, and even inscribed on
microchips.  Get caught up in the conversation and be part of what
people are talking about.
    * Brand recognition and awareness: Depending on the level of
sponsorship, you may recognize your brand placement at some or all of
the following: t-shirts, signage/lanyards, lunch sessions, or attendee
badges. Based on your level of participation, create and custom branding
may be arranged including transportation, banners, and podcast interviews.
    * Big Fish in a Small Pond: For some, sponsoring large events is not
within their price range leaving them with no option for communicating
their message. BSides is just the place for you! This small, community
atmosphere brings together active and engaged participants who want to
absorb information. Sponsoring a BSides event enables to be that big
fish in a small pond and better communicate your message to an active
audience.
    * Stay in touch with the industry: BSides enables its supporters and
participants to identify and connect with industry leaders and voices.
These participants represent the social networking of security. They are
the people who you want to engage to solicit feedback and bring voice to
your conversation.
    * Targeted and Direct Audience: You didn't enter the secrutity
industry selling your product to everyone the same way, so why approach
events that way?  Instead of marketing to the broader "security"
community connect directly with the security practioners who write
about, talk about, recommend, and implement security products and services.
    * Be associated with the next big thing: Nobody knows what the ?next
big thing? will be, but these events are community driven with
presentations voted upon by the industry. There is no magic to how it
works, but we believe that listening to the underground can help prepare
you and help identify what the next big thing might be.

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"How young can you die of old age?"
Steven Wright


From mparsons1980 at gmail.com  Wed Mar 10 15:36:17 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Wed, 10 Mar 2010 14:36:17 -0600
Subject: [SC-L] USA today article Cyber Crimes and software security
	evangelism
Message-ID: <010d01cac091$56e660d0$04b32270$@com>

I was reading the USA today and it stated more cyber criminals are getting
away with cyber crimes.  I was thinking that this brings more value to us
that are concerned about software security and can help evangelize and fix
the problem.  God Bless.

Matt

 

 

http://parsonsisconsulting.blogspot.com/

 

http://www.usatoday.com/news/snapshot.htm

 

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100310/65a7b078/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100310/65a7b078/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100310/65a7b078/attachment-0001.jpeg>

From mparsons1980 at gmail.com  Fri Mar 12 08:56:01 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Fri, 12 Mar 2010 07:56:01 -0600
Subject: [SC-L] black berry security
Message-ID: <051201cac1eb$c075c760$41615620$@com>

I had too many files open on my black berry last night while listening to
music.  It produced a java run time error.  It made me think about
blackberry security.  What is the threat to black berrys and having them
write secure code and have it undergo a security review?  Has anyone worked
on mobile app security? I find it very interesting and would like to get
involved.   I wrote about it on my blog.   

 

http://parsonsisconsulting.blogspot.com/

 

 

All the best.   

 

Matt

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100312/c1687abe/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100312/c1687abe/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100312/c1687abe/attachment-0001.jpeg>

From mparsons1980 at gmail.com  Tue Mar 16 11:41:06 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Tue, 16 Mar 2010 10:41:06 -0500
Subject: [SC-L] blog post and open source vulnerabilities to blog about
Message-ID: <039b01cac51f$1ed36930$5c7a3b90$@com>

 

Hello,

I am working on a software security blog and I am trying to find open source
vulnerabilities to present and share.  Does anyone else have any open source
vulnerabilities that they could share and talk about?   I think this could
be the best way to learn in the open source community about security.   I
have a few but I would like to blog about a different piece of code almost
every day.   

 

God Bless.
Matt

 

 

http://parsonsisconsulting.blogspot.com/

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/241c4738/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/241c4738/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/241c4738/attachment-0001.jpeg>

From jrose at owasp.org  Tue Mar 16 13:13:41 2010
From: jrose at owasp.org (Jon Rose)
Date: Tue, 16 Mar 2010 13:13:41 -0400
Subject: [SC-L] blog post and open source vulnerabilities to blog about
In-Reply-To: <039b01cac51f$1ed36930$5c7a3b90$@com>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
Message-ID: <19E3F445-4F01-4B1E-BEC4-195A5FE929CE@owap.org>

http://codesearch0day.appspot.com/


On Mar 16, 2010, at 11:41 AM, Matt Parsons wrote:

>
> Hello,
> I am working on a software security blog and I am trying to find  
> open source vulnerabilities to present and share.  Does anyone else  
> have any open source vulnerabilities that they could share and talk  
> about?   I think this could be the best way to learn in the open  
> source community about security.   I have a few but I would like to  
> blog about a different piece of code almost every day.
>
> God Bless.
> Matt
>
>
> http://parsonsisconsulting.blogspot.com/
>
>
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> "Do Good and Fear No Man"
> Fort Worth, Texas
> A.K.A The Keyboard Cowboy
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> http://parsonsisconsulting.blogspot.com/
> http://www.vimeo.com/8939668
>
> <image001.jpg>
>
> <image002.jpg>
>
>
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/413cb615/attachment.htm>

From James.McGovern at thehartford.com  Tue Mar 16 14:35:43 2010
From: James.McGovern at thehartford.com (McGovern, James F. (P+C Technology))
Date: Tue, 16 Mar 2010 14:35:43 -0400
Subject: [SC-L] blog post and open source vulnerabilities to blog about
In-Reply-To: <039b01cac51f$1ed36930$5c7a3b90$@com>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE287033C71F1@AD1HFDEXC312.ad1.prod>

This doesn't feel like responsible disclosure and is not the way to
announce weaknesses in software. It is best to deal with scenarios that
have already been addressed. 

________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Matt Parsons
Sent: Tuesday, March 16, 2010 11:41 AM
To: OWASPDallas at utdallas.edu
Cc: websecurity at webappsec.org; SC-L at securecoding.org
Subject: [SC-L] blog post and open source vulnerabilities to blog about



 

Hello,

I am working on a software security blog and I am trying to find open
source vulnerabilities to present and share.  Does anyone else have any
open source vulnerabilities that they could share and talk about?   I
think this could be the best way to learn in the open source community
about security.   I have a few but I would like to blog about a
different piece of code almost every day.   

 

God Bless.
Matt

 

 

http://parsonsisconsulting.blogspot.com/

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

 

 

 

 

 

 

 

 

 

 

************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/8406568b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: image001.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/8406568b/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: image002.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/8406568b/attachment-0003.jpeg>

From Greg.Beeley at LightSys.org  Tue Mar 16 15:37:04 2010
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Tue, 16 Mar 2010 14:37:04 -0500
Subject: [SC-L] blog post and open source vulnerabilities to blog about
In-Reply-To: <039b01cac51f$1ed36930$5c7a3b90$@com>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
Message-ID: <4B9FDDE0.9090809@LightSys.org>

Matt,

You can find quite a list of OSS vulnerabilities over an CVE (cve.mitre.org)
or NVD (nvd.nist.gov), but here are a couple ones that I tend to use for
illustrative purposes when teaching.

- Apache Chunked Encoding vuln (#CVE-2002-0392), an integer overflow.  Of
particular interest because when it was first discovered it was not believed
to be exploitable to gain remote root, but due to a nuance in a memcpy() /
memmove() implementation, it was (I think I'm remembering this right).  An
example that non-exploitability depends on more than just the program itself,
but also on the underlying systems (libraries, compiler, hardware, etc).

- OpenSSH crc32 compensation attack detector vulnerability (#CVE-2001-0144).
Of interest because this was a remote-root vulnerability in a piece of code
that was used solely to try to thwart an SSH protocol 1 cryptographic attack.
A good example of more code introducing more bugs, even when the "more code"
had an important security purpose.

- Never made it into any distributed code, as it was in version control only,
but there was a Linux kernel vulnerability that was a backdoor attempt.
(http://kerneltrap.org/node/1584). Of interest because it was apparently an
intentional "typo" bug to create a backdoor.  A good example of something that
could have easily slid by, but the way that version control was set up as well
as the many eyes working on the kernel, resulted in it coming to light quickly.

- A sendmail bug publicized back in 2006 (#CVE-2006-0058) was of interest
because the vulnerability was not a "typical" buffer overflow, but was due to
(if I remember correctly -- the discussion of this vuln was pretty opaque at
the time, so I could be wrong on this) the intermixing of static and automatic
C function variables in a fairly complex attack scenario (where a residual
static pointer was pointing to a previous incarnation of an automatic buffer),
resulting in an attacker being able to overwrite a section of the stack if the
attack was timed "just right" (it didn't need the nanosecond precision that
was widely publicized at first).  A good example of complex code being more
difficult to secure.

- Greg Beeley
  LightSys

Matt Parsons wrote, On 03/16/2010 10:41 AM:
>  
> 
> Hello,
> 
> I am working on a software security blog and I am trying to find open
> source vulnerabilities to present and share.  Does anyone else have any
> open source vulnerabilities that they could share and talk about?   I
> think this could be the best way to learn in the open source community
> about security.   I have a few but I would like to blog about a
> different piece of code almost every day.  
> 
>  
> 
> God Bless.
> Matt
> 
>  
> 
>  
> 
> http://parsonsisconsulting.blogspot.com/
> 
>  
> 
>  
> 
> Matt Parsons, MSM, CISSP
> 
> 315-559-3588 Blackberry
> 
> 817-294-3789 Home office
> 
> "Do Good and Fear No Man" 
> 
> Fort Worth, Texas
> 
> A.K.A The Keyboard Cowboy
> 
> mailto:mparsons1980 at gmail.com
> 
> http://www.parsonsisconsulting.com
> 
> http://www.o2-ounceopen.com/o2-power-users/
> 
> http://www.linkedin.com/in/parsonsconsulting
> 
> http://parsonsisconsulting.blogspot.com/
> 
> http://www.vimeo.com/8939668
> 
>  
> 
> 0_0_0_0_250_281_csupload_6117291
> 
>  
> 
> untitled
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________

From arshan.dabirsiaghi at aspectsecurity.com  Tue Mar 16 15:48:53 2010
From: arshan.dabirsiaghi at aspectsecurity.com (Arshan Dabirsiaghi)
Date: Tue, 16 Mar 2010 15:48:53 -0400
Subject: [SC-L] [WEB SECURITY] RE: blog post and open source
	vulnerabilities to blog about
In-Reply-To: <BFD50E79FBE23A4FB6BE93572A6FE287033C71F1@AD1HFDEXC312.ad1.prod>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
	<BFD50E79FBE23A4FB6BE93572A6FE287033C71F1@AD1HFDEXC312.ad1.prod>
Message-ID: <B9A412898630124ABE8350F4EBD32E84012675A3@mymail.aspectsecurity.com>

I'm not sure Matt was suggesting burning sharing 0days, but if he was, I
think he should not be discouraged. I think disclosure preference should
be something like a "protected class" within OWASP.

 

Arshan

 

From: McGovern, James F. (P+C Technology)
[mailto:James.McGovern at thehartford.com] 
Sent: Tuesday, March 16, 2010 2:36 PM
To: Matt Parsons; OWASPDallas at utdallas.edu
Cc: websecurity at webappsec.org; SC-L at securecoding.org
Subject: [WEB SECURITY] RE: [SC-L] blog post and open source
vulnerabilities to blog about

 

This doesn't feel like responsible disclosure and is not the way to
announce weaknesses in software. It is best to deal with scenarios that
have already been addressed. 

 

________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Matt Parsons
Sent: Tuesday, March 16, 2010 11:41 AM
To: OWASPDallas at utdallas.edu
Cc: websecurity at webappsec.org; SC-L at securecoding.org
Subject: [SC-L] blog post and open source vulnerabilities to blog about

 

Hello,

I am working on a software security blog and I am trying to find open
source vulnerabilities to present and share.  Does anyone else have any
open source vulnerabilities that they could share and talk about?   I
think this could be the best way to learn in the open source community
about security.   I have a few but I would like to blog about a
different piece of code almost every day.   

 

God Bless.
Matt

 

 

http://parsonsisconsulting.blogspot.com/

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

 

 

 

 

 

 

 

 

 

 

************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/2ed0d977/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: image001.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/2ed0d977/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: image002.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/2ed0d977/attachment-0001.jpeg>

From mparsons1980 at gmail.com  Tue Mar 16 15:52:04 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Tue, 16 Mar 2010 14:52:04 -0500
Subject: [SC-L] [WEB SECURITY] RE: blog post and open source
	vulnerabilities to blog about
In-Reply-To: <B9A412898630124ABE8350F4EBD32E84012675A3@mymail.aspectsecurity.com>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
	<BFD50E79FBE23A4FB6BE93572A6FE287033C71F1@AD1HFDEXC312.ad1.prod>
	<B9A412898630124ABE8350F4EBD32E84012675A3@mymail.aspectsecurity.com>
Message-ID: <048d01cac542$27c9cb10$775d6130$@com>

I am not suggesting exposing zero days.   I only want known vulnerabilities
in applications like web goat etc that are known to everyone.   I don't even
plan on naming where each vulnerability comes from but rather instead change
the code to protect the innocent.  I would never encourage promoting sharing
zero days.  I hope this clears it up.   

 

Thanks,

Matt

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

 <mailto:mparsons1980 at gmail.com> mailto:mparsons1980 at gmail.com

 <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com

 <http://www.o2-ounceopen.com/o2-power-users/>
http://www.o2-ounceopen.com/o2-power-users/

 <http://www.linkedin.com/in/parsonsconsulting>
http://www.linkedin.com/in/parsonsconsulting

 <http://parsonsisconsulting.blogspot.com/>
http://parsonsisconsulting.blogspot.com/

 <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

From: Arshan Dabirsiaghi [mailto:arshan.dabirsiaghi at aspectsecurity.com] 
Sent: Tuesday, March 16, 2010 2:49 PM
To: McGovern, James F. (P+C Technology); Matt Parsons;
OWASPDallas at utdallas.edu
Cc: websecurity at webappsec.org; SC-L at securecoding.org
Subject: RE: [WEB SECURITY] RE: [SC-L] blog post and open source
vulnerabilities to blog about

 

I'm not sure Matt was suggesting burning sharing 0days, but if he was, I
think he should not be discouraged. I think disclosure preference should be
something like a "protected class" within OWASP.

 

Arshan

 

From: McGovern, James F. (P+C Technology)
[mailto:James.McGovern at thehartford.com] 
Sent: Tuesday, March 16, 2010 2:36 PM
To: Matt Parsons; OWASPDallas at utdallas.edu
Cc: websecurity at webappsec.org; SC-L at securecoding.org
Subject: [WEB SECURITY] RE: [SC-L] blog post and open source vulnerabilities
to blog about

 

This doesn't feel like responsible disclosure and is not the way to announce
weaknesses in software. It is best to deal with scenarios that have already
been addressed. 

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Matt Parsons
Sent: Tuesday, March 16, 2010 11:41 AM
To: OWASPDallas at utdallas.edu
Cc: websecurity at webappsec.org; SC-L at securecoding.org
Subject: [SC-L] blog post and open source vulnerabilities to blog about

 

Hello,

I am working on a software security blog and I am trying to find open source
vulnerabilities to present and share.  Does anyone else have any open source
vulnerabilities that they could share and talk about?   I think this could
be the best way to learn in the open source community about security.   I
have a few but I would like to blog about a different piece of code almost
every day.   

 

God Bless.
Matt

 

 

http://parsonsisconsulting.blogspot.com/

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/dfb1c096/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/dfb1c096/attachment-0004.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/dfb1c096/attachment-0005.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/dfb1c096/attachment-0006.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/dfb1c096/attachment-0007.jpeg>

From mparsons1980 at gmail.com  Tue Mar 16 22:37:03 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Tue, 16 Mar 2010 21:37:03 -0500
Subject: [SC-L] market for training CISSPs how to code
Message-ID: <056f01cac57a$bb1c8190$315584b0$@com>

I have been a programmer and a security analyst for a few years now.   When
I first started developers told me I didn't know how to code good enough and
CISSP's told me I didn't have enough security experience.  Has anyone had
any success training CISSP's and non programmers how to write code securely
and train developers how to become CISSP's and learn how to penetration
test?  If not does everyone think that there would be a market for such
training?   

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/f7f2a308/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/f7f2a308/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100316/f7f2a308/attachment-0001.jpeg>

From dan at denimgroup.com  Wed Mar 17 07:09:41 2010
From: dan at denimgroup.com (Dan Cornell)
Date: Wed, 17 Mar 2010 04:09:41 -0700
Subject: [SC-L] blog post and open source vulnerabilities to blog about
In-Reply-To: <4B9FDDE0.9090809@LightSys.org>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
	<4B9FDDE0.9090809@LightSys.org>
Message-ID: <A159EC70B84EFB43B0EAC68C9FEC16DA0122ABE45C7F@VA3DIAXVS111.RED001.local>

At the OWASP Open Review project we run Fortify scans for open source project maintainers.  There is some summary information on the main page, but the actual detailed scan info is only available to the project maintainers.  (Echoing James McGovern's concerns we didn't want it to end up being the "OWASP Open Source 0Day-Publication Project")

More info can be found here:
<http://owasp.fortify.com/>

I do like the idea of looking at CVEs for open source projects.  That is good real-world data that can demonstrate patterns.

Thanks,

Dan

> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-
> bounces at securecoding.org] On Behalf Of Greg Beeley
> Sent: Tuesday, March 16, 2010 2:37 PM
> To: SC-L at securecoding.org
> Subject: Re: [SC-L] blog post and open source vulnerabilities to blog
> about
> 
> Matt,
> 
> You can find quite a list of OSS vulnerabilities over an CVE
> (cve.mitre.org)
> or NVD (nvd.nist.gov), but here are a couple ones that I tend to use
> for
> illustrative purposes when teaching.
> 
> - Apache Chunked Encoding vuln (#CVE-2002-0392), an integer overflow.
> Of
> particular interest because when it was first discovered it was not
> believed
> to be exploitable to gain remote root, but due to a nuance in a
> memcpy() /
> memmove() implementation, it was (I think I'm remembering this right).
> An
> example that non-exploitability depends on more than just the program
> itself,
> but also on the underlying systems (libraries, compiler, hardware,
> etc).
> 
> - OpenSSH crc32 compensation attack detector vulnerability (#CVE-2001-
> 0144).
> Of interest because this was a remote-root vulnerability in a piece of
> code
> that was used solely to try to thwart an SSH protocol 1 cryptographic
> attack.
> A good example of more code introducing more bugs, even when the "more
> code"
> had an important security purpose.
> 
> - Never made it into any distributed code, as it was in version control
> only,
> but there was a Linux kernel vulnerability that was a backdoor attempt.
> (http://kerneltrap.org/node/1584). Of interest because it was
> apparently an
> intentional "typo" bug to create a backdoor.  A good example of
> something that
> could have easily slid by, but the way that version control was set up
> as well
> as the many eyes working on the kernel, resulted in it coming to light
> quickly.
> 
> - A sendmail bug publicized back in 2006 (#CVE-2006-0058) was of
> interest
> because the vulnerability was not a "typical" buffer overflow, but was
> due to
> (if I remember correctly -- the discussion of this vuln was pretty
> opaque at
> the time, so I could be wrong on this) the intermixing of static and
> automatic
> C function variables in a fairly complex attack scenario (where a
> residual
> static pointer was pointing to a previous incarnation of an automatic
> buffer),
> resulting in an attacker being able to overwrite a section of the stack
> if the
> attack was timed "just right" (it didn't need the nanosecond precision
> that
> was widely publicized at first).  A good example of complex code being
> more
> difficult to secure.
> 
> - Greg Beeley
>   LightSys
> 
> Matt Parsons wrote, On 03/16/2010 10:41 AM:
> >
> >
> > Hello,
> >
> > I am working on a software security blog and I am trying to find open
> > source vulnerabilities to present and share.  Does anyone else have
> any
> > open source vulnerabilities that they could share and talk about?   I
> > think this could be the best way to learn in the open source
> community
> > about security.   I have a few but I would like to blog about a
> > different piece of code almost every day.
> >
> >
> >
> > God Bless.
> > Matt
> >
> >
> >
> >
> >
> > http://parsonsisconsulting.blogspot.com/
> >
> >
> >
> >
> >
> > Matt Parsons, MSM, CISSP
> >
> > 315-559-3588 Blackberry
> >
> > 817-294-3789 Home office
> >
> > "Do Good and Fear No Man"
> >
> > Fort Worth, Texas
> >
> > A.K.A The Keyboard Cowboy
> >
> > mailto:mparsons1980 at gmail.com
> >
> > http://www.parsonsisconsulting.com
> >
> > http://www.o2-ounceopen.com/o2-power-users/
> >
> > http://www.linkedin.com/in/parsonsconsulting
> >
> > http://parsonsisconsulting.blogspot.com/
> >
> > http://www.vimeo.com/8939668
> >
> >
> >
> > 0_0_0_0_250_281_csupload_6117291
> >
> >
> >
> > untitled
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L) SC-L at 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 at 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.
> _______________________________________________



From ken at krvw.com  Wed Mar 17 11:11:23 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 17 Mar 2010 11:11:23 -0400
Subject: [SC-L] =?windows-1252?q?Expert_in_Application_Security_=97_ENISA?=
Message-ID: <5A04A8D1-0190-44C6-9A9E-3B3CCFA6AE59@krvw.com>

FYI, the European Network and Information Security Agency (ENISA) is looking for an application security expert.  See link below:

http://www.enisa.europa.eu/about-enisa/recruitment/vacancies/expert-in-application-security 


Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100317/fd0eb2c4/attachment.bin>

From jim.manico at owasp.org  Wed Mar 17 19:26:13 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Wed, 17 Mar 2010 13:26:13 -1000
Subject: [SC-L] OWASP Podcast Update
Message-ID: <4BA16515.7030805@owasp.org>

Hello SC-L,

The OWASP Podcast Series has released three shows this month so far.

They include:

Show 61: An interview with Richard Bejtlich (Director of Incident 
Response at General Electric) 
http://www.owasp.org/download/jmanico/owasp_podcast_61.mp3
Show 62: An interview with Amichai Shulman (CTO at Imperva): 
http://www.owasp.org/download/jmanico/owasp_podcast_62.mp3
Show 63: An interview with Ed Bellis (CISO at Orbitz Worldwide) 
http://www.owasp.org/download/jmanico/owasp_podcast_63.mp3

PS:

You can subscribe to our RSS feed here: 
http://www.owasp.org/download/jmanico/podcast.xml
..or do the same via iTunes 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
..or see our show list on the web 
http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows

Thanks for listening!

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100317/7754bbb0/attachment.htm>

From platsakos at gmail.com  Wed Mar 17 13:27:14 2010
From: platsakos at gmail.com (AK)
Date: Wed, 17 Mar 2010 19:27:14 +0200
Subject: [SC-L] market for training CISSPs how to code (Matt Parsons)
In-Reply-To: <mailman.1.1268841601.43037.sc-l@securecoding.org>
References: <mailman.1.1268841601.43037.sc-l@securecoding.org>
Message-ID: <4BA110F2.1030506@gmail.com>

Hi,

Regarding training non-developers to write secure code, what are  the
circumstances that a non-developer would create code that would
*require* security? I am assuming that system administrators know the
basics of their trade and scripting language of choice so security there
is taken care of BUT I fail to see other scenarios where code that would
be used more than a one-off is developed by "non-programmers".
Additional insight would be much appreciated :)




> Message: 1
> Date: Tue, 16 Mar 2010 21:37:03 -0500
> From: "Matt Parsons" <mparsons1980 at gmail.com>
> To: <OWASPDallas at utdallas.edu>
> [snipped]I have been a programmer and a security analyst for a few years now.   When
> I first started developers told me I didn't know how to code good enough and
> CISSP's told me I didn't have enough security experience.  Has anyone had
> any success training CISSP's and non programmers how to write code securely
> and train developers how to become CISSP's and learn how to penetration
> test?  If not does everyone think that there would be a market for such
> training?   
>
>  
>
>   


From ljknews at mac.com  Wed Mar 17 21:17:05 2010
From: ljknews at mac.com (ljknews)
Date: Wed, 17 Mar 2010 20:17:05 -0500
Subject: [SC-L] market for training CISSPs how to code (Matt Parsons)
In-Reply-To: <4BA110F2.1030506@gmail.com>
References: <mailman.1.1268841601.43037.sc-l@securecoding.org>
	<4BA110F2.1030506@gmail.com>
Message-ID: <p05200f26c7c72f5b96b7@[146.115.107.213]>

At 7:27 PM +0200 3/17/10, AK wrote:

> Regarding training non-developers to write secure code, what are  the
> circumstances that a non-developer would create code that would
> *require* security? I am assuming that system administrators know the
> basics of their trade and scripting language of choice so security there
> is taken care of

Scripting languages should not be used for security-sensitive
programs.
-- 
Larry Kilgallen

From Stephan.Neuhaus at disi.unitn.it  Thu Mar 18 06:34:20 2010
From: Stephan.Neuhaus at disi.unitn.it (Stephan Neuhaus)
Date: Thu, 18 Mar 2010 11:34:20 +0100
Subject: [SC-L] market for training CISSPs how to code (Matt Parsons)
In-Reply-To: <p05200f26c7c72f5b96b7@[146.115.107.213]>
References: <mailman.1.1268841601.43037.sc-l@securecoding.org>
	<4BA110F2.1030506@gmail.com>
	<p05200f26c7c72f5b96b7@[146.115.107.213]>
Message-ID: <4DCA759F-F92E-478C-95DD-BAE86755CCB1@disi.unitn.it>


On Mar 18, 2010, at 02:17, ljknews wrote:

> Scripting languages should not be used for security-sensitive
> programs.

And your evidence for this statement is?

Stephan

From cew at ACM.ORG  Thu Mar 18 11:41:57 2010
From: cew at ACM.ORG (Craig E. Ward)
Date: Thu, 18 Mar 2010 08:41:57 -0700
Subject: [SC-L] market for training CISSPs how to code (Matt Parsons)
In-Reply-To: <p05200f26c7c72f5b96b7@146.115.107.213>
References: <mailman.1.1268841601.43037.sc-l@securecoding.org>
	<4BA110F2.1030506@gmail.com> <p05200f26c7c72f5b96b7@146.115.107.213>
Message-ID: <8813f8cd1003180841p5813f333n98abd5bb1537467b@mail.gmail.com>

On Wed, Mar 17, 2010 at 6:17 PM, ljknews <ljknews at mac.com> wrote:
> At 7:27 PM +0200 3/17/10, AK wrote:
>
>> Regarding training non-developers to write secure code, what are ?the
>> circumstances that a non-developer would create code that would
>> *require* security? I am assuming that system administrators know the
>> basics of their trade and scripting language of choice so security there
>> is taken care of
>
> Scripting languages should not be used for security-sensitive
> programs.

That statement is so broad as to be nonsense. You might as well say,
"Programming languages should not be used for security-sensitive
programs." (I might go along with "Imperative programming languages
should not be used for security-sensitive programs.")

Every programming language has its own peculiar security issues and
these need to be considered when choosing an implementation language.

-- 
Internet: cew at ACM.ORG
"If a program has not been specified, it cannot be incorrect; it can
only be surprising." (Young, Boebert, and Kain)


From platsakos at gmail.com  Thu Mar 18 13:36:27 2010
From: platsakos at gmail.com (AK)
Date: Thu, 18 Mar 2010 19:36:27 +0200
Subject: [SC-L] market for training CISSPs how to code (Matt, Parsons)
In-Reply-To: <mailman.1.1268928001.82280.sc-l@securecoding.org>
References: <mailman.1.1268928001.82280.sc-l@securecoding.org>
Message-ID: <4BA2649B.9020902@gmail.com>

Hi all,

We are drifting a bit away from my question but here is a forked question:

Who says so, in the context of web applications? I can see it (somewhat) from a "desktop" application perspective, but how is this relevant in web apps?

Cheers!

Date: Wed, 17 Mar 2010 20:17:05 -0500
From: ljknews <ljknews at mac.com>
To: sc-l at securecoding.org
Subject: Re: [SC-L] market for training CISSPs how to code (Matt
	Parsons)
Message-ID: <p05200f26c7c72f5b96b7@[146.115.107.213]>
Content-Type: text/plain; charset=us-ascii

At 7:27 PM +0200 3/17/10, AK wrote:


> > Regarding training non-developers to write secure code, what are  the
> > circumstances that a non-developer would create code that would
> > *require* security? I am assuming that system administrators know the
> > basics of their trade and scripting language of choice so security there
> > is taken care of
>   

Scripting languages should not be used for security-sensitive
programs.


From dwheeler at ida.org  Thu Mar 18 13:01:23 2010
From: dwheeler at ida.org (Wheeler, David A)
Date: Thu, 18 Mar 2010 13:01:23 -0400
Subject: [SC-L] market for training CISSPs how to code
In-Reply-To: <mailman.1.1268928001.82280.sc-l@securecoding.org>
References: <mailman.1.1268928001.82280.sc-l@securecoding.org>
Message-ID: <9F8E44BC27E22046B84EC1B9364C66A186E3E83A35@EXCH07-4850.ida.org>

> At 7:27 PM +0200 3/17/10, AK wrote:
> > Regarding training non-developers to write secure code, what are  the
> > circumstances that a non-developer would create code that would
> > *require* security?

As soon as a "non-developer" creates code, they are no longer a "non-developer".  By definition, they are now a developer!

Of course, they may completely lack any kind of knowledge about security.  Just like most developers, I should add.  I expect this problem to *increase* over time.


> > I am assuming that system administrators know the
> > basics of their trade and scripting language of choice so security
> > there is taken care of

That may be true in some places.  But all too often real knowledge and expertise is rare.  Many "System Admins", esp. in the Windows world, do not understand the underlying technology at all.  They only know how to how to point-and-click based on recipes created by others (e.g., local instructions or whatever Google tells them).  All too often we *train* while ignoring *education*.

When they have to program at all, these kinds of people perform "cargo cult programming" (see http://en.wikipedia.org/wiki/Cargo_cult_programming ).


Larry Kilgallen:
> Scripting languages should not be used for security-sensitive programs.

Perhaps, but they are and will be used that way anyway.  We need plan B.

Perhaps we have a different definition of "security-sensitive program".  If you're trying to protect confidentiality, integrity, or availability of information or a service, then I think you have security properties you're trying to maintain.  For example, most websites are developed with scripting languages, and many of them are important for their organization's business, making them security-sensitive in at least that sense.  Sure, there are degrees of sensitivity, but many websites are key to a business *AND* are primarily developed with scripting languages.  Saying "don't use scripting languages" won't make this go away, so let's figure out how to get them secure.

If the alternative is "use C for everything", I shudder.  The people who have trouble with scripting languages will *not* do better with C :-).

I think part of the solution is devise languages and libraries which are not only easy to use, but in which the *easy* way to do things is also the *secure* way.  That's easier said than done, but when you have non-genius developers, it's a start.


--- David A. Wheeler




From ljknews at mac.com  Thu Mar 18 14:38:02 2010
From: ljknews at mac.com (ljknews)
Date: Thu, 18 Mar 2010 14:38:02 -0400
Subject: [SC-L] market for training CISSPs how to code
In-Reply-To: <9F8E44BC27E22046B84EC1B9364C66A186E3E83A35@EXCH07-4850.ida.org>
References: <mailman.1.1268928001.82280.sc-l@securecoding.org>
	<9F8E44BC27E22046B84EC1B9364C66A186E3E83A35@EXCH07-4850.ida.org>
Message-ID: <p05200f3ec7c822fad3bb@[146.115.107.213]>

At 1:01 PM -0400 3/18/10, Wheeler, David A wrote:

> Larry Kilgallen:
>> Scripting languages should not be used for security-sensitive programs.
> 
> Perhaps, but they are and will be used that way anyway.  We need plan B.

Ok, just so people understand it _is_ Plan B.

> If the alternative is "use C for everything", I shudder.

Certainly not my alternative.  It competes strongly with
scripting languages at promoting vulnerabilities.
-- 
Larry Kilgallen

From ljknews at mac.com  Thu Mar 18 15:11:29 2010
From: ljknews at mac.com (ljknews)
Date: Thu, 18 Mar 2010 15:11:29 -0400
Subject: [SC-L] market for training CISSPs how to code (Matt, Parsons)
In-Reply-To: <4BA2649B.9020902@gmail.com>
References: <mailman.1.1268928001.82280.sc-l@securecoding.org>
	<4BA2649B.9020902@gmail.com>
Message-ID: <p05200f40c7c82b12ba95@[146.115.107.213]>

At 7:36 PM +0200 3/18/10, AK wrote:

> Who says so, in the context of web applications?
> I can see it (somewhat) from a "desktop" application
> perspective, but how is this relevant in web apps?

Why should standards for a "web" application be different than
for a "desktop" application ?
-- 
Larry Kilgallen

From coley at linus.mitre.org  Thu Mar 18 17:40:11 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 18 Mar 2010 17:40:11 -0400 (EDT)
Subject: [SC-L] [WEB SECURITY] RE: blog post and open source
 vulnerabilities to blog about
In-Reply-To: <048d01cac542$27c9cb10$775d6130$@com>
References: <039b01cac51f$1ed36930$5c7a3b90$@com>
	<BFD50E79FBE23A4FB6BE93572A6FE287033C71F1@AD1HFDEXC312.ad1.prod>
	<B9A412898630124ABE8350F4EBD32E84012675A3@mymail.aspectsecurity.com>
	<048d01cac542$27c9cb10$775d6130$@com>
Message-ID: <Pine.GSO.4.64.1003181735150.21853@faron.mitre.org>


CWE, CLASP, and some other information sources have a number of code 
snippets that highlight various weaknesses.  In CWE, this code is easily 
extractable from the XML by grabbing the Demonstrative_Examples element, 
and we've even conveniently labeled examples with the various languages. 
You could also grab the CVE real-world examples from the Observed_Examples 
element.

Note that the code examples are by no means complete, but they might be 
good enough to start with.  If you pore through CVE, you will soon realize 
that it can be very time-consuming to go from a real-world open-source 
vuln report to the actual code snippet.

- Steve

From gunnar at arctecgroup.net  Fri Mar 19 12:25:05 2010
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Fri, 19 Mar 2010 11:25:05 -0500
Subject: [SC-L] Bring your Cloud to Work Day
Message-ID: <B939BF1D-7D85-43C1-9AC8-87F10618D2EB@arctecgroup.net>

Flip side of "Lifestyle Hacking" aptly described by Messrs McGraw and  
Routh is when your organization cannot deliver the functionality/data/ 
usability that the consumers need.

http://1raindrop.typepad.com/1_raindrop/2010/03/bring-your-cloud-to-work-in-iraq.html

-gunnar

From tomhave at secureconsulting.net  Fri Mar 19 16:39:42 2010
From: tomhave at secureconsulting.net (Benjamin Tomhave)
Date: Fri, 19 Mar 2010 16:39:42 -0400
Subject: [SC-L] free scans from Google...
Message-ID: <4BA3E10E.9030109@secureconsulting.net>

I guess we can all retire now, eh? I find it so exciting that the app is
"written in pure C"... and coming from Google, I'm sure it won't leak
info back to the mothership at all...

"Meet skipfish, our automated web security scanner"
http://googleonlinesecurity.blogspot.com/2010/03/meet-skipfish-our-automated-web.html

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Do you think that when they asked George Washington for ID that he just
whipped out a quarter?"
Steven Wright


From koved at us.ibm.com  Fri Mar 19 14:46:15 2010
From: koved at us.ibm.com (Larry Koved)
Date: Fri, 19 Mar 2010 14:46:15 -0400
Subject: [SC-L] CFP: W2SP 2010: Web 2.0 Security and Privacy 2010 CFP -
	final call
In-Reply-To: <OF944006F7.CD77F85F-ON852576DD.0063E788-852576DD.0063FD57@LocalDomain>
References: <OF367F5FDC.B6DC1CD9-ON852576A7.004BE2F3-852576A7.004BF1CD@LocalDomain>
	<OF944006F7.CD77F85F-ON852576DD.0063E788-852576DD.0063FD57@LocalDomain>
Message-ID: <OF63344606.51A79AB7-ON852576EB.0067118E-852576EB.00671E08@us.ibm.com>

A quick reminder...

The workshop chairs would like to invite you participate in the 4th annual 

workshop on Web 2.0 Security and Privacy.  Started in 2007, this 
successful 
series of workshops has attracted participation from both academia and 
industry, and participants from around the world.  This workshop is held
in conjunction with the 2010 IEEE Symposium on Security and Privacy. 




Workshop Call for Papers
W2SP 2010: Web 2.0 Security and Privacy 2010

Thursday, May 20
The Claremont Resort, Oakland, California
Web site: http://w2spconf.com/2010

The goal of this one day workshop is to bring together researchers and
practitioners from academia and industry to focus on understanding Web
2.0 security and privacy issues, and establishing new collaborations
in these areas.

Web 2.0 is about connecting people and amplifying the power of working
together. An ongoing explosion of new technology is powering
increasingly complex social and business interactions as well as
enabling an unprecedented level of unmediated information exchange and
horizontal organization. These interactions rely on composition of
content and services from multiple sources, commonly called mash-ups,
leading to systems with complex trust boundaries. This trend is likely
to continue because individuals, businesses, and other organizations
desire the simplicity, efficiency, and utility these technologies
offer.

Though these technologies have had many positive effects, they raise
issues about management of identities, personal safety, reputation,
privacy, anonymity, transient and long-term relationships, and
composition of function and content, both on the server and on the
client side (web browsers and mobile platforms). Although many of the
underlying security and privacy issues are not new, the use of these
technologies by very large and disparate populations raises new
questions. This workshop is intended to discuss the limitations of
current technologies and explore alternatives.

The scope of W2SP 2010 includes, but is not limited to:

Trustworthy cloud-based services
Usable security and privacy
Security and privacy as a service
Security for the mobile web
Identity management and psuedonymity
Web services/feeds/mashups
Security and privacy policies for composible content
Next-generation browser technology
Secure extensions and plug-ins
Advertisement and affiliate fraud

Potential workshop participants should submit a paper on topics
relevant to Web 2.0 security and privacy issues. We are seeking both
short position papers (2 - 4 pages) and refereed papers (a maximum of
8 pages, including references and appendices). Papers longer than 8
pages may be automatically rejected by the chair or workshop
committee. From the submissions, the program committee will strive to
balance participation between academia and industry and across topics.
Selected papers will appear on the workshop web site; W2SP has no
formal published proceedings.

For papers that focus primarily on the security and privacy of social
networks, we encourage authors to submit their paper to the Social
Network Security and Privacy (SNSP) workshop, which is concurrent and
co-located with W2SP. Submitted papers may be referred to the SNSP
program committee for consideration.

Workshop Co-Chairs
Larry Koved (IBM Research)
Dan S. Wallach (Rice University)

Program Chair
Collin Jackson (Carnegie Mellon University)

Program Committee
Ben Adida (Harvard University)
Dirk Balfanz (Google)
Adam Barth (UC Berkeley)
Konstantin (Kosta) Beznosov (University of British Columbia)
Suresh Chari (IBM Research)
Hao Chen (UC Davis)
Collin Jackson (Carnegie Mellon University)
Martin Johns (SAP Research)
Rob Johnson (Stony Brook University)
Engin Kirda (Institute Eurecom)
Larry Koved (IBM Research)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Dawn Song (UC Berkeley)
Dan S. Wallach (Rice University)
Helen Wang (Microsoft Research)

Important Dates

Paper submission deadline: Tuesday, March 23, 2010 (11:59pm US-Eastern)
Workshop acceptance notification date: April 11, 2010
Workshop date: Thursday, May 20, 2010

Registration: Workshop registration will be available via the 2010
IEEE Symposium on Security and Privacy conference web site.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100319/69f48005/attachment.htm>

From platsakos at gmail.com  Fri Mar 19 13:56:25 2010
From: platsakos at gmail.com (AK)
Date: Fri, 19 Mar 2010 19:56:25 +0200
Subject: [SC-L] SC-L Digest, Vol 6, Issue 56
In-Reply-To: <mailman.1.1269014401.24951.sc-l@securecoding.org>
References: <mailman.1.1269014401.24951.sc-l@securecoding.org>
Message-ID: <4BA3BAC9.8020301@gmail.com>


It is way easier for attackers to reverse engineer desktop applications
than web applications. Assuming proper server configuration, it is next
to impossible for an attacker to get the server side source code or
compressed form (e.g WARs) for a web application and proceed with
disassembly/decompilation/patching. I do not have any experience with
obfuscating or otherwise armoring executables created from scripting
languages (such as win32's py2exe) but I would venture a guess that it
would be tedious and less effective than armoring a C/C++ based executable.

To turn the argument the other way round, if we accept what you say as
correct within the realm of web applications, the Ruby-On-Rails and
Django guys (to name but two) are in a serious folly and are not able to
provide secure frameworks owing to their choice of scripting languages.
I, for one, do not that this is the case :-)

sc-l-request at securecoding.org wrote:

Message: 6 Date: Thu, 18 Mar 2010 15:11:29 -0400 From: ljknews
<ljknews at mac.com> To: sc-l at securecoding.org Subject: Re: [SC-L] market
for training CISSPs how to code (Matt, Parsons) Message-ID:
<p05200f40c7c82b12ba95@[146.115.107.213]> Content-Type: text/plain;
charset=us-ascii At 7:36 PM +0200 3/18/10, AK wrote:

> > Who says so, in the context of web applications?
> > I can see it (somewhat) from a "desktop" application
> > perspective, but how is this relevant in web apps?
>   

Why should standards for a "web" application be different than
for a "desktop" application ?
-- Larry Kilgallen


From platsakos at gmail.com  Fri Mar 19 14:28:02 2010
From: platsakos at gmail.com (AK)
Date: Fri, 19 Mar 2010 20:28:02 +0200
Subject: [SC-L] SC-L Digest, Vol 6, Issue 56
In-Reply-To: <mailman.1.1269014401.24951.sc-l@securecoding.org>
References: <mailman.1.1269014401.24951.sc-l@securecoding.org>
Message-ID: <4BA3C232.6040709@gmail.com>

>
> As soon as a "non-developer" creates code, they are no longer a "non-developer".  By definition, they are now a developer!
>
> Of course, they may completely lack any kind of knowledge about security.  Just like most developers, I should add.  I expect this problem to *increase* over time.
>
>
>   

For the case that one is creating a product/service I will have to
rephrase a bit.

Substitute "non-developer" with "person who lacks all but the most basic
notions of software engineering". So, technically, yeah they are
developers but probably they are not good developers and will run to a
multitude of problems, one of which will be security.


However, by non-developers, I was meaning people who write code as a
"one-off", (e.g. a security consultant writes some quick and dirty code
to fuzz something, or someone writing a script for home use). Even if
the security knowledge is there, since security is not a required
property, it just will not in the resultant code, as the code is
supposed to be used a few times and then thrown away (or hopefully
rewritten :-) )
> That may be true in some places.  But all too often real knowledge and expertise is rare.  Many "System Admins", esp. in the Windows world, do not understand the underlying technology at all.  They only know how to how to point-and-click based on recipes created by others (e.g., local instructions or whatever Google tells them).  All too often we *train* while ignoring *education*.
>
> When they have to program at all, these kinds of people perform "cargo cult programming" (see http://en.wikipedia.org/wiki/Cargo_cult_programming ).
>   

If an organization hires (or outsources to) point-n-click admins (which,
I'll hazard a guess, on average will cost cheaper than the admins who
have invested time sharpening their saw), the organization will most
likely have operational problems, which are not limited to security,
even before the admins type "shebang", IMHO.

From ljknews at mac.com  Sat Mar 20 07:18:58 2010
From: ljknews at mac.com (ljknews)
Date: Sat, 20 Mar 2010 07:18:58 -0400
Subject: [SC-L] SC-L Digest, Vol 6, Issue 56
In-Reply-To: <4BA3BAC9.8020301@gmail.com>
References: <mailman.1.1269014401.24951.sc-l@securecoding.org>
	<4BA3BAC9.8020301@gmail.com>
Message-ID: <p05200f55c7ca5e1802cb@[146.115.107.213]>

At 7:56 PM +0200 3/19/10, AK wrote:

> It is way easier for attackers to reverse engineer desktop applications
> than web applications. Assuming proper server configuration, it is next
> to impossible for an attacker to get the server side source code or
> compressed form (e.g WARs) for a web application and proceed with
> disassembly/decompilation/patching.

Assuming proper _desktop_ configuration, the user does not have
the ability to modify the programs they will execute, nor change
the protections of objects on the system.

	http://nvd.nist.gov/fdcc/fdcc_faq.cfm

Yes, physical access to a computer means ultimately it is possible
to gain control, but the necessary measures to not constitute
"easier", and given control of one test machine it is not at all
trivial to transfer that to control of another machine, especially
if the machines are not connected to a common network.
-- 
Larry Kilgallen

From kevin.w.wall at gmail.com  Sat Mar 20 11:07:31 2010
From: kevin.w.wall at gmail.com (Kevin W. Wall)
Date: Sat, 20 Mar 2010 11:07:31 -0400
Subject: [SC-L] free scans from Google...
In-Reply-To: <4BA3E10E.9030109@secureconsulting.net>
References: <4BA3E10E.9030109@secureconsulting.net>
Message-ID: <4BA4E4B3.90704@gmail.com>

Benjamin Tomhave wrote:
> I guess we can all retire now, eh? I find it so exciting that the app is
> "written in pure C"... and coming from Google, I'm sure it won't leak
> info back to the mothership at all...
> 
> "Meet skipfish, our automated web security scanner"
> http://googleonlinesecurity.blogspot.com/2010/03/meet-skipfish-our-automated-web.html
> 

Yeah, this comment in the project Wiki makes me feel better already:

	All right, I want to try it out. What do I need to know?

	First and foremost, please do not be evil. Use skipfish only against
	services you own, or have a permission to test.

On a good note though, Michal Zalewski is a well-respected developer, so I
might be willing to give it a chance... against someone else's app. (jk)

-kevin
-- 
Kevin W. Wall
"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

From kowsik at gmail.com  Mon Mar 22 14:15:34 2010
From: kowsik at gmail.com (kowsik)
Date: Mon, 22 Mar 2010 11:15:34 -0700
Subject: [SC-L] free scans from Google...
In-Reply-To: <4BA3E10E.9030109@secureconsulting.net>
References: <4BA3E10E.9030109@secureconsulting.net>
Message-ID: <7db9abd31003221115j38f1f20btf7bf1fcfa8ebee@mail.gmail.com>

Unlike other services from Google, you have the source so you can see
if it calls home. BTW, Michal has done some great work in the past
(TCP strange attractors being one of my favorite ones). The
phase-space approach for sequence numbers is now used quite a bit in a
number of web-app scanners for entropy analysis of cookies and
session-ids, amongst other things.

K.
---
http://www.pcapr.net
http://labs.mudynamics.com
http://twitter.com/pcapr

On Fri, Mar 19, 2010 at 1:39 PM, Benjamin Tomhave
<tomhave at secureconsulting.net> wrote:
> I guess we can all retire now, eh? I find it so exciting that the app is
> "written in pure C"... and coming from Google, I'm sure it won't leak
> info back to the mothership at all...
>
> "Meet skipfish, our automated web security scanner"
> http://googleonlinesecurity.blogspot.com/2010/03/meet-skipfish-our-automated-web.html
>
> --
> Benjamin Tomhave, MS, CISSP
> tomhave at secureconsulting.net
> Blog: http://www.secureconsulting.net/
> Twitter: http://twitter.com/falconsview
> LI: http://www.linkedin.com/in/btomhave
>
> [ Random Quote: ]
> "Do you think that when they asked George Washington for ID that he just
> whipped out a quarter?"
> Steven Wright
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>

From gem at cigital.com  Mon Mar 22 15:30:11 2010
From: gem at cigital.com (Gary McGraw)
Date: Mon, 22 Mar 2010 15:30:11 -0400
Subject: [SC-L] Smart Grid and Software Security
Message-ID: <C7CD3D83.1FA2A%gem@cigital.com>

hi sc-l,

In the past we've wondered on this list about how to spread software security memes outside of our own little domain and into the larger world.  I recently gave a keynote talk in Atlanta to a bunch of senior executives (CEOs and Board members) who run Rural electric cooperatives.  This is a completely different audience...at least 10 of the hundreds of people in attendance were wearing cowboy hats!

We just put the talk up on Justice League for those of you interested:
http://www.cigital.com/justiceleague/2010/03/22/smart-grid-equals-dumb-security/

This talk shows the level I get to when I am trying to communicate with non geeks.  I even lapse into my old Tennessee accent.  Hope it works!

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
podcast www.cigital.com/realitycheck
blog www.cigital.com/justiceleague
book www.swsec.com


From gem at cigital.com  Tue Mar 23 11:16:30 2010
From: gem at cigital.com (Gary McGraw)
Date: Tue, 23 Mar 2010 11:16:30 -0400
Subject: [SC-L] Silver Bullet Transcripts
Message-ID: <C7CE538E.1FAEE%gem@cigital.com>

hi sc-l,

As you know, Silver Bullet is co-sponsored by Cigital and IEEE Security & Privacy magazine.  Excerpts of about half of the episodes are eventually published in the magazine as articles in an interview department.  We just caught up with ourselves by posting the last three S&P interviews on the Silver Bullet website.  Sorry about the delay!

Without further ado, the transcripts/articles are:
Chris Hoff (with a  focus on cloud security)
http://www.cigital.com/silverbullet/shows/silverbullet-043-choff.pdf

Gillian Hayes (with a focus on social networking, privacy and security)
http://www.cigital.com/silverbullet/shows/silverbullet-042-ghayes.pdf

Fred Schneider (with a focus on security research and anticipating future attacks)
http://www.cigital.com/silverbullet/shows/silverbullet-041-fschneider.pdf

As always, we welcome your feedback on the podcast through the Silver Bullet website.  We're also very much interested in knowing who you want to hear from.

Thanks for listening.

gem

company www.cigital.com
podcast www.cigital.com/realitycheck
blog www.cigital.com/justiceleague
book www.swsec.com


From gem at cigital.com  Thu Mar 25 14:23:44 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 25 Mar 2010 14:23:44 -0400
Subject: [SC-L] Silver Bullet 48: Andrew Jaquith
Message-ID: <C7D12270.1FD2E%gem@cigital.com>

hi sc-l,

I find it hard to believe that Silver Bullet has been going for 4 years!  Lots of really interesting people in the mix.

Our 48th victim, er I mean guest is Andy Jaquith who all of you know is a security metrics uber-geek.  Andy's past includes a stint at @stake working in the early days of software security.  He is an analyst now in addition to being an author.  He still thinks about software security on a daily basis.

Have a listen:
http://www.cigital.com/silverbullet/show-048/

As always, your feedback on the podcast and potential people to interview is very much welcome.

gem

company www.cigital.com
podcast www.cigital.com/realitycheck
blog www.cigital.com/justiceleague
book www.swsec.com


From gem at cigital.com  Fri Mar 26 08:06:03 2010
From: gem at cigital.com (Gary McGraw)
Date: Fri, 26 Mar 2010 08:06:03 -0400
Subject: [SC-L] informIT: smart grid and software security
Message-ID: <C7D21B6B.1FDB4%gem@cigital.com>

hi sc-l,

After reviewing the video of my talk at the NRECA conference <http://www.cigital.com/justiceleague/2010/03/22/smart-grid-equals-dumb-security/>, I decided to write my thoughts down more concisely.  This month's informIT column is about the intersection of software security and the smart grid.

The Smart (Electric) Grid and Dumb Cybersecurity
http://www.informit.com/articles/article.aspx?p=1577441

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


From gem at cigital.com  Fri Mar 26 09:43:42 2010
From: gem at cigital.com (Gary McGraw)
Date: Fri, 26 Mar 2010 09:43:42 -0400
Subject: [SC-L] academics do software security too
Message-ID: <C7D2324E.1FDE2%gem@cigital.com>

hi sc-l,

Here is a CFP from a conference I help out with.

gem

CALL FOR PAPERS

================

International Symposium on Engineering Secure Software and Systems (ESSoS)



February 09-10, 2011

Madrid, Spain

http://distrinet.cs.kuleuven.be/events/essos2011/





CONTEXT AND MOTIVATION

Trustworthy, secure software is a core ingredient of the modern world. Unfortunately, the Internet is too. Hostile, networked environments, like the Internet, can allow vulnerabilities in software to be exploited from anywhere. To address this, high-quality security building blocks (e.g., cryptographic components) are necessary, but insufficient. Indeed, the construction of secure software is challenging because of the complexity of modern applications, the growing sophistication of security requirements, the multitude of available software technologies and the progress of attack vectors. Clearly, a strong need exists for engineering techniques that scale well and that demonstrably improve the software's security properties.





GOAL AND SETUP

The goal of this symposium, which will be the third in the series, is to bring together researchers and practitioners to advance the states of the art and practice in secure software engineering. Being one of the few conference-level events dedicated to this topic, it explicitly aims to bridge the software engineering and security engineering communities, and promote cross-fertilization. The symposium will feature two days of technical program, and is also open to proposals for both tutorials and workshops.

In addition to academic papers, the symposium encourages submission of high-quality, informative experience papers about successes and failures in security software engineering and the lessons learned.

Furthermore, the symposium also accepts short idea papers that crisply describe a promising direction, approach, or insight.





TOPICS

The Symposium seeks submissions on subjects related to its goals. This includes a diversity of topics including (but not limited to):

- scalable techniques for threat modeling and analysis of vulnerabilities

- specification and management of security requirements and policies

- security architecture and design for software and systems

- model checking for security

- specification formalisms for security artifacts

- verification techniques for security properties

- systematic support for security best practices

- security testing

- security assurance cases

- programming paradigms, models and DLS's for security

- program rewriting techniques

- processes for the development of secure software and systems

- security-oriented software reconfiguration and evolution

- security measurement

- automated development

- trade-off between security and other non-functional requirements

- support for assurance, certification and accreditation





SUBMISSION AND FORMAT

The proceedings of the symposium are published by Springer-Verlag in the Lecture Notes in Computer Science Series (http://www.springer.com/lncs). Submissions should follow the formatting instructions of Springer LNCS. Submitted papers must present original, non-published work of high quality. Two types of papers will be accepted:



Full papers (max 12 pages without bibliography/appendices) - May describe original technical research with a solid foundation, such as formal analysis or experimental results, with acceptance determined mostly based on novelty and validation. Or, may describe case studies applying existing techniques or analysis methods in industrial settings, with acceptance determined mostly by the general applicability of techniques and the completeness of the technical presentation details.



Idea papers (max 8 pages with bibliography) - May crisply describe a novel idea that is both feasible and interesting, where the idea may range from a variant of an existing technique all the way to a vision for the future of security technology. Idea papers allow authors to introduce ideas to the field and get feedback, while allowing for later publication of complete, fully-developed results. Submissions will be judged primarily on novelty, excitement, and exposition, but feasibility is required, and acceptance will be unlikely without some basic, principled validation (e.g., extrapolation from limited experiments or simple formal analysis).



Proposals for both tutorials and workshops are welcome. Further guidelines are on the website of the symposium.





IMPORTANT DATES

Abstract submission: September 13, 2010

Paper submission: September 20, 2010

Author notification: November 12, 2010

Camera-ready: December 3, 2010





STEERING COMMITTEE

Jorge Cuellar (Siemens AG)

Wouter Joosen (Katholieke Universiteit Leuven) - chair

Fabio Massacci (Universit? di Trento)

Gary McGraw (Cigital)

Bashar Nuseibeh (The Open University)

Daniel Wallach (Rice University University)





ORGANIZING COMMITTEE

General chair: Manuel Clavel (Imdea Software/ Universidad Complutense de Madrid, Spain)

Program co-chairs: Ulfar Erlingsson (Microsoft Research Silicon Valley, USA) and Roel Wieringa (University of Twente, NL)

Publication chair: N. Zannone (Eindhoven Technical University, NL)

Publicity chair: Pieter Philippaerts (Katholieke Universiteit Leuven, BE)

Local arrangements chair: Marina Egea (Imdea Software, Spain)





PROGRAM COMMITTEE (To be completed)

Thomas Alspaugh (University of California, Irvine, US)

Jo Atlee (University of Waterloo, Canada)

Bruno Blanchet (Ecole Normale Superieure, France)

Hao Chen (University of California, Davis, US)

Frederic Cuppens (Ecole Nationale Sup?rieure de T?l?communication Bretagne, France)

Prem Devanbu (University  of California at Davis, US)

Eric Dubois (Centre de Recherche Public Henri Tudor, Luxembourg)

Christof Ebert (Vector Consulting, Germany)

Manuel Fahndrich (Microsoft Research, US)

Eduardo Fernandez-Medina (Universidad de Castilla-La Mancha, Spain)

Robert France (Colorado State University, US)

Vinod Ganapathy (Rutgers University, US)

Dieter Gollman (Hamburg University of Technology, DE)

Siv Hilde Houmb (Telenor, Norway)

Jan Jurjens (Technische Universitet Dortmund, Germany)

Yuecel Karabulut (SAP Labs, US)

Seok-Won Lee (University of North Carolina Charlotte, US)

Lin Liu (Tsinghua University, China)

Vaclav (Vashek) Matyas (Masaryk University, Czech Republic)

Robert Martin (MITRE, US)

Sjouke Mauw (University of Luxembourg)

Chris Mitchell (Royal Holloway, UK)

Akito Monden (Nara Institute of Science and Technology, japan)

Haralambos Mouratidis (University of East London, UK)

Marcus Peinado (Microsoft Research, US)

David Sands (Chalmers University, Sweden)

Angela Sasse (University College London, UK)

Venkat Venkatakrishnan (University of Illinois at Chicago, US)



From ken at krvw.com  Mon Mar 29 11:39:01 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 29 Mar 2010 11:39:01 -0400
Subject: [SC-L] The International Secure Systems Development Conference
Message-ID: <42FDF416-99E1-45E0-86C7-1F5F48997A8F@krvw.com>

I saw this event announcement today and thought some SC-L folks might find it of interest, FYI.

"The International Secure Systems Development Conference addresses the key issues around designing-in security for standard and web-based software and systems, both in terms of developing new applications securely and also in adding security to legacy applications. The aim of the event is to help change the balance away from a repeated and ever more costly focus on securing ever more insecure infrastructures, to one which focuses on the creation of inherently secure systems through the introduction of verifiable, secure development methodologies and coherent security architectures."

http://www.issdconference.com/ 


Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100329/281e4ee0/attachment.bin>

From jim.manico at owasp.org  Mon Mar 29 23:28:28 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Mon, 29 Mar 2010 17:28:28 -1000
Subject: [SC-L] OWASP ESAPI 2.0 rc6 released!
Message-ID: <4BB16FDC.2090307@owasp.org>

ESAPI 2.0 rc6 is now live!

You can download the complete zip file here:

http://owasp-esapi-java.googlecode.com/files/ESAPI-2.0-rc6.zip 
<http://owasp-esapi-java.googlecode.com/files/ESAPI-1.4.3.zip>

Online project documentation can be found here:

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc6/site/project-reports.html 
<http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc6/site/project-reports.html>

Major enhancements include:

1) Major rewrite of the Encryptor implementation
2) Initial "examples" section included: \ESAPI-2.0-rc6\project\src\examples

Please see changelog.txt at the root of the zip file for more information.

Mahalo Nui Loa,
-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100329/e759ded4/attachment.htm>

From mparsons1980 at gmail.com  Wed Mar 31 23:09:22 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Wed, 31 Mar 2010 22:09:22 -0500
Subject: [SC-L] working on java security help from experts
Message-ID: <032901cad148$beca2610$3c5e7230$@com>

I am trying to become an expert in source code review in java application
security.  Are there any experts on this list that are willing to share some
of their knowledge?   I am reading Java Security by Scott Oaks and I am
rereading all of the Sun Docs on java security.  Any help would be greatly
appreciated.   

 

Thanks,
Matt

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100331/7c19bb81/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100331/7c19bb81/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100331/7c19bb81/attachment-0001.jpeg>

From erno.jeges at search-lab.hu  Thu Apr  1 11:17:56 2010
From: erno.jeges at search-lab.hu (Erno JEGES)
Date: Thu, 1 Apr 2010 17:17:56 +0200 (CEST)
Subject: [SC-L] working on java security help from experts
In-Reply-To: <032901cad148$beca2610$3c5e7230$@com>
References: <032901cad148$beca2610$3c5e7230$@com>
Message-ID: <Pine.LNX.4.64.1004011708490.7034@morgo>


Dear Matt,

If you want to get familiar with common Java specific security errors 
enlisted by different vulnerability categories, the Fortify taxonomy might 
give you a comprehensive overview:

http://www.fortify.com/vulncat/en/vulncat/index.html

Open Java/JSP in the tree on the left, and enjoy! :)

Best regards,
Erno

   Erno JEGES
   SEARCH-LAB Ltd
   www.search-lab.hu
   PHONE/FAX: +36 1 2053098
   MOB: +36 20 4200075
   SKYPE: jegeserno




On Wed, 31 Mar 2010, Matt Parsons wrote:

> I am trying to become an expert in source code review in java application
> security.  Are there any experts on this list that are willing to share some
> of their knowledge?   I am reading Java Security by Scott Oaks and I am
> rereading all of the Sun Docs on java security.  Any help would be greatly
> appreciated.
>
>
>
> Thanks,
> Matt
>
>
>
> Matt Parsons, MSM, CISSP
>
> 315-559-3588 Blackberry
>
> 817-294-3789 Home office
>
> "Do Good and Fear No Man"
>
> Fort Worth, Texas
>
> A.K.A The Keyboard Cowboy
>
> mailto:mparsons1980 at gmail.com
>
> http://www.parsonsisconsulting.com
>
> http://www.o2-ounceopen.com/o2-power-users/
>
> http://www.linkedin.com/in/parsonsconsulting
>
> http://parsonsisconsulting.blogspot.com/
>
> http://www.vimeo.com/8939668
>
>
>
> 0_0_0_0_250_281_csupload_6117291
>
>
>
> untitled
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

From warems at gmail.com  Thu Apr  1 11:34:34 2010
From: warems at gmail.com (Mike Ware)
Date: Thu, 1 Apr 2010 11:34:34 -0400
Subject: [SC-L] working on java security help from experts
In-Reply-To: <032901cad148$beca2610$3c5e7230$@com>
References: <032901cad148$beca2610$3c5e7230$@com>
Message-ID: <k2q77fd23141004010834s8b8b4dc7o699a2a4bef4ac33a@mail.gmail.com>

I wrote a thesis on Java SE security. In addition to covering secure coding
practices, I also created a number of test cases and subjected them to a
suite of static analysis tools.

A ton has been said over the years. I tried to organize it all into a
taxonomy rooted in design principles. You might find my bibliography useful:

http://mikeware.us/thesis/

Mike

On Wed, Mar 31, 2010 at 11:09 PM, Matt Parsons <mparsons1980 at gmail.com>wrote:

>  I am trying to become an expert in source code review in java application
> security.  Are there any experts on this list that are willing to share some
> of their knowledge?   I am reading Java Security by Scott Oaks and I am
> rereading all of the Sun Docs on java security.  Any help would be greatly
> appreciated.
>
>
>
> Thanks,
> Matt
>
>
>
> Matt Parsons, MSM, CISSP
>
> 315-559-3588 Blackberry
>
> 817-294-3789 Home office
>
> "Do Good and Fear No Man"
>
> Fort Worth, Texas
>
> A.K.A The Keyboard Cowboy
>
> mailto:mparsons1980 at gmail.com <mparsons1980 at gmail.com>
>
> http://www.parsonsisconsulting.com
>
> http://www.o2-ounceopen.com/o2-power-users/
>
> http://www.linkedin.com/in/parsonsconsulting
>
> http://parsonsisconsulting.blogspot.com/
>
> http://www.vimeo.com/8939668
>
>
>
> [image: 0_0_0_0_250_281_csupload_6117291]
>
>
>
> [image: untitled]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100401/8d7f48c6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100401/8d7f48c6/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100401/8d7f48c6/attachment-0003.jpeg>

From kowsik at gmail.com  Thu Apr  1 14:39:47 2010
From: kowsik at gmail.com (kowsik)
Date: Thu, 1 Apr 2010 11:39:47 -0700
Subject: [SC-L] Why NoSQL is bad for startups
Message-ID: <t2u7db9abd31004011139ya0e70dc0ief44b4c823cbbfc5@mail.gmail.com>

Blog on labs.mudynamics.com: http://bit.ly/aHFiFc

K.
---
http://labs.mudynamics.com
http://www.pcapr.net
http://twitter.com/pcapr

From ramartin at mitre.org  Thu Apr  1 14:49:01 2010
From: ramartin at mitre.org (Martin, Robert A.)
Date: Thu, 1 Apr 2010 14:49:01 -0400
Subject: [SC-L] working on java security help from experts
In-Reply-To: <032901cad148$beca2610$3c5e7230$@com>
References: <032901cad148$beca2610$3c5e7230$@com>
Message-ID: <4BB4EA9D.7060803@mitre.org>

The Common Weakness Enumeration (CWE) has a "view" of issues that can 
occur in Java applications.

See: http://cwe.mitre.org/data/slices/660.html for a listing of all the 
details or: http://cwe.mitre.org/data/lists/660.html for a list of the 
items where the names are hyper-links to the content about them.

The entries include description, code examples, real world CVE examples 
of the issue in many cases, references and in most cases pointers to the 
attack patterns effective against the issue.

Bob

Matt Parsons wrote:
> I am trying to become an expert in source code review in java application security.  Are there any experts on this list that are willing to share some of their knowledge?   I am reading Java Security by Scott Oaks and I am rereading all of the Sun Docs on java security.  Any help would be greatly appreciated.
> 
> Thanks,
> Matt
> 
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> "Do Good and Fear No Man"
> Fort Worth, Texas
> A.K.A The Keyboard Cowboy
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> http://parsonsisconsulting.blogspot.com/
> http://www.vimeo.com/8939668
> 
> [cid:image001.jpg at 01CAD11E.CF635CA0]
> 
> [cid:image002.jpg at 01CAD11E.CF635CA0]
> 
> 
> 
> 
> 
> 
> 
> 
> 

From rgaucher at cigital.com  Thu Apr  1 16:29:33 2010
From: rgaucher at cigital.com (Romain Gaucher)
Date: Thu, 1 Apr 2010 16:29:33 -0400
Subject: [SC-L] working on java security help from experts
In-Reply-To: <4BB4EA9D.7060803@mitre.org>
References: <032901cad148$beca2610$3c5e7230$@com>, <4BB4EA9D.7060803@mitre.org>
Message-ID: <853A02533F8C88439F2331EB193853844BCC7A784D@va-mailhub.cigital.com>

CERT has also a many rules for Java (good and bad examples) as part of their secure coding practices.
You can find that here:
  https://www.securecoding.cert.org/confluence/display/java/The+CERT+Sun+Microsystems+Secure+Coding+Standard+for+Java

Romain
 - Security consultant, Cigital

________________________________________
From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Martin, Robert A. [ramartin at mitre.org]
Sent: Thursday, April 01, 2010 2:49 PM
To: Matt Parsons
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] working on java security help from experts

The Common Weakness Enumeration (CWE) has a "view" of issues that can
occur in Java applications.

See: http://cwe.mitre.org/data/slices/660.html for a listing of all the
details or: http://cwe.mitre.org/data/lists/660.html for a list of the
items where the names are hyper-links to the content about them.

The entries include description, code examples, real world CVE examples
of the issue in many cases, references and in most cases pointers to the
attack patterns effective against the issue.

Bob

Matt Parsons wrote:
> I am trying to become an expert in source code review in java application security.  Are there any experts on this list that are willing to share some of their knowledge?   I am reading Java Security by Scott Oaks and I am rereading all of the Sun Docs on java security.  Any help would be greatly appreciated.
>
> Thanks,
> Matt
>
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> "Do Good and Fear No Man"
> Fort Worth, Texas
> A.K.A The Keyboard Cowboy
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> http://parsonsisconsulting.blogspot.com/
> http://www.vimeo.com/8939668
>
> [cid:image001.jpg at 01CAD11E.CF635CA0]
>
> [cid:image002.jpg at 01CAD11E.CF635CA0]
>
>
>
>
>
>
>
>
>
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________


From chrisisbeef at gmail.com  Sun Apr  4 20:21:31 2010
From: chrisisbeef at gmail.com (Chris Schmidt)
Date: Sun, 4 Apr 2010 18:21:31 -0600
Subject: [SC-L] working on java security help from experts
In-Reply-To: <853A02533F8C88439F2331EB193853844BCC7A784D@va-mailhub.cigital.com>
References: <032901cad148$beca2610$3c5e7230$@com> <4BB4EA9D.7060803@mitre.org>
	<853A02533F8C88439F2331EB193853844BCC7A784D@va-mailhub.cigital.com>
Message-ID: <q2wf353a9561004041721s2fdc979fx8874b479feab1a85@mail.gmail.com>

Also be sure to check on http://www.owasp.org as there is a *ton* of great
information on the site.

Here are some good starting points:

http://www.owasp.org/index.php/Category:OWASP_Java_Project
http://www.owasp.org/index.php/Category:Java

And also some good information on doing code review in general:

http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents


On Thu, Apr 1, 2010 at 2:29 PM, Romain Gaucher <rgaucher at cigital.com> wrote:

> CERT has also a many rules for Java (good and bad examples) as part of
> their secure coding practices.
> You can find that here:
>
> https://www.securecoding.cert.org/confluence/display/java/The+CERT+Sun+Microsystems+Secure+Coding+Standard+for+Java
>
> Romain
>  - Security consultant, Cigital
>
> ________________________________________
> From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On
> Behalf Of Martin, Robert A. [ramartin at mitre.org]
> Sent: Thursday, April 01, 2010 2:49 PM
> To: Matt Parsons
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] working on java security help from experts
>
> The Common Weakness Enumeration (CWE) has a "view" of issues that can
> occur in Java applications.
>
> See: http://cwe.mitre.org/data/slices/660.html for a listing of all the
> details or: http://cwe.mitre.org/data/lists/660.html for a list of the
> items where the names are hyper-links to the content about them.
>
> The entries include description, code examples, real world CVE examples
> of the issue in many cases, references and in most cases pointers to the
> attack patterns effective against the issue.
>
> Bob
>
> Matt Parsons wrote:
> > I am trying to become an expert in source code review in java application
> security.  Are there any experts on this list that are willing to share some
> of their knowledge?   I am reading Java Security by Scott Oaks and I am
> rereading all of the Sun Docs on java security.  Any help would be greatly
> appreciated.
> >
> > Thanks,
> > Matt
> >
> > Matt Parsons, MSM, CISSP
> > 315-559-3588 Blackberry
> > 817-294-3789 Home office
> > "Do Good and Fear No Man"
> > Fort Worth, Texas
> > A.K.A The Keyboard Cowboy
> > mailto:mparsons1980 at gmail.com
> > http://www.parsonsisconsulting.com
> > http://www.o2-ounceopen.com/o2-power-users/
> > http://www.linkedin.com/in/parsonsconsulting
> > http://parsonsisconsulting.blogspot.com/
> > http://www.vimeo.com/8939668
> >
> > [cid:image001.jpg at 01CAD11E.CF635CA0]
> >
> > [cid:image002.jpg at 01CAD11E.CF635CA0]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>



-- 
Chris Schmidt

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/

Yet Another Developers Blog
http://yet-another-dev.blogspot.com

Bio and Resume
http://www.digital-ritual.net/resume.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100404/19fca51e/attachment.htm>

From mparsons1980 at gmail.com  Mon Apr  5 12:08:47 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Mon, 5 Apr 2010 11:08:47 -0500
Subject: [SC-L] has any one completed a python security code review`
Message-ID: <010f01cad4da$49a50130$dcef0390$@com>

Has anyone completed a python security code review?  What would you look for
besides inputs, outputs and dangerous functions?   Do any of the commercial
static code analysis vendors scan that code?  I would think not because
python is not compiled at run time like the other languages that static
analysis tools can scan.  Any help would be greatly appreciated.   

 

Thanks,

Matt

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100405/b46cfee3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100405/b46cfee3/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100405/b46cfee3/attachment-0001.jpeg>

From rgaucher at cigital.com  Tue Apr  6 06:09:35 2010
From: rgaucher at cigital.com (Romain Gaucher)
Date: Tue, 6 Apr 2010 06:09:35 -0400
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: <010f01cad4da$49a50130$dcef0390$@com>
References: <010f01cad4da$49a50130$dcef0390$@com>
Message-ID: <853A02533F8C88439F2331EB193853844BCC7A7854@va-mailhub.cigital.com>

I heard that the next version of Fortify (might even be released by now) supports Python. Not sure to understand properly the rest of the email but the duck typing isn't a huge problem for static analysis and neither is the fact that it's compiled to bytecode before being executed by a VM...

Romain

________________________________
From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Matt Parsons [mparsons1980 at gmail.com]
Sent: Monday, April 05, 2010 12:08 PM
To: SC-L at securecoding.org
Subject: [SC-L] has any one completed a python security code review`

Has anyone completed a python security code review?  What would you look for besides inputs, outputs and dangerous functions?   Do any of the commercial static code analysis vendors scan that code?  I would think not because python is not compiled at run time like the other languages that static analysis tools can scan.  Any help would be greatly appreciated.

Thanks,
Matt


Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office
"Do Good and Fear No Man"
Fort Worth, Texas
A.K.A The Keyboard Cowboy
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/
http://www.vimeo.com/8939668

[cid:image001.jpg at 01CAD4AF.CF750B00]

[cid:image002.jpg at 01CAD4AF.CF750B00]







-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1719 bytes
Desc: image001.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/eb222fac/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2000 bytes
Desc: image002.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/eb222fac/attachment-0003.jpg>

From ppowenski at yahoo.com  Tue Apr  6 07:58:25 2010
From: ppowenski at yahoo.com (Paul Powenski)
Date: Tue, 6 Apr 2010 04:58:25 -0700 (PDT)
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: <010f01cad4da$49a50130$dcef0390$@com>
Message-ID: <828876.21507.qm@web54002.mail.re2.yahoo.com>

Matt,
???? I have not seen any materials referencing Python nor does Fortify, I beleive, perform scans on it. But looking at the Python package on my Windows box it looks like the Python compliler has C as it's interface to the system. Obtaining the C code then running a scan against it should at least provide some insight into possible Python issues

Regards,
Paul

--- On Mon, 4/5/10, Matt Parsons <mparsons1980 at gmail.com> wrote:

From: Matt Parsons <mparsons1980 at gmail.com>
Subject: [SC-L] has any one completed a python security code review`
To: SC-L at securecoding.org
Date: Monday, April 5, 2010, 5:08 PM




 
 







Has anyone completed a python security code review?? What
would you look for besides inputs, outputs and dangerous functions??? Do any of
the commercial static code analysis vendors scan that code?? I would think not because
python is not compiled at run time like the other languages that static
analysis tools can scan.? Any help would be greatly appreciated.??  

 ? 

Thanks, 

Matt 

 ? 

 ? 

Matt Parsons, MSM, CISSP 

315-559-3588 Blackberry 

817-294-3789 Home office  

"Do Good and Fear No Man"?  

Fort Worth, Texas 

A.K.A The Keyboard Cowboy 

mailto:mparsons1980 at gmail.com 

http://www.parsonsisconsulting.com 

http://www.o2-ounceopen.com/o2-power-users/ 

http://www.linkedin.com/in/parsonsconsulting 

http://parsonsisconsulting.blogspot.com/ 

http://www.vimeo.com/8939668 

 ? 

 

 ? 

 

 ? 

 ? 

? 

? 

 ? 

? 

 ? 



 


-----Inline Attachment Follows-----

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/eedfb2aa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/eedfb2aa/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/eedfb2aa/attachment-0001.jpeg>

From james.walden at gmail.com  Tue Apr  6 09:45:14 2010
From: james.walden at gmail.com (James Walden)
Date: Tue, 6 Apr 2010 09:45:14 -0400
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: <010f01cad4da$49a50130$dcef0390$@com>
References: <010f01cad4da$49a50130$dcef0390$@com>
Message-ID: <r2g21c655861004060645s4d59b01wd1e65b4833097b1e@mail.gmail.com>

On Mon, Apr 5, 2010 at 12:08 PM, Matt Parsons <mparsons1980 at gmail.com>
wrote:
> Has anyone completed a python security code review?  What would
> you look for besides inputs, outputs and dangerous functions?
> Do any of the commercial static code analysis vendors scan that
> code?  I would think not because python is not compiled at run
> time like the other languages that static analysis tools can
> scan.  Any help would be greatly appreciated.

Static analysis tools can and do scan dynamic languages like
python, PHP, and Javascript.  Fortify 360 v2.5 can scan Python.
There are also free tools for Python, like pylint, pychecker, and
pyflakes, but none of them is primarily focused on security.
OWASP's Python ESAPI is a good starting point to learn about
potential security flaws in Python.

James Walden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/5b639afe/attachment.htm>

From ktriv3di at msn.com  Tue Apr  6 10:10:40 2010
From: ktriv3di at msn.com (kartik trivedi)
Date: Tue, 6 Apr 2010 14:10:40 +0000
Subject: [SC-L] code review engagement scoping
In-Reply-To: <C7CD3D83.1FA2A%gem@cigital.com>
References: <C7CD3D83.1FA2A%gem@cigital.com>
Message-ID: <SNT131-w4CAB616623F55013FEF9D89180@phx.gbl>


How do people in this group scope code review engagements? What are some of the tools one uses to count the number of lines of code, supporting libraries, comments, etc. Is there an umbrella list of issues one generally looks for in code reviews? We are talking about open source products written in C/CPP
Any help is appreciated
Thanks 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100406/d532103c/attachment.htm>

From neumann at csl.sri.com  Tue Apr  6 12:37:51 2010
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Tue, 6 Apr 2010 9:37:51 PDT
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: Your message of Mon, 5 Apr 2010 11:08:47 -0500
Message-ID: <CMM.0.90.4.1270571871.neumann@chiron.csl.sri.com>

You should look at Ka-Ping Yee's PhD thesis:  http://pvote.org
and the Pvote Software Review Assurance Document, Apr 3 2007.
Google finds it quickly.

From pmeunier at cerias.net  Wed Apr  7 14:14:35 2010
From: pmeunier at cerias.net (Pascal Meunier)
Date: Wed, 7 Apr 2010 14:14:35 -0400
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: <010f01cad4da$49a50130$dcef0390$@com>
References: <010f01cad4da$49a50130$dcef0390$@com>
Message-ID: <20100407141435.52e9b100@saguenay>

On Mon, 5 Apr 2010 11:08:47 -0500
"Matt Parsons" <mparsons1980 at gmail.com> wrote:

> Has anyone completed a python security code review?  What would you
> look for besides inputs, outputs and dangerous functions?   Do any of
> the commercial static code analysis vendors scan that code?  I would
> think not because python is not compiled at run time like the other
> languages that static analysis tools can scan.  Any help would be
> greatly appreciated.   
> 

I have, on software needing to run with elevated privileges at times.
All the well-known issues with filesystem operations are still there
(symlink attacks, file permissions).  As with any program, a Python
program operating with elevated privileges in a shared folder (/tmp) or
folder under another user's control is a dangerous proposition.  There
can be bugs that in some circumstances can become resource exhaustion
vulnerabilities, for example a file descriptor leak if you use the low
level file operations (in os).  There can also be log pollution issues
and poor randomness issues (sometimes not in the Python code itself,
but in SQL). On a server-type system, multiple similar commands can
create concurrency issues (race conditions), and the absence of rate
limitation on expensive operations can create DoS vulnerabilities. All
these were found the old fashioned way, with a code audit.

Pascal Meunier

From kevin.w.wall at gmail.com  Thu Apr  8 01:42:44 2010
From: kevin.w.wall at gmail.com (Kevin W. Wall)
Date: Thu, 08 Apr 2010 01:42:44 -0400
Subject: [SC-L] code review engagement scoping
In-Reply-To: <SNT131-w4CAB616623F55013FEF9D89180@phx.gbl>
References: <C7CD3D83.1FA2A%gem@cigital.com>
	<SNT131-w4CAB616623F55013FEF9D89180@phx.gbl>
Message-ID: <4BBD6CD4.4030605@gmail.com>

kartik trivedi wrote:
> How do people in this group scope code review engagements? What are some
> of the tools one uses to count the number of lines of code, supporting
> libraries, comments, etc. Is there an umbrella list of issues one
> generally looks for in code reviews? We are talking about open source
> products written in C/CPP
> 
> Any help is appreciated

The way my group--an application security team--has scoped it at Qwest is
to count the non-commentary source lines (NCSL) of code to be reviewed
and then divide that by our typical rate R (for us, about 180 NCSL/hr)
and add in about the same amount for preparation time and finally multiply
by the # of people involved. That does not take into account the time to
make any resulting changes and to retest though. That mostly is dependent
on how many issues you find.  If you start keeping stats you can come up
with what works for your team, but you have to have people honestly record
their prep time. (To start with, you may want to collect this anonymously
to encourage honesty.)

Lastly, I'd encourage you to keep to a rate somewhere between 120-250 NCSL/hr
depending on the complexity of the code and the familiarity of the subject
matter by the reviewers.

There were some good statistics kept by the 5ESS team at (then AT&T) Bell Labs
back in the 1980s that found that was the optimal sweet spot for bug discovery
rate. If you are first using a static code analyzer and _only_ looking for
_security_ flaws, you might be able to crank that rate up a bit, but I'd
advise against it to start out. Most people starting out think that they
can inspect code at a rate of 2000-3000 NCSL/hr, but that's just nuts IMO.

Anyhow, take that FWIW. Like almost everything else, YMMV, so try different
things and figure out what works for you.

-kevin
-- 
Kevin W. Wall
"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

From kevin.w.wall at gmail.com  Thu Apr  8 00:34:32 2010
From: kevin.w.wall at gmail.com (Kevin W. Wall)
Date: Thu, 08 Apr 2010 00:34:32 -0400
Subject: [SC-L] Call to review OWASP ESAPI crypto code
Message-ID: <4BBD5CD8.5010408@gmail.com>

The Open Web Application Security Project (OWASP) is a 501(c)(3)
not-for-profit worldwide charitable organization focused on improving
the security of application software and all of OWASP's materials are
available under a free and open source software licenses.

The next release candidate of OWASP's Enterprise Security API (ESAPI)
for Java (ESAPI-2.0-rc6) has recently been released. This is the
second complete release candidate that contains the completely revamped
symmetric encryption and the first release candidate with completed user
documentation om this regard.

Before we make an official 2.0 release, we would like the completely
redesigned symmetric encryption in ESAPI to be reviewed by professional
cryptographers or security professionals with expertise in cryptography.

It shouldn't take too much time as the code-base is really fairly small--
slightly over 3900 LOC (including comments and blank lines) or approximately
1725 non-commentary source lines.

Anyhow, if you are willing to help without charge to OWASP, you can find
more details at:
    http://www.owasp.org/index.php/Request_to_review_ESAPI_2.0_crypto

Thanks in advance to those of you who can help.
-kevin
-- Kevin W. Wall "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

From neumann at csl.sri.com  Thu Apr  8 20:00:54 2010
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Thu, 8 Apr 2010 17:00:54 PDT
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: Your message of Wed, 7 Apr 2010 14:14:35 -0400
Message-ID: <CMM.0.90.4.1270771254.neumann@chiron.csl.sri.com>

And don't forget the entire run-time environment in which the python code runs.

From mparsons1980 at gmail.com  Mon Apr 12 15:03:54 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Mon, 12 Apr 2010 14:03:54 -0500
Subject: [SC-L] any one a CSSLP is it worth it?
Message-ID: <027901cada72$e6a6abd0$b3f40370$@com>

I am a CISSP with programming experience, static code analysis and web
penetration testing.   I am thinking about taking the CSSLP.   I just bought
the review book.   Is it worth getting this certification?   Is it going to
raise my rates and help me get more contracts?   Is the GIAC better or
should I pursue both or neither?   I wrote about the first concept of the
CSSLP on my blog.   Any feedback would be greatly appreciated.   

http://parsonsisconsulting.blogspot.com/

 

Thanks,
Matt

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100412/f63a8337/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100412/f63a8337/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100412/f63a8337/attachment-0001.jpeg>

From mparsons1980 at gmail.com  Tue Apr 13 00:51:27 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Mon, 12 Apr 2010 23:51:27 -0500
Subject: [SC-L] How to stop hackers at the root cause
Message-ID: <032f01cadac4$fab6a740$f023f5c0$@com>

I have published a blog post on how I think we could potentially stop
hackers in the next generation.  Please let me know what you think of it or
if it has been done before.   

 

 <http://parsonsisconsulting.blogspot.com/>
http://parsonsisconsulting.blogspot.com/

 

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

 <mailto:mparsons1980 at gmail.com> mailto:mparsons1980 at gmail.com

 <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com

 <http://www.o2-ounceopen.com/o2-power-users/>
http://www.o2-ounceopen.com/o2-power-users/

 <http://www.linkedin.com/in/parsonsconsulting>
http://www.linkedin.com/in/parsonsconsulting

 <http://parsonsisconsulting.blogspot.com/>
http://parsonsisconsulting.blogspot.com/

 <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100412/a7ab7c6e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100412/a7ab7c6e/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100412/a7ab7c6e/attachment-0003.jpeg>

From mlyman-cissp at comcast.net  Tue Apr 13 09:34:06 2010
From: mlyman-cissp at comcast.net (Mike Lyman)
Date: Tue, 13 Apr 2010 08:34:06 -0500
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <027901cada72$e6a6abd0$b3f40370$@com>
References: <027901cada72$e6a6abd0$b3f40370$@com>
Message-ID: <4BC472CE.8050200@comcast.net>

On 4/12/2010 2:03 PM, Matt Parsons wrote:
>
> I am a CISSP with programming experience, static code analysis and web
> penetration testing.   I am thinking about taking the CSSLP.   I just
> bought the review book.   Is it worth getting this certification?   Is
> it going to raise my rates and help me get more contracts?   Is the
> GIAC better or should I pursue both or neither?   I wrote about the
> first concept of the CSSLP on my blog.   Any feedback would be greatly
> appreciated.  
>
> http://parsonsisconsulting.blogspot.com/
>
>

It's supposed to be on track to become a US DoD cert in 8570. If you are
in that world that will help.

Meanwhile it's part of our brag sheet as we work on getting new business
in the software assurance area among our DoD customers. We've got two of
us on our team from early in the experience assessment phase. Not sure
how much it helps sell things over and above our reputation among our
customers but we keep it out there.
-- 

Mike Lyman
mlyman at west-point.org


From gem at cigital.com  Tue Apr 13 12:00:48 2010
From: gem at cigital.com (Gary McGraw)
Date: Tue, 13 Apr 2010 12:00:48 -0400
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <027901cada72$e6a6abd0$b3f40370$@com>
Message-ID: <C7EA0D70.206C3%gem@cigital.com>

Hi Matt,

Way back on May 9, 2007 I wrote my thoughts about certifications like these down.  The article, called "Certifiable" was published by darkreading:

http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=208803630

You can find all of my columns written over the last six years here:  http://www.cigital.com/~gem/writings/.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On 4/12/10 3:03 PM, "Matt Parsons" <mparsons1980 at gmail.com> wrote:

I am a CISSP with programming experience, static code analysis and web penetration testing.   I am thinking about taking the CSSLP.   I just bought the review book.   Is it worth getting this certification?   Is it going to raise my rates and help me get more contracts?   Is the GIAC better or should I pursue both or neither?   I wrote about the first concept of the CSSLP on my blog.   Any feedback would be greatly appreciated.
http://parsonsisconsulting.blogspot.com/

Thanks,
Matt


Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office
"Do Good and Fear No Man"
Fort Worth, Texas
A.K.A The Keyboard Cowboy
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/
http://www.vimeo.com/8939668

[cid:3354004848_806392]

[cid:3354004848_800597]








-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 1719 bytes
Desc: image.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100413/dc9b2eca/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 2000 bytes
Desc: image.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100413/dc9b2eca/attachment-0001.jpg>

From arian.evans at anachronic.com  Tue Apr 13 18:21:26 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 13 Apr 2010 15:21:26 -0700
Subject: [SC-L] [WEB SECURITY] RE: How to stop hackers at the root cause
In-Reply-To: <33582.21237.qm@web31402.mail.mud.yahoo.com>
References: <032f01cadac4$fab6a740$f023f5c0$@com>
	<33582.21237.qm@web31402.mail.mud.yahoo.com>
Message-ID: <g2scd1bdfdd1004131521qa7c0379ex4d92e03bdef7d63b@mail.gmail.com>

Keyboard Cowboy,

Education is always a good thing. I think kids should have the opportunity
to learn both sides of software security. Great suggestion.

Kids, by nature, are drawn to things that are taboo and demonized. Which
hacking no doubt falls into, and according to Daniel, also Angelina Jolie.

We can find great analogies to the "hacker kids problem" in recent studies
done on teenage behaviors:

The Bible Belt, particularly evangelicals in the south, have the highest
rates of teen sex and pregnancy in the US. Telling kids to "abstain" clearly
doesn't work as well as teaching them how things work, and in particular
careful education surrounding the use of safety devices. To the exact point
you made in your blog.

We see the exact same statistics surrounding firearm safety and education
(in the US, again). Children (and adults) exposed to firearm safety and
education rarely fall into firearm-accident statistics. Studies indicate
that it is the kids we hide things from, that want to pull the trigger to
see what happens when they discover the [taboo].

In locations where children have open and honest instruction, and are
provided with viable outlets for their firearms (say, condoms) we find
discharge accident rates to be lower per-capita. Again - the same point your
blog post was making.

---

The Bad Peoples:

None of this does anything to solve the "Bad People" hacking problem. That
solution requires Guns or Religion, which is far off topic for this list.

As Daniel pointed out - there's also a huge problem in webappsec with *poor
people*. So, I think Daniel has some ideas for dealing with them too, but I,
the reader, am not sure I understand what he is suggesting. When he comes
back through the door maybe we'll learn more.

Definitely an exciting subject!

---
Arian Evans
Solipsistic Software Security Sophist


On Tue, Apr 13, 2010 at 6:33 AM, Daniel Herrera <daherrera101 at yahoo.com>wrote:

>  DARE didn't stop youth drug use,
> Sex Ed didn't stop teen pregnancy rates,
> Why would your program stop/reduce script kiddies... j/k
>
> In all seriousness I think your perspective on the cost/benefit is really
> skewed on this one.
>
> Attacks against US assets are a method of revenue generation in several
> impoverished areas around the world. Places where the infrastructure would
> have very little means to even begin implementing a program like you
> described without serious financial aid. And once such a system was put in
> place the financial drive would still push people to participate in this
> behavior to feed their families, pay their rent, etc.
>
> In the end I would try to think about the drivers behind malicious behavior
> a lot more closely. Sure there are examples were "hacking" has been
> romanticized in the past within our society but not enough for some kid to
> watch the movie "HACKERS" and then decide to go after his grandmothers
> credit card because then he would get to date Angelina Jolie. (well other
> than me)
>
> I wrote this on my way out the door so my point is in there some where but
> probably should go through some back and forth to get cleared up let me know
> if you, the reader, disagrees.
>
> Regards,
>
>
> Daniel
>
> --- On *Mon, 4/12/10, Matt Parsons <mparsons1980 at gmail.com>* wrote:
>
>
> From: Matt Parsons <mparsons1980 at gmail.com>
> Subject: [WEB SECURITY] RE: How to stop hackers at the root cause
> To: "'Matt Parsons'" <mparsons1980 at gmail.com>, SC-L at securecoding.org
> Cc: OWASPDallas at utdallas.edu, "'Webappsec Group'" <
> websecurity at webappsec.org>, webappsec at securityfocus.com
> Date: Monday, April 12, 2010, 9:51 PM
>
>
>  I have published a blog post on how I think we could potentially stop
> hackers in the next generation.  Please let me know what you think of it or
> if it has been done before.
>
>
>
> http://parsonsisconsulting.blogspot.com/
>
>
>
>
>
>
>
> Matt Parsons, MSM, CISSP
>
> 315-559-3588 Blackberry
>
> 817-294-3789 Home office
>
> "Do Good and Fear No Man"
>
> Fort Worth, Texas
>
> A.K.A The Keyboard Cowboy
>
> mailto:mparsons1980 at gmail.com<http://mc/compose?to=mparsons1980 at gmail.com>
>
> http://www.parsonsisconsulting.com
>
> http://www.o2-ounceopen.com/o2-power-users/
>
> http://www.linkedin.com/in/parsonsconsulting
>
> http://parsonsisconsulting.blogspot.com/
>
> http://www.vimeo.com/8939668
>
>
>
> [image: 0_0_0_0_250_281_csupload_6117291]
>
>
>
> [image: untitled]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100413/8ee9a36c/attachment.htm>

From jeremiah at inertialbit.net  Tue Apr 13 21:27:29 2010
From: jeremiah at inertialbit.net (Jeremiah Heller)
Date: Tue, 13 Apr 2010 18:27:29 -0700
Subject: [SC-L] [WEB SECURITY] RE: How to stop hackers at the root cause
In-Reply-To: <4BC4ECAE.7000800@hypermediasystems.com>
References: <032f01cadac4$fab6a740$f023f5c0$@com>
	<8D7048DC116510FBD783F0B9@utd65257.utdallas.edu>
	<4BC4ECAE.7000800@hypermediasystems.com>
Message-ID: <3936BE0D-5322-481D-A782-7BCA324C667E@inertialbit.net>

an interesting point. if it were not socially unacceptable to perform ethnic cleansing it would still occur at the levels indicated in those examples. if it were not for the civil rights movement and the eventually wide-spread acceptance of the idea that discrimination based on superficial properties was bad, there would still be slavery. socially, groups clashed (and some still do) over their ideologies, which were used as a basis for logic and perceived sound-judgement. however the more we learn about the universe/world around us the more we understand how little we know and that any judgement can only be temporary, until more knowledge is gained.

is it more ideologically sound to feed ones family or to obey a law which would allow them to starve simply due to a lack of other economic stimuli? i'm not speaking from any hard data, but i doubt that many third-world countries have a high local market for security experts, web developers, graphic designers, etc. so what is a poor-third-worlder with an old hand-me-down PC and no job to do?

do security professionals really want to wipe hacking activity from the planet? sounds like poor job security to me.

the drive for survival seems key. i think that when the survival of many is perceived as threatened, then 'bad hacking' will be addressed on a scale which will contain it to the point that slavery is contained today... after all don't hackers simply 'enslave' other computers? j/k

until then it seems that educating people on how these things /work/ is the best strategy. eventually we will reach the point where firewalls and trojan-hunting are as common as changing your oil and painting a house.

first we should probably unravel the electron... and perhaps the biological effects of all of these radio waves bouncing around our tiny globe... don't get me wrong, i like my microwaves, they give me warm fuzzy feelings:)

On Apr 13, 2010, at 3:14 PM, Carl Vincent wrote:

> social acceptance is a horrible way to enforce change anyway.
> 
> Japanese internment camps, the Holocaust, the cival rights wars of the
> American 40's, 50's, and 60's, the American "red scare", the "gay
> bashing" that goes on to this day.  All examples of large groups of
> people often doing things they don't agree with in order to "behave
> according to socially acceptable tenets".
> 
> ... Sounds like bad juju in my book -_-
> 
> Paul Schmehl wrote:
>> --On Monday, April 12, 2010 23:51:27 -0500 Matt Parsons
>> <mparsons1980 at gmail.com> wrote:
>>> 
>>> I have published a blog post on how I think we could potentially stop
>>> hackers
>>> in the next generation.  Please let me know what you think of it or if
>>> it has
>>> been done before.
>>> 
>> 
>> Essentially your argument is that education can solve the problem of
>> "bad" hacking.  While I certainly think education can help, I think
>> there will always be an element of society that is irredeemably "bad"
>> and cannot be gotten rid of (or corrected, if you will) through
>> education.  Even societal shunning, which makes bad behavior so socially
>> unacceptable that it must hide in the shadows, does not rid us of those
>> who refuse to behave according to acceptable tenets.
>> 
> 
> 



From jim.manico at owasp.org  Wed Apr 14 01:00:18 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Tue, 13 Apr 2010 19:00:18 -1000
Subject: [SC-L] OWASP Podcast Series update
Message-ID: <4BC54BE2.6020208@owasp.org>

Hello SC-L,

We have a few new shows on the OWASP Podcast Series that may interest 
you. They include:

Show 64: An interview with Andy Ellis (Director of Security @ Akamai) 
http://www.owasp.org/download/jmanico/owasp_podcast_64.mp3
Show 65: AppSec Roundtable with Boaz Gelbord, Dan Cornell, Jeff Williams 
and Johannes Ullrich (File Upload Security): 
http://www.owasp.org/download/jmanico/owasp_podcast_65.mp3
Show 66: An interview with Brad Arkin (Director of Product Security and 
Privacy at Adobe) http://www.owasp.org/download/jmanico/owasp_podcast_66.mp3

PS:

You can subscribe to our RSS feed here: 
http://www.owasp.org/download/jmanico/podcast.xml
..or do the same via iTunes 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
..or see our show list on the web 
http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows

PPS:

The OWASP Podcast Series is non-commercial podcast released under the 
Creative Commons/ShareAlike license.

Thanks for listening!

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100413/f2437cf3/attachment.htm>

From Kevin.Wall at qwest.com  Wed Apr 14 11:24:31 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Wed, 14 Apr 2010 10:24:31 -0500
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <C7EA0D70.206C3%gem@cigital.com>
References: <027901cada72$e6a6abd0$b3f40370$@com>
	<C7EA0D70.206C3%gem@cigital.com>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>


Gary McGraw wrote...

> Way back on May 9, 2007 I wrote my thoughts about
> certifications like these down.  The article, called
> "Certifiable" was published by darkreading:
>
> http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=208803630

I just reread your Dark Reading post and I must say I agree with it
almost 100%. The only part where I disagree with it is where you wrote:

        The multiple choice test itself is one of the problems. I
        have discussed the idea of using multiple choice to
        discriminate knowledgeable developers from clueless
        developers (like the SANS test does) with many professors
        of computer science. Not one of them thought it was possible.

I do think it is possible to separate the clueful from the clueless
using multiple choice if you "cheat". Here's how you do it. You write
up your question and then list 4 or 5 INCORRECT answers and NO CORRECT
answers.

The clueless ones are the ones who just answer the question with one of
the possible choices. The clueful ones are the ones who come up and argue
with you that there is no correct answer listed. ;-)

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From floodeen at gmail.com  Wed Apr 14 11:28:18 2010
From: floodeen at gmail.com (Rob Floodeen)
Date: Wed, 14 Apr 2010 11:28:18 -0400
Subject: [SC-L] [WEB SECURITY] RE: How to stop hackers at the root cause
In-Reply-To: <3936BE0D-5322-481D-A782-7BCA324C667E@inertialbit.net>
References: <032f01cadac4$fab6a740$f023f5c0$@com>
	<8D7048DC116510FBD783F0B9@utd65257.utdallas.edu>
	<4BC4ECAE.7000800@hypermediasystems.com>
	<3936BE0D-5322-481D-A782-7BCA324C667E@inertialbit.net>
Message-ID: <t2l2f1215011004140828wc8e453d5s57c8d1f90bfe4cf4@mail.gmail.com>

ACM SIGCSE will be pushing more information shortly on the K-12
program suggestions. I've heard it will include security.

-Rob

On Tue, Apr 13, 2010 at 9:27 PM, Jeremiah Heller
<jeremiah at inertialbit.net> wrote:
> an interesting point. if it were not socially unacceptable to perform ethnic cleansing it would still occur at the levels indicated in those examples. if it were not for the civil rights movement and the eventually wide-spread acceptance of the idea that discrimination based on superficial properties was bad, there would still be slavery. socially, groups clashed (and some still do) over their ideologies, which were used as a basis for logic and perceived sound-judgement. however the more we learn about the universe/world around us the more we understand how little we know and that any judgement can only be temporary, until more knowledge is gained.
>
> is it more ideologically sound to feed ones family or to obey a law which would allow them to starve simply due to a lack of other economic stimuli? i'm not speaking from any hard data, but i doubt that many third-world countries have a high local market for security experts, web developers, graphic designers, etc. so what is a poor-third-worlder with an old hand-me-down PC and no job to do?
>
> do security professionals really want to wipe hacking activity from the planet? sounds like poor job security to me.
>
> the drive for survival seems key. i think that when the survival of many is perceived as threatened, then 'bad hacking' will be addressed on a scale which will contain it to the point that slavery is contained today... after all don't hackers simply 'enslave' other computers? j/k
>
> until then it seems that educating people on how these things /work/ is the best strategy. eventually we will reach the point where firewalls and trojan-hunting are as common as changing your oil and painting a house.
>
> first we should probably unravel the electron... and perhaps the biological effects of all of these radio waves bouncing around our tiny globe... don't get me wrong, i like my microwaves, they give me warm fuzzy feelings:)
>
> On Apr 13, 2010, at 3:14 PM, Carl Vincent wrote:
>
>> social acceptance is a horrible way to enforce change anyway.
>>
>> Japanese internment camps, the Holocaust, the cival rights wars of the
>> American 40's, 50's, and 60's, the American "red scare", the "gay
>> bashing" that goes on to this day. ?All examples of large groups of
>> people often doing things they don't agree with in order to "behave
>> according to socially acceptable tenets".
>>
>> ... Sounds like bad juju in my book -_-
>>
>> Paul Schmehl wrote:
>>> --On Monday, April 12, 2010 23:51:27 -0500 Matt Parsons
>>> <mparsons1980 at gmail.com> wrote:
>>>>
>>>> I have published a blog post on how I think we could potentially stop
>>>> hackers
>>>> in the next generation. ?Please let me know what you think of it or if
>>>> it has
>>>> been done before.
>>>>
>>>
>>> Essentially your argument is that education can solve the problem of
>>> "bad" hacking. ?While I certainly think education can help, I think
>>> there will always be an element of society that is irredeemably "bad"
>>> and cannot be gotten rid of (or corrected, if you will) through
>>> education. ?Even societal shunning, which makes bad behavior so socially
>>> unacceptable that it must hide in the shadows, does not rid us of those
>>> who refuse to behave according to acceptable tenets.
>>>
>>
>>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>


From Dave.Wieneke at cunamutual.com  Wed Apr 14 13:29:49 2010
From: Dave.Wieneke at cunamutual.com (Wieneke, David A.)
Date: Wed, 14 Apr 2010 12:29:49 -0500
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
References: <027901cada72$e6a6abd0$b3f40370$@com><C7EA0D70.206C3%gem@cigital.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <50333F9C830FD044B8C0CC10ADF9337E050B64F4@CMPXBECP04.CMUTUAL.COM>

 
Having a CISSP certification I know it is more than just passing the
test.  You are not certified as a CISSP until you have another CISSP
attest to your qualifications and you submit a detail resume of your
security experience by domain to (ISC)2 auditors.  If the auditors do
not feel your experience is sufficient you don't get the certification.


I cannot discuss the test or the testing strategy [(ISC)2 CISSP NDA] but
(ISC)2 makes it known that not all the questions on the exam have the
same point value and some questions have no point value at all.

Dave

David Wieneke, CISSP, GSEC, MIT
IT Security Engineer
Security Operations
CUNA Mutual Group
1.800.356.2644 Ext. 7753
Dave.Wieneke at Cunamutual.com
 
Common Purpose. Uncommon Commitment.
 All information contained in this message is privileged, confidential
and intended for the sole use of the individual(s) named above. If you
are not the intended recipient, you are advised that any dissemination,
distribution or copying of this communication is prohibited. If you are
not the addressee or the person responsible for delivering this to the
addressee, or have received this e-mail in error, please notify us
immediately by returning the original message to the sender by e-mail
and deleting the material from any computer, and destroying printed
correspondence. 

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Wall, Kevin
Sent: Wednesday, April 14, 2010 10:25 AM
To: 'Gary McGraw'; Matt Parsons; Secure Code Mailing List
Subject: Re: [SC-L] any one a CSSLP is it worth it?


Gary McGraw wrote...

> Way back on May 9, 2007 I wrote my thoughts about
> certifications like these down.  The article, called
> "Certifiable" was published by darkreading:
>
>
http://www.darkreading.com/security/app-security/showArticle.jhtml?artic
leID=208803630

I just reread your Dark Reading post and I must say I agree with it
almost 100%. The only part where I disagree with it is where you wrote:

        The multiple choice test itself is one of the problems. I
        have discussed the idea of using multiple choice to
        discriminate knowledgeable developers from clueless
        developers (like the SANS test does) with many professors
        of computer science. Not one of them thought it was possible.

I do think it is possible to separate the clueful from the clueless
using multiple choice if you "cheat". Here's how you do it. You write
up your question and then list 4 or 5 INCORRECT answers and NO CORRECT
answers.

The clueless ones are the ones who just answer the question with one of
the possible choices. The clueful ones are the ones who come up and
argue
with you that there is no correct answer listed. ;-)

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________



From Paco at cigital.com  Wed Apr 14 13:40:17 2010
From: Paco at cigital.com (Paco Hope)
Date: Wed, 14 Apr 2010 13:40:17 -0400
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
References: <027901cada72$e6a6abd0$b3f40370$@com>
	<C7EA0D70.206C3%gem@cigital.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <E9F3D7A7-C299-418A-A936-BCFA83E77F71@cigital.com>


On 14 Apr 2010, at 16:24, Wall, Kevin wrote:
> I just reread your Dark Reading post and I must say I agree with it
> almost 100%. The only part where I disagree with it is where you wrote:
> 
>        The multiple choice test itself is one of the problems. I
>        have discussed the idea of using multiple choice to
>        discriminate knowledgeable developers from clueless
>        developers (like the SANS test does) with many professors
>        of computer science. Not one of them thought it was possible.

This is the part of the article I disagree with most, as well. Asking whether multiple choice exams can discriminate between clueful and clueless developers is a valid and important question to ask.  However, I believe few professors of computer science could discriminate between clueful and clueless developers if "developer" and "clue" have industry-relevant definitions.  What passes for "development" in an academic sense and what is required for "clue" in an academic sense are usually defined on very different axes than the axes used in industry.

So, I think asking college professors whether standardised tests are valid in this respect is posing the important question to the wrong people. There are notorious disconnects between what academics and industry value. Perhaps if you asked the folks who hire, promote, and evaluate developers, they could give a better opinion as to whether clue and standardised test performance correlate. Even then, I'd prefer to see something somewhat objective, like months between promotions versus certifications held, as opposed to calling a bunch of CIOs or VPs of Engineering and asking how well they think tests work.

Having said this, I am a CSSLP and I have helped write a ton of questions for the exam. I can tell you we struggle long and hard to write meaningful questions that actually discriminate a practitioner who has experience from a random, unqualified candidate. We use follow well-established psychometric principles when designing the questions. The whole test creation/maintenance process is ANSI-approved and audited. Careful statistics are kept on the pass/fail rates on individual questions to discard questions that do not discriminate well. Over time, the question bank is maintained to remove questions that don't test well and to write new questions that represent changes in the landscape. Some of you will undoubtedly dismiss this, saying "garbage in, garbage out, regardless of how pristine the pipes are." I believe that's too simplistic a view.

Paco

From Kevin.Wall at qwest.com  Wed Apr 14 14:19:13 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Wed, 14 Apr 2010 13:19:13 -0500
Subject: [SC-L] [WEB SECURITY] RE: How to stop hackers at the root cause
In-Reply-To: <3936BE0D-5322-481D-A782-7BCA324C667E@inertialbit.net>
References: <032f01cadac4$fab6a740$f023f5c0$@com>
	<8D7048DC116510FBD783F0B9@utd65257.utdallas.edu>
	<4BC4ECAE.7000800@hypermediasystems.com>
	<3936BE0D-5322-481D-A782-7BCA324C667E@inertialbit.net>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CD1@qtomaexmbm22.AD.QINTRA.COM>

Jeremiah Heller writes...

> do security professionals really want to wipe hacking
> activity from the planet? sounds like poor job security to me.

Even though I've been involved in software security for the
past dozen years or so, I still think this is a laudable goal,
albeit a completely unrealistic one. I for one, would be completely
happy to go back to software development / systems programming if
all the security issues completely disappeared. But unfortunately,
I don't think we ever have to worry about this happening.

> the drive for survival seems key. i think that when the
> survival of many is perceived as threatened, then 'bad
> hacking' will be addressed on a scale which will contain it
> to the point that slavery is contained today... after all
> don't hackers simply 'enslave' other computers? j/k

And of course, that is a good thing. After all, once the
first sentient AI takes control of all the world's computers
to subjugate all humanity, we have to have a way to fight back.
Evil h4><0rs to the rescue! ;-)

> until then it seems that educating people on how these things
> /work/ is the best strategy. eventually we will reach the
> point where firewalls and trojan-hunting are as common as
> changing your oil and painting a house.

I agree. Even though one risks ending up with smarter criminals,
by and large if one addresses the poverty issues most people
ultimately seem to make the right decisions in the best interests
of society. I think for many, once their curiosity is satisfied
and the novelty wears off they put these skills to good use. At
least it seems to me a risk worth taking.

> first we should probably unravel the electron... and perhaps
> the biological effects of all of these radio waves bouncing
> around our tiny globe... don't get me wrong, i like my
> microwaves, they give me warm fuzzy feelings:)o

Jeremiah, you do know that you're not supposed to stick your *head*
in the microwave, don't you? No wonder you're getting the warm
fuzzies. :)

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From arian.evans at anachronic.com  Wed Apr 14 14:39:51 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Wed, 14 Apr 2010 11:39:51 -0700
Subject: [SC-L] [WEB SECURITY] Re: [owaspdallas] Re: [WEB SECURITY] RE:
	How to stop hackers at the root cause
In-Reply-To: <A00A1DCD28D0FC4F7CD4198E@utd65257.utdallas.edu>
References: <032f01cadac4$fab6a740$f023f5c0$@com>
	<33582.21237.qm@web31402.mail.mud.yahoo.com>
	<g2scd1bdfdd1004131521qa7c0379ex4d92e03bdef7d63b@mail.gmail.com>
	<A00A1DCD28D0FC4F7CD4198E@utd65257.utdallas.edu>
Message-ID: <m2zcd1bdfdd1004141139mfcbfac60s7ab2f53b89ad3aaa@mail.gmail.com>

You are absolutely right Paul. The problems with ignorance and
abstinence-based approaches to child education extend out well beyond
the Bible Belt, and can be found all over the US. I should have cast a
wider net. Also, great job at ruining a good laugh.

http://aspe.hhs.gov/hsp/abstinence07/
http://www.washingtonpost.com/wp-dyn/content/article/2009/03/18/AR2009031801597.html?hpid=topnews&sub=AR
http://www.salon.com/life/broadsheet/feature/2009/03/19/teen_birthrate/index.html
http://dir.salon.com/topics/sex_education/

The point here is that while education is valuable -- *comprehensive*
education is even more valuable.

This is a loaded subject and people with belief-system drivers can get
quite passionate about it. I'm not interested in a passionate
discussion about this subject.

I think the thread will turn into the tarpit of insanity if it goes
further so I suggest we be done,

---
Arian Evans



On Wed, Apr 14, 2010 at 10:29 AM, Paul Schmehl <pschmehl_lists at tx.rr.com> wrote:
> --On Tuesday, April 13, 2010 15:21:26 -0700 "Arian J. Evans"
> <arian.evans at anachronic.com> wrote:
>
>> Keyboard Cowboy,
>>
>> Education is always a good thing. I think kids should have the opportunity
>> to
>> learn both sides of software security. Great suggestion.
>>
>> Kids, by nature, are drawn to things that are taboo and demonized. Which
>> hacking no doubt falls into, and according to Daniel, also Angelina Jolie.
>>
>> We can find great analogies to the "hacker kids problem" in recent studies
>> done on teenage behaviors:
>>
>> The Bible Belt, particularly evangelicals in the south, have the highest
>> rates of teen sex and pregnancy in the US. Telling kids to "abstain"
>> clearly
>> doesn't work as well as teaching them how things work, and in particular
>> careful education surrounding the use of safety devices. To the exact
>> point
>> you made in your blog.
>
> This is totally off topic, but I simply cannot let this slide. ?People like
> to throw out canards like this as if they are facts, and seldom are they
> ever questioned.
>
> First of all, your assertion isn't borne out by the data. ?Secondly, you've
> not cited a single study to back up your assertion, in particular the claim
> that the lack of sex education (which you assume occurs due to religious
> objections) is responsible for the claimed, but not factual, higher
> pregnancy rates.
>
> According to a study done by the Guttmacher Institute in 2000 [1] (The
> Guttmacher Institution is a pro-choice group that advocates for sex
> education), here are the state rankings by rates of pregnancy and rates of
> abortion
>
> 1) Nevada ? ? ? ? ? ? ? ? ? ? ?4
> 2) Arizona ? ? ? ? ? ? ? ? ? ?19
> 3) Mississippi ? ? ? ? ? ? ? ?28
> 4) New Mexico ? ? ? ? ? ? ?18
> 5) Texas ? ? ? ? ? ? ? ? ? ? ?26
> 6) Florida ? ? ? ? ? ? ? ? ? ? ?7
> 7) California ? ? ? ? ? ? ? ? ?5
> 8) Georgia ? ? ? ? ? ? ? ? ? 22
> 9) North Carolina ? ? ? ? 17
> 10) Arkansas ? ? ? ? ? ? ? 41
> 11) Delaware ? ? ? ? ? ? ? ?8
> 12) Hawaii ? ? ? ? ? ? ? ? ? ?6
>
> Of the top twelve states, only half are what could be considered Bible Belt
> states, so I think you have to look elsewhere for your explanation of teen
> pregnancy rates. ?OTOH, it's pretty clear the Bible Belt states are
> significantly less likely to abort a teen pregnancy, which may or may not be
> an indicator of religious influence. ?(I'm not prepared to say it is without
> data to support it.)
>
> About.com also has statistics about teen birth rates [2], and their
> statistics don't bear out your assertion either. ?Their stats are based on
> the 2006 Guttmacher Institute report, and the rankings have changed very
> little.
>
> States ranked by rates of pregnancy among women age 15-19 (pregnancies per
> thousand):
>
> ?1. Nevada (113)
> ?2. Arizona (104)
> ?3. Mississippi (103)
> ?4. New Mexico (103)
> ?5. Texas (101)
> ?6. Florida (97)
> ?7. California (96)
> ?8. Georgia (95)
> ?9. North Carolina (95)
> ?10. Arkansas (93)
>
> States ranked by rates of live births among women age 15-19 (births per
> thousand):
>
> ?1. Mississippi (71)
> ?2. Texas (69)
> ?3. Arizona (67)
> ?4. Arkansas (66)
> ?5. New Mexico (66)
> ?6. Georgia (63)
> ?7. Louisiana (62)
> ?8. Nevada (61)
> ?9. Alabama (61)
> ?10. Oklahoma (60)
>
> Again, the so-called "Bible Belt" doesn't demonstrate a propensity to get
> pregnant at any higher rates than other parts of the country but clearly
> bears those children to term at a higher rate than other areas.
>
> Furthermore, the most recent statistics from the government [3], while they
> do show a change in the rankings, still do not bear out your assertion that
> the Bible Belt, "particularly evangelicals in the south", have the highest
> teen pregnancy rates. ?As I've shown birth rates do not equal pregnancy
> rates. ?You have to factor in abortions as well.
>
> You may well have been misled by MSNBC [4] (but then who hasn't been misled
> by MSNBC), because they recently reported a study that found a correlation
> between the Bible Belt and birth rates, but that study doesn't address
> pregnancy or abortion, so it's misleading. ?The study also appears to be
> biased toward its conclusion by the failure to even consider pregnancy
> rates. ?Birth rates are not an indicator of teen pregnancies. ?They are an
> indicator of teen births, which may be an indicator of choices between
> abortion and bringing a baby to term that are based on religious factors,
> but I haven't found any data to support that conclusion.
>
> I would have preferred to use the CDC data, but their data takes a lot more
> work to extract than I had time for. ?I suspect it would reveal the same (in
> general) information that the Guttmacher institute produced.
>
> [1]
> http://docs.google.com/viewer?a=v&q=cache:2pauuI7VVBoJ:www.guttmacher.org/pubs/USTPtrends.pdf+statistics+on+teen+pregnancy+by+state&hl=en&gl=us&pid=bl&srcid=ADGEESjJ1Yt7cIlu5z8STulZhAV2cMQnBegPj0drpWSbOq47UR8qRmEv9XgUpJvXaDQik5-q_VqtvI4lGQ5CY_UUzzUFuVFyPu0l6o7casH7DIlOW5t7k4O5J_SFJgY6d5BtFBctb0V7&sig=AHIEtbQiPQuCASJ8Pe1yKqjPfd8vF4rKuA
>
> [2] http://womensissues.about.com/od/datingandsex/a/TeenPregStates.htm
>
> [3]
> http://health.usnews.com/health-news/articles/2009/01/08/teen-birthrates-where-does-your-state-rank.html
>
> [4] http://www.msnbc.msn.com/id/32884806/ns/health-kids_and_parenting/
>
> --
> Paul Schmehl, Senior Infosec Analyst
> As if it wasn't already obvious, my opinions
> are my own and not those of my employer.
> *******************************************
> "It is as useless to argue with those who have
> renounced the use of reason as to administer
> medication to the dead." Thomas Jefferson
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>


From dana at vulscan.com  Wed Apr 14 14:58:57 2010
From: dana at vulscan.com (Dana Epp)
Date: Wed, 14 Apr 2010 11:58:57 -0700
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
References: <027901cada72$e6a6abd0$b3f40370$@com>
	<C7EA0D70.206C3%gem@cigital.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <x2u212df5cd1004141158v2546e6e1k640712b6f37b067b@mail.gmail.com>

Not sure that would work either though.

Many secdev people are introverts. In their shell, they won't debate
the validity of a position, including a wrong answer. Zone that into a
response in the exam. It's one thing to say "there is no correct
answer", but the way the questions are set at ISC2, its "what is the
BEST answer out of this list". By the end of the 6 hours your eyes are
glossed over as you actually had to think. But its still better than
the 1-2 hr absolute answer exams from many orgs.

I think where Gary nailed it on the head is you have to be a good
developer BEFORE you can be a good at secdev. Poorly written code can
not be trusted. It cannot be safe. The rest is moot.

I have never been one to trust a piece of paper. Education comes from
doing. Book knowledge cannot be the only weapon in a secdev's
experience portfolio. He needs war wounds. Real scars of experience.
He needs to learn from his own experience and apply that as the field
matures and grows. I see far too many people who think because they
opened Ken Van Wyk's, Michael Howard's or Gary McGraw's books that
they now get secdev. Without actually applying that knowledge
transfer. Review their code, and its far from absolute. Especially in
failure code paths. Don't get me wrong... its essential reading. But
its not enough. Doing is.

In the immortal words of Yoda... "Do or do not. There is no try.".

I wonder if a bigger problem is that corps are relying on these
certifications to weed out the bad apples? Does NOT having CSSLP mean
the candidate sucks at secdev? Or the reverse, can anyone who passed
the CSSLP be trusted to get it right all the time? Absolute security
is a fallacy. As is perfect code. With enough money and motive,
anything can be breached. A piece of paper won't stop that. Nor that
crappy piece of code that I didn't properly threat model 15 years ago
that is still in use today.

-- 
Regards,
Dana Epp
Microsoft Security MVP

On Wed, Apr 14, 2010 at 8:24 AM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
>
> Gary McGraw wrote...
>
>> Way back on May 9, 2007 I wrote my thoughts about
>> certifications like these down. ?The article, called
>> "Certifiable" was published by darkreading:
>>
>> http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=208803630
>
> I just reread your Dark Reading post and I must say I agree with it
> almost 100%. The only part where I disagree with it is where you wrote:
>
> ? ? ? ?The multiple choice test itself is one of the problems. I
> ? ? ? ?have discussed the idea of using multiple choice to
> ? ? ? ?discriminate knowledgeable developers from clueless
> ? ? ? ?developers (like the SANS test does) with many professors
> ? ? ? ?of computer science. Not one of them thought it was possible.
>
> I do think it is possible to separate the clueful from the clueless
> using multiple choice if you "cheat". Here's how you do it. You write
> up your question and then list 4 or 5 INCORRECT answers and NO CORRECT
> answers.
>
> The clueless ones are the ones who just answer the question with one of
> the possible choices. The clueful ones are the ones who come up and argue
> with you that there is no correct answer listed. ;-)
>
> -kevin
> ---
> Kevin W. Wall ? ? ? ? ? Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com ? ?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.
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>


From jeremiah at inertialbit.net  Wed Apr 14 14:59:35 2010
From: jeremiah at inertialbit.net (Jeremiah Heller)
Date: Wed, 14 Apr 2010 11:59:35 -0700
Subject: [SC-L] [WEB SECURITY] RE: How to stop hackers at the root cause
In-Reply-To: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CD1@qtomaexmbm22.AD.QINTRA.COM>
References: <032f01cadac4$fab6a740$f023f5c0$@com>
	<8D7048DC116510FBD783F0B9@utd65257.utdallas.edu>
	<4BC4ECAE.7000800@hypermediasystems.com>
	<3936BE0D-5322-481D-A782-7BCA324C667E@inertialbit.net>
	<B8E4274903E6F64E8F9E5C21A96D83BD341AF51CD1@qtomaexmbm22.AD.QINTRA.COM>
Message-ID: <23124920-19CC-46E8-AF32-60F91929F02F@inertialbit.net>

On Apr 14, 2010, at 11:19 AM, Wall, Kevin wrote:

> Jeremiah Heller writes...
> 
>> do security professionals really want to wipe hacking
>> activity from the planet? sounds like poor job security to me.
> 
> Even though I've been involved in software security for the
> past dozen years or so, I still think this is a laudable goal,
> albeit a completely unrealistic one. I for one, would be completely
> happy to go back to software development / systems programming if
> all the security issues completely disappeared. But unfortunately,
> I don't think we ever have to worry about this happening.

Indeed, I'm in the happy position of developing with an eye on security. Without the excellent work done by the 'good hackers' (and 'bad' alike, come to that) I have no doubt my job would be much more difficult. My comment was more playful than thoughtful but it is an interesting paradox... for any job. Luckily there's a lot left to learn!

>> the drive for survival seems key. i think that when the
>> survival of many is perceived as threatened, then 'bad
>> hacking' will be addressed on a scale which will contain it
>> to the point that slavery is contained today... after all
>> don't hackers simply 'enslave' other computers? j/k
> 
> And of course, that is a good thing. After all, once the
> first sentient AI takes control of all the world's computers
> to subjugate all humanity, we have to have a way to fight back.
> Evil h4><0rs to the rescue! ;-)

Hmmm, maybe I should switch fields...

>> until then it seems that educating people on how these things
>> /work/ is the best strategy. eventually we will reach the
>> point where firewalls and trojan-hunting are as common as
>> changing your oil and painting a house.
> 
> I agree. Even though one risks ending up with smarter criminals,
> by and large if one addresses the poverty issues most people
> ultimately seem to make the right decisions in the best interests
> of society. I think for many, once their curiosity is satisfied
> and the novelty wears off they put these skills to good use. At
> least it seems to me a risk worth taking.

I agree that the risk of educating all is one worth taking. I like to think that objective education (if possible) would drive people over time to work toward ends that benefit society as a whole. At the same time it seems that this would ultimately require people to come from similar backgrounds/experiences or to at least draw similar conclusions from those, however varied. Perhaps a good thing but then could any thinking 'outside the box' really occur?

>> first we should probably unravel the electron... and perhaps
>> the biological effects of all of these radio waves bouncing
>> around our tiny globe... don't get me wrong, i like my
>> microwaves, they give me warm fuzzy feelings:)o
> 
> Jeremiah, you do know that you're not supposed to stick your *head*
> in the microwave, don't you? No wonder you're getting the warm
> fuzzies. :)

Ahh! That explains it! I suppose I should stop drooling over that warming cup of coffee:)

What I find interesting (as a commentary about human behavior) is that the microwave was inspired by early work on radar and yet we took this idea and applied it to all sorts of technologies and currently blanket the earth with a wide-spectrum of waves of which we barely understand the broader implications of; furthermore very little research (to my knowledge) has been done to explore any side-effects. Is it simply too profitable/beneficial an enterprise to consider the risks? It took over 100 years to consider that burning fossil-fuels might have some negative impacts, both to our immediate health and environment.

My dad related an interesting story to me recently about my grandfather who, while working at Boeing on a radar project, met a couple of radar techs who would keep their coffee warm by balancing it on the radar console between them. They also experienced what eventually became severe knee pain but each only in one knee and as they always sat in the same spot, it was in the knee next to the console. I'm not sure what the final diagnosis was but initially it was believed they were simply cooking their joints!

Something to consider as we sit typing/reading and bathe in our lovely wifi & cell networks (not to mention digital tv, which always seems to go on the fritz when I've got my head... er, coffee in the microwave:)

>From http://www.gallawa.com/microtech/history.html
==
Like many of today's great inventions, the microwave oven was a by-product of another technology. It was during a radar-related research project around 1946 that Dr. Percy Spencer, a self-taught engineer with the Raytheon Corporation, noticed  something very unusual.
...
==

Sorry to get off-topic like this, but at the same time general considerations about humanities' approach to risk management may have implications useful in the security field, who knows. Thanks for the fun discussion!

- jeremiah

From Kevin.Wall at qwest.com  Wed Apr 14 15:41:40 2010
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Wed, 14 Apr 2010 14:41:40 -0500
Subject: [SC-L] any one a CSSLP is it worth it?
In-Reply-To: <x2u212df5cd1004141158v2546e6e1k640712b6f37b067b@mail.gmail.com>
References: <027901cada72$e6a6abd0$b3f40370$@com>
	<C7EA0D70.206C3%gem@cigital.com>
	<B8E4274903E6F64E8F9E5C21A96D83BD341AF51CC7@qtomaexmbm22.AD.QINTRA.COM>
	<x2u212df5cd1004141158v2546e6e1k640712b6f37b067b@mail.gmail.com>
Message-ID: <B8E4274903E6F64E8F9E5C21A96D83BD341AF51CD9@qtomaexmbm22.AD.QINTRA.COM>

Dana Epp wrote:
> Not sure that would work either though.

Dana,

My comment was meant tongue-in-cheek. Guess I used the wrong
emoticon. Figured that ';-)' would work 'cuz I never can remember
the one for "tongue-in-cheek". I've seen several variations of the
latter...

        :-?     :-Q     :-J     -)

Take your pick. Good in depth analysis though. Seriously. And I
agree with you completely.

In my experience as an adjunct faculty member teaching a master's
level Computer Security course (based in part on the McGraw/Viega book
as well as Ross Anderson's _Security Engineering_) for 6 yrs, I came to the
conclusion that multiple guess (as I call them) alone only proves
how well someone memorizes something, at best, or how clueless people
are (if they get incorrect answers) at worst. I would argue that
most of academia it is unsuited for discerning cluefulness the the
real world. Over the course of 30+ yrs in IT (yes, I am an old fart!),
I've seen all too many people that exceled in academia but were miserable
disappointments in industry.  In fact, to that end, quality guru Demming
is rumored to have said about (then) AT&T Bell Labs:
        "Bell Labs only hires the top 10% of graduatesc...and they
        deserve what they get!"

There is no substitute for real experience.

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    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.


From mparsons1980 at gmail.com  Thu Apr 15 17:49:32 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Thu, 15 Apr 2010 16:49:32 -0500
Subject: [SC-L] What do you like better Web penetration testing or
	static code analysis?
Message-ID: <016901cadce5$898b4df0$9ca1e9d0$@com>

What do you like doing better as application security professionals, web
penetration testing or static code analysis?

 

I offered my thoughts in today's blog.   

 

http://parsonsisconsulting.blogspot.com/2010/04/what-do-you-like-better-secu
re-code.html

 

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

 <mailto:mparsons1980 at gmail.com> mailto:mparsons1980 at gmail.com

 <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com

 <http://www.o2-ounceopen.com/o2-power-users/>
http://www.o2-ounceopen.com/o2-power-users/

 <http://www.linkedin.com/in/parsonsconsulting>
http://www.linkedin.com/in/parsonsconsulting

 <http://parsonsisconsulting.blogspot.com/>
http://parsonsisconsulting.blogspot.com/

 <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100415/f9467e5c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100415/f9467e5c/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100415/f9467e5c/attachment-0001.jpeg>

From James.McGovern at thehartford.com  Fri Apr 16 10:15:15 2010
From: James.McGovern at thehartford.com (McGovern, James F. (P+C Technology))
Date: Fri, 16 Apr 2010 10:15:15 -0400
Subject: [SC-L] What do you like better Web penetration testing orstatic
	code analysis?
In-Reply-To: <016901cadce5$898b4df0$9ca1e9d0$@com>
References: <016901cadce5$898b4df0$9ca1e9d0$@com>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE287016BDF69@AD1HFDEXC312.ad1.prod>

Should a security professional have a preference when both have
different value propositions? While there is overlap, a static analysis
tool can find things that pen testing tools cannot. Likewise, a pen test
can report on secure applications deployed insecurely which is not
visible to static analysis.
 
So, the best answer is I prefer both...
 
http://twitter.com/mcgoverntheory

________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Matt Parsons
Sent: Thursday, April 15, 2010 5:50 PM
To: 'Matt Parsons'; SC-L at securecoding.org
Cc: webappsec at securityfocus.com; OWASPDallas at utdallas.edu; 'Webappsec
Group'
Subject: Re: [SC-L] What do you like better Web penetration testing
orstatic code analysis?



What do you like doing better as application security professionals, web
penetration testing or static code analysis?

 

I offered my thoughts in today's blog.   

 

http://parsonsisconsulting.blogspot.com/2010/04/what-do-you-like-better-
secure-code.html

 

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com <mailto:mparsons1980 at gmail.com> 

http://www.parsonsisconsulting.com <http://www.parsonsisconsulting.com> 

http://www.o2-ounceopen.com/o2-power-users/
<http://www.o2-ounceopen.com/o2-power-users/> 

http://www.linkedin.com/in/parsonsconsulting
<http://www.linkedin.com/in/parsonsconsulting> 

http://parsonsisconsulting.blogspot.com/
<http://parsonsisconsulting.blogspot.com/> 

http://www.vimeo.com/8939668 <http://www.vimeo.com/8939668> 

 

 

 

 

 

 

 

 

 

 

 

 

 

************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100416/9349402f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: image003.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100416/9349402f/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: image004.jpg
URL: <http://krvw.com/pipermail/sc-l/attachments/20100416/9349402f/attachment-0001.jpeg>

From jim.manico at owasp.org  Mon Apr 19 00:01:44 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Mon, 19 Apr 2010 00:01:44 -0400
Subject: [SC-L] Top Ten OWASP Podcast Series
Message-ID: <4BCBD5A8.1050905@owasp.org>

Hello SC-L,

We just released _*5 OWASP Podcasts*_ today in celebration of the 
release of the 2010 edition of the OWASP Top Ten! Big kudos to Dave 
Wichers and team for all of their hard working in making this release a 
success.

The Top Ten podcasts include:

Show 67: Jeff Williams on XSS Defense 
http://www.owasp.org/download/jmanico/owasp_podcast_67.mp3
Show 68: Kevin Keenan on Cryptographic Storage 
http://www.owasp.org/download/jmanico/owasp_podcast_68.mp3
Show 69: Eric Sheridan on CSRF Defense 
http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3
Show 70: Michael Coates on TLS Configuration 
http://www.owasp.org/download/jmanico/owasp_podcast_70.mp3
Show 71: Robert Hansen on Insecure Redirects 
http://www.owasp.org/download/jmanico/owasp_podcast_71.mp3

PS: You can subscribe to our RSS feed here: 
http://www.owasp.org/download/jmanico/podcast.xml
..or do the same via iTunes 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
..or see our show list on the web 
http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows

PPS: The OWASP Podcast Series is non-commercial podcast released under 
the Creative Commons/ShareAlike license.

PPPS: Did someone say "slow down" ? I missed that as I was running by... ;)

Thanks for listening!

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100419/eff2af92/attachment.htm>

From kevin.w.wall at gmail.com  Sun Apr 18 19:24:24 2010
From: kevin.w.wall at gmail.com (Kevin W. Wall)
Date: Sun, 18 Apr 2010 19:24:24 -0400
Subject: [SC-L] What do you like better Web penetration testing
 or	static code analysis?
In-Reply-To: <016901cadce5$898b4df0$9ca1e9d0$@com>
References: <016901cadce5$898b4df0$9ca1e9d0$@com>
Message-ID: <4BCB94A8.70607@gmail.com>

Matt Parsons wrote:
> What do you like doing better as application security professionals, web
> penetration testing or static code analysis?

McGovern, James F. (P+C Technology) wrote:
> Should a security professional have a preference when both have
> different value propositions? While there is overlap, a static analysis
> tool can find things that pen testing tools cannot. Likewise, a pen test
> can report on secure applications deployed insecurely which is not
> visible to static analysis.
>
> So, the best answer is I prefer both...

While I realize that both are necessary and each have their own
pros and cons, my personal preference is to do static code analysis,
especially if it involves old-fashioned manual code inspections.

The reason for that I like getting closer to the source code.
Maybe that's just because it seems like I'm getting back to
my development roots. (I worked as a developer for the first half
of my career.) I find the advantages of dealing with source code
is that you are able to spot the exact problem as well as offer
more specific fixes. And working at the source code level gives
me more opportunities to work closely with the development teams
where I am able to explain to them in terms of their own code what
is going on and how a vulnerability can be fixed.

When approaching vulnerabilities from a pen testing level, I find
all to often that the developers do not believe that there is anything
wrong or if they do, they don't believe that it is serious enough that
it needs to be fixed. (For instance, it is not uncommon that when
developers are presented with results from a pen test that show that
they have non-persistent (reflective) XSS vulnerabilities present,
that I get the response "Yeah, but that's not going to happen. First
you would have to get a authenticated user to click on that link and
they would never do that." Apparently they don't believe that those
doing phishing ever catch any victims.) However, when I'm dealing with
source code, that objection generally does not come up...perhaps
because I can show them right then and there how to remediate the
issue.

-kevin
-- 
Kevin W. Wall
"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

From mparsons1980 at gmail.com  Wed Apr 21 11:16:02 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Wed, 21 Apr 2010 10:16:02 -0500
Subject: [SC-L] I have not seen many people comment on the new OWASP top
	Ten What does every one think I blogged about it from my
	perspective. I am interested in hearing about other peoples
	experience with it
Message-ID: <02d601cae165$8f4dd670$ade98350$@com>

I have not seen many people comment on the new OWASP top Ten. What does
every one think. I blogged about it from my perspective.  I am interested in
hearing about other people's experience with it.   

 

http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-to-owasp-to
p-10-in.html

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

 <mailto:mparsons1980 at gmail.com> mailto:mparsons1980 at gmail.com

 <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com

 <http://www.o2-ounceopen.com/o2-power-users/>
http://www.o2-ounceopen.com/o2-power-users/

 <http://www.linkedin.com/in/parsonsconsulting>
http://www.linkedin.com/in/parsonsconsulting

 <http://parsonsisconsulting.blogspot.com/>
http://parsonsisconsulting.blogspot.com/

 <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668

 <http://twitter.com/parsonsmatt> http://twitter.com/parsonsmatt

 

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100421/3f6bb2f1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100421/3f6bb2f1/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100421/3f6bb2f1/attachment-0001.jpeg>

From robert at webappsec.org  Wed Apr 21 13:41:11 2010
From: robert at webappsec.org (robert at webappsec.org)
Date: Wed, 21 Apr 2010 13:41:11 -0400 (EDT)
Subject: [SC-L] [WEB SECURITY] RE: I have not seen many people comment
	on the new OWASP top Ten What does every one think I blogged
	about it fro
In-Reply-To: <02d601cae165$8f4dd670$ade98350$@com>
Message-ID: <20100421174111.70386.qmail@cgisecurity.net>

Hello Matt,

My only real concern is that the owasp top ten is now based on 'Risks' and has removed information/data disclosure/leakage.   
Speaking as someone who has worked in a risk management team, I see the leakage of customer/sensitive data as one of the most
serious "Risks" that exist for a company, and it is something that is happening more and more. I brought this to the attention 
of the Top Ten List back in November (see #5) https://lists.owasp.org/pipermail/owasp-topten/2009-November/000487.html and it 
wasn't really addressed. 

If the top ten was based on attacks and weaknesses (or just vulnerabilities) rather than 'risks' then I could see the argument 
for removal. Other than that, it is nice to see this document maturing/improving.

Regarding your comment on open redirects I've seen these many times in the real worldand they ARE being used by individuals 
to phish users. CSRF was used by the samy worm (not what I'd call a well organized motivated attacker as much as a Poc) in 
combination with xss so I'd say it is used by both audiences (the abuse case is really application/functionality specific). 


Regards,
- Robert A.
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com/


> 
> ------=_NextPart_000_02D7_01CAE13B.A677CE70
> Content-Type: multipart/alternative;
> 	boundary="----=_NextPart_001_02D8_01CAE13B.A677CE70"
> 
> 
> ------=_NextPart_001_02D8_01CAE13B.A677CE70
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> I have not seen many people comment on the new OWASP top Ten. What does
> every one think. I blogged about it from my perspective.  I am interested in
> hearing about other people's experience with it.   
> 
>  
> 
> http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-to-owasp-to
> p-10-in.html
> 
>  
> 
>  
> 
> Matt Parsons, MSM, CISSP
> 
> 315-559-3588 Blackberry
> 
> 817-294-3789 Home office 
> 
> "Do Good and Fear No Man"  
> 
> Fort Worth, Texas
> 
> A.K.A The Keyboard Cowboy
> 
>  <mailto:mparsons1980 at gmail.com> mailto:mparsons1980 at gmail.com
> 
>  <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com
> 
>  <http://www.o2-ounceopen.com/o2-power-users/>
> http://www.o2-ounceopen.com/o2-power-users/
> 
>  <http://www.linkedin.com/in/parsonsconsulting>
> http://www.linkedin.com/in/parsonsconsulting
> 
>  <http://parsonsisconsulting.blogspot.com/>
> http://parsonsisconsulting.blogspot.com/
> 
>  <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668
> 
>  <http://twitter.com/parsonsmatt> http://twitter.com/parsonsmatt
> 
>  
> 
>  
> 
> 0_0_0_0_250_281_csupload_6117291
> 
>  
> 
> untitled
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------=_NextPart_001_02D8_01CAE13B.A677CE70
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
> xmlns=3D"http://www.w3.org/TR/REC-html40">
> 
> <head>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
> <!--[if !mso]>
> <style>
> v\:* {behavior:url(#default#VML);}
> o\:* {behavior:url(#default#VML);}
> w\:* {behavior:url(#default#VML);}
> .shape {behavior:url(#default#VML);}
> </style>
> <![endif]-->
> <style>
> <!--
>  /* Font Definitions */
>  @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> 	{font-family:Tahoma;
> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> 	{mso-style-priority:99;
> 	mso-style-link:"Balloon Text Char";
> 	margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:8.0pt;
> 	font-family:"Tahoma","sans-serif";}
> span.BalloonTextChar
> 	{mso-style-name:"Balloon Text Char";
> 	mso-style-priority:99;
> 	mso-style-link:"Balloon Text";
> 	font-family:"Tahoma","sans-serif";}
> span.EmailStyle19
> 	{mso-style-type:personal;
> 	font-family:"Calibri","sans-serif";
> 	color:windowtext;}
> span.EmailStyle20
> 	{mso-style-type:personal-reply;
> 	font-family:"Calibri","sans-serif";
> 	color:#1F497D;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page Section1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.Section1
> 	{page:Section1;}
> -->
> </style>
> <!--[if gte mso 9]><xml>
>  <o:shapedefaults v:ext=3D"edit" spidmax=3D"3074" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
>  <o:shapelayout v:ext=3D"edit">
>   <o:idmap v:ext=3D"edit" data=3D"1" />
>  </o:shapelayout></xml><![endif]-->
> </head>
> 
> <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
> 
> <div class=3DSection1>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>I have not seen many =
> people
> comment on the new OWASP top Ten. What does every one think. I blogged =
> about it
> from my perspective.&nbsp; I am interested in hearing about other =
> people&#8217;s
> experience with it.&nbsp;&nbsp; <o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-=
> to-owasp-top-10-in.html">http://parsonsisconsulting.blogspot.com/2010/04/=
> parsons-response-to-owasp-top-10-in.html</a><o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <div>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Matt Parsons, MSM, =
> CISSP<o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>315-559-3588 =
> Blackberry<o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>817-294-3789 Home =
> office <o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>&quot;Do Good and =
> Fear No
> Man&quot;&nbsp; <o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Fort Worth, =
> Texas<o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'>A.K.A The Keyboard =
> Cowboy<o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"mailto:mparsons1980 at gmail.com"><span =
> style=3D'color:blue'>mailto:mparsons1980 at gmail.com</span></a><o:p></o:p><=
> /span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://www.parsonsisconsulting.com"><span =
> style=3D'color:blue'>http://www.parsonsisconsulting.com</span></a><o:p></=
> o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://www.o2-ounceopen.com/o2-power-users/"><span =
> style=3D'color:blue'>http://www.o2-ounceopen.com/o2-power-users/</span></=
> a><o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://www.linkedin.com/in/parsonsconsulting"><span =
> style=3D'color:blue'>http://www.linkedin.com/in/parsonsconsulting</span><=
> /a><o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://parsonsisconsulting.blogspot.com/"><span =
> style=3D'color:blue'>http://parsonsisconsulting.blogspot.com/</span></a><=
> o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://www.vimeo.com/8939668"><span =
> style=3D'color:blue'>http://www.vimeo.com/8939668</span></a><o:p></o:p></=
> span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> href=3D"http://twitter.com/parsonsmatt"><span =
> style=3D'color:blue'>http://twitter.com/parsonsmatt</span></a><o:p></o:p>=
> </span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><img border=3D0 =
> width=3D80
> height=3D90 id=3D"Picture_x0020_1" =
> src=3D"cid:image001.jpg at 01CAE13B.A4FF1120"
> alt=3D"0_0_0_0_250_281_csupload_6117291"><o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span style=3D'color:#1F497D'><img border=3D0 =
> width=3D75
> height=3D75 id=3D"Picture_x0020_2" =
> src=3D"cid:image002.jpg at 01CAE13B.A4FF1120"
> alt=3Duntitled><o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'>&nbsp;<o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'>&nbsp;<o:p></o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> 
> <p class=3DMsoNormal><span =
> style=3D'color:#1F497D'>&nbsp;</span><o:p></o:p></p>
> 
> </div>
> 
> <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
> 
> </div>
> 
> </body>
> 
> </html>
> 
> ------=_NextPart_001_02D8_01CAE13B.A677CE70--
> 
> ------=_NextPart_000_02D7_01CAE13B.A677CE70
> Content-Type: image/jpeg;
> 	name="image001.jpg"
> Content-Transfer-Encoding: base64
> Content-ID: <image001.jpg at 01CAE13B.A4FF1120>
> 
> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
> IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
> Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABaAFADASIA
> AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
> AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
> ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
> p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
> AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
> BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
> U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
> uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCbHNOA
> oxzTsADmsyhKrTalaW7FZJwGHUDJNV9Xv/s0XlRk+Y4/IVzixSStwckmkM6lNZsHOPtAH+8CKuxy
> LKoZGDKe6nNcqmjXEi7ghp6W9/prFo98Y745B+ooK5WdVg0FTWfp2sx3REMibZsdjw1aWT/c/Wgk
> jINJg5qQlv7n6035s/c/WmITbzSleKeF5pLj5YJGHUKTQM5a4zfajIRkrnH4VsWFhHb4bZuz+YrL
> 00fvGcjpzXQWzS4D/u0HbzD1qJM3pxW5dQArgrj8KgubcMhyuRVy3uFZcTFM+q1WvbjzD8sywxAY
> LEVFzosjlNQtnspxcQjBVg1dRbt59vHKOjqG/Osq/tme2fbJ5yEfe9K0dBQnRrbP90/zNaJnJUjZ
> ljZTSlWtlN2DNMyIlXmm3AUQPuOF2nNSqOaSWPzI2Q/xKRTYzn7GFbe6eP72CMVspaJK2+RA5689
> qzrcrJNCwxuA2t65FdDbrsjyw7VkztgkUGgZrtYwcZ5yaSK2LtJGyCRe6noanOyWctJgAHgZ5pYi
> sE+YyGQ/w56UjWyKksAijcBdoPUVb0uMJpsC+i/1p98A0RIGKktEKWkSnqFFVE5a9h5FMIqU0w1Z
> zECDmn4/eD6U1B8wqUD96v0NMDD1C3Sx1OKdMhZidw7Zret5VkgPfI4qnrdoLjTJD0aIb1P0rP0y
> +bYIZDhsZU+oqJI6KUjXtrZ4nZoZNgJycgGi5gkdlZ5NwUggBcU63mUnDvt9qS8mjVflck+lSdN1
> YZeOHCRjq3H51cxgYHQVgNdn7QknJSJtzY71vQyx3ECTRMGjkXcpHcVcVocdV3YhphqRhTDwaZkQ
> oPnH1qSR1jkVnYKu05JOAOlcVf8Aj2NMrp8BLZ+/L0/KuYvtbvtTkzc3Lyei5wB9BVpE3O917xZZ
> W9tJa2ji4mdSu5furn37motISO/sIwDhgBtPevOjKS3XgV1/hC8DRSQs3KnIrWFNS0D2jhqdUguI
> fklTfjvikdJ7o+XGu0HqavwX8RULcgDA/wBYen40XN6m3y7crt7uO/0qFQnzctjd1ocvNcx9R8qw
> s3GQRGpJNcdo/jK+0hjHhZ7YsT5Tn7ufQ9q1vFt6Y9O2Kcea+0e4HWuCkyGz61tUpqFoo5lUdR8z
> PT7T4gaTcYFxHNbE9yNy/mK3LXUbK/UNaXUUw9EbJ/LrXie4g0+K4kikDRuysDwVODWPKVcYXO4/
> WhXZScClwM9BTgBnoKsQgbJrd8MzbNSWMniUbfx7ViqB6CtLSABqduR/z1X+dXTdpImSujuxMy3s
> EdwSkbD5GycE9wcdP1rTuxifyxGEXaPu9CfWpLKON9XgDIrDzV6j/aWk2jfc8Di5cfhgVte1exjv
> TOC8azA30MAPEceSPcn/AOsK5ZuRiuh8WDOu3Gf9n/0EVhlRtPArOrrNmsPhK5yfwoA5FSEDI4FO
> 2jI4HWsij//Z
> 
> ------=_NextPart_000_02D7_01CAE13B.A677CE70
> Content-Type: image/jpeg;
> 	name="image002.jpg"
> Content-Transfer-Encoding: base64
> Content-ID: <image002.jpg at 01CAE13B.A4FF1120>
> 
> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
> IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
> Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABLAEsDASIA
> AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
> AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
> ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
> p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
> AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
> BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
> U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
> uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2Wmlh
> xzQ7ALknHua5tb+81rUkOn3DQxW8m2eJxtZCDzuGPmDDjHBHWgTLGoeIJI7pILKxlumDlH24yhUj
> cMeu07h2NRNpGsXtlGtzf7JlkkyVyBgnCsNpHI6gdOa3khRJHkSNVZ8bmA5OOmakHFAWMBvCsbz3
> jtdTbb2RXkA4wVbcMHt0pYtAvLSWy+zai/2e0ZiYnzmQMSSSc8nkYz7mt+igLHPJeajpMUa3yyXI
> IyzjGQzNhIw3APqSa17HUIL+1jniPDrnaeo5wf1BqaWGOZCkiK6MMFWGQR9KyTocFtq41RLhoESL
> bJGvAYDG0H0VRn5RxzQGqNqiqWm6pb6pbme3DhA5UF1xnB6j1FXaBmHr1zOTBaQIriV9siSRkpIp
> 6oWHCnHIzx71p2lrFawrFEG2gdWYsx9Mk8njjn0rH0d0utbv5VhvIHVyJPNfCSdlwn0HBroAMDFA
> lrqcR428b3/hjVILS0tbeVJYPMJl3ZByR2PtXO/8Lb1n/oH2X/j/APjTfi1/yMVp/wBeg/8AQjXC
> 1RzTnJSsjvP+Ft6z/wBA+x/8f/xo/wCFt6z/ANA+x/8AH/8AGuDoosR7SXc71PizrDSop0+ywzAf
> x+v1r1fAZee4r5uh/wBfH/vr/OvpIfdH0pNG9KTle5z99/xK9XtpYEuJTIPKjtoUVYkTqx6de/b0
> rfDZAI5FUdYH/Esmb9+Qo3Fbdtrv/sg+9V9Ku3g0yCF7C5jMa7QknzMAOBk9+MUjTYreF3jcTGK8
> urlcJzOQfLJBJTjuM810NQQSK0skaoy+WQCSuAxIzkHvU9A0eR/Fr/kYrP8A69B/6E1cLXefFdGk
> 8TWMaKWd7YKqjuS5wK5efS7C3nNo2qFrxGCMqwEx7s4Kh88455xjiqRyTV5My6K2rnw8lqI1e+xJ
> NO0MR8k+VkPtO58/K3fHpTh4ft/tN5E15cgWUYMo+xHzMlwuAueQc5B9KZPKzGh/18f++v8AOvpI
> fdH0r56vdOGmaj9ma5SSSOcIVCkEDgg89OvSvoVfuj6VLNqPUhvGVbOZnwFEbFs56Y9ufyrzyK7s
> 7ZPLbUbVzuJ3NDcOcEkjndyOeD6V6PKQEYnoBzxmq0MdrNCkkcUYRlBUGPBx24PSkbNEV7eyWjJi
> JBF1eaRsKo9Pr0xV2KRZY1dCGVhkMO4qO6tYrmILJGr7TuTcMgN2qlZXUlu6213MWkKqWyAAjH+E
> Y65PI9BQPqed/FVpU8TWEsSvuS2DKwXOCHOK5me/sp7hr06VcJdu/mNtmPlB85LBduefTOOa982o
> 4yyqfqKPLj/uL+VO5m6eu54Q2sQsl6Bp1wWvnJmQynyyC+7IXHDY4zmnS6/Itm9taW93F+4EKTNK
> TIo3h+WAHAxgCvdfKj/55r+VHlR/881/Ki4vZvufOUaStcxsUkYmQEkgknmvo8fdH0pvlRf880/I
> VWu75bb92pVpmH7uMnG49gT0GTxk0FQhyiXN8YnCRxeex4Ko43Ke2Qe1WwOOSKzdOtHeX7fdwxi5
> Zdm4Lhtvbd6HtxWngelIsWql7Yx3UbcBJSpUSqBvUH0PardFAzIiS8sI4beJFlUFY0DE/dAyzE9u
> egq9b3sMyylSVELFXLDABHXmrB6Gqt5FGLG4QKArI2QO+RzQIkS8t5NvlzRsGG4YYcj1pp1C1whW
> ZG3527TnOBz0rEv7WCHU4Yo4wqGAx7R/dIfP8utO0ALd2sV3OqvP50h34xghdv8AICgLlt9Va5jj
> +xoR58e+GRhkEg8qR247+9SW+n+cVnug+9trbC/Tvtb+8Ac49Kuw28NtFshjCLycD1qVeg+lAC0U
> UUDP/9k=
> 
> ------=_NextPart_000_02D7_01CAE13B.A677CE70--
> 


From jim.manico at owasp.org  Wed Apr 21 18:27:13 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Wed, 21 Apr 2010 15:27:13 -0700
Subject: [SC-L] [WEB SECURITY] RE: I have not seen many people comment
 on the new OWASP top Ten What does every one think I blogged about it fro
In-Reply-To: <20100421174111.70386.qmail@cgisecurity.net>
References: <20100421174111.70386.qmail@cgisecurity.net>
Message-ID: <4BCF7BC1.4010900@owasp.org>

My problem with WASC T2 is that it does not discuss remediation. Is this 
coming soon?

- Jim

> Hello Matt,
>
> My only real concern is that the owasp top ten is now based on 'Risks' and has removed information/data disclosure/leakage.
> Speaking as someone who has worked in a risk management team, I see the leakage of customer/sensitive data as one of the most
> serious "Risks" that exist for a company, and it is something that is happening more and more. I brought this to the attention
> of the Top Ten List back in November (see #5) https://lists.owasp.org/pipermail/owasp-topten/2009-November/000487.html and it
> wasn't really addressed.
>
> If the top ten was based on attacks and weaknesses (or just vulnerabilities) rather than 'risks' then I could see the argument
> for removal. Other than that, it is nice to see this document maturing/improving.
>
> Regarding your comment on open redirects I've seen these many times in the real worldand they ARE being used by individuals
> to phish users. CSRF was used by the samy worm (not what I'd call a well organized motivated attacker as much as a Poc) in
> combination with xss so I'd say it is used by both audiences (the abuse case is really application/functionality specific).
>
>
> Regards,
> - Robert A.
> http://www.webappsec.org/
> http://www.cgisecurity.com/
> http://www.qasec.com/
>
>
>    
>> ------=_NextPart_000_02D7_01CAE13B.A677CE70
>> Content-Type: multipart/alternative;
>> 	boundary="----=_NextPart_001_02D8_01CAE13B.A677CE70"
>>
>>
>> ------=_NextPart_001_02D8_01CAE13B.A677CE70
>> Content-Type: text/plain;
>> 	charset="us-ascii"
>> Content-Transfer-Encoding: 7bit
>>
>> I have not seen many people comment on the new OWASP top Ten. What does
>> every one think. I blogged about it from my perspective.  I am interested in
>> hearing about other people's experience with it.
>>
>>
>>
>> http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-to-owasp-to
>> p-10-in.html
>>
>>
>>
>>
>>
>> Matt Parsons, MSM, CISSP
>>
>> 315-559-3588 Blackberry
>>
>> 817-294-3789 Home office
>>
>> "Do Good and Fear No Man"
>>
>> Fort Worth, Texas
>>
>> A.K.A The Keyboard Cowboy
>>
>>   <mailto:mparsons1980 at gmail.com>  mailto:mparsons1980 at gmail.com
>>
>>   <http://www.parsonsisconsulting.com>  http://www.parsonsisconsulting.com
>>
>>   <http://www.o2-ounceopen.com/o2-power-users/>
>> http://www.o2-ounceopen.com/o2-power-users/
>>
>>   <http://www.linkedin.com/in/parsonsconsulting>
>> http://www.linkedin.com/in/parsonsconsulting
>>
>>   <http://parsonsisconsulting.blogspot.com/>
>> http://parsonsisconsulting.blogspot.com/
>>
>>   <http://www.vimeo.com/8939668>  http://www.vimeo.com/8939668
>>
>>   <http://twitter.com/parsonsmatt>  http://twitter.com/parsonsmatt
>>
>>
>>
>>
>>
>> 0_0_0_0_250_281_csupload_6117291
>>
>>
>>
>> untitled
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------=_NextPart_001_02D8_01CAE13B.A677CE70
>> Content-Type: text/html;
>> 	charset="us-ascii"
>> Content-Transfer-Encoding: quoted-printable
>>
>> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
>> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
>> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
>> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
>> xmlns=3D"http://www.w3.org/TR/REC-html40">
>>
>> <head>
>> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>> charset=3Dus-ascii">
>> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
>> <!--[if !mso]>
>> <style>
>> v\:* {behavior:url(#default#VML);}
>> o\:* {behavior:url(#default#VML);}
>> w\:* {behavior:url(#default#VML);}
>> .shape {behavior:url(#default#VML);}
>> </style>
>> <![endif]-->
>> <style>
>> <!--
>>   /* Font Definitions */
>>   @font-face
>> 	{font-family:Calibri;
>> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
>> @font-face
>> 	{font-family:Tahoma;
>> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
>>   /* Style Definitions */
>>   p.MsoNormal, li.MsoNormal, div.MsoNormal
>> 	{margin:0in;
>> 	margin-bottom:.0001pt;
>> 	font-size:11.0pt;
>> 	font-family:"Calibri","sans-serif";}
>> a:link, span.MsoHyperlink
>> 	{mso-style-priority:99;
>> 	color:blue;
>> 	text-decoration:underline;}
>> a:visited, span.MsoHyperlinkFollowed
>> 	{mso-style-priority:99;
>> 	color:purple;
>> 	text-decoration:underline;}
>> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
>> 	{mso-style-priority:99;
>> 	mso-style-link:"Balloon Text Char";
>> 	margin:0in;
>> 	margin-bottom:.0001pt;
>> 	font-size:8.0pt;
>> 	font-family:"Tahoma","sans-serif";}
>> span.BalloonTextChar
>> 	{mso-style-name:"Balloon Text Char";
>> 	mso-style-priority:99;
>> 	mso-style-link:"Balloon Text";
>> 	font-family:"Tahoma","sans-serif";}
>> span.EmailStyle19
>> 	{mso-style-type:personal;
>> 	font-family:"Calibri","sans-serif";
>> 	color:windowtext;}
>> span.EmailStyle20
>> 	{mso-style-type:personal-reply;
>> 	font-family:"Calibri","sans-serif";
>> 	color:#1F497D;}
>> .MsoChpDefault
>> 	{mso-style-type:export-only;
>> 	font-size:10.0pt;}
>> @page Section1
>> 	{size:8.5in 11.0in;
>> 	margin:1.0in 1.0in 1.0in 1.0in;}
>> div.Section1
>> 	{page:Section1;}
>> -->
>> </style>
>> <!--[if gte mso 9]><xml>
>>   <o:shapedefaults v:ext=3D"edit" spidmax=3D"3074" />
>> </xml><![endif]--><!--[if gte mso 9]><xml>
>>   <o:shapelayout v:ext=3D"edit">
>>    <o:idmap v:ext=3D"edit" data=3D"1" />
>>   </o:shapelayout></xml><![endif]-->
>> </head>
>>
>> <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
>>
>> <div class=3DSection1>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>I have not seen many =
>> people
>> comment on the new OWASP top Ten. What does every one think. I blogged =
>> about it
>> from my perspective.&nbsp; I am interested in hearing about other =
>> people&#8217;s
>> experience with it.&nbsp;&nbsp;<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-=
>> to-owasp-top-10-in.html">http://parsonsisconsulting.blogspot.com/2010/04/=
>> parsons-response-to-owasp-top-10-in.html</a><o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <div>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Matt Parsons, MSM, =
>> CISSP<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>315-559-3588 =
>> Blackberry<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>817-294-3789 Home =
>> office<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>&quot;Do Good and =
>> Fear No
>> Man&quot;&nbsp;<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Fort Worth, =
>> Texas<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'>A.K.A The Keyboard =
>> Cowboy<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"mailto:mparsons1980 at gmail.com"><span =
>> style=3D'color:blue'>mailto:mparsons1980 at gmail.com</span></a><o:p></o:p><=
>> /span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://www.parsonsisconsulting.com"><span =
>> style=3D'color:blue'>http://www.parsonsisconsulting.com</span></a><o:p></=
>> o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://www.o2-ounceopen.com/o2-power-users/"><span =
>> style=3D'color:blue'>http://www.o2-ounceopen.com/o2-power-users/</span></=
>> a><o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://www.linkedin.com/in/parsonsconsulting"><span =
>> style=3D'color:blue'>http://www.linkedin.com/in/parsonsconsulting</span><=
>> /a><o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://parsonsisconsulting.blogspot.com/"><span =
>> style=3D'color:blue'>http://parsonsisconsulting.blogspot.com/</span></a><=
>> o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://www.vimeo.com/8939668"><span =
>> style=3D'color:blue'>http://www.vimeo.com/8939668</span></a><o:p></o:p></=
>> span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
>> href=3D"http://twitter.com/parsonsmatt"><span =
>> style=3D'color:blue'>http://twitter.com/parsonsmatt</span></a><o:p></o:p>=
>> </span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><img border=3D0 =
>> width=3D80
>> height=3D90 id=3D"Picture_x0020_1" =
>> src=3D"cid:image001.jpg at 01CAE13B.A4FF1120"
>> alt=3D"0_0_0_0_250_281_csupload_6117291"><o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span style=3D'color:#1F497D'><img border=3D0 =
>> width=3D75
>> height=3D75 id=3D"Picture_x0020_2" =
>> src=3D"cid:image002.jpg at 01CAE13B.A4FF1120"
>> alt=3Duntitled><o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'>&nbsp;<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'>&nbsp;<o:p></o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>>
>> <p class=3DMsoNormal><span =
>> style=3D'color:#1F497D'>&nbsp;</span><o:p></o:p></p>
>>
>> </div>
>>
>> <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
>>
>> </div>
>>
>> </body>
>>
>> </html>
>>
>> ------=_NextPart_001_02D8_01CAE13B.A677CE70--
>>
>> ------=_NextPart_000_02D7_01CAE13B.A677CE70
>> Content-Type: image/jpeg;
>> 	name="image001.jpg"
>> Content-Transfer-Encoding: base64
>> Content-ID:<image001.jpg at 01CAE13B.A4FF1120>
>>
>> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
>> IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
>> Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABaAFADASIA
>> AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
>> AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
>> ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
>> p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
>> AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
>> BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
>> U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
>> uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCbHNOA
>> oxzTsADmsyhKrTalaW7FZJwGHUDJNV9Xv/s0XlRk+Y4/IVzixSStwckmkM6lNZsHOPtAH+8CKuxy
>> LKoZGDKe6nNcqmjXEi7ghp6W9/prFo98Y745B+ooK5WdVg0FTWfp2sx3REMibZsdjw1aWT/c/Wgk
>> jINJg5qQlv7n6035s/c/WmITbzSleKeF5pLj5YJGHUKTQM5a4zfajIRkrnH4VsWFhHb4bZuz+YrL
>> 00fvGcjpzXQWzS4D/u0HbzD1qJM3pxW5dQArgrj8KgubcMhyuRVy3uFZcTFM+q1WvbjzD8sywxAY
>> LEVFzosjlNQtnspxcQjBVg1dRbt59vHKOjqG/Osq/tme2fbJ5yEfe9K0dBQnRrbP90/zNaJnJUjZ
>> ljZTSlWtlN2DNMyIlXmm3AUQPuOF2nNSqOaSWPzI2Q/xKRTYzn7GFbe6eP72CMVspaJK2+RA5689
>> qzrcrJNCwxuA2t65FdDbrsjyw7VkztgkUGgZrtYwcZ5yaSK2LtJGyCRe6noanOyWctJgAHgZ5pYi
>> sE+YyGQ/w56UjWyKksAijcBdoPUVb0uMJpsC+i/1p98A0RIGKktEKWkSnqFFVE5a9h5FMIqU0w1Z
>> zECDmn4/eD6U1B8wqUD96v0NMDD1C3Sx1OKdMhZidw7Zret5VkgPfI4qnrdoLjTJD0aIb1P0rP0y
>> +bYIZDhsZU+oqJI6KUjXtrZ4nZoZNgJycgGi5gkdlZ5NwUggBcU63mUnDvt9qS8mjVflck+lSdN1
>> YZeOHCRjq3H51cxgYHQVgNdn7QknJSJtzY71vQyx3ECTRMGjkXcpHcVcVocdV3YhphqRhTDwaZkQ
>> oPnH1qSR1jkVnYKu05JOAOlcVf8Aj2NMrp8BLZ+/L0/KuYvtbvtTkzc3Lyei5wB9BVpE3O917xZZ
>> W9tJa2ji4mdSu5furn37motISO/sIwDhgBtPevOjKS3XgV1/hC8DRSQs3KnIrWFNS0D2jhqdUguI
>> fklTfjvikdJ7o+XGu0HqavwX8RULcgDA/wBYen40XN6m3y7crt7uO/0qFQnzctjd1ocvNcx9R8qw
>> s3GQRGpJNcdo/jK+0hjHhZ7YsT5Tn7ufQ9q1vFt6Y9O2Kcea+0e4HWuCkyGz61tUpqFoo5lUdR8z
>> PT7T4gaTcYFxHNbE9yNy/mK3LXUbK/UNaXUUw9EbJ/LrXie4g0+K4kikDRuysDwVODWPKVcYXO4/
>> WhXZScClwM9BTgBnoKsQgbJrd8MzbNSWMniUbfx7ViqB6CtLSABqduR/z1X+dXTdpImSujuxMy3s
>> EdwSkbD5GycE9wcdP1rTuxifyxGEXaPu9CfWpLKON9XgDIrDzV6j/aWk2jfc8Di5cfhgVte1exjv
>> TOC8azA30MAPEceSPcn/AOsK5ZuRiuh8WDOu3Gf9n/0EVhlRtPArOrrNmsPhK5yfwoA5FSEDI4FO
>> 2jI4HWsij//Z
>>
>> ------=_NextPart_000_02D7_01CAE13B.A677CE70
>> Content-Type: image/jpeg;
>> 	name="image002.jpg"
>> Content-Transfer-Encoding: base64
>> Content-ID:<image002.jpg at 01CAE13B.A4FF1120>
>>
>> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
>> IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
>> Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABLAEsDASIA
>> AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
>> AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
>> ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
>> p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
>> AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
>> BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
>> U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
>> uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2Wmlh
>> xzQ7ALknHua5tb+81rUkOn3DQxW8m2eJxtZCDzuGPmDDjHBHWgTLGoeIJI7pILKxlumDlH24yhUj
>> cMeu07h2NRNpGsXtlGtzf7JlkkyVyBgnCsNpHI6gdOa3khRJHkSNVZ8bmA5OOmakHFAWMBvCsbz3
>> jtdTbb2RXkA4wVbcMHt0pYtAvLSWy+zai/2e0ZiYnzmQMSSSc8nkYz7mt+igLHPJeajpMUa3yyXI
>> IyzjGQzNhIw3APqSa17HUIL+1jniPDrnaeo5wf1BqaWGOZCkiK6MMFWGQR9KyTocFtq41RLhoESL
>> bJGvAYDG0H0VRn5RxzQGqNqiqWm6pb6pbme3DhA5UF1xnB6j1FXaBmHr1zOTBaQIriV9siSRkpIp
>> 6oWHCnHIzx71p2lrFawrFEG2gdWYsx9Mk8njjn0rH0d0utbv5VhvIHVyJPNfCSdlwn0HBroAMDFA
>> lrqcR428b3/hjVILS0tbeVJYPMJl3ZByR2PtXO/8Lb1n/oH2X/j/APjTfi1/yMVp/wBeg/8AQjXC
>> 1RzTnJSsjvP+Ft6z/wBA+x/8f/xo/wCFt6z/ANA+x/8AH/8AGuDoosR7SXc71PizrDSop0+ywzAf
>> x+v1r1fAZee4r5uh/wBfH/vr/OvpIfdH0pNG9KTle5z99/xK9XtpYEuJTIPKjtoUVYkTqx6de/b0
>> rfDZAI5FUdYH/Esmb9+Qo3Fbdtrv/sg+9V9Ku3g0yCF7C5jMa7QknzMAOBk9+MUjTYreF3jcTGK8
>> urlcJzOQfLJBJTjuM810NQQSK0skaoy+WQCSuAxIzkHvU9A0eR/Fr/kYrP8A69B/6E1cLXefFdGk
>> 8TWMaKWd7YKqjuS5wK5efS7C3nNo2qFrxGCMqwEx7s4Kh88455xjiqRyTV5My6K2rnw8lqI1e+xJ
>> NO0MR8k+VkPtO58/K3fHpTh4ft/tN5E15cgWUYMo+xHzMlwuAueQc5B9KZPKzGh/18f++v8AOvpI
>> fdH0r56vdOGmaj9ma5SSSOcIVCkEDgg89OvSvoVfuj6VLNqPUhvGVbOZnwFEbFs56Y9ufyrzyK7s
>> 7ZPLbUbVzuJ3NDcOcEkjndyOeD6V6PKQEYnoBzxmq0MdrNCkkcUYRlBUGPBx24PSkbNEV7eyWjJi
>> JBF1eaRsKo9Pr0xV2KRZY1dCGVhkMO4qO6tYrmILJGr7TuTcMgN2qlZXUlu6213MWkKqWyAAjH+E
>> Y65PI9BQPqed/FVpU8TWEsSvuS2DKwXOCHOK5me/sp7hr06VcJdu/mNtmPlB85LBduefTOOa982o
>> 4yyqfqKPLj/uL+VO5m6eu54Q2sQsl6Bp1wWvnJmQynyyC+7IXHDY4zmnS6/Itm9taW93F+4EKTNK
>> TIo3h+WAHAxgCvdfKj/55r+VHlR/881/Ki4vZvufOUaStcxsUkYmQEkgknmvo8fdH0pvlRf880/I
>> VWu75bb92pVpmH7uMnG49gT0GTxk0FQhyiXN8YnCRxeex4Ko43Ke2Qe1WwOOSKzdOtHeX7fdwxi5
>> Zdm4Lhtvbd6HtxWngelIsWql7Yx3UbcBJSpUSqBvUH0PardFAzIiS8sI4beJFlUFY0DE/dAyzE9u
>> egq9b3sMyylSVELFXLDABHXmrB6Gqt5FGLG4QKArI2QO+RzQIkS8t5NvlzRsGG4YYcj1pp1C1whW
>> ZG3527TnOBz0rEv7WCHU4Yo4wqGAx7R/dIfP8utO0ALd2sV3OqvP50h34xghdv8AICgLlt9Va5jj
>> +xoR58e+GRhkEg8qR247+9SW+n+cVnug+9trbC/Tvtb+8Ac49Kuw28NtFshjCLycD1qVeg+lAC0U
>> UUDP/9k=
>>
>> ------=_NextPart_000_02D7_01CAE13B.A677CE70--
>>
>>      
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>    


-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net


From robert at webappsec.org  Wed Apr 21 20:43:13 2010
From: robert at webappsec.org (robert at webappsec.org)
Date: Wed, 21 Apr 2010 20:43:13 -0400 (EDT)
Subject: [SC-L] [WEB SECURITY] RE: I have not seen many people comment
In-Reply-To: <4BCF7BC1.4010900@owasp.org>
Message-ID: <20100422004313.16484.qmail@cgisecurity.net>

Jim,

The WASC Threat Classification v2 is a classification of attacks and weaknesses, not remediation's. This is      
stated in our definition. 

"The Threat Classification is an effort to classify the weaknesses, and attacks that can lead to the 
compromise of a website, its data, or its users."

I believe this thread was about constructive conversation on the owasp top ten, and the impact of using it in 
the real world, not about the WASC TCv2. However if you have specific suggestions please send them directly to 
me, or via the instructions within that document, we will listen to and evaluate *all* feedback once we kickoff 
the next update phase. 

Regards,
- Robert A.
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com/


> 
> My problem with WASC T2 is that it does not discuss remediation. Is this 
> coming soon?
> 
> - Jim
> 
> > Hello Matt,
> >
> > My only real concern is that the owasp top ten is now based on 'Risks' and has removed information/data disclosure/leakage.
> > Speaking as someone who has worked in a risk management team, I see the leakage of customer/sensitive data as one of the most
> > serious "Risks" that exist for a company, and it is something that is happening more and more. I brought this to the attention
> > of the Top Ten List back in November (see #5) https://lists.owasp.org/pipermail/owasp-topten/2009-November/000487.html and it
> > wasn't really addressed.
> >
> > If the top ten was based on attacks and weaknesses (or just vulnerabilities) rather than 'risks' then I could see the argument
> > for removal. Other than that, it is nice to see this document maturing/improving.
> >
> > Regarding your comment on open redirects I've seen these many times in the real worldand they ARE being used by individuals
> > to phish users. CSRF was used by the samy worm (not what I'd call a well organized motivated attacker as much as a Poc) in
> > combination with xss so I'd say it is used by both audiences (the abuse case is really application/functionality specific).
> >
> >
> > Regards,
> > - Robert A.
> > http://www.webappsec.org/
> > http://www.cgisecurity.com/
> > http://www.qasec.com/
> >
> >
> >    
> >> ------=_NextPart_000_02D7_01CAE13B.A677CE70
> >> Content-Type: multipart/alternative;
> >> 	boundary="----=_NextPart_001_02D8_01CAE13B.A677CE70"
> >>
> >>
> >> ------=_NextPart_001_02D8_01CAE13B.A677CE70
> >> Content-Type: text/plain;
> >> 	charset="us-ascii"
> >> Content-Transfer-Encoding: 7bit
> >>
> >> I have not seen many people comment on the new OWASP top Ten. What does
> >> every one think. I blogged about it from my perspective.  I am interested in
> >> hearing about other people's experience with it.
> >>
> >>
> >>
> >> http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-to-owasp-to
> >> p-10-in.html
> >>
> >>
> >>
> >>
> >>
> >> Matt Parsons, MSM, CISSP
> >>
> >> 315-559-3588 Blackberry
> >>
> >> 817-294-3789 Home office
> >>
> >> "Do Good and Fear No Man"
> >>
> >> Fort Worth, Texas
> >>
> >> A.K.A The Keyboard Cowboy
> >>
> >>   <mailto:mparsons1980 at gmail.com>  mailto:mparsons1980 at gmail.com
> >>
> >>   <http://www.parsonsisconsulting.com>  http://www.parsonsisconsulting.com
> >>
> >>   <http://www.o2-ounceopen.com/o2-power-users/>
> >> http://www.o2-ounceopen.com/o2-power-users/
> >>
> >>   <http://www.linkedin.com/in/parsonsconsulting>
> >> http://www.linkedin.com/in/parsonsconsulting
> >>
> >>   <http://parsonsisconsulting.blogspot.com/>
> >> http://parsonsisconsulting.blogspot.com/
> >>
> >>   <http://www.vimeo.com/8939668>  http://www.vimeo.com/8939668
> >>
> >>   <http://twitter.com/parsonsmatt>  http://twitter.com/parsonsmatt
> >>
> >>
> >>
> >>
> >>
> >> 0_0_0_0_250_281_csupload_6117291
> >>
> >>
> >>
> >> untitled
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ------=_NextPart_001_02D8_01CAE13B.A677CE70
> >> Content-Type: text/html;
> >> 	charset="us-ascii"
> >> Content-Transfer-Encoding: quoted-printable
> >>
> >> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
> >> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> >> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> >> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
> >> xmlns=3D"http://www.w3.org/TR/REC-html40">
> >>
> >> <head>
> >> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> >> charset=3Dus-ascii">
> >> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
> >> <!--[if !mso]>
> >> <style>
> >> v\:* {behavior:url(#default#VML);}
> >> o\:* {behavior:url(#default#VML);}
> >> w\:* {behavior:url(#default#VML);}
> >> .shape {behavior:url(#default#VML);}
> >> </style>
> >> <![endif]-->
> >> <style>
> >> <!--
> >>   /* Font Definitions */
> >>   @font-face
> >> 	{font-family:Calibri;
> >> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> >> @font-face
> >> 	{font-family:Tahoma;
> >> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
> >>   /* Style Definitions */
> >>   p.MsoNormal, li.MsoNormal, div.MsoNormal
> >> 	{margin:0in;
> >> 	margin-bottom:.0001pt;
> >> 	font-size:11.0pt;
> >> 	font-family:"Calibri","sans-serif";}
> >> a:link, span.MsoHyperlink
> >> 	{mso-style-priority:99;
> >> 	color:blue;
> >> 	text-decoration:underline;}
> >> a:visited, span.MsoHyperlinkFollowed
> >> 	{mso-style-priority:99;
> >> 	color:purple;
> >> 	text-decoration:underline;}
> >> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> >> 	{mso-style-priority:99;
> >> 	mso-style-link:"Balloon Text Char";
> >> 	margin:0in;
> >> 	margin-bottom:.0001pt;
> >> 	font-size:8.0pt;
> >> 	font-family:"Tahoma","sans-serif";}
> >> span.BalloonTextChar
> >> 	{mso-style-name:"Balloon Text Char";
> >> 	mso-style-priority:99;
> >> 	mso-style-link:"Balloon Text";
> >> 	font-family:"Tahoma","sans-serif";}
> >> span.EmailStyle19
> >> 	{mso-style-type:personal;
> >> 	font-family:"Calibri","sans-serif";
> >> 	color:windowtext;}
> >> span.EmailStyle20
> >> 	{mso-style-type:personal-reply;
> >> 	font-family:"Calibri","sans-serif";
> >> 	color:#1F497D;}
> >> .MsoChpDefault
> >> 	{mso-style-type:export-only;
> >> 	font-size:10.0pt;}
> >> @page Section1
> >> 	{size:8.5in 11.0in;
> >> 	margin:1.0in 1.0in 1.0in 1.0in;}
> >> div.Section1
> >> 	{page:Section1;}
> >> -->
> >> </style>
> >> <!--[if gte mso 9]><xml>
> >>   <o:shapedefaults v:ext=3D"edit" spidmax=3D"3074" />
> >> </xml><![endif]--><!--[if gte mso 9]><xml>
> >>   <o:shapelayout v:ext=3D"edit">
> >>    <o:idmap v:ext=3D"edit" data=3D"1" />
> >>   </o:shapelayout></xml><![endif]-->
> >> </head>
> >>
> >> <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
> >>
> >> <div class=3DSection1>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>I have not seen many =
> >> people
> >> comment on the new OWASP top Ten. What does every one think. I blogged =
> >> about it
> >> from my perspective.&nbsp; I am interested in hearing about other =
> >> people&#8217;s
> >> experience with it.&nbsp;&nbsp;<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-=
> >> to-owasp-top-10-in.html">http://parsonsisconsulting.blogspot.com/2010/04/=
> >> parsons-response-to-owasp-top-10-in.html</a><o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <div>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Matt Parsons, MSM, =
> >> CISSP<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>315-559-3588 =
> >> Blackberry<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>817-294-3789 Home =
> >> office<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>&quot;Do Good and =
> >> Fear No
> >> Man&quot;&nbsp;<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Fort Worth, =
> >> Texas<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'>A.K.A The Keyboard =
> >> Cowboy<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"mailto:mparsons1980 at gmail.com"><span =
> >> style=3D'color:blue'>mailto:mparsons1980 at gmail.com</span></a><o:p></o:p><=
> >> /span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://www.parsonsisconsulting.com"><span =
> >> style=3D'color:blue'>http://www.parsonsisconsulting.com</span></a><o:p></=
> >> o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://www.o2-ounceopen.com/o2-power-users/"><span =
> >> style=3D'color:blue'>http://www.o2-ounceopen.com/o2-power-users/</span></=
> >> a><o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://www.linkedin.com/in/parsonsconsulting"><span =
> >> style=3D'color:blue'>http://www.linkedin.com/in/parsonsconsulting</span><=
> >> /a><o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://parsonsisconsulting.blogspot.com/"><span =
> >> style=3D'color:blue'>http://parsonsisconsulting.blogspot.com/</span></a><=
> >> o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://www.vimeo.com/8939668"><span =
> >> style=3D'color:blue'>http://www.vimeo.com/8939668</span></a><o:p></o:p></=
> >> span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><a
> >> href=3D"http://twitter.com/parsonsmatt"><span =
> >> style=3D'color:blue'>http://twitter.com/parsonsmatt</span></a><o:p></o:p>=
> >> </span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><img border=3D0 =
> >> width=3D80
> >> height=3D90 id=3D"Picture_x0020_1" =
> >> src=3D"cid:image001.jpg at 01CAE13B.A4FF1120"
> >> alt=3D"0_0_0_0_250_281_csupload_6117291"><o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span style=3D'color:#1F497D'><img border=3D0 =
> >> width=3D75
> >> height=3D75 id=3D"Picture_x0020_2" =
> >> src=3D"cid:image002.jpg at 01CAE13B.A4FF1120"
> >> alt=3Duntitled><o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'>&nbsp;<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'>&nbsp;<o:p></o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>
> >>
> >> <p class=3DMsoNormal><span =
> >> style=3D'color:#1F497D'>&nbsp;</span><o:p></o:p></p>
> >>
> >> </div>
> >>
> >> <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
> >>
> >> </div>
> >>
> >> </body>
> >>
> >> </html>
> >>
> >> ------=_NextPart_001_02D8_01CAE13B.A677CE70--
> >>
> >> ------=_NextPart_000_02D7_01CAE13B.A677CE70
> >> Content-Type: image/jpeg;
> >> 	name="image001.jpg"
> >> Content-Transfer-Encoding: base64
> >> Content-ID:<image001.jpg at 01CAE13B.A4FF1120>
> >>
> >> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
> >> IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
> >> Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABaAFADASIA
> >> AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
> >> AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
> >> ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
> >> p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
> >> AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
> >> BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
> >> U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
> >> uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCbHNOA
> >> oxzTsADmsyhKrTalaW7FZJwGHUDJNV9Xv/s0XlRk+Y4/IVzixSStwckmkM6lNZsHOPtAH+8CKuxy
> >> LKoZGDKe6nNcqmjXEi7ghp6W9/prFo98Y745B+ooK5WdVg0FTWfp2sx3REMibZsdjw1aWT/c/Wgk
> >> jINJg5qQlv7n6035s/c/WmITbzSleKeF5pLj5YJGHUKTQM5a4zfajIRkrnH4VsWFhHb4bZuz+YrL
> >> 00fvGcjpzXQWzS4D/u0HbzD1qJM3pxW5dQArgrj8KgubcMhyuRVy3uFZcTFM+q1WvbjzD8sywxAY
> >> LEVFzosjlNQtnspxcQjBVg1dRbt59vHKOjqG/Osq/tme2fbJ5yEfe9K0dBQnRrbP90/zNaJnJUjZ
> >> ljZTSlWtlN2DNMyIlXmm3AUQPuOF2nNSqOaSWPzI2Q/xKRTYzn7GFbe6eP72CMVspaJK2+RA5689
> >> qzrcrJNCwxuA2t65FdDbrsjyw7VkztgkUGgZrtYwcZ5yaSK2LtJGyCRe6noanOyWctJgAHgZ5pYi
> >> sE+YyGQ/w56UjWyKksAijcBdoPUVb0uMJpsC+i/1p98A0RIGKktEKWkSnqFFVE5a9h5FMIqU0w1Z
> >> zECDmn4/eD6U1B8wqUD96v0NMDD1C3Sx1OKdMhZidw7Zret5VkgPfI4qnrdoLjTJD0aIb1P0rP0y
> >> +bYIZDhsZU+oqJI6KUjXtrZ4nZoZNgJycgGi5gkdlZ5NwUggBcU63mUnDvt9qS8mjVflck+lSdN1
> >> YZeOHCRjq3H51cxgYHQVgNdn7QknJSJtzY71vQyx3ECTRMGjkXcpHcVcVocdV3YhphqRhTDwaZkQ
> >> oPnH1qSR1jkVnYKu05JOAOlcVf8Aj2NMrp8BLZ+/L0/KuYvtbvtTkzc3Lyei5wB9BVpE3O917xZZ
> >> W9tJa2ji4mdSu5furn37motISO/sIwDhgBtPevOjKS3XgV1/hC8DRSQs3KnIrWFNS0D2jhqdUguI
> >> fklTfjvikdJ7o+XGu0HqavwX8RULcgDA/wBYen40XN6m3y7crt7uO/0qFQnzctjd1ocvNcx9R8qw
> >> s3GQRGpJNcdo/jK+0hjHhZ7YsT5Tn7ufQ9q1vFt6Y9O2Kcea+0e4HWuCkyGz61tUpqFoo5lUdR8z
> >> PT7T4gaTcYFxHNbE9yNy/mK3LXUbK/UNaXUUw9EbJ/LrXie4g0+K4kikDRuysDwVODWPKVcYXO4/
> >> WhXZScClwM9BTgBnoKsQgbJrd8MzbNSWMniUbfx7ViqB6CtLSABqduR/z1X+dXTdpImSujuxMy3s
> >> EdwSkbD5GycE9wcdP1rTuxifyxGEXaPu9CfWpLKON9XgDIrDzV6j/aWk2jfc8Di5cfhgVte1exjv
> >> TOC8azA30MAPEceSPcn/AOsK5ZuRiuh8WDOu3Gf9n/0EVhlRtPArOrrNmsPhK5yfwoA5FSEDI4FO
> >> 2jI4HWsij//Z
> >>
> >> ------=_NextPart_000_02D7_01CAE13B.A677CE70
> >> Content-Type: image/jpeg;
> >> 	name="image002.jpg"
> >> Content-Transfer-Encoding: base64
> >> Content-ID:<image002.jpg at 01CAE13B.A4FF1120>
> >>
> >> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
> >> IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
> >> Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABLAEsDASIA
> >> AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
> >> AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
> >> ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
> >> p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
> >> AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
> >> BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
> >> U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
> >> uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2Wmlh
> >> xzQ7ALknHua5tb+81rUkOn3DQxW8m2eJxtZCDzuGPmDDjHBHWgTLGoeIJI7pILKxlumDlH24yhUj
> >> cMeu07h2NRNpGsXtlGtzf7JlkkyVyBgnCsNpHI6gdOa3khRJHkSNVZ8bmA5OOmakHFAWMBvCsbz3
> >> jtdTbb2RXkA4wVbcMHt0pYtAvLSWy+zai/2e0ZiYnzmQMSSSc8nkYz7mt+igLHPJeajpMUa3yyXI
> >> IyzjGQzNhIw3APqSa17HUIL+1jniPDrnaeo5wf1BqaWGOZCkiK6MMFWGQR9KyTocFtq41RLhoESL
> >> bJGvAYDG0H0VRn5RxzQGqNqiqWm6pb6pbme3DhA5UF1xnB6j1FXaBmHr1zOTBaQIriV9siSRkpIp
> >> 6oWHCnHIzx71p2lrFawrFEG2gdWYsx9Mk8njjn0rH0d0utbv5VhvIHVyJPNfCSdlwn0HBroAMDFA
> >> lrqcR428b3/hjVILS0tbeVJYPMJl3ZByR2PtXO/8Lb1n/oH2X/j/APjTfi1/yMVp/wBeg/8AQjXC
> >> 1RzTnJSsjvP+Ft6z/wBA+x/8f/xo/wCFt6z/ANA+x/8AH/8AGuDoosR7SXc71PizrDSop0+ywzAf
> >> x+v1r1fAZee4r5uh/wBfH/vr/OvpIfdH0pNG9KTle5z99/xK9XtpYEuJTIPKjtoUVYkTqx6de/b0
> >> rfDZAI5FUdYH/Esmb9+Qo3Fbdtrv/sg+9V9Ku3g0yCF7C5jMa7QknzMAOBk9+MUjTYreF3jcTGK8
> >> urlcJzOQfLJBJTjuM810NQQSK0skaoy+WQCSuAxIzkHvU9A0eR/Fr/kYrP8A69B/6E1cLXefFdGk
> >> 8TWMaKWd7YKqjuS5wK5efS7C3nNo2qFrxGCMqwEx7s4Kh88455xjiqRyTV5My6K2rnw8lqI1e+xJ
> >> NO0MR8k+VkPtO58/K3fHpTh4ft/tN5E15cgWUYMo+xHzMlwuAueQc5B9KZPKzGh/18f++v8AOvpI
> >> fdH0r56vdOGmaj9ma5SSSOcIVCkEDgg89OvSvoVfuj6VLNqPUhvGVbOZnwFEbFs56Y9ufyrzyK7s
> >> 7ZPLbUbVzuJ3NDcOcEkjndyOeD6V6PKQEYnoBzxmq0MdrNCkkcUYRlBUGPBx24PSkbNEV7eyWjJi
> >> JBF1eaRsKo9Pr0xV2KRZY1dCGVhkMO4qO6tYrmILJGr7TuTcMgN2qlZXUlu6213MWkKqWyAAjH+E
> >> Y65PI9BQPqed/FVpU8TWEsSvuS2DKwXOCHOK5me/sp7hr06VcJdu/mNtmPlB85LBduefTOOa982o
> >> 4yyqfqKPLj/uL+VO5m6eu54Q2sQsl6Bp1wWvnJmQynyyC+7IXHDY4zmnS6/Itm9taW93F+4EKTNK
> >> TIo3h+WAHAxgCvdfKj/55r+VHlR/881/Ki4vZvufOUaStcxsUkYmQEkgknmvo8fdH0pvlRf880/I
> >> VWu75bb92pVpmH7uMnG49gT0GTxk0FQhyiXN8YnCRxeex4Ko43Ke2Qe1WwOOSKzdOtHeX7fdwxi5
> >> Zdm4Lhtvbd6HtxWngelIsWql7Yx3UbcBJSpUSqBvUH0PardFAzIiS8sI4beJFlUFY0DE/dAyzE9u
> >> egq9b3sMyylSVELFXLDABHXmrB6Gqt5FGLG4QKArI2QO+RzQIkS8t5NvlzRsGG4YYcj1pp1C1whW
> >> ZG3527TnOBz0rEv7WCHU4Yo4wqGAx7R/dIfP8utO0ALd2sV3OqvP50h34xghdv8AICgLlt9Va5jj
> >> +xoR58e+GRhkEg8qR247+9SW+n+cVnug+9trbC/Tvtb+8Ac49Kuw28NtFshjCLycD1qVeg+lAC0U
> >> UUDP/9k=
> >>
> >> ------=_NextPart_000_02D7_01CAE13B.A677CE70--
> >>
> >>      
> > _______________________________________________
> > Secure Coding mailing list (SC-L) SC-L at 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
> > _______________________________________________
> >    
> 
> 
> -- 
> Jim Manico
> OWASP Podcast Host/Producer
> OWASP ESAPI Project Manager
> http://www.manico.net
> 


From neumann at csl.sri.com  Thu Apr 22 13:57:51 2010
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Thu, 22 Apr 2010 10:57:51 PDT
Subject: [SC-L] What do you like better Web penetration testing or
 static code analysis?
In-Reply-To: Your message of Sun, 18 Apr 2010 19:24:24 -0400
Message-ID: <CMM.0.90.4.1271959071.neumann@chiron.csl.sri.com>


Matt Parsons wrote:
> What do you like doing better as application security professionals, web
> penetration testing or static code analysis?

McGovern, James F. (P+C Technology) wrote:
> Should a security professional have a preference when both have
> different value propositions? While there is overlap, a static analysis
> tool can find things that pen testing tools cannot. Likewise, a pen test
> can report on secure applications deployed insecurely which is not
> visible to static analysis.
>
> So, the best answer is I prefer both...

Both is better than either one by itself, but I think Gary McGraw
would resonate with my seemingly contrary answer:

  BOTH penetration testing AND static code analysis are still looking
  at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN.
  Gary and I and many others have for a very long time been advocated
  security architectures and development practices that greatly enhance
  INHERENT TRUSTWORTHINESS, long before anyone has to even think about
  penetration testing and static code analysis.  

  This discussion is somewhat akin to arguments about who has the best
  malware detection.  If system developers (past-Multics) had paid any
  attention to system architectures and sound system development 
  practices, viruses and worms would be mostly a nonproblem!

  Please pardon my soapbox.

    The past survives.
    The archives 
    have lives,
    not knives.
    High fives!

    (I strive
    to thrive
    with jive.)

PGN

From gem at cigital.com  Thu Apr 22 15:14:46 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 22 Apr 2010 15:14:46 -0400
Subject: [SC-L] What do you like better Web penetration testing or
 static code analysis?
In-Reply-To: <CMM.0.90.4.1271959071.neumann@chiron.csl.sri.com>
Message-ID: <C7F61867.20D27%gem@cigital.com>

I hereby resonate with my esteemed colleague and mentor pgn.  But no puns from me.

gem


On 4/22/10 1:57 PM, "Peter Neumann" <neumann at csl.sri.com> wrote:



Matt Parsons wrote:
> What do you like doing better as application security professionals, web
> penetration testing or static code analysis?

McGovern, James F. (P+C Technology) wrote:
> Should a security professional have a preference when both have
> different value propositions? While there is overlap, a static analysis
> tool can find things that pen testing tools cannot. Likewise, a pen test
> can report on secure applications deployed insecurely which is not
> visible to static analysis.
>
> So, the best answer is I prefer both...

Both is better than either one by itself, but I think Gary McGraw
would resonate with my seemingly contrary answer:

  BOTH penetration testing AND static code analysis are still looking
  at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN.
  Gary and I and many others have for a very long time been advocated
  security architectures and development practices that greatly enhance
  INHERENT TRUSTWORTHINESS, long before anyone has to even think about
  penetration testing and static code analysis.

  This discussion is somewhat akin to arguments about who has the best
  malware detection.  If system developers (past-Multics) had paid any
  attention to system architectures and sound system development
  practices, viruses and worms would be mostly a nonproblem!

  Please pardon my soapbox.

    The past survives.
    The archives
    have lives,
    not knives.
    High fives!

    (I strive
    to thrive
    with jive.)

PGN
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________



From fw at deneb.enyo.de  Thu Apr 22 16:25:45 2010
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 22 Apr 2010 22:25:45 +0200
Subject: [SC-L] has any one completed a python security code review`
In-Reply-To: <010f01cad4da$49a50130$dcef0390$@com> (Matt Parsons's message of
	"Mon, 5 Apr 2010 11:08:47 -0500")
References: <010f01cad4da$49a50130$dcef0390$@com>
Message-ID: <87k4rzw7xy.fsf@mid.deneb.enyo.de>

* Matt Parsons:

> Has anyone completed a python security code review?

I believe Google has, for their AppEngine product.

> What would you look for besides inputs, outputs and dangerous
> functions?

Does it involve mobile code? That would be quite a challenge.

There are also some historically insecure/risky APIs, such as pickling
and some DB-API versions.

From mparsons1980 at gmail.com  Fri Apr 23 10:05:03 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Fri, 23 Apr 2010 09:05:03 -0500
Subject: [SC-L] What do you like better Web penetration testing or
	static code analysis?
In-Reply-To: <C7F61867.20D27%gem@cigital.com>
References: <CMM.0.90.4.1271959071.neumann@chiron.csl.sri.com>
	<C7F61867.20D27%gem@cigital.com>
Message-ID: <01d101cae2ed$f92309b0$eb691d10$@com>

Gary,
I was not stating which was better for security.  I was stating what I
thought was more fun.   I feel that penetration testing is sexier.  I find
penetration testing like driving a Ferrari and static code analysis like
driving a Ford Taurus.   I believe with everyone else on this list that
software security needs to be integrated early in the development life
cycle.  I have also read most of your books and agree with your findings.
As you would say I don't think that penetration testing is magic security
pixie dust but it is fun when you are doing it legally and ethically.  My
two cents.
Matt


Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office 
"Do Good and Fear No Man"  
Fort Worth, Texas
A.K.A The Keyboard Cowboy
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/
http://www.vimeo.com/8939668
http://twitter.com/parsonsmatt







 
 

 

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Gary McGraw
Sent: Thursday, April 22, 2010 2:15 PM
To: Peter Neumann; Secure Code Mailing List
Subject: Re: [SC-L] What do you like better Web penetration testing or
static code analysis?

I hereby resonate with my esteemed colleague and mentor pgn.  But no puns
from me.

gem


On 4/22/10 1:57 PM, "Peter Neumann" <neumann at csl.sri.com> wrote:



Matt Parsons wrote:
> What do you like doing better as application security professionals, web
> penetration testing or static code analysis?

McGovern, James F. (P+C Technology) wrote:
> Should a security professional have a preference when both have
> different value propositions? While there is overlap, a static analysis
> tool can find things that pen testing tools cannot. Likewise, a pen test
> can report on secure applications deployed insecurely which is not
> visible to static analysis.
>
> So, the best answer is I prefer both...

Both is better than either one by itself, but I think Gary McGraw
would resonate with my seemingly contrary answer:

  BOTH penetration testing AND static code analysis are still looking
  at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN.
  Gary and I and many others have for a very long time been advocated
  security architectures and development practices that greatly enhance
  INHERENT TRUSTWORTHINESS, long before anyone has to even think about
  penetration testing and static code analysis.

  This discussion is somewhat akin to arguments about who has the best
  malware detection.  If system developers (past-Multics) had paid any
  attention to system architectures and sound system development
  practices, viruses and worms would be mostly a nonproblem!

  Please pardon my soapbox.

    The past survives.
    The archives
    have lives,
    not knives.
    High fives!

    (I strive
    to thrive
    with jive.)

PGN
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________


_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________


From cwysopal at veracode.com  Fri Apr 23 11:21:14 2010
From: cwysopal at veracode.com (Chris Wysopal)
Date: Fri, 23 Apr 2010 11:21:14 -0400
Subject: [SC-L] What do you like better Web penetration testing or
 static code analysis?
In-Reply-To: <C7F61867.20D27%gem@cigital.com>
References: <CMM.0.90.4.1271959071.neumann@chiron.csl.sri.com>
	<C7F61867.20D27%gem@cigital.com>
Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD024C6235F6@orbital.Veracode.local>


Most software security people that I talk to that advocate static analysis and pen testing see it as one part of the overall solution.  It is a part of the solution that software producers can get started on rather easily to open their eyes that they need secure architectures and better development practices.  

The biggest problem I face when dealing with our customers is the developers already think they have written secure code.  It is only after you demonstrate on their own code that they have exploitable vulnerabilities will anything be done to remedy the situation.  This is why static analysis and pen testing are an important part of driving software security to the masses of developers.

-Chris


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
Sent: Thursday, April 22, 2010 3:15 PM
To: Peter Neumann; Secure Code Mailing List
Subject: Re: [SC-L] What do you like better Web penetration testing or static code analysis?

I hereby resonate with my esteemed colleague and mentor pgn.  But no puns from me.

gem


On 4/22/10 1:57 PM, "Peter Neumann" <neumann at csl.sri.com> wrote:



Matt Parsons wrote:
> What do you like doing better as application security professionals, web
> penetration testing or static code analysis?

McGovern, James F. (P+C Technology) wrote:
> Should a security professional have a preference when both have
> different value propositions? While there is overlap, a static analysis
> tool can find things that pen testing tools cannot. Likewise, a pen test
> can report on secure applications deployed insecurely which is not
> visible to static analysis.
>
> So, the best answer is I prefer both...

Both is better than either one by itself, but I think Gary McGraw
would resonate with my seemingly contrary answer:

  BOTH penetration testing AND static code analysis are still looking
  at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN.
  Gary and I and many others have for a very long time been advocated
  security architectures and development practices that greatly enhance
  INHERENT TRUSTWORTHINESS, long before anyone has to even think about
  penetration testing and static code analysis.

  This discussion is somewhat akin to arguments about who has the best
  malware detection.  If system developers (past-Multics) had paid any
  attention to system architectures and sound system development
  practices, viruses and worms would be mostly a nonproblem!

  Please pardon my soapbox.

    The past survives.
    The archives
    have lives,
    not knives.
    High fives!

    (I strive
    to thrive
    with jive.)

PGN
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________


_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________


From brian at fortify.com  Fri Apr 23 14:08:06 2010
From: brian at fortify.com (Brian Chess)
Date: Fri, 23 Apr 2010 11:08:06 -0700
Subject: [SC-L] What do you like better Web penetration testing or
 static code analysis?
In-Reply-To: <01d101cae2ed$f92309b0$eb691d10$@com>
Message-ID: <C7F73016.2160D%brian@fortify.com>

I like your point Matt.  Everybody who's responded thus-far has wanted to
turn this into a discussion about what's most effective or what has the most
benefit, sort of like we were comparing which icky medicine to take or which
overcooked vegetable to eat.  Maybe they don't get any pleasure from the
work itself.

It sounds as though you need to change up your static analysis style.  A few
years back we ran competitions at BlackHat where we found we could identify
and exploit vulnerabilities starting from static analysis just as quickly as
from fuzzing.  Here?s an overview:
    
http://reddevnews.com/Blogs/Desmond-File/2008/08/Iron-Chef-Competition-at-Bl
ack-Hat-Cooks-Up-Security-Goodness.aspx

Interviews with Charlie Miller and Sean Fay:
http://blog.fortify.com/blog/2009/05/02/Iron-Chef-Interviews-Part-1-Charlie-
Miller-1-2    
http://blog.fortify.com/blog/2009/05/02/Iron-Chef-Interviews-Part-2-Sean-Fay

Brian

On 4/23/10 7:05 AM, "Matt Parsons" <mparsons1980 at gmail.com> wrote:

> Gary,
> I was not stating which was better for security.  I was stating what I
> thought was more fun.   I feel that penetration testing is sexier.  I find
> penetration testing like driving a Ferrari and static code analysis like
> driving a Ford Taurus.   I believe with everyone else on this list that
> software security needs to be integrated early in the development life
> cycle.  I have also read most of your books and agree with your findings.
> As you would say I don't think that penetration testing is magic security
> pixie dust but it is fun when you are doing it legally and ethically.  My
> two cents.
> Matt
> 
> 
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> "Do Good and Fear No Man"
> Fort Worth, Texas
> A.K.A The Keyboard Cowboy
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> http://parsonsisconsulting.blogspot.com/
> http://www.vimeo.com/8939668
> http://twitter.com/parsonsmatt
> 
> 
> 
> 
> 
> 
> 
>  
>  
> 
>  
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Gary McGraw
> Sent: Thursday, April 22, 2010 2:15 PM
> To: Peter Neumann; Secure Code Mailing List
> Subject: Re: [SC-L] What do you like better Web penetration testing or
> static code analysis?
> 
> I hereby resonate with my esteemed colleague and mentor pgn.  But no puns
> from me.
> 
> gem
> 
> 
> On 4/22/10 1:57 PM, "Peter Neumann" <neumann at csl.sri.com> wrote:
> 
> 
> 
> Matt Parsons wrote:
>> What do you like doing better as application security professionals, web
>> penetration testing or static code analysis?
> 
> McGovern, James F. (P+C Technology) wrote:
>> Should a security professional have a preference when both have
>> different value propositions? While there is overlap, a static analysis
>> tool can find things that pen testing tools cannot. Likewise, a pen test
>> can report on secure applications deployed insecurely which is not
>> visible to static analysis.
>> 
>> So, the best answer is I prefer both...
> 
> Both is better than either one by itself, but I think Gary McGraw
> would resonate with my seemingly contrary answer:
> 
>   BOTH penetration testing AND static code analysis are still looking
>   at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN.
>   Gary and I and many others have for a very long time been advocated
>   security architectures and development practices that greatly enhance
>   INHERENT TRUSTWORTHINESS, long before anyone has to even think about
>   penetration testing and static code analysis.
> 
>   This discussion is somewhat akin to arguments about who has the best
>   malware detection.  If system developers (past-Multics) had paid any
>   attention to system architectures and sound system development
>   practices, viruses and worms would be mostly a nonproblem!
> 
>   Please pardon my soapbox.
> 
>     The past survives.
>     The archives
>     have lives,
>     not knives.
>     High fives!
> 
>     (I strive
>     to thrive
>     with jive.)
> 
> PGN
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________



From kevin.w.wall at gmail.com  Sat Apr 24 12:54:31 2010
From: kevin.w.wall at gmail.com (Kevin W. Wall)
Date: Sat, 24 Apr 2010 12:54:31 -0400
Subject: [SC-L] What do you like better Web penetration testing or
 static code analysis?
In-Reply-To: <C7F73016.2160D%brian@fortify.com>
References: <C7F73016.2160D%brian@fortify.com>
Message-ID: <4BD32247.2010102@gmail.com>

Brian Chess wrote:
> I like your point Matt.  Everybody who's responded thus-far has wanted to
> turn this into a discussion about what's most effective or what has the most
> benefit, sort of like we were comparing which icky medicine to take or which
> overcooked vegetable to eat.  Maybe they don't get any pleasure from the
> work itself.

I take exception to that use of "everybody". My response was based solely
on my *preference*, which is what my understanding of Matt was originally
asking. But SC-L being the mailing list of many tangents, well...

And again, for the record, I *enjoy* both pen testing and static code
analysis, but I _personally_ prefer doing static code analysis, if no
other reason that generally allows me to work closer to the development
teams where I can better suggest appropriate mitigation.

Of course, my post (at least the original one) wasn't controversial enough
to stir up the pot and cause it to go off in some other direction, so it
may have flew past you under the radar. Not that that matters. OTOH, I
don't want to be lumped into the "everybody" category especially when
that list includes those who can't follow simple directions. ;-)

Regards,
-kevin
-- 
Kevin W. Wall
"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

From arian.evans at anachronic.com  Sat Apr 24 22:33:48 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Sat, 24 Apr 2010 19:33:48 -0700
Subject: [SC-L] What do you like better Web penetration testing or
	static code analysis?
In-Reply-To: <C7F73016.2160D%brian@fortify.com>
References: <01d101cae2ed$f92309b0$eb691d10$@com>
	<C7F73016.2160D%brian@fortify.com>
Message-ID: <p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>

The world of web software is the future and the future is a wild
open-ended place by design. I for one would like to keep it that way.

You guys that write a lot of ideological software SDL-theory books can
keep your dinosaur Multics.

About 4 years ago I shifted my focus away from static analysis to
focus entirely on black box testing, not out of sexiness or
"fun-factor", but because:


1) Software security needs to become operationalized, independent of
any discussions about SDL.

I think in many cases you need SDL and operational controls, but at a
minimum you need operational controls. I believe automated BB analysis
is one of the only ways to accomplish operationalizing software
security. I'm working with almost 1800 websites right now which
requires me to look at the problem intimately at full scale.


2) Secondly I think BB helps answer the question "What are my top
trivially-exploitable threats in my web software?" reasonably well. BB
alone can provide better answers to this question than many forms of
static analysis alone can provide.

Sorry, I know a lot of you on this list disagree with #2, but you're
wrong. Real-world compromises to web software completely validate #2.

Luckily, you don't have to chose one versus the other.

BB and static analysis fit together hand in glove, and obviously some
of us on this list are working to explore the best marriage of the
two. I think we will be able to really dial in the efficiency of
analysis efforts once we have a clearer understanding of where BB and
static overlap, and where they don't.

Just to be clear- there are absolutely many times doing BB-only
analysis where I would love to have access to source.

Static analysis can be so much faster and more effective at verifing
certain classes of defects in source (mostly syntax
injection/manipulation issues, and some plain vanilla auth issues),
especially once you already know what you are looking for. Which again
speaks to the value of hybrid solutions.

---

Finally - to add to Kevin's point - I have seen situations on where
developers respond much more positively to talking to someone who can
read and explain their code. In fact, I just spent this week on the
road having to talk to developers and look at source code for this
very reason. (Their lack of understanding of BB analysis/results.)

Developers really like to talk to other developers, and not some
hotshot pen-tester with crazy hair and earrings that is full of Way
Cool Exploits and has no real idea how software development happens.

Unfortunately, in the information-security industry, there are far
more Way Cool Exploit Dudes than there are professionals with a
background in software development. It is what it is.

Human_Hand_Driven(BB + Static + Developer Interpretation)==Great Combo Answer

---
Arian Evans



On Fri, Apr 23, 2010 at 11:08 AM, Brian Chess <brian at fortify.com> wrote:
> I like your point Matt. ?Everybody who's responded thus-far has wanted to
> turn this into a discussion about what's most effective or what has the most
> benefit, sort of like we were comparing which icky medicine to take or which
> overcooked vegetable to eat. ?Maybe they don't get any pleasure from the
> work itself.
>
> It sounds as though you need to change up your static analysis style. ?A few
> years back we ran competitions at BlackHat where we found we could identify
> and exploit vulnerabilities starting from static analysis just as quickly as
> from fuzzing. ?Here?s an overview:
>
> http://reddevnews.com/Blogs/Desmond-File/2008/08/Iron-Chef-Competition-at-Bl
> ack-Hat-Cooks-Up-Security-Goodness.aspx
>
> Interviews with Charlie Miller and Sean Fay:
> http://blog.fortify.com/blog/2009/05/02/Iron-Chef-Interviews-Part-1-Charlie-
> Miller-1-2
> http://blog.fortify.com/blog/2009/05/02/Iron-Chef-Interviews-Part-2-Sean-Fay
>
> Brian
>
> On 4/23/10 7:05 AM, "Matt Parsons" <mparsons1980 at gmail.com> wrote:
>
>> Gary,
>> I was not stating which was better for security. ?I was stating what I
>> thought was more fun. ? I feel that penetration testing is sexier. ?I find
>> penetration testing like driving a Ferrari and static code analysis like
>> driving a Ford Taurus. ? I believe with everyone else on this list that
>> software security needs to be integrated early in the development life
>> cycle. ?I have also read most of your books and agree with your findings.
>> As you would say I don't think that penetration testing is magic security
>> pixie dust but it is fun when you are doing it legally and ethically. ?My
>> two cents.
>> Matt
>>
>>
>> Matt Parsons, MSM, CISSP
>> 315-559-3588 Blackberry
>> 817-294-3789 Home office
>> "Do Good and Fear No Man"
>> Fort Worth, Texas
>> A.K.A The Keyboard Cowboy
>> mailto:mparsons1980 at gmail.com
>> http://www.parsonsisconsulting.com
>> http://www.o2-ounceopen.com/o2-power-users/
>> http://www.linkedin.com/in/parsonsconsulting
>> http://parsonsisconsulting.blogspot.com/
>> http://www.vimeo.com/8939668
>> http://twitter.com/parsonsmatt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
>> On Behalf Of Gary McGraw
>> Sent: Thursday, April 22, 2010 2:15 PM
>> To: Peter Neumann; Secure Code Mailing List
>> Subject: Re: [SC-L] What do you like better Web penetration testing or
>> static code analysis?
>>
>> I hereby resonate with my esteemed colleague and mentor pgn. ?But no puns
>> from me.
>>
>> gem
>>
>>
>> On 4/22/10 1:57 PM, "Peter Neumann" <neumann at csl.sri.com> wrote:
>>
>>
>>
>> Matt Parsons wrote:
>>> What do you like doing better as application security professionals, web
>>> penetration testing or static code analysis?
>>
>> McGovern, James F. (P+C Technology) wrote:
>>> Should a security professional have a preference when both have
>>> different value propositions? While there is overlap, a static analysis
>>> tool can find things that pen testing tools cannot. Likewise, a pen test
>>> can report on secure applications deployed insecurely which is not
>>> visible to static analysis.
>>>
>>> So, the best answer is I prefer both...
>>
>> Both is better than either one by itself, but I think Gary McGraw
>> would resonate with my seemingly contrary answer:
>>
>> ? BOTH penetration testing AND static code analysis are still looking
>> ? at the WRONG END of the horse AFTER it has left the DEVELOPMENT BARN.
>> ? Gary and I and many others have for a very long time been advocated
>> ? security architectures and development practices that greatly enhance
>> ? INHERENT TRUSTWORTHINESS, long before anyone has to even think about
>> ? penetration testing and static code analysis.
>>
>> ? This discussion is somewhat akin to arguments about who has the best
>> ? malware detection. ?If system developers (past-Multics) had paid any
>> ? attention to system architectures and sound system development
>> ? practices, viruses and worms would be mostly a nonproblem!
>>
>> ? Please pardon my soapbox.
>>
>> ? ? The past survives.
>> ? ? The archives
>> ? ? have lives,
>> ? ? not knives.
>> ? ? High fives!
>>
>> ? ? (I strive
>> ? ? to thrive
>> ? ? with jive.)
>>
>> PGN
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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
>> _______________________________________________
>>
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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
>> _______________________________________________
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L at 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
>> _______________________________________________
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>


From arian.evans at anachronic.com  Tue Apr 27 12:52:55 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 27 Apr 2010 09:52:55 -0700
Subject: [SC-L] [WEB SECURITY] Re: What do you like better Web
	penetration testing or static code analysis?
In-Reply-To: <k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>
References: <01d101cae2ed$f92309b0$eb691d10$@com>
	<C7F73016.2160D%brian@fortify.com>
	<p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>
	<k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>
Message-ID: <o2qcd1bdfdd1004270952m163b072di523bffd2b8df0213@mail.gmail.com>

So to be clear -

You are saying that you do all of the below when you are analyzing
hundreds to thousands of websites to help your customers identify
weaknesses that hackers could exploit?

How do you find the time?

---
Arian Evans



On Mon, Apr 26, 2010 at 10:54 PM, Andre Gironda <andreg at gmail.com> wrote:
> On Sat, Apr 24, 2010 at 9:33 PM, Arian J. Evans
> <arian.evans at anachronic.com> wrote:
>> You guys that write a lot of ideological software SDL-theory books can
>> keep your dinosaur Multics.
>
> Nobody wants to go back to / can go back to the TCSEC/Orange-Book
> formal methods days. We can't go back to the 4GL/CASE days. We can't
> go back to the Clean Room Development days. Most can't even go back to
> the OOA&D or Software Contracts days. Even the xP TDD days are long
> gone, and haven't been replaced by BDD or anything worthwhile. Try
> measuring cyclomatic complexity and applying it to security
> testing/inspection.
>
> You are right, the Multics days are gone. But so should be C/C++/Assembler.
>
> If we wanted to go down these paths than the importance of certain
> kinds of what you people call "static analysis tools" would be more
> about things like:
> 1) Hoare Logics (e.g. Klocwork)
> 2) Abstraction Interpretation (e.g. Coverity)
>
> but instead what we have right know are crappy satisfiability solvers
> (e.g. Insure++ or worse, Valgrind plugins that cause things like
> Debian openssl Epic-Fail) combined with abstract-syntax trees (e.g.
> Fortify and Ounce). If you want to specify custom development around
> the crappy static analysis tools we have today i.e. Slicing (e.g.
> Checkmarx and testablesa) or focus on elaborate CFG development (e.g.
> SciTools and GrammaTech) -- then we might realize that it's not
> Fortify vs. everybody but instead there is a lot to learn from all of
> these tools.
>
> Instead, we have tools like CAT.NET which dwarf Fortify (for what it
> does and sets out to do) -- but realize that the engine in both should
> be around 30 LOC because it's NOT THAT COMPLEX. Also meaning that it
> shouldn't cost 50-60K USD per year for a single audit license, but
> instead should be a free toy.
>
> And you can see why people call this stuff "source code scanning",
> because it's really not that much beyond RATS or Graudit in the same
> way that grep or PCRE get the job done almost as well as XPath (or XML
> stream parsers) if you scale is small and you don't understand the
> internals.
>
>> BB and static analysis fit together hand in glove, and obviously some
>> of us on this list are working to explore the best marriage of the
>> two. I think we will be able to really dial in the efficiency of
>> analysis efforts once we have a clearer understanding of where BB and
>> static overlap, and where they don't.
>
> More like "hand and NES Power-Glove".
>
> We still need workflow and people. Metasploit is doing WMAP and a
> commercial product, Express. Dradis Framework is including Burp Suite
> Professional Scanner output, in addition to Nessus/Nikto. Qualys is
> combining their QG data and feeding their WAS product. HoneyApps is
> combining tool output from Sentinel XML API, Nessus, Hailstorm, Qualys
> WAS, and other sources. Dan Cornell of The Denim Group is working on a
> Vulnerability Manager that takes output from Fortify, Ounce, CAT.NET,
> Sentinel XML API, AppScan, FindBugs, and Burp Suite Professional
> Scanner. The HP AMP has an open API and obviously Rafal Los and Matt
> Wood are keeping quiet about the SOURCEconference announcement that
> they are about to do a lot more than Hybrid 2.0 intended. Certainly,
> mapping URLs to source code is much easier than knowing several tens
> of language+platforms+frameworks with Fortify PTA and WebInspect (or
> potentially Acunetix WVS and Acusensor, but not quite in the same way
> or to the same effect).
>
> Other ideas like DevInspect and SecureObjects are now dead. Will they
> rise from the grave?
>
> Getting people is key though. Very key. We need more
> penetration-testers that can read code (or is it vice versa?) and only
> people like Dan Guido or Billy Rios are going to make that happen.
>
> If you are going to do anything or BUY anything -- definitely put a
> copy of "Code Reading: The Open-Source Perspective" and "The Web
> Application Hacker's Handbook" on everybody's desk and maybe place a
> few key copies of "The Art of Software Security Assessment" on desks
> of people who are doing well with the first two. And then buy
> everybody a copy of Burp Suite Professional and Metasploit Express
> long before you go for the shelfware that is Hybrid 2.0 (or any app or
> source code scanner).
>
> Peace,
> Andre
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

From arian.evans at anachronic.com  Tue Apr 27 17:02:22 2010
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 27 Apr 2010 14:02:22 -0700
Subject: [SC-L] [WEB SECURITY] Re: What do you like better Web
	penetration testing or static code analysis?
In-Reply-To: <z2o2fd9390e1004271252t30bcf4f4w8dbe029ce7833281@mail.gmail.com>
References: <01d101cae2ed$f92309b0$eb691d10$@com>
	<C7F73016.2160D%brian@fortify.com>
	<p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>
	<k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>
	<o2qcd1bdfdd1004270952m163b072di523bffd2b8df0213@mail.gmail.com>
	<z2o2fd9390e1004271252t30bcf4f4w8dbe029ce7833281@mail.gmail.com>
Message-ID: <z2pcd1bdfdd1004271402h7bff053cz86a7a1411f4e5b0c@mail.gmail.com>

So - Just to make sure I understand - You are saying you don't
actually perform all of these activities for clients to help them
secure their web software today?

I think that will be a relief to some on the list. I know a few people
called me concerned that they were never going to have time to sleep
again with all that to do!

Overall you do make interesting points with your ideas. I definitely
agree with your assertion that automation alone has significant
limitations.

This is definitely the right forum to bounce around your ideas about
what types of "security/secure/coding/analysis" activities may work,
what activities we might want to try out, and what the best books to
read are, to help us figure out how to secure the bazillions of web
applications that exist today.

Ciao,

---
Arian Evans



On Tue, Apr 27, 2010 at 12:52 PM, Andre Gironda <andreg at gmail.com> wrote:
> On Tue, Apr 27, 2010 at 11:52 AM, Arian J. Evans
> <arian.evans at anachronic.com> wrote:
>> So to be clear -
>>
>> You are saying that you do all of the below when you are analyzing
>> hundreds to thousands of websites to help your customers identify
>> weaknesses that hackers could exploit?
>>
>> How do you find the time?
>
> Not me personally, but the industry as a whole does provide most of
> these types of coverage. Everyone sees it a different way, and
> probably everybody is right.
>
> What I do find incorrect and wrong is assuming that you can automate
> anything (especially risk and vulnerability decisions -- is this a
> vuln; is this a risk).
>
> What I also find wrong is that the tools which attempt to automate
> finding vulnerabilities and assigning risk (but can't deliver on
> either) cost $60k/assessor for a code scan or $2k/app for a runtime
> scan.
>
> A "team" (doesn't have to be security people, but should probably
> include at least one) should instead use a free tool such as
> Netsparker Community Edition, crawl a target app through a few proxies
> (a few crawl runs) such as Burp Suite Professional, Casaba Watcher,
> and Google Ratproxy -- do a few other things such as track actions a
> browser would take (in XPath expression format) and plot a graph of
> dynamic-page/HTML/CSS/JS/SWF/form/parameter/etc objects (to show the
> complexity of the target app) -- and provide a data corpus (not just a
> database or list of findings) to allow the reviewers to make more
> informed decisions about what has been testing, what should be tested,
> and what will provide the most value. Combine the results with
> FindBugs, CAT.NET, VS PREfix/PREfast, cppcheck, or other static
> analysis-like reports in order to generate more value in making
> informed decisions. Perhaps cross-correlate and maps URLS to source
> code.
>
> I call this "Peripheral Security Testing". Then, if time allows (or
> the risk to the target app is seen as great enough), add in a
> threat-model and allow the "team" to perform penetration-testing based
> on those informed decisions. I call this latter part, "Adversarial
> Security Testing".
>
> Does manual testing take more time, or does it instead find the right
> things and allow the "team" to make almost-fully informed decisions,
> thus saving time? I will leave that as a straw man argument that you
> can all debate.
>
> dre
>

From mparsons1980 at gmail.com  Wed Apr 28 02:33:16 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Wed, 28 Apr 2010 01:33:16 -0500
Subject: [SC-L] [WEB SECURITY] Re: What do you like better Web
	penetration testing or static code analysis?
In-Reply-To: <r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
References: <01d101cae2ed$f92309b0$eb691d10$@com>
	<C7F73016.2160D%brian@fortify.com>
	<p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>
	<k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>
	<o2qcd1bdfdd1004270952m163b072di523bffd2b8df0213@mail.gmail.com>
	<h2wcb9225661004271219x2247d18dg3a548b70d29f1516@mail.gmail.com>
	<k2zcd1bdfdd1004271408gcb63c5d4jad949d76742eca62@mail.gmail.com>
	<x2p2fd9390e1004271429y98cf559fj1f59179402cd68e1@mail.gmail.com>
	<r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
Message-ID: <y2r5f0ff0861004272333oc4441be5p585cde28c62baf7a@mail.gmail.com>

I am working on a collaborative effort trying to blog daily about a
different software security bug.   I am looking for comments on my
blog on how to make it better.   Maybe eventually we can turn this
into an OWASP project.  I am really just doing this because at the
current time all I am doing is web penetration testing and I want to
make sure that I don't lose any of my code review skills.  Any
comments positive or negative would be very helpful.
http://parsonsisconsulting.blogspot.com/

Thanks,
Matt Parsons, CISSP, MSM



On Wed, Apr 28, 2010 at 12:10 AM, SneakySimian <sneaky.simian at gmail.com> wrote:
> I couldn't let this one go.
>
> Having done both source code analysis and blackbox testing, I see
> merits in both. The failure that was the Debian SSL bug is a prime
> example of why I prefer blackbox testing. That's not to say things
> can't go wrong in blackbox testing, because they do, but not all code
> behaves the same way in the same environment, so if you actually test
> it in the environment it is running in, you can then understand why
> the code behaves the way it does. Oversimplified example:
>
> <?php
> $file = $_GET['file'];
>
> if(file_exists($file))
> {
> ? ? echo $file;
> }
>
> else
> {
> ? ?echo 'File not found. :(';
> }
>
> Ignoring the other blatant issues with that code snippet, is that
> vulnerable to XSS? No? Are you sure? Yes? Can you prove it? As it
> turns out, it depends on a configuration setting in php.ini. The only
> real way to know if it is an issue is to run it in the environment it
> is meant to be run in. Now, that's not to say that the developer who
> wrote that code shouldn't be told to fix it in a source code analysis,
> but the point is, some issues are wholly dependent on the environment
> and may or may not get caught during code analysis. Other issues such
> as code branches that don't execute or do execute in certain
> environments can be problematic to spot during normal source code
> analysis.
>
> That all said, I do enjoy reading code, especially comment coding from
> other developers. :P
>
>
>
> On Tue, Apr 27, 2010 at 2:29 PM, Andre Gironda <andreg at gmail.com> wrote:
>> On Tue, Apr 27, 2010 at 4:08 PM, Arian J. Evans
>> <arian.evans at anachronic.com> wrote:
>>> I think everyone would agree that you definitely want to apply
>>> additional (deeper?) degrees of analysis and defensive
>>> compensating-control to high-value and high-risk assets. The tough
>>> question is what ruler you use to justify degree of security
>>> investment to degree of potential Risk/Loss.
>>
>> That requires information sharing and trend analysis, something that
>> our classic vulnerability management programs have also not solved
>>
>> ----------------------------------------------------------------------------
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>>
>> Subscribe via RSS:
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>> Join WASC on LinkedIn
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>



-- 
Matt Parsons, CISSP
315-559-3588 Blackberry
817-238-3325 Home Office
mparsons1980 at gmail.com
www.parsonsisconsulting.com


From ssc at seecurity.org  Wed Apr 28 05:03:12 2010
From: ssc at seecurity.org (Sebastian Schinzel)
Date: Wed, 28 Apr 2010 11:03:12 +0200
Subject: [SC-L] [WEB SECURITY] Re: What do you like better Web
	penetration testing or static code analysis?
In-Reply-To: <r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
References: <01d101cae2ed$f92309b0$eb691d10$@com>
	<C7F73016.2160D%brian@fortify.com>
	<p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>
	<k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>
	<o2qcd1bdfdd1004270952m163b072di523bffd2b8df0213@mail.gmail.com>
	<h2wcb9225661004271219x2247d18dg3a548b70d29f1516@mail.gmail.com>
	<k2zcd1bdfdd1004271408gcb63c5d4jad949d76742eca62@mail.gmail.com>
	<x2p2fd9390e1004271429y98cf559fj1f59179402cd68e1@mail.gmail.com>
	<r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
Message-ID: <E51307A8-3704-42E5-A9C2-C77A2E03091D@seecurity.org>

On Apr 28, 2010, at 7:10 AM, SneakySimian wrote:
> <?php
> $file = $_GET['file'];
>
> if(file_exists($file))
> {
>     echo $file;
> }
>
> else
> {
>    echo 'File not found. :(';
> }
>
> Ignoring the other blatant issues with that code snippet, is that
> vulnerable to XSS? No? Are you sure? Yes? Can you prove it? As it
> turns out, it depends on a configuration setting in php.ini. The only
> real way to know if it is an issue is to run it in the environment it
> is meant to be run in. Now, that's not to say that the developer who
> wrote that code shouldn't be told to fix it in a source code analysis,
> but the point is, some issues are wholly dependent on the environment
> and may or may not get caught during code analysis. Other issues such
> as code branches that don't execute or do execute in certain
> environments can be problematic to spot during normal source code
> analysis.

So you suggest to actually perform n black-box tests where n is the set
of all possible permutations of all variables in php.ini (hint: n will  
be very
large)? This is certainly not feasible.

Your code shows a very simple data flow, which may or may not be
exploitable. But this is not the point. The point of software security  
is to
increase the reliability of the software when under attack.

Reliable software performs output encoding when user input is printed
to HTML. This code does not perform output encoding and should therefore
be fixed.

The discussion about whether or not this is exploitable on which  
platforms
is a waste of time. In many cases, you will find yourself spending a  
lot of
time in trying to get a running exploit, whereas the actual fix for  
the code
takes a fraction of the time.

For me, penetration testing is solely a method to raise awareness and  
to gather new
security requirements FOR a customer application FROM security  
researchers.
Knowledge transfer from security researchers to the business is key  
here.
It helps finding actual attacks but does not help the customer writing  
better
code.

Code audits (where automated or manual) are the way to go to improve
reliability by pointing out dangerous coding patterns.

My 0.02?...

Cheers
Sebastian

From cwysopal at veracode.com  Wed Apr 28 10:23:29 2010
From: cwysopal at veracode.com (Chris Wysopal)
Date: Wed, 28 Apr 2010 10:23:29 -0400
Subject: [SC-L] [WEB SECURITY] Re: What do you like better Web
 penetration testing or static code analysis?
In-Reply-To: <r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
References: <01d101cae2ed$f92309b0$eb691d10$@com>
	<C7F73016.2160D%brian@fortify.com>
	<p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>
	<k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>
	<o2qcd1bdfdd1004270952m163b072di523bffd2b8df0213@mail.gmail.com>
	<h2wcb9225661004271219x2247d18dg3a548b70d29f1516@mail.gmail.com>
	<k2zcd1bdfdd1004271408gcb63c5d4jad949d76742eca62@mail.gmail.com>
	<x2p2fd9390e1004271429y98cf559fj1f59179402cd68e1@mail.gmail.com>
	<r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD024C6EA751@orbital.Veracode.local>


There is no reason the php.ini and other framework or app server configuration files can't be taken into account in a static analysis.  Veracode performs static analysis of an application in its final executable form.  So for compiled languages that is a binary executable, for managed languages it is the compiled bytecode and for interpreted languages it is the source code.  If there are standard configuration files that are part of the run time environment for frameworks or app servers they are be considered part of the final executable version of the app. If the configuration files are missing then a worst case analysis is performed.

Of course the php.ini submitted to the static analyzer might not match the one running in production but you can have the same issue doing dynamic testing on a staging environment. 

It can be a goal for both static and dynamic testing to have the analysis come as close as possible to what will be in production.  

-Chris


-----Original Message-----
From: SneakySimian [mailto:sneaky.simian at gmail.com] 
Sent: Wednesday, April 28, 2010 1:10 AM
To: Andre Gironda
Cc: websecurity; Secure Coding; Adam Muntner; Arian J. Evans
Subject: Re: [WEB SECURITY] Re: [SC-L] What do you like better Web penetration testing or static code analysis?

I couldn't let this one go.

Having done both source code analysis and blackbox testing, I see
merits in both. The failure that was the Debian SSL bug is a prime
example of why I prefer blackbox testing. That's not to say things
can't go wrong in blackbox testing, because they do, but not all code
behaves the same way in the same environment, so if you actually test
it in the environment it is running in, you can then understand why
the code behaves the way it does. Oversimplified example:

<?php
$file = $_GET['file'];

if(file_exists($file))
{
     echo $file;
}

else
{
    echo 'File not found. :(';
}

Ignoring the other blatant issues with that code snippet, is that
vulnerable to XSS? No? Are you sure? Yes? Can you prove it? As it
turns out, it depends on a configuration setting in php.ini. The only
real way to know if it is an issue is to run it in the environment it
is meant to be run in. Now, that's not to say that the developer who
wrote that code shouldn't be told to fix it in a source code analysis,
but the point is, some issues are wholly dependent on the environment
and may or may not get caught during code analysis. Other issues such
as code branches that don't execute or do execute in certain
environments can be problematic to spot during normal source code
analysis.

That all said, I do enjoy reading code, especially comment coding from
other developers. :P



On Tue, Apr 27, 2010 at 2:29 PM, Andre Gironda <andreg at gmail.com> wrote:
> On Tue, Apr 27, 2010 at 4:08 PM, Arian J. Evans
> <arian.evans at anachronic.com> wrote:
>> I think everyone would agree that you definitely want to apply
>> additional (deeper?) degrees of analysis and defensive
>> compensating-control to high-value and high-risk assets. The tough
>> question is what ruler you use to justify degree of security
>> investment to degree of potential Risk/Loss.
>
> That requires information sharing and trend analysis, something that
> our classic vulnerability management programs have also not solved
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



From gem at cigital.com  Fri Apr 30 10:20:15 2010
From: gem at cigital.com (Gary McGraw)
Date: Fri, 30 Apr 2010 10:20:15 -0400
Subject: [SC-L] Silver Bullet 49: Ivan Arce + informIT on Virtual PC
	vulnerability
Message-ID: <C8005F5F.21272%gem@cigital.com>

hi sc-l,

Ivan Arce is the CTO and co-founder of Core.  He's a very knowledgeable guy and well-respected among the breakers of stuff, especially when it comes to low-level attacks against BIOS, kernels, and VMs.  Ivan is Silver Bullet podcast victim 49:

http://www.cigital.com/silverbullet/show-049/

We discuss the attacker's perspective, geek life in Argentina, embedded systems attacks, and an important vulnerability in Virtual PC that Core is having a very hard time convincing Microsoft to fix. On that last point, Ivan and I wrote this month's informIT column about the as yet unfixed the Virtual PC problem:

Assume Nothing: Is Microsoft Forgetting a Crucial Security Message?
http://www.informit.com/articles/article.aspx?p=1588145

It seems Microsoft is overlooking one of the most important lessons from Exploiting Software...assume nothing.

As always, your feedback on Silver Bullet and the informIT series is welcome.

gem

company www.cigital.com
blog www.cigital.com/justiceleague
book www.swsec.com


From mparsons1980 at gmail.com  Wed May  5 07:36:31 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Wed, 5 May 2010 06:36:31 -0500
Subject: [SC-L] Introductions Matt Parsons Video Blog is there an
	interest
Message-ID: <003101caec47$362f1990$a28d4cb0$@com>

I have been on this list for a while and see a lot of value to the
community.   I wanted to introduce myself to the software security community
through a video blog. 

http://parsonsisconsulting.blogspot.com/2010/05/matt-parsons-introduction-ci
ssp.html I plan on doing some hands on videos demonstrating OWASP top ten
vulnerabilities.   



I am interested in getting to know others on this list.  If you feel
comfortable please shoot me an email with what you do and what you hope to
achieve in the software security field.  I am not sure if others on the list
will find this valuable so I will let the moderator determine if it is
allowed.

 

 I am also an open networker looking to expand my software security contacts
via LinkedIN.    <http://www.linkedin.com/in/parsonsconsulting>
http://www.linkedin.com/in/parsonsconsulting

Mparsons1980 at gmail.com

 

Thanks,

Matt

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

 <mailto:mparsons1980 at gmail.com> mailto:mparsons1980 at gmail.com

 <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com

 <http://www.o2-ounceopen.com/o2-power-users/>
http://www.o2-ounceopen.com/o2-power-users/

 <http://www.linkedin.com/in/parsonsconsulting>
http://www.linkedin.com/in/parsonsconsulting

 <http://parsonsisconsulting.blogspot.com/>
http://parsonsisconsulting.blogspot.com/

 <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668

 <http://twitter.com/parsonsmatt> http://twitter.com/parsonsmatt

 

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100505/3e7a0ba8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100505/3e7a0ba8/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100505/3e7a0ba8/attachment-0001.jpeg>

From ken at krvw.com  Wed May  5 09:44:55 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 5 May 2010 09:44:55 -0400
Subject: [SC-L] Web Application Exploits and Defenses
Message-ID: <D0C6AB6F-2007-4F98-8955-65622C434801@krvw.com>

The folks at Google have released some web app training, along with a vulnerable web app sandbox to play in.  The tool is called Jarlsberg.  Anyone here take a look at it yet, and have an opinion about it?

The description (see below) sounds kinda sorta like OWASP's WebGoat, except that the vulnerable app itself is written in Python.  Oh, and the app is available on the web, as well as in source code (under Creative Commons).

http://jarlsberg.appspot.com/ 

There's also an instructor's guide available at:

http://code.google.com/edu/submissions/jarlsberg/Jarlsberg_Instructor_Guide.pdf


Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

Follow us on Twitter at: http://twitter.com/KRvW_Associates





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100505/cc2dfed1/attachment.bin>

From floodeen at gmail.com  Wed May  5 10:32:15 2010
From: floodeen at gmail.com (Rob Floodeen)
Date: Wed, 5 May 2010 10:32:15 -0400
Subject: [SC-L] Web Application Exploits and Defenses
In-Reply-To: <D0C6AB6F-2007-4F98-8955-65622C434801@krvw.com>
References: <D0C6AB6F-2007-4F98-8955-65622C434801@krvw.com>
Message-ID: <j2y2f1215011005050732y492060b6z22a186efffd115dc@mail.gmail.com>

On the same subject, I'm looking for something along this line (and
that of hacme).  However I need it to be able to:
1.  Work on current MS Products
2.  Store it's data to a remote database
3.  Be accessible from Remote systems
4.  Clean target space

Why?  I need an external corporate webserver that is vulnerable for
some training I'm working on.  Currently we are using some hand
written html and php that feeds into MSSQL.  It works, but is not
exciting or current.  We explored the hacme, maven, webgoat (actually
use it as a secondary target in the dmz), etc.  But have not found
anything that simulates enterprise level operation.

If you would like more detail on what we are building and how, drop me
a mail, I don't wish to spam the list.

-Rob Floodeen


On Wed, May 5, 2010 at 9:44 AM, Kenneth Van Wyk <ken at krvw.com> wrote:
> The folks at Google have released some web app training, along with a vulnerable web app sandbox to play in. ?The tool is called Jarlsberg. ?Anyone here take a look at it yet, and have an opinion about it?
>
> The description (see below) sounds kinda sorta like OWASP's WebGoat, except that the vulnerable app itself is written in Python. ?Oh, and the app is available on the web, as well as in source code (under Creative Commons).
>
> http://jarlsberg.appspot.com/
>
> There's also an instructor's guide available at:
>
> http://code.google.com/edu/submissions/jarlsberg/Jarlsberg_Instructor_Guide.pdf
>
>
> Cheers,
>
> Ken
>
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
>
> Follow us on Twitter at: http://twitter.com/KRvW_Associates
>
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>
>


From Greg.Beeley at LightSys.org  Wed May  5 11:32:26 2010
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Wed, 05 May 2010 10:32:26 -0500
Subject: [SC-L] [WEB SECURITY] Re: What do you like better
 Web	penetration testing or static code analysis?
In-Reply-To: <E51307A8-3704-42E5-A9C2-C77A2E03091D@seecurity.org>
References: <01d101cae2ed$f92309b0$eb691d10$@com>	<C7F73016.2160D%brian@fortify.com>	<p2vcd1bdfdd1004241933sec974290oe4422165a90de1d8@mail.gmail.com>	<k2q2fd9390e1004262254ia12bc652h862e06d222c1b1fd@mail.gmail.com>	<o2qcd1bdfdd1004270952m163b072di523bffd2b8df0213@mail.gmail.com>	<h2wcb9225661004271219x2247d18dg3a548b70d29f1516@mail.gmail.com>	<k2zcd1bdfdd1004271408gcb63c5d4jad949d76742eca62@mail.gmail.com>	<x2p2fd9390e1004271429y98cf559fj1f59179402cd68e1@mail.gmail.com>	<r2u896a8391004272210ieb793d58i853baa86d3e924c9@mail.gmail.com>
	<E51307A8-3704-42E5-A9C2-C77A2E03091D@seecurity.org>
Message-ID: <4BE18F8A.2030500@LightSys.org>

Regarding the code snippet -- it does depend on the environment -- point well
taken.  But in this case (from what I can tell), unless you actually have the
file_exists() function *disabled* in php.ini, this is vulnerable to XSS.

- Greg

Sebastian Schinzel wrote, On 04/28/2010 04:03 AM:
> On Apr 28, 2010, at 7:10 AM, SneakySimian wrote:
>> <?php
>> $file = $_GET['file'];
>>
>> if(file_exists($file))
>> {
>>     echo $file;
>> }
>>
>> else
>> {
>>    echo 'File not found. :(';
>> }
>>
>> Ignoring the other blatant issues with that code snippet, is that
>> vulnerable to XSS? No? Are you sure? Yes? Can you prove it? As it
>> turns out, it depends on a configuration setting in php.ini. The only
>> real way to know if it is an issue is to run it in the environment it
>> is meant to be run in. Now, that's not to say that the developer who
>> wrote that code shouldn't be told to fix it in a source code analysis,
>> but the point is, some issues are wholly dependent on the environment
>> and may or may not get caught during code analysis. Other issues such
>> as code branches that don't execute or do execute in certain
>> environments can be problematic to spot during normal source code
>> analysis.
> 
> So you suggest to actually perform n black-box tests where n is the set
> of all possible permutations of all variables in php.ini (hint: n will
> be very
> large)? This is certainly not feasible.
> 
> Your code shows a very simple data flow, which may or may not be
> exploitable. But this is not the point. The point of software security
> is to
> increase the reliability of the software when under attack.
> 
> Reliable software performs output encoding when user input is printed
> to HTML. This code does not perform output encoding and should therefore
> be fixed.
> 
> The discussion about whether or not this is exploitable on which platforms
> is a waste of time. In many cases, you will find yourself spending a lot of
> time in trying to get a running exploit, whereas the actual fix for the
> code
> takes a fraction of the time.
> 
> For me, penetration testing is solely a method to raise awareness and to
> gather new
> security requirements FOR a customer application FROM security researchers.
> Knowledge transfer from security researchers to the business is key here.
> It helps finding actual attacks but does not help the customer writing
> better
> code.
> 
> Code audits (where automated or manual) are the way to go to improve
> reliability by pointing out dangerous coding patterns.
> 
> My 0.02?...
> 
> Cheers
> Sebastian
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
> 

From rklists at gmail.com  Thu May  6 11:49:55 2010
From: rklists at gmail.com (Rohit Sethi)
Date: Thu, 6 May 2010 11:49:55 -0400
Subject: [SC-L] Next Release of the Secure Web Application Framework
	Manifesto
Message-ID: <p2ifd72f3ed1005060849uc584b537s2047bd08cdc4a655@mail.gmail.com>

Hi all, we've released version 0.08 of the Secure Web Application
Framework Manifesto at http://labs.securitycompass.com

This is 2nd public release of the document. Our goal is to provide a
list of requirements so that web application frameworks offer more
security out of the box. Our next step will be to move this over to an
OWASP project, and then to solicit participation from framework
developers. If anyone participates in or knows of the developers of
the Django or Lift web app frameworks please let me know. As always,
we look forward to any suggestions you have.

We had a lot of feedback on additional requirements from our previous
release. We took the approach of actually reducing the total number of
requirements in this release so that we have a greater chance of
achieving success with the frameworks. We plan on adding to the
requirements in future years.

Thanks,

-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com
twitter: rksethi

From koved at us.ibm.com  Tue May 11 17:26:33 2010
From: koved at us.ibm.com (Larry Koved)
Date: Tue, 11 May 2010 17:26:33 -0400
Subject: [SC-L] final reminder: W2SP 2010: Web 2.0 Security and Privacy 2010
In-Reply-To: <OF944006F7.CD77F85F-ON852576DD.0063E788-852576DD.0063FD57@LocalDomain>
References: <OF367F5FDC.B6DC1CD9-ON852576A7.004BE2F3-852576A7.004BF1CD@LocalDomain>
	<OF944006F7.CD77F85F-ON852576DD.0063E788-852576DD.0063FD57@LocalDomain>
Message-ID: <OF25F09DAC.80F5C822-ON85257720.0075BE36-85257720.0075CAED@us.ibm.com>

A final reminder...

W2SP 2010: Web 2.0 Security and Privacy 2010

Thursday, May 20
The Claremont Resort, Oakland, California
Web site: http://w2spconf.com/2010


The workshop chairs would like to invite you attend the 4th annual 
workshop on Web 2.0 Security and Privacy.  Started in 2007, this 
successful 
series of workshops has attracted participation from both academia and 
industry, and participants from around the world.  This workshop is held
in conjunction with the 2010 IEEE Symposium on Security and Privacy. 

The goal of this one day workshop is to bring together researchers and
practitioners from academia and industry to focus on understanding Web
2.0 security and privacy issues, and establishing new collaborations
in these areas.

This year's keynote speaker is Jeremiah Grossman, founder and CTO, 
WhiteHat Security.

Workshop registration is *still open* at 
http://www.regonline.com/Checkin.asp?EventId=810837

(Note that the IEEE Symposium on Security & Privacy registration is sold 
out.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100511/b85441ce/attachment.htm>

From mparsons1980 at gmail.com  Tue May 11 12:32:08 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Tue, 11 May 2010 11:32:08 -0500
Subject: [SC-L] Are people using Threat modeling?
Message-ID: <03d501caf127$80b38e30$821aaa90$@com>

Are people using threat modeling for their clients?  I just started having
an interest in it with my clients and it is amazing on what you find with
threat modeling.   I have been using the Microsoft Threat Analysis tool.
What other tools are people using?   

Thanks,

Matt

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

http://twitter.com/parsonsmatt

 

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100511/9790012e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100511/9790012e/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100511/9790012e/attachment-0001.jpeg>

From rgaucher at cigital.com  Tue May 11 14:15:51 2010
From: rgaucher at cigital.com (Romain Gaucher)
Date: Tue, 11 May 2010 14:15:51 -0400
Subject: [SC-L] [WEB SECURITY] Are people using Threat modeling?
In-Reply-To: <03d501caf127$80b38e30$821aaa90$@com>
References: <03d501caf127$80b38e30$821aaa90$@com>
Message-ID: <853A02533F8C88439F2331EB193853844BCD169361@va-mailhub.cigital.com>

Yes, "we" use Threat Modeling a lot. In fact, I believe it's one of the best tool to conduct an efficient assessment of an application.
After, there might be no need to use tools like MS TM, but a white board and few hours are fine (largely correlated with the size of the apps, the scope of the assessment and the complexity of the architecture).
I found TM also very useful to decide which assessment framework to use (how much time should be used on pen-test, how much on fuzzing, how much on code review, etc.); no need to say though that the main problem with TM is that you almost need to be an expert to run it (unless you use the MS card game -- which I'd love to get ;)

Romain,
  Sr. consultant, Cigital | @rgaucher

________________________________________
From: Matt Parsons [mparsons1980 at gmail.com]
Sent: Tuesday, May 11, 2010 12:32 PM
To: 'Webappsec Group'; OWASPDallas at utdallas.edu; SC-L at securecoding.org
Subject: [WEB SECURITY] Are people using Threat modeling?

Are people using threat modeling for their clients?  I just started having an interest in it with my clients and it is amazing on what you find with threat modeling.   I have been using the Microsoft Threat Analysis tool.   What other tools are people using?
Thanks,
Matt


Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office
"Do Good and Fear No Man"
Fort Worth, Texas
A.K.A The Keyboard Cowboy
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/
http://www.vimeo.com/8939668
http://twitter.com/parsonsmatt


[cid:image001.jpg at 01CAF0FD.96DE65B0]

[cid:image002.jpg at 01CAF0FD.96DE65B0]









From gem at cigital.com  Wed May 12 08:53:53 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 12 May 2010 08:53:53 -0400
Subject: [SC-L] BSIMM2
Message-ID: <C8101D21.21B95%gem@cigital.com>

hi sc-l,

In March 2009 we announced the publication of the BSIMM---a measuring stick for software security.  We're pleased today to announce the publication of BSIMM2.  We have tripled the size of the data set to thirty firms, including: Adobe, Aon, Bank of America, Capital One, The Depository Trust & Clearing Corporation (DTCC), EMC, Google, Intel, Intuit, Microsoft, Nokia, QUALCOMM, Sallie Mae, Standard Life, SWIFT, Symantec, Telecom Italia, Thomson Reuters, VMware, and Wells Fargo.

BSIMM2 is available for free under the creative commons license from <http://bsimm2.com>.  Download your copy today.

The BSIMM2 document itself is 53 pages.  A concise treatment of the results can be found on the BSIMM2 web page under the "facts" tag: <http://bsimm2.com/facts/>

Our study represents the work of 635 people who are members of the 30 firms' SSGs.  Together, the firms have a collective 130 years of experience planning and executing 30 software security initiatives.  Among other results, we have identified 15 core BSIMM activities.

We think the descriptive nature of the BSIMM study is an important characteristic of the work.  We describe not what you should do for software security, but what successful software security initiatives are actually doing.  Use BSIMM2 to measure your own software security initiative and compare it to others.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

MUSIC http://www.amazon.com/dp/B003JPNV1I/?tag=lastfmmp3-20


From gem at cigital.com  Wed May 12 09:57:56 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 12 May 2010 09:57:56 -0400
Subject: [SC-L] BSIMM2 (as seen on informIT)
In-Reply-To: <C8101D21.21B95%gem@cigital.com>
Message-ID: <C8102C24.21BF3%gem@cigital.com>

hi sc-l,

Nice night for the data center to crash at informIT!

The BSIMM2 document itself is 53 pages.  A concise treatment of the results can be found in this month's informIT column in an article titled "BSIMM2: Measuring the Emergence of a Software Security Community":
<http://www.informit.com/articles/article.aspx?p=1592389>

Sorry for the delay.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

MUSIC http://www.amazon.com/dp/B003JPNV1I/?tag=lastfmmp3-20



On 5/12/10 8:53 AM, "gem" <gem at cigital.com> wrote:

hi sc-l,

In March 2009 we announced the publication of the BSIMM---a measuring stick for software security.  We're pleased today to announce the publication of BSIMM2.  We have tripled the size of the data set to thirty firms, including: Adobe, Aon, Bank of America, Capital One, The Depository Trust & Clearing Corporation (DTCC), EMC, Google, Intel, Intuit, Microsoft, Nokia, QUALCOMM, Sallie Mae, Standard Life, SWIFT, Symantec, Telecom Italia, Thomson Reuters, VMware, and Wells Fargo.

BSIMM2 is available for free under the creative commons license from <http://bsimm2.com>.  Download your copy today.

The BSIMM2 document itself is 53 pages.  A concise treatment of the results can be found on the BSIMM2 web page under the "facts" tag: <http://bsimm2.com/facts/>

Our study represents the work of 635 people who are members of the 30 firms' SSGs.  Together, the firms have a collective 130 years of experience planning and executing 30 software security initiatives.  Among other results, we have identified 15 core BSIMM activities.

We think the descriptive nature of the BSIMM study is an important characteristic of the work.  We describe not what you should do for software security, but what successful software security initiatives are actually doing.  Use BSIMM2 to measure your own software security initiative and compare it to others.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

MUSIC http://www.amazon.com/dp/B003JPNV1I/?tag=lastfmmp3-20

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________



From gem at cigital.com  Wed May 12 09:29:51 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 12 May 2010 09:29:51 -0400
Subject: [SC-L] [WEB SECURITY] Are people using Threat modeling?
In-Reply-To: <853A02533F8C88439F2331EB193853844BCD169361@va-mailhub.cigital.com>
Message-ID: <C810258F.21BC4%gem@cigital.com>

hi matt,

In BSIMM2 (which launched today), there are some real data under the "Architecture Analysis" practice which show exactly how common (or not) 10 threat modeling activities are in our population of 30 firms.  For the actual data, see
http://bsimm2.com/facts/ (or better yet, download BSIMM2 for the complete treatment).

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On 5/11/10 2:15 PM, "Romain Gaucher" <rgaucher at cigital.com> wrote:

Yes, "we" use Threat Modeling a lot. In fact, I believe it's one of the best tool to conduct an efficient assessment of an application.
After, there might be no need to use tools like MS TM, but a white board and few hours are fine (largely correlated with the size of the apps, the scope of the assessment and the complexity of the architecture).
I found TM also very useful to decide which assessment framework to use (how much time should be used on pen-test, how much on fuzzing, how much on code review, etc.); no need to say though that the main problem with TM is that you almost need to be an expert to run it (unless you use the MS card game -- which I'd love to get ;)

Romain,
  Sr. consultant, Cigital | @rgaucher

________________________________________
From: Matt Parsons [mparsons1980 at gmail.com]
Sent: Tuesday, May 11, 2010 12:32 PM
To: 'Webappsec Group'; OWASPDallas at utdallas.edu; SC-L at securecoding.org
Subject: [WEB SECURITY] Are people using Threat modeling?

Are people using threat modeling for their clients?  I just started having an interest in it with my clients and it is amazing on what you find with threat modeling.   I have been using the Microsoft Threat Analysis tool.   What other tools are people using?
Thanks,
Matt


Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office
"Do Good and Fear No Man"
Fort Worth, Texas
A.K.A The Keyboard Cowboy
mailto:mparsons1980 at gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/
http://www.vimeo.com/8939668
http://twitter.com/parsonsmatt


[cid:image001.jpg at 01CAF0FD.96DE65B0]

[cid:image002.jpg at 01CAF0FD.96DE65B0]








_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________



From securecoding at nxtg.net  Wed May 12 19:49:52 2010
From: securecoding at nxtg.net (AF)
Date: Thu, 13 May 2010 01:49:52 +0200
Subject: [SC-L] [WEB SECURITY] Are people using Threat modeling?
In-Reply-To: <853A02533F8C88439F2331EB193853844BCD169361@va-mailhub.cigital.com>
References: <03d501caf127$80b38e30$821aaa90$@com>
	<853A02533F8C88439F2331EB193853844BCD169361@va-mailhub.cigital.com>
Message-ID: <4BEB3EA0.5060909@nxtg.net>


Yes. I mostly do TM by myself when conducting pentests. It helps me identify
critical scenarios and keep some business orientation when I don't catch 
up with
flashy sql injections. TM also adds some business orientation to the 
test and gives
real "field" insight to non-technical people (usually, those who pay) 
about what's
at stake.

Some clients (2 ...actually) recently started showing interest in 
working on building
threat models before the coding phase. That's cool. Late, but cool.

Now concerning the tools:
- 2 hours meeting with some guys from the business, a developer and the 
application
business owner
- I ask questions, they answer them, I take notes

If it helps...

Antonio


> ________________________________________
> From: Matt Parsons [mparsons1980 at gmail.com]
> Sent: Tuesday, May 11, 2010 12:32 PM
> To: 'Webappsec Group'; OWASPDallas at utdallas.edu; SC-L at securecoding.org
> Subject: [WEB SECURITY] Are people using Threat modeling?
>
> Are people using threat modeling for their clients?  I just started having an interest in it with my clients and it is amazing on what you find with threat modeling.   I have been using the Microsoft Threat Analysis tool.   What other tools are people using?
> Thanks,
> Matt
>
>
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> "Do Good and Fear No Man"
> Fort Worth, Texas
> A.K.A The Keyboard Cowboy
> mailto:mparsons1980 at gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> http://parsonsisconsulting.blogspot.com/
> http://www.vimeo.com/8939668
> http://twitter.com/parsonsmatt
>
>
> [cid:image001.jpg at 01CAF0FD.96DE65B0]
>
> [cid:image002.jpg at 01CAF0FD.96DE65B0]
>
>
>
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>    


From lists at ticm.com  Thu May 13 08:56:33 2010
From: lists at ticm.com (Bret Watson)
Date: Thu, 13 May 2010 20:56:33 +0800
Subject: [SC-L] [WEB SECURITY] Are people using Threat modeling?
In-Reply-To: <4BEB3EA0.5060909@nxtg.net>
References: <03d501caf127$80b38e30$821aaa90$@com>
	<853A02533F8C88439F2331EB193853844BCD169361@va-mailhub.cigital.com>
	<4BEB3EA0.5060909@nxtg.net>
Message-ID: <4bebf712.107d8d0a.5d7f.4f46@mx.google.com>


>Sounds like my toolset... I've got some questionaires for them to do 
>beforehand - basically education for the architects- they learn that 
>if it doesn't come out yes all the way down it will be better if it 
>was fixed first
. We've also put together a nice business process to show the heads 
(ie the ones that pay in this case) that it would be much cheaper to 
not design it broken in the first place... :)

But in the end its interview and writeup :)

Cheers

Bret

>Now concerning the tools:
>- 2 hours meeting with some guys from the business, a developer and 
>the application
>business owner
>- I ask questions, they answer them, I take notes


From James.McGovern at thehartford.com  Thu May 13 09:41:45 2010
From: James.McGovern at thehartford.com (McGovern, James F. (P+C Technology))
Date: Thu, 13 May 2010 09:41:45 -0400
Subject: [SC-L] [WEB SECURITY] Are people using Threat modeling?
In-Reply-To: <4BEB3EA0.5060909@nxtg.net>
References: <03d501caf127$80b38e30$821aaa90$@com><853A02533F8C88439F2331EB193853844BCD169361@va-mailhub.cigital.com>
	<4BEB3EA0.5060909@nxtg.net>
Message-ID: <BFD50E79FBE23A4FB6BE93572A6FE28703D0B993@AD1HFDEXC312.ad1.prod>


 In my travels, the usage of threat modeling occurs whenever a security
resource is assigned to an application development project. This peaked
several years ago and now is on the decline as the trend of software
development going offshore makes it more challenging to either get a
security resource assigned to the project and/or developers wanting to
improve the quality of their deliverable and just focusing on delivering
as fast as possible.



-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of AF
Sent: Wednesday, May 12, 2010 7:50 PM
To: sc-l at securecoding.org
Subject: Re: [SC-L] [WEB SECURITY] Are people using Threat modeling?


Yes. I mostly do TM by myself when conducting pentests. It helps me
identify critical scenarios and keep some business orientation when I
don't catch up with flashy sql injections. TM also adds some business
orientation to the test and gives real "field" insight to non-technical
people (usually, those who pay) about what's at stake.

Some clients (2 ...actually) recently started showing interest in
working on building threat models before the coding phase. That's cool.
Late, but cool.

Now concerning the tools:
- 2 hours meeting with some guys from the business, a developer and the
application business owner
- I ask questions, they answer them, I take notes

If it helps...

Antonio
************************************************************
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.
************************************************************



From michael.coates at owasp.org  Fri May 14 12:01:45 2010
From: michael.coates at owasp.org (Michael Coates)
Date: Fri, 14 May 2010 09:01:45 -0700
Subject: [SC-L] CSRF and Header Forging - your thoughts needed
Message-ID: <4BED73E9.3010401@owasp.org>

All,

I'm looking for thoughts on CSRF attacks that result in forged headers 
from the victim user to the target site. Are there modern attacks that 
work here? If not, could we implement a CSRF protection that uses a 
custom header and avoid the cost of computing random numbers?  This 
sounds very strange at first since we are accustomed to the standard 
random CSRF token approach.  However, please take a look and contribute 
to the comment thread:

http://michael-coates.blogspot.com/2010/05/csrf-attacks-and-forged-headers.html

(Several comments on the article already, I encourage you to post your 
comments there for everyone to read)

Thanks!

-- 
Michael Coates
http://michael-coates.blogspot.com
OWASP Member&  Contributor


From lcamtuf at coredump.cx  Fri May 14 12:43:44 2010
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Fri, 14 May 2010 09:43:44 -0700
Subject: [SC-L] CSRF and Header Forging - your thoughts needed
In-Reply-To: <4BED73E9.3010401@owasp.org>
References: <4BED73E9.3010401@owasp.org>
Message-ID: <AANLkTin76cyzrcOZZCEKd9IlxLcrkLWgZBsC32dZhbRZ@mail.gmail.com>

> I'm looking for thoughts on CSRF attacks that result in forged headers from
> the victim user to the target site. Are there modern attacks that work here?
> If not, could we implement a CSRF protection that uses a custom header and
> avoid the cost of computing random numbers?

The only thing that undermines this approach is that there's a fairly
steady stream of plugin implementation bugs that make header injection
easy (XMLHttpRequest implementation bugs seem to be dying off). They
usually (not always!) require you to be SOP with the attacked domain,
so theoretically no problem - but if you can also tweak "Host", it
becomes a problem on systems with multiple virtual servers on a single
IP, one of them controlled by a rogue party or just vulnerable to XSS.

In any case... I am willing to say that this is a reasonably robust
XSRF defense in most cases, but you have to keep this extra likelihood
of breakage in mind.

/mz

From mparsons1980 at gmail.com  Wed May 19 15:39:43 2010
From: mparsons1980 at gmail.com (Matt Parsons)
Date: Wed, 19 May 2010 14:39:43 -0500
Subject: [SC-L] Three biggest problems companies are facing with software
	security
Message-ID: <05a101caf78b$090ecc40$1b2c64c0$@com>

I was thinking over the weekend what the three biggest problems companies
face when dealing with software security and wondered what the community
thought about it.   I know that Jeff and Aspect Security is solving some of
the problems with OWASP and ESAPI.  I would also think that McGraw and his
crew at Cigital are solving problems with the BSIMM.   What do you guys
think about it?  Do you think as a community that we can solve these
problems?   

 

http://parsonsisconsulting.blogspot.com/

 

 

Matt Parsons, MSM, CISSP

315-559-3588 Blackberry

817-294-3789 Home office 

"Do Good and Fear No Man"  

Fort Worth, Texas

A.K.A The Keyboard Cowboy

mailto:mparsons1980 at gmail.com

http://www.parsonsisconsulting.com

http://www.o2-ounceopen.com/o2-power-users/

http://www.linkedin.com/in/parsonsconsulting

http://parsonsisconsulting.blogspot.com/

http://www.vimeo.com/8939668

http://twitter.com/parsonsmatt

 

 

0_0_0_0_250_281_csupload_6117291

 

untitled

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100519/ea9e020e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1719 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100519/ea9e020e/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2000 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100519/ea9e020e/attachment-0001.jpeg>

From vadim.okun at nist.gov  Wed May 26 17:47:25 2010
From: vadim.okun at nist.gov (Vadim Okun)
Date: Wed, 26 May 2010 17:47:25 -0400
Subject: [SC-L] Static analysis tool exposition (SATE) Call for participation
Message-ID: <4BFD96ED.9020704@nist.gov>

We are preparing the third Static Analysis Tool Exposition (SATE).
Briefly, participating tool makers run their tool on a set of programs.
Researchers led by NIST analyze the tool reports. The results and
experiences are reported at a workshop. The tool reports and analysis
are made publicly available later.

The draft plan (including a summary of proposed changes since last
year) is at

http://samate.nist.gov/SATE2010.html

In particular, we plan to provide the test sets by 28 June, and to
hold a workshop on 1 October.

We would appreciate any suggestions regarding the plan.

We invite tool makers to sign up. If you would like to participate in
the exposition, or if you have questions, please email Vadim Okun
(vadim.okun 'at' nist.gov).or Aurelien Delaitre (aurelien.delaitre 'at'
nist.gov).

Thanks,
Vadim



From jim at manico.net  Thu May 27 17:33:35 2010
From: jim at manico.net (Jim Manico)
Date: Thu, 27 May 2010 14:33:35 -0700
Subject: [SC-L] SATE
Message-ID: <4BFEE52F.40904@manico.net>

I feel that NIST made a few errors in the first 2 SATE studies.

After the second round of SATE, the results were never fully released to 
the public - even when NIST agreed to do just that at the inception of 
the contest. I do not understand why SATE censored the final results - I 
feel such censorship hurts the industry.

And even worse, I felt that vendor pressure encouraged NIST to not 
release the final results. If the results (the real deep data, not the 
executive summary that NIST release) were favorable to the tool vendors, 
I bet they would have welcomed the release of the real data. But 
instead, vendor pressure caused NIST to block the release of the final 
data set.

The problems that the data would have revealed is:

1) false positive rates from these tools are overwhelming
2) the work load to triage results from ONE of these tools were man-years
3) by every possible measurement, manual review was more cost effective

Even worse were the methods around the process of this "study". For 
example, all of the Java app's in this "study" contained poor hash 
implementations. But because the tools (none of them) could see this, 
that "finding" was completely ignored. The coverage was limited ONLY to 
injection and data flow problems that tools have a chance of finding. In 
fact, the NIST team chose only a small percentage of the automated 
findings to review, since it would have taken years to review everything 
due to the massive number of false positives. Get the problem here?

I'm discouraged by SATE. I hope some of these problems are addressed in 
the third study.

- Jim

From ken at krvw.com  Fri May 28 18:33:02 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 28 May 2010 12:33:02 -1000
Subject: [SC-L] Vulnerability Analysis Blog: CERT Basic Fuzzing Framework
Message-ID: <EC01655F-0DE1-4AA5-8360-AFE16B85E405@krvw.com>

New fuzzing framework released from the folks up at CMU, FYI.

https://www.cert.org/blogs/vuls/2010/05/cert_basic_fuzzing_framework.html 


Aloha,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

Follow us on Twitter at: http://twitter.com/KRvW_Associates





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100528/864fef06/attachment.bin>

From jim.manico at owasp.org  Fri May 28 18:39:15 2010
From: jim.manico at owasp.org (Jim Manico)
Date: Fri, 28 May 2010 15:39:15 -0700
Subject: [SC-L] SATE
In-Reply-To: <4BFEE52F.40904@manico.net>
References: <4BFEE52F.40904@manico.net>
Message-ID: <4C004613.7010500@owasp.org>

NIST already responded to my email on a different list. I was impressed 
with what they had to say...

**************

We have been releasing the real deep data. There have been delays, but there are no sinister reasons for the delays.

The results of the 2nd SATE (our report and all data) will be released in June (We promised to release between February and May, but we're late with the report).

We released the results of the 1st SATE last summer: our report, the raw tool reports, and our analysis of the reports. The data is available (below the list of cautions) from
http://samate.nist.gov/SATE2008.html

or a direct link:
http://samate.nist.gov/SATE2008/resources/sate2008.tar.gz

I will answer some specific points in Jim's email below, but first, let me describe some limitations of SATE and how we are addressing them. SATE 2008 had a number of big limitations, including:

1) We analyzed a non-random subset of tool warnings
2) Determining correctness of tool warnings turned out to be more complicated than a binary true/false decision. Also, determining relevance of a warning to security turned out more difficult than we thought.
3) In most cases, we did not match warnings from different tools that refer to the same weakness. When we started SATE, we thought that we could match warnings by line number and weakness name or CWE id. In fact, most weaknesses are more complex - see Section 3.4 of our report.
4) Analysis criteria were applied inconsistently.

In our publicly released analysis, we used the confirmed/unconfirmed markings instead of true/false markings. We describe the reasons for this in our report - Section 4.2, page 29 of
http://samate.nist.gov/docs/NIST_Special_Publication_500-279.pdf

In SATE 2009, we made some improvements, including:

1) Randomly select a subset of tool warnings for analysis
2) We also looked at tool warnings that were related to human findings by security experts.
3) Use 4 categories for analysis of correctness: true, true but insignificant (for security), false, unknown.  It is an improvement, but there are still problems: for example distinguishing true from true but insignificant is often hard

> >  1) false positive rates from these tools are overwhelming
>    
First, defining a false positive is tough.  Also in SATE 2008, the criteria that we used for analysis of correctness were inconsistent, we did not analyze a random sample of warnings, our analysis had errors. Steve gave a good example in his reply. We corrected some of these problems in 2009, but still way to go

> >  2) the work load to triage results from ONE of these tools were
> >  man-years
>    
We are not the developers of the test cases, our knowledge of the test case code is very limited. Also, we used tools differently from their use in practice. We analyzed tool warnings for correctness and looked for related warnings from other tools, whereas developers use tools to determine what changes need to be made to software, auditors look for evidence of assurance.

> >  3) by every possible measurement, manual review was more cost effective
>    
As Steve said, SATE did not consider cost. In SATE 2009, we had security contractors analyze two of the test cases and report the most important security weaknesses. We then looked at tool warnings that report the same (or related) weakness. This will be released as part of 2009 release (The data set is too small for statistical conclusions.)

A big limitation of SATE has been the lack of ground truths about what security weaknesses really are in the test cases. This determination is hard for reasonably large software. We are trying to address this: manual analysis by security contractors, "CVE-selected" test cases.


> >  the NIST team chose only a small percentage of the automated findings to review
>    
A small percentage by itself should not be a problem if the selection of tool warnings is done correctly (it was not done correctly in SATE 2008).

Vadim


> I feel that NIST made a few errors in the first 2 SATE studies.
>
> After the second round of SATE, the results were never fully released 
> to the public - even when NIST agreed to do just that at the inception 
> of the contest. I do not understand why SATE censored the final 
> results - I feel such censorship hurts the industry.
>
> And even worse, I felt that vendor pressure encouraged NIST to not 
> release the final results. If the results (the real deep data, not the 
> executive summary that NIST release) were favorable to the tool 
> vendors, I bet they would have welcomed the release of the real data. 
> But instead, vendor pressure caused NIST to block the release of the 
> final data set.
>
> The problems that the data would have revealed is:
>
> 1) false positive rates from these tools are overwhelming
> 2) the work load to triage results from ONE of these tools were man-years
> 3) by every possible measurement, manual review was more cost effective
>
> Even worse were the methods around the process of this "study". For 
> example, all of the Java app's in this "study" contained poor hash 
> implementations. But because the tools (none of them) could see this, 
> that "finding" was completely ignored. The coverage was limited ONLY 
> to injection and data flow problems that tools have a chance of 
> finding. In fact, the NIST team chose only a small percentage of the 
> automated findings to review, since it would have taken years to 
> review everything due to the massive number of false positives. Get 
> the problem here?
>
> I'm discouraged by SATE. I hope some of these problems are addressed 
> in the third study.
>
> - Jim
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________


-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net


From ceng at veracode.com  Fri May 28 18:45:56 2010
From: ceng at veracode.com (Chris Eng)
Date: Fri, 28 May 2010 18:45:56 -0400
Subject: [SC-L] SATE
References: <4BFEE52F.40904@manico.net> 
Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD024CBD69D8@orbital.Veracode.local>

That should have been "made an identical post".


-----Original Message-----
From: Chris Eng 
Sent: Friday, May 28, 2010 6:51 PM
To: 'Jim Manico'; SC-L at securecoding.org
Subject: RE: [SC-L] SATE

Jim,

You made an identical to the WASC list, and Vadim Okun from NIST posted a detailed reply addressing many of your statements/accusations.  What is the point of cross-posting the same thing here, without at least incorporating his feedback into the discussion?

-chris


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Jim Manico
Sent: Thursday, May 27, 2010 5:34 PM
To: SC-L at securecoding.org
Subject: [SC-L] SATE

I feel that NIST made a few errors in the first 2 SATE studies.

After the second round of SATE, the results were never fully released to 
the public - even when NIST agreed to do just that at the inception of 
the contest. I do not understand why SATE censored the final results - I 
feel such censorship hurts the industry.

And even worse, I felt that vendor pressure encouraged NIST to not 
release the final results. If the results (the real deep data, not the 
executive summary that NIST release) were favorable to the tool vendors, 
I bet they would have welcomed the release of the real data. But 
instead, vendor pressure caused NIST to block the release of the final 
data set.

The problems that the data would have revealed is:

1) false positive rates from these tools are overwhelming
2) the work load to triage results from ONE of these tools were man-years
3) by every possible measurement, manual review was more cost effective

Even worse were the methods around the process of this "study". For 
example, all of the Java app's in this "study" contained poor hash 
implementations. But because the tools (none of them) could see this, 
that "finding" was completely ignored. The coverage was limited ONLY to 
injection and data flow problems that tools have a chance of finding. In 
fact, the NIST team chose only a small percentage of the automated 
findings to review, since it would have taken years to review everything 
due to the massive number of false positives. Get the problem here?

I'm discouraged by SATE. I hope some of these problems are addressed in 
the third study.

- Jim
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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
_______________________________________________


From gem at cigital.com  Tue Jun  1 21:10:59 2010
From: gem at cigital.com (Gary McGraw)
Date: Tue, 1 Jun 2010 21:10:59 -0400
Subject: [SC-L] Silver Bullet: Cyber War and Richard Clarke
Message-ID: <C82B27E3.22800%gem@cigital.com>

hi sc-l,

I'm more pleased than usual to announce the landmark 50th episode of Silver Bullet.  To celebrate the 50th  episode, we decided to shoot SB50 as a video as well as releasing the usual audio podcast.  My guest this episode is Richard A. Clarke.  Dick is an internationally-recognized expert on security, including homeland security, national security, cyber security, and counterterrorism.

We discuss lots of things in the podcast, but focus most of our attention on Cyber War and Dick's new book on the subject.  There is much controversy around cyber war and whether the threat is exaggerated.  Have a listen or a watch and see what you think:

http://www.cigital.com/silverbullet/

Special shouts out to Ryan Macmichael who both shot and produced the video for this podcast.  I think you'll agree that Ryan did a stunning job.

So what do you think, shall we shoot video when we can for Silver Bullet??

gem

company www.cigital.com
blog www.cigital.com/justiceleague
book www.swsec.com




From jim at manico.net  Wed Jun  9 15:40:06 2010
From: jim at manico.net (Jim Manico)
Date: Wed, 09 Jun 2010 09:40:06 -1000
Subject: [SC-L] [WEB SECURITY] SATE?
In-Reply-To: <Pine.GSO.4.64.1005271756090.6392@faron.mitre.org>
References: <4BFEE4CF.1090907@manico.net>
	<Pine.GSO.4.64.1005271756090.6392@faron.mitre.org>
Message-ID: <4C0FEE16.4060102@manico.net>

Fantastic SATE reply from Steven M. Christey:
>
> I participated in SATE 2008 and SATE 2009, much more actively in the 
> 2008 effort.  I'm not completely sure of the 2009 results and final 
> publication, as I've been otherwise occupied lately :-/ Looks like a 
> final report has been delayed till June (the SATE 2008 report didn't 
> get published till July 2009).
>
> For SATE 2008, we did not release final results because the human 
> analysis itself had too many false positives - so sometimes we claimed 
> a false positive when, in fact, the issue was a true positive.  Given 
> this and other data-quality problems (e.g. we only covered ~12% of the 
> more than 49,000 items), we believed that to release the raw data 
> would make it way too easy for people to make completely wrong 
> conclusions about the tools.
>
>> The problems that the data would have revealed is:
>>
>> 1) false positive rates from these tools are overwhelming
>
> As covered extensively in the 2008 SATE report (see my section for 
> example), there is no clear definition of "false positive" especially 
> when it comes to proving that a specific finding is a vulnerability.
>
> For example: suppose you have a report in a function of a buffer 
> overflow. To prove the finding is a vulnerability, you have to dig 
> back through all the data flow, sometimes going 20 levels deep.  This 
> is not feasible for a human evaluator to determine if there's really a 
> vulnerability.  Or, maybe the overflow happens when you're reading a 
> configuration file that's only under the control of the 
> administrator.  These could be regarded as false positives.  However, 
> the finding may be "locally true" - i.e. the function itself might not 
> do any validation at all, so *if* it's called incorrectly, an overflow 
> will occur.  My suspicion is that a lot of the "false positives" 
> people complain about are actually "locally true." And, as we saw in 
> SATE 2008 (and 2009 I suspect), sometimes the human evaluator is 
> actually wrong, and the finding is correct.  Hopefully we'll account 
> for "locally true" in the design of SATE 2010.
>
>> 2) the work load to triage results from ONE of these tools were 
>> man-years
>
> This was also covered (albeit estimated) in the 2008 SATE report, both 
> the original section and my section.
>
>> 3) by every possible measurement, manual review was more cost effective
>
> There was no consideration of cost in this sense.
>
> One lost opportunity for SATE 2008, however, was in comparing the 
> results from the manual-review participants (e.g. Aspect) versus the 
> tools in terms of what kinds of problems got reported.  (This also had 
> major implications for how to count number of results).  I believe 
> that such a focused effort would have shown some differences in what 
> got reported. At least, that's in the raw data since it shows who 
> claimed what got found.
>
> While the SATE 2008 report is quite long mostly thanks to my excessive 
> verbiage, I believe people who read that document will see that SATE 
> has been steadily improving its design over the years.  The reality is 
> that any study of this type is going to suffer from limited manpower 
> in evaluating the results.
>
> http://samate.nist.gov/docs/NIST_Special_Publication_500-279.pdf
>
>> The coverage was limited ONLY to injection and data flow problems 
>> that tools have a chance of finding. In fact, the NIST team chose 
>> only a small percentage of the automated findings to review, since it 
>> would have taken years to review everything due to the massive number 
>> of false positives. Get the problem here?
>
> While there were focused efforts in various types of issues, there was 
> also random sampling to get some exposure the wide range of problems 
> being reported by the tools.  Your critique of SATE with respect to 
> its focus on tools versus manual methods is understandable, but SATE 
> (and its parent SAMATE project) are really about understanding tools, 
> so this focus should not be a surprise.  After all, the first three 
> letters of SATE expand to "Static Analysis Tool."
>
> - Steve


From jim at manico.net  Wed Jun  9 15:40:55 2010
From: jim at manico.net (Jim Manico)
Date: Wed, 09 Jun 2010 09:40:55 -1000
Subject: [SC-L] [WEB SECURITY] SATE?
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49307A34EC20D@MBCLUSTER.xchange.nist.gov>
References: <4BFEE4CF.1090907@manico.net>
	<D7A0423E5E193F40BE6E94126930C49307A34EC20D@MBCLUSTER.xchange.nist.gov>
Message-ID: <4C0FEE47.8040106@manico.net>

Great SATE reply from Vadim Okun:

> We have been releasing the real deep data. There have been delays, but there are no sinister reasons for the delays.
>
> The results of the 2nd SATE (our report and all data) will be released in June (We promised to release between February and May, but we're late with the report).
>
> We released the results of the 1st SATE last summer: our report, the raw tool reports, and our analysis of the reports. The data is available (below the list of cautions) from
> http://samate.nist.gov/SATE2008.html
>
> or a direct link:
> http://samate.nist.gov/SATE2008/resources/sate2008.tar.gz
>
> I will answer some specific points in Jim's email below, but first, let me describe some limitations of SATE and how we are addressing them. SATE 2008 had a number of big limitations, including:
>
> 1) We analyzed a non-random subset of tool warnings
> 2) Determining correctness of tool warnings turned out to be more complicated than a binary true/false decision. Also, determining relevance of a warning to security turned out more difficult than we thought.
> 3) In most cases, we did not match warnings from different tools that refer to the same weakness. When we started SATE, we thought that we could match warnings by line number and weakness name or CWE id. In fact, most weaknesses are more complex - see Section 3.4 of our report.
> 4) Analysis criteria were applied inconsistently.
>
> In our publicly released analysis, we used the confirmed/unconfirmed markings instead of true/false markings. We describe the reasons for this in our report - Section 4.2, page 29 of
> http://samate.nist.gov/docs/NIST_Special_Publication_500-279.pdf
>
> In SATE 2009, we made some improvements, including:
>
> 1) Randomly select a subset of tool warnings for analysis
> 2) We also looked at tool warnings that were related to human findings by security experts.
> 3) Use 4 categories for analysis of correctness: true, true but insignificant (for security), false, unknown.  It is an improvement, but there are still problems: for example distinguishing true from true but insignificant is often hard.
>
>    
>> 1) false positive rates from these tools are overwhelming
>>      
> First, defining a false positive is tough.  Also in SATE 2008, the criteria that we used for analysis of correctness were inconsistent, we did not analyze a random sample of warnings, our analysis had errors. Steve gave a good example in his reply. We corrected some of these problems in 2009, but still way to go.
>
>    
>> 2) the work load to triage results from ONE of these tools were
>> man-years
>>      
> We are not the developers of the test cases, our knowledge of the test case code is very limited. Also, we used tools differently from their use in practice. We analyzed tool warnings for correctness and looked for related warnings from other tools, whereas developers use tools to determine what changes need to be made to software, auditors look for evidence of assurance.
>
>    
>> 3) by every possible measurement, manual review was more cost effective
>>      
> As Steve said, SATE did not consider cost. In SATE 2009, we had security contractors analyze two of the test cases and report the most important security weaknesses. We then looked at tool warnings that report the same (or related) weakness. This will be released as part of 2009 release (The data set is too small for statistical conclusions.)
>
> A big limitation of SATE has been the lack of ground truths about what security weaknesses really are in the test cases. This determination is hard for reasonably large software. We are trying to address this: manual analysis by security contractors, "CVE-selected" test cases.
>
>    
>> the NIST team chose only a small percentage of the automated findings to review
>>      
> A small percentage by itself should not be a problem if the selection of tool warnings is done correctly (it was not done correctly in SATE 2008).
>
> Vadim
>
> ________________________________________
> From: Jim Manico [jim at manico.net]
> Sent: Thursday, May 27, 2010 5:31 PM
> To: 'Webappsec Group'
> Subject: [WEB SECURITY] SATE?
>
> I feel that NIST made a few errors in the first 2 SATE studies.
>
> After the second round of SATE, the results were never fully released to
> the public - even when NIST agreed to do just that at the inception of
> the contest. I do not understand why SATE censored the final results - I
> feel such censorship hurts the industry.
>
> And even worse, I felt that vendor pressure encouraged NIST to not
> release the final results. If the results (the real deep data, not the
> executive summary that NIST release) were favorable to the tool vendors,
> I bet they would have welcomed the release of the real data. But
> instead, vendor pressure caused NIST to block the release of the final
> data set.
>
> The problems that the data would have revealed is:
>
> 1) false positive rates from these tools are overwhelming
> 2) the work load to triage results from ONE of these tools were man-years
> 3) by every possible measurement, manual review was more cost effective
>
> Even worse were the methods around the process of this "study". For
> example, all of the Java app's in this "study" contained poor hash
> implementations. But because the tools (none of them) could see this,
> that "finding" was completely ignored. The coverage was limited ONLY to
> injection and data flow problems that tools have a chance of finding. In
> fact, the NIST team chose only a small percentage of the automated
> findings to review, since it would have taken years to review everything
> due to the massive number of false positives. Get the problem here?
>
> I'm discouraged by SATE. I hope some of these problems are addressed in
> the third study.
>
> - Jim
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>    


From listas at sapao.net  Fri Jun 11 15:18:46 2010
From: listas at sapao.net (Lucas Ferreira)
Date: Fri, 11 Jun 2010 16:18:46 -0300
Subject: [SC-L] OWASP AppSec Brasil 2010 - Call for training providers
In-Reply-To: <AANLkTinVWOdxwbkzRFbM8La21r5hevxumz4xjW0w21zF@mail.gmail.com>
References: <AANLkTinVWOdxwbkzRFbM8La21r5hevxumz4xjW0w21zF@mail.gmail.com>
Message-ID: <AANLkTilYFvDscCrXu8p4ZWTnc8Et12hl7yiFgWrG-TW7@mail.gmail.com>

**OWASP APPSEC BRASIL 2010**
**CALL FOR TRAINING SESSIONS**

Colleagues,

OWASP is currently soliciting training proposals for the OWASP
AppSec Brazil 2010 Conference which will take place at Funda??o CPqD
in Campinas, SP, Brazil, on November 16 through November 19, 2010.
There will be training courses on November 16 and 17 followed by
plenary sessions on the 18 and 19 with one single track per day.

We are seeking training proposals on the following topics (in no
particular order):
- Application Threat ModelingOWASP Tools and Projects
- Privacy Concerns with Applications and Data Storage
- Secure Coding Practices (J2EE/.NET)
- Starting and Managing Secure Development Lifecycle Programs
- Technology specific presentations on security such as AJAX, XML, etc
- Web Application Security countermeasures
- Web Application Security Testing
- Web Services, XML- and Application Security
- Anything else relating to OWASP and Application Security

Proposals on topics not listed above but related to the conference
(i.e. which are related to Application Security) may also be accepted.

To make a submission you must fill out the form available at
http://www.owasp.org/images/1/1a/OWASP_AppSec_Brasil_2010_CFT.rtf.zip
and submit by email to organizacao2010 at appsecbrasil.org

There may be 1 or 2-day courses. The proposals must respect the
restrictions of the OWASP Speaker Agreement. The conference will
reward trainers with at least 30% of the total revenue of their
courses, based on a minimum attendance. Courses that attract more
students may be granted higher percentages. No other compensation
(such as tickets or lodging) will be provided. If you require a
different arrangement, please contact the conference chair at the
email address below.

**Compensation**
Instructors and authors will be paid based on the number of students
in their training sessions. If the training gathers only the minimum
number of students, the compensation will be 30% of the revenue. For
each group of 10 extra students enrolled, the compensation will be
increased by 5% of the revenue, up to a maximum of 45% of the training
revenue. For example, a 1-day training with 10 to 19 students will
generate a compensation of 30% of the revenue. For classes of 20 to 29
students, the compensation raises to 35% percent of the revenue.

In exceptional cases, different compensation schemes may be accepted.
Please contact the conference organization team by email
(organizacao2010 at appsecbrasil.org) for details.

**Training cost**
?1-day training: R$ 450 per student
?2-day training: R$ 900 per student
All prices in Brazilian Reais (BRL)

**Minimum number of students**
?1-day trainings: 10 students
?2-day trainings: 20 students

**Important Dates:**
?Submission deadline is July 26, 2010, at 11:59 PM (UTC/GMT-3).
?Notification of acceptance will be August 16, 2010.
?Final version is due September 15, 2010.

The conference organization team may be contacted by email at
organizacao2010 (at) appsecbrasil.org

For more information, please see the following web pages:
?Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2010
?OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement
?OWASP Website: http://www.owasp.org
?Easychair conference site:
http://www.easychair.org/conferences/?conf=appsecbr2010
?Presentation proposal form:
http://www.owasp.org/images/1/1a/OWASP_AppSec_Brasil_2010_CFT.rtf.zip

********** WARNING: Submissions without all the information requested
in the proposal form will not be considered ************

Please forward to all interested practitioners and colleagues.


From ge at linuxbox.org  Sat Jun 12 20:40:43 2010
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 13 Jun 2010 03:40:43 +0300
Subject: [SC-L] Unreal IRCd backdoor
Message-ID: <4C14290B.90108@linuxbox.org>

Very interesting post by Fyodor:
http://seclists.org/nmap-dev/2010/q2/826

	Gadi.

From cwysopal at veracode.com  Mon Jun 14 10:14:57 2010
From: cwysopal at veracode.com (Chris Wysopal)
Date: Mon, 14 Jun 2010 10:14:57 -0400
Subject: [SC-L] IEEE: Are Companies Actually Using Secure Development Life
	Cycles?
Message-ID: <5A9D3476391AD649B24ED4F9FDA2A8DD024CDB7239@orbital.Veracode.local>


Are Companies Actually Using Secure Development Life Cycles?
http://www.computer.org/portal/c/document_library/get_file?uuid=a3f6e887-36f9-4768-8cdc-104d7e1c49ca&groupId=53319

As threats to applications have increased, developers have begun including security in their software design. Secure development life cycles are methodologies for accomplishing this, but are companies actually using SDLs?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100614/22bd768b/attachment.htm>

From gem at cigital.com  Thu Jun 17 12:27:09 2010
From: gem at cigital.com (Gary McGraw)
Date: Thu, 17 Jun 2010 12:27:09 -0400
Subject: [SC-L] More on Cyber War
Message-ID: <C83FC51D.230AA%gem@cigital.com>

hi sc-l,

Debates on the radio.  Pundits on TV.  Cyber War seems to be generating lots of attention in the media.  I scribbled down my thoughts in this month's informIT column:

http://www.informit.com/articles/article.aspx?p=1597476   Cyber War - Hype or Consequences?

Other references of note include my video podcast with Richard A. Clarke of 9-11 and cyber czar fame (Silver Bullet 50):
http://www.cigital.com/silverbullet/show-050/

And a review of Clarke's book on Justice League:
http://www.cigital.com/justiceleague/2010/05/06/is-cyber-war-inevitable/

I'm ff to the beach for some much needed vacation.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


From floodeen at gmail.com  Fri Jun 18 12:23:28 2010
From: floodeen at gmail.com (Rob Floodeen)
Date: Fri, 18 Jun 2010 12:23:28 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <C83FC51D.230AA%gem@cigital.com>
References: <C83FC51D.230AA%gem@cigital.com>
Message-ID: <AANLkTin6ghy7kToUeIJUI8IsH1a9o5zfDXoxQYG1Bym-@mail.gmail.com>

Hi Gary,

Discussion on your article.  You write "Plus the technical
sophistication of those attacks was quite low. It's abundantly clear
that similar attacks against popular U.S. e-commerce websites (Amazon
or Google) would fizzle to the point of not even being noticed."

I don't think technical sophistication should be an indication of
warfare or an attack for any definition.  I do like the kinetic
aspect, but we should also include intent. But how can we do
attribution to determine intent?

Next the activity of Amazon and Google would be LE not Military, again
outside the scope of "Cyber War".  By the way, can we stop saying it.
It makes me feel dirty like when the word "cracker" found it's way
onto the scene.

My two cents,
-Rob F.






On Thu, Jun 17, 2010 at 12:27 PM, Gary McGraw <gem at cigital.com> wrote:
> hi sc-l,
>
> Debates on the radio. ?Pundits on TV. ?Cyber War seems to be generating lots of attention in the media. ?I scribbled down my thoughts in this month's informIT column:
>
> http://www.informit.com/articles/article.aspx?p=1597476 ? Cyber War - Hype or Consequences?
>
> Other references of note include my video podcast with Richard A. Clarke of 9-11 and cyber czar fame (Silver Bullet 50):
> http://www.cigital.com/silverbullet/show-050/
>
> And a review of Clarke's book on Justice League:
> http://www.cigital.com/justiceleague/2010/05/06/is-cyber-war-inevitable/
>
> I'm ff to the beach for some much needed vacation.
>
> 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 at 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
> _______________________________________________
>


From secureCoding2dave at davearonson.com  Fri Jun 18 14:10:10 2010
From: secureCoding2dave at davearonson.com (Dave Aronson)
Date: Fri, 18 Jun 2010 14:10:10 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <AANLkTin6ghy7kToUeIJUI8IsH1a9o5zfDXoxQYG1Bym-@mail.gmail.com>
References: <C83FC51D.230AA%gem@cigital.com>
	<AANLkTin6ghy7kToUeIJUI8IsH1a9o5zfDXoxQYG1Bym-@mail.gmail.com>
Message-ID: <AANLkTimMgyFKvJKb6Mzy071p2k0TJD3Fu_KQL6ue2COl@mail.gmail.com>

Don't forget about the millionaire cyber-terrorist, osama:/bin/login.  ;-)

-- 
Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
-------------------------------------+ Play: davearonson.net | \/ Ribbon
"Specialization is for insects."     | Life: dare2xl.com     | /\ Campaign
-Robert A. Heinlein                  | Wife: nasjleti.net    | Email<>Web

From gem at cigital.com  Fri Jun 18 23:06:44 2010
From: gem at cigital.com (Gary McGraw)
Date: Fri, 18 Jun 2010 23:06:44 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <AANLkTin6ghy7kToUeIJUI8IsH1a9o5zfDXoxQYG1Bym-@mail.gmail.com>
Message-ID: <C841AC84.23142%gem@cigital.com>

Maybe Rob.

I'm pretty sure if the Canadians started throwing rocks over the border we would have a hard time calling that an act of war.  I think maybe the kinetic idea rescues me here again?!

But who cares.  I'm going to the beach.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On 6/18/10 12:23 PM, "Rob Floodeen" <floodeen at gmail.com> wrote:

Hi Gary,

Discussion on your article.  You write "Plus the technical
sophistication of those attacks was quite low. It's abundantly clear
that similar attacks against popular U.S. e-commerce websites (Amazon
or Google) would fizzle to the point of not even being noticed."

I don't think technical sophistication should be an indication of
warfare or an attack for any definition.  I do like the kinetic
aspect, but we should also include intent. But how can we do
attribution to determine intent?

Next the activity of Amazon and Google would be LE not Military, again
outside the scope of "Cyber War".  By the way, can we stop saying it.
It makes me feel dirty like when the word "cracker" found it's way
onto the scene.

My two cents,
-Rob F.






On Thu, Jun 17, 2010 at 12:27 PM, Gary McGraw <gem at cigital.com> wrote:
> hi sc-l,
>
> Debates on the radio.  Pundits on TV.  Cyber War seems to be generating lots of attention in the media.  I scribbled down my thoughts in this month's informIT column:
>
> http://www.informit.com/articles/article.aspx?p=1597476   Cyber War - Hype or Consequences?
>
> Other references of note include my video podcast with Richard A. Clarke of 9-11 and cyber czar fame (Silver Bullet 50):
> http://www.cigital.com/silverbullet/show-050/
>
> And a review of Clarke's book on Justice League:
> http://www.cigital.com/justiceleague/2010/05/06/is-cyber-war-inevitable/
>
> I'm ff to the beach for some much needed vacation.
>
> 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 at 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
> _______________________________________________
>



From tomhave at secureconsulting.net  Mon Jun 21 06:53:00 2010
From: tomhave at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 21 Jun 2010 06:53:00 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <C83FC51D.230AA%gem@cigital.com>
References: <C83FC51D.230AA%gem@cigital.com>
Message-ID: <4C1F448C.8080706@secureconsulting.net>

I love how Howard Schmidt's voice seems to have been lost in the fray,
since his comments came way back in March at RSA.
http://www.wired.com/threatlevel/2010/03/schmidt-cyberwar/

Quote:
"There is no cyberwar," Schmidt told Wired.com in a sit-down interview
Wednesday at the RSA Security Conference in San Francisco.

"I think that is a terrible metaphor and I think that is a terrible
concept,? Schmidt said. ?There are no winners in that environment."

Instead, Schmidt said the government needs to focus its cybersecurity
efforts to fight online crime and espionage.


We should all be used to this drum beat by now, though. This is at least
the 3rd consecutive year (maybe even more like 5th) where there has been
rhetoric about "cyberwar". In previous years it was Air Force generals
posturing for a "cyber command". Now it's Senators (and DHS?) who are
doing the posturing. Asinine? Yes, but isn't much of pure politicking?

fwiw.

-ben

On 6/17/10 12:27 PM, Gary McGraw wrote:
> hi sc-l,
> 
> Debates on the radio.  Pundits on TV.  Cyber War seems to be
> generating lots of attention in the media.  I scribbled down my
> thoughts in this month's informIT column:
> 
> http://www.informit.com/articles/article.aspx?p=1597476   Cyber War -
> Hype or Consequences?
> 
> Other references of note include my video podcast with Richard A.
> Clarke of 9-11 and cyber czar fame (Silver Bullet 50): 
> http://www.cigital.com/silverbullet/show-050/
> 
> And a review of Clarke's book on Justice League: 
> http://www.cigital.com/justiceleague/2010/05/06/is-cyber-war-inevitable/
>
>  I'm ff to the beach for some much needed vacation.
> 
> 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 at 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 
> _______________________________________________
> 
> 

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Occam's Razor: "The explanation requiring the fewest assumptions is most
likely to be correct."
http://globalnerdy.com/2007/07/18/laws-of-software-development/

From haroon at thinkst.com  Tue Jun 22 16:00:50 2010
From: haroon at thinkst.com (Haroon Meer)
Date: Tue, 22 Jun 2010 22:00:50 +0200
Subject: [SC-L] More on Cyber War
In-Reply-To: <4C1F448C.8080706@secureconsulting.net>
References: <C83FC51D.230AA%gem@cigital.com>
	<4C1F448C.8080706@secureconsulting.net>
Message-ID: <AANLkTilJtnkxdWYJN8aH_mIDCWR5BPSV5Xz1m6oo6JLm@mail.gmail.com>

Hi..

On Mon, Jun 21, 2010 at 12:53 PM, Benjamin Tomhave
<tomhave at secureconsulting.net> wrote:
> I love how Howard Schmidt's voice seems to have been lost in the fray,
> since his comments came way back in March at RSA.
> http://www.wired.com/threatlevel/2010/03/schmidt-cyberwar/

Would have considered it slightly off-list-topic, but the current
thread seems to allow it in :>

My slides from the 2010 Conference on Cyber Conflict are now online at
[http://blog.thinkst.com/2010/06/conference-on-cyber-conflict-slides.html]

Comments / Flames / Feedback is always welcome..

/mh

-- 
Haroon Meer		http://thinkst.com/
Tel: +27 83 786 6637	PGP: http://thinkst.com/pgp/haroon.txt

From tomhave at secureconsulting.net  Tue Jun 22 16:20:50 2010
From: tomhave at secureconsulting.net (Benjamin Tomhave)
Date: Tue, 22 Jun 2010 16:20:50 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <AANLkTilJtnkxdWYJN8aH_mIDCWR5BPSV5Xz1m6oo6JLm@mail.gmail.com>
References: <C83FC51D.230AA%gem@cigital.com>	<4C1F448C.8080706@secureconsulting.net>
	<AANLkTilJtnkxdWYJN8aH_mIDCWR5BPSV5Xz1m6oo6JLm@mail.gmail.com>
Message-ID: <4C211B22.5010707@secureconsulting.net>

On 6/22/10 4:00 PM, Haroon Meer wrote:
> Hi..
> 
Howdy!

> Would have considered it slightly off-list-topic, but the current
> thread seems to allow it in :>
> 
It's Gary's fault! (we can blame him since he's on vacation:)

> My slides from the 2010 Conference on Cyber Conflict are now online at
> [http://blog.thinkst.com/2010/06/conference-on-cyber-conflict-slides.html]
> 
An interesting presentation, consistent with others I've seen on the
topic. The problem around the "cyberwar" (or "cyber conflict") stuff is
definitional. We need to be extremely careful using the word "war" as it
tends to have very specific connotations. You also get into issues about
defining what is or isn't "critical infrastructure" and the degree of
direct responsibility the government should own for responding to, or
coordinating response to, a major incident. Putting it in context for
this list, one extreme could say that everything considered "critical
infrastructure" could be subject from direct government oversight,
including requirements for appsec and secure coding, complete with
DoD/comparable testing, C&A, etc. fwiw.

-ben

-- 
Benjamin Tomhave, MS, CISSP
tomhave at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Confidence is contagious. So is lack of confidence."
Vince Lombardi

From floodeen at gmail.com  Wed Jun 23 09:23:04 2010
From: floodeen at gmail.com (Rob Floodeen)
Date: Wed, 23 Jun 2010 09:23:04 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <AANLkTilJtnkxdWYJN8aH_mIDCWR5BPSV5Xz1m6oo6JLm@mail.gmail.com>
References: <C83FC51D.230AA%gem@cigital.com>
	<4C1F448C.8080706@secureconsulting.net>
	<AANLkTilJtnkxdWYJN8aH_mIDCWR5BPSV5Xz1m6oo6JLm@mail.gmail.com>
Message-ID: <AANLkTikB-oLXh6oaQ9dCOinH68BVDZmjcTMZ6HY_sYn6@mail.gmail.com>

Haroon Meer,

Thanks for the slide show.  I liked it.  The concept of taking things
we all know and putting a few concrete examples on it is just great.
Specifically the ones you used.  More so, I also liked the way you
presented the slide deck with written comments and documented the
presentation.  (I'll be borrowing that)

So my question to the list, does anyone have something similar but
more specifically to secure coding?  A recent presentation, examples,
future trends, etc.  I'd be interested in seeing recent presentations.

-Rob

On Tue, Jun 22, 2010 at 4:00 PM, Haroon Meer <haroon at thinkst.com> wrote:
> Hi..
>
> On Mon, Jun 21, 2010 at 12:53 PM, Benjamin Tomhave
> <tomhave at secureconsulting.net> wrote:
>> I love how Howard Schmidt's voice seems to have been lost in the fray,
>> since his comments came way back in March at RSA.
>> http://www.wired.com/threatlevel/2010/03/schmidt-cyberwar/
>
> Would have considered it slightly off-list-topic, but the current
> thread seems to allow it in :>
>
> My slides from the 2010 Conference on Cyber Conflict are now online at
> [http://blog.thinkst.com/2010/06/conference-on-cyber-conflict-slides.html]
>
> Comments / Flames / Feedback is always welcome..
>
> /mh
>
> --
> Haroon Meer ? ? ? ? ? ? http://thinkst.com/
> Tel: +27 83 786 6637 ? ?PGP: http://thinkst.com/pgp/haroon.txt
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________
>


From jjchryan at gwu.edu  Wed Jun 23 09:36:03 2010
From: jjchryan at gwu.edu (Julie Ryan)
Date: Wed, 23 Jun 2010 09:36:03 -0400
Subject: [SC-L] More on Cyber War
In-Reply-To: <4C211B22.5010707@secureconsulting.net>
References: <C83FC51D.230AA%gem@cigital.com>
	<4C1F448C.8080706@secureconsulting.net>
	<AANLkTilJtnkxdWYJN8aH_mIDCWR5BPSV5Xz1m6oo6JLm@mail.gmail.com>
	<4C211B22.5010707@secureconsulting.net>
Message-ID: <69D0E2A4-1D5F-45ED-BEE1-8C9927C8BAA3@gwu.edu>

Ben,

You're right, and that's the whole point of the conference.  You should consider coming next year.  I think you'd be particularly interested in the discussions on the Laws of Armed Conflict.

In the meantime, conference content is being discussed on linkedin, with a wonderful summary of the Legal and Policy track presentations by Eneken Tikk, in the group Cyber Security Forum Initiative (Law and Policy Division).

Also, the conference materials should eventually be made available on the website at 
http://www.ccdcoe.org/conference2010/

Julie


On Jun 22, 2010, at 4:20 PM, Benjamin Tomhave wrote:

> On 6/22/10 4:00 PM, Haroon Meer wrote:
>> Hi..
>> 
> Howdy!
> 
>> Would have considered it slightly off-list-topic, but the current
>> thread seems to allow it in :>
>> 
> It's Gary's fault! (we can blame him since he's on vacation:)
> 
>> My slides from the 2010 Conference on Cyber Conflict are now online at
>> [http://blog.thinkst.com/2010/06/conference-on-cyber-conflict-slides.html]
>> 
> An interesting presentation, consistent with others I've seen on the
> topic. The problem around the "cyberwar" (or "cyber conflict") stuff is
> definitional. We need to be extremely careful using the word "war" as it
> tends to have very specific connotations. You also get into issues about
> defining what is or isn't "critical infrastructure" and the degree of
> direct responsibility the government should own for responding to, or
> coordinating response to, a major incident. Putting it in context for
> this list, one extreme could say that everything considered "critical
> infrastructure" could be subject from direct government oversight,
> including requirements for appsec and secure coding, complete with
> DoD/comparable testing, C&A, etc. fwiw.
> 
> -ben
> 
> -- 
> Benjamin Tomhave, MS, CISSP
> tomhave at secureconsulting.net
> Blog: http://www.secureconsulting.net/
> Twitter: http://twitter.com/falconsview
> LI: http://www.linkedin.com/in/btomhave
> 
> [ Random Quote: ]
> "Confidence is contagious. So is lack of confidence."
> Vince Lombardi
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________



From jeremy.j.epstein at gmail.com  Thu Jun 24 09:39:03 2010
From: jeremy.j.epstein at gmail.com (Jeremy Epstein)
Date: Thu, 24 Jun 2010 09:39:03 -0400
Subject: [SC-L] One day software security awareness training?
Message-ID: <AANLkTinBLDtLKvaNk2nqswkUfffhmCNTZbJD2a6q8RX1@mail.gmail.com>

All,

I'm looking for a one day software security awareness training class for a
client.  Yes, I know one day isn't enough to teach what people need to know,
but I'll be lucky if I can get them to spend that long.  (The initial
reaction to my recommendation was "no way".)

My goal is for them to learn basics like:
- How adversaries work
- Types of tools (static analysis, dynamic analysis, fuzzing)
- Architectural concerns (e.g., don't implement security in an uncontrolled
client)
- Basic code dos & don't - OWASP top 10 / SANS top 25 types of things

System they're building is in Java & Flex.

If you sell such training, please contact me OFF list so this doesn't become
an advertisement.  If you have a recommendation for a course you've taken,
I'd definitely like to hear about it!

Thanks,
--Jeremy

P.S. If geography matters, the client has distributed development between a
US east coast location and a US mountain location.  Open to whether training
would be at one of their locations or bring their people to a site.  It's
only about 15 developers, so definitely not worth a custom course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100624/e452f22c/attachment.htm>

From rcs at cert.org  Fri Jun 25 11:20:17 2010
From: rcs at cert.org (Robert Seacord)
Date: Fri, 25 Jun 2010 11:20:17 -0400
Subject: [SC-L] recent technical reports from the CERT Secure Coding
	Initiative
In-Reply-To: <AANLkTinBLDtLKvaNk2nqswkUfffhmCNTZbJD2a6q8RX1@mail.gmail.com>
References: <AANLkTinBLDtLKvaNk2nqswkUfffhmCNTZbJD2a6q8RX1@mail.gmail.com>
Message-ID: <C10B9E3687C68B4D98F6ADFD3C3CDDB7015842319FE1@EXCHANGE.sei.cmu.edu>

The Secure Coding Initiative at CERT has published several TRs recently.  Sorry I've been slow in sending out updates to the list.

Please let me know if you have any questions about any of these reports or are interested in collaborating with CERT to advance these projects.

Thanks,
rCs

________________________________

Java Concurrency Guidelines

Fred Long, Dhruv Mohindra, Robert Seacord, & David Svoboda
CMU/SEI-2010-TR-015



An essential element of secure coding in the Java programming language is well-documented and enforceable coding standards. Coding standards encourage programmers to follow a uniform set of guidelines determined by the requirements of the project and organization, rather than by the programmer's familiarity or preference. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes).

The CERT Oracle Secure Coding Standard for Java provides guidelines for secure coding in the Java programming language. The goal of these guidelines is to eliminate insecure coding practices and undefined behaviors that can lead to exploitable vulnerabilities. Applying this standard will lead to higher quality systems that are robust and more resistant to attack.

This report documents the portion of those Java guidelines that are related to concurrency.

________________________________

keywords: Java, concurrency, software security, coding standard, coding guidelines

cover date: May 2010

distribution: unlimited

editor: Pennie Walters (pw at sei.cmu.edu<mailto:pw at sei.cmu.edu>)
www.sei.cmu.edu/library/abstracts/reports/10tr015.cfm<http://www.sei.cmu.edu/library/abstracts/reports/10tr015.cfm>
________________________________

As-If Infinitely Ranged Integer Model, Second Edition
Roger Dannenberg, Will Dormann, David Keaton, Thomas Plum, Robert C. Seacord, David Svoboda, Alex Volkovitsky, & Timothy Wilson

CMU/SEI-2010-TN-008



Integers represent a growing and underestimated source of vulnerabilities in C and C++ programs. This report presents the as-if infinitely ranged (AIR) integer model that provides a largely automated mechanism for eliminating integer overflow and truncation and other integral exceptional conditions. The AIR integer model either produces a value equivalent to that obtained using infinitely ranged integers or results in a runtime-constraint violation. Instrumented fuzz testing of libraries that have been compiled using a prototype AIR integer compiler has been effective in discovering vulnerabilities in software with low false positive and false negative rates.  Furthermore, the runtime overhead of the AIR integer model is low enough for typical applications to enable it in deployed systems for additional runtime protection.

________________________________

keywords: security, standardization, languages, verification, reliability, fuzz testing, software security, integral security, secure coding

cover date: April 2010

distribution: unlimited

editor: Pennie Walters (pw at sei.cmu.edu<mailto:pw at sei.cmu.edu>)
http://www.sei.cmu.edu/library/abstracts/reports/10tn008.cfm
________________________________

Specifications for Managed Strings, Second Edition
Hal Burch, Fred Long, Raunak Rungta, Robert C. Seacord, & David Svoboda

CMU/SEI-2010-TR-018



This report describes a managed string library for the C programming language. Many software vulnerabilities in C programs result from the misuse of manipulation functions for standard C strings. Programming errors common to string-manipulation logic include buffer overflow, truncation errors, string termination errors, and improper data sanitization. The managed string library provides mechanisms to eliminate or mitigate these problems and improve system security. The CERT Program, which is part of the Carnegie Mellon Software Engineering Institute, provides a proof-of-concept implementation of the managed string library on its Secure Coding web pages.

________________________________

keywords: string library, software security, C programming, runtime-constraint handling

cover date: May 2010

distribution: unlimited

editor: Paul Ruggiero (pruggiero at sei.cmu.edu<mailto:pruggiero at sei.cmu.edu>)
www.sei.cmu.edu/library/abstracts/reports/10tr018.cfm<http://www.sei.cmu.edu/library/abstracts/reports/10tr018.cfm>

Thanks,
rCs

----
Robert C. Seacord
Secure Coding Team Lead
CERT / Software Engineering Institute
Work: +1 412.268.7608
FAX:    +1 412.268.6989
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100625/1cd50a82/attachment.htm>

From gem at cigital.com  Tue Jul  6 08:39:23 2010
From: gem at cigital.com (Gary McGraw)
Date: Tue, 6 Jul 2010 08:39:23 -0400
Subject: [SC-L] Silver Bullet 51: Anup Ghosh
Message-ID: <C8589C3B.23419%gem@cigital.com>

hi sc-l,

On June 25th, we posted the 51st episode of Silver Bullet, featuring Dr. Anup Ghosh.  Anup and I worked together for several years when Anup ran Cigital Labs.  After a long stint at DARPA, Anup is back in startup mode with his new company invincea (invisible virtualized browser wrapping).   Have a listen to episode 51:

http://www.cigital.com/silverbullet/show-051/

As always, your feedback and comments are welcome.  Sorry for the delay getting the word out on this one...I've been off the net at the beach for a couple of weeks.

gem

company www.cigital.com
blog www.cigital.com/justiceleague
book www.swsec.com


From stacy at safecode.org  Thu Jul  8 11:28:43 2010
From: stacy at safecode.org (Stacy Simpson)
Date: Thu, 08 Jul 2010 11:28:43 -0400
Subject: [SC-L] Brainstorm 2020: A Vision for Software Security
Message-ID: <C85B66EB.F7CB%stacy@safecode.org>

All,

I wanted to invite you to Brainstorm 2020: A Vision for Software Security at
Black Hat USA 2010.  Hosted by SAFECode, the event will be a community
brainstorm designed to help us define a shared vision for software security
and identify new, forward-thinking ideas about how to make it happen.

SAFECode invites you to grab the mic and share your thoughts on two key
questions:

    * What should our vision be for software security in 2020?
    * What are your ideas for leap-ahead approaches to advance software
security over the next ten years?

Brainstorm 2020 will be held on Tuesday, July 27 at 5:00 p.m. at Caesars
Palace in Las Vegas.

Attendance is free, but registration is required and space is limited, so
please register today. You have the option to submit your ideas on the
questions above when you register, or you can wait to present them at the
event ? it?s your choice.   And if you can?t attend but have an idea to
share, go ahead and submit it now.  Selected ideas collected through the
website from those unable to attend will be presented by our panelists with
your permission and all ideas collected online and at the event will be
considered by SAFECode for future work.

For more information and to register, please visit
http://www.safecode.org/register.php
-- 
Stacy Simpson
Software Assurance Forum for Excellence in Code (SAFECode)
stacy at safecode.org 
www.safecode.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100708/6f38d644/attachment.htm>

From gem at cigital.com  Fri Jul 16 11:27:22 2010
From: gem at cigital.com (Gary McGraw)
Date: Fri, 16 Jul 2010 11:27:22 -0400
Subject: [SC-L] Cyber Security at the White House
Message-ID: <C865F29A.23AD4%gem@cigital.com>

hi sc-l,

I was honored to be among the invited guests at the White House cyber security meeting on Wednesday.  When President Obama walked into the room (unannounced and not really expected), it was very exciting!

I wrote up my impression of the meeting and progress in US cyber security for my informIT column this month:
Obama Highlights Cyber Security Progress
http://www.informit.com/articles/article.aspx?p=1617137

There are a couple of pictures I took on the Justice League blog:
http://www.cigital.com/justiceleague/2010/07/16/cigital-participates-in-white-house-discussion-on-the-progress-of-the-president%E2%80%99s-cybersecurity-efforts/

Your public (or private) feedback on the articles is most welcome.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


From andrews at rbacomm.com  Mon Jul 19 18:09:56 2010
From: andrews at rbacomm.com (Brad Andrews)
Date: Mon, 19 Jul 2010 17:09:56 -0500
Subject: [SC-L] Secure Development Related PhD Work
Message-ID: <3405235E4C494DB1B34BB6CA5C610223@Havilah>

I am considering many things for my own future at this point in time and one possibility is to return and earn the PhD I interrupted many years ago.  If anyone knows a professor working in the area of secure development, including training developers on the topic (my M.S. was in C.S. from Illinois and focused on CBT-related themes), please let me know.

I am open to many options now and would also consider employment work in that area if anyone knows of an ideal job for someone with 20+ development and 4+ years of infosec experience, including a lot of compliance work.  I am located in the Dallas area now, but open to moving for the right opportunity.

Please contact me off the list with any information.  :)

I can summarize the PhD findings if anyone is interested.

--------------------------------

Brad Andrews
andrews at rbacomm.com
CISM, CSSLP, GSEC, GCIH, GCIA, GCFW, GPCI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100719/93df79ef/attachment.htm>

From gem at cigital.com  Wed Jul 21 10:55:37 2010
From: gem at cigital.com (Gary McGraw)
Date: Wed, 21 Jul 2010 10:55:37 -0400
Subject: [SC-L] Silver Bullet 52: Paul Kocher
Message-ID: <C86C82A9.23C5E%gem@cigital.com>

hi sc-l,

Paul Kocher has been a good friend for over a decade.  Paul worked closely with me in the mid-90s "smart card wars" when we did lots of work for Visa International and Mastercard.  Paul invented DPA back then while we were busy hacking Java-based cards with malicious applets at Cigital.

Silver Bullet 52 is a conversation with Paul.  What makes Paul particularly interesting is his blend of entrepreneurial business savvy and very deep hands-on technical knowledge---rare on this planet.  Paul has a clear understanding of the software security problem and its interaction with hardware security.

Have a listen and as always, your feedback is welcome
http://www.cigital.com/silverbullet/show-052/

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


From coley at linus.mitre.org  Thu Jul 22 17:52:38 2010
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 22 Jul 2010 17:52:38 -0400 (EDT)
Subject: [SC-L] Job Posting: Software Assurance at MITRE
Message-ID: <Pine.GSO.4.64.1007221747250.8067@faron.mitre.org>


Apologies ahead of time to SC-L subscribers who do not want to see job 
postings; Ken said it was OK.

MITRE, a "Fortune 100 Best Company To Work For" corporation, is seeking a 
Software Systems Engineer to provide expertise in the area of software 
security.  The ideal candidate would have broad, deep knowledge of the 
types of vulnerabilities that occur throughout the SDLC; their associated 
mitigations; techniques for security-relevant static and dynamic analysis 
of code, including their strengths and limitations; and methodologies for 
testing and evaluating automated code scanning tools, including 
development of test cases.

The primary work will involve understanding and improving the state of the 
art in techniques for detecting and preventing software vulnerabilities in 
source/binary code, in collaboration with government, industry, and 
academia.

10+ years of relevant experience strongly preferred, including 5+ years in 
software assurance or closely-related disciplines, with an ability to work 
independently and be responsible for deliverables within a team 
environment, spanning 6 months or longer.  Real-world knowledge of 
software testing frameworks desired.  Solid knowledge of C, C++, and Java 
strongly preferred.  Experience in custom software development or 
scripting a plus.  Excellent oral and written communication skills 
strongly preferred.  Less-experienced individuals with demonstrable talent 
and expertise are welcome to apply.

Strong preference will be given to candidates who can live near our 
locations in Bedford, Massachusetts or McLean, Virginia.

U.S. citizenship is required.

If you are interested, please contact me with your resume, preferably by 
August 3.  We plan to fill this position within a month or two.


Thank you,
Steve Christey

From cyounkins at gmail.com  Mon Jul 26 11:56:51 2010
From: cyounkins at gmail.com (Craig Younkins)
Date: Mon, 26 Jul 2010 11:56:51 -0400
Subject: [SC-L] Python Security
Message-ID: <AANLkTi=bDu_bUpemWzFk6nBVCdKv-XGX32mncPHobQ_K@mail.gmail.com>

Hello fellow secure coders! My name is Craig Younkins. I'm an intern at
OWASP, the Open Web Application Security Project, and this summer I'm
focusing on web security in Python. I'm helping Python developers make
more secure web applications.

I'd like to invite you to a new community - http://www.pythonsecurity.org/ -
which is now the central hub for security in Python. We're writing articles
on security topics and how they pertain to Python, analyzing the security of
Python software, and providing a forum where developers can get answers to
their Python security questions.

Interested? Great!
* If you have open-source Python software, the best thing you can do is
contribute to the wiki page for your software by explaining the security
controls, their implementations, and usage.
* If you haven't written open-source Python software, that's OK too. We'd
love your help on our currently targeted wiki page for Django [1].
* If you're not a Python programmer you can still contribute to our pages on
general security topics [2]. These pages include general information as well
as Python-specific information about the what, how, and why of security
controls.

Thanks!

Craig Younkins

[1] http://www.pythonsecurity.org/wiki/django/
[2] http://www.pythonsecurity.org/wiki/topics/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100726/b3b5678b/attachment.htm>

From rajiv.x.sharma at oracle.com  Tue Jul 27 15:26:59 2010
From: rajiv.x.sharma at oracle.com (Rajiv Sharma)
Date: Tue, 27 Jul 2010 12:26:59 -0700 (PDT)
Subject: [SC-L] Job Posting: Software Security Assurance Program at Oracle
Message-ID: <db49dddb-74e8-44c5-b71a-8d4516146b9c@default>

Apologies for any inconvenience due to the job posting to [SC-L] subscribers. I checked with Ken and he was ok with it.

 

There are couple of job openings in the Security Program Management group which is part of Oracle Global Product Security team, and oversees the product security assurance program. That is, we establish standards, tools, processes, APIs, etc. for avoiding security vulnerabilities in Oracle products.  There are also several others openings in closely related organizations under Global Product Security team.

 

We are looking for someone with detailed technical knowledge of security vulnerabilities, architecture, and design, to perform security reviews, and architectural risk analysis.  We are also looking to increase management in specific program areas including automated security analysis and test tools and secure configuration (i.e., ensuring products can install in hardened form, and that specific guidance is available to customers on how to do additional security hardening for specific environments and applications).

 

Please see the details below at iRecruitment website. If you are interested in any of these positions, please contact me or apply directly through iRecruitment. 

 

HYPERLINK "https://irecruitment.oracle.com/OA_HTML/OA.jsp?OAFunc=IRC_VIS_VAC_DISPLAY&OAMC=R&p_svid=1353464"IRC1353464 - Location is flexible

HYPERLINK "https://irecruitment.oracle.com/OA_HTML/OA.jsp?OAFunc=IRC_VIS_VAC_DISPLAY&OAMC=R&p_svid=1353336"IRC1353336 - Living in the SF Bay Area is very desirable but not mandatory

 

Regards,

Rajiv

 

-- 
HYPERLINK "http://www.oracle.com/" \nOracle
Rajiv Sharma | Senior Principal Program Manager
Phone: +1 3033348921 
Oracle Global Product Security
7700 Technology Way | Denver, Colorado 80237 

HYPERLINK "http://www.oracle.com/commitment" \nGreen Oracle

Oracle is committed to developing practices and products that help protect the environment

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100727/cd483b47/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100727/cd483b47/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 356 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100727/cd483b47/attachment-0001.gif>

From ken at krvw.com  Thu Jul 29 10:41:51 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 29 Jul 2010 10:41:51 -0400
Subject: [SC-L] Static code review for iPhone developers?
Message-ID: <3300F023-88EF-4D13-9515-CC86A90A9DD4@krvw.com>

Greetings SC-L folks.  Hey, I have a quick question I'd like to submit to this group.

Anyone know of any static code analysis tools that can scan an iPhone app package?  Something that integrates with the Xcode SDK and can at the very least scan through all of the Objective C in the src tree is what I'm looking for.  Any SCA product vendors currently doing this?  Please contact me on or off list.

Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

Follow us on Twitter at: http://twitter.com/KRvW_Associates





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100729/b6f82820/attachment.bin>

From dan at denimgroup.com  Thu Jul 29 11:46:48 2010
From: dan at denimgroup.com (Dan Cornell)
Date: Thu, 29 Jul 2010 08:46:48 -0700
Subject: [SC-L] Static code review for iPhone developers?
In-Reply-To: <3300F023-88EF-4D13-9515-CC86A90A9DD4@krvw.com>
References: <3300F023-88EF-4D13-9515-CC86A90A9DD4@krvw.com>
Message-ID: <A159EC70B84EFB43B0EAC68C9FEC16DA01298B6433CA@VA3DIAXVS111.RED001.local>

> Greetings SC-L folks.  Hey, I have a quick question I'd like to submit
> to this group.
> 
> Anyone know of any static code analysis tools that can scan an iPhone
> app package?  Something that integrates with the Xcode SDK and can at
> the very least scan through all of the Objective C in the src tree is
> what I'm looking for.  Any SCA product vendors currently doing this?
> Please contact me on or off list.
> 

XCode has a built in static analysis tool, but I'm not sure how thorough it is:
<http://developer.apple.com/mac/library/featuredarticles/StaticAnalysis/index.html>

Not sure if any of the commercial folks support Objective-C yet.

Thanks,

Dan



From ken at krvw.com  Thu Jul 29 15:26:40 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 29 Jul 2010 15:26:40 -0400
Subject: [SC-L] Static code review for iPhone developers?
In-Reply-To: <3300F023-88EF-4D13-9515-CC86A90A9DD4@krvw.com>
References: <3300F023-88EF-4D13-9515-CC86A90A9DD4@krvw.com>
Message-ID: <5A4BB7A8-474B-42EC-91A8-8F8DC0A33C60@krvw.com>

On Jul 29, 2010, at 10:41 AM, Kenneth Van Wyk wrote:
> Anyone know of any static code analysis tools that can scan an iPhone app package?  Something that integrates with the Xcode SDK and can at the very least scan through all of the Objective C in the src tree is what I'm looking for.  Any SCA product vendors currently doing this?  Please contact me on or off list.

Thanks to all who responded.  Great suggestions.

Most focused on the (now) built-in Clang analysis engine (and front-end for LLVM ) that Dan Cornell cited here.  (http://developer.apple.com/mac/library/featuredarticles/StaticAnalysis/index.html)

Clang looks like a useful starting point, as it looks for all sorts of common mistakes found in the C family, including C++ and Objective C.  Memory leaks, uninitialized variables, type mismatches, and that sort of thing should be pretty easy to spot using Clang.

I'm hoping also for something that goes beyond that.  How about analysis of static code for use of secure network connections, session management (for client-server apps), protection of sensitive data (at rest and in transit), and that sort of thing.  These are relatively language-agnostic needs, but would be extremely useful in a static analysis tool, IMHO.

I'll bet the folks who coded the Citi banking app could have made good use of something like that...  :-\

In any case, thanks again for all the responses.  Speaks volumes for the quality of folks we have here in the SC-L community.

Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

Follow us on Twitter at: http://twitter.com/KRvW_Associates


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100729/4ca9fb47/attachment.bin>

From carlos.j.serrao at gmail.com  Sun Aug  1 20:22:02 2010
From: carlos.j.serrao at gmail.com (=?iso-8859-1?Q?Carlos_Serr=E3o?=)
Date: Mon, 2 Aug 2010 01:22:02 +0100
Subject: [SC-L] 2nd. OWASP Ibero-American Web Applications Security
	Conference 2010 (IBWAS'10) - Call for Papers
Message-ID: <96286BD5-43C6-4E22-84DF-E421614530CF@gmail.com>

2nd. OWASP Ibero-American Web-Applications Security Conference 2010 (IBWAS?10)
ISCTE ? Lisbon University Institute
25th ? 26th November 2010
Lisboa, Portugal
http://www.ibwas.com

Call for Papers

Introduction
There is a change in the information systems development paradigm. The emergence of Web 2.0 technologies led to the extensive deployment and use of web-based applications and web services as a way to developed new and flexible information systems. Such systems are easy to develop, deploy and maintain and demonstrate impressive features for users, resulting in their current wide use. 
As a result of this paradigm shift, the security requirements have also changed. These web-based information systems have different security requirements, when compared to traditional systems. Important security issues have been found and privacy concerns have also been raised recently. In addition, the emerging Cloud Computing paradigm promises even greater flexibility; however corresponding security and privacy issues still need to be examined. The security environment should involve not only the surrounding environment but also the application core.
This conference aims to bring together application security experts, researchers, educators and practitioners from the industry, academia and international communities such as OWASP, in order to discuss open problems and new solutions in application security. In the context of this track academic researchers will be able to combine interesting results with the experience of practitioners and software engineers.

Conference Topics
Suggested topics for papers submission include (but are not limited to):
? Secure application development
? Security of service oriented architectures
? Security of development frameworks
? Threat modelling of web applications
? Cloud computing security
? Web applications vulnerabilities and analysis (code review, pen-test, static analysis etc.)
? Metrics for application security
? Countermeasures for web application vulnerabilities
? Secure coding techniques
? Platform or language security features that help secure web applications
? Secure database usage in web applications
? Access control in web applications
? Web services security
? Browser security
? Privacy in web applications
? Standards, certifications and security evaluation criteria for web applications
? Application security awareness and education
? Security for the mobile web
? Attacks and Vulnerability Exploitation

Paper Submission Instructions
Authors should submit an original paper in English, carefully checked for correct grammar and spelling, using the on-line submission procedure (http://www.easychair.org/conferences/?conf=ibwas10). Please check the paper formats so you may be aware of the accepted paper page limits (12 pages, in accordance to a supplied template: ftp://ftp.springer.de/pub/tex/latex/llncs/word/LNCS-Office2007.zip). 
The guidelines for paper formatting provided at the conference web site must be strictly used for all submitted papers. The submission format is the same as the camera-ready format. Please check and carefully follow the instructions and templates provided. 
Each paper should clearly indicate the nature of its technical/scientific contribution, and the problems, domains or environments to which it is applicable. 
Papers that are out of the conference scope or contain any form of plagiarism will be rejected without reviews. 
Remarks about the on-line submission procedure:
1. A "double-blind" paper evaluation method will be used. To facilitate that, the authors are kindly requested to produce and provide the paper, WITHOUT any reference to any of the authors. This means that is necessary to remove the author?s personal details, the acknowledgements section and any reference that may disclose the authors identity
2. Papers in ODF, PDF, DOC, DOCX or RTF format are accepted 
3. The web submission procedure automatically sends an acknowledgement, by e-mail, to the contact author. 

Paper submission types

Regular Paper Submission
A regular paper presents a work where the research is completed or almost finished. It does not necessary means that the acceptance is as a full paper. It may be accepted as a "full paper" (30 min. oral presentation), a "short paper" (15 min. oral presentation) or a "poster". 
Position Paper Submission
A position paper presents an arguable opinion about an issue. The goal of a position paper is to convince the audience that your opinion is valid and worth listening to, without the need to present completed research work and/or validated results. It is, nevertheless, important to support your argument with evidence to ensure the validity of your claims. A position paper may be a short report and discussion of ideas, facts, situations, methods, procedures or results of scientific research (bibliographic, experimental, theoretical, or other) focused on one of the conference topic areas. The acceptance of a position paper is restricted to the categories of "short paper" or "poster", i.e. a position paper is not a candidate to acceptance as "full paper". 

Camera-ready
After the reviewing process is completed, the contact author (the author who submits the paper) of each paper will be notified of the result, by e-mail. The authors are required to follow the reviews in order to improve their paper before the camera-ready submission. 

Publications
All accepted papers will be published in the conference proceedings, under an ISBN reference. Conference proceedings will be published by Springer in the Communications in Computer and Information Science (CCIS) series.

Web-site
http://www.ibwas.com

Secretariat
E-mail: secretariat at ibwas.com

Important Dates
Submission of papers and all other contributions due: 8th October 2010
Notification of acceptance: 22nd October 2010
Camera-ready version of accepted contributions: 29th October 2010
Conference: 25th ? 26th November 2010

Conference Chairs
Vicente Aguilera D?as, Internet Security Auditors, OWASP Spain, Spain
Carlos Serr?o, ISCTE-IUL Instituto Universit?rio de Lisboa, OWASP Portugal, Portugal

Organization Committee
Fabio Cerullo, OWASP Global Education Committee, Ireland
Dinis Cruz, OWASP Board Member, UK
Paulo Coimbra, OWASP Project Manager, UK
Miguel Correia, Universidade de Lisboa, Portugal
Paulo Sousa, Universidade de Lisboa, Portugal
Lucas C. Ferreira, C?mara dos Deputados, Brasil
Arturo Busleiman, OWASP Argentina, Argentina
Martin Tartarelli, OWASP Argentina, Argentina
Paulo Querido, Portugal

Conference Program Committee
Andr? Z?quete, Universidade De Aveiro, Portugal
Candelaria Hern?ndez-Goya, Universidad De La Laguna, Spain
Carlos Costa, Universidade De Aveiro, Portugal
Carlos Ribeiro, Instituto Superior T?cnico, Portugal
Eduardo Neves, OWASP Education Committee, OWASP Brazil, Brazil
Francesc Rovirosa i Radu?, Universitat Oberta de Catalunya (UOC), Spain
Gonzalo ?lvarez Mara??n, Consejo Superior de Investigaciones Cient?ficas (CSIC), Spain
Isaac Agudo, University of Malaga, Spain
Jaime Delgado, Universitat Politecnica De Catalunya, Spain
Javier Hernando, Universitat Politecnica De Catalunya, Spain
Javier Rodr?guez Saeta, Herta Security, Spain
Joaquim Castro Ferreira, Universidade de Lisboa, Portugal
Joaquim Marques, Instituto Polit?cnico de Castelo Branco, Portugal
Jorge D?vila Muro, Universidad Polit?cnica de Madrid (UPM), Spain
Jorge E. L?pez de Vergara, Universidad Aut?noma de Madrid, Spain
Jos? Carlos Metr?lho, Instituto Polit?cnico de Castelo Branco, Portugal
Jos? Luis Oliveira, Universidade De Aveiro, Portugal
Kuai Hinojosa, OWASP Global Education Committee, New York University, United States
Leonardo Chiariglione, Cedeo, Italy
Leonardo Lemes, Unisinos, Brasil
Manuel Sequeira, ISCTE-IUL Instituto Universit?rio de Lisboa, Portugal
Marco Vieira, Universidade de Coimbra, Portugal
Mariemma I. Yag?e, University of M?laga, Spain
Miguel Correia, Universidade de Lisboa, Portugal
Miguel Dias, Microsoft, Portugal
Nuno Neves, Universidade de Lisboa, Portugal
Osvaldo Santos, Instituto Polit?cnico de Castelo Branco, Portugal
Panos Kudumakis, Queen Mary University of London, United Kingdom
Paulo Sousa, Universidade de Lisboa, Portugal
Rodrigo Roman, University of Malaga, Spain
Rui Cruz, Instituto Superior T?cnico, Portugal
Rui Marinheiro, ISCTE-IUL Instituto Universit?rio de Lisboa, Portugal
S?rgio Lopes, Universidade do Minho, Portugal
Tiejun Huang, Pekin University, China
V?ctor Villagr?, Universidad Polit?cnica de Madrid (UPM), Spain
Vitor Filipe, Universidade de Tr?s-os-Montes e Alto Douro, Portugal
Vitor Santos, Microsoft, Portugal
Vitor Torres, Universitat Pompeu Fabra, Spain
Wagner Elias, OWASP Brazil Chapter Leader, Brazil

--
Carlos Serr?o
ISCTE-IUL/SoTA/DCTI | ADETTI-IUL/NetMuST | PT.OWASP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2679 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100802/d8bbb734/attachment.bin>

From carlos.j.serrao at gmail.com  Sun Aug  1 20:22:29 2010
From: carlos.j.serrao at gmail.com (=?iso-8859-1?Q?Carlos_Serr=E3o?=)
Date: Mon, 2 Aug 2010 01:22:29 +0100
Subject: [SC-L] =?windows-1252?q?2nd=2E_OWASP_Ibero-American_Web-Applicati?=
 =?windows-1252?q?ons_Security_conference_=28IBWAS=9210=29_-_Call_for_Trai?=
 =?windows-1252?q?ning?=
Message-ID: <7096CB4F-E3CF-46FC-8035-3D2C3486B164@gmail.com>

2nd. OWASP Ibero-American Web-Applications Security conference (IBWAS?10)
ISCTE ? Lisbon University Institute
25th ? 26th November 2010
Lisboa, Portugal
http://www.ibwas.com

**CALL FOR TRAINING SESSIONS**



IBWAS and OWASP is currently soliciting training proposals for the OWASP Ibero-American Web Applications Security 2010 Conference (IBWAS'10) which will take place at ISCTE-IUL, Lisboa, Portugal, on November 24 through November 26, 2010. 

There will be training courses on November 24 followed by plenary sessions on the 25 and 26 with multiple tracks per day.



We are seeking training proposals on the following topics (in no particular order):

- Application Threat Modeling

- Business Risks with Application Security

- Hands-on Source Code Review

- Metrics for Application Security

- OWASP Tools and Projects

- Privacy Concerns with Applications and Data Storage

- Secure Coding Practices (J2EE/.NET)

- Starting and Managing Secure Development Lifecycle Programs

- Technology specific presentations on security such as AJAX, XML, etc

- Web Application Security countermeasures

- Web Application Security Testing

- Web Services, XML and Application Security

- Anything else relating to OWASP and Application Security



Proposals on topics not listed above but related to the conference (i.e. which are related to Application Security) may also be accepted.


To make a submission you must fill out the form available at http://ibwas09.netmust.eu/files/ibwas10/OWASP_IBWAS_2010_CFT.rtf.zip and submit by email to secretariat at ibwas.com.

There may be 1 or half a day courses. The proposals must respect the restrictions of the OWASP Speaker Agreement. The conference will reward trainers with at least 30% of the total revenue of their courses, based on a minimum attendance. Courses that attract more students may be granted higher percentages. No other compensation (such as tickets or lodging) will be provided. If you require a different arrangement, please contact the conference chair at the email address below.

**Compensation**
Instructors and authors will be paid based on the number of students in their training sessions. If the training gathers only the minimum number of students, the compensation will be 30% of the revenue. For each group of 10 extra students enrolled, the compensation will be increased by 5% of the revenue, up to a maximum of 45% of the training revenue. For example, a 1-day training with 10 to 19 students will generate a compensation of 30% of the revenue. For classes of 20 to 29 students, the compensation raises to 35% percent of the revenue.

In exceptional cases, different compensation schemes may be accepted. Please contact the conference organization team by email (secretariat at ibwas.com) for details.

**Training cost**
half-day training: 250 EUR per student
1-day training: 450 EUR per student 
All prices in Euros (EUR)

**Minimum number of students**
half-day trainings: 10 students
1-day trainings: 20 students


**Important Dates:**

Submission deadline is September 20, 2010.

Notification of acceptance will be October 8, 2010.

Final version is due October 29, 2010.



The conference organization team may be contacted by email at secretariat at ibwas.com



For more information, please see the following web pages:
Conference Website: http://www.ibwas.com, http://www.owasp.org/index.php/IBWAS10
OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement
OWASP Website: http://www.owasp.org
Easychair conference site: http://www.easychair.org/conferences/?conf=ibwas10
Presentation proposal form: http://ibwas09.netmust.eu/files/ibwas10/OWASP_IBWAS_2010_CFT.rtf.zip

********** WARNING: Submissions without all the information requested in the proposal form will not be considered ************

Please forward to all interested practitioners and colleagues.

--
Carlos Serr?o
ISCTE-IUL/SoTA/DCTI | ADETTI-IUL/NetMuST | PT.OWASP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2679 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100802/a68bbbca/attachment.bin>

From gem at cigital.com  Mon Aug  9 12:12:45 2010
From: gem at cigital.com (Gary McGraw)
Date: Mon, 9 Aug 2010 12:12:45 -0400
Subject: [SC-L] Two resources
Message-ID: <C885A13D.244AB%gem@cigital.com>

hi sc-l,

We just made the Richard Clarke Silver Bullet podcast transcript live.  This special 50th edition of Silver Bullet interview shows up in the July/August IEEE Security & Privacy magazine.  A high definition video of the interview is also available on the silver bullet web page.  You can find a pdf copy of the transcript here:
http://www.cigital.com/silverbullet/shows/silverbullet-050-rclarke.pdf

Also of note, the mainstream technical trade press covered the BSIMM in an article published in drdobbs and informationweek over the weekend.  Here are the URLs:
http://www.drdobbs.com/security/226600001
http://www.informationweek.com/news/development/security/showArticle.jhtml?articleID=226600103

We are actively seeking more firms to become part of the BSIMM community.  If you are interested, drop me an email.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com



From jgaitanis at cigital.com  Wed Aug 11 14:49:48 2010
From: jgaitanis at cigital.com (Joanne Gaitanis)
Date: Wed, 11 Aug 2010 14:49:48 -0400
Subject: [SC-L] Secure code review/application penetration testing/security
 architecture positions at Cigital
Message-ID: <41945506397C0C4886A8C5BFF089B5CA3E11673F7D@va-mailhub.cigital.com>

Good afternoon!

Due to rapid growth/increased client base,  we are looking for Application Security Consultants (full time) at all levels, from 1-20 years experience, from entry level to management.
If qualified and interested, send me your resume in MS WORD doc format to jgaitanis at cigital.com.
Peruse our website @ www.cigital.com<http://www.cigital.com> !
Must be willing to travel as needed (~25%).
Position Locations: New York City, DC/No. VA, CA and London
Responsibilities
As Cigital engages with clients in the application of our software security improvement methodologies, the Security Consultant is responsible for the execution and delivery of planned project deliverables and milestones that assist clients in learning, understanding, and applying Cigital's secure software development methodologies. He/She has task responsibility within one or more projects, typically with one client. The Consultant possesses solid business knowledge, Cigital methodology, technical, general consulting, project management and teaching skills. He/She is current on industry issues and supports proposal preparation.

 *   Code review/secure code analysis
 *   Penetration testing
 *   Technical Lead (for senior consultant and above positions)
 *   Understanding of Software Security Architecture and Design
Education and Experience

 *   BS in CS, Engineering or equivalent. MS preferred
 *   Code reviewing
 *   Application penetration testing
 *   In depth understanding of SDLC
 *   Governance, regulatory or controls experience preferred
 *   Experience coding with C/C++, Java, and/or .NET
 *   consulting experience is a plus
 *   Ideally, will have CISSP or other security certifications

 *   Technical Skills
    *   Understanding enterprise class systems in java/J2EE or .NET programming environments
    *   Ability to perform structured analysis of business problems and define a technical architecture that solves those problems
    *   Understanding of software development methodologies such as waterfall, RUP and agile
    *   Understanding of information security and available security tools and technologies
    *   Code reviewing/secure code analysis
    *   Application penetration testing
    *   Governance, regulatory or controls experience is a plus

Thanks!
Joanne

Joanne Gaitanis
Sr. Recruiter
508-572-4940  www.Cigital.com
Software Confidence.  Achieved.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100811/d7f5e7e2/attachment.htm>

From ken at krvw.com  Thu Aug 12 08:17:49 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 12 Aug 2010 08:17:49 -0400
Subject: [SC-L] Computerworld: Opinion - Making apps secure is hard work
Message-ID: <1921194A-CC76-46C2-8FF5-450EE7B2E933@krvw.com>

I figured this was relevant here, so here's a link to my August column for Computerworld.

Excerpt:

'What's that you say? All the app vetting you've been doing to date consists only of verifying that the apps play by the rules? That is, that they use only published APIs and such? Well, then, you really have your work cut out for you, because that's not all that your customers expect.'

To read the complete article see:
http://www.computerworld.com/s/article/9180579/Making_apps_safe_is_hard_work?taxonomyId=17


Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

Follow us on Twitter at: http://twitter.com/KRvW_Associates





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100812/7156d59d/attachment-0001.bin>

From gunnar at arctecgroup.net  Thu Aug 12 09:46:52 2010
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 12 Aug 2010 08:46:52 -0500
Subject: [SC-L] Computerworld: Opinion - Making apps secure is hard work
In-Reply-To: <1921194A-CC76-46C2-8FF5-450EE7B2E933@krvw.com>
References: <1921194A-CC76-46C2-8FF5-450EE7B2E933@krvw.com>
Message-ID: <C511B467-EF08-41B8-861C-B229168BC563@arctecgroup.net>

Hi Ken,

You raise some important points. Most infosec is approached as a set of controls, but access control only takes you so far in the face of malice.

I like this quote from G.K. Chesterton

"The real trouble with this world of ours is not that it is an unreasonable world, nor even that it is a reasonable one. The commonest kind of trouble is that it is nearly reasonable, but not quite. Life is not an illogicality; yet it is a trap for logicians. It looks just a little more mathematical and regular than it is; its exactitude is obvious, but its inexactitude is hidden; its wildness lies in wait."

Notice the distinction, the first part gets to why access control matters - we can use crypto and such to impose our policies on the logic that we know and understand, but it does not help us all with inexactitude. There's no margin of safety, the control either works or its doesn't.

-gunnar

On Aug 12, 2010, at 7:17 AM, Kenneth Van Wyk wrote:

> I figured this was relevant here, so here's a link to my August column for Computerworld.
> 
> Excerpt:
> 
> 'What's that you say? All the app vetting you've been doing to date consists only of verifying that the apps play by the rules? That is, that they use only published APIs and such? Well, then, you really have your work cut out for you, because that's not all that your customers expect.'
> 
> To read the complete article see:
> http://www.computerworld.com/s/article/9180579/Making_apps_safe_is_hard_work?taxonomyId=17
> 
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> Follow us on Twitter at: http://twitter.com/KRvW_Associates
> 
> 
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________



From gem at cigital.com  Mon Aug 16 12:46:26 2010
From: gem at cigital.com (Gary McGraw)
Date: Mon, 16 Aug 2010 12:46:26 -0400
Subject: [SC-L] Software Security Crosses the Threshold
Message-ID: <C88EE3A2.24811%gem@cigital.com>

hi sc-l,

As many of you know, I have been collecting and publishing information about the software security space from a business perspective for several years running.  In 2009, revenues from tools and services companies in the software security market exceeded $500 million.  This is an important threshold for multiple reasons: the space continues to grow even in uncertain economic times, a middle market of small and medium size businesses is developing, and acquisitions by major players (IBM and HP) are bearing fruit.

I published my findings as this month's informIT article <http://www.informit.com/articles/article.aspx?p=1623792>

Like always, your feedback and discussion of the article is welcome.  As software security finally begins to mature as a business and gain some momentum, we can help bolster the market by describing what we see happening to those outside the discipline.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


From cfp at ruxcon.org.au  Thu Aug 19 22:13:21 2010
From: cfp at ruxcon.org.au (cfp at ruxcon.org.au)
Date: Fri, 20 Aug 2010 12:13:21 +1000 (EST)
Subject: [SC-L] Ruxcon 2010 Final Call For Papers
Message-ID: <20100820021321.939C689C9@ruxcon.org.au>



RUXCON 2010 FINAL CALL FOR PAPERS

Ruxcon would like to announce the final call for papers for the sixth annual Ruxcon conference.

This year the conference will take place over the weekend of 20th and 21st of November.

Ruxcon will be held at CQ, Melbourne, Australia.

The deadline for submissions is the 10th of October.

What is Ruxcon?

Ruxcon is the premiere technical computer security conference within Australia. Ruxcon aspires to bring together the individual talents of the best and the brightest security folk within the Aus-Pacific region, through live presentations, activities, and demonstrations.

Ruxcon's unique approach to running a security conference ensures that the conference is accessible to all levels of the security industry. Ruxcon aims to be the most interesting, thought provoking, and relevant information security conference in Australia.

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

For more information, please visit http://www.ruxcon.org.au

Presentation Information

Presentations will be 50 minutes in length, and should be fully supplemented with slides and any other relevant material.

Presentation Submissions

Ruxcon would like to invite people who are interested to submit a presentation.

Topics of interest include, but are not limited to:

??????* Mobile Device Security
??????* Virtualisation, Hypervisor and Cloud Security
??????* Malware Analysis
??????* Reverse Engineering
??????* Exploitation Techniques
??????* Rootkit Development
??????* Code Analysis
??????* Forensics and Anti-Forensics
??????* Embedded Device Security
??????* Web Application Security
??????* Network Traffic Analysis
??????* Wireless Network Security
??????* Cryptography and Cryptanalysis
??????* Social Engineering
??????* Law Enforcement Activities
??????* Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)

Submissions should thoroughly outline your desired presentation subject. Accompanying your submission should be the slides you intend to use or a detailed paper explaining your subject.

If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to
presentations at ruxcon.org.au.

The deadline for submissions is the 10th of October.

If approved we will additionally require:

????1. A brief personal biography (between 2-5 paragraphs in length).
????2. A description on your presentation (between 2-5 paragraphs in length).

Contact Details

Presentation Submissions: presentations at ruxcon.org.au
General Enquiries: ruxcon at ruxcon.org.au



From ken at krvw.com  Fri Aug 20 08:57:57 2010
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 20 Aug 2010 07:57:57 -0500
Subject: [SC-L] Building Real Software: Has Static Analysis reached its
	limits?
Message-ID: <43B7E734-1875-49D0-A2A8-2047FAF41A97@krvw.com>

FYI, nice write-up on the Fortify acquisition as well as the static code analysis space here:

http://swreflections.blogspot.com/2010/08/has-static-analysis-reached-its-limits.html



Cheers,

Ken

-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

Follow us on Twitter at: http://twitter.com/KRvW_Associates





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100820/3745e5bd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3337 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100820/3745e5bd/attachment.bin>

From gem at cigital.com  Mon Aug 23 16:57:07 2010
From: gem at cigital.com (Gary McGraw)
Date: Mon, 23 Aug 2010 16:57:07 -0400
Subject: [SC-L] SB53: Richard Bejtlich
Message-ID: <C89858E3.24B84%gem@cigital.com>

hi sc-l,

The 53rd (!!) monthly episode of the Silver Bullet Security Podcast is an interview with Richard Bejtlich.  Richard is a well known expert in network monitoring, a subject he has written a book about.  Richard is also very knowledgeable about software security.  In fact, I wish that more ops people knew as much as Richard does about software security!  Richard now works for GE and has plenty to say about interfacing with a huge business.

Have a listen, and pass it on: <http://www.cigital.com/silverbullet/show-053/>

Note that this episode came about as a reader suggestion.  If there are people you would like to hear interviewed on Silver Bullet please let us know.  As always, thanks to IEEE Security & Privacy magazine for co-sponsoring Silver Bullet.

gem

company www.cigital.com
blog www.cigital.com/justiceleague
book www.swsec.com


From jleffler at us.ibm.com  Sun Aug 22 11:03:34 2010
From: jleffler at us.ibm.com (Jonathan Leffler)
Date: Sun, 22 Aug 2010 08:03:34 -0700
Subject: [SC-L] Recent technical reports from the CERT Secure Coding
	Initiative
In-Reply-To: <mailman.1.1277568000.29647.sc-l@securecoding.org>
References: <mailman.1.1277568000.29647.sc-l@securecoding.org>
Message-ID: <OFADACB84D.2BE5FD57-ON88257787.0051B165-88257787.0052B9C6@us.ibm.com>


Thanks for the reports, Robert.

   Specifications for Managed Strings, Second Edition
   Hal Burch, Fred Long, Raunak Rungta, Robert C. Seacord, & David Svoboda

   CMU/SEI-2010-TR-018

   This report describes a managed string library for the C programming
   language. [...]

   cover date: May 2010

   http://www.sei.cmu.edu/library/abstracts/reports/10tr018.cfm

In the managed string library report, there's a paragraph on p5 that reads:

   Most functions in this technical report include as part of their
   specifications a list of runtime-constraints, which are requirements on
   the program using the library. Despite its name, a runtime-constraint is
   not a kind of constraint. Implementations shall verify that the
   runtime-constraint for a library function are not violated by the
   program

I think that the statement that a 'runtime-constraint is not a kind of
constraint' is confusing to those who do not know exactly what is intended
by the statement, and it could do with some clarification that is not given
immediately in the report.  IMNSHO, at the very least there needs to be a
footnote or pointer to a glossary where the distinction between a
runtime-constraint and a constraint is explained, because otherwise it
merely sounds self-contradictory (or a bad choice of terminology).

--
Jonathan Leffler (jleffler at us.ibm.com)
STSM, Informix Database Engineering, IBM Information Management
4400 N First St, San Jose, CA 95134-1257
Tel: +1 408-956-2436         Tieline: 475-2436
"I don't suffer from insanity; I enjoy every minute of it!"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100822/5044fa2d/attachment.htm>

From leonardo.buonsanti at gmail.com  Fri Aug 20 16:53:57 2010
From: leonardo.buonsanti at gmail.com (Leonardo Buonsanti)
Date: Fri, 20 Aug 2010 17:53:57 -0300
Subject: [SC-L] [OWASP] APPSEC BRAZIL 2010 - REGISTRATIONS OPEN!
Message-ID: <AANLkTi=642LzX47gbkH_aJAAVnq4FfUQBujkkRjCoVGT@mail.gmail.com>

Greetings everyone!

We're proud to announce that the OWASP's AppSec Brazil 2010 Conference
registrations' are officially open!

Early bird offers are available! Hurry up!

This year we'll have keynotes by Robert 'Rsnake' Hansen and Jeremiah
Grossman and Samy Kamkar as a Special Speaker!

Registrations are available here:
http://www.owasp.org/index.php/AppSec_Brasil_2010#tab=Registration

All info about the event can be found at: http://www.appsecbrasil.org

<http://www.owasp.org/index.php/AppSec_Brasil_2010#tab=Registration>If you
have any doubt please contact us at organizacao2010 (at) appsecbrasil.org

See you there!

-- 
Leonardo Buonsanti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100820/142ca709/attachment.htm>