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

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 
Alternative IP Addresses 
Slashes and URL Encoding Combined 
Web Logs 
Overflow Binary Resource File 
Overflow Variables and Tags 
Overflow

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

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