RE: [SC-L] How do we improve s/w developer awareness?

[Peter Amey]

[snip]
> 
> Remember that little incident in 2000 when the London 
> millennium bridge was
> closed immediately after opening due to excessive wobbling when people
> walked across it? I can't guarantee that my recollection is 
> accurate, but
> I'm sure they were trying to put this down to that software classic, a
> 'Design feature'.

The Millenium Bridge wobble is indeed instructive.  Engineering is usually a 
profession that is conservative and places great emphasis on codifying and 
learning from past mistakes.  Much bridge design work uses well-established, 
trustworthy principles.  The Millenium Bridge designers deliberately pushed the 
boundaries to produce something novel and exciting.  Never before had a 
suspension bridge had the suspension and decking in the same plane (i.e. the 
deck doesn't "hang" from the suspension, its balanced on/between the 
suspension).  The result was strong enough but had unexpected dynamics i.e. it 
wobbled!
I am confident that this experience is already in the text books, standard data 
tables and CAD tools.  The engineering body of knowledge had been added to and 
the problem should not recur.

This is where the software community can learn:

1.  We are appalling at learning from previous mistakes (other than in 
perfecting our ability to repeat them!)
2.  We routinely push the boundaries of what we try and achieve by leaping 
instead of stepping.
3.  We routinely adopt novel and untried technology in preference to proven and 
trustworthy alternatives.  Indeed, mature technology often seems to be rejected 
precisely because it is not new, novel or exciting enough.

The Millenium Bridge made news precisely because such engineering faiures are 
rare; software engineering failures make the news because they are so common 
the papers would be empty if they weren't reported! 

[snip]

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 High Integrity 
Systems Ltd (Praxis HIS). 

 Although this email and any attachments are believed to be free of any virus 
or other defect, no responsibility is accepted by Praxis HIS 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 HIS can be contacted at [EMAIL 
PROTECTED]

**

Re: [SC-L] How do we improve s/w developer awareness?

[David A. Wheeler]

der Mouse said:
>>Changing liability laws on the other hand is a simple solution.
> 
> But at what price?  It would kill off open source completely, as far as
> I can see, in the jurisdiction(s) in question.  (How many open source
> projects could afford to defend a liability suit even if they (a)
> wanted to and (b) had a won case?)
> 
> Of course, if you don't mind that, go right ahead.  You don't say where
> you are, but looking over your message I see reason to thin it's the
> USA, and I long ago wrote off the USA as a place to write code.  I
> think it could be a very good thing for the USA to try such laws; it
> would give us hard data about what their effect is, rather than the
> speculation (however well-informed) that's all we have to go on now -
> and it quite likely would have the pleasant side effect of pushing most
> open source projects out into the free (or at least freer) world.

One solution would be to exempt open source software from such
liability, under the theory that:
* If anyone can read & analyze the source code, the real security
   of the product is much easier for customers to determine
   (directly or by hiring someone).  Part of the problem now is that
   vendors always say they're wonderful... and if it's closed source,
   it's too difficult to determine if that's true.
   It's usually pretty easy to determine if an OSS program is
   poorly designed or well designed for security.
* If anyone can change the program & redistribute those changes,
   then anyone can fix things THEY think are problems immediately,
   instead of waiting for a vendor (who may not bother or take
   years).  After all, the customer has the urgency, not the vendor.
* Requiring liability for open source software would kill a great deal
   of innovation, since a common model for distributing ideas &
   promulgating standards is to distribute an
   open source software implementation.  The Internet would probably
   never have gotten far, except that the BSD TCP/IP stack could be
   freely copied into arbitrary places (as code or as concept).
   The same for DNS, web servers, etc.
* If it's NOT open source, then the vendor is probably charging a
   per-use or per-year fee, and thus can afford insurance, lawsuits, etc.
   This often isn't true for OSS; a project could separately charge
   for liability insurance, but because it's optional, the group
   becomes much smaller than "all users".

There's even a precedent for this: U.S. export crypto laws essentially
give a free pass (in most cases) to open source software.
And in general, for important things the U.S. often requires either
disclosure or liability; this approach gives consumers a choice.

I'm not certain that liability laws for vendors are the way to go.
Generally such laws just make people buy insurance for the
lawsuits; if nothing else changes, that just means that the
lawyers get rich and nothing useful happens.  Sometimes, the
insurance companies impose requirements to get that insurance.
But those requirements are to reduce the insurance company risk,
not to improve the innovation or capability of products, or
even the security of the products as viewed by an end-user.
It'd be easy to kill the baby on this road.

If you go down this path,
you'd probably be better off creating a nice, narrow list
of common security flaws, and then say that you can sue
if it's something on THAT list.  That way, rather than something
vague, they can at least eliminate a finite set of problems,
that's short and manageable. Not perfect, but a start.

Another approach is to permit suits against people who CHOSE
the product.  This has some
advantages, but it's not perfect either.  Problem here is that
popular products generally get a free pass ("everyone else
chose this shoddy product!"), which means that this can
_disincentivize_ vendors of popular products from fixing their
wares, and it can disincentivize competition ("no one would
be willing to risk using my new product because they might get sued").

Sigh.  Nothing is simple!

Anyway, just a few thoughts.

--- David A. Wheeler

RE: [SC-L] How do we improve s/w developer awareness?

[owner-sc-l]

<[EMAIL PROTECTED]>
From: "Peter Amey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Precedence: bulk
Mailing-List: contact <[EMAIL PROTECTED]> ; run by MajorDomo
List-Id: Secure Coding Mailing List 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
List-Help: 
List-Archive: 
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: moderator for [EMAIL PROTECTED]

[snip]
> 
> Remember that little incident in 2000 when the London 
> millennium bridge was
> closed immediately after opening due to excessive wobbling when people
> walked across it? I can't guarantee that my recollection is 
> accurate, but
> I'm sure they were trying to put this down to that software classic, a
> 'Design feature'.

The Millenium Bridge wobble is indeed instructive.  Engineering is usually 
a profession that is conservative and places great emphasis on codifying 
and learning from past mistakes.  Much bridge design work uses 
well-established, trustworthy principles.  The Millenium Bridge designers 
deliberately pushed the boundaries to produce something novel and exciting. 
 Never before had a suspension bridge had the suspension and decking in the 
same plane (i.e. the deck doesn't "hang" from the suspension, its balanced 
on/between the suspension).  The result was strong enough but had 
unexpected dynamics i.e. it wobbled!
I am confident that this experience is already in the text books, standard 
data tables and CAD tools.  The engineering body of knowledge had been 
added to and the problem should not recur.

This is where the software community can learn:

1.  We are appalling at learning from previous mistakes (other than in 
perfecting our ability to repeat them!)
2.  We routinely push the boundaries of what we try and achieve by leaping 
instead of stepping.
3.  We routinely adopt novel and untried technology in preference to proven 
and trustworthy alternatives.  Indeed, mature technology often seems to be 
rejected precisely because it is not new, novel or exciting enough.

The Millenium Bridge made news precisely because such engineering faiures 
are rare; software engineering failures make the news because they are so 
common the papers would be empty if they weren't reported! 

[snip]

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 High Integrity Systems Ltd (Praxis HIS). 

 Although this email and any attachments are believed to be free of any 
virus or other defect, no responsibility is accepted by Praxis HIS 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 HIS can be 
contacted at [EMAIL PROTECTED]

**

Re: [SC-L] How do we improve s/w developer awareness? [Virus Checked]

[graham . coles]

I have to say I find your comparison between bridge engineers and software
engineers rather troubling.

In response to your question:

  'Would you accept "it was too hard to do a stress analysis" from the
engineer designing a bridge?'

I think, regrettably, we probably would do these days.

Remember that little incident in 2000 when the London millennium bridge was
closed immediately after opening due to excessive wobbling when people
walked across it? I can't guarantee that my recollection is accurate, but
I'm sure they were trying to put this down to that software classic, a
'Design feature'.

Seems that far from Software Engineers taking the bridge engineers
approach, we may be seeing the exact reverse happening. :-)

--
Graham Coles.






   
  Brian Utterback   
   
   
  Sun.COM> cc:   [EMAIL PROTECTED]  
   
      Sent by:             Subject:  Re: [SC-L] How do we 
improve s/w developer awareness? [Virus Checked] 
  [EMAIL PROTECTED] 
   
  coding.org
   

   

   
  02/12/2004 13:25  
   

   




George Capehart wrote:

> Yes, assuming management cares . . . and that's *my* broken record . . .
> :)
>
> If the tone of my comments was a bit harsh, it is most emphatically not
> intended to be directed at your thoughts.  It is only because of my
> intense frustration with the situation.  When "Management" wants
> software systems to be secure, they will be.  Not perfectly so, but
> within published limits.  "Management" will see to it that the
> appropriate policies and processes are in place to assure it.
> "Management" will see to it that delivering a product that passes the
> certification process is more important than delivering a product by a
> certain date.  "Management" will require that a security architecture
> be in place before the design process starts, etc., etc., etc.  The
> board will hold "Management" accountable for the risk that the use of
> the system entails.  When that happens, "Management" will come to
> realize that security is *their* problem, *not* InfoSec's problem.
> /Until/ that happens, changing frameworks, development tools,
> methodologies or whatever will not solve the problem.  "The Problem"
> just isn't in IT.
>
> As Dennis Miller says:  "But that's just my opinion.  I could be wrong."


Which brings up the next broken record. Management will not care until
it affects the bottom line not to care. As long as it costs money to
care (missed deadlines, more tools and training, etc.) and it doesn't
cost anything not to care, then they *shouldn't* care.  Either the
consumers have to care so that security problems cost sales, or
the liability laws need to change so that security problems result in
financial penalties. Consumers in  general are too diverse a group to
really change what they want. It would be very difficult to educate the
entire consumer base to the collateral costs of poor security in
products and to set valid expectations about what is and is not
possible. The "all software has bugs" mantra is now very ingrained.
Changing liability laws on the other hand is a simple solution. This
will force managers to do the proper due diligence just to CYA.
Sure, there will be increased litigation costs, but a couple high
profile cases and the whole process of development will change.

And I don't buy the "programming is too hard, there will always be bugs"
argument. Maybe there will always be bugs, but I don't think we have
reached the point where we can really make a call about how hard it
really is. We call programmers "engineers", but very, very few software

Re: [SC-L] How do we improve s/w developer awareness?

[der Mouse]

> Changing liability laws on the other hand is a simple solution.

But at what price?  It would kill off open source completely, as far as
I can see, in the jurisdiction(s) in question.  (How many open source
projects could afford to defend a liability suit even if they (a)
wanted to and (b) had a won case?)

Of course, if you don't mind that, go right ahead.  You don't say where
you are, but looking over your message I see reason to thin it's the
USA, and I long ago wrote off the USA as a place to write code.  I
think it could be a very good thing for the USA to try such laws; it
would give us hard data about what their effect is, rather than the
speculation (however well-informed) that's all we have to go on now -
and it quite likely would have the pleasant side effect of pushing most
open source projects out into the free (or at least freer) world.

/~\ The ASCIIder 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

RE: [SC-L] How do we improve s/w developer awareness?

[Shea, Brian A]

FYI this is part of a notice that went out to financial institutions
recently. 

Complete Financial Institution Letter:
http://www.fdic.gov/news/news/financial/2004/fil12104.html 
 
Highlights: 

Management is responsible for ensuring that commercial off-the-shelf
(COTS) software packages and vendor-supplied in-house computer system
solutions comply with all applicable laws and regulations.
 
The guidance contained in this financial institution letter will assist
management in developing an effective computer software evaluation
program to accomplish this objective. 

An effective computer software evaluation program will mitigate many of
the risks - including failure to be regulatory compliant - that are
associated with software products throughout their life cycle. 

Management should use due diligence in assessing the quality and
functionality of COTS software packages and vendor-supplied in-house
computer system solutions.

Distribution:
FDIC-Supervised Banks (Commercial and Savings) 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Greenarrow 1
Sent: Monday, November 29, 2004 6:08 PM
To: George Capehart
Subject: Re: [SC-L] How do we improve s/w developer awareness?

Words could not be spoken better.  This is my argument from the get go.
I,
to, am tired of seeing everyone blame it on the Dev department when the
orders from above are I want this now and fast.  Maybe, we can focus and
convince upper level management that security is as important as the
greed,
money, bells, whistles.  But while I support Dev I still do not
understand
how some companies development departments can include tight secured
coding
in a short time frame and others seem to provide excuses or just do not
care.

Customers are now looking at the security of programs.  Slowly,
consumers
are finally looking at security flaws mainly because of the media
coverage
that computer softwares are creating.  While it may only be top
contenders
in the software field customers are now questioning other programs they
have
which I support fully.  I can see this in the rise of subscribers to
certain
Security Flaw Alerts which has risen over 71% within the last 3 months.

Just a word of warning as consumers become more aware of security in the
softwares they purchase companies that do not secure will start showing
a
downslide in purchases.  It is happening to one major company as we
email
each other on issues.

Regards,
George
Greenarrow1
InNetInvestigations-Forensics


- Original Message -
From: "George Capehart" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 28, 2004 5:18 PM
Subject: Re: [SC-L] How do we improve s/w developer awareness?


> On Thursday 11 November 2004 10:26, Kenneth R. van Wyk allegedly
wrote:
> > Greetings,
> >
> > In my business travels, I spend quite a bit of time talking with
> > Software Developers as well as IT Security folks.  One significant
> > different that I've found is that the IT Security folks, by and
> > large, tend to pay a lot of attention to software vulnerability and
> > attack information while most of the Dev folks that I talk to are
> > blissfully unaware of the likes of Full-Disclosure, Bugtraq, PHRACK,
> > etc.  I haven't collected any real stats, but it seems to me to be
at
> > least a 90/10% and 10/90% difference.  (Yes, I know that this is a
> > gross generalization and there are no doubt significant exceptions,
> > but...)
> >
> > I believe that this presents a significant hurdle to getting Dev
> > folks to care about Software Security issues.  Books like Gary
> > McGraw's Exploiting Software do a great job at explaining how
> > software can be broken, which is a great first step, but it's only a
> > first step.
>
> Apologies for the two-week latency in this reply.  I don't have as
much
> time for the lists as I used to.
>
> I have read the rest of this thread, and I didn't see any comments
that
> address a dimension that is, for me, the most salient.  I feel like a
> broken record because this topic crops up on one security-related list
> or another at least once a quarter and I end up saying the same thing
> every time.  I'm going to say it again, though, because I really
> believe that it is important . . . Dev folks will care about security
> when their managers care about security.  If time-to-market and bells
> and whistles are more important to "management" than security is,
> that's where dev folks will spend their time.  It is their job to do
> what their managers tell them to do.  When "management" decides that
it
> is more important to deliver a product that is based on a robust
> security architecture and which is built and tested with security in
> mind, it will be.  Until then

RE: [SC-L] How do we improve s/w developer awareness?

[Michael S Hines]

I've been trying to get IT Auditors and the Audit community in general to apply 
the same
due dilligence to operating systems (infrastructure or general controls) that 
they apply
to applications systems testing.

I'm not aware of anyone in the IT Audit community doing OS audits - to verify 
that the
systems work as advertised and do not fail where they should not.   I become 
quite aware
of this a few years ago when I was in a group doing Penetraiton Testing of an 
OS and
discovered many flaws.

Why don't auditors audit the OS?  I, frankly, don't know. 

But Auditors do have the ear of upper management and they could be the ones 
indicating the
weaknessed in the infrastructure that puts the organization at risk. 

We wouldn't put in a new payroll system without verifying that it works 
properly.  Yet
we're more than willing to unpackage and plug in a desktop computer without the 
same due
dilligence.  Why?It's beyond me.  

Perhaps if more people were asking the right questions to the right people ...  
?  

Why we've come to accept the CTL_ALT_DEL 'three finger salute' as SOP is beyond 
me.  

Of course the issues above aren't limited to one particular OS.  There are 
plenty of
problems to go around.
(see the work done at Univ of Wisconsin - the Fuzz Testing project 
http://www.cs.wisc.edu/~bart/fuzz/fuzz.html )

Mike Hines
---
Michael S Hines
[EMAIL PROTECTED] 

Re: [SC-L] How do we improve s/w developer awareness?

[Brian Utterback]

George Capehart wrote:
Yes, assuming management cares . . . and that's *my* broken record . . .
:)
If the tone of my comments was a bit harsh, it is most emphatically not
intended to be directed at your thoughts.  It is only because of my
intense frustration with the situation.  When "Management" wants
software systems to be secure, they will be.  Not perfectly so, but
within published limits.  "Management" will see to it that the
appropriate policies and processes are in place to assure it.
"Management" will see to it that delivering a product that passes the
certification process is more important than delivering a product by a
certain date.  "Management" will require that a security architecture
be in place before the design process starts, etc., etc., etc.  The
board will hold "Management" accountable for the risk that the use of
the system entails.  When that happens, "Management" will come to
realize that security is *their* problem, *not* InfoSec's problem.
/Until/ that happens, changing frameworks, development tools,
methodologies or whatever will not solve the problem.  "The Problem"
just isn't in IT.
As Dennis Miller says:  "But that's just my opinion.  I could be wrong."

Which brings up the next broken record. Management will not care until
it affects the bottom line not to care. As long as it costs money to
care (missed deadlines, more tools and training, etc.) and it doesn't
cost anything not to care, then they *shouldn't* care.  Either the
consumers have to care so that security problems cost sales, or
the liability laws need to change so that security problems result in
financial penalties. Consumers in  general are too diverse a group to
really change what they want. It would be very difficult to educate the
entire consumer base to the collateral costs of poor security in
products and to set valid expectations about what is and is not
possible. The "all software has bugs" mantra is now very ingrained.
Changing liability laws on the other hand is a simple solution. This
will force managers to do the proper due diligence just to CYA.
Sure, there will be increased litigation costs, but a couple high
profile cases and the whole process of development will change.
And I don't buy the "programming is too hard, there will always be bugs"
argument. Maybe there will always be bugs, but I don't think we have
reached the point where we can really make a call about how hard it
really is. We call programmers "engineers", but very, very few software
"engineers" deserve the title. Would you accept "it was too hard to
do a stress analysis" from the engineer designing a bridge?
--
blu
It is bafflingly paradoxical that the United States is by far the
world's leading scientific nation while simultaneously housing the most
scientifically illiterate populace outside the Third World.
- Richard Dawkins

Brian Utterback - OP/N1 Revenue Product Engineering, Sun Microsystems
Ph/VM: 877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Re: [SC-L] How do we improve s/w developer awareness?

[George Capehart]

On Tuesday 30 November 2004 11:58, Evans, Arian allegedly wrote:
> I've almost completely ignored this thread because like
> George I believe it's the same old broken record I first
> heard Marcus Ranum spin up a decade ago. When it comes to
> this subject I feel like we [security professionals] are
> a bunch of myopic carriage horses sprinting through the
> forest wondering where all the trees are coming from.

Nice analogy.  :)

>
> Among other things, I teach classes on webappsec; how to
> design and build secure apps, how to crack them, and so
> on. It's fun and exciting to see the lightbulb go on with
> your classic VB ASP newbie.
>
> It's also a waste of time for several reasons.
>
> One: I'm talking to the wrong people:
>
> I have a 3-hour 'morning' class for development managers,
> business line owners, and c-levels. It is about real life
> *incidents*\ and incident response, business process and
> risk management, and how to shim security into a development
> process so it fits hand in glove with business requirements.
> No BUFD and BPPST (big post-production 'security test').
>
> People rarely attend that class. Maybe I'm just a bad presenter.

No, they just don't care.

>
> Two: the world's web apps are always going to be coded by
> entry-level VB ASP people. Security is a complex and ephemeral
> subject. We don't expect developers of this skill set to
> be responsible for optimizing compiled code, so who in their
> right mind thinks they are going to become security experts?

They don't need to be security experts.  They just need to be able to
follow design specs and coding policies and processes.  This just goes
back to the absence of governance and risk management.  The design
specs should specify a "secure design."  Coding policies should specify
"secure coding practices" and the build processes should enforce the
policy.

>
> I do know I've made developers very aware of security,
> and even have a few that keep in touch and use me for
> a 'recommended reading' list.
>
> But it is 8pm Friday night and this app was supposed to go
> live by 5pm and we just got it rolled to prod, QA thumbs-up
> and business signoff, and I've got a wife with a cold dinner
> and a kid waiting for me to come home.

That's not a coding problem.  It's a project management problem.

>
> And a manager that's not worried about security because
> the business is not worried about security issues and they
> pay those folks in the security department to run their
> scanners anyway. CISSPs. Security is their job.

Again, an absence of governance and risk management . . .

>
> Now, Yogi Berra.
>
> Nothing changes until something changes.
>
> We need a change in framework and development tools. This
> can solve for technical issues (e.g.--buffer overflows)
> that are the legacy and gift of C and her children.

To a large extent, yes . . . iff, management is worried about security
issues and insists that frameworks and tools that promote
application-level security are used.  But, as you noted above, that is
not the case . . .

>
> Logical issues, design issues, will always exist and we
> exist to help find them and help educate the business to
> find case to correct them, if such case exists.

Yes, assuming management cares . . . and that's *my* broken record . . .
:)

If the tone of my comments was a bit harsh, it is most emphatically not
intended to be directed at your thoughts.  It is only because of my
intense frustration with the situation.  When "Management" wants
software systems to be secure, they will be.  Not perfectly so, but
within published limits.  "Management" will see to it that the
appropriate policies and processes are in place to assure it.
"Management" will see to it that delivering a product that passes the
certification process is more important than delivering a product by a
certain date.  "Management" will require that a security architecture
be in place before the design process starts, etc., etc., etc.  The
board will hold "Management" accountable for the risk that the use of
the system entails.  When that happens, "Management" will come to
realize that security is *their* problem, *not* InfoSec's problem.
/Until/ that happens, changing frameworks, development tools,
methodologies or whatever will not solve the problem.  "The Problem"
just isn't in IT.

As Dennis Miller says:  "But that's just my opinion.  I could be wrong."

/g

Re: [SC-L] How do we improve s/w developer awareness?

[Greenarrow 1]

Words could not be spoken better.  This is my argument from the get go.  I,
to, am tired of seeing everyone blame it on the Dev department when the
orders from above are I want this now and fast.  Maybe, we can focus and
convince upper level management that security is as important as the greed,
money, bells, whistles.  But while I support Dev I still do not understand
how some companies development departments can include tight secured coding
in a short time frame and others seem to provide excuses or just do not
care.

Customers are now looking at the security of programs.  Slowly, consumers
are finally looking at security flaws mainly because of the media coverage
that computer softwares are creating.  While it may only be top contenders
in the software field customers are now questioning other programs they have
which I support fully.  I can see this in the rise of subscribers to certain
Security Flaw Alerts which has risen over 71% within the last 3 months.

Just a word of warning as consumers become more aware of security in the
softwares they purchase companies that do not secure will start showing a
downslide in purchases.  It is happening to one major company as we email
each other on issues.

Regards,
George
Greenarrow1
InNetInvestigations-Forensics


- Original Message -
From: "George Capehart" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 28, 2004 5:18 PM
Subject: Re: [SC-L] How do we improve s/w developer awareness?


> On Thursday 11 November 2004 10:26, Kenneth R. van Wyk allegedly wrote:
> > Greetings,
> >
> > In my business travels, I spend quite a bit of time talking with
> > Software Developers as well as IT Security folks.  One significant
> > different that I've found is that the IT Security folks, by and
> > large, tend to pay a lot of attention to software vulnerability and
> > attack information while most of the Dev folks that I talk to are
> > blissfully unaware of the likes of Full-Disclosure, Bugtraq, PHRACK,
> > etc.  I haven't collected any real stats, but it seems to me to be at
> > least a 90/10% and 10/90% difference.  (Yes, I know that this is a
> > gross generalization and there are no doubt significant exceptions,
> > but...)
> >
> > I believe that this presents a significant hurdle to getting Dev
> > folks to care about Software Security issues.  Books like Gary
> > McGraw's Exploiting Software do a great job at explaining how
> > software can be broken, which is a great first step, but it's only a
> > first step.
>
> Apologies for the two-week latency in this reply.  I don't have as much
> time for the lists as I used to.
>
> I have read the rest of this thread, and I didn't see any comments that
> address a dimension that is, for me, the most salient.  I feel like a
> broken record because this topic crops up on one security-related list
> or another at least once a quarter and I end up saying the same thing
> every time.  I'm going to say it again, though, because I really
> believe that it is important . . . Dev folks will care about security
> when their managers care about security.  If time-to-market and bells
> and whistles are more important to "management" than security is,
> that's where dev folks will spend their time.  It is their job to do
> what their managers tell them to do.  When "management" decides that it
> is more important to deliver a product that is based on a robust
> security architecture and which is built and tested with security in
> mind, it will be.  Until then, it won't.  At one time or another in my
> career, I have held just about every position in the software
> development food chain.  I have had the president of the company tell
> me:  "I don't care what it takes, you /*will*/ have this project done
> and delivered in four months!"  Well, we delivered a
> less-than-half-assed piece of software, but you can be sure that it was
> designed at the keyboard with absolutely *no* thought for security.
> That guy didn't know security from Adam's house cat and cared less.  It
> was not my job to deliver *secure* software.  It was my job to deliver
> /*what we'd promised the customer*/ in four months.  Security wasn't in
> the spec, so security wasn't in the product.
>
> It is not fair to beat up on the developers . . . or even the project
> managers.  This is a governance/risk management problem.  This is a
> C-/board-level problem.  It's not going to be solved until the people
> giving the orders give orders to "do it right."  I know many developers
> and project managers who have a clue, but it doesn't matter if they are
> not allowed to exercise it.
>
> My 0.02$CURRENCY.
>
> Cheers,
>
> George Capehart
> --
> George W. Capehart
>
> Key fingerprint:  3145 104D 9579 26DA DBC7  CDD0 9AE1 8C9C DD70 34EA
>
> "With sufficient thrust, pigs fly just fine."  -- RFC 1925

Re: [SC-L] How do we improve s/w developer awareness?

[George Capehart]

On Thursday 11 November 2004 10:26, Kenneth R. van Wyk allegedly wrote:
> Greetings,
>
> In my business travels, I spend quite a bit of time talking with
> Software Developers as well as IT Security folks.  One significant
> different that I've found is that the IT Security folks, by and
> large, tend to pay a lot of attention to software vulnerability and
> attack information while most of the Dev folks that I talk to are
> blissfully unaware of the likes of Full-Disclosure, Bugtraq, PHRACK,
> etc.  I haven't collected any real stats, but it seems to me to be at
> least a 90/10% and 10/90% difference.  (Yes, I know that this is a
> gross generalization and there are no doubt significant exceptions,
> but...)
>
> I believe that this presents a significant hurdle to getting Dev
> folks to care about Software Security issues.  Books like Gary
> McGraw's Exploiting Software do a great job at explaining how
> software can be broken, which is a great first step, but it's only a
> first step.

Apologies for the two-week latency in this reply.  I don't have as much 
time for the lists as I used to.

I have read the rest of this thread, and I didn't see any comments that 
address a dimension that is, for me, the most salient.  I feel like a 
broken record because this topic crops up on one security-related list 
or another at least once a quarter and I end up saying the same thing 
every time.  I'm going to say it again, though, because I really 
believe that it is important . . . Dev folks will care about security 
when their managers care about security.  If time-to-market and bells 
and whistles are more important to "management" than security is, 
that's where dev folks will spend their time.  It is their job to do 
what their managers tell them to do.  When "management" decides that it 
is more important to deliver a product that is based on a robust 
security architecture and which is built and tested with security in 
mind, it will be.  Until then, it won't.  At one time or another in my 
career, I have held just about every position in the software 
development food chain.  I have had the president of the company tell 
me:  "I don't care what it takes, you /*will*/ have this project done 
and delivered in four months!"  Well, we delivered a 
less-than-half-assed piece of software, but you can be sure that it was 
designed at the keyboard with absolutely *no* thought for security.  
That guy didn't know security from Adam's house cat and cared less.  It 
was not my job to deliver *secure* software.  It was my job to deliver 
/*what we'd promised the customer*/ in four months.  Security wasn't in 
the spec, so security wasn't in the product.

It is not fair to beat up on the developers . . . or even the project 
managers.  This is a governance/risk management problem.  This is a 
C-/board-level problem.  It's not going to be solved until the people 
giving the orders give orders to "do it right."  I know many developers 
and project managers who have a clue, but it doesn't matter if they are 
not allowed to exercise it.

My 0.02$CURRENCY.

Cheers,

George Capehart
-- 
George W. Capehart

Key fingerprint:  3145 104D 9579 26DA DBC7  CDD0 9AE1 8C9C DD70 34EA

"With sufficient thrust, pigs fly just fine."  -- RFC 1925

Re: [SC-L] How do we improve s/w developer awareness?

[Nick Murison]

[ Apologies to moderator for the resend.  I've not PGP/MIME signed this
  one, as I guess that's the reason for the last copy disappearing. ]
[Ed. Apologies back at ya, as I'm on the road this week and trying my best
to deal with a brain-damaged web emailer. KRvW]

On Fri, Nov 12, 2004 at 08:24:59AM -0500, Jeff Williams wrote:
> In my opinion, the way out of this trap is to get more information to
> consumers about the security in software.  Information like how many lines
> of code, what languages, what libraries, process used, security testing
> done, mechanisms included, and other information can and should be
> disclosed.

These metrics are all well and good, but what makes you think consumers will
ever be able to care about such things?  Consumers have so far only cared
about security when it directly affects them.  One could argue that's how it
should be; users should never have to worry about the software they are
running because "bad" software should never get past the door of the
developers.

Providing consumers with assurances about the security of their systems strikes 
me as a good idea,
and this is how
it's worked for government contracts.
However, they need to be in terms which the average consumer will a) understand 
and b) care about.

What would be nice to see would be some form of competition based on
security, and not just the latest wiz-bangs in Grokulator 4.3.  How exactly
you get consumers to care about these things before it immediately affects
them is the question we should be looking at.

Regards,
-- 
Nicholas John Murison
~
http://www.urgusabic.net

Re: [SC-L] How do we improve s/w developer awareness?

[Kenneth R. van Wyk]

<[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Secured by aspStation
Sender: [EMAIL PROTECTED]
Precedence: bulk
Mailing-List: contact <[EMAIL PROTECTED]> ; run by MajorDomo
List-Id: Secure Coding Mailing List 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
List-Help: 
List-Archive: 
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: moderator for [EMAIL PROTECTED]

Dana Epp wrote:

> I think we have to go one step further.
>
> Its nice to know what the attack patterns are. A better thing to do is
> to know how to identify them during threat modeling, and then apply
> safeguards to mitigate the risk. ie: We need a merge of thoughts from
> "Exploiting Software" and "Building Secure Software" into a single
> source... where attack and defense can be spoken about together.

I fully agree with you, Dana, and it's a good point.  That said, though,
let me just revisit the observation that I made at the beginning of this
thread.  In my discussions with a _whole bunch_* of developers, I've
noted that few of them even bother to notice security faults in software
beyond the most cursory levels.  (*No, this doesn't represent a
statistical sampling or any scientific study of any sorts; just my gut
feel.)  The observation came from noticing how few developers read, or
are even aware of the existance of things like Full-Disclosure, Bugtraq,
PHRACK, and RISKS.

Gunnar Peterson noted that security is just one among many "*-ilities"
that developers have to contend with, and that makes good sense to me.

So, I guess that the real question should be, "how do we get software
developers _in general_ to sit up and notice software security?"
Training, books, etc., are well and good, but they presuppose that the
developer has already passed the first hurdle of noticing that security
is an issue.  I'm convinced that most developers will quickly understand
at least most of the issues once they start reading/learning.

Cheers,

Ken van Wyk
KRvW Associates, LLC
http://www.KRvW.com

RE: [SC-L] How do we improve s/w developer awareness?

[Aleksander P. Czarnowski]

Hi,

> We certainly have a lot to learn from the other communities, but 
> security is
> worse than the other *-ilities, because it is more difficult to see.
> Consumers can tell which operating system is easier to use, and 
> which one is
> faster, but there is no way to know which is more secure today.

Let me add to this a bit. Actually if consumer could tell which operating 
system is easier to use and faster than we are on the right track. This is 
about security, as secure operating system should provide stability, speed 
and... it's security system should be invisible to the end user as long as 
he/she is doing his/her job. Of course at the end it comes to more colorful 
icons and nicer pictures for desktop wallpapers...
Just me 2 cents,
Regards
Aleksander Czarnowski
AVET INS 
 

Re: [SC-L] How do we improve s/w developer awareness?

[ljknews]

At 3:39 PM + 11/12/04, M Taylor wrote:

>RISK Digest  (comp.risks) is about the closest,
>although not security focused it does discuss system failures beyond 
>buffer overflows and TCP/IP protocol suite. It does not exclude familiar
>risks (and documented failures) of buffer overflows, but extends into
>numerous design related failures which can have security implications
>which transcend any given platoform or language.

Oh, yes, I read that religiously, I just consider it on a different
plateau than all the others :-)
-- 
Larry Kilgallen

Re: [SC-L] How do we improve s/w developer awareness?

[Dana Epp]

I think we have to go one step further.
Its nice to know what the attack patterns are. A better thing to do is to know how to identify them 
during threat modeling, and then apply safeguards to mitigate the risk. ie: We need a merge of 
thoughts from "Exploiting Software" and "Building Secure Software" into a 
single source... where attack and defense can be spoken about together.
We all like to spout out that until you know the threats to which you are 
susceptible to, you cannot build secure systems. The reality is, unless you 
know how to MITIGATE the threats... simply knowing they exist doesn't do much 
to protect the customer.
Gary McGraw wrote:
One of the reasons that Greg Hoglund and I wrote Exploiting Software was
to gain a basic underdstanding of what we call "attack patterns".  The
idea is to abstract away from platform and language considerations (at
least some), and thus elevate the level of attack discussion.
We identify and discuss 48 attack patterns in Exploiting Software.  Each
of them has a handful of associated examples from real exploits.  I will
paste in the complete list below.  As you will see, we provided a start,
but there is plenty of work here remaining to be done.
Perhaps by talking about patterns of attack we can improve the signal to
noise ratio in the exploit discussion department.
gem
Gary McGraw, Ph.D.
CTO, Cigital
http://www.cigital.com
WE NEED PEOPLE!
Make the Client Invisible
Target Programs That Write to Privileged OS Resources 
Use a User-Supplied Configuration File to Run Commands That Elevate
Privilege 
Make Use of Configuration File Search Paths 
Direct Access to Executable Files 
Embedding Scripts within Scripts 
Leverage Executable Code in Nonexecutable Files 
Argument Injection 
Command Delimiters 
Multiple Parsers and Double Escapes 
User-Supplied Variable Passed to File System Calls 
Postfix NULL Terminator 
Postfix, Null Terminate, and Backslash 
Relative Path Traversal 
Client-Controlled Environment Variables 
User-Supplied Global Variables (DEBUG=1, PHP Globals, and So Forth) 
Session ID, Resource ID, and Blind Trust
Analog In-Band Switching Signals (aka "Blue Boxing") 
Attack Pattern Fragment: Manipulating Terminal Devices 
Simple Script Injection 
Embedding Script in Nonscript Elements 
XSS in HTTP Headers 
HTTP Query Strings 
User-Controlled Filename 
Passing Local Filenames to Functions That Expect a URL 
Meta-characters in E-mail Header
File System Function Injection, Content Based
Client-side Injection, Buffer Overflow
Cause Web Server Misclassification
Alternate Encoding the Leading Ghost Characters
Using Slashes in Alternate Encoding
Using Escaped Slashes in Alternate Encoding 
Unicode Encoding 
UTF-8 Encoding 
URL Encoding 
Alternative IP Addresses 
Slashes and URL Encoding Combined 
Web Logs 
Overflow Binary Resource File 
Overflow Variables and Tags 
Overflow Symbolic Links 
MIME Conversion 
HTTP Cookies 
Filter Failure through Buffer Overflow 
Buffer Overflow with Environment Variables 
Buffer Overflow in an API Call 
Buffer Overflow in Local Command-Line Utilities 
Parameter Expansion 
String Format Overflow in syslog() 



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.


--
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

Re: [SC-L] How do we improve s/w developer awareness?

[Gunnar Peterson]

Concur that security is more colorless than most of the other ilities. My point
is that the other domains which serve up the non-functional requirements are
colorless to some degree as well. So in terms of how the other ility domains
approach the quantification and elaboration of the goals that emerge from their
domains and getting them in the hands of architects and developers, there may
be some activities and artifacts in there that we can learn from.

-gp

Quoting Jeff Williams <[EMAIL PROTECTED]>:

> We certainly have a lot to learn from the other communities, but security is
> worse than the other *-ilities, because it is more difficult to see.
> Consumers can tell which operating system is easier to use, and which one is
> faster, but there is no way to know which is more secure today.
>
> Until consumers can tell the difference between a security program and one
> that is not, they will not pay more for the secure one.  Which means that it
> is not going to make many managers' radar screen, and therefore developer
> awareness will never happen on a broad scale.
>
> In my opinion, the way out of this trap is to get more information to
> consumers about the security in software.  Information like how many lines
> of code, what languages, what libraries, process used, security testing
> done, mechanisms included, and other information can and should be
> disclosed.
>
> --Jeff
>
> - Original Message -
> From: "Gunnar Peterson" <[EMAIL PROTECTED]>
> To: "Yousef Syed" <[EMAIL PROTECTED]>
> Cc: "Secure Coding Mailing List" <[EMAIL PROTECTED]>
> Sent: Friday, November 12, 2004 6:58 AM
> Subject: Re: [SC-L] How do we improve s/w developer awareness?
>
>
> > > Making software secure should be a requirement of the development
> > > process. I've had the priviledge to have worked on some very good
> > > projects where the managers emphasised security in the beginning of
> > > the projects life cycle since it was a requirement of the client.
> >
> > Making software secure absolutely should be part of the development
> > lifecycle, and as early as possible, too. My overall point was that if
> > you talk to the people who really care about usability (as
> > distinguished from just "features") you will hear very similar
> > frustrations about their ability to get what they consider true
> > usability requirements into the end product. So in terms of learning
> > from other communities I think as opposed to beating our heads against
> > the same wall it can be helpful to learn from another *-ility community
> > to see what ways they have tried successfully/unsuccessfully to
> > increase the quality in software from their viewpoint. My suggestion is
> > that the problem is not just software security but run a little deeper
> > to the main problem of software quality of which security is one of the
> > factors (albeit an important one).
> >
> > So what are the common threads amongst usability and security? For
> > examples it is interesting to note that both communities seem to value
> > early involvement in the development lifecycle and striving for
> > simplicity in design. Software security does not need more barriers,
> > but to the extent that we can find allies with similar goals and issues
> > from other communities (could be *-ilitity, business, compliance, legal
> > btw) and collaborate with them to communicate the value of quality,
> > then our chances for shipping better software are increased.
> >
> > -gp
> >
> > "Societies have invested more than a trillion dollars in software and
> > have grotesquely enriched minimally competent software producers whose
> > marketing skills far exceed their programming skills. Despite this
> > enormous long-run investment in software, economists were unable to
> > detect overall gains in economic productivity from information
> > technology until perhaps the mid-1990s or later; the economist Robert
> > Solow once remarked that computers showed up everywhere except in
> > productivity statistics.
> >
> > Quality may sometimes be the happy by-product of competition. The lack
> > of competition for the PC operating system and key applications has
> > reduced the quality and the possibilities for the user interface. There
> > is no need on our interface for a visible OS, visible applications, or
> > for turning the OS and browsers and e-mail programs into marketing
> > experiences. None of this stuff appeared on the original graphical user
> > interface designed by Xerox PARC. That interface consisted almost
> > enti

RE: [SC-L] How do we improve s/w developer awareness?

[Wall, Kevin]

Gary,

While I've not yet seen your _Exploiting Software_ book, I use
your _Building Secure Software_ as one of the texts for a graduate
CS class in security (http://cs.franklin.edu/Syllabus/comp676/).

Unfortunately, I've not seen any copies of your book in any major
bookstore in the Columbus, OH area, so appologies about my
naïvety in this area, but I've not had a chance to peruse it.

But I have one question regarding your "attack patterns"--and please
don't take this as a challenge. My question is, what makes you
and Hoglund's "attack patterns" so different from (say) the security
patterns as described by Yoder and Barcalow or by Mark Schumacher?

What makes "attack patterns" so different than the work done by
the OASIS Web Application Security technical committee (charter at:
http://www.oasis-open.org/committees/was/charter.php) that
is chaired by Mark Curphey, Peter Michalek, and your Citadel
colleague, David Raphael and had its roots in the OWASP ASAC
work started several years ago.

I'm not trying to accuse you of academic plaigarism, but am curious
in how you see your "attack patterns" fitting together in the
bigger picture along with the OASIS WAS work and the generic
security patterns work of Yoder, Barcalow, Schumacher, and others?
Or perhaps are they more like the CVE work maintained by Mitre?

What are the differences? What is the overlap? Can you point to
an online example of any documented attack pattern that you have
in the book so we can see one or a few of them? Why should I want
to use your attack patterns rather than one of these other efforts
I've mentioned?

Like I said, not only have I not _read_ your book, I've not even had
a chance to thumb through it.

I think it's good to try to catalogue such things, but I think it's
going in the wrong direction when there is little industry consensus
on exactly how to do this. Adding yet another classification scheme
is not valuable unless we can understand exactly what the new scheme
brings to the table and how it fits along side other similar attempts.

Also, one last thing... not to nitpick, but it seems that your 48 attack
patterns can be grouped into a few broader categories? Does your book
do this as well?

Thanks in advance for your response,
-kevin wall
---
Kevin W. Wall   Qwest Information Technology, Inc.
[EMAIL PROTECTED]   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



-Original Message-
From: [EMAIL PROTECTED] on behalf of Gary McGraw
Sent: Fri 11/12/2004 8:39 AM
To: ljknews; Secure Coding Mailing List
Subject: RE: [SC-L] How do we improve s/w developer awareness?
 
One of the reasons that Greg Hoglund and I wrote Exploiting Software was
to gain a basic underdstanding of what we call "attack patterns".  The
idea is to abstract away from platform and language considerations (at
least some), and thus elevate the level of attack discussion.

We identify and discuss 48 attack patterns in Exploiting Software.  Each
of them has a handful of associated examples from real exploits.  I will
paste in the complete list below.  As you will see, we provided a start,
but there is plenty of work here remaining to be done.

Perhaps by talking about patterns of attack we can improve the signal to
noise ratio in the exploit discussion department.

gem

Gary McGraw, Ph.D.
CTO, Cigital
http://www.cigital.com
WE NEED PEOPLE!

Make the Client Invisible
Target Programs That Write to Privileged OS Resources 
Use a User-Supplied Configuration File to Run Commands That Elevate
Privilege 
Make Use of Configuration File Search Paths 
Direct Access to Executable Files 
Embedding Scripts within Scripts 
Leverage Executable Code in Nonexecutable Files 
Argument Injection 
Command Delimiters 
Multiple Parsers and Double Escapes 
User-Supplied Variable Passed to File System Calls 
Postfix NULL Terminator 
Postfix, Null Terminate, and Backslash 
Relative Path Traversal 
Client-Controlled Environment Variables 
User-Supplied Global Variables (DEBUG=1, PHP Globals, and So Forth) 
Session ID, Resource ID, and Blind Trust
Analog In-Band Switching Signals (aka "Blue Boxing") 
Attack Pattern Fragment: Manipulating Terminal Devices 
Simple Script Injection 
Embedding Script in Nonscript Elements 
XSS in HTTP Headers 
HTTP Query Strings 
User-Controlled Filename 
Passing Local Filenames to Functions That Expect a URL 
Meta-characters in E-mail Header
File System Function Injection, Content Based
Client-side Injection, Buffer Overflow
Cause Web Server Misclassification
Alternate Encoding the Leading Ghost Characters
Using Slashes in Alternate Encoding
Using Escaped Slashes in Alternate Encoding 
Unicode Encoding 
UTF-8 Encoding 
URL Encoding 
Alternati

Re: [SC-L] How do we improve s/w developer awareness?

[M Taylor]

On Thu, Nov 11, 2004 at 04:56:20PM -0500, ljknews wrote:
> At 2:48 PM -0500 11/11/04, Paco Hope wrote:
> 
> >On 11/11/04 11:46 AM, "ljknews" <[EMAIL PROTECTED]> wrote:
> >> As a software developer, I care about such issues, but the compiliations
> >> you list are largely not applicable to the operating system and programming
> >> languages with which I work.
> >
> 
> I am still looking for a forum that omits those problems due to choice
> of C and related programming languages that use null terminated string.
> I know that is a bad idea, and I don't do it.
> 
> I am still looking for a forum that omits problems propagated over IP
> and related protocols.  I don't do that either.
> 
> I have yet to see a standard "tool" (as distinguished from social
> engineering technique) from elsewhere that fits VMS.
> 

RISK Digest  (comp.risks) is about the closest,
although not security focused it does discuss system failures beyond 
buffer overflows and TCP/IP protocol suite. It does not exclude familiar
risks (and documented failures) of buffer overflows, but extends into
numerous design related failures which can have security implications
which transcend any given platoform or language.

Of course VMS is not immune to security risks. I know, I created more
than one insecure piece of software for VMS (in-house stuff that is 
now retired).

RE: [SC-L] How do we improve s/w developer awareness?

[Gary McGraw]

On the usability and software security front, you may be interested in
the "Principle 6: Keep it Simple" discussion found in Chapter 5 of
Building Secure Software (pages 104-107).

gem




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.

Re: [SC-L] How do we improve s/w developer awareness?

[Jeff Williams]

We certainly have a lot to learn from the other communities, but security is
worse than the other *-ilities, because it is more difficult to see.
Consumers can tell which operating system is easier to use, and which one is
faster, but there is no way to know which is more secure today.

Until consumers can tell the difference between a security program and one
that is not, they will not pay more for the secure one.  Which means that it
is not going to make many managers' radar screen, and therefore developer
awareness will never happen on a broad scale.

In my opinion, the way out of this trap is to get more information to
consumers about the security in software.  Information like how many lines
of code, what languages, what libraries, process used, security testing
done, mechanisms included, and other information can and should be
disclosed.

--Jeff

- Original Message - 
From: "Gunnar Peterson" <[EMAIL PROTECTED]>
To: "Yousef Syed" <[EMAIL PROTECTED]>
Cc: "Secure Coding Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, November 12, 2004 6:58 AM
Subject: Re: [SC-L] How do we improve s/w developer awareness?


> > Making software secure should be a requirement of the development
> > process. I've had the priviledge to have worked on some very good
> > projects where the managers emphasised security in the beginning of
> > the projects life cycle since it was a requirement of the client.
>
> Making software secure absolutely should be part of the development
> lifecycle, and as early as possible, too. My overall point was that if
> you talk to the people who really care about usability (as
> distinguished from just "features") you will hear very similar
> frustrations about their ability to get what they consider true
> usability requirements into the end product. So in terms of learning
> from other communities I think as opposed to beating our heads against
> the same wall it can be helpful to learn from another *-ility community
> to see what ways they have tried successfully/unsuccessfully to
> increase the quality in software from their viewpoint. My suggestion is
> that the problem is not just software security but run a little deeper
> to the main problem of software quality of which security is one of the
> factors (albeit an important one).
>
> So what are the common threads amongst usability and security? For
> examples it is interesting to note that both communities seem to value
> early involvement in the development lifecycle and striving for
> simplicity in design. Software security does not need more barriers,
> but to the extent that we can find allies with similar goals and issues
> from other communities (could be *-ilitity, business, compliance, legal
> btw) and collaborate with them to communicate the value of quality,
> then our chances for shipping better software are increased.
>
> -gp
>
> "Societies have invested more than a trillion dollars in software and
> have grotesquely enriched minimally competent software producers whose
> marketing skills far exceed their programming skills. Despite this
> enormous long-run investment in software, economists were unable to
> detect overall gains in economic productivity from information
> technology until perhaps the mid-1990s or later; the economist Robert
> Solow once remarked that computers showed up everywhere except in
> productivity statistics.
>
> Quality may sometimes be the happy by-product of competition. The lack
> of competition for the PC operating system and key applications has
> reduced the quality and the possibilities for the user interface. There
> is no need on our interface for a visible OS, visible applications, or
> for turning the OS and browsers and e-mail programs into marketing
> experiences. None of this stuff appeared on the original graphical user
> interface designed by Xerox PARC. That interface consisted almost
> entirely of documents--which are, after all, what users care about.
> Vigorous competition might well have led to distinctly better PC
> interfaces--without computer administrative debris, without operating
> system imperialism, without unwanted marketing experiences--compared to
> what we have now on Windows and Mac.
>
>   Today nearly all PC software "competition" is merely between the old
> release and the new release of the same damn product. It is hard to
> imagine a more perversely sluggish incentive system for quality.
> Indeed, under such a system, the optimal economic strategy for market
> leaders may well be the production and distribution of buggy software,
> for the real money is in the updates and later releases.
>
> One of Philip Greenspun's points in his introductory programming course
> at MIT

RE: [SC-L] How do we improve s/w developer awareness?

[Gary McGraw]

One of the reasons that Greg Hoglund and I wrote Exploiting Software was
to gain a basic underdstanding of what we call "attack patterns".  The
idea is to abstract away from platform and language considerations (at
least some), and thus elevate the level of attack discussion.

We identify and discuss 48 attack patterns in Exploiting Software.  Each
of them has a handful of associated examples from real exploits.  I will
paste in the complete list below.  As you will see, we provided a start,
but there is plenty of work here remaining to be done.

Perhaps by talking about patterns of attack we can improve the signal to
noise ratio in the exploit discussion department.

gem

Gary McGraw, Ph.D.
CTO, Cigital
http://www.cigital.com
WE NEED PEOPLE!

Make the Client Invisible
Target Programs That Write to Privileged OS Resources 
Use a User-Supplied Configuration File to Run Commands That Elevate
Privilege 
Make Use of Configuration File Search Paths 
Direct Access to Executable Files 
Embedding Scripts within Scripts 
Leverage Executable Code in Nonexecutable Files 
Argument Injection 
Command Delimiters 
Multiple Parsers and Double Escapes 
User-Supplied Variable Passed to File System Calls 
Postfix NULL Terminator 
Postfix, Null Terminate, and Backslash 
Relative Path Traversal 
Client-Controlled Environment Variables 
User-Supplied Global Variables (DEBUG=1, PHP Globals, and So Forth) 
Session ID, Resource ID, and Blind Trust
Analog In-Band Switching Signals (aka "Blue Boxing") 
Attack Pattern Fragment: Manipulating Terminal Devices 
Simple Script Injection 
Embedding Script in Nonscript Elements 
XSS in HTTP Headers 
HTTP Query Strings 
User-Controlled Filename 
Passing Local Filenames to Functions That Expect a URL 
Meta-characters in E-mail Header
File System Function Injection, Content Based
Client-side Injection, Buffer Overflow
Cause Web Server Misclassification
Alternate Encoding the Leading Ghost Characters
Using Slashes in Alternate Encoding
Using Escaped Slashes in Alternate Encoding 
Unicode Encoding 
UTF-8 Encoding 
URL Encoding 
Alternative IP Addresses 
Slashes and URL Encoding Combined 
Web Logs 
Overflow Binary Resource File 
Overflow Variables and Tags 
Overflow Symbolic Links 
MIME Conversion 
HTTP Cookies 
Filter Failure through Buffer Overflow 
Buffer Overflow with Environment Variables 
Buffer Overflow in an API Call 
Buffer Overflow in Local Command-Line Utilities 
Parameter Expansion 
String Format Overflow in syslog() 




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.

Re: [SC-L] How do we improve s/w developer awareness?

[Gunnar Peterson]

> Making software secure should be a requirement of the development  
> process. I've had the priviledge to have worked on some very good  
> projects where the managers emphasised security in the beginning of  
> the projects life cycle since it was a requirement of the client.

Making software secure absolutely should be part of the development  
lifecycle, and as early as possible, too. My overall point was that if  
you talk to the people who really care about usability (as  
distinguished from just "features") you will hear very similar  
frustrations about their ability to get what they consider true  
usability requirements into the end product. So in terms of learning  
from other communities I think as opposed to beating our heads against  
the same wall it can be helpful to learn from another *-ility community  
to see what ways they have tried successfully/unsuccessfully to  
increase the quality in software from their viewpoint. My suggestion is  
that the problem is not just software security but run a little deeper  
to the main problem of software quality of which security is one of the  
factors (albeit an important one).

So what are the common threads amongst usability and security? For  
examples it is interesting to note that both communities seem to value  
early involvement in the development lifecycle and striving for  
simplicity in design. Software security does not need more barriers,  
but to the extent that we can find allies with similar goals and issues  
from other communities (could be *-ilitity, business, compliance, legal  
btw) and collaborate with them to communicate the value of quality,  
then our chances for shipping better software are increased.

-gp

"Societies have invested more than a trillion dollars in software and  
have grotesquely enriched minimally competent software producers whose  
marketing skills far exceed their programming skills. Despite this  
enormous long-run investment in software, economists were unable to  
detect overall gains in economic productivity from information  
technology until perhaps the mid-1990s or later; the economist Robert  
Solow once remarked that computers showed up everywhere except in  
productivity statistics.

Quality may sometimes be the happy by-product of competition. The lack  
of competition for the PC operating system and key applications has  
reduced the quality and the possibilities for the user interface. There  
is no need on our interface for a visible OS, visible applications, or  
for turning the OS and browsers and e-mail programs into marketing  
experiences. None of this stuff appeared on the original graphical user  
interface designed by Xerox PARC. That interface consisted almost  
entirely of documents--which are, after all, what users care about.  
Vigorous competition might well have led to distinctly better PC  
interfaces--without computer administrative debris, without operating  
system imperialism, without unwanted marketing experiences--compared to  
what we have now on Windows and Mac.

  Today nearly all PC software "competition" is merely between the old  
release and the new release of the same damn product. It is hard to  
imagine a more perversely sluggish incentive system for quality.  
Indeed, under such a system, the optimal economic strategy for market  
leaders may well be the production and distribution of buggy software,  
for the real money is in the updates and later releases.

One of Philip Greenspun's points in his introductory programming course  
at MIT is that the one-semester course can enable students to create  
the programming equivalent of the amazon, eBay, or photo.net websites.  
So why it is so hard to get it right the first time? Or at least by the  
Release 8.06th time? See Software Engineering for Internet Applications  
(MIT 6.171) at http://philip.greenspun.com/teaching/one-term-web

-- Edward Tufte, June 28, 2002 "
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg? 
msg_id=D8&topic_id=1&topic=Ask%20E%2eT%2e

Re: [SC-L] How do we improve s/w developer awareness?

[ljknews]

At 2:48 PM -0500 11/11/04, Paco Hope wrote:

>On 11/11/04 11:46 AM, "ljknews" <[EMAIL PROTECTED]> wrote:
>> As a software developer, I care about such issues, but the compiliations
>> you list are largely not applicable to the operating system and programming
>> languages with which I work.
>
>Advisories, problems, and failures do not have involve your platform or
>language to be instructive. In fact, in this age of productization and
>commoditization of technology, many of the differences are superficial.

I am still looking for a forum that omits those problems due to choice
of C and related programming languages that use null terminated string.
I know that is a bad idea, and I don't do it.

I am still looking for a forum that omits problems propagated over IP
and related protocols.  I don't do that either.

>Sure, the stock exploits won't apply, or maybe the concepts need some
>translation, but there is absolutely a good reason to be aware of the
>failures in other software. The same marketing that makes us think
>FooBarSystems Gronkulator 4.2 is much better than Gronkulator 4.1 makes us
>think that security issues written up on Gronulator 4.x have nothing to do
>with other versions of Gronkulator, or Linux for that matter. There are a
>surprisingly small number of tools in hackers' toolboxes, yet they all seem
>to fit lots and lots of software.

I have yet to see a standard "tool" (as distinguished from social
engineering technique) from elsewhere that fits VMS.

>Should you join every single mailing list in the world and read every single
>post? No. Should you only join the security-[platform]-[language] email list
>for the one thing you program? Also no. Somewhere between the extremes of
>"read everything you can" and working with blinders on is the "right" place
>where you read "stuff that I'm not working on, but informs me." It's not
>always an easy place to find. But I reject categorical statements like the
>one above that appear to say "if it ain't specific to my platform, it has no
>value to me."

No, I am saying "the typical forum is so full of irrelevant material that
it is a waste of my time that should be spent elsewhere".
-- 
Larry Kilgallen

Re: [SC-L] How do we improve s/w developer awareness?

[Yousef Syed]

Making software secure should be a requirement of the development process. I've 
had the priviledge to have worked on some very good projects where the managers 
emphasised security in the beginning of the projects life cycle since it was a 
requirement of the client. 

Unfourtunately, functionality for users takes precedence and Security is 
usually left as an add-on at the end in most places. 
This is down to managers and the business/clients not giving security the right 
focus. 
I've been told on atleast two projects not to worry about security "because we 
have a firewall"! Even if they can be convinced of the benefits of security in 
depth etc, they still don't want to do it.
That is the mentality that many developers are up against. Couple that to 
demands on budget and deadlines, it is no wonder that so much software is 
insecure. 

ys

- Original Message -
From: Gunnar Peterson <[EMAIL PROTECTED]>
To: "Kenneth R. van Wyk" <[EMAIL PROTECTED]>
Subject: Re: [SC-L] How do we improve s/w developer awareness?
Date: Thu, 11 Nov 2004 10:34:24 -0600

> 
> I agree. In general "classic" IT Security types are too focused on the problem
> and not focused enough on the solution side of the equation. Development is in
> many cases simply blissfully unaware of real security or thinks its someone
> else's job. In terms of dealing with developers and getting them to care,
> Gary's books and Secure Coding are excellent resources for motivated
> developers. I think it is important to understand that there a lot of problems
> with software, not just security problems. Studying how, say, usability
> architects approach software problems is instructive in how security personnel
> may effectively engage developers. If you read this thread from Edward Tufte's
> site, then you see that leading usability people have no more easy answers 
> than
> software security people:
> 
> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=D8&topic_id=1&topic=Ask%20E%2eT%2e
> 
> If we say that the value of software is tied to how usable, reliable and 
> secure
> the software is, then how do we get developers to care about *-ility?
> 
> *-ilities unite!
> 
> -gp
> 
> Quoting "Kenneth R. van Wyk" <[EMAIL PROTECTED]>:
> 
> > Greetings,
> >
> > In my business travels, I spend quite a bit of time talking with Software
> > Developers as well as IT Security folks.  One significant different that 
> > I've
> > found is that the IT Security folks, by and large, tend to pay a lot of
> > attention to software vulnerability and attack information while most of the
> > Dev folks that I talk to are blissfully unaware of the likes of
> > Full-Disclosure, Bugtraq, PHRACK, etc.  I haven't collected any real stats,
> > but it seems to me to be at least a 90/10% and 10/90% difference.  (Yes, I
> > know that this is a gross generalization and there are no doubt significant
> > exceptions, but...)
> >
> > I believe that this presents a significant hurdle to getting Dev folks to
> > care
> > about Software Security issues.  Books like Gary McGraw's Exploiting 
> > Software
> > do a great job at explaining how software can be broken, which is a great
> > first step, but it's only a first step.
> >
> > Am I alone in this opinion or have others noticed the same sort of thing?
> > It's going to be a long, slow battle, in my opinion.
> >
> > Cheers,
> >
> > Ken
> > --
> > KRvW Associates, LLC
> > http://www.KRvW.com
> >
> 
> 
> 

-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [SC-L] How do we improve s/w developer awareness?

[Gunnar Peterson]

I agree. In general "classic" IT Security types are too focused on the problem
and not focused enough on the solution side of the equation. Development is in
many cases simply blissfully unaware of real security or thinks its someone
else's job. In terms of dealing with developers and getting them to care,
Gary's books and Secure Coding are excellent resources for motivated
developers. I think it is important to understand that there a lot of problems
with software, not just security problems. Studying how, say, usability
architects approach software problems is instructive in how security personnel
may effectively engage developers. If you read this thread from Edward Tufte's
site, then you see that leading usability people have no more easy answers than
software security people:

http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=D8&topic_id=1&topic=Ask%20E%2eT%2e

If we say that the value of software is tied to how usable, reliable and secure
the software is, then how do we get developers to care about *-ility?

*-ilities unite!

-gp

Quoting "Kenneth R. van Wyk" <[EMAIL PROTECTED]>:

> Greetings,
>
> In my business travels, I spend quite a bit of time talking with Software
> Developers as well as IT Security folks.  One significant different that I've
> found is that the IT Security folks, by and large, tend to pay a lot of
> attention to software vulnerability and attack information while most of the
> Dev folks that I talk to are blissfully unaware of the likes of
> Full-Disclosure, Bugtraq, PHRACK, etc.  I haven't collected any real stats,
> but it seems to me to be at least a 90/10% and 10/90% difference.  (Yes, I
> know that this is a gross generalization and there are no doubt significant
> exceptions, but...)
>
> I believe that this presents a significant hurdle to getting Dev folks to
> care
> about Software Security issues.  Books like Gary McGraw's Exploiting Software
> do a great job at explaining how software can be broken, which is a great
> first step, but it's only a first step.
>
> Am I alone in this opinion or have others noticed the same sort of thing?
> It's going to be a long, slow battle, in my opinion.
>
> Cheers,
>
> Ken
> --
> KRvW Associates, LLC
> http://www.KRvW.com
>

Re: [SC-L] How do we improve s/w developer awareness?

[Paco Hope]

On the one hand, we're revisiting a topic that comes up like clockwork every
3 months or so.  Someone rants that it's the developers' fault, then someone
will inject a recommendation that tools can allow us to use trained monkeys,
and then someone will bring out an obscure operating system or language and
just say "If we all wrote object oriented snobol on Atari 2600s we wouldn't
have this problem."  Lather. Rinse. Repeat.

On the other hand, I think I can say something constructive in reply to
this.

On 11/11/04 11:46 AM, "ljknews" <[EMAIL PROTECTED]> wrote:
> As a software developer, I care about such issues, but the compiliations
> you list are largely not applicable to the operating system and programming
> languages with which I work.

Advisories, problems, and failures do not have involve your platform or
language to be instructive. In fact, in this age of productization and
commoditization of technology, many of the differences are superficial.
Sure, the stock exploits won't apply, or maybe the concepts need some
translation, but there is absolutely a good reason to be aware of the
failures in other software. The same marketing that makes us think
FooBarSystems Gronkulator 4.2 is much better than Gronkulator 4.1 makes us
think that security issues written up on Gronulator 4.x have nothing to do
with other versions of Gronkulator, or Linux for that matter. There are a
surprisingly small number of tools in hackers' toolboxes, yet they all seem
to fit lots and lots of software.

For example, a developer developing a traditional 3-tier web app using
VB.NET on Windows servers would absolutely benefit from understanding how
the design and architecture of a 3-tier java-based site running on Solaris
failed. You have to be able to extrapolate and get a view of the forest
instead of the trees, but it is valuable indeed.

Should you join every single mailing list in the world and read every single
post? No. Should you only join the security-[platform]-[language] email list
for the one thing you program? Also no. Somewhere between the extremes of
"read everything you can" and working with blinders on is the "right" place
where you read "stuff that I'm not working on, but informs me." It's not
always an easy place to find. But I reject categorical statements like the
one above that appear to say "if it ain't specific to my platform, it has no
value to me."

Paco
--
Paco Hope, CISSP
Senior Software Security Consultant
Cigital, Inc. http://www.cigital.com/
[EMAIL PROTECTED] -- +1.703.585.7868




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.

Re: [SC-L] How do we improve s/w developer awareness?

[ljknews]

At 10:26 AM -0500 11/11/04, Kenneth R. van Wyk wrote:

>In my business travels, I spend quite a bit of time talking with Software 
>Developers as well as IT Security folks.  One significant different that I've 
>found is that the IT Security folks, by and large, tend to pay a lot of 
>attention to software vulnerability and attack information while most of the 
>Dev folks that I talk to are blissfully unaware of the likes of 
>Full-Disclosure, Bugtraq, PHRACK, etc.

>I believe that this presents a significant hurdle to getting Dev folks to care 
>about Software Security issues.

As a software developer, I care about such issues, but the compiliations
you list are largely not applicable to the operating system and programming
languages with which I work.
-- 
Larry Kilgallen

[SC-L] How do we improve s/w developer awareness?

[Kenneth R. van Wyk]

Greetings,

In my business travels, I spend quite a bit of time talking with Software 
Developers as well as IT Security folks.  One significant different that I've 
found is that the IT Security folks, by and large, tend to pay a lot of 
attention to software vulnerability and attack information while most of the 
Dev folks that I talk to are blissfully unaware of the likes of 
Full-Disclosure, Bugtraq, PHRACK, etc.  I haven't collected any real stats, 
but it seems to me to be at least a 90/10% and 10/90% difference.  (Yes, I 
know that this is a gross generalization and there are no doubt significant 
exceptions, but...)

I believe that this presents a significant hurdle to getting Dev folks to care 
about Software Security issues.  Books like Gary McGraw's Exploiting Software 
do a great job at explaining how software can be broken, which is a great 
first step, but it's only a first step.

Am I alone in this opinion or have others noticed the same sort of thing?  
It's going to be a long, slow battle, in my opinion.

Cheers,

Ken
-- 
KRvW Associates, LLC
http://www.KRvW.com