Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25

[Johan Peeters]

> Steve I agree with you on this one.  Both input validation and output encoding
> are countermeasures to the same basic problem -- that some of the parts of
> your string of data may get treated as control structures instead of just as
> data.  For the purpose of this email I'm using a definition of "input

while I am being persuaded that you can use input validation and
output encoding interchangeably as countermeasures for *some* problems
documented here, there is another important dimension: enforcement of
business rules. In this domain, I do not see an alternative to input
validation.

kr,

Yo
-- 
Johan Peeters
http://johanpeeters.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] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors

[Chris Wysopal]

The only attention software security seems to get in the mainstream
press beyond the bug or attack of the day is from top X lists.  That
alone makes them worthwhile. They definitely steer the conversation in
the right direction. I think everyone involved in creating and promoting
top X lists believes they are a conversation starter and not an end game
for software security.  We just have to make sure the rest of software
security follows.

-Chris

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw
Sent: Tuesday, January 13, 2009 4:50 PM
To: Secure Code Mailing List
Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous
ProgrammingErrors

hi sc-l,

There are some important good things about top ten lists that are worthy
of mention.  The notion of knowing your enemy is essential in security
(as it is in warfare), and top ten lists can help get software people
started thinking about attacks, attackers, and the vulnerabilities they
go after. These days almost any attention paid to the problem is good
attention, and the fact that the the tech press is paying attention to
software security at all is a good thing.  Top ten lists help in that
respect.

But, I am really worried about these kinds of lists and I wrote up my
worries in an article that was just posted:
Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work
http://www.informit.com/articles/article.aspx?p=1322398

I thought you might get a kick out of it.

gem

http://www.cigital.com/~gem




___
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] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors

[Gary McGraw]

Hi Steve,

Thanks for your thoughtful response.  I do think the top-25 project moved 
things in the right direction (in particular with the idea of mitigations), but 
I still have worries.  BTW, sorry for the delay responding, I had band practice 
last night for my "Hot Club Millwood" (Django/Grappeli covers) concert Friday.

BTW, I do hope everyone will read the original article 
 in order to see the 
paragraphs explaining the sentences that Steve snipped here. Some particular 
responses to steve's concerns:
gem> Executives don't care about technical bugs
s> No, but they do what PCI says they have to (i.e. listen to the OWASP Top
s> Ten).  They do care about the bottom line.  They hate buying software and
s> finding out how crappy it is afterward.

Unfortunately security by compliance seems to be more of a problem than it is a 
justification for top ten lists.  In my view, PCI does not lead to secure 
software.

gem> Too much focus on bugs.
s> The Top 25 has 4 or 5 items that are clearly design-related

I acknowledge movement in the right direct here.  Question for sc-l...do we 
need a "top ten flaws" list?

gem> Using bug parade lists for training leads to awareness but does not 
educate.
s> Yep - which is why we want universities to get cracking, and if the Top 25
s> helps to prod them on, then so be it.

Good lord I hope that the CS curriculum does not embrace the bug parade.  I 
would rather have a crop of kids who know how C *actually works*, what a stack 
is, and how computers function!  Education prepares people for training...it 
does not supercede it.  Sadly, I have little faith that software security will 
work its way into the university curriculum in a meaningful way (and will be 
ecstatically psyched to be completely wrong).

gem> Top ten lists mix levels.
s> Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them?

Good question.  You tell me!  Hopefully it's better than the OWASP 10!  Once 
again, I think we need to ponder the difference between a taxonomy and a top-N 
list.

gem> Automated tools can find bugs---let them.
s> Yes, and a lesson of the Top 25 (that we all already know) is that when
s> people start to apply it, they'll see how a tool won't be a silver bullet.

A tool is so much superior to a list that I simply have say..huh?!

gem> When it comes to testing, security requirements are more important than 
vulnerability lists.
s> New York State has put up draft text that mentions the Top 25 as
s> part of a condition for acquisition.

In my view this is not a helpful development.

gem> Ten is not enough.
s> I'm of the mindset that the Top 25 is, short-term, an awareness tool for
s> developers and for customers.

Agreed.  I like it for that reason.

s>In the longer term, maybe it will be a little blip on the road to actionable 
software assurance.

This is my concern.

s> The Top 25 is a means to an end, and not the end itself.

Also agreed.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
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.
___

[SC-L] InternetNews Realtime IT News - New York Plans Application Security Program

[Kenneth Van Wyk]

Now here's an interesting development in the software security space.   
Seems that New York State is going to start requiring contracted  
application developers to conform with a minimum set of practices (as  
covered in the SANS "Application Security Procurement Language", http://www.sans.org/appseccontract/) 
.


http://www.internetnews.com/dev-news/article.php/3796091

IMHO, putting things like this into contract language is a good  
thing.  Even if the SANS list isn't the right one for everyone, it's a  
starting point.


Cheers,

Ken

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







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

[SC-L] Silver Bullet 34: Bill Brenner

[Gary McGraw]

hi sc-l,

Ever wonder what it's like to cover security from a media perspective?  Bill 
Brenner (once at TechTarget and now Sr Ed at CSOonline and CSO magazine) is my 
victim in the 34th Silver Bullet.

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

A bit less on software security this time, but plenty of data on getting 
executives to listen.

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] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors

[Steven M. Christey]

To all, I'll ask a more strategic question - assuming we're agreed that
the Top 25 is a non-optimal means to an end, what can the software
security community do better to raise awareness and see real-world change?

Gary and others who've broken into mainstream media - what aspects of your
message resonate with the everyday people, and what doesn't?

I personally feel that we need to do a better job of educating the general
consumer, not just the ones who hire consultants.

On Wed, 14 Jan 2009, Gary McGraw wrote:

> gem> Using bug parade lists for training leads to awareness but does not 
> educate.
> s> Yep - which is why we want universities to get cracking, and if the Top 25
> s> helps to prod them on, then so be it.
>
> Good lord I hope that the CS curriculum does not embrace the bug parade.

I think what I meant was, if there is more awareness that "hey, security
is a problem and this Top 25 thing can help fix it, and the authors are
saying that education needs to catch up" - then that may develop into
indirect pressure on universities to make changes.

> Sadly, I have little faith that software security will work its way into
> the university curriculum in a meaningful way (and will be ecstatically
> psyched to be completely wrong).

I'm not going to say I'm overly optimistic either, maybe it's too much
wishful thinking on my end.

One ray of hope is that a lot of the press has reflected our statements
that security is not part of the curriculum at most universities.  Much of
the press has also reflected the apparently-surprising fact that lots of
hacking is possible because programmers make errors with security
consequences.

> gem> Top ten lists mix levels.
> s> Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them?
>
> Good question.  You tell me!

I can't at this point - though I know it's not a clean mix.

> gem> Automated tools can find bugs---let them.
> s> Yes, and a lesson of the Top 25 (that we all already know) is that when
> s> people start to apply it, they'll see how a tool won't be a silver bullet.
>
> A tool is so much superior to a list that I simply have say..huh?!

Sorry, I should have been more specific.

1) to oversimplify, tools don't find design flaws, so people who rely
exclusively on tools for Top 25 compliance will realize that they're not a
silver bullet.  Or if they don't, maybe their auditors will.

2) tools generate so many results that it's hard to prioritize which bugs
to fix first.  Top 25 will provide consumers with one cut at that.

> gem> When it comes to testing, security requirements are more important
> than vulnerability lists.
>
> s> New York State has put up draft text that mentions the Top 25 as
> s> part of a condition for acquisition.
>
> In my view this is not a helpful development.

I encourage people to look at the New York State contract text.  The Top
25 is a relatively small part of it.

In that context, I'm viewing it as "something of substance [having been
reviewed by diverse people] that's better than nothing."

Have people on this list written or used contract language that translates
(somehow) into real software security?  If the Top 25 isn't the right
answer, then what is?

- Steve
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25

[Florian Weimer]

* Steven M. Christey:

>Yet smart people insist that it's still input validation, even
>when presented with the example I gave.  So So what's the
>perspective difference that's causing the disconnect?

Some technologies are designed as if to discourage proper output
encoding.  Most templating engines (native PHP, Perl variable
interpolation, JSP, Template::Toolkit, StringTemplate) discard the
distinction between literal strings in the template, and substitution
variables.  In many cases, there's little support for composing
reusable, parameterized templates from other templates, and you have
to fall back to the host language and plain string concatenation
instead to create such abstractions.  This means that it appears
rather costly to do proper output encoding, especially in legacy
systems.  And input encoding looks very easy to do (at least until you
discover more and more potential input paths).

But I suspect that the culture of input validation is partly
responsible for the difficulty of addressing cross-site scripting
issues. 8-(

(There's also a rather nasty potential explanation: input validation
sells web firewalls and related services, output encoding does not.)
___
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] Some Interesting Topics arising from the SANS/CWE Top 25

[Steven M. Christey]

On Tue, 13 Jan 2009, Greg Beeley wrote:

> Steve I agree with you on this one.  Both input validation and output
> encoding are countermeasures to the same basic problem -- that some of
> the parts of your string of data may get treated as control structures
> instead of just as data.

Note that I'm only talking about this in light of injection-related
issues.

Input validation is an important countermeasure for buffer overflows, for
example, whereas output encoding isn't.  (Unless you want to take the
approach that things like strncpy() or safe string libraries are really
related to controlling "output" when you process strings from an input
buffer to an output buffer, and shellcode is a means of "injection"...)


>  For the purpose of this email I'm using a definition of "input
> validation" as sanitizing/restricting data at its entry to a program,
> and "encoding" as the generation of any string in any format other than
> straight binary-safe data.

This touches on something that I've been a little concerned about, which
is the variety of definitions that people have for the same word.  We
struggle with that in CWE - which is why "output encoding/escaping" is in
the CWE name instead of, say, sanitization or validation.  I don't think
there's necessarily a solution [face it, we're not all going to adopt the
same terminology willingly], but it's a problem.

- Steve
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25

[Johan Peeters]

> What is a business rule? Something like "If the customer has changed
> the shipment address from a previous order, we must re-request his or
> her credit card details"?  How would you implement *that* using input
> validation?
>

The example I often use is 'equity can only be used as debt
collateral, if it has a rating' :-)
Before setting to work on your example, Florian, I would rephrase it
as 'the date of entry of the shipment address must not be after the
date of entry of credit card details'. I would then consider this an
input validation problem.

kr,

Yo
-- 
Johan Peeters
http://johanpeeters.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] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors

[Gary McGraw]

Hi Chris,

You certainly have a point.  There are occasional stories on software security 
that are not disaster coverage or top ten's, but not enough (sample from this 
set: http://www.cigital.com/~gem/press/).

gem

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


On 1/13/09 11:08 PM, "Chris Wysopal"  wrote:



The only attention software security seems to get in the mainstream
press beyond the bug or attack of the day is from top X lists.  That
alone makes them worthwhile. They definitely steer the conversation in
the right direction. I think everyone involved in creating and promoting
top X lists believes they are a conversation starter and not an end game
for software security.  We just have to make sure the rest of software
security follows.

-Chris

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw
Sent: Tuesday, January 13, 2009 4:50 PM
To: Secure Code Mailing List
Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous
ProgrammingErrors

hi sc-l,

There are some important good things about top ten lists that are worthy
of mention.  The notion of knowing your enemy is essential in security
(as it is in warfare), and top ten lists can help get software people
started thinking about attacks, attackers, and the vulnerabilities they
go after. These days almost any attention paid to the problem is good
attention, and the fact that the the tech press is paying attention to
software security at all is a good thing.  Top ten lists help in that
respect.

But, I am really worried about these kinds of lists and I wrote up my
worries in an article that was just posted:
Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work
http://www.informit.com/articles/article.aspx?p=1322398

I thought you might get a kick out of it.

gem

http://www.cigital.com/~gem




___
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] Some Interesting Topics arising from the SANS/CWE Top 25

[Florian Weimer]

* Johan Peeters:

> while I am being persuaded that you can use input validation and
> output encoding interchangeably

Interchangeably?  Hardly.

> as countermeasures for *some* problems documented here, there is
> another important dimension: enforcement of business rules. In this
> domain, I do not see an alternative to input validation.

What is a business rule? Something like "If the customer has changed
the shipment address from a previous order, we must re-request his or
her credit card details"?  How would you implement *that* using input
validation?
___
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] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors

[Stephen de Vries]

On Jan 14, 2009, at 8:45 PM, Steven M. Christey wrote:
>
> To all, I'll ask a more strategic question - assuming we're agreed  
> that
> the Top 25 is a non-optimal means to an end, what can the software
> security community do better to raise awareness and see real-world  
> change?

 From a Web Security point of view, have a look at the OWASP ASVS  
project: 
http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Abstract:
"Whereas the OWASP Top Ten is a tool that provides web application  
security awareness, the OWASP Application Security Verification  
Standard (ASVS) is a commercially-workable open standard that defines  
ranges in coverage and levels of rigor that can be used to perform  
application security verifications
...
The primary aim of the OWASP ASVS Project is to normalize the range in  
the coverage and level of rigor available in the market when it comes  
to performing application security verification using a commercially- 
workable open standard. This standard can be used to establish a level  
of confidence in the security of web applications."


regards,
Stephen

___
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] Some Interesting Topics arising from the SANS/CWE Top 25

[Ivan Ristic]

On Wed, Jan 14, 2009 at 12:41 AM, Greg Beeley  wrote:
> Steve I agree with you on this one.  Both input validation and output encoding
> are countermeasures to the same basic problem...

I'd like to offer a different view for your consideration, which is
that input validation and output encoding actually don't have anything
to do with security. Those techniques are essential software building
blocks. While it is true that omission to use these techniques often
causes security issues, that only means such programs are insecure in
addition to being defective. I think that it's inherently wrong to
associate input validation and output encoding with security. Fix the
defects and the security issues will go away. On the other hand, if
you only fix the security issues you may be left with a number of
defects on your hands.

Input validation layers should focus on accepting only valid data (per
business requirements), while code that transmits data across system
boundaries should focus on using the exchange and communication
protocols correctly.

Actually, now that I think about it more, I think we are struggling
with the term input validation because the term has been overloaded.
In the one sense, we are talking about validating user input, which
mostly needs to concern itself with adhering to business requirements.
This meaning is not very important for security, but the other one,
validating data before something is done with it, is. If you take a
web application for example, you would ideally verify that all user
submitted data adheres to your business requirements.

-- 
Ivan Ristic
___
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] SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors

[Gary McGraw]

Brian Chess, Sammy Migues and I continue to pound out the software assurance 
maturity model.  Expect more on that soon.   Working with a large real-world 
data set has really been amazing.

For those of you just getting wind of this, see:
http://www.informit.com/articles/article.aspx?p=1271382
http://www.informit.com/articles/article.aspx?p=1315431

No BS, just reality.

gem

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


On 1/14/09 5:18 PM, "Stephen de Vries"  wrote:



On Jan 14, 2009, at 8:45 PM, Steven M. Christey wrote:
>
> To all, I'll ask a more strategic question - assuming we're agreed
> that
> the Top 25 is a non-optimal means to an end, what can the software
> security community do better to raise awareness and see real-world
> change?

 From a Web Security point of view, have a look at the OWASP ASVS
project: 
http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Abstract:
"Whereas the OWASP Top Ten is a tool that provides web application
security awareness, the OWASP Application Security Verification
Standard (ASVS) is a commercially-workable open standard that defines
ranges in coverage and levels of rigor that can be used to perform
application security verifications
...
The primary aim of the OWASP ASVS Project is to normalize the range in
the coverage and level of rigor available in the market when it comes
to performing application security verification using a commercially-
workable open standard. This standard can be used to establish a level
of confidence in the security of web applications."


regards,
Stephen

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