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

[McGovern, James F (HTSC, IT)]

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

- For those who work in large enterprises, the positive thinking is even
further reinforced where even functional delivery takes a back seat to
perception management. In order for secure coding to mature, folks need
the ability for someone to not get offended so easily. A good first step
may be figuring out a way to tell someone that their code sucks without
ending up in HR (observed but not personal)

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


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?

[Goertzel, Karen [USA]]

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

[SC-L] informIT: attack categories

[Gary McGraw]

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

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

[Andy Steingruebl]

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?

Maybe we're still having that pupil/student discussion?

In engineering disciplines we split courses into different areas of
concern but still make everyone take all of the classes whether they
are beginner or advanced.  Or, physics for example.  Or maybe
something like music lessons?  Maybe we should teach all kids about
vibrato and complex rhythms from day-1, or maybe before they have even
picked up an instrument we should make them study music theory?

I'm just having a hard time understanding why we're trying to invent
this from scratch when plenty of other disciplines, how people learn
other skills, etc. all start from basics and then get more advanced.

-- 
Andy Steingruebl
stein...@gmail.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.
___

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

[Stephan Neuhaus]

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

You cannot teach advanced grammar to a student with no language  
skills.


I have excellent language skills (after my gaffe with the word  
"student" on this very list, I should perhaps add "in my mother  
tongue"), but you still couldn't teach me grammar. I just don't get  
it.  On the other hand, I have known people who couldn't hold write a  
short essay if it saved their lives, yet they were brilliant in taking  
sentences apart.



Similarly, to think you can teach secure coding to a student with no
coding skills is follow.


I wouldn't teach "secure coding". I'd teach what Karen has termed  
"goodness properties" along with the other coding stuff like  
variables, loops and so on. Even if you teach total beginners, you  
will usually approach programming as a problem-solving exercise. But  
in order to solve an exercise, you must have at least some notion of  
what constitutes a valid solution. So even complete beginners have a  
notion of what it means for the program to produce the desired result.  
And from that basic understanding of correctness to "the program  
should not behave in any unexpected way, even when attacked" it is not  
that far.


Best,

Stephan
___
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?

[Pete Werner]

The "just get the bloody thing to work" is usually an attitude foisted
on developers by the business side.

I work in an internal application security function for a large
enterprise and i'm yet to meet a developer who wasn't concerned about
security.

Developer education is very important and we have a lot of it
available for out developers, some of it even compulsory.

However, unless there is the will of the business behind it, developer
concerns are oft pushed aside in the interest of expediency.

I find the business side usually does have a genuine interest in
"security" and "quality", however they are concepts that remain
largely unquantifiable, and in the case of security you only need to
mess up once to end up with a nasty situation.

It's can be a tough sell getting time to focus on these things, given
they can be so vague. In the case of my organisation, business side
support comes from both internal advocacy of security practises by our
function and externally imposed legal requirements. Mostly the latter
;)

Filtering inputs is NOT hard, and most developers are getting better
at things like that. However, the problems of application security go
beyond the developer level, and it's important not to lose sight of
that fact. If there were an easy solution everything would already be
perfectly secure.

Pete

On Wed, Aug 26, 2009 at 12: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.
>
> Great strategy! Our hacker friends will love it.
>
> 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 Benjamin Tomhave [list-s...@secureconsulting.net]
> Sent: Monday, August 24, 2009 8:35 PM
> To: sc-l@securecoding.org
> Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
>
> Two quick comments in catching up on the thread...
>
> First, security in the software development concept is at least an
> intermediate concept, if not advanced
> ___
> 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] Where Does Secure Coding Belong In the Curriculum?

[Matt Bishop]

Ben,


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.


I agree and I disagree. If I walked into an ECS 10 (Intro to  
Programming class) and began "We use the waterfall model to provide a  
moderate level of assurance ..." about 75% of the students would be  
out the door. That's one problem with teaching security per se: you  
need to describe *what* your security requirements are, and when  
you're struggling to learn how to write a "for" loop, being asked to  
implement security requirements as such is intimidating.


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 find the distinction between "robust" and "secure" is useful,  
although often the two are interchangeable. By "robust", I mean the  
more nebulous requirement that the program not crash (although it may  
terminate gracefully :-)) and that it handle unexpected inputs  
reasonably, and so forth. By "secure", I mean meeting a specific set  
of requirements that describe what "security" means; for example,  
unexpected inputs may require specific actions (in which case handling  
them is both robust and secure :-)). Note: I'm not sure the  
distinction here is too meaningful, so please don't ask me to define a  
boundary.


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.

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?

[Stephan Neuhaus]

On Aug 25, 2009, at 18:07, Andy Steingruebl wrote:


really?  First graders are learning to do math proofs instead
of basic addition?  I'm quite surprised by this.


Yeah, sorry.  When I wrote about "students" I meant "college  
students". I don't know, is that a difference between British English  
(pupils) and American English (students)? Anyway, my bad.



We're missing I think the point I raised earlier.  Not everyone learns
to program in high school or college.  And, even learning the basics
of what an algorithm are is tricky, much less learning defensive
programming, etc.


But the topic of the thread is "Where Does Secure Coding Belong In the  
Curriculum?" and 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.


Best,

Stephan
___
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 Steingruebl]

On Tue, Aug 25, 2009 at 4:09 AM, Stephan
Neuhaus wrote:
>
> On Aug 25, 2009, at 02:35, Benjamin Tomhave wrote:
>
>> First, security in the software development concept is at least an
>> intermediate concept, if not advanced.
>
> Not at all. That would be like saying that correctness is also an advanced
> concept, because it gets in the way of coding. Security is about exploiting
> assumptions (often hidden) that we make when we write and deploy software. I
> see no reason why teaching to think about assumptions should be deferred.
> You teach math students how to do proofs right from the beginning for
> essentially the same reasons :-)

really?  First graders are learning to do math proofs instead
of basic addition?  I'm quite surprised by this.

We're missing I think the point I raised earlier.  Not everyone learns
to program in high school or college.  And, even learning the basics
of what an algorithm are is tricky, much less learning defensive
programming, etc.

So, yes, it is an "advanced" concept for the majority of beginning programmers.

-- 
Andy Steingruebl
stein...@gmail.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.
___

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

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



I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science. It increasingly makes sense
given the failures up to this point.


The problem then is that every Joe, Dick, and Harry out there who can  
get hello world to compile think they're artists. Seriously, unlike  
art, programming is usually not a vehicle for one's creative urges,  
but a tool to get a job done, as you yourself say. (I hesitate to use  
the word "science" as an antonym to "art" here, perhaps "craft" would  
be better.)


Unfortunately, security assumptions are rarely written down so I  
don't

see how they can be enforced at the language or compiler level.

Here you make a patently bad assumption yourself. It should be  
possible

for the compiler to automatically protect against overflows, as an
example.


Sure, for certain languages and certain classes of well-understood  
problems, compiler or language support can be engineered. But my point  
stands: security assumptions are rarely written down. This is because  
they are taken to be self-evident and not in need of explicit  
formulation. Also, they depend on the domain. If I express a hospital  
drug disbursal system in any of the common general-purpose programming  
languages, the assumption that one cannot be a doctor and a nurse at  
the same time is usually implicit. I challenge you to develop Java or C 
++ support that will capture any flaw in the implementation of this  
particular RBAC *without* having to make that assumption explicit.



Safe input validation and output encoding could also be forced
at a given level.


Really? I'd be interested in hearing about such techniques that cannot  
be short-cut (which, as you state, is one big factor for security  
defects in software).


Best,

Stephan
___
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]

Stephan Neuhaus wrote:
> 
> and deploy software. I see no reason why teaching to think about
> assumptions should be deferred. You teach math students how to do proofs
> right from the beginning for essentially the same reasons :-)
> 
You don't teach proofs - not really. The elementary and junior high
curriculum generally does not contain anything about proofs (if it does,
then that program is rare - especially in the NCLB era - unless you're
considering use of manipulatives to be a "proof" with which I would
disagree as it's merely empirical). You have to teach the basic
constructs. You have to ingrain the fundamentals. The same is true for
coding.

The good news, perhaps, is that you're not generally teaching 1st
graders how to write code. So you can go into more advanced topics with
high school or college students. Nonetheless, these programs rarely
resemble anything in real life. You talk about assumptions - this is one
of the biggest - that CompSci curricula actually teaches much of
anything relevant to enterprise life. Anyway.

I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science. It increasingly makes sense
given the failures up to this point. Though, at the same time, I stick
with my original 2nd point, which is that as soon as coders can take
short-cuts, they will, because deadlines rule the day.

> Unfortunately, security assumptions are rarely written down so I don't
> see how they can be enforced at the language or compiler level.
> 
Here you make a patently bad assumption yourself. It should be possible
for the compiler to automatically protect against overflows, as an
example. Safe input validation and output encoding could also be forced
at a given level. Compiler/interpreter - it doesn't matter, as long as
you're not expecting a human coder to do extra work under deadlines and
duress to "do things right" (especially when it conflicts with "doing
the right thing" which is getting the job done and keeping one's boss
happy).

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.

-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: ]
Sturgeon's Revelation: "Ninety percent of everything is crud."
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.
___

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

[Benjamin Tomhave]

It's a catch-22, and there's certainly no need to be snarky about it.
You cannot teach advanced grammar to a student with no language skills.
Similarly, to think you can teach secure coding to a student with no
coding skills is follow. I think James McGovern's suggestion is probably
the best alternative, having students evaluate and analyze the
difference between good and bad code. However, I think the utility in
that approach will quickly deteriorate as the students gain more skill
in writing their own code. The lazy coder will win out in the end when
there are deadlines to be met.

As for our hacker friends, if we want to go down that path, then I
submit that this war is already very much lost. Hanging out with some of
the crews at Defcon this year was an eye-opening experience. We are so
far behind the curve that it is irrational to think that we will ever
catch-up unless the entire battlefield is changed, and the rules of
engagement along with them. 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 not, incidentally,
FUD - it's fact, to which not nearly enough people have direct exposure.

-ben

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.
> 
> Great strategy! Our hacker friends will love it.
> 
> 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 Benjamin Tomhave [list-s...@secureconsulting.net] Sent:
> Monday, August 24, 2009 8:35 PM To: sc-l@securecoding.org Subject:
> Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
> 
> Two quick comments in catching up on the thread...
> 
> First, security in the software development concept is at least an 
> intermediate concept, if not advanced
> 

-- 
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: ]
"If at first you don't succeed, failure might be your thing."
Warren Miller, Impact
___
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]]

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.

Great strategy! Our hacker friends will love it.

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 Benjamin Tomhave [list-s...@secureconsulting.net]
Sent: Monday, August 24, 2009 8:35 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

Two quick comments in catching up on the thread...

First, security in the software development concept is at least an
intermediate concept, if not advanced
___
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?

[Stephan Neuhaus]

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


First, security in the software development concept is at least an
intermediate concept, if not advanced.


Not at all. That would be like saying that correctness is also an  
advanced concept, because it gets in the way of coding. Security is  
about exploiting assumptions (often hidden) that we make when we write  
and deploy software. I see no reason why teaching to think about  
assumptions should be deferred. You teach math students how to do  
proofs right from the beginning for essentially the same reasons :-)



Perhaps this means that the
language itself needs to require strong type checking that enforce
appropriate secure coding behavior?


Unfortunately, security assumptions are rarely written down so I don't  
see how they can be enforced at the language or compiler level.


Best,

Stephan
___
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] OWASP Podcast August Update

[James Manico]

Hello SC-L!

The OWASP Podcast Series continues to accelerate! We released 5 podcasts
this month which I hope you find to be of  value.
39August 25, 2009Listen
Now
 | Show Notes Interview with Gunnar Peterson
(Webservices)38August 25, 2009Listen
Now
 | Show Notes Interview with the OWASP Global
Education Committee37August 22, 2009*Listen
Now
* | Show Notes Interview with Jason Lam and Johannes
Ullrich (SANS Institute)36August 15, 2009Listen
Now
 | Show Notes May 2009 News Commentary Recorded July
23 with Boaz Gelbord, Andre Gironda, Jason Lam, Jim Manico, Alex Smolen, Ben
Tomhave, Andrew van der Stock and Jeff Williams (part 2)35August 4, 2009Listen
Now  | Show
Notes Interview with Anton Chuvakin, Ph.D (PCI)
Faster than a speeding bullet *winks*, the OWASP Podcast
Seriesis
bringing on 2 additional hosts, is spawning a Spanish AppSec podcast
series, and will be releasing interviews from Andy Steingruebl (PayPal),
David Rice (Geekonomics), and the DC AppSec crowd (Acronyms) in September.

Ken, please forgive me for ignoring your advice to slow down. ;D

Aloha to all of SC-L and thank you for listening.

-- 
Jim Manico
jim.man...@aspectsecurity.com
jim.man...@owasp.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] Functional Correctness

[Pravir Chandra]

Well, this topic gets muddy pretty quickly since I agree with many of
the comments made on this thread. We have to be careful with hype and
claims made by new models (BSIMM and OpenSAMM in particular) since
depending on how the 'rest of the world' sees them speaks directly to
our credibility as industry experts.

I've tried hard when presenting OpenSAMM to fully claim that the model
is chocked full of value judgements about what organizations SHOULD be
doing to make a justified argument (qualitatively) that the software
they produce has a degree of assurance built-in. Is it a guarantee?
No. Is it still valuable? Absolutely. Before, we had no ability to
make an apples-to-apples comparison between two organizations, and the
model helps that. We also didn't know how to quantify iterative
improvement very well or explain the breadth of the software security
problem to people either, and OpenSAMM helps that too. I disagree with
the remark that maturity models are only useful to companies starting
with nothing, because I've seen firsthand how OpenSAMM has helped
people (already doing a lot for assurance) think through aspects of
the software security problem that fell outside their tunnel-vision.

Now, on to the sticky topic of value judgements. Based on how I've
seen the BSIMM presented, one might think that at face value, it is
somehow more free of author/contributor value judgements than OpenSAMM
or other secure SDLC models (I've read several articles referring to
these as 'alchemy'). This is simply not true. I, for one, agree with
Brad that claims of a scientific nature need to be extremely carefully
qualified. At the end of the day, we don't yet know enough about
practical methods for improving software security that have much
justification beyond what experts think amounts to a 'good thing'
(excepting formal methods, of course, but I did say practical :). This
is the case for both BSIMM and OpenSAMM.

I welcome comments/questions/flames.

p.





On 8/22/09, Cassidy, Colin (GE Infra, Energy)  wrote:
>
>
> Brad Andrews Writes:
>
>> After all, we can just "implement this maturity model and eliminate
>> all our security problems, at least in the application,
>> right?"  That
>> is likely to end up resulting in even more resistance in the future
>> when management questions why they need to keep spending more for
>> software security, a secure architecture, etc.  Don't people learn
>> what they need to know at some point?
>
> I don't thinks that's ever been the case that you can just apply your model
> and all will be well Microsoft didn`t release their SDL and said "there all
> our software will now be secure", they're constantly evolving their
> processes.
>
> Also some of the activities within the BSIMM are about constant improvement
> and keeping up with the latest trends, so even just following the BSIMM your
> processes are never static.
>
>> I don't think we will ever be static.  As soon as we remove the low
>> hanging fruit, the fruit higher up the tree will be the problem.
>
> Or, the fruit on another tree :) who's attacking the OS now when the apps
> are so easy to attack
>
>> This isn't to say a maturity model is useless, but I remain
>> skeptical
>> that it will live up to the "hype" (low key now, but there) it is
>> being presented with.
>
> I think that the models (both BSIMM and OSAMM) help to provide a framework
> and a direction to those that have no real security practices at all.  Or
> allow a measurement of existing process and see where their weaknesses are.
> That and the senior management like the pretty graphs even if they don't
> know what it means :D
>
> CJC
>


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

[Benjamin Tomhave]

Two quick comments in catching up on the thread...

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.

Second, as long as "the right way" is not the same as "the easy way"
then there will always be a disconnect. Perhaps this means that the
language itself needs to require strong type checking that enforce
appropriate secure coding behavior? Or maybe this is even enforced at
the compiler level? (there have, of course, been problems with
compilers, too, particularly in optimization mode)

cheers,

-ben

Brad Andrews wrote:
> 
> But we are not talking about separate classes.  The assertion (which I
> probably clipped, sorry) was that it should be woven into the
> curriculum.  I was noting where and how to do so, starting in the intro
> level classes.  Just telling a starting programmer to properly check
> input length is all well and good, but falls far short of making a
> secure programmer.
> 
> I have no doubt that you can teach some new developers the principles in
> a short time and make them more productive than those who have been
> programming longer term.  They don't have to unlearn anything!  But this
> will not work for everyone.  Some will sit through a class with glazed
> eyes and no understanding.
> 
> Also remember we will have to get outside those with a fairly high level
> of motivation (internal or external) for learning the material to be
> successful.
> 
> I also would like to see how you would teach secure development, with
> minimal extra time load, in a basic programming sequence, possibly even
> at a non-traditional or lower tier school.  We won't make significant
> progress until we can do that, and it still leaves out the "self taught."
> 

-- 
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: ]
Moore's Law: "The number of transistors on an integrated circuit will
double in about 18 months."
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.
___