On Mon, 14 Feb 2011, Ory Segal wrote:

The news isn't all bleak.  But, I think there are at least 3 main issues
at play right now:

1. As already mentioned, there is not enough engagement or education with
   the developer community. I agree that reaching out more to developers is a
   very important strategy.

2. We are not effectively translating security into actual impact on the
   business or mission.

3. Customers don't know how to ask for "more security."

To expand on point 3 a bit...

I believe that in the past, there wasn't enough consumer interest in
security to make it affect a software vendor's bottom line.  At this stage
though, there are enough large organizations who care about security to
consider putting it into contract language.

Now the problem is shifting to the question: how do you know how secure a
piece of software really is?  Consumers need help in knowing what to ask
for and how to ask for it.  "New" efforts like CWSS and Jeff Williams'
security facts label, combined with ongoing work such as DHS' assurance
cases, OWASP's secure contract annex, BSIMM, OWASP Top Ten, CWE Top 25,
etc. are all laying the groundwork that should ultimately make it easier
for customers to ask for more security.

There will probably be a bit of churn and controversy as assurance metrics
are developed, since we still don't have a quantitatively-defensible way
to say how well various techniques work for which security concerns,
especially while there are questionable rates of false positives and false
negatives.

My belief is that once software-assurance measurement starts to become
"usable" to consumers, there will be an increasing push toward security as
a requirement (or at least, a desired feature), which will then ultimately
impact the day-to-day developer.  We're getting there, though.

• Steve

On Sun, 13 Feb 2011, Michal Zalewski wrote:

I believe that software by many popular vendors/services is, in general,
more "objectively" secure than it was 10 years ago - in terms of having
fewer vulnerabilities, and a much smaller percentage of "obvious"
vulnerabilities that (generally) require more human effort to find.  Bug
bounties and Pwn2Own are symptoms of that.  But, maybe the day-to-day
threat has changed much more rapidly, and the attack surface is much
greater than it was 10 years ago.  So, the "operational" security may have
declined in that time.

Admittedly, we still regularly see brand-new software classes start off
with the same old security issues.  "Secure-by-design" has a longer way to
go than avoiding implementation bugs.

• Steve

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Having been a developer for 13yrs prior to working now in AppSec, I
couldn't have said it better.

Businesses (and even .gov), especially now, are trying to grow every
year more so than the last -- so the demands from higher management
(which are unfounded) are going to be about this goal more so than doing
it right -- the overall Security goal. Doing it right means longer
development and assessment times and this just does not seem to fit many
business models right now.

This is the very typical argument of Security v. Business Goals
ultimately. Thanks for point that out -- because it definitely needs to
be noted.

Mike Duncan
ISSO, Application Security Specialist
Government Contractor with STG, Inc.
NOAA :: National Climatic Data Center

On 02/13/2011 06:56 PM, steve jensen wrote:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ZRyAACgkQnvIkv6fg9ha0OQCgk/Jl5DKtGO6ZhP5v9ZqdaA3+
1ooAnRv+Wer6pp0MjpfGwJ6GeHZ2HQ9g
=xQ21
-----END PGP SIGNATURE-----

--On February 14, 2011 9:21:56 AM +0200 Ory Segal SEGALORY@il.ibm.com
wrote:

This is a human nature issue.  You can't solve human nature issues with
technology.

Most humans will choose the path of least resistance when confronted with
decision paths.  Look how long it took to get safety features into
automobiles.  Things we now take for granted (crush zones, air bags, safety
belts) were considered extraneous at first, then luxuries, until the death
toll rose to a level that people began demanding action.  Even now some
people will opt not to use a seat belt even though the evidence for doing
so is overwhelming and the cost of having them is built in to the product.

Software is no different.  It's a human endeavor.  Until the perceived cost
of not having security built in exceeds some comfort level (and who knows
what that might be?) not much will change.  There will be leaders and
innovators who are out front working for change, and they will be able to
sell their products to the security conscious buyers, but it will not be a
commodity until enough "bad" happens to force the "good".

Telling someone there are security holes in their product doesn't mean they
will fix them.  Until those holes incur a cost to them that they perceive
is higher than the cost of fixing them, they're not going to fix them
unless altruism comes into play.  It seldom does.

--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.

"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

--On February 14, 2011 1:19:41 PM -0500 "Vance, Michael"
Michael.Vance@salliemae.com wrote:

Absolutely....except...when it breaks the application in unexpected ways,
then the developer has to explain why he chose the path of input
verification over functionality when that wasn't in the specs he was given.

Recently we were asked to open some ports on our firewall so some folks
could engage in online multiplayer games.  When we asked why that was
needed, the answer we got from the game vendor was, "Other universities
have done it, and the game works."

Mind you, they want these ports opened to literally thousands of IP
addresses.  (They gave us a list of 12 networks in the /21 to /18 size.)

We said no.  You tell us what isn't working, and we'll find a way to get it
working without exposing ourselves to excessive risk.  Oh, and BTW, we can
telnet to every port they've asked for and get a banner, so the problem
isn't the ports they told us about anyway.  It's probably some port they
want to open without first getting a request from a client.

Ease of use will always trump security until someone puts their foot down
and says no.  When they do, they must be backed up by both facts and their
administration.

Making things work as expected in a secure environment is a non-trivial
exercise.  It requires a much clearer understanding of TCP/IP, networking,
routing, applications and protocols than many people have a grasp of.  It
also requires experience with the right tools used in the right ways to
track down actual causes and suggest solutions.

That's why it isn't often done.  It's hard.  Opening the firewall is easy.
The requestor is satisfied immediately, and there isn't that incredible
pressure to relent _just_this_one_time so someone can get done what they
want to do.  (It works at home,  Why doesn't it work here?)

These aren't easy problems to solve.  If they were, they would have been
solved already.  Arguing about whose fault it is is pointless and
non-productive.  Finding a way to blend security into technology until it
becomes an integral part is much more productive.

--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.

"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

I know there are a ton of replies but I'm going to get my 2 cents as
well...

It's likely the priority list would be different if John polled customers
<grin>.  Most large software customers with significant resources do not
take the claims of vendors in areas of security and performance at face
value.  These customers conduct their own security and performance
assessments.  Depending upon the results they may defer purchases if the
product does not, or cannot, meet their expectations.

The real challenge for security is visibility.  A product that is highly
secure presents the same user interface as one that is not.  It takes
significant resources and expertise to establish the security posture for
a perspective product -- to make the invisible, visible.  Such resources
are out of reach for most small to medium businesses and individuals.  All
product features being equal, it's likely most will pay a little more
money for product that is also secure.  After all, security does cost
money.

David Rice had an awesome presentation at OWASP AppSec 2010 in Irvine,
California.  He drives an analog between pollution and security and how
the world's tolerance for poor security is changing.  Security
professionals are the "tree huggers" of cyber space - I like that.  There
might be a YouTube version out there.

(ok, 3 cents)

Regards,
Milton

On 2/13/11 3:27 PM, "robert@webappsec.org" robert@webappsec.org wrote:

Hi Robert and WebSecurity!

Thanks for all the comments on the Security People vs Developers article.
I've read a lot of interesting perspectives on this list and the blog post
got 1200+ readers. Now we have to move forward.

Therefore we have started up the Developer Outreach Initiative. You can read
about my two proposed outreach projects here (and please comment!):
http://appsandsecurity.blogspot.com/2011/02/developer-outreach-initiative.html

Abbreviated:

Proposed Solution – Security Itches
My first proposition is this: Instead of pushing coding guidelines and
security tools onto developers I think we should start by asking them "What
are your security itches?". Whatever we get back will be our starting point.
Maybe we'll pick ten itches and publish good solutions.
What if they have the wrong itches? Well, the goal of the outreach is

1. to find out what developers think, and 2) address their itches to build
   some well-needed credibility. Before we have credibility we cannot push
   coding guidelines. And if developers think SSL certs are their primary
   problem that is important.

Proposed Solution – Open Test Data
Security people tell developers to "do input validation". Input validation
is no news to developers. The problem is defining the data model and testing
the input validation. We can do something important here – building
opentestdata.org. I own the domain and dream about the following beautiful
community effort:
You go to the site and can either "submit test data" or "download test
data". On the submission page you can anonymously enter a e.g. Portuguese
postal address, an Indian human name, a Swedish postal/zip code ... or 100
SQL injection strings. The effort is almost zero.
On the download page you choose your format and download in context. "We
have European customers so we want European human names, postal addresses,
and phone numbers". Developers will love it. And that's where we can start
promoting security testing!

Kind regards, John Wilander

2011/2/14 robert@webappsec.org

--
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
http://owaspsweden.blogspot.comCo-organizer Global Summit,
http://www.owasp.org/index.php/Summit_2011
http://www.owasp.org/index.php/Summit_2011Conf Comm,
http://www.owasp.org/index.php/Global_Conferences_Committee

This has been my main research project for the last couple years, with a
security focus.

The repo is at HTTP://fuzzdb.googlecode.com

There have been a lot of quality submissions, already, and it could always
use more!

Adam

On Feb 22, 2011 12:28 PM, robert@webappsec.org wrote:

testin=

"We

I tried to start something similar at www.qasec.com a couple years ago but
ended up removing
it as I couldn't dedicate the attention that it deserved. I think that
having a repository
of qa test cases (with and without a security focus) is something that is
sorely needed and would
go a long way. As is the case with any open project finding a
dedicated/qualified leader is the most
difficult aspect. If you're saying that you'll lead this effort then I'd be
willing to contribute some
sample plans.

Regards,

• Robert
  http://www.cgisecurity.com/
  http://www.webappsec.org/
  http://www.qasec.com/

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

I tried to start something similar at www.qasec.com a couple years ago but ended up removing
it as I couldn't dedicate the attention that it deserved. I think that having a repository
of qa test cases (with and without a security focus) is something that is sorely needed and would
go a long way. As is the case with any open project finding a dedicated/qualified leader is the most
difficult aspect. If you're saying that you'll lead this effort then I'd be willing to contribute some
sample plans.

Regards,

• Robert
  http://www.cgisecurity.com/
  http://www.webappsec.org/
  http://www.qasec.com/