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

[Brad Andrews]

Has anyone who holds to this taught a beginning level programming  
class?  Getting students to understand what a loop is can be hard  
enough, given limited time.  Diving into exploits and buffer overflows  
can be much more difficult.

I am sure some things could be put into a basic class, but the ideas  
are a bit deeper.  Security at the "Hello World!" or Mortgage  
Calculator program level seems quite difficult.

This bears some thinking through, but the security risks seem to be:

- Make sure the input amount is in dollars.
- Make sure the term is numeric and within "reasonable" ranges.
- Make sure that interest rate is in the form of XX.XX.

Other things checked for would be

- Proper output.
- Pausing at the right point so the output can be viewed correctly.

I am sure I am missing things, but this should serve as a base.

Where do you inject security there?  Sure, you can note the importance  
of checking the data, but just because someone checks the input here  
doesn't mean they will have a clue on checking the input on a web form  
for an SQL injection attempt.

I get students who can't loop to start over, they are certainly not  
going to catch that they need to do deeper input inspection,  
especially in a completely unrelated topic.

I am probably blowing some smoke here and I may disagree with myself  
later, but I think this discussion is worth having.

-- 

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


Quoting Mike Lyman <mlyman-cissp at comcast.net>:

> Neil Matatall wrote:
>> So where does secure coding belong in the curriculum?
>>
>> Higher Ed?  High School?
>>
>> Undergrad? Grad? Extension?
>
> Secure coding needs to be taught anytime programing is taught.
>
>> From my experience in my son's boy scout troop, I'm not sure I'd call it
> out as security and confuse middle school/junior high school students
> but I'd teach them basics like input validation and bounds checking as
> basic good programing. The security aspects can wait until later when
> they can better handle several concepts at once.
>
> After that is just needs to be part of the course and called out for
> what it is. There is room for stand alone security focused training and
> courses but it needs to be drilled in all along the way. I recall my own
> computer science instructors telling us *not* to spend time on bells and
> whistles and concentrate on the concept the lesson was covering. If the
> lesson was on pointers, adding things like error checking and user
> friendly features didn't count for anything. I can understand why that
> was said but it sends the wrong message and begins the development of
> bad habits. That was 20 to 30 years ago and most computer users' idea of
> security was locking their car doors but it did set us up for bad
> habits. Basics need to be drilled in early and always count for
> something even if the lesson is while loops.
> --
>
> Mike Lyman
> mlyman at west-point.org
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________
>