Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Steven M. Christey]

On Tue, 25 Aug 2009, Benjamin Tomhave wrote:

> We should be seeking to innovate outside the box - change the rules of
> the game dramatically - rather than trying to work within the arbitrary
> constructs we've placed around ourselves.

Insert obligatory OWASP ESAPI praise here.  The Enterprise Security API
project is trying to build an API that makes it easier for application
developers to fold in security.  If you need crypto, use the crypto API.
If you need authentication, use the authentication API.

I think ESAPI (or similar APIs) have the potential to be game-changers.
One primary benefit is that programmers aren't trying to implement
security themselves.  One potential selling point to developers would be
saving time - rather than wasting days/weeks/months implementing your own
authentication scheme, use the API.  Obviously there are limitations in
its applicability, but it seems to be off to a great start.

http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

This kind of thing could be extended to non-web applications, or possibly
introduced to programmers fairly early in education.

Disclaimer: I've participated in the project here and there.

Another way to change the game (besides languages) is to define and adopt
more secure protocols.  Given how slow DNSSEC and IPv6 have been in terms
of adoption, and how rapidly AJAX has grown, I'm not too optimistic for
success in this area without serious customer demand.

Even requiring the use of non-proprietary, well-documented protocols and
data formats, with strict conformance by implementations, could go a long
way - because then you can develop extensive test suites against these
standards and use a whitelist-based approach of refusing anything that
does not conform.  Unfortunately, I'm not too optimistic in this regard,
either.

- Steve
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Brad Andrews]

I had proofs in junior high Geometry too, though I do not recall using  
them outside that class.  I went all the way through differential  
equations, matrix algebra and probability/statistics and I don't  
recall much focus on proofs.  This was in the early 1980s in a good  
school (Illinois), so it wasn't just modern teaching methods that were  
too blame.  I am not sure that the proofs were all that useful for  
understanding some things either, though the logic they taught has  
value that I missed a bit of since I did hit some modern techniques.


--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


Quoting Stephan Neuhaus :



On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote:


You don't teach proofs - not really. The elementary and junior high
curriculum generally does not contain anything about proofs


I was talking about college students because that's when I was properly
taught programming.  That may no longer be true.  But in maths, I *was*
taught how to do proper proofs in high school (from 7th grade on, when
we had Geometry). I may have been unusually lucky.


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Brad Andrews]

While part of me agrees with that in principle, I am not so sure in  
practice.  I have found many of the students I have struggle with just  
getting the basic structures down, not anything fancy.


The class is not taught at an elite university, but more "for the  
masses" though, but isn't that who really needs to be targeted?  While  
the elite definitely need to understand the importance of development  
security and how to do it, so do the masses.  The latter are going to  
be much harder to reach.


It is kind of like general computer user security.  The power users  
need to know the subject, but so do the occasional users.  Most  
programmers are not power users in the programming field,  
unfortunately or not.


--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


Quoting Stephan Neuhaus :


I maintain that when someone is intellectually mature
enough so that you can teach them how to program and at the same time
really know what they're doing, you can teach them about correctness
and security too.


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] Inherently Secure Code?

[Brad Andrews]

I am not sure I agree that this is any more achievable than claiming a  
bank building should allow all valid customers in, but keep out all  
thieves.  While we can and should make great strides, we will always  
have some exposure because we have to let some things through.  The  
only way we can have perfectly secure code is to not allow someone to  
use it.  The same is true of bug free code, but that is another  
argument.  :)


Isn't this kind of like wanting the "evil bit" to be set in all  
malicious packets?  Great idea, but not achievable.


--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


Quoting Benjamin Tomhave :


we are now trapped in a box of our own
making that has us squabbling over academic minutiae like how to teach
secure coding when we should not have to consider this topic at all -
the code itself should be inherently secure.

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Andy Murren]

Personally I think secure coding should be included in the entire
curriculum irrespective of the level. People learn habits early on
that they tend to carry for as long as they are programmers. How many
programmers that learned the K&R style of indentation for example
continue to use it as their default style even when they have learned
new languages.

Having just done a quick survey of the programming books on my shelves
I don't find security or secure coding covered much if at all. I doubt
that is because some business guy came down to the author and told him
to excise security from the book. If basic security and secure coding
practices are not integrated into programming from the beginning it is
an add on, and hence not a natural component of the (art|science) of
programming and much easier to skip.

I have started teaching my 12 year old son C programming at home. We
started off with a basic "Hello World", then added his name as a
variable, then a loop to print different names, then added the ability
to take the name as input from the command line. At each step we added
in a bit of exception handling, and once we got to user input data we
added basic data and input validation. Each new version of the program
had a test plan and had to handle exceptions. This is a very simple
example and is not something production ready, but every step showed
him how to program without leaving security out.

In my opinion, any educational program that deals with computers or
networks should have security and secure coding woven into it. The
amount and type of secure coding depends on the subject. A management
class that calculates costs and ROI of a project should have metrics
for the cost of security or robustness failures. Networking classes
should have secure configuration integrated. Software
engineering/design would need to have appropriate modules on
encryption, identity management, etc, etc.

In the end I think the question should be: "Is there a place where
does security and secure coding NOT belong in a curriculum?"
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] informIT: attack categories

[Steven M. Christey]

Gary,

You said in the article:

>The next category of attacks to expect are attacks that target defects in
>design and architecture - which I call flaws.

I think it's already happening.  I fully expect to see this reflected in
the updated CVE vulnerability trends for 2007/2008, which (fingers
crossed) will be released in the next month or so (OK, most of the flaws
will be in web apps, but still...)

>we lack a taxonomy of flaws such as the ones we have for bugs (see the
>Seven pernicious kingdoms and the CWE).

CWE is not just a bug parade, it's also a flaw parade ;-)  Although the
parts related to flaws don't
have the depth or specificity that exists for bugs/faults.  The
"weaknesses introduced during design" view CWE-701 actually lists 353
entries.

  http://cwe.mitre.org/data/lists/701.html

... although there are a lot of weaknesses that you could argue are bugs.
For example, is path traversal a bug or a flaw?  It probably depends on
how file handling is performed within a specific application.  Actually, I
think the lines between flaws and bugs/faults can get pretty fuzzy.

We do want to address CWE's relative lack of depth for flaws, however.
The hierarchy in the research view (CWE-1000) may be the best way to
peruse where CWE stands.  I'd love to hear from others who are working in
classification at the flaw level.

Current areas of promise under CWE are CWE-227 ("API Abuse" which has been
borrowed from Seven Pernicious Kingdoms and given a little more
structure), resource lifecycle issues and control spheres (CWE-664),
external control of critical data/variables/systems/clients (CWE-642),
protection mechanism failures (CWE-693), and even many of the classic
Saltzer-and-Schroeder design principles (CWE-657).  It is not coincidental
that these areas still need some work, and any/all input is welcome.  Use
the "graph" tab on the individual CWE pages to see the sub-hierarchies.

Interestingly (or perhaps not), implementation bugs and
design/architecture flaws may share some of the same underlying
fundamental properties.  For example, a bug-level action of setting a
variable declaration to "public" instead of "private" has some of the same
properties as a flaw-level action of creating an open socket that anybody
can connect to - you're unintentionally exposing a resource to somebody
who shouldn't have any access to that resource at all.  Or, as an example
of a resource lifecycle problem, a use-after-free implementation bug isn't
so different than the flaw in which you continue to use a certificate
after it has expired.

I suspect that design/architecture level taxonomies will be very
challenging to build.  For one part, there's a lot less research in the
area than implementation bugs (at least the research that I'm aware of),
and certainly a lot less public vuln data to draw from (e.g. CVE). There's
a lot of stuff on design but not in any easily-packaged form to build a
taxonomy, and it's often tied to specific technologies.  For another, you
have a lot more different perspectives at play.  We can look at an
unbounded strcpy and say "well that's clearly a bug" but at the design
level, is the problem "use of a language that supports arbitrary indexing
of arbitrary pointers" or "use of a risky API function that doesn't
perform its own bounds-checking" or "use of a data structure [string] that
does not have expliticly-stated length as a separate field from the
buffer" or "failure to validate input"?  (The answer may be "all of the
above" or "it depends on your perspective," but that's where taxonomy
construction gets really hard.)

I, for one, can't wait.

- Steve
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Goertzel, Karen [USA]]

Not so much anti-social as untrusting, supicious, and paranoid. Actually, being 
highly social could provide an excellent "cover" to fool the bad guys into 
thinking one is a lot less security-savvy than one actually is.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of McGovern, James F (HTSC, IT) [james.mcgov...@thehartford.com]
Sent: Tuesday, August 25, 2009 2:09 PM
To: Secure Code Mailing List
Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum?

There are several perspectives missing from the dialog:

- Before we even talk about secure coding, we need a course on secure
thinking. Most folks are indoctrinated into thinking positive which
blinds them from seeing vulnerabilities right in front of them. A prereq
on being antisocial might be a good start
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Wall, Kevin]

James McGovern wrote...

> - Taking this one step further, how can we convince
> professors who don't
> teach secure coding to not accept insecure code from their students.
> Professors seed the students thinking by accepting anything
> that barely
> works at the last minute. Universities need to be consistent amongst
> their own teaching/thinking.

Well, actually, I think that what Matt Bishop wrote in his response to
Benjamin Tomhave is the key:

> But in introductory classes, I tend to focus on what I am calling
> "robust" above; when I teach software security, I focus on
> both, as I consider robustness part of security.
>
> By the way, you can do this very effectively in a beginning
> programming class. When I taught Python, as soon as the students got
> to basic structures like control loops (for which they had to do
> simple reading), I showed them how to catch exceptions so that they
> could handle input errors. When they did functions, we went into
> exceptions in more detail. They were told that if they didn't handle
> exceptions in their assignments, they would lose points -- and the
> graders gave inputs that would force exceptions to check that
> they did.
>
> Most people got it quickly.

That is, Matt suggested a direct reward / punishment. Specifically, if
the students don't account for bad input via exceptions or some other
suitable mechanism, the simply loose points.

Matt's right. If it boils down to grades, most students will get it, and
fast.

And whether we call this secure-coding, robustness, or simply correctness,
it's a start.

I think that too many people when they hear that we need to start teaching
security at every level of CS are thinking of more complicated things like
encryption, authentication protocols, Bell-LaPadula, etc. but I don't think
that was where the thrust of this thread was leading.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
kevin.w...@qwest.comPhone: 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



___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Olin Sibert]

I'm mostly a lurker here, and I'm a practitioner rather than a
professional educator, but there's a viewpoint I haven't seem
much of that I want to support, namely:

 Exploits are FUN.

Teach from that angle, and I think you'll get more traction.

I've given a fair number of "basic security" talks to commercial
audiences. Invariably, a significant fraction of the audience,
whether they are professional programmers, inexperienced interns,
marketing types, managers, etc., end up wanting to understand
how exploits actually work and how they are prevented.  I can't
help thinking that this would be true of even the freshest of
programming/compsci students. Heck, I've even gotten that
reaction from some of my kids' high school friends.

Not everyone thinks that way, but I think if we can get students
to think "hey, that's pretty clever" instead of teaching security
as something you _must_ do because it's good for you even though
it's not obviously related to getting the job done, odds for
success are higher. Rigor needs to come eventually, but I think
it is absolutely appropriate to include some exploit-based
entertainment even at the earliest stages of education.

We should be selling sizzling steak, not cod liver oil.

Olin Sibert
Oxford Systems, Inc.

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] informIT: attack categories

[Gary McGraw]

hi sc-l,

Fred sent me some email today and reminded me that he has written about this 
idea himself in IEEE Security & Privacy magazine.  We already had a link to his 
article on the Silver Bullet website, but here's a direct link:

"The Monoculture Risk Put in Context"
IEEE Security and Privacy 7, 1 (January/February 2009), 14-17. Fred Schneider 
and Ken Birman.
http://www.cs.cornell.edu/fbs/publications/IEEEspMonoculture.pdf

gem


On 8/25/09 1:35 PM, "gem"  wrote:

hi sc-l,

If you listened recently to the latest episode of Silver Bullet with Fred 
Schneider from Cornell , one of 
the ideas Fred and I discussed was the notion of attack categories and 
anticipating large scale trends in attack space.  Hopefully you guys all recall 
that I am a strong proponent of understanding the attacker's perspective (see, 
for example Exploiting Software from way back in 2004 where Hoglund and I 
coined the term "attack pattern" ).  This 
month's informIT article is about the notion of long term attack categories and 
is meant to inform software security research:

Software [In]security: Attack Categories and History Prediction
http://www.informit.com/articles/article.aspx?p=1393066

BTW, shout outs for the OWASP top 10 and CWE in the article may surprise the 
usual nay sayers.

Feedback is most welcome.  (Thanks to Ken and Sammy for helping me make this 
article slightly more coherent.)

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
podcast www.cigital.com/justiceleague
book www.swsec.com

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] informIT: attack categories

[Gary McGraw]

hi steve,

The bugs/flaw continuum is, in fact, a continuum.  It's great that you guys 
have begun to collect and publish information about flaws in the CWE.  I agree 
completely with your statement "I suspect that design/architecture level 
taxonomies will be very challenging to build."

Part of what Fred is trying to spark with his work is some research funding for 
that area.

gem


On 8/25/09 6:36 PM, "Steven M. Christey"  wrote:



Gary,

You said in the article:

>The next category of attacks to expect are attacks that target defects in
>design and architecture - which I call flaws.

I think it's already happening.  I fully expect to see this reflected in
the updated CVE vulnerability trends for 2007/2008, which (fingers
crossed) will be released in the next month or so (OK, most of the flaws
will be in web apps, but still...)

>we lack a taxonomy of flaws such as the ones we have for bugs (see the
>Seven pernicious kingdoms and the CWE).

CWE is not just a bug parade, it's also a flaw parade ;-)  Although the
parts related to flaws don't
have the depth or specificity that exists for bugs/faults.  The
"weaknesses introduced during design" view CWE-701 actually lists 353
entries.

  http://cwe.mitre.org/data/lists/701.html

... although there are a lot of weaknesses that you could argue are bugs.
For example, is path traversal a bug or a flaw?  It probably depends on
how file handling is performed within a specific application.  Actually, I
think the lines between flaws and bugs/faults can get pretty fuzzy.

We do want to address CWE's relative lack of depth for flaws, however.
The hierarchy in the research view (CWE-1000) may be the best way to
peruse where CWE stands.  I'd love to hear from others who are working in
classification at the flaw level.

Current areas of promise under CWE are CWE-227 ("API Abuse" which has been
borrowed from Seven Pernicious Kingdoms and given a little more
structure), resource lifecycle issues and control spheres (CWE-664),
external control of critical data/variables/systems/clients (CWE-642),
protection mechanism failures (CWE-693), and even many of the classic
Saltzer-and-Schroeder design principles (CWE-657).  It is not coincidental
that these areas still need some work, and any/all input is welcome.  Use
the "graph" tab on the individual CWE pages to see the sub-hierarchies.

Interestingly (or perhaps not), implementation bugs and
design/architecture flaws may share some of the same underlying
fundamental properties.  For example, a bug-level action of setting a
variable declaration to "public" instead of "private" has some of the same
properties as a flaw-level action of creating an open socket that anybody
can connect to - you're unintentionally exposing a resource to somebody
who shouldn't have any access to that resource at all.  Or, as an example
of a resource lifecycle problem, a use-after-free implementation bug isn't
so different than the flaw in which you continue to use a certificate
after it has expired.

I suspect that design/architecture level taxonomies will be very
challenging to build.  For one part, there's a lot less research in the
area than implementation bugs (at least the research that I'm aware of),
and certainly a lot less public vuln data to draw from (e.g. CVE). There's
a lot of stuff on design but not in any easily-packaged form to build a
taxonomy, and it's often tied to specific technologies.  For another, you
have a lot more different perspectives at play.  We can look at an
unbounded strcpy and say "well that's clearly a bug" but at the design
level, is the problem "use of a language that supports arbitrary indexing
of arbitrary pointers" or "use of a risky API function that doesn't
perform its own bounds-checking" or "use of a data structure [string] that
does not have expliticly-stated length as a separate field from the
buffer" or "failure to validate input"?  (The answer may be "all of the
above" or "it depends on your perspective," but that's where taxonomy
construction gets really hard.)

I, for one, can't wait.

- Steve


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Pravir Chandra]

The "playing in traffic" example is one extreme end of the spectrum. A
good analogy for the other end might be physics where you just teach
Newtonian theory it as if it were 100% accurate and then, if the
student decides to take a relativistic physics class, you teach them
on day 1 that everything they know isn't right. It seems teaching
secure programming must lie somewhere between these two ends of the
spectrum.

Perhaps a more useful exercise (rather than debating where in the
gradient through metaphor) is to try to enumerate the variables that
play into what draws a topic toward one end or the other. Such
variables might include:
 * "stickiness" of the bias/habits acquired as you learn more
 * impetus to learn more
 * ability/access to learn more

Just a thought.

p.


On 8/25/09, Goertzel, Karen [USA]  wrote:
> We teach toddlers from the time they can walk that they shouldn't play in
> traffic. A year or two later, we teach them to look both ways before
> crossing the street. Even later - usually when they're approaching their
> teens, and can deal with "grim reality", we give examples that illustrate
> exactly WHY they needed to know those things.
>
> But that doesn't mean we wait until the kids are 11 or 12 to tell them
> shouldn't play in traffic.
>
> There has to be some way to start introducing the idea even to the rawest of
> raw beginning programming students that "good" is much more desirable than
> "expedient", and then to introduce the various properties that collectively
> constitute "good" - including security.
>
> Karen Mercedes Goertzel, CISSP
> Associate
> 703.698.7454
> goertzel_ka...@bah.com
> 
> From: Andy Steingruebl [stein...@gmail.com]
> Sent: Tuesday, August 25, 2009 1:14 PM
> To: Goertzel, Karen [USA]
> Cc: Benjamin Tomhave; sc-l@securecoding.org
> Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
>
> On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen
> [USA] wrote:
>> For consistency's sake, I hope you agree that if security is an
>> intermediate-to-advanced concept in software development, then all the
>> other "-ilities" ("goodness" properties, if you will), such as quality,
>> reliability, usability, safety, etc. that go beyond "just get the bloody
>> thing to work" are also intermediate-to-advanced concepts.
>>
>> In other words, teach the "goodness" properties to developers only after
>> they've inculcated all the bad habits they possibly can, and then, when
>> they are out in the marketplace and never again incentivised to actually
>> unlearn those bad habits, TRY desperately to change their minds using
>> nothing but F.U.D. and various other psychological means of dubious
>> effectiveness.
>
> Seriously?  We're going to teach kids in 5th grade who are just
> learning what an algorithm is how to protect against malicious inputs,
> how to make their application fast, handle all exception conditions,
> etc?
>
> ...
> ___
> 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
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>


-- 
~ ~  ~ ~~~ ~~ ~
Pravir Chandra  chandralistorg
PGP:CE60 0E10 9207 7290 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~  ~ ~
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Jim Manico]

> I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science

Keep your Picasso out of my coding shop, world of discrete mathematics  
and predicate logic! I don't care how cheap his hourly is. :)


I'd prefer to think of coders as craftsman; we certainly are not  
artists, scientists or engineers. ;) And craftsman are bound by the  
laws of mathematics and the sponsors who pay us, artists have no bounds.


- Jim

On Aug 25, 2009, at 11:35 AM, Benjamin Tomhave > wrote:



I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Benjamin Tomhave]

Matt Bishop wrote:
> 
> Instead, what you can do is frame the issues as "good programming". When
> teaching for loops, teach the idea of a "limit" (upper and lower
> bounds). Then when you get to arrays, it's natural to discuss bounds
> checking in the context of iteration (I don't phrase it that way, of
> course). When you grade, you check for it. Presto! Now you have taught
> what is commonly considered a security requirement without ever
> mentioning the word "security".
> 
I would agree with this, as I think it again syncs with what James
McGovern talked about earlier, too. A graduated approach to "secure
coding" (for whatever definition we might insert) is the only logical
progression. However, as you conceded, we have to be very careful just
how much we introduce and when. I remember the disconnect in the mid-90s
when the CompSci curriculum switched to OO. Some of us got caught in the
blender where our first CS class was non-OO and our 2nd class was
suddenly all OO and we didn't know what the heck was going on. It seems
we're perhaps still in this transitional state to a large part.

> By the way, you can do this very effectively in a beginning programming
> class. When I taught Python, as soon as the students got to basic
> structures like control loops (for which they had to do simple reading),
> I showed them how to catch exceptions so that they could handle input
> errors. When they did functions, we went into exceptions in more detail.
> They were told that if they didn't handle exceptions in their
> assignments, they would lose points -- and the graders gave inputs that
> would force exceptions to check that they did.
> 
Let's just hope that the code isn't compiled with -O3 or similar,
creating an unintended bug. :)
http://isc.sans.org/diary.html?storyid=6820

> Most people got it quickly.
> 
Getting it and applying it IRL are of course two completely different
things. I still find it somewhat absurd that we even need to have this
discussion still after how many decades of curriculum development? :)

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"Reading is to the mind what exercise is to the body."
Sir Richard Steele
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Benjamin Tomhave]

Goertzel, Karen [USA] wrote:
> We teach toddlers from the time they can walk that they shouldn't
> play in traffic. A year or two later, we teach them to look both ways
> before crossing the street. Even later - usually when they're
> approaching their teens, and can deal with "grim reality", we give
> examples that illustrate exactly WHY they needed to know those
> things.
> 
Actually, I'm not teaching my 1 yo toddler much of anything about
traffic right now. I'm more playing guardian when she runs around the
house and making sure she doesn't get into situations for which she
would be completely and totally unprepared (and in serious danger). She
lacks the language skills to even marginally understand basic concepts
like "street" let alone "don't play in the street." I think this rather
proves my point that secure coding is not itself a fundamental concept,
but rather an intermediate-to-advanced concept. Matt Bishop's comments
are great, but they've also been applied in a context of higher ed., and
recognize the limits of student understanding at different phases of
development.

-ben

> But that doesn't mean we wait until the kids are 11 or 12 to tell
> them shouldn't play in traffic.
> 
> There has to be some way to start introducing the idea even to the
> rawest of raw beginning programming students that "good" is much more
> desirable than "expedient", and then to introduce the various
> properties that collectively constitute "good" - including security.
> 
> Karen Mercedes Goertzel, CISSP Associate 703.698.7454 
> goertzel_ka...@bah.com  From:
> Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009
> 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave;
> sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding
> Belong In the Curriculum?
> 
> On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen 
> [USA] wrote:
>> For consistency's sake, I hope you agree that if security is an
>> intermediate-to-advanced concept in software development, then all
>> the other "-ilities" ("goodness" properties, if you will), such as
>> quality, reliability, usability, safety, etc. that go beyond "just
>> get the bloody thing to work" are also intermediate-to-advanced
>> concepts.
>> 
>> In other words, teach the "goodness" properties to developers only
>> after they've inculcated all the bad habits they possibly can, and
>> then, when they are out in the marketplace and never again
>> incentivised to actually unlearn those bad habits, TRY desperately
>> to change their minds using nothing but F.U.D. and various other
>> psychological means of dubious effectiveness.
> 
> Seriously?  We're going to teach kids in 5th grade who are just 
> learning what an algorithm is how to protect against malicious
> inputs, how to make their application fast, handle all exception
> conditions, etc?
> 
> ...
> 

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"That which has always been accepted by everyone, everywhere, is almost
certain to be false."
Paul Valery
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Matt Bishop]

Ben,


Let's just hope that the code isn't compiled with -O3 or similar,
creating an unintended bug. :)
http://isc.sans.org/diary.html?storyid=6820


Brings back memories -- the first day on the job as a summer intern I  
had to track down a bug in a UNIX device driver. Turned out the  
optimizer was clobbering a jump -- the driver worked fine unoptimized.  
I quit believing tools like compilers were flaw-free after that!



Most people got it quickly.


Getting it and applying it IRL are of course two completely different
things. I still find it somewhat absurd that we even need to have this
discussion still after how many decades of curriculum development? :)


Oh, I don't -- I think it's all too understandable. A story first, to  
provide some background.


One of my grad students (a security type, of course :-)) was my TA for  
the undergraduate operating systems class. We had the students form  
teams, and each team modified a kernel. The TA then graded  
interactively, asking the students about what they did and why, as he  
went through their code. My TA was appalled at the poor quality of the  
code of most teams -- it worked, but was not robust and was sloppy.  
So, he told each group that if they turned in code that poor the next  
time, he'd deduct 20% on general principles. So what do students do in  
that case? Right -- complain to the professor (me). I said something  
to the effect that I strongly disagreed with the TA, and felt he  
should have handled the situation differently; but since he said he'd  
only take off 20%, instead of the 40% I would have taken off, I'd  
support his decision. The students got the message. On the next  
assignment (and for the res of the class), the code was much better.


This suggests to me the problem is not so much a failure to teach  
robustness; in fact, I suspect most intro to programming teachers do  
mention it (although to different degrees of thoroughness and probably  
not using that name). The *real* problem is that we don't keep  
reinforcing it throughout the student's career.


And that's an artifact of a lack of resources for the type of grading.  
Give classes the support to do this, and I suspect you'd see people  
get in the habit of writing better code. Better, use students and  
people from industry who know this stuff to staff a clinic analogous  
to a writing clinic for English and law schools -- that would  
reinforce it not just for the students, but for the clinic staff as  
well.


Anyone who's interested in this idea can read about a small experiment  
I did in a paper at


http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/

The results of having students use such a clinic, on a very small  
scale, led to some pretty good improvements in their code. The  
problem, of course, is that supporting such a clinic requires a lot of  
people time, and getting people to donate their time, or the resources  
(read: cash) to pay for it, isn't easy.


Matt
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Benjamin Tomhave]

Matt Bishop wrote:
> 
> And that's an artifact of a lack of resources for the type of grading.
> Give classes the support to do this, and I suspect you'd see people get
> in the habit of writing better code. Better, use students and people
> from industry who know this stuff to staff a clinic analogous to a
> writing clinic for English and law schools -- that would reinforce it
> not just for the students, but for the clinic staff as well.
> 
This sounds like an excellent extension for OWASP. :)

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"I hope if dogs ever take over the world and they choose a king, they
don't just go by size, because I bet there are some Chihuahuas with some
good ideas."
Deep Thoughts by Jack Handy
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Bennett, Jason]

 
 
"So many mistakes have been made in
generations before mine that we are now trapped in a box of our own
making that has us squabbling over academic minutiae like how to teach
secure coding when we should not have to consider this topic at all -
the code itself should be inherently secure."
 
This is the comment that agrees with my own belief. When teaching "how to
program" secure coding should be seen as inherent in this and not as some
sort of optional add that is only required if the code is supposed to
"secure". Many of the techniques are just making the code more robust and
this covers a considerable amount of the problems with code today. I see no
reason that this shouldn't be taught as part of any programming course. Does
this cover all secure coding, no of course not, but unless the foundations
of secure implementation is inherent then more advance issues ar the least
of the communities worries.
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmas...@thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Wall, Kevin]

Brad Andrews writes...

> I had proofs in junior high Geometry too, though I do not recall using
> them outside that class.  I went all the way through differential
> equations, matrix algebra and probability/statistics and I don't
> recall much focus on proofs.  This was in the early 1980s in a good
> school (Illinois), so it wasn't just modern teaching methods that were
> too blame.  I am not sure that the proofs were all that useful for
> understanding some things either, though the logic they taught has
> value that I missed a bit of since I did hit some modern techniques.

This may be heading slightly OT, but I don't think your experience
is really that unusual. My BS was a double major in math and physics
and my MS was in CS.

We used "proofs" in most of my math classes, many of my physics classes,
and several of my CS classes.

Besides the frequency, what varied in each of these was the level of
rigor expected. The proofs in math were extremely rigorous, the ones
in physics less so, and the ones in most of my CS classes would have
been classified as only so much "hand waving" if they would have been
done in my math classes. But an important thing to note in all of these
courses was, with the exception of very few advanced (senior & grad
level) math classes such as "advanced calculus" and "abstract algebra"
and "number theory", the use of 'proofs' wasn't the end, but only a
means to the end.

But still 'proofs' were utilized throughout much of this very diverse
coursework to add to the rigor of the logic and presumably to reinforce
understanding and learning.

In the same way, I think that 'security' (or 'robustness' or 'correctness'
or whatever you wish to call it) needs to be CONSISTENTLY blended into the
college and possibly even high school CS curriculum so some element of it
is touched upon in each of the classes and as one progresses it is discussed
more and more. So just as 'proofs' are sprinkled into math, physics, CS,
etc. we need to sprinkle in basic security / robustness concepts such
as:
+ An understanding of what input may be 'trusted' and what inputs
  cannot be trusted leading to the concept of trust boundaries.
+ The concept of correctness extends merely past handling 'correct' input
  and needs to somehow gracefully handle incorrect input as well.
+ Understanding the concept of risk, eventually leading to an understanding
  of risk analysis in upper level CS courses
+ Having an adversarial testing mindset, always thinking "how can I 'break'
  this program or system?". (BTW, sad to say, this has probably been the
  hardest thing to teach my colleagues. Some of them seem to get it, and
  some of them never do.)

There are probably others--this is by no means a complete list--but we
need to emphasize that to those instructing CS that this is not going to
take up a significant portion of their coursework nor require a significant
amount of time or effort on there part. Rather it needs to be folded into
the mix as appropriate.

I think back to my days in elementary mathematics. I recall learning at a
very early age, when learning division, that you can't divide by 0. The
explanation given by the teach wasn't in depth, it was more like "you are
just not permitted to do that", or occasionally "it's undefined" without
telling us WHY it's undefined. In a similar manner, we can teach "don't
blindly accept unchecked input", etc. And then if that is reinforced in
the grading process I do think it will come through.

Surely if we could just do that much, it would be a good start. But my
observation, based on my CS colleagues that I've taught with and before
that, the CS courses that I've taken at the graduate level, is that
other than the obligatory half hour mention of security in my operating
systems course, I can barely recall it ever even coming up. And I also
seldom recall that instructors would every toss your programs truly
malformed input either. By comparison, when I had an opportunity to
teach a masters level CS course on distributed systems (the Tannenbaum
book), I tossed in matters of security throughout, not just in the
chapters about security. Of course, I don't think until we got to the
chapters about security that the students realized that's what I was
teaching them, but that's OK too. The subliminal methods sometimes
work as well.

-kevin
--
Kevin W. Wall   614.215.4788Application Security Team / Qwest IT
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."-- Nathaniel Borenstein, co-creator of MIME
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://ww

Re: [SC-L] informIT: attack categories

[Prasad Shenoy]

Gary,
Great article and since you used attacks and categories in the same :)
sentence I am tempted to ask if you looked at WASC Threat
Classification project?

On Tuesday, August 25, 2009, Steven M. Christey  wrote:
>
> Gary,
>
> You said in the article:
>
>>The next category of attacks to expect are attacks that target defects in
>>design and architecture - which I call flaws.
>
> I think it's already happening.  I fully expect to see this reflected in
> the updated CVE vulnerability trends for 2007/2008, which (fingers
> crossed) will be released in the next month or so (OK, most of the flaws
> will be in web apps, but still...)
>
>>we lack a taxonomy of flaws such as the ones we have for bugs (see the
>>Seven pernicious kingdoms and the CWE).
>
> CWE is not just a bug parade, it's also a flaw parade ;-)  Although the
> parts related to flaws don't
> have the depth or specificity that exists for bugs/faults.  The
> "weaknesses introduced during design" view CWE-701 actually lists 353
> entries.
>
>   http://cwe.mitre.org/data/lists/701.html
>
> ... although there are a lot of weaknesses that you could argue are bugs.
> For example, is path traversal a bug or a flaw?  It probably depends on
> how file handling is performed within a specific application.  Actually, I
> think the lines between flaws and bugs/faults can get pretty fuzzy.
>
> We do want to address CWE's relative lack of depth for flaws, however.
> The hierarchy in the research view (CWE-1000) may be the best way to
> peruse where CWE stands.  I'd love to hear from others who are working in
> classification at the flaw level.
>
> Current areas of promise under CWE are CWE-227 ("API Abuse" which has been
> borrowed from Seven Pernicious Kingdoms and given a little more
> structure), resource lifecycle issues and control spheres (CWE-664),
> external control of critical data/variables/systems/clients (CWE-642),
> protection mechanism failures (CWE-693), and even many of the classic
> Saltzer-and-Schroeder design principles (CWE-657).  It is not coincidental
> that these areas still need some work, and any/all input is welcome.  Use
> the "graph" tab on the individual CWE pages to see the sub-hierarchies.
>
> Interestingly (or perhaps not), implementation bugs and
> design/architecture flaws may share some of the same underlying
> fundamental properties.  For example, a bug-level action of setting a
> variable declaration to "public" instead of "private" has some of the same
> properties as a flaw-level action of creating an open socket that anybody
> can connect to - you're unintentionally exposing a resource to somebody
> who shouldn't have any access to that resource at all.  Or, as an example
> of a resource lifecycle problem, a use-after-free implementation bug isn't
> so different than the flaw in which you continue to use a certificate
> after it has expired.
>
> I suspect that design/architecture level taxonomies will be very
> challenging to build.  For one part, there's a lot less research in the
> area than implementation bugs (at least the research that I'm aware of),
> and certainly a lot less public vuln data to draw from (e.g. CVE). There's
> a lot of stuff on design but not in any easily-packaged form to build a
> taxonomy, and it's often tied to specific technologies.  For another, you
> have a lot more different perspectives at play.  We can look at an
> unbounded strcpy and say "well that's clearly a bug" but at the design
> level, is the problem "use of a language that supports arbitrary indexing
> of arbitrary pointers" or "use of a risky API function that doesn't
> perform its own bounds-checking" or "use of a data structure [string] that
> does not have expliticly-stated length as a separate field from the
> buffer" or "failure to validate input"?  (The answer may be "all of the
> above" or "it depends on your perspective," but that's where taxonomy
> construction gets really hard.)
>
> I, for one, can't wait.
>
> - Steve
> ___
> 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
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>

-- 
Thanks & Regards,
Prasad N. Shenoy

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Kenneth Van Wyk]

On Aug 25, 2009, at 8:16 PM, Olin Sibert wrote:

Exploits are FUN.


I agree, at least to a point.  Whenever I work exploits into my  
workshops, the results are right on the mark.  So long as the exploits  
are balanced with just the right amount of remediations, it works great.


The key is to hook the students with the exploits, and then sprinkle  
in a "now here's how to do it _right_" discussion while they're still  
paying attention.  ;-)


And FWIW, I've found OWASP's WebGoat to be phenomenally effective at  
doing just that.  There are other similar tools out there as well, but  
the point is to give the class a safe sandbox to play in.


Cheers,

Ken

-
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

(This email is digitally signed with a free x.509 certificate from  
CAcert. If you're unable to verify the signature, try getting their  
root CA certificate at http://www.cacert.org -- for free.)





smime.p7s
Description: S/MIME cryptographic signature
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] informIT: attack categories

[ljknews]

At 6:36 PM -0400 8/25/09, Steven M. Christey wrote:
> Gary,
> 
> You said in the article:
> 
>>The next category of attacks to expect are attacks that target defects in
>>design and architecture - which I call flaws.
> 
> I think it's already happening.

I think it has been happening for years.  I use Microsoft Word
V5.1a from 1992, because Microsoft followed that with Word 6.0
which introduced the design defect allowing Macro Viruses.

Of course this was not actually an innovation, as IBM had
previously introduced _and_withdrawn_ a similar vulnerability
in their CMS operating environment (the mail program would
automatically call a text formatter which could call the
operating system under the direction of the sender.

Those who do not study history are condemned to repeat it.
-- 
Larry Kilgallen
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Inherently Secure Code?

[Peter G. Neumann]

I don't much like INHERENTLY SECURE CODE.
Software components by themselves are not secure.
Security (and trustworthiness that encompasses security, reliability,
  survivability, etc.) is an emergent property of the entire system
  or enterprise.  To say that a component is secure is rather fatuous.

See my DARPA report on composable trustworthy architectures for
starters.
  http://www.csl.sri.com/neumann/chats4.pdf or .html

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Goertzel, Karen [USA]]

Your example is spurious as a refutation of what I was trying to say (as I 
suspect you already know). Obviously you're not going to try to teach a 
not-yet-verbal infant a self-preservation concept that requires even the most 
rudimentary reasoning.

That said, I'll be interested to hear from you in, say, a year and a half from 
now. And I still maintain that the intellectual maturity of a 
two-and-a-half-year-old hardly constitutes "intermediate-to-advanced" EXCEPT 
possibly when compared with that of a one-year-old.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: Benjamin Tomhave [list-s...@secureconsulting.net]
Sent: Wednesday, August 26, 2009 12:27 AM
To: Goertzel, Karen [USA]
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

Goertzel, Karen [USA] wrote:
> We teach toddlers from the time they can walk that they shouldn't
> play in traffic. A year or two later, we teach them to look both ways
> before crossing the street. Even later - usually when they're
> approaching their teens, and can deal with "grim reality", we give
> examples that illustrate exactly WHY they needed to know those
> things.
>
Actually, I'm not teaching my 1 yo toddler much of anything about
traffic right now. I'm more playing guardian when she runs around the
house and making sure she doesn't get into situations for which she...
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Goertzel, Karen [USA]]

I too remember learning proofs in Jr. High. And I also believe the main 
objective was to teach 12 and 13 year olds that it is possible to apply a 
repeatable, disciplined process to how they approach problem solving. Certainly 
not a worthless lesson, even if the mathematics involved are never used again.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Brad Andrews [andr...@rbacomm.com]
Sent: Tuesday, August 25, 2009 4:23 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

I had proofs in junior high Geometry too, though I do not recall using
them outside that class.  I went all the way through differential
equations, matrix algebra and probability/statistics and I don't
recall much focus on proofs.  This was in the early 1980s in a good
school (Illinois), so it wasn't just modern teaching methods that were
too blame.  I am not sure that the proofs were all that useful for
understanding some things either, though the logic they taught has
value that I missed a bit of since I did hit some modern techniques.

--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Goertzel, Karen [USA]]

I see your point. On the other hand, there are times I worry that "teach the 
hacker mentality" approach to secure development training smacks a bit too much 
teaching future policemen the delights of robbery, rape, torture, and murder in 
order to prepare the to defend the public against robbers, rapists, torturers, 
and murders.

Definitely teach - with examples - what it is about software that makes it so 
easy to exploit and violate. But stop short of handing the students detailed 
blueprints and instructions, reinforced by lots of hands-on lab time. I'm just 
untrusting enough of human nature to worry that once some of them discover how 
much more fun it is to hack than to defend against hacking, what you'll end up 
with is not the next Bob Seacord but the next Kevin Mitnick.

At the very least, make psychological exams a prerequisite of acceptance into 
your class, so you can weed out the likely psychopaths and sociopaths.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Olin Sibert [u3...@siliconkeep.com]
Sent: Tuesday, August 25, 2009 8:16 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

I'm mostly a lurker here, and I'm a practitioner rather than a
professional educator, but there's a viewpoint I haven't seem
much of that I want to support, namely:

  Exploits are FUN.

Teach from that angle, and I think you'll get more traction
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Mike Lyman]

Benjamin Tomhave wrote:
> First, security in the software development concept is at least an
> intermediate concept, if not advanced. Riffing on Brad's comments, it
> seems irrational to think that you can jump straight from structural
> basics with which many students struggle (OO anybody?) directly to
> concepts that bridge computer architecture, code structure, and various
> other problems.
>   

Like most technical skills, there is a range of skills that play into
secure software. When you are teaching hello world, you are not coving
program architecture and requirements management. In a similar way you
are not going to get into advanced secure software concepts when you are
teaching hello world. You teach the appropriate skill levels at the
appropriate time and some of these are going to be skills that play into
secure programming. For students at perhaps the high school level and
above, you can probably even begin to introduce them as things that
impact security even if the focus is mainly on doing things right. Bad
habits develop early and we need to prevent them as early as possible.

Earlier I related how I had college instructors tell us not to worry
about extras like error handling but to concentrate on the lesson he was
trying to teach us. Clearly many of us were able to worry about error
handling, we were trying to do it. We tried to do user friendly
interfaces (command line at the time) and respond to incorrect input,
don't bother with that, just concentrate on the lesson. The wrong
lessons were taught those days. Forget the implied requirements, just
get the job done as quickly as possible. Wrong lesson. Early on, way
back in high school, I learned about problems with dividing by zero and
learned to check for it even if it wasn't explicitly in the code. That
was the beginning of input validation. Early on I learned the limits of
integer types on computers (also in high school), that was the beginning
of learning about integer overflow problems.

Secure coding needs to be injected into the entire curriculum to keep
the bad habits from developing early but it needs to be done at a skills
appropriate level. We're not going to teach people to do a threat
modeling when they are doing hello world. We can't teach people to
validate input when they have not had any lessons on comparison
operators, if statements or case statements etc. Once they've had those
though, some basic input validation becomes a great programming
assignment to test their understanding of those skills.
-- 

Mike Lyman
mly...@west-point.org

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Goertzel, Karen [USA]]

Your Picasso - or, perhaps, Frank Lloyd Wright would be a better analogy - 
definitely has a role in software development.  I want his creativity up front 
in the specification and high-level design of the building (the software 
system). But when it comes to detailed design and testing, I'm going to call in 
the engineers, and when it comes to coding, no-one does it better than skilled 
construction workers who have mastered the use of hammers, saws, adzes, etc. 

So yes - the coders are craftsmen. But the problem is that in software 
development, the roles are seldom so clearcut, especially not in Agile 
development. So one does find far too many craftsmen attempting the engineers' 
and architects' jobs without anything like the necessary training and 
certification of their competence to perform those functions.

Or maybe, if we accept the "software development as an art" analogy, our 
problem is we have way too many architects trying to code successfully.

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_ka...@bah.com

From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf 
Of Jim Manico [...@manico.net]
Sent: Tuesday, August 25, 2009 11:17 PM
To: Benjamin Tomhave
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

> I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science

Keep your Picasso out of my coding shop, world of discrete mathematics and 
predicate logic! I don't care how cheap his hourly is. :)

I'd prefer to think of coders as craftsman; we certainly are not artists, 
scientists or engineers. ;) And craftsman are bound by the laws of mathematics 
and the sponsors who pay us, artists have no bounds.

- Jim


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Wall, Kevin]

> Actually, I'm not teaching my 1 yo toddler much of anything about
> traffic right now. I'm more playing guardian when she runs around the
> house and making sure she doesn't get into situations for which she
> would be completely and totally unprepared (and in serious
> danger). She lacks the language skills to even marginally
> understand basic concepts like "street" let alone "don't play
> in the street." I think this rather proves my point that
> secure coding is not itself a fundamental concept,
> but rather an intermediate-to-advanced concept. Matt Bishop's comments
> are great, but they've also been applied in a context of
> higher ed., and recognize the limits of student understanding
> at different phases of development.

I don't mean to split hairs here, but I think "fundamental concept"
vs "intermediate-to-advanced concept" is a red herring. In your case
of you teaching a 1 yr old toddler, "NO" is about the only thing
they understand at this point. That doesn't imply that concepts like
"street" are intermediate-to-advanced. It's all a matter of perspective.
If you are talking to someone with a Ph.D. in physics about partial
differential equations, PDEs *are* a fundamental concept at that level
(and much earlier in fact). The point is, not to argue semantics, but
rather to teach LEVEL-APPROPRIATE concepts.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
kevin.w...@qwest.comPhone: 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


___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[McGovern, James F (HTSC, IT)]

OK, do you really think the folks who pay our bills even understand the
difference between art and craftmanship? Imagine me building a house out
of 2x2 because I can save money on the 2x4s. If I can entertain (manage
perception) the clients such that they won't look (aka CIO) and can
distract the rogue inspector with some other finding (you always have to
let them find something) then I can frame your home and sheetrock it
before you even notice.
 
We are not craftsmen nor are customers willing to pay for it. For the
last 30 or so years, they have been taking our output regardless of
quality and using it. They are more happy with disclaimers and the
appearance of goodness than actual goodness. Enterprises might be
happier with a secure coding process that creates the appearance of
security than the actual heavy lifting of writing secure code. We live
in a world where everyone desires process to be a substitute for
competence.



From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Jim Manico
Sent: Tuesday, August 25, 2009 11:17 PM
To: Benjamin Tomhave
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?


> I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science


Keep your Picasso out of my coding shop, world of discrete mathematics
and predicate logic! I don't care how cheap his hourly is. :)


I'd prefer to think of coders as craftsman; we certainly are not
artists, scientists or engineers. ;) And craftsman are bound by the laws
of mathematics and the sponsors who pay us, artists have no bounds.

- Jim

On Aug 25, 2009, at 11:35 AM, Benjamin Tomhave
 wrote:



I again come back to James McGovern's suggestion, which is
treating
coding as an art rather than a science


This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited.  If you are 
not the intended recipient, please notify the sender immediately by return 
e-mail, delete this communication and destroy all copies.

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Benjamin Tomhave]

Wall, Kevin wrote:
> 
> I don't mean to split hairs here, but I think "fundamental concept"
> vs "intermediate-to-advanced concept" is a red herring. In your case
> of you teaching a 1 yr old toddler, "NO" is about the only thing
> they understand at this point. That doesn't imply that concepts like
> "street" are intermediate-to-advanced. It's all a matter of perspective.
> If you are talking to someone with a Ph.D. in physics about partial
> differential equations, PDEs *are* a fundamental concept at that level
> (and much earlier in fact). The point is, not to argue semantics, but
> rather to teach LEVEL-APPROPRIATE concepts.
> 
I think you do mean to split hairs, and I think you're right to do so.
Context is very important. For example, all this talk about where to fit
secure coding into the curriculum is great, but it also ignores the very
large population of self-taught coders out there, as well as those who
learn their craft in a setting other than a college or university. Ergo,
it still seems like we're talking at ends about an issue that, while
important, is still only at best a partial solution.

-ben

-- 
Benjamin Tomhave, MS, CISSP
fal...@secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
Fitts' Law: "The time to acquire a target is a function of the distance
to and the size of the target."
http://globalnerdy.com/2007/07/18/laws-of-software-development/
___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___