Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Fernando Schapachnik]

En un mensaje anterior, Blue Boar escribió:
 Fernando Schapachnik wrote:
 I smell a discusion going nowhere. What is the point of teaching a 
 languague?
 Teach them to program in a paradigm (better, in all of them, and give them 
 the
 tools to make educated choices about which is better for each context), and
 choose any language as an *example* of the paradigm.
 
 Ah... but beyond design problems, aren't most security problems 
 language-specific abuses and bugs?  I'm thinking things like I didn't 
 realize it would let me mix signed and unsigned... I didn't realize it 
 would let me right off the end of the buffer... I didn't realize I had 
 to escape or filter certain characters

Same thing happens with concurrency. You need to tell them about shared
variables, mutexes, locking, atomicity, protected sections, etc. When they are
going to undertake a real project in a specific language they need to know how
these are implemented there. I expect them to be able to learn that from the
multiple available resources, once the foundations are learn.

Now s/concurrency/security/. Imagine next year, when language NEW appears
and some people from this list are required to work in it. I suspect most
of them would probably apply their existing knowledge and some searching around
to understand the new thread model, and act acordindgly. Is the same scenario
for students.

Regards.

Fernando.

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Peter Amey]

 -Original Message-
 From: Crispin Cowan [mailto:[EMAIL PROTECTED]
 Sent: 09 July 2004 04:27
 To: Peter Amey
 Cc: ljknews; [EMAIL PROTECTED]
 Subject: Re: [SC-L] Education and security -- another perspective (was
 ACM Queue - Content)
 
 
 Peter Amey wrote:
 
 What is wrong with this picture ?
 
 I see both of you willing to mandate the teaching of C and yet not
 mandate the teaching of any of Ada, Pascal, PL/I etc.
   
 
 Makes sense to me. what is the point of teaching dead 
 languages like 
 Ada, Pascal, and PL/I?  Teach C, Assembler, and Java/C# (for the 
 mainstream), and some lisp variant (Scheme, ML, Haskell) and Prolog 
 variant for variety. But Ada, Pascal, and PL/I are suitable 
 only for a history of programming languages course :)
 
 
 I do hope that is a sort of smiley at the end of your 
 message.  Please.
   
 
 It is a sort-of smiley. On one hand, I find the whole thing 
 amusing. On 
 the other hand, I find it patently absurd that someone would suggest 
 that curriculum in 2004 would comprise Ada, Pascal, and PL/I, all of 
 which are (for industrial purposes) dead languages.
 
 On one hand, university should be about learning concepts rather than 
 languages, because the concepts endure while the languages go 
 in and out 
 of fashion. 

[snip]

I would have to (at least partly) diagree on two counts.  

Firstly a tactical one: Ada is by no means a dead language.  There is a great tendency 
in our industry to regard whatever is in first place at any particular point in life's 
race to be the winner and everything else to be dead.  In practice very 
substantial use may continue to be made of things which are not in the ultra-visible 
first place.  For example, OS/2 was killed by Windows yet most ATMs in the USA still 
run OS/2.  We have't discussed the dead languages Cobol and Prolog but both are 
actually still in widespread use, the latter in the specific niches for which it is 
suitable.  Ada is actually still doing rather well in areas where high reliability is 
valued more than fashion (the Ada side of my business is growing steadily and has been 
for years).  Since we are concerned on this list with improving the security (a form 
of reliability) of systems, study of a language which has a proven track record in 
delivering relibaility is wholly appropriate.

Secondly, in response to your suggestion that we teach concepts (which I wholly agree 
with), languages, including dead ones, encapsulate and illustrate concepts.  Pascal 
was designed to teach structured programming.  Occam provides a splendid introduction 
to concurrency.  Modula-2 and Ada are ideal for illustrating the vital concepts of 
abstraction, encapsulation and the separation of specification and implementation.  
The languages are worth studying for these reasons alone.  Those exposed to them will 
be better programmers in any language and will find adoption of new ones much easier.  

As you say, languages come in and out of fashion; what I find sad is that so many of 
the new languages have failed to learn and build on the lessons of those that have 
gone before.  I think it highly probable that this is because their designers have 
casually dismissed those that went before as dead and therefore of no interest.  They 
would have done better to emulate Newton and stood on the shoulders of giants such 
as Wirth.

I would never recruit someone just because they knew Ada rather than C; however, I 
would be highly unlikely to recruit someone who had such a closed mind that they 
thought Ada had nothing to teach them and was only fit for snide mockery.


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] Education and security -- another perspective (was ACM Queue - Content)

[Crispin Cowan]

Peter Amey wrote:
What is wrong with this picture ?
I see both of you willing to mandate the teaching of C and yet not
mandate the teaching of any of Ada, Pascal, PL/I etc.
 

Makes sense to me. what is the point of teaching dead languages like 
Ada, Pascal, and PL/I?  Teach C, Assembler, and Java/C# (for the 
mainstream), and some lisp variant (Scheme, ML, Haskell) and Prolog 
variant for variety. But Ada, Pascal, and PL/I are suitable 
only for a history of programming languages course :)
   

I do hope that is a sort of smiley at the end of your message.  Please.
 

It is a sort-of smiley. On one hand, I find the whole thing amusing. On 
the other hand, I find it patently absurd that someone would suggest 
that curriculum in 2004 would comprise Ada, Pascal, and PL/I, all of 
which are (for industrial purposes) dead languages.

On one hand, university should be about learning concepts rather than 
languages, because the concepts endure while the languages go in and out 
of fashion. Evidence: 20 years ago, when I was in college, Ada, Pascal, 
and PL/I only included one dead language :)  On the other hand, the 
students do need to get a job when they graduate, and we do them a 
disservice to not at least teach concepts using a language currently in 
use in industry.

There is also room for a lot of breadth in a college program. I was only 
overtly instructed in languages a few times, the rest were read the 
book then do this assignment. But in that approach, I learned COBOL, 
Pascal, PL/M, 68000 assembler, C, C++, FORTRAN, VAX assembler, Prolog, 
LISP, and Maple.  Its not like this list needs to be short.

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Crispin Cowan]

Peter Amey wrote:
Firstly a tactical one: Ada is by no means a dead language.  There is a great tendency in our industry to 
regard whatever is in first place at any particular point in life's race to be the winner and 
everything else to be dead.
Ada was pushed hard enough by the DoD for a decade that it is to be 
expected that there is a lot of Ada code to be maintained. I'm also 
willing to believe that your business in Ada may be growing, but that is 
likely because others are exiting the business and leaving the 
remainders for you; I do not believe (unless you have evidence to the 
contrary) in significant growth in new project starts in Ada.

I focus on new project starts because that is the only case in which 
language selection is even an interesting question. For any kind of 
on-going work, using the same language that the project was started in 
is the obvious choice most of the time.

 In practice very substantial use may continue to be made of things which are not in 
the ultra-visible first place.  For example, OS/2 was killed by Windows yet most ATMs 
in the USA still run OS/2.
But no new OS2 ATMs are being built, and they are being phased out.
 We have't discussed the dead languages Cobol and Prolog but both are actually still 
in widespread use,
COBOL: same reason, legacy systems, and LOTS of them.
Prolog: not so sure. Prolog may still be a language of choice for expert 
systems projects. But I don't work in that field. I do have a completely 
un-used Prolog text book left over from grad school if someone wants to 
buy it :)

Secondly, in response to your suggestion that we teach concepts (which I wholly agree with), languages, including dead ones, encapsulate and illustrate concepts.  Pascal was designed to teach structured programming.  Occam provides a splendid introduction to concurrency.  Modula-2 and Ada are ideal for illustrating the vital concepts of abstraction, encapsulation and the separation of specification and implementation.  The languages are worth studying for these reasons alone.  Those exposed to them will be better programmers in any language and will find adoption of new ones much easier.  
 

In programming language terms, Ada is grossly primitive. Its object 
orientation mechanisms are crude at best. A *great* deal of progress in 
language technology has been made since Ada was developed. For just 
about any kind of concept or safety feature, students and developers 
would be better served to consider Java, C#, or ML instead of Ada.

As you say, languages come in and out of fashion; what I find sad is that so many of the new languages have failed to learn and build on the lessons of those that have gone before.  I think it highly probable that this is because their designers have casually dismissed those that went before as dead and therefore of no interest.  They would have done better to emulate Newton and stood on the shoulders of giants such as Wirth.
 

And that is what I meant by history of programming languages. Java, 
C#, and ML are strictly better than Pascal and Ada for almost 
everything. But they did not spring out of the earth, they were built on 
the progress of previous languages. Java in particular contains no novel 
features at all, but rather shows good taste in the features it borrows 
from others. What made Java interesting was the accident of history that 
caused it to become the first strongly typed polymorphic programming 
language to become widely popular.

You *can* teach object orientation with Simula 67 or SmallTalk, if you 
really want to. But teaching object orientation with Java is a lot more 
approachable in the contemporary context.

I would never recruit someone just because they knew Ada rather than C; however, I would be highly unlikely to recruit someone who had such a closed mind that they thought Ada had nothing to teach them and was only fit for snide mockery.
 

I don't mock Ada for what it is: a fairly good programming language from 
the 1970s, with obvious scars from having been designed by committee 
(too big, too many features). Ada's defects are artifacts of its age and 
its history, not of poor design.

I do mock the suggestion that a large, complex, and retrograde language 
with no industrial growth is a suitable subject for undergraduate education.

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[David Crocker]

Crispin Cowan wrote:


In programming language terms, Ada is grossly primitive. Its object
orientation mechanisms are crude at best. A *great* deal of progress in
language technology has been made since Ada was developed. For just
about any kind of concept or safety feature, students and developers
would be better served to consider Java, C#, or ML instead of Ada.


I'm no fan of Ada (I find the language cumbersome and verbose, and it makes a
pigs ear of trying to be fully O-O) - but I have to defend Peter Amey in this
case.

There is a tendency to regard every programming problem as an O-O problem.
Sometime last year I read a thread on some programming newsgroup in which
contributors argued about the correct way to write a truly O-O Hello world
program. All the solutions provided were cumbersome compared to the traditional
printf(Hello, world!) solution. The point is, printing Hello, world! is
not an O-O problem!

Although for most commercial application packages an O-O architecture is the
best choice at present, for many embedded systems there is absolutely no reason
to use polymorphism with dynamic binding - which are the main language features
that distinguish the O-O approach from earlier methods. Ada has always provided
the other benefits associated with O-O languages (encapsulation, information
hiding, genericity). In safety-critical work there is a good case for regarding
dynamic binding as dangerous unless you formally prove it to be safe using
rigorous methods. And much as I dislike Ada, I have to admit that if you don't
intend to use dynamic binding and don't need the low-level features of C, Ada is
one of the safest languages around.

BTW there is probably more embedded programming being done using C rather than
anything more modern. Java is ruled out for most real-time embedded applications
because garbage collection pauses cannot be tolerated. [My own preference for
embedded work is MISRA C extended with a few features from C++ - but it needs
good tool support in order to ensure that all the worst unsafe features of C/C++
are avoided.]


Java, C#, and ML are strictly better than Pascal and Ada for almost
everything. But they did not spring out of the earth, they were built on
the progress of previous languages. Java in particular contains no novel
features at all, but rather shows good taste in the features it borrows
from others. What made Java interesting was the accident of history that
caused it to become the first strongly typed polymorphic programming
language to become widely popular.


I disagree with your almost everything because there is a huge amount of
embedded software developed for which Java is unsuitable. Java is certainly a
big improvement on C++ for anyone not needing the low-level control that C++ can
give, but unfortunately the designers of Java still borrowed too much from
C/C++. In particular, mixing automatic type conversion with overloading is a
_very_ bad idea. Indeed, for safety-critical work, almost any sort of automatic
type conversion is a very bad idea. The depressing thing about Java is that it
contains almost nothing new. In contrast, the designers of Eiffel added language
features designed to make producing correct programs easier.


You *can* teach object orientation with Simula 67 or SmallTalk, if you
really want to. But teaching object orientation with Java is a lot more
approachable in the contemporary context.


I certainly wouldn't advocate teaching Simula or Smalltalk. But focussing solely
on Java and O-O programming does not set students up well for embedded software
development.

David Crocker
Consultancy, contracting and tools for dependable software development
www.eschertech.com

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Wall, Kevin]

David Crocker wrote...

 There is a tendency to regard every programming problem as an
 O-O problem.  Sometime last year I read a thread on some
 programming newsgroup in which contributors argued about the
 correct way to write a truly O-O Hello world program. All
 the solutions provided were cumbersome compared to the traditional
 printf(Hello, world!) solution. The point is, printing
 Hello, world! is not an O-O problem!

Amen to that! I made similar remarks in the 'comp.compiler' and
'comp.object' USENET newsgroups as far back as 1991 (see for
example [URL probably will wrap] ...
http://groups.google.com/groups?hl=enlr=lang_enie=UTF-8newwindow=1safe=activethreadm=91-08-148%40comp.compilersrnum=1prev=/groups%3Fq%3Dcblph!kww%2Bgroup:comp.*%26hl%3Den%26lr%3Dlang_en%26ie%3DUTF-8%26newwindow%3D1%26safe%3Dactive%26selm%3D91-08-148%2540comp.compilers%26rnum%3D1)

I also muttered similar things within the Bell Labs community
much earlier than that during a time that C++ was first gaining momentum.

I'm of the belief that one should use the appropriate programming paradigm
that best fits the problem at hand. Contrary to how some may feel, I
strongly believe that does NOT mean that the best solution is always
an OO approach. Unfortunately, when all you have is a hammer...
[Note: In general, I'm a fan of OO--where and when appropriate.]

But this is getting way-off topic, so I'll cease my ranting.
(About time he shuts up! ;-)
-kevin
---
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

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[ljknews]

At 2:26 PM +0100 7/9/04, David Crocker wrote:

 And much as I dislike Ada, I have to admit that if you don't
 intend to use dynamic binding and don't need the low-level features of C,...

Which are those low-level features not available with Ada ?

The C compilers I have used claim to be ANSI-compliant but lack anything
equivalent to Ada's representation clauses.

-- 
Larry Kilgallen

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[der Mouse]

 I see both of you willing to mandate the teaching of C and yet not
 mandate the teaching of any of Ada, Pascal, PL/I etc.

 This seems like the teaching of making do.

And is not making do an important skill?

More seriously, as long as Unix variants maintain their position of
importance (something that shows no signs of going away), C will be an
important language for anyone outside academia to know - and many of
those inside academia.  As such, I would say that any program with so
much as pretensions to preparing people for the real world needs to
teach it to some extent.

Certainly not exclusively (I know I'm a better programmer for knowing
many languages).  Perhaps not even predominantly.  But as theoretically
ugly as it may be, it is still pragmatically critical.

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[James Walden]

ljknews wrote:
What is wrong with this picture ?
I see both of you willing to mandate the teaching of C and yet not
mandate the teaching of any of Ada, Pascal, PL/I etc.

This seems like the teaching of making do.
You read more into my post than I wrote, as I did not mandate that the students 
must learn C/C++.  They already know C/C++ by the time they take my course, but 
few have any exposure to the relevant security issues.  It's important that a 
security class cover security issues with the languages that the students have 
already used in their curriculum, unless that's already covered elsewhere.  How 
many people will change their programming language if they don't see what's 
wrong with the one they're currently using?

In summary, I teach the students the security issues (the powers and failures 
of C as Dana put it), not the language itself.  I do offer an overview of the 
features of more secure languages that students haven't used, but I don't have 
time to teach a new language in my security class, which isn't a pure software 
security class.

As for teaching students languages, we traditionally taught software 
engineering in Ada at my university, though we've moved to mostly Java or 
Python since the term project was required to be a web-based system. 
Introductory classes are taught using Java, in part because the AP test is 
Java-based, while computer architecture and assembly is taught using assembly, 
and operating systems is taught using C/C++.  Electives introduce other 
languages, of course.  I like ocaml myself, but its use is restricted to 
restricted to certain electives.

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

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Dana Epp]

What is wrong with this picture ?
I see both of you willing to mandate the teaching of C and yet not
mandate the teaching of any of Ada, Pascal, PL/I etc.
This seems like the teaching of making do.
Hmmm, interesting point. In a particular set of learning objectives 
required to complete a credential (ie: CompSci, CIS etc) what do you 
recommend we sacrifice to put in all this teaching?

I don't pick C for C's sake. I choose C because ON AVERAGE, most 
students will be exposed to C more than the languages you suggest. 
Especially in the majority on industries hiring students out of university.

However, that said, I don't think the language matters past exposure to 
the industry. A strong foundation of programming skills should be 
language agnostic; loops are loops, recursion is recursion, conditions 
are conditions etc. Learning the syntax of the language to accomplish it 
is secondary. Knowing how a loop breaks down into machine instructions 
is the goal here. Not how to do it in Ada.

Think about it in reflection of a linguist doing translation at the 
United Nations. They didn't simply go and learn every particular 
language. They are trained in understanding the mechanisms of human 
speech and formal grammar, and they then apply it to the language they 
are learning. In other words, they work from their foundation of 
learning in grammar and then apply the syntax of the particular language 
they are translating. It makes learning new languages much easier, and 
much faster.

So too should be programming. If a student has a strong foundation of 
learning when it comes to programming, they can adapt to different 
computer languages that they are exposed to as it comes to them. C is a 
perfect language to use to quickly get those concepts across in a 
practical environment in universities. And more importantly, from a 
secure coding objective, you can show what NOT to do.

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

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Peter Amey]

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
 Behalf Of Crispin Cowan
 Sent: 07 July 2004 23:29
 To: ljknews
 Cc: [EMAIL PROTECTED]
 Subject: Re: [SC-L] Education and security -- another perspective (was
 ACM Queue - Content)
 
 
 ljknews wrote:
 
 What is wrong with this picture ?
 
 I see both of you willing to mandate the teaching of C and yet not
 mandate the teaching of any of Ada, Pascal, PL/I etc.
   
 
 Makes sense to me. what is the point of teaching dead languages like 
 Ada, Pascal, and PL/I?  Teach C, Assembler, and Java/C# (for the 
 mainstream), and some lisp variant (Scheme, ML, Haskell) and Prolog 
 variant for variety. But Ada, Pascal, and PL/I are suitable 
 only for a 
 history of programming languages course :)
 

I do hope that is a sort of smiley at the end of your message.  Please.

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] Education and security -- another perspective (was ACM Queue - Content)

[Fernando Schapachnik]

En un mensaje anterior, ljknews escribió:
 At 1:56 PM -0700 7/7/04, Dana Epp wrote:
 
 I don't pick C for C's sake. I choose C because ON AVERAGE, most students will be 
 exposed to C more than the languages you suggest. Especially in the majority on 
 industries hiring students out of university.
 
 Primarily because that is what universities use for training.
 
 Originally because Unix was so cheap for educational institutions.
 
 I smell a vicious circle.

I smell a discusion going nowhere. What is the point of teaching a languague?
Teach them to program in a paradigm (better, in all of them, and give them the
tools to make educated choices about which is better for each context), and
choose any language as an *example* of the paradigm.

Latter on, they can pick the particularities of any language by a book.
Remember: don't give them fishes, teach them how to fish.

Having said that, giving a quick overview of C seems like a good idea when
teaching about security, because you can easily show examples of all types of
problems (I think is important, however, to make it clear that their represent a
class of problems, and can happen in many languages, not only in C).

Regards, Fernando.

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Peter Amey]

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
 Behalf Of der Mouse
 Sent: 08 July 2004 03:47
 To: [EMAIL PROTECTED]
 Subject: Re: [SC-L] Education and security -- another perspective (was
 ACM Queue - Content)
 
 
  I see both of you willing to mandate the teaching of C and yet not
  mandate the teaching of any of Ada, Pascal, PL/I etc.
 
  This seems like the teaching of making do.
 
 And is not making do an important skill?
 

Absolutely, making do is an important skill.  However, those being taught have to be 
told that they are making do and made properly aware of the alternatives.  In fact 
showing them the superiority of the alternatives should help them understand the 
limitations of C and why they need to know how to make do!

What is not acceptable is to deprive them of the knowledge of superior alternatives 
and leave them thinking that making do is the state of the art.

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] Education and security -- another perspective (was ACM Queue - Content)

[Blue Boar]

Jose Nazario wrote:
rather than talking in a vacuum, make sure you've read the latest
ACM/IEEE-CS curriculum guidelines:
http://www.acm.org/education/curricula.html
http://sites.computer.org/ccse/
Hrm.  I checked both pages, and searched for secur, and got nothing. 
I didn't click every link... security is mentioned briefly in a couple 
of places in the ACM strawman.

Was that your point?
BB

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Blue Boar]

Fernando Schapachnik wrote:
I smell a discusion going nowhere. What is the point of teaching a languague?
Teach them to program in a paradigm (better, in all of them, and give them the
tools to make educated choices about which is better for each context), and
choose any language as an *example* of the paradigm.
Ah... but beyond design problems, aren't most security problems 
language-specific abuses and bugs?  I'm thinking things like I didn't 
realize it would let me mix signed and unsigned... I didn't realize it 
would let me right off the end of the buffer... I didn't realize I had 
to escape or filter certain characters

BB

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[James Walden]

Dana Epp wrote:
I'd be interested to hear what people think of the two approaches 
(separate security courses vs. spreading security all over the curricula).

 Regards.

 Fernando.
I don't think it's an either/or question; we need both approaches.  Students 
should study security wherever it's relevant in the curriculum, but they also 
need a security class towards the end of the degree program to integrate what 
they've learned with a deeper and more theoretical look at security at the 
level of Matt Bishop's Computer Security: Art and Science.

Well, I have been asked to teach a new forth year course at the British 
Columbia Institute of Technology (BCIT) this fall on Secure Programming 
(COMP4476).
It looks like a good class, Dana.  My only suggestion would be to present 
secure design principles in unit 2, instead of waiting to bring them up until 
unit 7 (I'm presuming you'll bring up more than least privilege there.)  I 
think you're right to wait until later in the term to bring up buffer 
overflows; it's a more difficult problem for students than I expected it to be 
the first time I gave such an assignment.

I only wish I could make all these books be textbook requirements for 
the curriculum. It should be mandatory reading.
I think they're all good books, but covering fewer topics and books in greater 
depth increases learning, so don't succumb to that temptation.  You can't teach 
them everything in one term, but you can point the way to continue learning 
with those books for students who want to know about security than one class 
can teach them.

Of course, I also think students should have to take at least one course 
in ASM to really understand how computer instructions work, so they can 
gain a foundation of learning for the heart of computer processing. And
I think they should be taught the powers and failures of C. Since I know 
many of you think I'm nuts for that, you might want to look at this 
outline with the same amount of consideration.
I agree with you on both of those requirements.  You need to have a basic 
understanding of assembly and how C is translated into assembly to understand 
the most common types of buffer overflow attacks.  There are better languages 
for secure programming than C, but students are almost certainly going to have 
to read or write C at some point in their careers, so they need to understand it.

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

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[James Walden]

Crispin Cowan wrote:
Another perspective (overheard at a conference 12 years ago):
   * Scientists build stuff in order to learn stuff.
   * Engineers learn stuff in order to build stuff.
I think that's about as accurate a summary of the distinction as you can make 
in 16 words.  What makes it even more fuzzy in our case is that computer 
science does not fit in any one category, as it's a conglomerate of maths, 
science, and engineering.  That may be why some universities are moving from 
departments of computer or information science to schools of computer or 
information science.

... however, the programming skills that universities teach is usually a 
side-effect of something else they are teaching: topics like algorithms, 
graphics, database, operating systems, networking, etc. They teach you 
the topic, give you a development project in that topic, and expect you 
to pick up the programming skills along the way.

What is broken about all this is security: the above approach teaches 
the kiddies to implement software anyway they can, under a lot of time 
pressure, and with very little QA pressure: graders have no time to 
rigorously test assignment hand-ins, and certainly not time to pen-test 
them.
I agree that programming being taught as an afterthought is one of the major 
sources of the problem with security, and it's related to computer science 
being a conglomerate of disciplines.  CS today feels like we're studying 
natural philosophy in the days before biology, chemistry, and physics became 
their own disciplines.  It worked when computer science was a younger field, 
but there's so much to study today that we can't fit all of it into a four year 
curriculum.

There are only a few solutions to adding security to the curriculum in this 
sutation: 1) remove other material to add security in its place, 2) expand the 
number of required classes and thus time for a degree, or 3) specialize CS into 
multiple disciplines, at least one of which has room for security in its 
curriculum.  I think the third choice is the likely and best long term 
solution, and the first is the most workable short term solution.

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

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[ljknews]

At 9:40 AM -0400 7/7/04, James Walden wrote:
Dana Epp wrote:

 Of course, I also think students should have to take at least one course in ASM to 
 really understand how computer instructions work, so they can gain a foundation of 
 learning for the heart of computer processing. And
 I think they should be taught the powers and failures of C. Since I know many of 
 you think I'm nuts for that, you might want to look at this outline with the same 
 amount of consideration.

I agree with you on both of those requirements.  You need to have a basic 
understanding of assembly and how C is translated into assembly to understand the 
most common types of buffer overflow attacks.  There are better languages for secure 
programming than C, but students are almost certainly going to have to read or write 
C at some point in their careers, so they need to understand it.

What is wrong with this picture ?

I see both of you willing to mandate the teaching of C and yet not
mandate the teaching of any of Ada, Pascal, PL/I etc.

This seems like the teaching of making do.
-- 
Larry Kilgallen

RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Wall, Kevin]

Fernando Schapachnik wrote...

 I've considered 'secure coding' courses, and the idea always 
 look kind oversized. How much can you teach that students can't read 
 themselves from a book? Can you fill a semester with that? I'm
 interested in people's experiences here.

I suppose that depends largely on how you define secure coding
and how much depth you want to go into.

For the past 2 years I've taught a CS masters level course in
computer security. In addition to secure coding practices, I
also discuss:

* fundamental concepts of security (e.g., authentication,
  authorization, confidentiality, data integrity, nonrepudiation,
etc.);
* risk management and threat models;
* cryptographic foundations;
* authentication, access control, and auditing;
* common threats and vulnerabilities, and
* designing secure systems.

For the most part, because of time constraints and the fact that we are
trying to cover broader things then simply coding-related issues, the
secure coding practices are interspersed with the other topics, where
and when appropriate. (If you want more detail, you can find the
syllabus
at http://cs.franklin.edu/Syllabus/comp676/.)

 Adding a 'security chapter' to existing courses seems more 
 appropiate (at least to me). At the end of our Programming II
 course, I showcase students the vulnerabilities that can be
 understood or are related with what they've saw in
 class: these includes buffer overflows, input validation, integer
 over/underflows, race conditions, least priviledge, etc. I 
 stress that these are only samples, and point them to links
 (like David's great 'Secure Programming How-To') and books.
 I haven't had the chance to evaluate the impact of that, but
 it is on my to-do list.

I think that is a good approach, although I prefer mixing these
issues in where/when they might be more appropriate (e.g., discuss
security issues arising from race conditions when discussing
multi-threading, etc.) rather then saving them up for the end--if
only because there's a chance that they get crowded out if the
pace goes slower than expected.

 Similary, some other courses where security can be plugged 
 include operating systems, networking, SE, system's design, etc.

Indeed. At the same university, I taught the Distributed Operating
Systems masters level course. We used the Tannebaum / van Steen
text. The longest single chapter in the book was on security,
so the topic naturally fit in. (However, I know of other instructors
before me who simply skipped that chapter, thinking it wasn't as
important as the rest of the stuff.)

 I'd be interested to hear what people think of the two 
 approaches (separate security courses vs. spreading security
 all over the curricula).

I don't see it as either / or, but rather both / and. I think that
we sprinkle discussion of security, where appropriate, throughout
core courses (OS, networking, software design, etc.) and also have a
course or two at an upper (junior/senior) level. In that way, I
see it very similar to the way that we approach software design.
Generally there's a specific course or two on design, but we (hopefully)
teach it in bits and pieces at the beginning programming levels as well.
---
Kevin W. Wall   Qwest Information Technology, Inc.
[EMAIL PROTECTED]   Phone: 614.215.4788
The difference between common-sense and paranoia is that common-sense
 is thinking everyone is out to get you. That's normal -- they are.
 Paranoia is thinking that they're conspiring.-- J. Kegler

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Fernando Schapachnik]

En un mensaje anterior, der Mouse escribió:
  I think over the past 40 years or so, as a discipline, we've failed
  rather miserably at teaching programming, period.
  Right.  But on the other hand, that's not surprising - [because
  we've mostly not even _tried_ to teach programming, as opposed to
  computer science or software engineering].
  Care to explain what do you think a 'programming course' should have
  that is not covered in SE or CS courses (or curricula)?
 
 A computer scientist is a theoretician.  A software engineer is a
 designer.  A programmer is an implementer.
 
 A computer scientist can prove you can't, in general, sort faster than
 O(n log n) (and a good one can recast this as an explanatino of why).
 
 A software engineer can look at the application and decide which
 sorting algorithm is approproate for _this_ task, including, perhaps,
 choosing one with O(n^2) worst-case behaviour because of some
 application-specific property.
 
 A programmer can sit down and implement a sorting algorithm.

Well, my view is that a computer scientist is a scientist, which means he looks
into new/open problems. He'd better recall you can't sort faster than O(n log n)
based on comparisons, as a phisicist better recall general relativity laws, but
it can be a theoretician or an applied one (for example, designing new
programming languagues, etc). A software engineer applies stablished methods (if
shuch a thing exists today is left as an excercise to the reader) to tackle
problems. But that includes desigining, testing and programming. They are just
different parts of the software life cicle but all of them should be undertaken
as professional grade tasks.

So, in short, I think that programming is included in SE is included in CS.
Where A is included B means that any individual with an B degree should have
the knowledge necessary to successfully performs A's dutties (he might not have
the experience).

I don't agree with David Wheeler's statement that secure coding should be
taught instead of more basic things like sorting algorithms. Both are
important, but I believe that properly understading foundations is more
important that 'don't trust the input'. Of course there's more to security
than that, but that leads me to my main point. How should secure coding be
taught?

I've considered 'secure coding' courses, and the idea allways look kind
oversized. How much can you teach that students can't read themselves from a
book? Can you fill a semester with that? I'm interested in people's experiences
here.

Adding a 'security chapter' to existing courses seems more appropiate (at least
to me). At the end of our Programming II course, I showcase students the
vulnerabilities that can be understood or are related with what they've saw in
class: these includes buffer overflows, input validation, integer
over/underflows, race conditions, least priviledge, etc. I stress that these are
only samples, and point them to links (like David's great 'Secure Programming
How-To') and books. I haven't had the chance to evaluate the impact of that, but
it is on my to-do list.

Similary, some other courses where security can be plugged include operating
systems, networking, SE, system's design, etc.

I'd be interested to hear what people think of the two approaches (separate
security courses vs. spreading security all over the curricula).

Regards.

Fernando.

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Mark Rockman]

You are not nuts.  Your course outline  is a very substantial step in the
right direction.
- Original Message - 
From: Dana Epp [EMAIL PROTECTED]
To: Fernando Schapachnik [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 06, 2004 16:42
Subject: Re: [SC-L] Education and security -- another perspective (was ACM
Queue - Content)


  I'd be interested to hear what people think of the two approaches
(separate
  security courses vs. spreading security all over the curricula).
 
  Regards.
 
  Fernando.

 Well, I have been asked to teach a new forth year course at the British
 Columbia Institute of Technology (BCIT) this fall on Secure Programming
 (COMP4476). I have no problem sharing my course outline and breakdown,
 since a lot of this is adopted from experiences many other structured
 secure programming courses and literature are taking. The idea is that
 students need to build a strong foundation of learning that they can
 adopt in which ever discipline they follow in the future. This shouldn't
 be a first year course, but I think its a bit late being a fourth year
 course. You will note that the course I am teaching is somewhat language
 agnostic, and even platform agnostic to ensure that the foundation isn't
 tainted with 'fad-of-the-day' techniques, technologies and tools. (Hold
 that to Web applications, which the jury is still out on)

 Course Breakdown
 
 1. Essentials of Application Security
 * Types of attacks (hackers, DoS, Viruses, Trojans, Worms,
 organizational attacks etc)
 * Consequences of Poor Security (Data theft, lost productivity, damage
 reputation, loose consumer confidence, lost revenues)
 * Challenges when Implementing Security (Security vs Usability,
 Attackers vs Defenders, The misinformation about the security cost)

 2. Secure Application Development Practices
 * Implementing security at every stage of the development process
 * Designing clean error code paths, and fail securely
 * Planning on Failure through results checking
 * Code review

 3. Threat Modeling
 * Attack Trees
 * STRIDE Threat Modeling
 * DREAD risk analysis

 4. Using Security Technologies
 * Encryption
 * Hashing
 * Digital signatures
 * Digital certificates
 * Secure communications (Using IPSec/SSL)
 * Authentication
 * Authorization

 5. Detecting and fixing Memory and Arithmetic Issues
 * Buffer overflows
 * Heap overflows
 * Integer overflows

 6. Defending against Faulty Inputs and Tainted Data
 * User input validation techniques
 * Regular expressions
 * Parameter checking
 * Fault injection reflection

 7. Design, Develop and Deploy software through least privilege
 * Running in least privilege
 * Developing and debugging in least privilege
 * Providing secure defaults using the Pareto Principle
 * Applying native OS security contexts to processes and files (ACL,
 perms etc)

 8. Securing Web applications
 * C14N
 * SQL Injection
 * Cross-site scripting
 * Parameter checking

 As I complete the lesson plan this summer this outline will change. I
 think more study on understanding trusted and untrusted boundaries needs
 to be added, and some areas such as Threat Modeling will be flushed out
 with more detail. Overall though, you can get an idea of areas of
 education that I feel make up a core foundation of learning in secure
 programming. I wish I could take credit for this thinking, as its a
 strong foundation to build on. Alas I cannot; pick up any number of
 secure coding books and realize that this is all covered there in some
 degree:

 * Building Secure Code
 * Secure Coding Principles  Practices
 * Secure Programming Cookbook
 * Security Engineering
 * Building Secure Software

 I only wish I could make all these books be textbook requirements for
 the curriculum. It should be mandatory reading. Although you can teach
 some aspects in any course being provided, the reality is I think a
 dedicated course helps to build on the real foundation of learning. All
 other courses can re-enforce these teachings to further drive it home
 for the student.

 Of course, I also think students should have to take at least one course
 in ASM to really understand how computer instructions work, so they can
 gain a foundation of learning for the heart of computer processing. And
 I think they should be taught the powers and failures of C. Since I know
 many of you think I'm nuts for that, you might want to look at this
 outline with the same amount of consideration.

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

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Crispin Cowan]

der Mouse wrote:
Care to explain what do you think a 'programming course' should have
that is not covered in SE or CS courses (or curricula)?
   

A computer scientist is a theoretician.  A software engineer is a
designer.  A programmer is an implementer.
A computer scientist can prove you can't, in general, sort faster than
O(n log n) (and a good one can recast this as an explanatino of why).
 

That's an interesting distinction, but it doesn't really map to reality. 
There are lots of academic computer scientists who actually study 
implementation issues. Me, for instance :) We publish in security at 
USENIX Security, NDSS (Network and Distributed Systems Security, I am on 
the PC for 2005 
http://www.isoc.org/isoc/conferences/ndss/05/cfp.shtml), more broadly 
for systems at USENIX (plug: I am on the Freenix program committee for 
2005 http://www.usenix.org/events/usenix05/cfp/freenix.html), OSDI, 
SOSP, etc.

Even more broadly, people publishing stuff at SIGGRAPH are often doing 
at least as much with implementation as algorithms.

Another perspective (overheard at a conference 12 years ago):
   * Scientists build stuff in order to learn stuff.
   * Engineers learn stuff in order to build stuff.
So both classes learn stuff and build stuff, but for different motives. 
As a result, the output of scientists is often informative, but not so 
often useful, and the output from engineers is often useful, but not so 
often informative. To the contrary, it is rather poor work if a 
scientists work is not informative, and disastrous if an engineer's work 
is informative (e.g. the Tacoma Narrows bridge, or Microsoft Windows :)

There is a good deal of overlap, of course; it's rare to find anyone
who is wholly one of these without any bleedover from the others.  In
particular, any really good person in any of the three fields is going
to have a good deal of skill/knowledge from the other two mixed in.
 

Agreed.
What this means for acamdeia is less clear.  In particular, most CS and
SE programs actually include a good deal of programming, partly because
that's what many of the students actually want, partly for historical
reasons, and partly because you do need some familiarity with
programming to be a good CS or SE (just as you need some CS/SE to be a
good programmer).
 

... however, the programming skills that universities teach is usually a 
side-effect of something else they are teaching: topics like algorithms, 
graphics, database, operating systems, networking, etc. They teach you 
the topic, give you a development project in that topic, and expect you 
to pick up the programming skills along the way.

This effect is more pronounced the more advanced the school is. The 
thought is that programming is a relatively simple topic, so while a 
community college will spend most of their time teaching programming, a 
top-tier university will spend about 2 weeks teaching the frosh to 
program, and the rest of it they are supposed to gather while studying 
actual computer science.

What is broken about all this is security: the above approach teaches 
the kiddies to implement software anyway they can, under a lot of time 
pressure, and with very little QA pressure: graders have no time to 
rigorously test assignment hand-ins, and certainly not time to pen-test 
them.

Bringing us back to the root of this thread: we have been waiting 
forever for security to make it into the basic CS curricula. The rate of 
progress is not encouraging.

Thus, to really separate the programs, you'd have to pull the
programming out of the CS and SE curricula and put them in a
programming curriculum, perhaps with some new material added.  I'd
actually argue for going the other way, though, since the lines between
the areas are actually rather artificial, drawn not so much because
there really are boundaries there as because humans like to draw
boundaries around things.
 

For that to work, there would have to be programming content in 
curricula to pull out :)  OTOH, on reflection I tend to agree that 
unless how to program *safely* is a subject, that you cannot expect 
kids to infer it, and so successfully teaching security

What this has to do with _secure_ coding...well, nothing, directly.
But part of teaching programming really ought to be teaching the
security side of it, and whether you call it CS or SE or programming,
that's something I agree academia has mostly failed at.
Security for CS includes things like a bit of cryptography, some of the
mutant complexity theory that considers a problem that's O(1) 99% of
the time O(n^n) the other 1% easy rather than hard; security for SE
includes things like writing interface contracts that specify what
_isn't_ defined as well as what _is_; security for programmers includes
things like not overrunning buffers.  Again, there's a lot of overlap.
/~\ The ASCII   der Mouse
\ / Ribbon Campaign
X  Against HTML[EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D 

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[Fernando Schapachnik]

En un mensaje anterior, der Mouse escribió:
  In general, I don't think this is an issue that is unique to _secure_
  programming (coding, design, etc.).  I think over the past 40 years
  or so, as a discipline, we've failed rather miserably at teaching
  programming, period.
 
 Right.  But on the other hand, that's not surprising - when did you
 last see even a course, never mind a program, in academia that was
 _supposed_ to teach programming (as opposed to computer science or
 software engineering or any of the various other things usually taught
 instead of it)?

Care to explain what do you think a 'programming course' should have that is not
covered in SE or CS courses (or curricula)?

Regards.

Fernando.

Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

[der Mouse]

 I think over the past 40 years or so, as a discipline, we've failed
 rather miserably at teaching programming, period.
 Right.  But on the other hand, that's not surprising - [because
 we've mostly not even _tried_ to teach programming, as opposed to
 computer science or software engineering].
 Care to explain what do you think a 'programming course' should have
 that is not covered in SE or CS courses (or curricula)?

A computer scientist is a theoretician.  A software engineer is a
designer.  A programmer is an implementer.

A computer scientist can prove you can't, in general, sort faster than
O(n log n) (and a good one can recast this as an explanatino of why).

A software engineer can look at the application and decide which
sorting algorithm is approproate for _this_ task, including, perhaps,
choosing one with O(n^2) worst-case behaviour because of some
application-specific property.

A programmer can sit down and implement a sorting algorithm.

There is a good deal of overlap, of course; it's rare to find anyone
who is wholly one of these without any bleedover from the others.  In
particular, any really good person in any of the three fields is going
to have a good deal of skill/knowledge from the other two mixed in.

What this means for acamdeia is less clear.  In particular, most CS and
SE programs actually include a good deal of programming, partly because
that's what many of the students actually want, partly for historical
reasons, and partly because you do need some familiarity with
programming to be a good CS or SE (just as you need some CS/SE to be a
good programmer).

Thus, to really separate the programs, you'd have to pull the
programming out of the CS and SE curricula and put them in a
programming curriculum, perhaps with some new material added.  I'd
actually argue for going the other way, though, since the lines between
the areas are actually rather artificial, drawn not so much because
there really are boundaries there as because humans like to draw
boundaries around things.

What this has to do with _secure_ coding...well, nothing, directly.
But part of teaching programming really ought to be teaching the
security side of it, and whether you call it CS or SE or programming,
that's something I agree academia has mostly failed at.

Security for CS includes things like a bit of cryptography, some of the
mutant complexity theory that considers a problem that's O(1) 99% of
the time O(n^n) the other 1% easy rather than hard; security for SE
includes things like writing interface contracts that specify what
_isn't_ defined as well as what _is_; security for programmers includes
things like not overrunning buffers.  Again, there's a lot of overlap.

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B