SC-L Digest, Vol 3, Issue 102

[jgrembi at gmail.com (Jason Grembi)]

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