Re: [SC-L] re-writing college books - erm.. ahm...

[pete werner]

On 11/7/06, Wall, Kevin <[EMAIL PROTECTED]> wrote:
>
> Developers have to cut corners somewhere, and since security issues
> are not paramount, that's often what gets overlooked.
>

this is the biggest issue i think. it gets overlooked because
management dont value it. partly because its expensive to do, and
theres no real qualitative or quantitative measures of success. you
cant go to your management and say "i spent 20% of my time working on
security issues, it cost us $x but it will save our customers $y, and
security was improved by 15%" or if you can, you're bullshitting, but
will probably get a nice bonus :)

i think a college level textbook would have limited benefit. there is
plenty of information out there at the moment for those who are
interested, both on the net and in book form. i suppose its nice to
have a single point of reference though. however, most graduates
aren't really good practical programmers. they know stuff like what a
for loop is and how recursion works, which is great, but they learn
the ins and outs of developing when they get their first real job.

so they get their first job, and basically learn from the people
they're working with. the people they're working with and learning
from are busy, and working under time and budget constraints. they're
just not going to focus on security, even if they had the knowledge to
do it effectively, because other things are more important to the
companies management. most managers (and developers too i guess) do
care about security, but only in the way people care about global
warming. they know global warming is bad, but oh gee what are we going
to do, oh today i remembered to turn off my desk lamp when i left the
office. great. same with security, you dont have to be a genius to
work out security holes are bad, but oh gee what are you actually
going to do about it?

if organisations dont really care about software security, a security
concious developer faces an uphill battle. if two devs are working on
some code, one does it slower but more securely, the other does it
quicker but less securely, who's going to look better, in a typical
organisation? your fresh grad is going to learn quick enough what
companies want from them. as time goes by, they become the ones
breaking in the new developers, so the cycle continues. a book isnt
going to help this, it probably wont hurt, but i dont think the lack
of available literature is a big problem.

a good organisation will focus on what its customers want. untill the
customers start kicking up a storm about vulnerabilities, there's
little impetus for management to devote resources to security. i think
this is one of the things microsoft has done well, over the last few
years they have started taking security seriously, and i can only
assume its because their customers starting complaining. they still
have a lot of security issues (an insuperable amount imo), but it
shows that for companies to start taking software security seriously,
it has to be something the customer wants.
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Wall, Kevin]

In response to a post by Jerry Leichter, Gadi Evron wrote...

> A bridge is a single-purpose device. A watch is a simple
> purpose computer, as was the Enigma machine, if we can call
> it such.
> 
> Multi-purpose computers or programmable computers are where
> our problems start. Anyone can DO and create. One simply has
> to sit in front of a keyboard and screen and make it happen.

Let us keep in mind that in the name of profits (and ignoring our
prophets, see .sig, below), as an industry, we have strived to
lower the entry level of programming by introducing "diseases"
(I'll probably catch some flack for that) such as Visual Basic,
etc. so that managers who have never had even the simplest
introduction to computer science can now develop their own
software, complete with security vulnerabilities. This only
exacerbates the situation. To add to that, often you get some
manager or marketing type who slaps together a "working" prototype
of something they or a customer is asking for by using a spreadsheet,
an Access "database", and some VB glue that works for maybe 100
records and then s/he thinks that a small development team should be
able to tweak that prototype to turn it into an enterprise-wide,
Internet-facing application that can handle millions of records,
handle a transaction volume that is 3 or 4 orders of magnitude larger
than the prototype handles, and slap it all together in a couple
of weeks.

Developers have to cut corners somewhere, and since security issues
are not paramount, that's often what gets overlooked.

As an industry, I think that we've, in part, done this to ourselves.
When I started in this industry 27 years ago, at least real software
engineering techniques were _attempted_. There were requirements
gathered, specifications written and reviewed, designs written,
reviewed, and applied, and an extensive testing period after
coding was more or less complete. But that used to take 15-20 people
about 1 to 2 years. Now we've compressed that down to 90 days or so,
so something had to give (besides our sanity ;-). What I see today
is a few "analysts" go talk to marketing or other stakeholders and
they write up some "user stories" (not even real "use cases"; what
I'm referring to but more like a sentence or two describing some basic,
sunny-day-only usage scenario collected into a spreadsheet). From
there, the application development teams jump directly into coding/testing,
magically expecting the design to somehow just "emerge" or expecting to
be able to "refactor it" later (if there ever is a "later"). (Can you
tell I think that extreme programming--at least as practiced here--has
been a horrible failure, especially from a security POV? :)

I ask you, just where would civil or mechanical engineering be today
if they had encouraged the average construction worker to develop their
own bridge or designed their own buildings rather than relying on
architects and engineers to do this? That's just one reason why things
are as bad as they are. Today, I don't even see professional software
developers develop software using good software engineering principles.
("It takes too long" or "It's too expensive" are the usual comments.)
Or where would we be if the city council expected to build a new
80-story skyscraper, starting from inception, in only 6 months?
It's no wonder that we so often here that remark that says

 "If [building] architects built buildings the way that
 software developers build software, the first woodpecker
 that came by would destroy civilization."

Maybe what we need is to require that as part of the software development
education, we need to partly indoctrinate them into other "real"
engineering disciplines and hope that some of it rubs off. Because, IMO
what we are doing now is failing miserably.

BTW, if you've not yet read the Dijkstra article referenced below, I
highly recommend it. It's quite dated, but it's a gem for .sig quotes.

-kevin

Std disclaimer: Everything I've written above reflects solely my own
opinion and not the opinion of any of my employers,
past or present.
--- 
Kevin W. Wall   Qwest Information Technology, Inc. 
[EMAIL PROTECTED]  Phone: 614.215.4788 
"It is practically impossible to teach good programming to students 
 that have had a prior exposure to BASIC: as potential programmers 
 they are mentally mutilated beyond hope of regeneration" 
- Edsger Dijkstra, How do we tell truths that matter? 
  http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html 
 



This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attach

Re: [SC-L] re-writing college books - erm.. ahm...

[Leichter, Jerry]

| Most of the incidents in your first paragraph were improved with the
| establishment of laws, regulation bodies, and external testing with a
| stamp of approval.  The Underwriters labaroratory was established to
| ensure that a product was sales worthy to the public due to
| manufacturers focusing on sales and not much on safety.
|  
|  Having a clearing house/body/organization which inspects an
| application for business worthiness, critical machinery functions,
| consumer entertainment or consumer sensitive use (personal planner,
| financial package) might persuade vendors to use security enabled
| tools and software building tools stricktly based upon how difficult
| it is to acheive a worthiness approval. For instance if an application
| is developed in C,C++,C# then an appropriate set of audits and testing
| must be performed to acheive a certification. Since these would be
| more comprehensive than other languages the vendor would have to
| decide which is easier the extra expense of the extensive audits and
| testing vs. using a approved language that does not required a greater
| degree of testing. This would provide software tools vendors the
| incentive to create more security enabled tools to align themselves
| with the requirements of the body delivering the accredication for
| use.
|  
|  The software industry is no different than most other
| industries. There are devices with little risk a garage door opener, a
| radio might have more user risk depending upon how you look at it, and
| then there are very dangerous applicances Irons, Microwaves, Snow
| Blowers.  For software a game, word processor, personal finance
| planner, for a business a financial package.
I agree with what you say  until the very last paragraph.  The
different in the software industry is that we don't really know yet what
the right standards should be - and it's not even clear to me that there
is any concerted effort to find out.  Yes, it's possible to build
highly reliable software for things like aircraft control.  It's (a)
extremely expensive to do - the techniques we have today are so
expensive as to rule out all but obviously life-critical uses of
software; (b) only give you assurance in certain directions.  In
particular, aircraft control software doesn't have to be exposed to
active, intelligent attackers on the Internet.

All elements of the software development community - developers
themselves, software makers, makers of products based on software, even
most software purchasers and users - have a vested interest in resisting
such laws, regulations, and external bodies.  It crimps their style,
adds to their costs, and has no obvious benefits.  The same, of course,
was true of most other kinds of engineered product development at some
point in their life.  However, it's much easier for everyone to see that
there is something wrong when a boiler blows up because the maker saved
money by using steel that's too brittle than it is to see that a bug in
handling URL's allowed a cross-site scripting attack that allowed
critical information to be stolen.  This leads to much less pressure on
the software industry to fix things.  Things are changing, but we're
running into another problem: Even very simple attempts at regulation
quickly run into lack of the basic science and engineering knowledge
necessary.  Industry standards on boilers could refer to standard tables
of steel strengths.  An industry standard to prevent cross-site
scripting attacks could refer to ... what, exactly?  And, again, there
is the important distinction that boiler failures are due to "lawful"
physical processes, while cross-site scripting prevention failures are
due to intelligent attacks.  Perhaps for that kind of thing we need to
look not at industry standards but at military experience

-- Jerry
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Paul Powenski]

Most of the incidents in your first paragraph were improved with the establishment of laws, regulation bodies, and external testing with a stamp of approval. The Underwriters labaroratory was established to ensure that a product was sales worthy to the public due to manufacturers focusing on sales and not much on safety.   Having a clearing house/body/organization which inspects an application for business worthiness, critical machinery functions, consumer entertainment or consumer sensitive use (personal planner, financial package) might  persuade vendors to use security enabled tools and  software building tools stricktly based upon  how difficult it is to acheive a  worthiness  approval. For instance if an application is developed in C,C++,C# then an appropriate set of audits and testing must be performed to acheive a certification. Since these would be more comprehensive than other languages the vendor would have to decide which is
 easier the extra expense of the extensive audits and testing vs. using a approved language that does not required a greater degree of testing. This would provide software tools vendors the incentive to create more security enabled tools to align themselves with the requirements of the body delivering the accredication for use.  The software industry is no different than most other industries. There are devices with little risk a garage door opener, a radio might have more user risk depending upon how you look at it, and then there are very dangerous applicances Irons, Microwaves, Snow Blowers.  For software a game, word processor, personal finance planner, for a business a financial package.  "Leichter, Jerry" <[EMAIL PROTECTED]> wrote: Much as I agree with many of the sentiments expressed in this
 discussion,there's a certain air of unreality to it.  While software has it's ownset of problems, it's not the first engineered artifact with securityimplications in the history of the world.  Bridges and buildingsregularly collapsed.  (In the Egyptian desert, you can still see apyramid that was built too aggressively - every designer wanted tobuild higher and steeper than his predecessor - and collapsed beforeit was finished.)  Steam boilers exploded.  Steel linings on woodenrailroad tracks stripped of, flew through the floors of passing cars,and killed people.  Electrical systems regularly caused fires.How do we keep such traditional artifacts safe?  It's not by writingintroductory texts with details of safety margins, how to analyze thestrength of materials, how to include a crowbar in a power supply.What you *may* get in an introductory course is the notion that thereare standards, that when it comes time for
 you to actually designstuff you'll have to know and follow them, and that if you don't you'relikely to end up at best unemployed and possibly in jail when your"creativity" kills someone.In software, we have only the beginnings of such standards.  Weteach and encourage an attitude in which every last bit of thesoftware is a valid place to exercise your creativity, for betteror (for most people, most of the time) worse.  With no establishedstandards, we have no way to push back on managers and marketingguys and such who insist that something must be shipped by theend of the week, handle 100 clients at a time, have no more tha1 second response time, and run on some old 486 with 2 MB of memory.I don't want to get into the morass of licensing.  It's a fact thatlicensing is heavily intertwined with standard-setting in manyolder fields, but not in all of them, and there's no obvious inherentreason why it has to
 be.The efforts to write down "best practices" at CERT are very important,but also very preliminary.  As it stands, what we have to offerare analogous to best practices for using saws and hammers andsuch - not best practices for determining floor loadings, appropriatebeam strengths, safe fire evacuation routes.Every little bit helps, but a look at history shows us just howlittle we really have to offer as yet.   -- Jerry___Secure Coding mailing list (SC-L)SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php 

 Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. 
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Gadi Evron]

On Sun, 5 Nov 2006, Leichter, Jerry wrote:
> Much as I agree with many of the sentiments expressed in this discussion,
> there's a certain air of unreality to it.  While software has it's own
> set of problems, it's not the first engineered artifact with security
> implications in the history of the world.  Bridges and buildings
> regularly collapsed.  (In the Egyptian desert, you can still see a
> pyramid that was built too aggressively - every designer wanted to
> build higher and steeper than his predecessor - and collapsed before
> it was finished.)  Steam boilers exploded.  Steel linings on wooden
> railroad tracks stripped of, flew through the floors of passing cars,
> and killed people.  Electrical systems regularly caused fires.
> 
> How do we keep such traditional artifacts safe?  It's not by writing
> introductory texts with details of safety margins, how to analyze the
> strength of materials, how to include a crowbar in a power supply.
> What you *may* get in an introductory course is the notion that there
> are standards, that when it comes time for you to actually design
> stuff you'll have to know and follow them, and that if you don't you're
> likely to end up at best unemployed and possibly in jail when your
> "creativity" kills someone.
> 
> In software, we have only the beginnings of such standards.  We
> teach and encourage an attitude in which every last bit of the
> software is a valid place to exercise your creativity, for better
> or (for most people, most of the time) worse.  With no established
> standards, we have no way to push back on managers and marketing
> guys and such who insist that something must be shipped by the
> end of the week, handle 100 clients at a time, have no more tha
> 1 second response time, and run on some old 486 with 2 MB of memory.
> 
> I don't want to get into the morass of licensing.  It's a fact that
> licensing is heavily intertwined with standard-setting in many
> older fields, but not in all of them, and there's no obvious inherent
> reason why it has to be.
> 
> The efforts to write down "best practices" at CERT are very important,
> but also very preliminary.  As it stands, what we have to offer
> are analogous to best practices for using saws and hammers and
> such - not best practices for determining floor loadings, appropriate
> beam strengths, safe fire evacuation routes.
> 
> Every little bit helps, but a look at history shows us just how
> little we really have to offer as yet.

Well said, and quite right. A few pointers though.

A bridge is a single-purpose device. A watch is a simple purpose computer,
as was the Enigma machine, if we can call it such.

Multi-purpose computers or programmable computers are where our problems
start. Anyone can DO and create. One simply has to sit in front of a
keyboard and screen and make it happen..

As such, even if built well, the computer is programmable, and thus at
risk.

Gadi.

> -- Jerry
> 
> 
> ___
> Secure Coding mailing list (SC-L)
> SC-L@securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Leichter, Jerry]

Much as I agree with many of the sentiments expressed in this discussion,
there's a certain air of unreality to it.  While software has it's own
set of problems, it's not the first engineered artifact with security
implications in the history of the world.  Bridges and buildings
regularly collapsed.  (In the Egyptian desert, you can still see a
pyramid that was built too aggressively - every designer wanted to
build higher and steeper than his predecessor - and collapsed before
it was finished.)  Steam boilers exploded.  Steel linings on wooden
railroad tracks stripped of, flew through the floors of passing cars,
and killed people.  Electrical systems regularly caused fires.

How do we keep such traditional artifacts safe?  It's not by writing
introductory texts with details of safety margins, how to analyze the
strength of materials, how to include a crowbar in a power supply.
What you *may* get in an introductory course is the notion that there
are standards, that when it comes time for you to actually design
stuff you'll have to know and follow them, and that if you don't you're
likely to end up at best unemployed and possibly in jail when your
"creativity" kills someone.

In software, we have only the beginnings of such standards.  We
teach and encourage an attitude in which every last bit of the
software is a valid place to exercise your creativity, for better
or (for most people, most of the time) worse.  With no established
standards, we have no way to push back on managers and marketing
guys and such who insist that something must be shipped by the
end of the week, handle 100 clients at a time, have no more tha
1 second response time, and run on some old 486 with 2 MB of memory.

I don't want to get into the morass of licensing.  It's a fact that
licensing is heavily intertwined with standard-setting in many
older fields, but not in all of them, and there's no obvious inherent
reason why it has to be.

The efforts to write down "best practices" at CERT are very important,
but also very preliminary.  As it stands, what we have to offer
are analogous to best practices for using saws and hammers and
such - not best practices for determining floor loadings, appropriate
beam strengths, safe fire evacuation routes.

Every little bit helps, but a look at history shows us just how
little we really have to offer as yet.
-- Jerry



___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Gunnar Peterson]

> Seeking perfect correctness as an approach to security is a fool's
> errand. Security is designing systems that can tolerate imperfect software.
> 

Exactly. On "Curb Your Enthusiasm" this happened recently. Larry David was
frantically looking for a DVD case, but could not find it.

LD: "I don't know what happened. I have a system. I put the DVD in the
player, and I put the case on top of the player. But now it is gone."

Friend: "That's not a system. A system is - you buy a bunch of empty DVD
cases and put them next to the player."

-gp


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Gadi Evron]

On Sun, 29 Oct 2006, Robert C. Seacord wrote:
> Gadi,
> 
> I feel like I've been here before, but I'll give it another shot anyway.
> 
> > Okay, than let's make some progress:
> > 1. Where and who is currently involved with doing this?
> > 2. What are they doing?
> > 3. Can we use their experience to make it a larger success?
> > 4. How do we begin doing something large-scale?
> 
> The Secure Coding Initiative at CERT has a web site at
> www.securecoding.cert.org.  The purpose of this site is to collect
> secure coding recommendations and rules for various programming
> languages.  Our initial focus has been C and C++, but we are willing and
> interested in expanding this effort to other programming languages
> provided that we can find someone to manage the efforts.
> 
> The C and C++ material on the site will be used as supplemental material
> to the Addison-Wesley book "Secure Coding in C and C++" in a "Secure
> Programming" course I am teaching this Spring at CMU (so it is being
> used to teach, as well as being a commercial and government resource).
> I am also working with other instructors at other educational
> institutions to develop secure coding curriculum.

We misunderstand each other. I am not speaking of a secure coding book, I
am speaking of "Introduction to Computer Science" and "The C programming
Language".

If we can use what you have already worked on to supplament these courses,
then all for the better!

> 
> We have had significant community effort in the development of these
> secure coding standard practices so far, but we can use all the help we
> can get.  If you would like to get involved, go the sight, sign up, and
> start reviewing the material.  If you are qualified and would like to
> edit the material directly, send me email and I will grant you edit
> permissions.

I doubt I am that much of a good coder anymore.

> 
> I think having a body of knowledge that identifies insecure coding
> practices and provides secure alternatives is a good first start, and
> not as easy as it sounds.

Agreed!
Nice work on all that!

> 
> -
> 
> I also had another thought about improving the quality of code examples
> in texts.  I know my publisher (Addison-Wesley), and I'm sure others,
> are very concerned about quality.  I could ask my editor if they would
> be willing to make sure that someone with a security background reviewed
> any new programming texts.  If we can come up with a list of subject
> matter experts willing to review new texts, I'm guessing they would be
> very happy to have our feedback.

That sounds like a very good idea! I am sure many would agree to get some
extra cash for reviewing, thing is, that doesn't pay very well.

> 
> rCs
> 
> 

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Robert C. Seacord]

Gadi,

I feel like I've been here before, but I'll give it another shot anyway.

> Okay, than let's make some progress:
> 1. Where and who is currently involved with doing this?
> 2. What are they doing?
> 3. Can we use their experience to make it a larger success?
> 4. How do we begin doing something large-scale?

The Secure Coding Initiative at CERT has a web site at
www.securecoding.cert.org.  The purpose of this site is to collect
secure coding recommendations and rules for various programming
languages.  Our initial focus has been C and C++, but we are willing and
interested in expanding this effort to other programming languages
provided that we can find someone to manage the efforts.

The C and C++ material on the site will be used as supplemental material
to the Addison-Wesley book "Secure Coding in C and C++" in a "Secure
Programming" course I am teaching this Spring at CMU (so it is being
used to teach, as well as being a commercial and government resource).
I am also working with other instructors at other educational
institutions to develop secure coding curriculum.

We have had significant community effort in the development of these
secure coding standard practices so far, but we can use all the help we
can get.  If you would like to get involved, go the sight, sign up, and
start reviewing the material.  If you are qualified and would like to
edit the material directly, send me email and I will grant you edit
permissions.

I think having a body of knowledge that identifies insecure coding
practices and provides secure alternatives is a good first start, and
not as easy as it sounds.

-

I also had another thought about improving the quality of code examples
in texts.  I know my publisher (Addison-Wesley), and I'm sure others,
are very concerned about quality.  I could ask my editor if they would
be willing to make sure that someone with a security background reviewed
any new programming texts.  If we can come up with a list of subject
matter experts willing to review new texts, I'm guessing they would be
very happy to have our feedback.

rCs


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Gadi Evron]

On Sat, 28 Oct 2006, Crispin Cowan wrote:
> Gadi Evron wrote:
> > So, "dump C", "Use SML", "What secure coding classes are you doing?" and
> > "we are already doing it!!" are the responses I got when I started this
> > thread.
> >   
> What did you expect from whining about the generally poor quality of
> software? :)
> 
> > Can someone mention again why re-writing the main often-used and probably
> > less than 3 mostly-used basic programming books is a bad idea?
> >   
> Uh ... 'cause I question the assertion that there are 3 mostly-used
> basic programming books. I suspect it is more like 78 mostly used books.
> More importantly, if there are 3 mostly used books, then there are 78
> more behind them vying for those 3 slots, and they all have the same
> problems. If you write a new book, then you just join the pool of 78,
> and you have the impact of a drop in the bucket.
> 
> Worse, we are talking about correctness here. Correctness is hard, and
> correctness on a large scale is harder. I doubt that even a concerted
> effort at a "correct" book on intro to programming would manage to
> actually be correct any time before the 3rd edition, 10 years from now.
> 
> Seeking perfect correctness as an approach to security is a fool's
> errand. Security is designing systems that can tolerate imperfect software.

For argument sake, let's assume there are 100.

How about campaigning for a secure coding chapter to be added to these
semester, erm, world-wide?

Nothing is ever easy, but we have to start somewhere. I don't see why this
is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact.

Gadi.

> 
> Crispin
> 
> -- 
> Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
>  Hack: adroit engineering solution to an unanticipated problem
>  Hacker: one who is adroit at pounding round pegs into square holes
> 

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Gadi Evron]

On Sat, 28 Oct 2006, Crispin Cowan wrote:
> Gadi Evron wrote:
> > Nothing is ever easy, but we have to start somewhere. I don't see why this
> > is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact.
> >   
> It is not a bad idea. But it clearly is not sufficient. Why are you

Now we're talking.

Not sufficient I am game with. Nothing ever is, it is one more thing to
do.

> assuming that it is not already being tried? The problem is that
it is

I am assuming most higher education institutions in the world do not have
it done.

> being tried with the usual degree of effectiveness, i.e. unevenly.
> Saying "lets try it" is redundant, because that is already going on,
> just not enough. To make it more, one would have to convince the people
> who are currently not doing it, or doing it badly, to do better, and
> they (by definition) are not listening.

Okay, than let's make some progress:
1. Where and who is currently involved with doing this?
2. What are they doing?
3. Can we use their experience to make it a larger success?
4. How do we begin doing something large-scale?

Gadi.

> 
> Crispin
> 
> -- 
> Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
>  Hack: adroit engineering solution to an unanticipated problem
>  Hacker: one who is adroit at pounding round pegs into square holes
> 

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Crispin Cowan]

Robert C. Seacord wrote:
>> Seeking perfect correctness as an approach to security is a fool's
>> errand. Security is designing systems that can tolerate imperfect software.
>> 
> I could go along with "achieving perfect correctness as an approach to
> security is a fool's belief" but I believe the desire to achieve
> correctness is a prerequisite for security.
>
> More specifically, I have found that systematic schemes for providing
> software security (such as memory protection, canaries, etc.) are
> generally ineffective once a coding error (such as a buffer overflow)
> allows an attacker to penetrate the peripheral defense of code
> correctness.  Given the current state of software security, I don't
> think any security "best" practice can abandoned and that
> defense-in-depth is a practical necessity.
>   
I don't think we disagree. When I said that seeking correctness is a
fool's errand, I meant (more precisely) that *depending on achieving*
correctness is a fool's errand. You must always assume the presence of
imperfect software, and then design in defense in depth to tolerate
that. Using other software engineering techniques (secure coding, the
occasional topic of this mailing list :) certainly helps, but cannot be
the whole approach to security.

> Also, back on the book topic, I recently heard of an older but
> successful book that did nothing but take examples from other books and
> show in detail how they were incorrect.  Perhaps such a "supplemental"
> text could be developed for commonly used text books.
>   
I like it! Bugtraq for books :) My engineers are quite fond of The
*Daily WTF*  a web site that lampoons bad code.

Crispin
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Crispin Cowan]

Gadi Evron wrote:
> For argument sake, let's assume there are 100.
>
> How about campaigning for a secure coding chapter to be added to these
> semester, erm, world-wide?
>
> Nothing is ever easy, but we have to start somewhere. I don't see why this
> is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact.
>   
It is not a bad idea. But it clearly is not sufficient. Why are you
assuming that it is not already being tried? The problem is that it is
being tried with the usual degree of effectiveness, i.e. unevenly.
Saying "lets try it" is redundant, because that is already going on,
just not enough. To make it more, one would have to convince the people
who are currently not doing it, or doing it badly, to do better, and
they (by definition) are not listening.

Crispin

-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
 Hack: adroit engineering solution to an unanticipated problem
 Hacker: one who is adroit at pounding round pegs into square holes

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Robert C. Seacord]

Crispin,

I think you may have over spoken below:

> Seeking perfect correctness as an approach to security is a fool's
> errand. Security is designing systems that can tolerate imperfect software.

I could go along with "achieving perfect correctness as an approach to
security is a fool's belief" but I believe the desire to achieve
correctness is a prerequisite for security.

More specifically, I have found that systematic schemes for providing
software security (such as memory protection, canaries, etc.) are
generally ineffective once a coding error (such as a buffer overflow)
allows an attacker to penetrate the peripheral defense of code
correctness.  Given the current state of software security, I don't
think any security "best" practice can abandoned and that
defense-in-depth is a practical necessity.

Also, back on the book topic, I recently heard of an older but
successful book that did nothing but take examples from other books and
show in detail how they were incorrect.  Perhaps such a "supplemental"
text could be developed for commonly used text books.

rCs

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Crispin Cowan]

Gadi Evron wrote:
> So, "dump C", "Use SML", "What secure coding classes are you doing?" and
> "we are already doing it!!" are the responses I got when I started this
> thread.
>   
What did you expect from whining about the generally poor quality of
software? :)

> Can someone mention again why re-writing the main often-used and probably
> less than 3 mostly-used basic programming books is a bad idea?
>   
Uh ... 'cause I question the assertion that there are 3 mostly-used
basic programming books. I suspect it is more like 78 mostly used books.
More importantly, if there are 3 mostly used books, then there are 78
more behind them vying for those 3 slots, and they all have the same
problems. If you write a new book, then you just join the pool of 78,
and you have the impact of a drop in the bucket.

Worse, we are talking about correctness here. Correctness is hard, and
correctness on a large scale is harder. I doubt that even a concerted
effort at a "correct" book on intro to programming would manage to
actually be correct any time before the 3rd edition, 10 years from now.

Seeking perfect correctness as an approach to security is a fool's
errand. Security is designing systems that can tolerate imperfect software.

Crispin

-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
 Hack: adroit engineering solution to an unanticipated problem
 Hacker: one who is adroit at pounding round pegs into square holes

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] re-writing college books - erm.. ahm...

[Gadi Evron]

On Tue, 24 Oct 2006, Crispin Cowan wrote:
> Sure, there are likely to be ways in which SML is better than C# or
> Java. However, in security, the perfect is all to often the enemy of the
> good-enough. The big community hears security people talk about the high
> security approach that security geeks really want, consider the costs,
> and go back to doing things the old way, and ignore the security people.
> If security people instead pitch something that is feasible and makes
> the situation better, instead of asking for the moon, we will make more
> progress.
> 
> Crispin

(not directed at you, Crispin)

So, "dump C", "Use SML", "What secure coding classes are you doing?" and
"we are already doing it!!" are the responses I got when I started this
thread.

Can someone mention again why re-writing the main often-used and probably
less than 3 mostly-used basic programming books is a bad idea?

All of us will still have a job in 5 years if we do this, even in 25. I
promise.

Gadi.

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php