Re: [SC-L] Perspectives on Code Scanning

2007-06-10 Thread Carl Alphonce

[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 [EMAIL PROTECTED] sent:
On 6/7/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] 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.


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-10 Thread Paolo Perego
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) [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] 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@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-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@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service

Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread Steven M. Christey

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
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread Michael S Hines
 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
[EMAIL PROTECTED]


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread SC-L Subscriber Dave Aronson
McGovern, James F \(HTSC, IT\) [mailto:[EMAIL PROTECTED] 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/



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread der Mouse
 --- 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   [EMAIL PROTECTED]
/ \ 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@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread Shea, Brian A
 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of der Mouse
Sent: Thursday, June 07, 2007 8:07 AM
To: SC-L@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   [EMAIL PROTECTED]
/ \ 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@securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC
(http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread der Mouse
 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   [EMAIL PROTECTED]
/ \ 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@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Perspectives on Code Scanning

2007-06-07 Thread Arian J. Evans

inline

On 6/6/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED]
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 organizationwow! 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 

Re: [SC-L] Perspectives on Code Scanning

2007-06-06 Thread Michael Silk
On 6/7/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] 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@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-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@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___