[SC-L] Customer Demand

[Brad Andrews]

While no customer is likely to say they don't care about software  
working now that we are past Y2K, they don't think about it at all and  
are unlikely to allow any schedule slippage to allow for making sure  
that is true.


Customers only really care about the things they will pay for.  Many  
companies claim they "can't stand" poor software or services, but they  
still pay for them, so they will keep getting them.


Until we convince them that good security really is important and that  
they must demand and pay for it, we won't make the progress we want to  
make.


How many companies wouldn't even be doing the PCI level of effort if  
they weren't forced to do so?  How many strictly limit it to their  
"PCI environment" rather than looking at the risk to the whole  
enterprise?  Even major breaches don't help since the "it can't happen  
here" attitude is common all over, in spite of the fact it is a risky  
stance.


While part of this is just a cynical rant, I think the base point is  
that we have a whole lot more selling to do on the need for software  
security before we can properly place it throughout the curriculum.   
That sales job is hard.  The fact a few people have "gotten it"  
doesn't mean most have or that we are completely ready for the next  
step.


I realize many here may not be saying that, but that is the message I  
get stepping back.  And I am a dreamer/visionary.  I like to think  
well ahead of things, but focusing too much there makes us likely to  
continue to be a niche area, leaving lots of vulnerabilities.


Wouldn't a better focus be on the customer demand end?  Stirring that  
up will do more to advance secure development than any number of  
maturity models.  Unfortunately, it is a much more difficult task.  I  
would bet it is also not as conceptually interesting to many.


--

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


Quoting Martin Gilje Jaatun :


His stance on this
is that "if security were important to the customer, the customer would
provide and prioritize security requirements". To me, this is a bit like
saying "If the customer doesn't explicitly state that the software
should be Y2k-proof, he/she is not really bothered about it".


___
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] Grading Secure Programs

[Brad Andrews]

This brings up a great point.  How can we grade a program's security  
level?  Is it just a checkoff list?  Which elements should be in that  
checkoff list?


The worst part of teaching is grading papers (programs are a close  
second).  Making that more complicated is not likely to work.  I  
already spend more time than I want on it, how are you going to  
convince me to spend more time looking for "secure programs"?  It  
won't happen.


(10 seconds grading would be too long, so "enough time" is a relative  
rather than an absolute time.)


This also ties back to what things you can really look for in most  
instructional programs, though this would depend on the level of the  
class.  Still, if you are going to require a solid mathematical  
algorithm, you had better have spent some time going over how to  
implement mathematical algorithms in code.  In the same way, if you  
want a student to check against SQL injection, you have to have taught  
that at some point.  (Neither have to be in the same class, but they  
must be prerequisites and likely part of a lower level class.)


Curious question:  How many proclaiming "weave it into the curriculum"  
have worked with many lower-level classes as an instructor?


--

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


Quoting Rob Floodeen :


  2. a formal method for deducting points from a properly working but
incorrectly constructed program (a "Show your work" secure coding
equivalent)


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

[Robert Seacord]

Neil,

I teach two software security classes at Carnegie Mellon:

CS 15392 Secure Programming - Undergraduate Computer Science
https://www.securecoding.cert.org/confluence/display/sci/S08+15392+Secure+Programming
 

INI 14735  Secure Software Engineering - Graduate Course in Information 
Networking Institute (INI)

The INI materials are on our blackboard system and harder to share, but much of 
the material is the same as the undergraduate course.

If your (or anyone else) is interested in teaching this course (or portions of 
this course) at your college or university I would be happy to share the power 
point slides and other course materials with you.  However, because the SEI 
offers a 4 day version of this course to professional audiences (see 
http://www.sei.cmu.edu/products/courses/p63.html), as well as licensing this 
course to organizations to provide this training, this offer only applies to 
higher education and not to professional education.

Thanks,
rCs


Robert C. Seacord
Secure Coding Team Lead
CERT / Software Engineering Institute
Work: +1 412.268.7608
FAX:+1 412.268.6989

___
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] Silver Bullet: Fred Schneider

[Gary McGraw]

hi sc-l,

The 41st epsiode of Silver Bullet just went live.  This episode features a 
conversation with Fred Schneider, a computer sceince professor at Cornell and a 
very important thought leader in security research.  Fred was the author of the 
seminal National Academies study "Trust in Cyberspace".  We talk about the 
relationship between reliability and security, about fault tolerant systems, 
and about diversity as a security mechanism.  We also talk about writing secure 
code, outlawing C, and the end of the age of bugs.  Fred brings up the idea of 
categories of attack and the evolution of attacks from configuration, through 
bugs, to flaws and finally to trust problems.

http://www.cigital.com/silverbullet/show-041/

Fred is particularly well spoken and cogent, and it was a great privilege to 
chat about security with him.  As always, your feedback is welcome.

gem

company www.cigital.com
podcast www.cigital.com/realitycheck
blog 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?

[McGovern, James F (HTSC, IT)]

Wanted to introduce another worst practice in terms of Universities vs
Enterprises that isn't about curriculum but is about knowledge of secure
coding. There are user groups such as OWASP where topics such as secure
coding are frequently discussed. These events are 100% free to attend
and are filled with professionals.

On my side of town, the professors that happen to be adjunct and have a
day job in corporations for whatever reason also are not only
introducing secure coding techniques into their material, they are
encouraging their students to attend our local Hartford OWASP chapter
(http://www.owasp.org/index.php/Hartford) Likewise, on numerous
occasions, we have reached out and extended the same invite to fulltime
professors who have neither made any effort in attending nor even
sharing with their students. 

So, when do we ask the more difficult question of whether current
professors are capable of teaching the curriculum in a manner that
enables the success for their students...

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?

[SC-L Reader Dave Aronson]

Goertzel, Karen [USA] wrote:

> If determination of functional correctness were extended from "must
> operate as specified under expected conditions" to "must operate as
> specified under all conditions", functional correctness would necessarily
> require security, safety, fault tolerance, and all those other good things
> that make software dependable instead of just correct.

A much-too-late entry for the bumper sticker contest we had here a few
years back:

 "Works as you wish, under all condish."

(Okay, okay, so maybe that kind of abbreviating is a bit out of
style... by 70 years or so)

-Dave

-- 
Dave Aronson, software engineer or trainer for hire.
Looking for job (or contract) in Washington DC area.
See http://davearonson.com/ for resume & other info.
___
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]

Karen Goertzel wrote...

> I'm more devious. I think what needs to happen is that we
> need to redefine what we mean by "functionally correct" or
> "quality" code. If determination of functional correctness
> were extended from "must operate as specified under expected
> conditions" to "must operate as specified under all
> conditions", functional correctness would necessarily require
> security, safety, fault tolerance, and all those other good
> things that make software dependable instead of just correct.

Except, unfortunately, as an industry / profession, we can't even
get the far-simpler (IMO) _functional correctness_ right let
alone (so-called) "non-functional" issues such as security, safety,
fault tolerance, etc. (Mathematical rigor and proof-of-correctness aside,
but in many [most?] cases that's not practical and even if it were, most
programmers' brains turn to mathematical mush whenever they see any
kind of correctness proof. Meaning that "it ain't going to happen"
if it requires thinking. ;-)

In some regard, I think this holds things back. If we don't do a
good job testing that the software does all that it's supposed to do
under *ideal* conditions, how are we ever to expect developers and
testers to test to make sure that the software doesn't do additional
things that it's NOT supposed to do under less than ideal conditions.
There's a reason why Ross Anderson and Roger Needham talked about
"Programming Satan's Computer" (see
http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf). [Yes, I 'm aware that
paper was about the correctness of distributed cryptographic protocols,
but I think both Anderson and Needham would agree that the term
"Programming Satan's Computer" applies more generally than just to that
narrow aspect of security.]

Not that I'm advocating of giving up, mind you. If the battle seems
hopeless, perhaps we would see more progress if we were to address
secure programming issues simply as a related aspect of program
correctness. Why? Because the development community seems to be more
willing to address those things. (Obviously, part of that is that
many programming flaws are rather tangible and something that casual
users can experience. Yeah! That's the ticket. Let's teach the general
populace how to hack into systems! Pass out free "You've been pwnd!"
T-shirts with every successful pwnage. Now *THAT* would be devious. ;-)

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

[SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)

[Martin Gilje Jaatun]

Karen, Matt & all,

Goertzel, Karen [USA] wrote:
> I'm more devious. I think what needs to happen is that we need to redefine 
> what we mean by "functionally correct" or "quality" code. If determination of 
> functional correctness were extended from "must operate as specified under 
> expected conditions" to "must operate as specified under all conditions", 
> functional correctness would necessarily require security, safety, fault 
> tolerance, and all those other good things that make software dependable 
> instead of just correct.
>   
I couldn't agree more!

However, I have had several discussions with a colleague who is fairly
well known in the"Software Process Improvement Mafia" on the topic of
how to ensure that security requirements are considered for _all_ kinds
of code, not just "security software". Particularily in the context of
agile development techniques, security keeps getting the short end of
the stick, losing every time to "working features". His stance on this
is that "if security were important to the customer, the customer would
provide and prioritize security requirements". To me, this is a bit like
saying "If the customer doesn't explicitly state that the software
should be Y2k-proof, he/she is not really bothered about it".

If we can "brainwash" the coming generations of programmers into
accepting Karen's definition of "quality code", we might finally be
getting somewhere.

-Martin

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

Here's an extract from the Information Assurance Technology Analysis Center 
(part of DTIC) "Software Security Assurance: A State of the Art Report" 
(http://iac.dtic.mil/iatac/download/security.pdf):

Courses on secure software development, secure programming, etc., typically
begin by introducing common attacks against software-intensive information
systems and the vulnerabilities targeted by those attacks, then progress to
modeling, design, coding, and testing practices that software developers can 
adopt
to reduce the likelihood that exploitable vulnerabilities will appear in the 
software
they produce. The following is a representative sampling of such courses:

- Arizona State University: Software Security
- Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems
- Carnegie Mellon University (CMU) and University of Ontario (Canada):
Secure Software Systems
- George Mason University: Secure Software Design and Programming
- George Washington University: Security and Programming Languages
- Catholic University of Leuven (Belgium): Development of Secure Software
- New Mexico Tech: Secure Software Construction
- North Dakota State University: Engineering Secure Software
- Northeastern University: Engineering Secure Software Systems
- Northern Kentucky University, Rochester Institute of Technology, and
University of Denver: Secure Software Engineering
- Polytechnic University: Application Security
- Purdue University: Secure Programming
- Queen’s University (Kingston, ON, Canada): Software Reliability
and Security
- Santa Clara University: Secure Coding in C and C++
- University of California at Berkeley, Walden University (online): Secure
Software Development
- University of California at Santa Cruz: Software Security Testing
- University of Canterbury (New Zealand): Secure Software
- University of Nice Sophia-Antipolis (Nice, France): Formal Methods
and Secure Software
- University of Oxford (UK): Design for Security
- University of South Carolina: Building Secure Software.

As noted earlier, other schools offer lectures on secure coding and other
software security relevant topics within their larger software engineering or
computer security course offerings. At least two universities - the University
of Texas at San Antonio and University of Dublin (Ireland) - have established
reading groups focusing on software security.

As part of its Trustworthy Computing initiative, Microsoft Research
has established its Trustworthy Computing Curriculum program [309] for
promoting university development of software security curricula. Interested
institutions submit proposals to Microsoft, and those that are selected are
provided seed funding for course development.

Another recent trend is post-graduate degree programs with specialties
or concentrations in secure software engineering (or security engineering for
software-intensive systems). Some of these are standard degree programs,
while others are specifically designed for the continuing education of working
professionals. The following are typical examples:

- James Madison University: Master of Science in Computer Science with
a Concentration in Secure Software Engineering
- Northern Kentucky University: Graduate Certificate in Secure
Software Engineering
- Stanford University: Online Computer Security Certificate in Designing
Secure Software From the Ground Up
- University of Colorado at Colorado Springs: Graduate Certificate in
Secure Software Systems
- Walden University (online): Master of Science in Software Engineering
with a Specialization in Secure Computing
- University of Central England at Birmingham: Master of Science in
Software Development and Security
- Chalmers University (Gothenburg, Sweden): Master of Science in
Secure and Dependable Computer Systems.

In another interesting trend (to date, exclusively in non-US schools),
entire academic departments - and in one case a whole graduate school—are
being devoted to teaching and research in software dependability, including
security, e.g.:

- University of Oldenburg (Germany) TrustSoft Graduate School of
Trustworthy Software Systems
- Fraunhofer Institute for Experimental Software Engineering (IESE)
(Kaiserslautern, Germany): Department of Security and Safety
- Bond University (Queensland, Australia): Centre for Software Assurance.


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 Gary McGraw [...@cigital.com]
Sent: Thursday, August 20, 2009 2:55 PM
To: Neil Matatall; Secure Code Mailing List
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

hi neil,

For what it's worth, there is a list of universities with some kind of software 
security curriculum on page 98 of "Software Security" .  
Remember, this list was created in 2006, and lots of other universities have 
jumped on the bandwagon since

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

[Neil Matatall]

Everyone,

Thank you for all of the input.  Really.  This information has been 
extremely helpful! 


Neil

Goertzel, Karen [USA] wrote:

Here's an extract from the Information Assurance Technology Analysis Center (part of 
DTIC) "Software Security Assurance: A State of the Art Report" 
(http://iac.dtic.mil/iatac/download/security.pdf):

Courses on secure software development, secure programming, etc., typically
begin by introducing common attacks against software-intensive information
systems and the vulnerabilities targeted by those attacks, then progress to
modeling, design, coding, and testing practices that software developers can 
adopt
to reduce the likelihood that exploitable vulnerabilities will appear in the 
software
they produce. The following is a representative sampling of such courses:

- Arizona State University: Software Security
- Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems
- Carnegie Mellon University (CMU) and University of Ontario (Canada):
Secure Software Systems
- George Mason University: Secure Software Design and Programming
- George Washington University: Security and Programming Languages
- Catholic University of Leuven (Belgium): Development of Secure Software
- New Mexico Tech: Secure Software Construction
- North Dakota State University: Engineering Secure Software
- Northeastern University: Engineering Secure Software Systems
- Northern Kentucky University, Rochester Institute of Technology, and
University of Denver: Secure Software Engineering
- Polytechnic University: Application Security
- Purdue University: Secure Programming
- Queen’s University (Kingston, ON, Canada): Software Reliability
and Security
- Santa Clara University: Secure Coding in C and C++
- University of California at Berkeley, Walden University (online): Secure
Software Development
- University of California at Santa Cruz: Software Security Testing
- University of Canterbury (New Zealand): Secure Software
- University of Nice Sophia-Antipolis (Nice, France): Formal Methods
and Secure Software
- University of Oxford (UK): Design for Security
- University of South Carolina: Building Secure Software.

As noted earlier, other schools offer lectures on secure coding and other
software security relevant topics within their larger software engineering or
computer security course offerings. At least two universities - the University
of Texas at San Antonio and University of Dublin (Ireland) - have established
reading groups focusing on software security.

As part of its Trustworthy Computing initiative, Microsoft Research
has established its Trustworthy Computing Curriculum program [309] for
promoting university development of software security curricula. Interested
institutions submit proposals to Microsoft, and those that are selected are
provided seed funding for course development.

Another recent trend is post-graduate degree programs with specialties
or concentrations in secure software engineering (or security engineering for
software-intensive systems). Some of these are standard degree programs,
while others are specifically designed for the continuing education of working
professionals. The following are typical examples:

- James Madison University: Master of Science in Computer Science with
a Concentration in Secure Software Engineering
- Northern Kentucky University: Graduate Certificate in Secure
Software Engineering
- Stanford University: Online Computer Security Certificate in Designing
Secure Software From the Ground Up
- University of Colorado at Colorado Springs: Graduate Certificate in
Secure Software Systems
- Walden University (online): Master of Science in Software Engineering
with a Specialization in Secure Computing
- University of Central England at Birmingham: Master of Science in
Software Development and Security
- Chalmers University (Gothenburg, Sweden): Master of Science in
Secure and Dependable Computer Systems.

In another interesting trend (to date, exclusively in non-US schools),
entire academic departments - and in one case a whole graduate school—are
being devoted to teaching and research in software dependability, including
security, e.g.:

- University of Oldenburg (Germany) TrustSoft Graduate School of
Trustworthy Software Systems
- Fraunhofer Institute for Experimental Software Engineering (IESE)
(Kaiserslautern, Germany): Department of Security and Safety
- Bond University (Queensland, Australia): Centre for Software Assurance.


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 Gary McGraw [...@cigital.com]
Sent: Thursday, August 20, 2009 2:55 PM
To: Neil Matatall; Secure Code Mailing List
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

hi neil,

For what it's worth, there is a list of universities with some kind of software security 
curriculum on page 98 of "Software 

Re: [SC-L] embedded systems security analysis

[Goertzel, Karen [USA]]

A colleague and I have been looking at the problem a bit, in the context of 
need for survivability in safety-critical systems. Below is an extract of the 
paper "Software Survivability: Where Safety and Security Converge" authored by 
Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore 
Winograd at the American Institute of Aeronautics and Astronautics' 
infot...@aerospace Conference in Seattle last spring.

There's also a brief discussion of security issues associated with embedded 
software in the DHS/DACS "Enhancing the Development Life Cycle to Produce 
Secure Software" - specifically pages 272-275. The document is freely 
downloadable after quick registration on the DACS (DTIC's Data and Analysis 
Center for Software) Web site: 
https://www.dacs.dtic.mil/techs/enhanced_life_cycles/

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

--

B.  Embedded No Longer Means Isolated

Before discounting a comparable threat to embedded systems, consider 
the following excerpt from Chapter seven of Exploiting Software [8] by Greg 
Hoglund and Gary McGraw: 

"For no valid technical reasons, people seem to believe that embedded 
systems are invulnerable to remote software-based attacks. One common 
misconception runs that because a device does not include an interactive shell 
out of the box, then accessing or using ‘shell code’ is not possible. This is 
probably why some people (wrongly) explain that the worst thing that an 
attacker can do to most embedded systems is merely to crash the device. The 
problem with this line of reasoning is that injected code is, in fact, capable 
of executing any set of instructions, including an entire shell program that 
encompasses and packages up for convenient use standard, supporting [operating 
system]-level functions. It does not matter that such code does not ship with 
the device. Clearly, this kind of code can simply be placed into the target 
during an attack. Just for the record, an attack of this sort may not need to 
insert a complete interactive TCP/IP shell. Instead, the attack might simply 
wipe out a configuration file or alter a password. 
There are any numbers of complex programs that can be inserted via a 
remote attack on an embedded system. Shell code is only one of them. Even the 
most esoteric of equipment can be reverse engineered, debugged, and played 
with. It does not really matter what processor or addressing scheme is being 
used, because all an attacker needs to do is to craft operational code for the 
target hardware. Common embedded hardware is (for the most part) well 
documented, and such documents are widely available." 

One of the most widely publicized successful attacks on an embedded 
system was the 2002 hack of the flash memory of the Microsoft XBox game cube in 
order to access the algorithm used by the game cube’s cryptosystem to decrypt 
and verify its bootloader. [9] 
Now consider how safety-critical embedded systems—from temperature 
controls to medical devices to on-board airplane and automotive computers and 
sensors—are increasingly becoming network-accessible. For example, embedded 
software in implanted medical devices is now accessible via radio frequency 
identification (RFID) interfaces. [10] And telemedicine applications in use by 
DoD enable software-controlled surgical robots located in U.S. military 
facilities in Iraq to be operated via satellite uplinks by doctors at the U.S. 
Navy Hospital in Bethesda, Maryland. [11] 
Consider General Motors’ OnStar and its less familiar rivals (Ford’s 
RESCU and VEMS, Volvo’s OnCall, BMW’s Assist, Mercedes-Benz’s TeleAid and 
COMAND). These services all include the ability of call center representatives 
to perform remote telematic diagnostics of the onboard computers in their 
subscribers’ vehicles. The data they collect via transmissions from the cars’ 
computers are returned to the remote call centers via cellular or satellite 
phone links. 
Remote monitoring and diagnosis of automotive computers sounds benign 
enough (though there are significant privacy concerns associated with some of 
the data being gathered by these services), but OnStar has gone a step beyond 
simple observation to actual remote control of at least one of the automobile’s 
safety-critical onboard computers: the one that controls its ignition. As USA 
Today reported in October 2007, [12] the 1.7 million General Motors 2009 
vehicles equipped with OnStar now allow their owners to grant permission for 
OnStar to cooperate with the police if their vehicles are stolen; specifically, 
if a police car is involved in a high-speed car chase with a stolen 
OnStar-enabled vehicle, the police can request that the stolen vehicle’s engine 
“be remotely switched off through the OnStar mobile communications system”. The 
objective of this police/OnStar cooperation is laudable: it allows the police 
to terminate car c

Re: [SC-L] embedded systems security analysis

[Jeremy Epstein]

I spent a fair bit of time doing stuff relating to voting systems,
which all have embedded systems.  (I am not one of the experts who
pulls them apart, lest anyone think I'm claiming credit for them.)
They are supposedly closed systems, but every time someone competent
has tried to attack them, they've been successful - even if there are
no published APIs or documents, all of them have attack surfaces.  It
might be something like the ability to insert a card in a PC slot (as
in the Princeton attack on Diebold touchscreen systems), a USB stick
(some of the UC Santa Barbara attacks - I think that was ES&S
touchscreen machines), Harri Hursti's attacks via a memory card on
Diebold optical scanners, Princeton's attacks via a proprietary memory
card on Sequoia systems, etc.  (There are others too - the machines in
my county use USB sticks and run Windows CE, so I believe they're
susceptible to even trivial attacks via an autorun.)  I also worked
with a team that did some attacks on another embedded system in a
voting machine, although we didn't get far enough to publish results
before we ran out of students to do the grunt work.

So I'd 1000% agree with Arian - not only is assuming you're safe
dangerous, but it's also wrong.

There's lots of attacks on other types of embedded systems - there
have been a few against electric power control systems, water control
systems, etc.  And there are more that haven't seen the light of
day I just heard about a very serious attack the other day that
hasn't ever made it into the news.

--Jeremy

On Thu, Aug 20, 2009 at 2:09 PM, Arian J.
Evans wrote:
> Rafael -- to clarify concretely:
>
> There are quite a few researchers that attack/exploit embedded
> systems. Some google searches will probably provide you with names.
>
> None of the folks I know of that actively work on exploiting embedded
> systems are on this listbut I figure if I know a handful of them
> in my small circle of software security folks - there have to be many
> more out there.
>
> Assuming you are safe is not just a dangerous assumption: but wrong.
>
> Specifically -
>
> One researcher I know pulls boards & system components apart and finds
> out who the source IC and component makers are.
>
> Then they contact the component and IC makers and pretends to be the
> board or system vendor who purchased the components, and asks for
> documentation, debuggers, magic access codes hidden in firmware (if he
> cannot reverse them).
>
> If this fails, the researcher has also befriended people at companies
> who do work with the IC or board maker, traded them information, in
> exchange for debuggers and the like.
>
> This particular researcher does not publish any of their research in
> this area. They do it mainly (I think) to help build better tools and
> as a hobby. (Several of you on this list probably know exactly whom
> I'm talking about. This person would prefer privacy, and I think the
> person's employer demands it, unless you get him in person and feed
> him enough beer.)
>
> If I were a bettin' man I'd figure if I know a few person doing this
> type of thing for quite a few years now -- there are bound to be many,
> many more
>
> Not sure what list to go to for talks on that type of thing.
> Blackhat.com has some older presentations on this subject.
>
> --
> Arian Evans
>
>
>
> On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruiz wrote:
>> Hi people,
>>
>> I am a lurker (I think), I am an embedded programmer and work at
>> Lowrance (a brand of the Navico company), and I don't think I can't
>> provide too much to security because embedded software is closed per se.
>> Or maybe I am wrong, is there a way to grab the source code from an
>> electronic equipment? That would be the only concern for embedded
>> programmers like me, but I just like to learn about the thinks you talk.
>>
>> Thank you.
>>
>> Greetings from Mexico.
>>
>> ___
>> 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.
> ___
>
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/

Re: [SC-L] What is the size of this list?

[Peter G. Neumann]

Let me amplify what Matt Bishop has said.
I tend to deal with TRUSTWORTHINESS, which encompasses
security, reliability, survivability, human safety, and anything
else that you have to trust whether you like it or not.
Security is only one aspect of it.  Long ago Butler Lampson
wrote a paper pointing out that if it is not secure, it won't
be reliable, and if it is not reliable, it is may not be secure.
That was applied to access controls in hardware, but it is equally
applied to SYSTEMS.  Also, all of those trustworthiness properties
tend to be emergent properties of the entire system/enterprise/whatever.
Beware of folks who tell you their crypto algorithm (for example) is
100% secure, and ignore that fact that if it badly implemented or the
keys are stored in an unsecure operating system, then all bets are off
and 100% secure becomes 0% secure.

end of soapbox, which some of you have heard from me before.

Peter
___
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] embedded systems security analysis

[Rafael Ruiz]

Thank you for all the info you guys have sent, it has been very
informative... :)

It is harder to steal the source (you need more electronical knowledge
and expensive debuggers and stuff) but it is possible... Do you guys
know some pages with security tips for embedded systems? 

___
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] What is the size of this list?

[Goertzel, Karen [USA]]

Interesting. My definition of "secure" is for software is "dependable, 
trustworthy, and survivable (or, if you prefer, resilient)", i.e., 

(1) It's got to behave correctly and predictably; 

(2) It's got to behave non-maliciously and also not be subvertible (i.e., no 
weaknesses that can be exploited as vulnerabilities); 

(3) When it comes under attack, 1 & 2 need to hold true for as long as possible 
before the software's execution gracefully degrades and ultimately fails; when 
it does fail, it must do so in a manner that doesn't make it, its data, or its 
resources vulnerable to further compromise, and it must recover to an 
acceptable level of operation (which, obviously, needs to be specified) as 
quickly as possible, with as little damage as possible (and having minimised 
the extent of that damage).

Obviously, there's very little software that can satisfy all three of these 
criteria 100%. But even 50% is better than 0%.

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

From: Peter G. Neumann [neum...@csl.sri.com]
Sent: Thursday, August 20, 2009 6:50 PM
To: Matt Bishop
Cc: Goertzel, Karen [USA]; Secure Coding List
Subject: Re: [SC-L] What is the size of this list?

Let me amplify what Matt Bishop has said.
I tend to deal with TRUSTWORTHINESS, which encompasses
security, reliability, survivability, human safety, and anything
else that you have to trust whether you like it or not.
Security is only one aspect of it.  Long ago Butler Lampson
wrote a paper pointing out that if it is not secure, it won't
be reliable, and if it is not reliable, it is may not be secure.
That was applied to access controls in hardware, but it is equally
applied to SYSTEMS.  Also, all of those trustworthiness properties
tend to be emergent properties of the entire system/enterprise/whatever.
Beware of folks who tell you their crypto algorithm (for example) is
100% secure, and ignore that fact that if it badly implemented or the
keys are stored in an unsecure operating system, then all bets are off
and 100% secure becomes 0% secure.

end of soapbox, which some of you have heard from me before.

Peter

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

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
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] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)

[Cassidy, Colin (GE Infra, Energy)]

Martin Gilje Jaatun wrote:
 
> Karen, Matt & all,
> 
> Goertzel, Karen [USA] wrote:
> > I'm more devious. I think what needs to happen is that we 
> need to redefine what we mean by "functionally correct" or 
> "quality" code. If determination of functional correctness 
> were extended from "must operate as specified under expected 
> conditions" to "must operate as specified under all 
> conditions", functional correctness would necessarily require 
> security, safety, fault tolerance, and all those other good 
> things that make software dependable instead of just correct.
> >   
> I couldn't agree more!
> 
> However, I have had several discussions with a colleague who is fairly
> well known in the"Software Process Improvement Mafia" on the topic of
> how to ensure that security requirements are considered for 
> _all_ kinds
> of code, not just "security software". Particularily in the context of
> agile development techniques, security keeps getting the short end of
> the stick, losing every time to "working features". His stance on this
> is that "if security were important to the customer, the 
> customer would
> provide and prioritize security requirements". To me, this is 
> a bit like
> saying "If the customer doesn't explicitly state that the software
> should be Y2k-proof, he/she is not really bothered about it".

The problem (certainly as I see it) is that the customer is likely to say
"Make it secure" without really understanding what that means.  Secure
against what exactly?

Or you'll get a list of security features that the customer wants, but as we
all know security features != secure product.

Instead we've taken a combined approach of including customer requirements
and adding specific requirements of our own focusing a good Secure
development practices.

> If we can "brainwash" the coming generations of programmers into
> accepting Karen's definition of "quality code", we might finally be
> getting somewhere.

And that's the trick we've been attempting here.  Secure software is nothing
more than really good quality code.  We already use coding guidelines and
have a strong(ish) process of code reviews.  So we have augmented our coding
and review guidelines to include secure coding aspect such as input/output
validation, good memory management etc. 

That said there is still a lot of scope for improvement in the rest of the
software development process (testing and design in particular).

CJC


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] embedded systems security analysis

[Goertzel, Karen [USA]]

We looked at the problem of voting system security specifically in the context 
of insider threat for last year's IATAC State of the Art Report on the Insider 
Threat to Information Systems - some of which involved "rogue" developers 
engineering backdoors into such systems. Unfortunately the document is limited 
distribution and FOUO, so I can't excerpt here. But if you're interested and a 
government employee or contractor, let me know and I'll get you instructions on 
how to register with DTIC to obtain a copy.

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 Jeremy Epstein [jeremy.j.epst...@gmail.com]
Sent: Thursday, August 20, 2009 5:39 PM
To: Arian J. Evans
Cc: Secure Coding List
Subject: Re: [SC-L] embedded systems security analysis

I spent a fair bit of time doing stuff relating to voting systems,
which all have embedded systems.  (I am not one of the experts who
pulls them apart, lest anyone think I'm claiming credit for them.)
They are supposedly closed systems, but every time someone competent
has tried to attack them, they've been successful - even if there are
no published APIs or documents, all of them have attack surfaces.  It...
___
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 think we need to start indoctrinating kids in the womb. Start selling Baby 
Schneier CDs alongside Baby Mozart. :)

Seriously, though, cyberspace is such an integral part of modern life, parents 
need to inculcate online security into their toddlers the same way they teach 
them to look both ways before crossing the street, and not to talk to or get 
into the car with strangers. In essence, we need to teach kids the virtual 
equivalents of these safe behaviours when they go online - which some of them 
are doing as early as age 4! If they can be "brainwashed" that early, they will 
come to have higher expectations of what SHOULD be present with regard to 
security properties in software-based systems. Then the notion won't seem alien 
to them. What will seem alien TO US is that they won't understand the struggles 
we've had to get people to start adding security. The idea of security having 
ever NOT been there will be bizarre to them.

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 Mike Lyman [mlyman-ci...@comcast.net]
Sent: Friday, August 21, 2009 8:17 AM
To: Secure Coding
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

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 programming is taught
___
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] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)

[Gary McGraw]

Actually CJC, it's often even worse than that.  In many cases, the customer or 
consumer has an implicit requirement for security that remains unstated.  Only 
when the system fails and is successfully attacked does that requirement shift 
from implicit to explicit.  "You mean it wasn't secure??  You've got to be 
kidding..."

In some sense that's what happened to Microsoft way back in the virus-bag days. 
 History shows that it is best to anticipate implicit requirements and address 
them as possible.

gem

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


On 8/21/09 8:40 AM, "Cassidy, Colin (GE Infra, Energy)"  
wrote:

Martin Gilje Jaatun wrote:

> Karen, Matt & all,
>
> Goertzel, Karen [USA] wrote:
> > I'm more devious. I think what needs to happen is that we
> need to redefine what we mean by "functionally correct" or
> "quality" code. If determination of functional correctness
> were extended from "must operate as specified under expected
> conditions" to "must operate as specified under all
> conditions", functional correctness would necessarily require
> security, safety, fault tolerance, and all those other good
> things that make software dependable instead of just correct.
> >
> I couldn't agree more!
>
> However, I have had several discussions with a colleague who is fairly
> well known in the"Software Process Improvement Mafia" on the topic of
> how to ensure that security requirements are considered for
> _all_ kinds
> of code, not just "security software". Particularily in the context of
> agile development techniques, security keeps getting the short end of
> the stick, losing every time to "working features". His stance on this
> is that "if security were important to the customer, the
> customer would
> provide and prioritize security requirements". To me, this is
> a bit like
> saying "If the customer doesn't explicitly state that the software
> should be Y2k-proof, he/she is not really bothered about it".

The problem (certainly as I see it) is that the customer is likely to say
"Make it secure" without really understanding what that means.  Secure
against what exactly?

Or you'll get a list of security features that the customer wants, but as we
all know security features != secure product.

Instead we've taken a combined approach of including customer requirements
and adding specific requirements of our own focusing a good Secure
development practices.

> If we can "brainwash" the coming generations of programmers into
> accepting Karen's definition of "quality code", we might finally be
> getting somewhere.

And that's the trick we've been attempting here.  Secure software is nothing
more than really good quality code.  We already use coding guidelines and
have a strong(ish) process of code reviews.  So we have augmented our coding
and review guidelines to include secure coding aspect such as input/output
validation, good memory management etc.

That said there is still a lot of scope for improvement in the rest of the
software development process (testing and design in particular).

CJC


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

[Rob Floodeen]

Gary wrote:
"He and I discuss the notion of education versus training at length"

And I don't want to bring up the discussion of the difference, however
it does get me to think.

In CS, we do a lot of Math, but programming is not like Math.  Math is
easy to verify if it is done correctly. But in programing what does
correctly mean?

So it has to be taught and incorporated in it's own way.

I think a way ahead should consider the following:
  1. the instructional staff reads all the code, all the time  (But
think of how long this would take)
  2. a formal method for deducting points from a properly working but
incorrectly constructed program (a "Show your work" secure coding
equivalent)
  3. a capability to verify and reinforce good practices consistently
and continually

Of course we can teach a class on best practices, things not to do,
etc. etc.  But how do we continually reinforce it throughout a
curriculum or even a career?

-Rob Floodeen




On Thu, Aug 20, 2009 at 2:55 PM, Gary McGraw wrote:
> hi neil,
>
> For what it's worth, there is a list of universities with some kind of 
> software security curriculum on page 98 of "Software Security" 
> .  Remember, this list was created in 2006, and lots of 
> other universities have jumped on the bandwagon since then.
>
> * University of California at Davis
> * University of Virginia
> * Johns Hopkins University
> * Princeton University
> * Purdue University (especially the CERIAS center)
> * Rice University
> * University of California at Berkeley
> * Stanford University
> * Naval Postgraduate School (a military school for graduates)
> * University of Idaho
> * Iowa State University
> * George Washington University
> * United States Military Academy at West Point
>
> Matt Bishop made some excellent points in this thread.  He and I discuss the 
> notion of education versus training at length in Silver Bullet episode 31 
>  part of which was transcribed 
> here .
>
> gem
>
> company www.cigital.com
> book www.swsec.com
>
>
> On 8/19/09 5:15 PM, "Neil Matatall"  wrote:
>
> Inspired by the "What is the size of this list?" discussion, I decided I 
> won't be a lurker :)
>
> A question prompted by 
> http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html 
> 
>  and the OWASP podcast mentions
>
> So where does secure coding belong in the curriculum?
>
> Higher Ed?  High School?
>
> Undergrad? Grad? Extension?
>
> I started a discussion in the Educause group on linked in.  I guess it 
> requires authentication and possibly group membership: 
> http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=138011&discussionID=5737656
>
> It looks like some Universities are offering courses now...
>
> Neil
>
>
> ___
> 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?

[Andy Steingruebl]

On Wed, Aug 19, 2009 at 2:15 PM, Neil Matatall wrote:
> Inspired by the "What is the size of this list?" discussion, I decided I
> won't be a lurker :)
>
> A question prompted by
> http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html
> and the OWASP podcast mentions
>
> So where does secure coding belong in the curriculum?
>
> Higher Ed?  High School?
>
> Undergrad? Grad? Extension?

Does it help at all to consider how and where most people actually
learn to program/develop?  I don't have percentages handy of how many
people with a job title or informal role as "programmer" or
"developer" actually took any formal education in this.  If we're just
trying to reach the group of developers that went through formal
training then we've seen some pretty good answers here in this thread
already. If we want to cover others though, we need to look elsewhere.

Let's look at another few fields where safety is important and yet the
work is often done by both professionals and amateurs - Plumbing
and/or Electrical Work.  My own view is that much software development
is actually a lot closer to the work of the amateur electrician than
the professional electrician.   That is, unlike fields like engineer,
architect, lawyer, accountant, we don't rely on professional
standards, degrees, certifications, etc. for most programmers.  I'm
leaving aside for a moment whether we can or should, and just pointing
out that it is the case.

In the case of the amateur electrician you'll find a wide variety in
their knowledge of safety concerns, adherence to code, etc.  They
probably know enough to not electrocute themselves while they are
working (though not always) but don't necessarily know enough to put
in wiring that won't burn their house down in a few years.

I think our real question isn't just how to reach the "professional"
programmer trained via formal training programs, but also how to reach
the "amateur" programmer trained via books, trial+error, etc.

In these cases the best bet is to make sure that the general training
manuals, how-to guides, etc. have a lot of safety/security information
included in them.  That the books people use to learn actually show
them safe examples, etc.  Obviously there are variations of code
requirements per location and such, but basic safety rules will
probably be mostly universal.

- Andy

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

[Gunnar Peterson]

I think we need to start indoctrinating kids in the womb. Start  
selling Baby Schneier CDs alongside Baby Mozart. :)




I can recommend this book, it was given to me by a client.

Enigma: A Magical Mystery

"Grade 3–6—Someone has stolen the props belonging to the residents of  
a retirement home for magicians, and Bertie Badger, the grandson of  
one of the illusionists, vows to find them. As he meets the  
performers, they each tell him a little about their specialty and  
what's missing. "My top hat, cape, and wand have gone, but there is  
worse to tell:/My precious magic bunny rabbit's disappeared as well!"  
Bertie discovers the thief, but it is left to readers to find the lost  
items hidden in the illustrations. Base's visual mystery books have  
delighted children for years, but this one has the added feature of a  
moving panel in the back cover that reveals a secret code. Children  
must turn dials to proper settings before it can be moved. The clues  
for setting them appear in the illustrations but are not at all  
obvious. With a little persistence, however, the target audience  
should be able to solve the puzzle. After readers crack the code, they  
can search for the missing items hidden in the art and decipher other  
messages found in the end matter. "


http://www.amazon.com/Enigma-Magical-Mystery-Graeme-Base/dp/081097245X

-gunnar
___
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] What is the size of this list?

[Brad Andrews]

I completely agree with your final statement Karen, but I see a lot  
more of the words aiming at the 100% mark and I think that is  
ultimately a bad focus since it is unachievable and therefore will  
waste focus and effort.


While on paper we can "prove" programs are bug free (security-related  
or not), it doesn't work in practice.  I may be biased by my  
experience, but you won't be able to design a perfect program anymore  
than you can design a "flawless" piece of handmade furniture.  Flaws  
happen.  They focus should be on minimizing them and reducing the risk  
that any flaws that make it through will cripple the end product,  
whether it be a wood table or a software program.


A recent CERT podcast implied that we could reach your 100% as we  
matured and that has just stuck in my craw.  I don't think it really  
is achievable, though making the case is going to take more than a  
quick reply on this list.


--

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


Quoting "Goertzel, Karen [USA]" :

Interesting. My definition of "secure" is for software is   
"dependable, trustworthy, and survivable (or, if you prefer,   
resilient)", i.e.,


(1) It's got to behave correctly and predictably;

(2) It's got to behave non-maliciously and also not be subvertible   
(i.e., no weaknesses that can be exploited as vulnerabilities);


(3) When it comes under attack, 1 & 2 need to hold true for as long   
as possible before the software's execution gracefully degrades and   
ultimately fails; when it does fail, it must do so in a manner that   
doesn't make it, its data, or its resources vulnerable to further   
compromise, and it must recover to an acceptable level of operation   
(which, obviously, needs to be specified) as quickly as possible,   
with as little damage as possible (and having minimised the extent   
of that damage).


Obviously, there's very little software that can satisfy all three   
of these criteria 100%. But even 50% is better than 0%.


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

Karen Goertzel wrote...

> I think we need to start indoctrinating kids in the womb. Start selling Baby 
> Schneier CDs alongside Baby Mozart. :)

Yeah, I can hardly wait to hear Schneier's remake of that Dr. Seuss children's 
classic

 One Fish, Twofish, Red Fish, Blowfish

-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://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]

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 :


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





___
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] Functional Correctness

[Brad Andrews]

I completely agree, though how are we really going to reach this  
point?  We have been talking about this at least since I got into  
development in the early 1980s.  We are not anywhere closer, though we  
have lots of neat tools that do lots of neat stuff.  Unfortunately,  
our programs are also a lot more complicated, making the "correct"  
proof much more difficult.


Can we really believe it is "just around the corner" to prove this?

--

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


Quoting "Cassidy, Colin (GE Infra, Energy)" :


Martin Gilje Jaatun wrote:


Karen, Matt & all,

Goertzel, Karen [USA] wrote:
> I'm more devious. I think what needs to happen is that we
need to redefine what we mean by "functionally correct" or
"quality" code.

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