RE: [SC-L] ACM Queue article and security education

2004-07-02 Thread Peter Amey


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
 Behalf Of Blue Boar
 Sent: 01 July 2004 21:03
 To: ljknews
 Cc: [EMAIL PROTECTED]
 Subject: Re: [SC-L] ACM Queue article and security education
 
 
 ljknews wrote:
  I think it will be properly considered when the most strict portion
  of the software world is using language X.   I have used many
  programs where the flaws in the program make it clear that 
 I care not
  one whit about whether the authors of that program have 
 opinion about
  anything I might use. They are simply not competent, either as
  individuals or else as an organization.
 
 By most strict portion, do you mean people that care most about 
 correct code, proofs, and such?  I don't deny that the bulk 
 of the heavy 
 lifting will be done by people well-qualified to do so.  
 However, I'm of 
 the school of thought that certain types of people who like to break 
 things, and whose chief skill is breaking things, will always have a 
 decent shot at finding a problem.  There are people who 
 couldn't build 
 it, but they can sure break it.
 
 You don't typically get their attention until something is really, 
 really popular.  So yes, you can write your stuff in Language X, and 
 assume it's secure.  It might not actually be until the whole 
 world has 
 had its way with Language X, but (hopefully) that's not a 
 problem.  You 
 can still do the dance of patching the last 5 problems in Language X, 
 and end up better off that if you'd just used C.
 
 Even Knuth has to write checks ocassionally, and he does a 
 lot of proof 
 work, doesn't he?
 
 So, if Language X only has 5 problems total, even if it takes 
 years to 
 ferret them out, butthey are fixable, please proceed with getting the 
 whole world to use Language X.
 

I'm not entirely sure I follow this.  I _think_ you are saying: since we can't be 
sure that X is perfect (because it might have 5 remaining flaws) then there is no 
point in adopting it.  You seem to be saying that it doesn't matter if X is 
_demonstrably_much_better_ than Y, if it is not perfect then don't change.  Have I got 
that right?

This is a variant on the Goedel gambit often used to attack formal verification.  It 
goes since Goedel's Theorem places strict limits on what we can formalize and prove, 
let's not bother at all and just do a few unit tests instead.  It also reminds me of 
what I call the asprin analogy: aspirin doesn't cure cancer so there's no point in 
taking it for headaches.

The reality is that demonstrable improvements in quality, safety and security can be 
achieved by using the right tools, languages and methods.  It is for those who choose 
_not_ to use the strongest engineering to justify their position not the other way 
round.


Peter


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.  The IT Department at Praxis Critical Systems can be contacted at 
[EMAIL PROTECTED]
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk





RE: [SC-L] ACM Queue article and security education

2004-07-02 Thread Peter Amey


 -Original Message-
 From: Blue Boar [mailto:[EMAIL PROTECTED]
 Sent: 01 July 2004 17:11
 To: Peter Amey
 Cc: [EMAIL PROTECTED]
 Subject: Re: [SC-L] ACM Queue article and security education
 
 
 Peter Amey wrote:
  There are languages which are more suitable for the construction of
  high-integrity systems and have been for years.  We could have
  adopted Modula-2 back in the 1980s, people could take the 
 blinkers of
  prejudice off and look properly at Ada.  Yet we continue to use
  C-derived languages with known weaknesses.
 
 So we trade the known problems for a set of unknown ones?  

[snip]

A mindset that would have kept us building aircraft in wood!

In any case, we _do_ adopt new languages and methods, frequently.  In the time I have 
been using SPARK I have had people say: that's neat, if only you could do it for X.  
Where X has been C, C++, Java and C# in that order and at about 5 year intervals.  
What we _don't_ do is make those choices based on any kind of objective assessment or 
engineering judgement.

[snip]

 Language X may very well be a much better starting point, I 
 don't know. 
   I do believe that it will never be properly looked at until 
 the whole 
 world starts using it for everything, though.

And how will the whole world start using it if everyone waits for everyone else?

In any case, I don't expect the whole world to adopt any one method (any more than I 
build bicycles in carbon fibre even though that is the material of choice for, say, 
racing cars).   What I do expect is that principled engineers, the kind of people who 
care enough about their profession to contribute to groups like this, will seek to use 
the best and most appropriate technology for their purposes.  


Peter


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.  The IT Department at Praxis Critical Systems can be contacted at 
[EMAIL PROTECTED]
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk





Re: [SC-L] ACM Queue article and security education

2004-07-02 Thread ljknews
At 1:02 PM -0700 7/1/04, Blue Boar wrote:
ljknews wrote:
 I think it will be properly considered when the most strict portion
 of the software world is using language X.   I have used many
 programs where the flaws in the program make it clear that I care not
 one whit about whether the authors of that program have opinion about
 anything I might use. They are simply not competent, either as
 individuals or else as an organization.

 By most strict portion, do you mean people that care most about correct
 code, proofs, and such?

And organizations that hire the people you describe below to test the
software they build.

 I don't deny that the bulk of the heavy lifting will be done by people
 well-qualified to do so.  However, I'm of the school of thought that
 certain types of people who like to break things, and whose chief skill
 is breaking things, will always have a decent shot at finding a problem.
 There are people who couldn't build it, but they can sure break it.

 You don't typically get their attention until something is really,
 really popular.

Lots of people bring their attention to issues they are paid to test.
-- 
Larry Kilgallen




Re: [SC-L] ACM Queue article and security education

2004-07-02 Thread Blue Boar
Peter Amey wrote:
I'm not entirely sure I follow this.  I _think_ you are saying:
since we can't be sure that X is perfect (because it might have 5
remaining flaws) then there is no point in adopting it.  You seem to
be saying that it doesn't matter if X is _demonstrably_much_better_
than Y, if it is not perfect then don't change.  Have I got that
right?
No.  I was claiming that languages that allow for safety and verifiction 
can't neccessarily be trusted 100%.  There will always be a last few 
bugs.  As I said in my note that you replied to, that doesn't 
neccessarily mean you don't use it.  The other part of my note had to do 
with the last few bugs not coming to light until *everyone* is using 
that language.  Also not a reason to not go ahead and use it now, since 
the sooner the world starts to switch, the sooner you kill the last few 
bugs.

I think you were reacting to the one sarcastic part of my note, which 
essentially says good luck getting the world to switch.

BB



RE: [SC-L] ACM Queue article and security education

2004-07-01 Thread Peter Amey


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
 Behalf Of Michael S Hines
 Sent: 30 June 2004 17:00
 To: [EMAIL PROTECTED]
 Subject: RE: [SC-L] ACM Queue article and security education
 
 
 If the state of the art in automobile design had progressed 
 as fast as the
 state of the art of secure programming - we'd all still be 
 driving Model
 T's.  
 
 Consider-
   - System Development Methods have not solved the (security) 
 problem -
 though we've certainly gone through lots of them.
   - Languages have not solved the (security) problem - though we've
 certainly gone through (and continue to go through) lots of them.
   - Module/Program/System testing has not solved the 
 (security) problem -
 though there has been a plethorea written about system 
 testing (both white
 box and black box).
 

I agree that we have not solved the problem by the above means but I think it should 
be said that this is due more to the refusal of our industry to make a serious attempt 
to use them than because they have used them and failed.  The reality is that most 
system development still uses ad hoc, informal approaches and inherently insecure and 
ambiguous implementation languages.  Testing cannot make up for these deficiencies 
because of fundamental limitations of coverage etc. see [1,2,3].

There are development approaches, such as the use of formal methods, which have a 
proven track record of success.  They are still being used successfully today.  Yet 
most of our industry is either unaware of them, regards formal methods as some 
academic failure from the 1970s or demands evidence (although they never seem to 
need evidence before adopting the latest fashionable fad).

There are languages which are more suitable for the construction of high-integrity 
systems and have been for years.  We could have adopted Modula-2 back in the 1980s, 
people could take the blinkers of prejudice off and look properly at Ada.  Yet we 
continue to use C-derived languages with known weaknesses.  All we hear are appeals to 
better training, tools to help find the stupidities the poor development approaches 
make inevitable and pious hopes that future developments in computer science will 
rescue us.  What we really need is to use the good stuff we already have.

Just to back this random polemic up a bit:  we have just delivered a secure system to 
an important customer which has been independently evaluated to a high level.  Zero 
defects were found.  It was cheaper than the system it replaces.  (Draconian NDAs 
limit what can be said to that unfortunately).  The system was formally specified in 
Z, coded in SPARK and proofs carried out to ensure that it was wholly free from 
run-time errors (and hence from attacks such as buffer overflow) and that essential 
security invariants are maintained.  None of this is bleeding edge technology.  Z has 
been around for ages, SPARK for 14 years.  



regards



Peter


1. Littlewood, Bev; and Strigini, Lorenzo: Validation of Ultrahigh Dependability for 
Software-
Based Systems. CACM 36(11): 69-80 (1993)
2. Butler, Ricky W.; and Finelli, George B.: The Infeasibility of Quantifying the 
Reliability of
Life-Critical Real-Time Software. IEEE Transactions on Software Engineering, vol. 19, 
no.
1, Jan. 1993, pp 3-12.
3. Littlewood, B: Limits to evaluation of software dependability. In Software 
Reliability and
Metrics (Proceedings of Seventh Annual CSR Conference, Garmisch-Partenkirchen). N.
Fenton and B. Littlewood. Eds. Elsevier, London, pp. 81-110.



**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.  The IT Department at Praxis Critical Systems can be contacted at 
[EMAIL PROTECTED]
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk





RE: [SC-L] ACM Queue article and security education

2004-07-01 Thread Michael S Hines
I can just see an OS go into a wait state now while the VM/.NET or whatever
does garbage collection; and the delays while the intermediate code is
turned into executable code by the loaders.   

Not!  

HLL have given us portability (witness - *nix) but at some price of
performance.  The HW development has outpaced SW development - to the tune
where we hardly notice the performance hit at all.  After all, now fast can
one person type (grin)?

It's always a trade off...   HW/SW.  

Mike Hines 
---
Michael S Hines
[EMAIL PROTECTED] 
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Blue Boar
Sent: Thursday, July 01, 2004 11:11 AM
To: Peter Amey
Cc: [EMAIL PROTECTED]
Subject: Re: [SC-L] ACM Queue article and security education

Peter Amey wrote:
 There are languages which are more suitable for the construction of
 high-integrity systems and have been for years.  We could have
 adopted Modula-2 back in the 1980s, people could take the blinkers of
 prejudice off and look properly at Ada.  Yet we continue to use
 C-derived languages with known weaknesses.

So we trade the known problems for a set of unknown ones?  It might be 
appropriate to do so; C may be broken enough that it's better to go 
for an unknown with a design that allows for a possible correct 
implementation.  I keep thinking of Java, for example.  It's a good 
paper design for security purposes (I'll leave functionality alone for 
now.)  But there are still all the issues with the VM implementation and 
libraries to deal with.

Language X may very well be a much better starting point, I don't know. 
  I do believe that it will never be properly looked at until the whole 
world starts using it for everything, though.

BB





Re: [SC-L] ACM Queue article and security education

2004-07-01 Thread ljknews
At 9:10 AM -0700 7/1/04, Blue Boar wrote:

Language X may very well be a much better starting point, I don't know.  I do believe 
that it will never be properly looked at until the whole world starts using it for 
everything, though.

I think it will be properly considered when the most strict portion of the
software world is using language X.   I have used many programs where the
flaws in the program make it clear that I care not one whit about whether
the authors of that program have opinion about anything I might use. They
are simply not competent, either as individuals or else as an organization.
-- 
Larry Kilgallen




Re: [SC-L] ACM Queue article and security education

2004-07-01 Thread Blue Boar
ljknews wrote:
I think it will be properly considered when the most strict portion
of the software world is using language X.   I have used many
programs where the flaws in the program make it clear that I care not
one whit about whether the authors of that program have opinion about
anything I might use. They are simply not competent, either as
individuals or else as an organization.
By most strict portion, do you mean people that care most about 
correct code, proofs, and such?  I don't deny that the bulk of the heavy 
lifting will be done by people well-qualified to do so.  However, I'm of 
the school of thought that certain types of people who like to break 
things, and whose chief skill is breaking things, will always have a 
decent shot at finding a problem.  There are people who couldn't build 
it, but they can sure break it.

You don't typically get their attention until something is really, 
really popular.  So yes, you can write your stuff in Language X, and 
assume it's secure.  It might not actually be until the whole world has 
had its way with Language X, but (hopefully) that's not a problem.  You 
can still do the dance of patching the last 5 problems in Language X, 
and end up better off that if you'd just used C.

Even Knuth has to write checks ocassionally, and he does a lot of proof 
work, doesn't he?

So, if Language X only has 5 problems total, even if it takes years to 
ferret them out, butthey are fixable, please proceed with getting the 
whole world to use Language X.

BB



Re: [SC-L] ACM Queue article and security education

2004-06-30 Thread ljknews
At 8:10 PM -0400 6/29/04, James Walden wrote:

While there are non-university classes and workshops that teach software security, I 
doubt that a majority of developers have attended even one such class.  Software 
security has to be integrated into the CS curriculum before we can expect a majority 
of developers to have the appropriate skills, and then there will still be the issue 
of applying them under deadline pressure.

That said, I agree with most of the article.  We can't wait for years to software 
security to become a standard part of the curriculum, and most of his suggestions, 
such as turning C compiler warnings into errors, are good ideas no matter what the 
current status of security education.  I also second his enthusiasm for perl's taint 
mode.

Teaching students how to avoid problems in C should be a separate (optional)
course.

Dealing with issues that have _not_ been solved in higher level languages
should be a required course not burdened by the baggage of C.

And whether something is a warning or an error is outside the scope
of the programming language itself and into the build process which would
allow completion in the face of warnings.


Re: [SC-L] ACM Queue article and security education

2004-06-30 Thread Peter G. Neumann
Gee, Some of us have been saying that for 40 years.




Re: [SC-L] ACM Queue article and security education

2004-06-30 Thread Kenneth R. van Wyk
James Walden wrote:
I'd like to open a discussion based on this quote from Marcus Ranum's 
ACM Queue article entitled Security: The root of the problem:
Thanks.  I also read Marcus's article with interest.  Caveat: clearly, I 
have a biased outlook, since software security training is one of the 
things that I do for a living.

Overall, I like and agree with much of what Marcus said in the article.  
I don't, however, believe that we can count on completely putting 
security below the radar for developers.  Having strong languages, 
compilers, and run-time environments that actively look out for and 
prevent common problems like buffer overruns are worthy goals, to be 
sure, but counting solely on them presumes that there are no security 
problems at the design, integration, or operations stages of the 
lifecycle.  Even if the run-time environment that Marcus advocates is 
_perfect_ in its protection, these other issues are still problematic 
and require the developers and operations staff to understand the problems.

From my perspective, security education is only beginning to climb an 
initial upward curve.  While classes in security topics are becoming 
more common in undergraduate computer science course catalogs, their 
presence is far from universal.  I don't know of any university that 
requires such a class for an undergraduate CS degree; if any such 
programs exist, they're not common.
I agree with you on this, certainly.  My nephew is a senior in an 
undergrad CS curriculum and his university has yet to discuss security 
in any of his course work, to my knowledge. 

While there are non-university classes and workshops that teach 
software security, I doubt that a majority of developers have attended 
even one such class.  Software security has to be integrated into the 
CS curriculum before we can expect a majority of developers to have 
the appropriate skills, and then there will still be the issue of 
applying them under deadline pressure.
Yup, but in the belt and suspenders approach that I like to advocate, 
I'd like to see software security in our undergrad curricula as well as 
professional training that helps developers understand the security 
touch points throughout the development process -- not just during the 
implementation phase.

Cheers,
Ken van Wyk
http://www.KRvW.com


Re: [SC-L] ACM Queue article and security education

2004-06-30 Thread James Walden
Kenneth R. van Wyk wrote:
Overall, I like and agree with much of what Marcus said in the article.  
I don't, however, believe that we can count on completely putting 
security below the radar for developers.  Having strong languages, 
compilers, and run-time environments that actively look out for and 
prevent common problems like buffer overruns are worthy goals, to be 
sure, but counting solely on them presumes that there are no security 
problems at the design, integration, or operations stages of the 
lifecycle.  Even if the run-time environment that Marcus advocates is 
_perfect_ in its protection, these other issues are still problematic 
and require the developers and operations staff to understand the problems.
I agree that you can't solve all security problems with development tools, but 
I think security tools are a worthwhile investment because deploying tools can 
be accomplished much more quickly than educating developers, tools can help 
experienced developers, and tools can raise awareness of software security 
issues.  The article's mention of people creating patches to eliminate compiler 
security warnings may indicate that I'm too optimistic about tools raising 
awareness, but I think that some developers will learn from their tools.

Yup, but in the belt and suspenders approach that I like to advocate, 
I'd like to see software security in our undergrad cirricula as well as 
professional training that helps developers understand the security 
touch points throughout the development process -- not just during the 
implementation phase.
I agree.  Students should see software security in all development phases 
relevant to each software course that they take; software engineering in 
particular should address security topics in all phases of the development 
process.  I think there's an additional need for a class focused purely on 
security to put all the elements of security together.

Peter G. Neumann wrote:
 Gee, Some of us have been saying that for 40 years.
I can't deny that even if I have only been reading your comp.risks digest for a 
little more than a third of that span, but I think the fact that today's 
security problems are directly and indirectly impacting large segments of the 
population has increased awareness of security problems, and, as a result, 
we're seeing a rise in security education.  Many of us like to think that 
computer science changes rapidly, and it does compared to older fields like 
physics, where you have to go to graduate school to study much that was 
developed after the 1930's, but I suspect most people in any field avoid change 
until it's forced upon them.

--
James Walden, Ph.D.
Visiting Assistant Professor of EECS
The University of Toledo @ LCCC
http://www.eecs.utoledo.edu/~jwalden/
[EMAIL PROTECTED]



RE: [SC-L] ACM Queue article and security education

2004-06-30 Thread Michael S Hines
If the state of the art in automobile design had progressed as fast as the
state of the art of secure programming - we'd all still be driving Model
T's.  

Consider-
  - System Development Methods have not solved the (security) problem -
though we've certainly gone through lots of them.
  - Languages have not solved the (security) problem - though we've
certainly gone through (and continue to go through) lots of them.
  - Module/Program/System testing has not solved the (security) problem -
though there has been a plethorea written about system testing (both white
box and black box).

And a question/comment/observation.
First the comment - As an IT Auditor we approach auditing in two stages -
first we look at general controls, and then application controls (won't go
into details here - there's information on this available elsewhere).  If
general controls are not in place, application controls are not relevant
(that is any application control can be circumvented due to weak general
controls). 
Then the question - Why do we not subject computer operating systems (which
are a general control) to the same level of testing that we subject
applications?   
And the observation - weaknesses in operting systems have been documented
(but not widely circulated) - yet we (as Sysadmins/users/auditors/security
experts - you pick) do not have a problem using faulty system software and
laying applications on top of them.  Why is that? 

And then a thought question - in message passing operating systems (those
that respond to external stimuli, or internal message queues) - if one can
inject messages into the processing queue, can't one in essence 'capture the
flag'?  Yet we see message passing systems as middleware (and OS core
technology in some cases) to facilitate cross platform interfaces.  Aren't
we introducing inherient security flaws in the process? 

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