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

[McGovern, James F (HTSC, IT)]

 Are there any industry metrics that indicate what percentage of
full-time software developers actually learned coding in a university
setting? I actually learned in high-school, focused on business
administration in college (easiest major on the planet) and
learned/matured on the job. Likewise, I also am surrounded by many folks
who have been in IT for say 30 or so years that learned coding from
those infomercial type schools you see on TV late at night. So, the
question of whether trade schools should teach secure coding should be
asked as well.

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

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

[McGovern, James F (HTSC, IT)]

There are several perspectives missing from the dialog:

- Before we even talk about secure coding, we need a course on secure
thinking. Most folks are indoctrinated into thinking positive which
blinds them from seeing vulnerabilities right in front of them. A prereq
on being antisocial might be a good start

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

- Taking this one step further, how can we convince professors who don't
teach secure coding to not accept insecure code from their students.
Professors seed the students thinking by accepting anything that barely
works at the last minute. Universities need to be consistent amongst
their own teaching/thinking.


This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited.  If you are 
not the intended recipient, please notify the sender immediately by return 
e-mail, delete this communication and destroy all copies.



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

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

[McGovern, James F (HTSC, IT)]

OK, do you really think the folks who pay our bills even understand the
difference between art and craftmanship? Imagine me building a house out
of 2x2 because I can save money on the 2x4s. If I can entertain (manage
perception) the clients such that they won't look (aka CIO) and can
distract the rogue inspector with some other finding (you always have to
let them find something) then I can frame your home and sheetrock it
before you even notice.
 
We are not craftsmen nor are customers willing to pay for it. For the
last 30 or so years, they have been taking our output regardless of
quality and using it. They are more happy with disclaimers and the
appearance of goodness than actual goodness. Enterprises might be
happier with a secure coding process that creates the appearance of
security than the actual heavy lifting of writing secure code. We live
in a world where everyone desires process to be a substitute for
competence.



From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Jim Manico
Sent: Tuesday, August 25, 2009 11:17 PM
To: Benjamin Tomhave
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?


> I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science


Keep your Picasso out of my coding shop, world of discrete mathematics
and predicate logic! I don't care how cheap his hourly is. :)


I'd prefer to think of coders as craftsman; we certainly are not
artists, scientists or engineers. ;) And craftsman are bound by the laws
of mathematics and the sponsors who pay us, artists have no bounds.

- Jim

On Aug 25, 2009, at 11:35 AM, Benjamin Tomhave
 wrote:



I again come back to James McGovern's suggestion, which is
treating
coding as an art rather than a science


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?

[McGovern, James F (HTSC, IT)]

Yet another perspective. I believe that this question may be somewhat
flawed as it doesn't take into consideration certain demographic
challenges. Right now the model seems to be based on either being
academic (sitting through a semester of some old fog with no real-world
experience blabbering theory) or in the professional world and their
ability to bring in consultants to perform in-house training (in a
highly constrained time crunch).

So, if you are an employee of a small software company, how do you learn
to write secure code? Academia hasn't yet adjusted to the modern world
of professionals where education needs to be a component in work/life
balance and not an impediment to it and therefore this isn't really an
option for the masses. Likewise, if you aren't employed by a large
enterprise with a training budget that can hire all these training firms
that want to do onsite classes for dozens of employees, you are left
with reading lots of books on your free time, a few OWASP TV videos and
google.

One of the more interesting experiences that I had was that a professor
at RPI uses one of the books I am the lead author for in his class. If I
wanted to be a guest lecturer, this would be no problem, yet if I wanted
to get credit for the course, I would actually have to sit through the
entire thing which would be as interesting as watching paint dry. I have
on several occasions made the offer that I will pay for all fees for a
given course upfront and I want to take the final exam. If I did not
score 100% you could fail me and still no university would take my
offer.

We got to find a balance between one-day train the world in corporate
America and months upon months of mind-numbling indoctrination that
universities push if we are to truly conquer the challenge of secure
coding.


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?

[McGovern, James F (HTSC, IT)]

 

We are NOT craftsmen by any stretch of the imagination. If you have ever
worked in a large enterprise, the ability to change roles and be fluid
in one's career is rewarding yet has unintended consequences.

If I went to my boss tomorrow and said that I no longer want to be an
architect and instead want some experience managing a project, what
training do you think I will be afforded before I actually get to
project manage a large initiative? For that matter I am an architect,
what training do you think I have received? 

Much of my daily job is art where all of about ten minutes requires
craftsmanship. We need to stop being delusional and thinking that us IT
folks are bound by ANY principle. If you find a single principle taught
in a university setting that hasn't been waived in a corporate
environment at one time or another, I sure would love to know what that
is.

We are artists. End of discussion...


From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On
Behalf Of Jim Manico [...@manico.net]
Sent: Tuesday, August 25, 2009 11:17 PM
To: Benjamin Tomhave
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

> I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science

Keep your Picasso out of my coding shop, world of discrete mathematics
and predicate logic! I don't care how cheap his hourly is. :)

I'd prefer to think of coders as craftsman; we certainly are not
artists, scientists or engineers. ;) And craftsman are bound by the laws
of mathematics and the sponsors who pay us, artists have no bounds.

- Jim


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

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] Another WAF in town

[McGovern, James F (HTSC, IT)]

Interesting approach. Curious to know if this will satisfy a PCI auditor
as a compensating control (section 6) 

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Thursday, September 24, 2009 12:03 PM
To: Secure Coding
Subject: [SC-L] Another WAF in town

FYI, some activity in the open source WAF space:

http://www.darkreading.com/security/app-security/showArticle.jhtml?artic
leID=220100630

Cheers,

Ken

-
Kenneth R. van Wyk
SC-L Moderator


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

[SC-L] Hiring folks that are familar with SC practices

[McGovern, James F (HTSC, IT)]

Title: Hiring folks that are familar with SC practices






Figured I would ask the list a question that I haven't figured out the answer to. How have other enterprises that seek architects and developers knowleedgable in secure coding software development practices articulated it to their internal HR recruiting arm? We have been seeking candidates with this background but haven't ran across much on our side of town.

James McGovern

Chief Security Architect

The Hartford

email: [EMAIL PROTECTED]




*
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] Comparing Scanning Tools

[McGovern, James F (HTSC, IT)]

The industry analyst take on tools tends to be slightly different than software 
practitioners at times. Curious if anyone has looked at Fortify and has formed 
any positive / negative / neutral opinions on this tool and others...


*
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] Secure Application Protocol Design

[McGovern, James F (HTSC, IT)]

Would love to see Gary address a couple of behaviors I have seen in my travel 
amongst architect types in corporate America especially the practice of secure 
application protocol design that isn't so secure. Is anyone writing/blogging 
deeply on this aspect?

Likewise, there are many folks in corporate America that have not yet 
acknowledged that they shouldn't be playing part-time cryptographer and don't 
have the competency to design cryptographic primitives such as hash functions 
and algorithms to protect data. Does anyone know of any "friendly" articles 
that speak to this problem space?


*
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

RE: [SC-L] Comparing Scanning Tools

[McGovern, James F (HTSC, IT)]

Thanks for the response. One of the things that I have been struggling to 
understand is not the importance of using such a tool as I believe they provide 
value but more of the fact that these tools may not be financial sustainable.

Many large enterprises nowadays outsource development to third parties. 
Likewise, the mindset in terms of budgeting tends to eschew "per developer 
seat" tool purchases. Nowadays, it is rare to find an enterprise not using free 
tools such as Eclipse and not paying for IDEs

I have yet to find a large enterprise that has made a significant investment in 
such tools. I wonder if budgets and the tools themselves are really causing 
more harm than helping in that enterprises will now think about trading off 
such tools vs the expense they cost.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 07, 2006 4:34 PM
To: McGovern, James F (HTSC, IT)
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Comparing Scanning Tools


| Date: Mon, 5 Jun 2006 16:50:17 -0400
| From: "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]>
| To: sc-l@securecoding.org
| Subject: [SC-L] Comparing Scanning Tools
| 
| The industry analyst take on tools tends to be slightly different than
| software practitioners at times. Curious if anyone has looked at Fortify
and
| has formed any positive / negative / neutral opinions on this tool and
| others...
We evaluated a couple of static code scanning tools internally.  The
following is an extract from an analysis I did.  I've deliberately
omitted comparisons - you want to know about Fortify, not how it
compares to other products (which raises a whole bunch of other
issues), and included the text below.  Standard disclaimers:  This
is not EMC's position, it's my personal take.

Caveats:  This analysis is based on a 3-hour vendor presentation.  The
presenter may have made mistakes, and I certainly don't claim that my
recall of what he said is error-free.  A later discussion with others
familiar with Fortify indicated that the experience we had is typical,
but is not necessarily the right way to evaluate the tool.  Effective
use of Fortify requires building a set of rules appropriate to a
particular environment, method of working, constraints, etc., etc. 
This takes significant time (6 months to a year) and effort, but
it was claimed that once you've put in the effort, Fortify is a
very good security scanner.  I am not in a position to evaluate that
claim myself.

BTW, one thing not called out below is that Fortify can be quite slow.
Our experience in testing was that a Fortify scan took about twice as
long as a C++ compile/link cycle, unless you add "data flow" analysis -
in which case the time is much, much larger.

The brief summary:  In my personal view, Fortify is a worthwhile tool,
but it would not be my first choice.  (Given the opportunity to choose
two tools, it would probably be my second.)  Others involved in the
evaluation reached the opposite conclusion, and rated Fortify first.

-- Jerry

Fortify


*
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

RE: [SC-L] Comparing Scanning Tools

[McGovern, James F (HTSC, IT)]

Several thoughts:

1. I love it when industry analysts are perceived as being credible by throwing 
out financial costs for things they really don't have visibility into.

2. The VA lost data not do secure coding techniques but an employee not 
following the rules on what data to take out of the building.

3. No industry analyst has ever attempted to quantify cost vs benefit of secure 
coding when compared to other constraints. The quantification to date has only 
been the cliche: it is cheaper to fix X earlier in the lifecycle rather than 
later in which X could be pretty much any system quality. 



-Original Message-
From: Gunnar Peterson [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 08, 2006 9:28 AM
To: McGovern, James F (HTSC, IT)
Cc: Secure Mailing List
Subject: Re: [SC-L] Comparing Scanning Tools


Hi James,

I think you are right to look at it as economic issue, but the other factor
to add into your model is not just the short term impact to developer
productivity (which is non-trivial), but also the long term effects of
making decisions *not* to deal with finding bugs.

"Cleaning up data breach costs more than encryption

Protecting customer records is a much less expensive than paying for
cleanup after a data breach or massive records loss, research company
Gartner said. Gartner analyst Avivah Litan testified on identity theft
at a Senate hearing held after the Department of Veterans Affairs lost
26.5 million vet identities. "A company with at least 10,000 accounts to
protect can spend, in the first year, as little as $6 per customer
account for just data encryption, or as much as $16 per customer account
for data encryption, host-based intrusion prevention, and strong
security audits combined," Litan said. "Compare [that] with an
expenditure of at least $90 per customer account when data is
compromised or exposed during a breach," she added. Litan recommended
encryption as the first step enterprises and government agencies should
take to protect customer/citizen data. If that's not feasible,
organizations should deploy host-based intrusion prevention systems, she
said, and/or conduct security audits to validate that the company or
agency has satisfactory controls in place."
http://www.techweb.com/wire/security/188702019

Or, Brian Chess once pointed out:
" My favorite historical analogy this month is from medicine: it took
*decades* between the time that researchers knew that fewer people died if
surgeons washed their hands and the time that antisepsis was common in the
medical community.  That lag was entirely due to social factors: if it's
1840 you've been successfully practicing medicine for decades, why would you
want to change your routine?  And yet imagine a modern day surgeon who says
"I'm really busy today, so I'm going to save time by not scrubbing in before
I start the operation."  It's simply unthinkable.  Hopefully software
development is headed in the same direction, but on an accelerated
timetable."

-gp


*
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

RE: [SC-L] RE: Comparing Scanning Tools

[McGovern, James F (HTSC, IT)]

Title: Re: [SC-L] RE: Comparing Scanning Tools



I 
think I should have been more specific in my first post. I should have phrased 
it as I have yet to find a large enterprise whose primary business isn't 
software or technology that has made a significant investment in such 
tools.
 
Likewise, a lot of large enteprrises are shifting away 
from building inhouse to either outsourcing and/or buying which means that secure coding practices should also be enforced via procurement agreements. Has 
anyone here ran across contract clauses that assist in this 
regard?

  -Original Message-From: Gunnar Peterson 
  [mailto:[EMAIL PROTECTED]Sent: Friday, June 09, 2006 8:48 
  AMTo: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, 
  IT)Subject: Re: [SC-L] RE: Comparing Scanning 
  ToolsRight, because their customers (are starting to) 
  demand more secure code from their technology. In the enterprise space the 
  financial, insurance, healthcare companies who routinely lose their customer’s 
  data and provide their customers with vulnerability-laden apps have not yet 
  seen the same amount of customer demand for this, but 84 million public lost 
  records later ( http://www.privacyrights.org/ar/ChronDataBreaches.htm) 
  this may begin to change.-gpOn 6/9/06 1:45 AM, "Brian   Chess" <[EMAIL PROTECTED]> wrote:
  McGovern, James F wrote:> I have yet to 
find a large enterprise that has made a significant investment in such tools. I’ll give you pointers to two.  They’re two of the three 
largest software companies in the world.http://news.com.com/2100-1002_3-5220488.htmlhttp://news.zdnet.com/2100-3513_22-6002747.htmlBrian

___Secure 
Coding mailing list (SC-L)SC-L@securecoding.orgList information, 
subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList 
charter available at - http://www.securecoding.org/list/charter.php

*
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] Compilers

[McGovern, James F (HTSC, IT)]

I have been noodling the problem space of secure coding after attending a 
wonderful class taught by Ken Van Wyk. I have been casually checking out 
Fortify, Ounce Labs, etc and have a thought that this stuff should really be 
part of the compiler and not a standalone product. Understanding that folks do 
start companies to make up deficiencies in what large vendors ignore, how far 
off base in my thinking am I?


*
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] Compilers

[McGovern, James F (HTSC, IT)]

Gunnar, I think the problem space of secure coding will never be pervasively 
solved if it relies on the licensing of tools for every developer on the 
planet. Folks have been conditioned to not pay for developer level tools and 
now use Eclipse, etc. Putting it only in the hands of a few folks may be useful 
or it may be futile, only time will tell.
 
In terms of your analogy of using try/catch blocks, I would say the following: 
First, languages within the last ten years require you to use them and they are 
not optional for the developer to skip in many situations. Second, compilers 
actually check try/catch blocks which says that compilers can and do play an 
important role which the community should leverage vs avoid.
 
This does beg another question of should the community be helping the folks who 
design languages to build in security-oriented constructs that we can leverage 
instead of waiting for after-the-fact find-it utilities?
 
 

-Original Message-
From: Gunnar Peterson [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 10:55 AM
To: McGovern, James F (HTSC, IT); Secure Mailing List
Subject: Re: [SC-L] Compilers


Sure it should be built into the language, and I assume it will be eventually. 
Heck it only took 30 or 40 years for people to force developers to use 
Try...Catch blocks. 

-gp


On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote:



I have been noodling the problem space of secure coding after attending a 
wonderful class taught by Ken Van Wyk. I have been casually checking out 
Fortify, Ounce Labs, etc and have a thought that this stuff should really be 
part of the compiler and not a standalone product. Understanding that folks do 
start companies to make up deficiencies in what large vendors ignore, how far 
off base in my thinking am I?


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





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

[McGovern, James F (HTSC, IT)]

I think my perspective is not just about overlap in terms of an abstract syntax 
tree but more in terms of usability. Security warnings should appear inline 
with other types of warnings from a developers perspective. When the 
information is presented separately, it will be an opportunity to ignore. It is 
harder to ignore compiler output.
 
Likewise, one of the lifecycle oriented things I have seen in several shops is 
that source code gets moved through environments and gets recompiled. So if I 
check in code to the integration environment, the build "tool" will extract and 
compile. Likewise, when code gets promoted to say QA environment, the code is 
extracted again and recompiled. This allows for build tools that emit metrics 
and track warnings in a centralized place to take advantage of security 
considerations as well.
 
Of course, some shops when they promote code move binaries which invalidates 
the above.

-Original Message-
From: Temin, Aaron L. [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 1:38 PM
To: McGovern, James F (HTSC, IT); Secure Coding
Subject: RE: [SC-L] Compilers


It would be worth knowing more about the basis you use for drawing the 
conclusion, but if it's just the overlap between compilers and static analyzers 
represented by the abstract syntax tree, I don't think that's enough to warrant 
building one into the other (it might argue for having a shared parser, but I 
don't think parsers are hard enough to build to make that worthwhile).  I would 
also suggest that looking for security weaknesses fits more into the unit 
testing part of development rather than the compiling part.  As for 
"standalone," I think Jtest is built as an Eclipse plug-in; I don't know if 
you'd consider that standalone or not, but at least the developer doens't have 
to start up another shell to run it.
 
Also, depending on the customer's organization, it might not be the developer 
who is running the security static analysis.  I was talking with an 
organization that was thinking of having the security group run the static 
analysis, as part of the acceptance phase of an iteration.
 
- Aaron


  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James 
F (HTSC, IT)
Sent: Thursday, December 21, 2006 10:31 AM
To: Secure Coding
Subject: [SC-L] Compilers


I have been noodling the problem space of secure coding after attending a 
wonderful class taught by Ken Van Wyk. I have been casually checking out 
Fortify, Ounce Labs, etc and have a thought that this stuff should really be 
part of the compiler and not a standalone product. Understanding that folks do 
start companies to make up deficiencies in what large vendors ignore, how far 
off base in my thinking am I?


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

[SC-L] Building Security In vs Auditing

[McGovern, James F (HTSC, IT)]

I read a recent press release in which a security vendor (names removed to both 
protect the innocent along with the fact that it doesn't matter for this 
discussion ) partnered with a prominent outsourcing firm. The press release was 
carefully worded but if you read into what wasn't said, it was in my opinion 
encouraging something that folks here tend to fight against. The outsourcing 
firm would use this tool in an auditing capacity for whatever client asked for 
another service but it would not become part of the general software 
development lifecycle for all projects. 

- It didn't mention any notion of all developers within the outsourcing firm 
having tools on their desktop to audit as they develop

- It didn't mention any notion of training all developers within the 
outsourcing firm on secure coding practices

- It did hint that one time periodic audits from a metrics perspective would be 
useful to clients that wanted this new service but didn't say how developers 
would be able to iterate on the code and reduce bugs. I would think that any 
offering that removes developers from the feedback loop while developing code 
and instead focusing on management-oriented (non-developer metrics) is 
generally a bad idea.

- It didn't mention even how many folks from their security practice were to 
receive training in secure coding practices

- Should we think of security as an extra "service" or something that should be 
incorporated into the SDLC in a consistent sustainable manner?


I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his 
wonderful training course by thinking that this type of initiative does more 
harm than good?


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

[SC-L] Hiring Security Architects

[McGovern, James F (HTSC, IT)]

We have had open job postings for security architects for a long time with zero 
hits and I would love to understand how other enterprises are hiring 
practitioners. Would love your thoughts on the following:

*   Are large enterprises sticking with consulting firms to gain expertise 
in implementing secure coding practices when they can't find full-time salaried 
individuals? 
*   Any thoughts on the capabilities of large consulting firms such as 
Accenture, Cognizant, DiamondCluster or TCS in terms of secure coding practices 
or is this still in the domain of "boutique" firms?
*   Has anyone ran across a job posting from any large Fortune 100 
enterprise for a security architect / engineer that was particularly good that 
I should consider plaigarizing?
*   Maybe the miss is in terms of compensation. What should an enterprise 
expect to pay in the marketplace for someone truly knowledgable in secure 
coding practices?
*   If I wanted to get a college graduate and allow them to grow into this 
position, are their particular universities that have received generous 
donations of static code analysis software so as to "educate" a younger 
workforce? If not, what would it take for us to collectively "ask" some of the 
vendors in this space to do so?


*
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] Building Security In vs Auditing

[McGovern, James F (HTSC, IT)]

Gary, I would love a little refinement of the benefits to badnessometers. Let's 
say I get a tool to tell me something I already suspect is wrong, what 
percentage of the population are better than they expected? The reason why I 
ask this question is that in our culture if I have a sense something is wrong, 
it usually isn't that difficult to find metrics as to why it is bad and 
therefore may have the perception of crying wolf as there are lots of bad 
things in all IT systems. Sometimes, going from good to great is a better 
approach than fixing bad and going to good.

Is it better to do such a badness test by doing a POC with one of the tool 
vendors in this space or do I get additional lift by going with a consulting 
firm in this regard (other than an opportunity to be smoozed regarding 
subsequent engagements and reused powerpoints and collateral from other gigs)?

What would it take to get some industry analyst coverage in this space? Lots of 
folks may be of the belief that it is a waste of time bothering but I would 
love to at least know if any of the firms here have at least made the effort.

-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 1:35 PM
To: McGovern, James F (HTSC, IT); sc-l@securecoding.org
Subject: RE: [SC-L] Building Security In vs Auditing


Hi all,

Very good questions.  

I think a service like the one you describe would be useful mostly as a way of 
identifying the depth of the problem.  Simply wielding a tool as a consultant 
does nothing to train the guys creating bugs not to do so in the future...and 
so the market will correct that over time in an efficient way.  But the fact 
remains that many potential customers and users of static analysis tools have 
no idea how much of a mess they have.  An outsourcing approach could help with 
that.  They'll find out they need em.

I believe so strongly in the "do anything to get started" thing that I also 
endorse the use of (really amazingly silly) application security testing tools. 
 I call these badnessometers (see chapter 1 of "software security"...and ken's 
slides for that matter).  But knowing that your web code sucks is better than 
remaining completely clueless.

In the end, tool integration *into dev* is the key to success with static 
analysis.  Many of our customers are having huge enterprise-wide success 
because they are learning to use, feed, tune, and train dev about these tools.  
The best are recycling the things they learn about their code back into 
training (and into better rules to enforce).

gem

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



*
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] Building Security In vs Auditing

[McGovern, James F (HTSC, IT)]

Thanks for your response but I am not sure that it got at the essence of my 
thinking, so let me ask some additional questions.

1. I haven't gotten a sense that a bakeoff matters. For example, if I wanted to 
write a simple JSP application, it really doesn't matter if I use Tomcat, 
Jetty, Resin or BEA from a functionality perspective while they may each have 
stuff that others don't, at the end of the day they are all good enough. So is 
there really that much difference in comparing say Fortify to OunceLabs or 
whatever other tools in this space exist vs simply choosing which ever one 
wants to cut me the best deal (e.g. site license for $99 a year :-) ?

2. Continuing with your plumber analogy, usually you either are referred by 
someone who had a particular experience with a vendor or you simply choose 
whoever is available from the Yellow Pages that will show up when you want them 
to and will charge what you think the best value is. My circle doesn't include 
the first and I would like to become smarter about the second in that should I 
choose someone knowledgable from Accenture, TCS, Cognizant or other firms I am 
familiar with or would I be doing myself a huge disservice and should instead 
focus on a boutique.

-Original Message-
From: Paco Hope [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 9:33 AM
To: McGovern, James F (HTSC, IT); sc-l@securecoding.org
Subject: RE: [SC-L] Building Security In vs Auditing


> Gary, I would love a little refinement of the benefits to badnessometers.
> Let's say I get a tool to tell me something I already suspect is wrong,
> what percentage of the population are better than they expected?

I won't speak for Gary, but working a few doors down I have seen a few of the 
same things he has.

Occasionally developers internally run free tools and surrepetitiously fix 
problems that the tools find (this happens in some cultures where management is 
particularly antagonistic towards security as a first class concern). In those 
unusual instances, I could see the results of a badnessometer coming out better 
than expected. Management would perceive that such things had never been run, 
and would be pleasantly surprised to learn that the sky might not be falling. 
Other than that, few people run a tool for the first time and see results 
better than they expected. Tools codify all manner of stuff that your 
developers almost certainly do not know how to check for (and if they do, they 
probably don't have time).

> Is it better to do such a badness test by doing a POC with one of the
> tool vendors in this space or do I get additional lift by going with
> a consulting firm in this regard?

I'm a consultant, take that as implied bias. But, I think you do get lift, and 
here's my analogy. Consider yourself a handy guy around the house who is going 
to do something moderately complicated, like redo a whole bathroom. You can buy 
all the tools and read all the books on how to do it for a lot less money than 
hiring a contractor to do the whole thing.  There's some pretty specialized 
tools in plumbing, though, and they're tools you probably haven't used more 
than once or twice. Do you gain some extra insight into the use of those tools 
by hiring someone experienced to assist on the complicated parts? I think so. 
That someone experienced will come in, help you wield the unfamiliar tool, show 
you some things that he has experienced, and get you through the difficult 
parts. Then you, being the handy guy you are, are left to finish the bathroom, 
doing things you know how to do well.

I think this analogy holds with a lot of the tools in security. You learn a lot 
by getting the experience someone brings, assuming you get a good someone. We, 
for example, have run a bunch of tools on a lot of different code bases. We 
know which rules tend to be alarmist and which ones are really important if 
they fire. Tool vendors won't give you that objectivity on their own tool, and 
some of the sales engineers don't have the insight into their own tool to know 
which warnings are just noise and which warnings are a big deal. A consultant 
can help you have a bake-off between tools, whereas a tool vendor typically 
lacks that objectivity.

Paco




This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of

[SC-L] Magazines

[McGovern, James F (HTSC, IT)]

I learned through the grapevine that folks from Network Computing will be doing 
an upcoming article and comparison of tools in the secure coding space. If you 
are a vendor, it would be wise to make sure your marketing folks are 
participating. The funny thing is that I wouldn't expect it to appear in such a 
publication. Having in the past written for Java Developers Journal, I wouldn't 
be against pitching the writing of a similar story if vendors here would be 
game as well.


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

[SC-L] Information Protection Policies

[McGovern, James F (HTSC, IT)]

Hopefully lots of the consultants on this list have been wildly successful in 
getting Fortune enterprises to embrace secure coding practices. I am curious to 
learn of those who have also been successful in getting these same Fortune 
enterprises to incorporate the notion of secure coding practices into an 
information protection policy and whether there are any publicly available 
examples.


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

[SC-L] What defines an InfoSec Professional?

[McGovern, James F (HTSC, IT)]

If you have two individuals, one of which has been practicing secure coding 
practices and encouraging others to do so for years while another individual 
was involved with firewalls, intrusion detection, information security policies 
and so on, are they both information security professionals or just the later?


*
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] What defines an InfoSec Professional?

[McGovern, James F (HTSC, IT)]

Traditionally InfoSec folks defined themselves as being knowledgable in 
firewalls, policies, etc. Lately, many enterprises are starting to recognize 
the importance of security within the software development lifecycle where even 
some have acknowledged that software is a common problem space for those things 
traditionally thought of as infrastructure. 

The harder part is not in terms of recognizing the trend but in terms of folks 
from the old world acknowledging folks from the new world (software 
development) also as security professionals. I haven't seen many folks make 
this transition. I do suspect that some of it is tied to the romance of 
certifications such as CISSP whereby the exams that prove you are a security 
professional talk all about physical security and network security but really 
don't address software development in any meaningful way.

Would be intriguing for folks here that blog to discuss ways for folks to 
transition / acknowledge respect not as just software developers with a 
specialization in security but in being true security professionals and treat 
them like peers all working on one common goal.

-Original Message-
From: Shea, Brian A [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 2:07 PM
To: Gunnar Peterson; McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: RE: [SC-L] What defines an InfoSec Professional?


The right answer is both IMO.  You need the thinkers, integrators, and
operators to do it right.  The term Security Professional at its basic
level simply denotes someone who works to make things secure.

You can't be secure with only application security any more than you can
be secure with only firewalls or NIDs.  The entire ecosystem and
lifecycle must be risk managed and that is accomplished by security
professionals.  Each professional may have a specialty due to the
breadth of topics covered by Security (let's not forget our Physical
Security either), but all would be expected to act as professionals.
Professionals in this definition being people who are certified and
expected to operate within specified standards of quality and behavior
much like CISSP, CPA, MD, etc.


*
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] Information Protection Policies

[McGovern, James F (HTSC, IT)]

Ken, in terms of a previous response to your posting in terms of getting 
customers to ask for secure coding practices from vendors, wouldn't it start 
with figuring out how they could simply cut-and-paste InfoSec policies into 
their own?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of McGovern, James F
(HTSC, IT)
Sent: Thursday, March 08, 2007 11:17 AM
To: SC-L@securecoding.org
Subject: [SC-L] Information Protection Policies


Hopefully lots of the consultants on this list have been wildly successful in 
getting Fortune enterprises to embrace secure coding practices. I am curious to 
learn of those who have also been successful in getting these same Fortune 
enterprises to incorporate the notion of secure coding practices into an 
information protection policy and whether there are any publicly available 
examples.


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

[SC-L] How is secure coding sold within enterprises?

[McGovern, James F (HTSC, IT)]

I am attempting to figure out how other Fortune enterprises have went about 
selling the need for secure coding practices and can't seem to find the answer 
I seek. Essentially, I have discovered that one of a few scenarios exist (a) 
the leadership chain was highly technical and intuitively understood the need 
(b) the primary business model of the enterprise is either banking, 
investments, etc where the risk is perceived higher if it is not performed (c) 
it was strongly encouraged by a member of a very large consulting firm (e.g. 
McKinsey, Accenture, etc).
 
I would like to understand what does the Powerpoint deck that employees of 
Fortune enterprises use to sell the concept PRIOR to bringing in consultants 
and vendors to help them fulfill the need. Has anyone ran across any PPT that 
best outlines this for demographics where the need is real but considered less 
important than other intiatives?


*
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] How is secure coding sold within enterprises?

[McGovern, James F (HTSC, IT)]

I agree with your assessment of how things are sold at a high-level but still 
struggling in that it takes more than just graphicalizing of your points to 
sell, hence I am still attempting to figure out a way to get my hands on some 
PPT that are used internal to enterprises prior to consulting engagements and I 
think a better answer will emerge. PPT may provide a sense of budget, 
timelines, roles and responsibilities, who needed to buy-in, industry metrics, 
quotes from noted industry analysts, etc that will help shortcut my own work so 
I can start moving towards the more important stuff.

-Original Message-
From: Andrew van der Stock [mailto:[EMAIL PROTECTED]
Sent: Monday, March 19, 2007 2:50 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


There are two major methods:



1.  Opportunity cost / competitive advantage (the Microsoft model) 

2.  Recovery cost reductions (the model used by most financial institutions)



Generally, opportunity cost is where an organization can further its goals by a 
secure business foundation. This requires the CIO/CSO to be able to sell the 
business on this model, which is hard when it is clear that many businesses 
have been founded on insecure foundations and do quite well nonetheless. 
Companies that choose to be secure have a competitive advantage, an advantage 
that will increase over time and will win conquest customers. For example (and 
this is my humble opinion), Oracle's security is a long standing unbreakable 
joke, and in the meantime MS ploughed billions into fixing their tattered 
reputation by making it a competitive advantage, and thus making their market 
dominance nearly complete. Oracle is now paying for their CSO's mistake in not 
understanding this model earlier. Forward looking financial institutions are 
now using this model, such as my old bank's (with its SMS transaction 
authentication feature) winning many new customers by not only promoting 
themselves as secure, but doing the right thing and investing in essentially 
eliminating Internet Banking fraud. It saves them money, and it works well for 
customers. This is the best model, but the hardest to sell.

The second model is used by most financial institutions. They are mature risk 
managers and understand that a certain level of risk must be taken in return 
for doing business. By choosing to invest some of the potential or known losses 
in reducing the potential for massive losses, they can reduce the overall risk 
present in the corporate risk register, which plays well to shareholders. For 
example, if you invest $1m in securing a cheque clearance process worth (say) 
$10b annually to the business, and that reduces check fraud by $5m per year and 
eliminates $2m of unnecessary overhead every year, security is an easy sell 
with obvious targets to improve profitability. A well managed operational risk 
group will easily identify the riskiest aspects of a mature company's 
activities, and it's easy to justify improvements in those areas. 

The FUD model (used by many vendors - "do this or the SOX boogeyman will get 
you") does not work.

The do nothing model (used by nearly everyone who doesn't fall into the first 
two categories) works for a time, but can spectacularly end a business. Card 
Systems anyone? Unknown risk is too risky a proposition, and is plain director 
negligence in my view. 

Thanks,
Andrew 


On 3/19/07 11:35 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote:



I am attempting to figure out how other Fortune enterprises have went about 
selling the need for secure coding practices and can't seem to find the answer 
I seek. Essentially, I have discovered that one of a few scenarios exist (a) 
the leadership chain was highly technical and intuitively understood the need 
(b) the primary business model of the enterprise is either banking, 
investments, etc where the risk is perceived higher if it is not performed (c) 
it was strongly encouraged by a member of a very large consulting firm (e.g. 
McKinsey, Accenture, etc).

I would like to understand what does the Powerpoint deck that employees of 
Fortune enterprises use to sell the concept PRIOR to bringing in consultants 
and vendors to help them fulfill the need. Has anyone ran across any PPT that 
best outlines this for demographics where the need is real but considered less 
important than other intiatives?


*
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 re

Re: [SC-L] How is secure coding sold within enterprises?

[McGovern, James F (HTSC, IT)]

Thanks for the response. I already own the book and understand how to engage 
vendors. Where I am seeking assistance is all the work that goes on within a 
large enterprise before these two things occur. The ideal situation for me 
would be to get my hands on the five to ten page Powerpoint slide deck that 
others who have blazed this path before me have used to sell the notion to 
their executives.

-Original Message-
From: Andrew van der Stock [mailto:[EMAIL PROTECTED]
Sent: Monday, March 19, 2007 5:06 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


In terms of creating a SDLC, pop out to Borders and get Howard and Lipner's 
"The Security Development Lifecycle" ISBN 9780735622142

http://www.microsoft.com/mspress/books/8753.aspx

It is simply the best text I've read in a long time. 

You may be interested in the work Mark Curphey et al is doing at his new start 
up. They launched an ISM portal a couple of weeks back. 

http://www.ism-community.org/

If you're just after ideas on how to engage vendors, check out Curphey's blog 
for some nice insider posts:

http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application-pen-testers/
http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-reviewers/
http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-security-folks/

He ran Foundstone's services for a while, and built up a pretty good 
consultancy. 

The sort of metrics you're after are notoriously hard to find out in the wild. 
There's some folks capturing screenshots of enterprise dashboards. This may or 
may not help at all. 

http://dashboardspy.com/

Thanks,
Andrew


On 3/19/07 4:12 PM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote:



I agree with your assessment of how things are sold at a high-level but still 
struggling in that it takes more than just graphicalizing of your points to 
sell, hence I am still attempting to figure out a way to get my hands on some 
PPT that are used internal to enterprises prior to consulting engagements and I 
think a better answer will emerge. PPT may provide a sense of budget, 
timelines, roles and responsibilities, who needed to buy-in, industry metrics, 
quotes from noted industry analysts, etc that will help shortcut my own work so 
I can start moving towards the more important stuff.



-Original Message-
From: Andrew van der Stock  [ mailto:[EMAIL PROTECTED]
Sent: Monday, March 19, 2007 2:50  PM
To: McGovern, James F (HTSC, IT)
Cc:  SC-L
Subject: Re: [SC-L] How is secure coding sold within  enterprises?

There are two major methods:

 


1.  Opportunity cost / competitive advantage (the  Microsoft model)   

2.  Recovery cost reductions (the model used by most  financial 
institutions)



Generally,  opportunity cost is where an organization can further its goals by 
a secure  business foundation. This requires the CIO/CSO to be able to sell the 
business  on this model, which is hard when it is clear that many businesses 
have been  founded on insecure foundations and do quite well nonetheless. 
Companies that  choose to be secure have a competitive advantage, an advantage 
that will  increase over time and will win conquest customers. For example (and 
this is  my humble opinion), Oracle's security is a long standing unbreakable 
joke, and  in the meantime MS ploughed billions into fixing their tattered 
reputation by  making it a competitive advantage, and thus making their market 
dominance  nearly complete. Oracle is now paying for their CSO's mistake in not 
 understanding this model earlier. Forward looking financial institutions are  
now using this model, such as my old bank's (with its SMS transaction  
authentication feature) winning many new customers by not only promoting  
themselves as secure, but doing the right thing and investing in essentially  
eliminating Internet Banking fraud. It saves them money, and it works well for  
customers. This is the best model, but the hardest to sell.

The second  model is used by most financial institutions. They are mature risk 
managers  and understand that a certain level of risk must be taken in return 
for doing  business. By choosing to invest some of the potential or known 
losses in  reducing the potential for massive losses, they can reduce the 
overall risk  present in the corporate risk register, which plays well to 
shareholders. For  example, if you invest $1m in securing a cheque clearance 
process worth (say)  $10b annually to the business, and that reduces check 
fraud by $5m per year  and eliminates $2m of unnecessary overhead every year, 
security is an easy  sell with obvious targets to improve profitability. A well 
managed operational  risk group will easily identify the riskiest aspects of a 
mature company's  activities, and it's easy to justify impr

Re: [SC-L] How is secure coding sold within enterprises?

[McGovern, James F (HTSC, IT)]

John, thanks for the response and I think you have an understanding of the 
essence of the problem in that current books don't cover the "selling" security 
aspects nor how things actually work in large corporations. One of the benefits 
to me seeing someone's deck that went before me is that I get to see and 
understand not only salient points, but also how they were presented in terms 
of order and emphasis. I of course could like most folks who are new to a space 
is to take a first shot at it and mercilessly iterate but I do think it is wise 
to figure out ways to leverage the work of my peers in other enterprises (of 
course I can return the favor on other initiatives) and only iterate based on 
local custom and not broader themes.
 
In terms of job grade, no I am not an EVP nor am I a developer. I someone 
higher on the foodchain than most in that my responsibilities include strategic 
direction. Likewise, the issue in terms of selling is really about budget, but 
it is about first buy-in of all participants throughout the enterprise and 
secondly the ability to make the case once we collectively conclude that we 
need consulting assistance, the ability to go off preferred vendor list and 
make the right choice.
 
Based on your comment, in your opinion, I would love to know which analysts 
should I quote and if you know of specific gems? In terms of keeping up with 
the Joneses, part of this requires the ability to understand what others are up 
to. From what I can tell from this list, I have only seen replies from two 
Fortune enterprises where the vast majority of other folks either have some 
government connection and/or employed by software vendors/consulting firms. One 
of my concerns with why ideas sometimes don't fly is not do to validity but the 
perception that if one waits it out, things will get better and more efficiency 
in terms of spend will emerge. In other words, one perception may be that 
focusing on secure coding is too early (Yes, the current description of why it 
is important is valid but it doesn't address the early concern)
 
Got any URLs to any good architectural checklists? I have only ran across 
code-oriented ones.
 
Anyone seen any good pictorial representations of roadmaps in this space?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Steven
Sent: Monday, March 19, 2007 9:56 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L
Subject: Re: [SC-L] How is secure coding sold within enterprises?


Andrew, James, 


Agreed, Microsoft has put some interesting thoughts out in their SDL book. 
Companies that produce a software product will find a lot of this approach 
resonates well. IT shops supporting financial houses will have more difficulty. 
McGraw wrote a decent blog entry on this topic:


http://www.cigital.com/justiceleague/2007/03/08/cigitals-touchpoints-versus-microsofts-sdl/



Shockingly, however, I seem to be his only commentator on the topic.


I think James will find Microsoft's literature falls terribly short of even the 
raw material required to produce the PPT he desires. Let's see what we can do 
for him.


First: audience. I'm not sure of James' position, but it doesn't sound like 
he's high enough that he's got the CISO's ear now, nor that he's face-down in 
the weeds either. James, you sit somewhere in-between? James appears to work 
for an insurance company. Insurance companies do care about risk, but they're 
sometimes blind to the kinds (and magnitudes) of software risk their business 
faces. They fall in a middle ground between securities companies and banks. 


Second, length: If you're going after a SVP or EVP, James, I'd keep the deck to 
~3-5 slides. 1) Motivate the problem, 2) Show your org's. status (as an 
application security framework) and, 3) show the 6mo., 9mo., 12mo. (maybe) 
roadmap. Depending on the SVP, another two slides comparing you to others might 
work, as well as a slide that talks in more detail about costs, deliverables, 
and resource-requirements, and value.


Higher? I'd do two slides: 1) framework and 2) roadmap. The end. Place costs 
and value on the roadmap.

What about content? Longer decks I've seen (or helped create) have begun with 
research from analyst firms, or with pertinent headlines, to motivate the 
problem (couched as FUD if you're not careful) on slide one. Still, you'd be 
wise to pick fodder that will appear to the decision maker's own objectives. 
His/her objectives may be in pursuit of differentiation/opportunity or risk 
reduction, as Andrew said, or (more probably) they're pursuant to a more 
mundane goal: drive down (or hold constant) security cost while driving up the 
effectiveness of the spending. 


To this end, the decks I've seen quickly moved beyond motivation into solution. 
Here, you have to begin thinking about your current o

[SC-L] Question on User Groups

[McGovern, James F (HTSC, IT)]

Quick question for folks here. I participate in multiple user-groups and the 
topic of secure coding practices has never appeared. What would it take for a 
software vendor on this list to present to the CT OO Users Group ( 
www.cooug.org). These events are well attended.
 
Likewise, I am also a member of the advisory board for the Technology Managers 
Forum in NYC ( www.techforum.com) where we are working on an upcoming agenda. I 
would like to see secure coding practices become a panel topic here as well. 
Likewise, for folks who want to establish booths, sponsorship opportunities are 
also available.
 
Between these two events, you could have the opportunity to work with lots of 
Fortune enterprises in the Northeast. Besides, we are more interesting than the 
usual government stuff :-)


*
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] Economics of Software Vulnerabilities

[McGovern, James F (HTSC, IT)]

The uprising from customers may already be starting. It is called open source. 
The real question is what is the duty of others on this forum to make sure that 
newly created software doesn't suffer from the same problems as the commercial 
closed source stuff...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ed Reed
Sent: Monday, March 19, 2007 4:27 PM
To: Crispin Cowan
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Economics of Software Vulnerabilities


Crispin Cowan wrote:
> Crispin, now believes that users are fundamentally what holds back security
>
>   
I was once berated on stage by Jamie Lewis for sounding like I was
placing the blame for poor security on customers themselves.

I have moved on, and believe, instead, that it is the economic
inequities - the mis-allocation of true costs - that is really to blame.

Vendors are getting better, because they're being shamed by publicity -
not because they're bearing more of the costs that users incur due to
shoddy software.

But as bad as the costs are that are born by users of shoddy software
(patch costs, loss of utility, denial of service, licenses for
anti-virus software to make up for the egregiously bad code that leaves
buffer overflow exploits available that anyone can leverage to take over
a system) - as bad as those costs are they're still swapped by the value
- increased productivity and adrenalin rush - that commercial
feature-ism delivers.

Add the slowly-warmed pot phenomenon (apocryphal as it may be) -
customers don't jump out of the boiling pot because they're too invested
to walk away.

Eventually I think they'll get fed up and there'll be a consumer uprising.

Until then let's encourage better coding practices and secure designs
and deep thought about "what policy do I want enforced". 

(obligatory plug for high assurance)

But, let's not confuse code quality with code security, either.  It
isn't secure (against hostile code) until you can verify that it (a)
does what the policy says it should do (functional testing) and (b)
doesn't do what the security policy says it shouldn't do (fuzzing is
just a way of performing boundary tests on inputs - it tells you nothing
about hidden behaviors of the system, and you can't tell anything about
those without formal analysis and good life cycle configuration management).

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


*
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] Economics of Software Vulnerabilities

[McGovern, James F (HTSC, IT)]

Kevin, I would love to see open source communities embrace secure coding 
practices with stronger assistance from software vendors in this space. This of 
course requires going beyond "audit" capability and figuring out ways to get 
the tools into developers hands.

As a contributor to open source projects, I struggle with introducing security 
as I already contribute my time with the support/blessing of my significant 
other but she wouldn't let me spend hard cash on tools for contributing to open 
source. I wish there was a better answer for us all in this seat.

Generally speaking, many of my peers outside of work contribute to open source 
with the rationale that it a safer place from a political perspective to try 
things out, kinda like a POC where the outcome doesn't have to be successful 
and it won't show up on your annual review. Lately, I haven't figured out how 
to reduce my own exposure...

-Original Message-
From: Wall, Kevin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 9:16 PM
To: McGovern, James F (HTSC, IT)
Cc: sc-l@securecoding.org
Subject: RE: [SC-L] Economics of Software Vulnerabilities


James McGovern apparently wrote...

> The uprising from customers may already be starting. It is 
> called open source. The real question is what is the duty of 
> others on this forum to make sure that newly created software 
> doesn't suffer from the same problems as the commercial 
> closed source stuff...

While I agree that the FOSS movement is an uprising, it:
1) it's being pushed by "customers" so much as IT developers
2) the "uprising" isn't so much as being an outcry against
   security as it is against not being able to have the
   desired features implemented in a manner desired.

At least that's how I see it.

With rare exceptions, in general, I do not find that the
open source community is that much more security consciousness
than those producing closed source. Certainly this seems true
if measured in terms of vulnerabilities and we measure "across
the board" (e.g., take a random sampling from SourceForge) and
not just our favorite security-related applications.

Where I _do_ see a remarkable difference is that the open source
community seems to be in general much faster in getting security
patches out once they are informed of a vulnerability. I suspect
that this has to do as much with the lack of bureaucracy in open
source projects as it does the fear of loss of reputation to their
open source colleagues.

However, this is just my gut feeling, so your gut feeling my differ.
(But my 'gut' is probably bigger than yours, so feeling prevails. ;-)
Does anyone have any hard evidence to back up this intuition. I
thought that Ross Anderson had done some research along those lines.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
[EMAIL PROTECTED]   Phone: 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 


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


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

[SC-L] Economics of Software Vulnerabilities

[McGovern, James F (HTSC, IT)]

May I share another perspective.

1. The debate between open source vs. closed source in terms of security 
doesn't matter. Does anyone has any metrics that quantify the economics of 
writing better corporate software not for public consumption?

2. If you can't make the economic case, then you can possibly make the case of 
indexing yourself to others. I know folks opinion here in terms of keeping up 
with the Jones's but unless someone brainstorms a way for folks to do this, the 
economic case may never be made.

3. When one looks at metrics and more importantly maturity models, they almost 
always measure process and tend to avoid measuring either people and/or 
technology. If security folks figuring out how to measure people, process and 
technology then additional opportunities for secure coding practices may expose 
themselves.


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

[SC-L] Darkreading: compliance

[McGovern, James F (HTSC, IT)]

SoX has done a wonderful job of getting enterprises to embrace the notion of 
holistic identity and access management which wasn't occuring prior to it. It 
would be interesting to hear from folks here what other enterprise initiatives 
do you think that should be on the radar of large enterprises.


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

[SC-L] Misc Thoughts

[McGovern, James F (HTSC, IT)]

Many folks acknowledge that outsourcing poses additional challenges to 
enterprises. OWASP has done a wonderful job in terms of creating boilerplate 
for procuring software, but nothing exists in terms of procuring services. What 
is the best entity to create standard boilerplate for outsourcing?

Large enterprises have information protection policies which are statements of 
controls that can be audited by firms such as Deloitte. Are there any good 
examples of "controls" that enterprises have adopted in terms of secure coding 
practices that are publicly available?

One thought that I had is that secure coding practices could be pervasively 
implemented if we as a community started to serve on non-profit advisory boards 
as these folks are the most exposed. How does one find opportunities to serve 
in this capacity.


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

[SC-L] Security Courses for Business Analysts

[McGovern, James F (HTSC, IT)]

Last year, several members of our architecture community spent two days with 
Ken and found it to be valuable. We hope to do the same thing around Q3/Q4 for 
a larger audience but have been asked to explore security training for the 
business analyst community. Can anyone point me in the right direction towards 
training providers that have courses with the below characteristics?

*   Training done on our site
*   Fixed price per training day regardless of number of attendees 
*   Discusses how to document security-specific requirements
*   Discusses how to institutionalize the creation of misuse cases
*   Making the business case at a project-level for increased security
*   Considerations around creation of software test plans that incorporate 
security-specific aspects





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

[SC-L] Foundations of Security: What Every Programmer Needs to Know

[McGovern, James F (HTSC, IT)]

http://www.bookpool.com/sm/1590597842

Any thoughts positive and negative on this book?


*
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] Darkreading: compliance

[McGovern, James F (HTSC, IT)]

Gary, may I suggest an alternative response to application firewalls and the 
notion that it is hair-brained? Of course this is true but this list is missing 
a major opportunity to finally calculate an ROI model. If you ask yourself, 
what types of firewalls are pervasively deployed, you would find that 
application-firewalls aren't. This would then mean that folks would either need 
to replace their existing firewall (very risky that no one would ever 
consider), add multiple firewalls which introduce operational complexity, etc. 

You are probably aware that Cisco Pix, Checkpoint, etc aren't app-level which 
says that incumbent vendors aren't the solution. Likewise, you are probably 
aware that for other than common protocols, you probably will have to pay big 
bucks to vendors to develop custom plugins to their closed source offerings and 
the procurement cycle times around this are lengthy at best.

For many shops, having another type of firewall could cost millions whereas 
putting tools in the hands of developers may actually be cheaper. We as a 
community may be better served by encouraging application firewalls and letting 
the financial model for complying work in our favor...

-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 04, 2007 10:01 AM
To: McGovern, James F (HTSC, IT); SC-L@securecoding.org
Subject: RE: [SC-L] Darkreading: compliance


Hi all,

Another big momentum machine for software security (and data security) is PCI 
compliance.   There is a challenge, though, and that is figuring out where the 
credit card data that you want to protect are.   We've found in our practice at 
cigital that the data are literally scattered all over the enterprise.   
Because of this, hair-brained solutions like application firewalls (something 
called out in the PCI standards) often don't help.

I think PCI compliance is doing for data security and data risk what SOX did 
for software security and sofware risk.   They both help with problem awareness.

To answer your question directly, we see lots of large enterprises working hard 
on PCI these days.

gem

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


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

[SC-L] FW: Need Sec Forum speakers-let us know by Wed. if interested

[McGovern, James F (HTSC, IT)]

Awhile back, I mentioned the Technology forum in NYC and they are seeking 
speakers. Of course there are some constraints to whom may sign up. A "sponsor" 
may serve on a panel but otherwise, the speakers need to be from end-customer 
enterprises and not from software vendors or consulting firms. If you know of 
folks that can speak on their successes, they should definetely be encouraged 
to participate. 
 
NOTE: There is strong demand for Secure Coding Practices...
 
-Original Message-
From: Victoria Adams-TechForum [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 5:10 PM
To: McGovern, James F (HTSC, IT)
Subject: Need Sec Forum speakers-let us know by Wed. if interested



TechForum members: Need speakers for panels-please let us know by Wednesday 
afternoon 
 
Dear Members of Technology Managers Forum : 
Based on your votes, we've narrowed down the topics for the May 17th  
<http://www.techforum.com/sf2007_1/index.html> Security Forum and are now 
looking for TF member speakers for the panels, or your recommendations for a 
colleague at your company. Please take a look at the topics below and let us 
know which ones, if any, you would be willing and able to speak on. We would 
like to hear back from you by Wednesday afternoon if possible. Also, let us 
know if you have anyone to recommend from your firm. 
Here are the top ranked topics (we will distill the topics into 4 panels 
eventually). Please let us know which topics you would be able to speak 
on--your first and second choice. If you have been on a panel very recently, we 
definitely still want you to volunteer, but we may ask you to be backup for a 
panel since we also like to give new members a chance to participate. 
(One note: "Human Engineering: Is Information Security a Social Problem?" was 
the top-ranked topic, but we thought we'd address this question within the 
context of every panel).

1: Secure Coding Practices & Strategic Applications: Which Comes First? 
2:Enterprise Security and Individual Privacy: When Two Worlds Collide 
3: The Forensic Edge: Will Security Event Monitoring Pay for Itself? 
4: Risk Management: Is Information Security the Whole Sandwich? 
5:Encryption: For some of the data, all of the time
6: Friendly Fire: Protecting the Network from its Own Endpoints
7: Secure Voice & Video: Miles to Go Before We Sleep
8: Security Is as Security Does: Dealing with the Insider Threat 



*
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] Silver Bullet: Ross Anderson

[McGovern, James F (HTSC, IT)]

Would it be possible for upcoming episodes to have an individual who is 
directly employed by a Fortune enterprise whose primary business model isn't 
technology? Way too many software vendors, consultants and folks from academia.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gary McGraw
Sent: Friday, April 13, 2007 5:33 PM
To: Mailing List, Secure Coding
Cc: Clark-Fisher, Kathy; Anderson,Ross
Subject: [SC-L] Silver Bullet: Ross Anderson


Hi all,

A faithful reader of sc-l (and a long time silver bullet listener) suggested 
that I interview Ross Anderson for an episode.   By popular demand, here's Ross:

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

This episode will appear in an upcoming issue of IEEE Security & Privacy 
magazine.  S&P co-sponsors Silver Bullet along with Cigital.

As usual, there is some talk about software security in this episode.  Your 
feedback is welcome!

gem

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


Sent from my treo.


*
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] How big is the market?

[McGovern, James F (HTSC, IT)]

One thing that I can say is that vendors sometimes are doing themselves a 
disservice in terms of getting software security to grow even faster. Currently 
anything that has the word "security" in it automatically gets redirected to 
information protection types in large enterprises who usually are degrees away 
from those who actually write source code. A method should be to reach out to 
the development community via publications such as Java Developers Journal and 
similar forums.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gary McGraw
Sent: Friday, April 20, 2007 4:17 PM
To: SC-L@securecoding.org
Subject: [SC-L] How big is the market?


Hi sc-lers,

At s3con this week I gave a keynote about the state of the practice in
software security.  Some of what I said is captured in my darkreading
column this month:

http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

There are a couple of things worth noting.  First of all, the article
has some numbers in it that show how the market is growing.  I believe
we attained a $200-275 million level in 2006.  Things look like they are
continuing to grow as well.

Second, this article discusses a few ways for a corporation to get
started with software security, from the kinds of full blown initiatives
that we recommend at Cigital to easier baby steps with badness-ometers
like SPI Dynamics and Watchfire.

Please do what you can to spread the word about this article so that
people outside of our specialty get a feeling for what is happening.
Software security is growing, and the growth is strong and consistent.

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


*
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] How big is the market?

[McGovern, James F (HTSC, IT)]

I just conducted a super-official study of what my peers are reading by walking 
a total of five aisles within a very large building. Here are a list of 
magazines on folks desk:

- Infoworld
- Java Developers Journal
- Insurance & Technology
- DMReview
- Intelligent Enterprise
- CIO
- Insurance Networking News

Likewise, I asked several folks as to whether they subscribe to Dr. Dobbs and 
the answer was zero. Interestingly enough, I also checked with other folks and 
there seems to be more memberships in our architecture group with the ACM over 
IEEE.

-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 11:24 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: RE: [SC-L] How big is the market?


Got it.  I like dr. dobbs OK.  Do you see that one around?  It has
software security content every once in a while.  What others do you
think would be a good target?

What do the rest of you guys think?

gem

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

 

-Original Message-
From: McGovern, James F (HTSC, IT)
[mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 24, 2007 11:17 AM
To: Gary McGraw
Cc: SC-L@securecoding.org
Subject: RE: [SC-L] How big is the market?

Gary, I do at some level agree in terms of quality of publication. My
perspective though is from an large enterprise perspective whose primary
business model isn't about technology and the magazines that folks do
read especially in the development community. A quick informal survey
tells me that absolutely zero of my peers read IEEE (note I am a
subscriber).

 Part of the problem may be the fact that us enterprise folks are
bombarded with free magazines and cannot justify spending money to
subscribe to ones such as the IEEE. I am merely suggesting some
diversification for folks that don't pay for magazines.

-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 10:50 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: RE: [SC-L] How big is the market?


I'm sorry James, but I have to respectfully disagree about the vendor
thing.  Perhaps the tools vendors target the "information protection"
people, but at Cigital we sell services to software execs (in huge
companies) who are way up the food chain. 

Software security is small, and we need to emphasize the growth and get
people interested.  This goes for everyone who reads this list.  To
continue our impressive growth as a field, we need to continue to build.

I do agree with you that people need to write more for developers (but I
hope they pick better places than JDJ to publish in).  Toward that end,
check out the "Building Security In" department in IEEE Security &
Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
check out Brian Chess's new book "Secure Programming with Static
Analysis" when it comes out in June.  However, for the most part, it's
critical to understand that workaday developers can't wrangle enough
budget to tackle software security.

BTW, I posted a reprise to the darkreading column on justice league
today:
http://www.cigital.com/justiceleague/
http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

All told, I am very optimistic about our field, but don't think we can
rest on our laurels at all yet.

gem

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



*
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] How big is the market?

[McGovern, James F (HTSC, IT)]

Gary, I do at some level agree in terms of quality of publication. My 
perspective though is from an large enterprise perspective whose primary 
business model isn't about technology and the magazines that folks do read 
especially in the development community. A quick informal survey tells me that 
absolutely zero of my peers read IEEE (note I am a subscriber).

 Part of the problem may be the fact that us enterprise folks are bombarded 
with free magazines and cannot justify spending money to subscribe to ones such 
as the IEEE. I am merely suggesting some diversification for folks that don't 
pay for magazines.

-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 10:50 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: RE: [SC-L] How big is the market?


I'm sorry James, but I have to respectfully disagree about the vendor
thing.  Perhaps the tools vendors target the "information protection"
people, but at Cigital we sell services to software execs (in huge
companies) who are way up the food chain. 

Software security is small, and we need to emphasize the growth and get
people interested.  This goes for everyone who reads this list.  To
continue our impressive growth as a field, we need to continue to build.

I do agree with you that people need to write more for developers (but I
hope they pick better places than JDJ to publish in).  Toward that end,
check out the "Building Security In" department in IEEE Security &
Privacy magazine <http://www.computer.org/portal/site/security/>.  Also
check out Brian Chess's new book "Secure Programming with Static
Analysis" when it comes out in June.  However, for the most part, it's
critical to understand that workaday developers can't wrangle enough
budget to tackle software security.

BTW, I posted a reprise to the darkreading column on justice league
today:
http://www.cigital.com/justiceleague/
http://www.darkreading.com/document.asp?doc_id=122253&WT.svl=column1_1

All told, I am very optimistic about our field, but don't think we can
rest on our laurels at all yet.

gem

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


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

[SC-L] NYC Security

[McGovern, James F (HTSC, IT)]

FYI. Awhile back I mentioned the Technology Managers Forum in which I am a 
participant. The agenda is finalized and secure coding practices was the number 
one topic: http://www.techforum.com/sf2007_1/index.html For product vendors and 
consulting firms that want access to key decision makers, this would be a great 
opportunity to get a booth. 

Anyway, hope to run across folks from this list here. Nothing is better than 
face-to-face conversations...


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

[SC-L] Magazines

[McGovern, James F (HTSC, IT)]

FYI. Other magazines read within a large enterprise:

- MSDN Magazine
- SC Magazine
- Oracle's Profit Magazine


*
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] Darkreading: Secure Coding Certification

[McGovern, James F (HTSC, IT)]

Gary, I think this test will miss for other reasons including but not limited 
to:

1. ONLY consultants and vendors have jumped on the bandwagon. Other IT 
professionals such as those who work in large enterprises have no motivation to 
pursue. 

2. The target price for the exams will be an impediment as many folks who can't 
get reimbursed for taking them will not bother. 

3. It needs to be more language agnostic. Folks who code in Smalltalk, Ruby or 
scripting languages should not be treated as second class citizens

4. I would not measure "experience" but desire to pursue knowledge. Experience 
over time can get static. How many of us know a COBOL programmer who has had 
one years of experience twenty times.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gary McGraw
Sent: Friday, May 11, 2007 11:18 AM
To: SC-L@securecoding.org
Subject: [SC-L] Darkreading: Secure Coding Certification


Hi all,

As readers of the list know, SANS recently announced a certification scheme for 
secure programming.  Many vendors and consultants jumped on the bandwagon.  I'm 
not so sure the bandwagon is going anywhere.  I explain why in my latest 
darkreading column:

http://www.darkreading.com/document.asp?doc_id=123606

What do you think?  Can we test someone's software security knowledge with a 
multiple choice test?  Anybody seen the body of knowledge behind the test?

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


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

[SC-L] Darkreading: Secure Coding Certification

[McGovern, James F (HTSC, IT)]

Maybe the test shouldn't focus on code at all? If we can agree that many flaws 
are found at design time even before code is written (Yes, most folks still use 
waterfall approaches but that is a different debate) then why can't questions 
occur at this level? 

If we follow the trend of IT at large, we would understand that lots of 
"coding" is going outside of the United States but architecture and design for 
the most part is still onshore, it has the potential for a bigger impact, 
access to more capital and therefore should come first.


*
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] Darkreading: Secure Coding Certification

[McGovern, James F (HTSC, IT)]

As someone who has read your books, I am in full agreement that we should use 
much of the material contained to create an exam around design. Instead of 
making it a "later" thing, what would it take for folks on this list to have 
some sense of urgency and blast SANS to do it sooner?

If any members here will also be in attendance at the TechForum in NYC 
(http://www.techforum.com/sf2007_1/index.html) would love to hook up for lunch.

-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 4:26 PM
To: McGovern, James F (HTSC, IT); 'SC-L@securecoding.org'
Subject: RE: [SC-L] Darkreading: Secure Coding Certification


Hi all,

I like this idea.   There is plenty of non-code material to master in our 
field.   I think a bunch of it is covered in detail in "Software 
Security"...but I am biased.

I would like to see coverage of common attack patterns, coverage of risk 
analysis basics, and coverage of both positive and negative design patterns.

gem

P.S. I plan to respond soon to previous posts.   Too much time on airplanes 
lately.

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



Sent from my treo.

 -Original Message-----
From:   McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED]
Sent:   Wednesday, May 16, 2007 03:08 PM Eastern Standard Time
To: SC-L@securecoding.org
Subject:[SC-L] Darkreading: Secure Coding Certification

Maybe the test shouldn't focus on code at all? If we can agree that many flaws 
are found at design time even before code is written (Yes, most folks still use 
waterfall approaches but that is a different debate) then why can't questions 
occur at this level?

If we follow the trend of IT at large, we would understand that lots of 
"coding" is going outside of the United States but architecture and design for 
the most part is still onshore, it has the potential for a bigger impact, 
access to more capital and therefore should come first.


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

___
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] Darkreading: Secure Coding Certification

[McGovern, James F (HTSC, IT)]

I agree. The two that I feel should be next in terms of developing 
certifications around are:
 
- How to describe misuse case and dangerous ommissions for people writing 
functional specifications: This is highly applicable in outsourcing 
environments including the Federal Government
 
- Strong Software Design Patterns for Software Architects/Lead Developers: This 
is where if security were properly addressed, would be pretty cheap to handle 
and have a better ROI than dealing with it at coding time.
 
http://www.theimf.com/events_detail.aspx?ID=164

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arian J. Evans
Sent: Wednesday, May 16, 2007 4:05 PM
To: SC-L@securecoding.org
Subject: Re: [SC-L] Darkreading: Secure Coding Certification


I don't understand this thread. These are different sets of issues. Often, they 
are different sets of people. Organizational size is a factor. A three-man 
startup is going to have a lot of hat overlap, where a monolithic enterprise is 
going to have broad distribution of hats. The spirit of this thread seems to 
have a well-meaning but misguided swaping of "ANDs" and "ORs". 

The arm-chair quarterbacking of a very useful, overdue effort, is a bit silly. 
We need these efforts.

As I mentioned previously, we need multiple tests:

+ "How to write and implement code that isn't weak to bit-fiddling" 

(e.g. don't concatenate strings, strongly type data, encode output safe for 
user agent, don't use LIKE queries with weak authorization models, blah blah; 
this is how you make XSS and SQLi and BoF/HoFs go away.) 

--> Check. That's the first thing thing SANS (err, SSI) is addressing.

We still need:

+ "Non-dangerous requirements-gathering for Product Evangelists/Owners"

(no, the customer does not really want that) 


+ "Strong Software Design Principles for Business Owners"

(weak secrets often reduce short-term costs, customer service, etc., but...) 


+ "Strong Software Design Patterns for Software Architects/Lead Developers" 

(yeah, your authorization model is Borked man. What were you drinking? In fact, 
why do you even have "roles" in your application? Might as well just use 
"Trust".)


+ "How to describe mis-use case and dangerous omissions for people writing 
functional specifications" 

(So Rob should run Rob's reports. Should Rob be able to run Sally's report(s)?? 
yes|no )


These are all different actions... often taken by different actors. At minimum 
it is while a given actor is performing different tasks. 

I'd love to see SSI collect a body of knowledge and make tests for all of 
these. I see no reason to debate "ORs" in here.

chow

Arian Evans




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

[SC-L] Tools: Evaluation Criteria

[McGovern, James F (HTSC, IT)]

We will shortly be starting an evaluation of tools to assist in the secure 
coding practices initiative and have been wildly successful in finding lots of 
consultants who can assist us in evaluating but absolutely zero in terms of 
finding RFI/RFPs of others who have travelled this path before us. Would 
especially love to understand stretch goals that we should be looking for 
beyond simple stuff like finding buffer overflows in C, OWASP checklists, etc.
 
In my travels, it "feels" as if folks are simply choosing tools in this space 
because they are the market leader, incumbent vendor or simply asking an 
industry analyst but none seem to have any "deep" criteria. I guess at some 
level, choosing any tool will move the needle, but investments really should be 
longer term.


*
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] Tools: Evaluation Criteria

[McGovern, James F (HTSC, IT)]

I think my thinking was a little different. I would also expect criteria that 
shows how it integrates into the entire lifecycle. For example, scanning source 
code that is already extracted is a little different than scanning a PVCS 
repository. Likewise, taking a list of vulnerabilities and understanding who 
created them, connecting to the identity stored in version control and then 
having the ability to feed tools such as JIRA, PVCS Tracker, etc would be 
powerful.

Good to see that folks are expanding the criteria in terms of what it scans 
for, but criteria as to how it integrates is also equally useful.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steven M. Christey
Sent: Tuesday, May 22, 2007 12:53 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: Re: [SC-L] Tools: Evaluation Criteria



On Tue, 22 May 2007, McGovern, James F (HTSC, IT) wrote:

> We will shortly be starting an evaluation of tools to assist in the
> secure coding practices initiative and have been wildly successful in
> finding lots of consultants who can assist us in evaluating but
> absolutely zero in terms of finding RFI/RFPs of others who have
> travelled this path before us. Would especially love to understand
> stretch goals that we should be looking for beyond simple stuff like
> finding buffer overflows in C, OWASP checklists, etc.

semi-spam: With over 600 nodes in draft 6, the Common Weakness Enumeration
(CWE) at http://cwe.mitre.org is the most comprehensive list of
vulnerability issues out there, and it's not just implementation bugs.
That might help you find other areas you want to test.  In addition, many
code analysis tool vendors are participating in CWE.

> In my travels, it "feels" as if folks are simply choosing tools in this
> space because they are the market leader, incumbent vendor or simply
> asking an industry analyst but none seem to have any "deep" criteria. I
> guess at some level, choosing any tool will move the needle, but
> investments really should be longer term.

Preliminary CWE analyses have shown a lot less overlap across the tools
than expected, so even baased on vulnerabilities tested, this is an
important consideration.

You might also want to check out the SAMATE project (samate.nist.gov),
which is working towards evaluation and understanding of tools, although
it's a multi-year program.

Finally, Network Computing did a tool comparison:


http://www.networkcomputing.com/article/printFullArticle.jhtml?articleID=198900460

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


*
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] Tools: Evaluation Criteria

[McGovern, James F (HTSC, IT)]

Peter, I think I agree with your comments at some level but disagree at 
another. Your comment about using languages and tools is spot on yet the reason 
no one is actually approaching it from this fashion is that you can't make 
money off it. For example, if we all jumped in and make the GNU C compiler 
better and even worked with code generation products that subscribe to say MDA, 
then how would most folks here profit?

Maybe folks are still building square windows because we haven't realized how 
software fails and can describe it in terms of a pattern. The only 
pattern-oriented book I have ran across in my travels is the Core Security 
Patterns put out by the folks at Sun. Do you think we should stop talking 
solely about code and start talking about how vulnerabilities are repeatedly 
introduced and describe using patterns notation?

It is also important to realize that the folks with decision-making authority 
in terms of procuring tools usually aren't from an engineering background. 
Nowadays, many decision-makers may not have even written a single line of code 
in their lifetime and use process as a substitute for competence. While process 
weenies don't necessary understand coding, they do usually understand the 
notion of auditing which these tools cater to.

If one can produce a metric, scorecard or other terms attractive to modern IT 
executives, it is certainly more attractive than engineering practices they 
don't understand.

Audit-oriented thinking also allows folks to put clauses into contracts when 
enterprises procure software from third-parties and can mandate scans by 
multiple tools that produce a score below say X while what you are proposing is 
a lot harder and requires more trust when third parties are involved.

-Original Message-
From: Peter Amey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2007 11:27 AM
To: McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: RE: [SC-L] Tools: Evaluation Criteria


 

[snip]
> 
> Good to see that folks are expanding the criteria in terms of 
> what it scans for, but criteria as to how it integrates is 
> also equally useful.
> 

On the contrary I find the idea of evaluating tools by "what they scan
for" very disturbing.  It shows a continuing belief that software
engineering involves building things then "scanning" them for defects.
We /must/ move to tools and methods that help us construct correct
programs rather than looking for defects in them afterwards.

Let me give you an example from my previous aeronautical career.  The
DeHavilland Comet was the world's first transatlantic jet airliner.  All
went well until after a year of two of service there were a series of
catastrophic airframe failures in flight, all with total loss of those
on board.  ISTR that there were 3 crashes in all.  The design defect
that caused the disasters was a combination of square cabin windows and
hull pressurisation on each flight.  The square windows caused amplified
stress at each window corner which, with the cyclic stress changes from
pressurisation caused metal fatigue failures and hull loss.  Metal
fatigue was little understood at the time.

Now for the lessons.  The aero industry quickly learned about metal
fatigue and stress raisers and used that information to design fuselages
that did not suffer from the Comet's defects.  That is why your airliner
window is oval not square.  There have been very, very few Comet-style
failures since (and they are usually associated with corrosion or poor
maintenance).  So, the problem was analysed, understood, disseminated
and hence eliminated.

In the software world we seem to content to build "window squareness
detection tools".  Some will find 70% of square windows but miss others
and produce false alarms in yet other cases.

Buffer overflows are the square windows of secure software: we shouldn't
be /scanning/ for them but using languages and tools that /prevent/
their introduction.

Regards


Peter



Peter Amey BSc ACGI CEng CITP MRAes FBCS

CTO (Software Engineering)
direct:   +44 (0) 1225 823761
mobile: +44 (0) 7774 148336
[EMAIL PROTECTED]

Praxis High Integrity Systems Ltd
20 Manvers St, Bath, BA1 1PX, UK
t: +44 (0)1225 466991
f: +44 (0)1225 469006
w: www.praxis-his.com



 



This email is confidential and intended solely for the use of the individual to 
whom it is addressed. If you are not the intended recipient, be advised that 
you have received this email in error and that any use, disclosure, copying or 
distribution or any action taken or omitted to be taken in reliance on it is 
strictly prohibited. If you have received this email in error please contact 
the sender. Any views or opinions presented in this email are solely those of 
the author and do not necessarily represent thos

[SC-L] Perspectives on Code Scanning

[McGovern, James F (HTSC, IT)]

I really hope that this email doesn't generate a ton of offline emails and hope 
that folks will talk publicly. It has been my latest thinking that the value of 
tools in this space are not really targeted at developers but should be 
targeted at executives who care about overall quality and security folks who 
care about risk. While developers are the ones to remediate, the accountability 
for secure coding resides elsewhere.

It would seem to be that tools that developers plug into their IDE should be 
free since the value proposition should reside elsewhere. Many of these tools 
provide "audit" functionality and allow enterprises to gain a view into their 
portfolio that they previously had zero clue about and this is where the value 
should reside.

If there is even an iota of agreement, wouldn't it be in the best interest of 
folks here to get vendors to ignore developer specific licensing and instead 
focus on enterprise concerns?


*
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] Perspectives on Code Scanning

[McGovern, James F (HTSC, IT)]

While developers create the problems, I don't believe it is their fault. If you 
were to analyze the SDLC of a Fortune enterprise or even software vendor they 
all have a common problem in that the reward systems for developers are all 
about features and time to market where security is always a last minute 
thought and prioritized last. Developers in an outsourcing context would 
probably get it handed to them if they were to spend additional time writing 
secure code if the client didn't ask for it. 

I believe this is a management problem and that management needs tools to help 
them understand how big of a problem they create for others. Developers should 
be cut a break and be given tools to do their jobs properly and there shouldn't 
be expense incurred to do so.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Michael Silk
Sent: Wednesday, June 06, 2007 7:00 PM
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning


On 6/7/07, McGovern, James F (HTSC, IT) <[EMAIL PROTECTED]> wrote:
> I really hope that this email doesn't generate a ton of offline emails and 
> hope that folks will
> talk publicly. It has been my latest thinking that the value of tools in this 
> space are not really
> targeted at developers but should be targeted at executives who care about 
> overall quality
> and security folks who care about risk. While developers are the ones to 
> remediate, the
> accountability for secure coding resides elsewhere.

and that's the problem. the accountability for insecure coding should
reside with the developers. it's their fault [mostly].



> It would seem to be that tools that developers plug into their IDE should be 
> free since the
> value proposition should reside elsewhere. Many of these tools provide 
> "audit" functionality
> and allow enterprises to gain a view into their portfolio that they 
> previously had zero clue
> about and this is where the value should reside.
>
> If there is even an iota of agreement, wouldn't it be in the best interest of 
> folks here to get
> vendors to ignore developer specific licensing and instead focus on 
> enterprise concerns?
>
>
> *
> 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.
> ___
>


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e
___
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] Perspectives on Code Scanning

[McGovern, James F (HTSC, IT)]

It was bothering me for a long time that I didn't find evidence of any 
enterprise of size wanting to even purchase "seats" for source code scanning by 
developers yet I find tons of evidence that folks want to have deeper audits 
and have the tools in the hands of a few. One cannot ignore the importance of 
the thud factor when the report comes out especially in organizations that are 
led by process weenies who aren't really technical.
 
I do believe that enterprises would entertain tools that enabled secure design 
and figure out a way to apply security patterns such as what is outlined in the 
Core Security Patterns book. Tools that could somehow automate 
architecture/design reviews would be of immense value as well. 
 
One interesting thought I have is that more developers may care about secure 
coding if there were statistics that compared American developers to those 
employed in other countries. Right now, outsourcing is an unpopular topic where 
folks respond based on how they feel. Imagine the press if folks could 
factually prove that folks in other countries increase security defects...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arian J. Evans
Sent: Thursday, June 07, 2007 4:21 PM
To: McGovern, James F (HTSC, IT); Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning





On 6/6/07, McGovern, James F (HTSC, IT) < [EMAIL PROTECTED]> wrote: 

I really hope that this email doesn't generate a ton of offline emails and hope 
that folks will talk publicly. It has been my latest thinking that the value of 
tools in this space are not really targeted at developers but should be 
targeted at executives who care about overall quality and security folks who 
care about risk. While developers are the ones to remediate, the accountability 
for secure coding resides elsewhere. 



Nice email James. These conversations are always enlightening. The responses 
tend to illuminate who has what experience types, between (a) university 
software experience, (b) government software-project experience, and (c) 
enterprise software experience. That makes a lot of difference in these 
discussions. Most enterprise /and/ small ISV developers I know, the good ones, 
either take pride in their quality of code and self-manage security issues, or 
are fast and productive and don't give a crap. 

And why should they give a crap? It's not their problem domain.

The armchair software-security pundits: "Shame on you. You didn't properly 
transcode these Hebrew and Latin code pages to avoid XSS attacks, dummy." 

The fast effective developer: "I delivered your functional specifications to 
the letter, on time, and the transcoding engine is FAST. What's the problem 
here?"




It would seem to be that tools that developers plug into their IDE should be 
free since the value proposition should reside elsewhere. Many of these tools 
provide "audit" functionality and allow enterprises to gain a view into their 
portfolio that they previously had zero clue about and this is where the value 
should reside. 



So of tools that plug into the IDE, let's distinguish between *source-code* and 
*run-time* "scanners". Source scanners I suspect will die a slow death, because 
sooner or later they are going to integrate into the IDE and per-seat value 
will plummet. They will be a "given feature" of IDEs. Sooner or later the IDE 
vendors will either buy & integrate, or come out with their own tools. Take 
Compuware, the quality is pretty low, but if I were a betting man I would bet 
that the bar gets set at "low-quality included-functionality" rather than set 
at "$50k per-seat amazing quality source code analzyer". 

I believe this is different from run-time or human design analysis, largely 
because of different business case.

For example: I have some clients that really like their Fortify tools, but they 
really don't like all the time and critical development resources it takes to 
use them, and how expensive they are. Cool tools, sexy technology, but they are 
hard to align with the business case and business goals for software 
development on multiple levels. 

Run-time analysis is different. Run-time "scanner" IDE-plugins as a concept is 
laughable, at best. Seriously -- who thinks that run-time scanners for 
developers is a viable idea?

 Run-time analysis's strengths are different too. It is easier at run-time to 
discover and analyze fundamental design flaws (note: I did not say "find them 
all", but definitely "find indication of them"), and to identify emergent 
behaviors. At best IDE plugins can perform some form of unit testing, but 
beyond verification of basic data-typing and IFOF/IFOE type issues, meh, not 
very useful. Not to mentioned entirely outside of the IDE problem-domain. 

Conclusion: two s

Re: [SC-L] Perspectives on Code Scanning

[McGovern, James F (HTSC, IT)]

In a previous thread someone appropriately commented that perspectives in this 
space differ depending upon whether you are a software vendor, government 
customer or enterprise. I do not disagree that developers need to know how to 
fix their code. What I am saying is that tools to assist developers in writing 
better could should be free.

Your quote "*imho* vendor has to follow developer licensing" is where I think 
it will harm the goals of secure coding at large. Consider the trend within the 
industry that tools for software development are essentially becoming free. No 
one pays for IDEs (rare exceptions) when things like Eclipse and Visual Studio 
have free versions.

Enterprise folks however will pay lots of money for tools in the auditing space 
that help them to quantify risk. The ability to scan large multiple code bases 
is a different product/problem than scanning while writing code in an IDE. I am 
saying that more money could be had if folks focus on the first and not the 
later. Vendors who get it twisted by focusing on the number of developers are 
dillusional and should ask themselves why aren't but a select few of any 
enterprise pervasively deploying tools to developers.

Give away the developer tools in the same way Microsoft does and you will 
accelerate your potential sales from the bottom up. Not all sales within places 
are driven top down...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Paolo Perego
Sent: Friday, June 08, 2007 5:40 AM
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning

Hi there, I found this thread very interesting.
It's true that developers are the ones who remediate to code
insecurity and executives care about how much effort has to be spent
over closing branches. Indeed I think the two categories needs a tool
approaching the same problem (tell if a code follows security best
practices or not) showing results in 2 "different" languages.

Developers need how to know how to fix their code. Executives need to
know how much these fixes cost, who will attend them and in how many
time fixes will be committed.

*imho* vendor has to follow developer licensing... since developer do
knows ho to write code but he has to be helped in writing it in a
secure way.

Safe coding is a concern for both developers than executives.
My 2 euro cents

Ciao ciao
thesp0nge
-- 
Owasp Orizon leader
orizon.sourceforge.net
___
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.
___


*
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] What's the next tech problem to be solved in softwaresecurity?

[McGovern, James F (HTSC, IT)]

The next problem to be solved is moving higher up the food chain by teaching 
architects secure architecture principles. Would love to see Gary McGraw tackle 
this subject in his next book...



From: [EMAIL PROTECTED] on behalf of Kenneth Van Wyk
Sent: Sun 6/10/2007 9:37 AM
To: Secure Coding
Subject: Re: [SC-L] What's the next tech problem to be solved in 
softwaresecurity?



First off, many thanks to all who've contributed to this thread.  The 
responses and range of opinions I find fascinating, and I hope that 
others have found value in it as well.  Great stuff, keep it coming.

That said, I see us going towards that favorite of rat-holes here, 
namely the "my programming language is better than yours, nyeah!" 
path.  Let's please avoid that.  I'm confident that we've seen it 
enough times to know that it ends with no clear winners (but plenty 
of losers).

Cheers,

Ken
-
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com








*
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] Perspectives on Code Scanning

[McGovern, James F (HTSC, IT)]

OK, so is the next challenge to create contract language that goes beyond the 
stuff that OWASP is doing to include all security requirements and not just web 
focused?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Michael S Hines
Sent: Thursday, June 07, 2007 9:13 AM
To: 'Secure Coding'
Subject: Re: [SC-L] Perspectives on Code Scanning


> and that's the problem. the accountability for insecure coding should
> reside with the developers. it's their fault [mostly].

The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for more secure
software.  There are pockets of success, but a whole lot more could be done.

--- the software should work and be secure (co-requirements).  The user
community has been educated to accept CTL-ALT-DEL and wait as an acceptable
method of computing (and when things are really haywire - resintall the OS
and loose all your work).   We've got a long way to go for them to expect
software to also be secure, since they now accept that it doesn't work right
as SOP.

Mike Hines
[EMAIL PROTECTED]


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


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

[SC-L] The Next Frontier

[McGovern, James F (HTSC, IT)]

Awhile back, someone asked the question of what should this list
collectively work on next. Today, I attended a demo from Fortify
Software and an idea appeared. It seems as if OWASP has a taxonomy of
all ways of classifying defects. Likewise, all of the tools emit some
form of information to be consumed by the audit role. 

Would there be value in terms of defining an XML schema that all tools
could emit audit information to? My thought is that this could solve
several problems. For example, if a large enterprise wanted to put in
their outsourcing contract that their outsourcer use a tool (any tool)
but also had to provide the audit results in a normalized markup
language then they could build trends, do analysis at a higher level to
look at common problems and so on.

Likewise, in situations where one doesn't necessarily have access to
source code (say Oracle, BEA, Microsoft and so on), we could ask for
evidence of what tests where ran and the results without having access
to the actual source code. Likewise, if there were a way to capture
signoffs and digitally sign portions then that could be something put
into the contract as well.

Thoughts?


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

[SC-L] Instead of the next frontier, how about another frontier

[McGovern, James F (HTSC, IT)]

I was thinking, Instead of the next frontier, how about another
frontier? Many software vendors pretend that the entire world is either
Java or .NET without acknowledging that all of the really good data in
many enterprises is sitting on a big ugly mainframe running COBOL, IMS,
PL/1, etc. It is assumed at this level that most folks in this space
have zero knowledge of these platforms and hence the reason their tools
don't support. 

It is my current thought that us folks in enterprises could do several
things. First, we have the environment that others may not have access
to. Second, we have employees that can help write specifications for
detecting some aspects (they are not secure coding oriented but do
understand things like buffer overflows) in PL1, COBOL, Assembler, etc. 

If the later is of value, we would of course like to figure out how to
make this happen with one effort where every vendor could potentially
consume and not do it for a single vendor.


*
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] The Next Frontier

[McGovern, James F (HTSC, IT)]

Would Fortify consider making their schema open source and donating it
to OWASP? Likewise, would Ouncelabs, coverity and others be willing to
adapt their product to it?


 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paco Hope
Sent: Wednesday, June 27, 2007 4:38 PM
To: Secure Coding
Subject: Re: [SC-L] The Next Frontier

On 6/26/07 5:00 PM, "McGovern, James F (HTSC, IT)"
<[EMAIL PROTECTED]> wrote:

Would there be value in terms of defining an XML schema that all tools
could emit audit information to?

You might want to take a look at what the Fortify guys already do. Their
"FVDL" (Fortify Vulnerability Description Language) is XML written to a
specific schema. Here's a snippet:


http://www.w3.org/2001/XMLSchema-instance"; version="1.5"
xsi:type="FVDL">  
curl-7.11.1
42
23572
 
/Users/paco/Documents/Fortify/curl-7.11.1/lib

connect.c
krb4.c
[..snip..]


28424EC3-FFAC-40C0-94D9-3D8283B2F57C
Input Validation and Representation
Buffer Overflow
dataflow
4.0


005542ED81D54F3C72BF3669EA8D130A
4.0
3.4

[..snip..]

Some of their XML seems quite reusable to me, and some of it seems
pretty proprietary. It doesn't seem like they share a DTD or a schema
publicly. Perhaps a little coaxing would get them to release it.

Paco
--
Paco Hope, CISSP
Technical Manager, Cigital, Inc
http://www.cigital.com/ * +1.703.585.7868 Software Confidence. Achieved.

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


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

[SC-L] Comparing Software Vendors

[McGovern, James F (HTSC, IT)]

 Jerry Leichter commented on flaws in scanning tools but I have a
different question. Lots of folks love to attack MS while letting other
vendors off the hook.Is there merit in terms of comparing vendor
offerings within a particular product line. For example is EMC's
Documentum product more secure than say an open source ECM vendor such
as Alfresco?

The industry analysts tend not to actually touch tools and rely on
others. There is some value in terms of quantifying which products are
more secure than others, so shouldn't we as a community help them figure
this out?


*
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] Secure Programming with Static Analysis

[McGovern, James F (HTSC, IT)]

If you are seeking additional book ideas for this series, may I suggest
posting to [EMAIL PROTECTED]

There are two books that I would love to see:

- Designing Secure Software - Not everything is about the code
- Procuring Secure Software - Most enterprises nowadays buy software vs
build it 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gary McGraw
Sent: Thursday, July 05, 2007 9:01 AM
To: 'Brian Chess'; 'sc-l@securecoding.org'
Subject: Re: [SC-L] Secure Programming with Static Analysis

Hi sc-l,

I have read this awesome book (more than once) and can vouch for it.  It
is an important part of the addison-wesley software security series, the
series that includes:
Software Security www.swsec.com
Rootkits
Exploiting Software
Building Secure Software
(and any day now Exploiting Online Games)

For more on the series, see www.buildingsecurityin.com.  We are always
on the lookout for more titles for the series, especially if they dive
deeply into one of the seven touchpoints, so if you have a book idea
please let me know.

Meanwhile, click on this link and buy Brian and Jacob's book:
http://www.amazon.com/dp/0321424778

gem

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



*
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] Resources to fix vulns

[McGovern, James F (HTSC, IT)]

I wish formulas were the solution to your question. The problem is that
the answer is heavily dependent upon the background of the C-level
executive. Some C-Level executives have an analytical background where
their backgrounds could have been actuarial, IT, statistics, etc where
they would understand intuitively that not all vulnerabilities are equal
and that the solution would feel more like describing a design pattern.
If your C-Level executive is a process weenie then you have to then get
into prioritization and the psychology of dealing with low-hanging fruit
vs severity vs occurences and so on. If you C-Level executive is
perception-oriented and frequently uses the phrase "perception is
reality" then your answer is simply to grab industry quotes from Gartner
or similar entity...



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M
Sent: Wednesday, July 18, 2007 11:54 AM
To: sc-l@securecoding.org
Subject: [SC-L] Resources to fix vulns



What do you tell a C-level exec in terms of h/c and time it will take to
fix web app vulnerabilities discovered in a website?

X number of vulnerabilities = Y h/c and Z time. 

Of course there's a host of factors/variables involved that could wind
up looking like actuarial tables or DNA sequences (!), but what we'd
like to be able to do is sum it up as an initial swag and let the app
owners use it as a factor in calculating the actual time to remediate.

Anyone done this or like to take a swipe? 

 
Chris McCown, GSEC(Gold) 
Intel Corporation 
* (916) 377-9428 | * [EMAIL PROTECTED]   



*
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] Resources to fix vulns

[McGovern, James F (HTSC, IT)]

 I would actually recommend AGAINST using prior track records for fixing
previous vulnerabilities because in all honestly they probably don't
track it. Most enterprises prioritize any type of defect based on the
importance as declared by business users whom traditionally would
prioritize a spelling error on a web page of higher importance than a
buffer overflow. Security stuff may get addressed while the developer
has the patient open and therefore there is no real transparency in
terms of the numbers.

Likewise, if you wanted to think of security as a system quality and
wanted to compare it to things like performance and scalability, those
things haven't been always solved by changing code where the behavior
was more like throwing lots of hardware at it. Security has done some of
this as well but this will not uncover what you seek.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ljknews
Sent: Wednesday, July 18, 2007 3:42 PM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Resources to fix vulns

At 8:53 AM -0700 7/18/07, McCown, Christian M wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
>   boundary="_=_NextPart_001_01C7C953.D03CBE5C"
>
> What do you tell a C-level exec in terms of h/c and time it will take 
>to fix web app vulnerabilities discovered in a website?
>
> X number of vulnerabilities = Y h/c and Z time.
>
> Of course there's a host of factors/variables involved that could wind

>up looking like actuarial tables or DNA sequences (!), but what we'd 
>like to be able to do is sum it up as an initial swag and let the app 
>owners use it as a factor in calculating the actual time to remediate.

Look at the track record for _that_organization_ fixing previous
vulnerabilities.
--
Larry Kilgallen


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

[SC-L] Smalltalk and other Second Class Languages

[McGovern, James F (HTSC, IT)]

 
By now, pretty much everyone is familiar with PCI and section 6 which
outlines the ten things an application but resolve. Many of the secure
coding tools such as Ounce Labs, Klokwork, etc have automated the
ability to inspect code but have only focused on languages such as Java
and .NET. I would like to get a sense as to how others are approaching
the notion of secure coding for languages such as Smalltalk,
Powerbuilder, Oracle Forms, etc and whether there are any public sources
of information on these languages from a security perspective.

If I have to bust my brain and figure it out myself, I would also like
guidance as to how to make this information known so that ALL software
vendors who automate the code review process can implement...


*
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] Security Testing track: Software Testing Conference:Washington DC

[McGovern, James F (HTSC, IT)]

 Upon reading this, I had several thoughts come to mind:

1. If we are to truly solve the last mile, we need to also choose more
mainstream conferences such as STPCon (http://www.stpcon.com) since they
also have an associated magazine (Software Test and Performance) which
may stimulate more magazine articles on the topic. I did a quick run
upstairs to our QA folks and asked them what magazines do they read as
well as awareness of certain conferences.

2. What do you think we can do as a unified group of individuals in
terms of a listserv to encourage various industry analyst firms such as
Gartner, Forrester and The Burton Group to talk about Secure Software
Testing as a research area? Many CIOs and other IT executives put lots
of value into what they say. We need more top down.

3. What would it take to get more speaker diversity? We have to figure
out how to get more end-customers telling their own stories vs vendors
and consulting firms

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paco Hope
Sent: Thursday, August 16, 2007 1:41 PM
To: Secure Coding
Subject: [SC-L] Security Testing track: Software Testing
Conference:Washington DC


Hey folks,

One of my strong beliefs is that we're never going to close the loop on
"Building Security In" until we get the QA side of the house involved in
security. To that end, I'm co-chairing VERIFY 2007, a software testing
conference where we have a security testing track. (In addition to more
typical QA issues like test automation) I thought some folks on this
list may be interested in attending, or passing it on to your colleagues
in QA organizations.

Conference web site is http://verifyconference.com/ and you can get a
2-page "Conference in a Nutshell" PDF here:
http://verifyconference.com/images/verify/verify2007.pdf

Please help me spread the word.

Thanks,
Paco
--
Paco Hope, CISSP
Co-Chair, VERIFY 2007
http://verifyconference.com/ * +1.703.606.1905


*
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] Software Security Training for Developers

[McGovern, James F (HTSC, IT)]

My general observation of training firms in this area is that they all
tend to use freelance trainers who float between the firms. The notion
of customized courseware is something they sell as a feature but
honestly feels more like a way to avoid actually developing consistent
training approaches where they instead rely on the individual hired
trainer and what they happen to feel comfortable teaching.
 
The issue with training in the language/platform of choice gets more
difficult depending upon what type of environment you reside. If you
look inside the average Fortune enterprise whose primary business model
isn't technology (e.g. Intel, IBM, Microsoft, etc) then you will tend to
find lots of variety of languages used in production environments with
no language (with the exception of possibly COBOL) being dominant. This
simple fact causes enterprises who have a variety of languages when
combined with the need for across the board training to make training
non-specific to any particular language.
 
Many of the tools also give feedback in a language-specific context
while writing code, so at some level I do believe that language-specific
training is not required.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of McCown, Christian M
Sent: Thursday, August 16, 2007 7:23 PM
To: sc-l@securecoding.org
Subject: [SC-L] Software Security Training for Developers




What are folks' experiences with software security training for
developers?  By this, I'm referring to teaching developers how to write
secure code.  Ex. things like how to actually code input validation
routines, what "evil" functions and libraries to avoid, how to handle
exceptions without divulging too much info, etc.  Not "how to hack
applications".  There are quality courses and training that show you how
to break into apps--which are great, but my concern is that if you are a
developer (vs. a security analyst, QA type, pen-tester, etc.),even when
you know what could happen, unless you've been specifically taught how
to implement these concepts  in your language/platform of choice (ASP
.NET, C#, Java, etc.), you're not getting the most bang for the buck
from them.


What vendors teach it? 
How much does it cost? 
Actual impact realized? 

Tx 

 
Chris McCown, GSEC(Gold) 
Intel Corporation 
* (916) 377-9428 | * [EMAIL PROTECTED]   



*
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] Software Security Training for Developers

[McGovern, James F (HTSC, IT)]

One of the things that is somewhat frustrating as a customer to training
and software vendors are statements such as "some general policy and
guidelines" without any pointers to what they should specifically
contain. Public URLs are greatly appreciated.




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nish Bhalla
Sent: Thursday, August 16, 2007 11:21 PM
To: 'McCown, Christian M'
Cc: sc-l@securecoding.org
Subject: Re: [SC-L] Software Security Training for Developers



Hi Chris,

 

We at Security Compass have been doing that for developers for about 2
years now. We have done this type of training and also the training from
the pen tester angle. 

 

Some of the things that we have seem make this training much more
effective are

 

[] If the direction for the training and security initiative is coming
in from the top rather than just from one manager (not to say that
having it from one manager doesn't help)

[] If there are some general policy and guidelines to building secure
software

[] If there are general guidelines to build secure architecture

[] if there are though processes in place for updating the existing SDLC
with security in place to improve the overall direction of the company
towards a more secure application development practice

[] Finally if the training is developed around these kind of practices
and customized to your specific environment.

 

We also think providing different kinds of training for different levels
of people is important, i.e. a training for managers, a training for
architects, a training for QA/Security professionals and finally a
training for developers. Each has a specific goal in mind and speaking
in the individual language so to speak to each group.

 

Hope this helps, If you would like to chat more just email me.

 

Nish.



*
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] how far we still need to go

[McGovern, James F (HTSC, IT)]

 Many folks have talked about certification of individuals but is there
merit in noodling the notion of a security maturity model? What if
end-customers could rank their software vendors in a transparent manner
in the same way that outsourcing firms pursue CMMi? 

The notion of third-party assessors that determine this form of
certification could be supplemental revenue for those who are employed
by consulting firms. Could be similar to SCRUMAlliance certification if
you prefer something lighter weight.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ljknews
Sent: Wednesday, July 25, 2007 10:23 PM
To: SC-L@securecoding.org
Subject: Re: [SC-L] how far we still need to go

At 2:03 AM +0100 7/26/07, Dinis Cruz wrote:
> It's a simple economics problem. The moment these companies and 
>developers lose sales (or market share) because their products require 
>admin / root privileges to run, is the moment they start to REALLY 
>support it.

For Windows that day might be when they have to run under the new US
federal government standard Windows configuration, due out any month
now.
--
Larry Kilgallen


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

[SC-L] Really dumb questions?

[McGovern, James F (HTSC, IT)]

Most recently, we have met with a variety of vendors including but not
limited to: Coverity, Ounce Labs, Fortify, Klocwork, HP and so on. In
the conversation they all used interesting phrases to describe they
classify their competitors value proposition. At some level, this has
managed to confuse me and I would love if someone could provide a way to
think about this in a more boolean way.

- So when a vendor says that they are focused on quality and not
security, and vice versa what exactly does this mean? I don't have a
great mental model of something that is a security concern that isn't a
predictor of quality. Likewise, in terms of quality, other than
producing metrics on things such as depth of inheritance, cyclomatic
complexity, etc wouldn't bad numbers here at least be a predictor of a
bad design and therefore warrant deeper inspection from a security
perspective?

- Even if the rationale is more about people focus rather than tool
capability, is there anything else that would prevent one tool from
serving both purposes?

- Is it reasonable to expect that all of the vendors in this space will
have the ability to support COBOL, Ruby and Smalltalk sometime next year
so that customers don't have to specifically request it?

- Do the underlying compilers need to do something different since
languages such as COBOL aren't object-oriented which would make analysis
a bit different?


*
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] Software process improvement produces secure software?

[McGovern, James F (HTSC, IT)]

One thing that I am firm in my belief is that process is not a substitute for 
competence. Imagine taking lots of overweight IT guys and training them to ride 
a horse. That doesn't mean that they will go on to become successful horse 
jockeys and you would be dumb to bet on them.
 
In terms of CMMi, my thought says that buyers of consulting services and 
enterprise software need an independent way of quantifying what they are buying 
from a security perspective. While the logic used in outsourcing is flawed, 
buyers still prefer outsourcing firms that have higher levels of CMMI than 
those that don't. 
 
In the same way this listserv attempts to help folks write secure software, we 
need a way to help folks also procure secure software and stealing some aspects 
of CMMi while compromising some level of integrity will have lift in the long 
run.



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goertzel, Karen
Sent: Tuesday, August 07, 2007 9:39 AM
To: sc-l@securecoding.org
Subject: Re: [SC-L] Software process improvement produces secure software?



I've always had a question about this as well; specifically, what is really 
meant by "adding security to a CMM"?

I've always felt that the level at which the software (or system) process is 
defined by a CMM is too high and too abstract for the addition of security 
activities to be particularly meaningful.

My feeling is that a CMM is best used as a means of ensuring that the more 
detailed life cycle process is implemented in a disciplined manner, and that 
the amount of benefit, in terms of improvement of whatever property one is 
trying to improve - quality, reliability, security, safety - of the 
system/software that results from the process can be measured.

Where the actual security activities need to be defined and added are to the 
life cycle methodology. At best, adding security to a CMM can provide a very 
high level framework for helping someone who is "shopping" for a life cycle 
methodology know what to look for in that methodology. Is a CMM necessary for 
that purpose? I'm not convinced that it is.

I think what is likely to be more effective is a change in outlook by the 
practitioners who will be using the life cycle methodology. Their outlook needs 
to change so that a single question is asked before any choice or decision is 
made: What are the security implications of the choice/decision?

Of course, there's much more to it than just asking that question. And that's 
the reason we need to train developers, testers, etc. to (1) understand what 
"security" means, both at the software and system levels; (2) visualise and 
recognise the possible impact(s) each of their choices/decisions could have on 
the security of the system they are building (before the fact); (3) recognise 
the impacts each of their choices/decisions has had on the security of the 
system they have built (after the fact). Tools and techniques to help 
developers do the second and third of these are proliferating (e.g., threat 
modeling, attack trees, etc. for before-the-fact; analysis and testing tools 
for after-the-fact). But in the end, I believe the #1 factor that will 
contribute to the increased security of software is the developer's mentality. 
A security-aware...and more importantly, a security-*concerned&...developer is 
more likely to (1) avoid making bad choices and decisions, and (2) to take an 
interest in, and pursue becoming, knowledgeable enough to correct bad choices 
that he/she did not avoid making earlier.

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
[EMAIL PROTECTED]




-Original Message-
From: [EMAIL PROTECTED] on behalf of Francisco Nunes
Sent: Tue 07-Aug-07 07:01
To: sc-l@securecoding.org
Subject: [SC-L] Software process improvement produces secure software?

Dear list members.

In june 2007, I had an interesting conversation with
Mr. Will Hayes from SEI during the Brazilian Symposium
on Software Quality. It was a great experience and I
am very grateful for this.

During our conversation, I made a question to Mr.
Hayes similar to this: "Is it possible that only
software development process improvements can produce
secure software?"

The scenario was only based on CMMI without security
interference.

His answer to this question was "YES". My answer was
"I DO NOT THINK SO".

His answer made me confuse and I had no arguments,
mainly, because my professional experience in software
process does not compare to Mr. Haye's experience.

Unfortunately, I also haven't found any statistics
which could answer this question. Please, if there is
one, let me know!

So, how about you, list members? What are your answers
to the question above?

I will try to organize your answers and present the
final result.

Thank you.

Yours faithfully,
Francisco José Barreto Nunes.


  Alertas do Yahoo! Mail em seu celular. Saiba mais em 
http://br.mobile.yahoo.com/mailalertas/

[SC-L] Two Questions around Consulting on Secure Coding

[McGovern, James F (HTSC, IT)]

I would like to gain a perspective from the various software vendors as
to which consulting firms they believe have the best expertise in
assisting clients with rollout of their tools. I hope that a couple of
names will appear across software vendors. I am also hoping one or two
names will emerge across vendors as common.

I know asking a question that is related to consulting but where an
answer from a consulting firm isn't required will compel consultant
types to respond, I figured I would also ask another question in which
they may have better perspective.

I am seeking a developer-level resource for a three month onsite
consulting engagement (initial) to operationalize our rollout of tools
that enable secure coding. Candidates should have the following
characteristics:

Knowledge and hands-on administration experience using Fortify Software,
Coverity, Ounce Labs, HP DevInspect, etc (We haven't chosen the tool
yet)
Ability to program in both Java and .NET languages
Ability to do presentations to other software developers on secure
coding topics
Strong analytical and logical thinking capability
Work indepedently and under little supervision / guidance and take on
technical lead role as needed
Ability to produce written documentation on technical alternatives
API design and implementation. Familiarity with XML, XML Schema, XSL or
other XML tools a plus.
Hourly rate depending on actual experience in a security context

Will need resumes emailed to me  by Friday, September 7th. Please also
include hourly rate. Not looking for candidates higher on the food chain
to do "strategy" , "POC", etc but developer-types to help with
operational aspects with rates inline with this notion.


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

[SC-L] Question on the importance of secure coding

[McGovern, James F (HTSC, IT)]

Figured I would ask the list for their perspective on why the adoption
of secure coding practices is so slow.

Generally speaking, not a day goes by where multiple software vendors
will email, snail mail, phone, etc their value proposition to some
problem in the world of security. They usually do a good job in terms of
identifying common gaps across enterprises yet have no clue as to
whether this gap is important to the enterprise to close.

If I were to ask my colleagues to enumerate gaps, I suspect it would be
too difficult to compose a list of several hundred distinct gaps in the
security space. The issue at hand is not whether the gap exists, whether
there are solutions to close it but one of which gaps are most important
to close.

Likewise, industry analysts do a great job of comparing products within
a domain. They will compare Fortify to Ounce Labs and so on. The thing
that is missing is how "should" secure coding compare to say identity
management or entitlements management or user-centric identity or
protecting against the insider threat and so on.

In some enterprises, the constraint for closing gaps can be funding
while pretty much in all enterprises the constraint in terms of closing
gaps is having the right resources. While everything is important, how
should one determine what is more important?

If we believe that secure coding is more important than how do we
collectively not only talk about it amongst ourselves but also get
industry analysts to also start saying it is more important vs resorting
to product comparisons. Likewise, magazines should also take a similar
approach. After all, many folks on this list understand that the vast
majority of decision makers nowadays don't necessarily come from a
technical background and at some level practice Management by Magazine
and therefore we should help them to be successful...


*
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] IT industry creates secure coding advocacy group

[McGovern, James F (HTSC, IT)]

 I publicly support Gunnar's assertion that folks in large enterprises
need to get together as a collective to drive secure coding practices.
If you know of others, please do not hesitate to have them connect to me
via LinkedIn (I am bad with managing contact information) and I will
most certainly take the lead...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gunnar Peterson
Sent: Tuesday, October 23, 2007 3:08 PM
To: Kenneth van Wyk; Secure Mailing List
Subject: Re: [SC-L] IT industry creates secure coding advocacy group

Hi Ken,

I thought the driving force was your book, after all they named their
initiative after it.

Anyhow, I'll reiterate here what I blogged:

It would be very interesting to see an equivalent initiative from the
customer side (who are the lucky recipients who have to pay for all the
security vulns created by the above). I know as a consultant there are
many large companies struggling with similar secure coding issues
exacerbated by outsourcing to some degree, and a lot could be gained by
a shared effort.
The analyst community like the vendors has more or less Fortune 500s out
in the dark, so this may be an area where a half dozen or so motivated
security architects and CISOs at Fortune 500s could band together to
create a group to help drive change. None of the other big players
(analysts, vendors, big consulting firms) seem to be doing it. Why not
bootstrap a Fortune 500 Secure Coding Initiative to drive better
products, services and share best practices in the software security
space?

-gp


On 10/23/07 1:55 PM, "Kenneth Van Wyk" <[EMAIL PROTECTED]> wrote:

> Saw this story via Gunnar's blog (thanks!):
> 
> http://www.gcn.com/online/vol1_no1/45286-1.html
> 
> Any thoughts on new group, which is calling itself SAFEcode?  Anyone 
> here involved in its formation and care to share with us what's the 
> driving force behind it?
> 
> Cheers,
> 
> Ken
> 
> -
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.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.
> ___



On 10/23/07 1:55 PM, "Kenneth Van Wyk" <[EMAIL PROTECTED]> wrote:

> Saw this story via Gunnar's blog (thanks!):
> 
> http://www.gcn.com/online/vol1_no1/45286-1.html
> 
> Any thoughts on new group, which is calling itself SAFEcode?  Anyone 
> here involved in its formation and care to share with us what's the 
> driving force behind it?
> 
> Cheers,
> 
> Ken
> 
> -
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.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.
> ___

--
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net

Blog: http://1raindrop.typepad.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.
___


*
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 communit

[SC-L] Mainframe Security

[McGovern, James F (HTSC, IT)]

 I was thinking that there is an opportunity for us otherwise lazy
enterprisey types to do our part in order to promote secure coding in an
open source way. Small vendors tend to be filled with lots of folks that
know C, Java and .NET but may not have anyone who knows COBOL.
Minimally, they probably won't have access to a mainframe or a large
code base. 

Being an individual who is savage about being open and participating in
a community, I would like to figure out why my particular call to action
is. What questions should I be asking myself regarding our mainframe,
how to exploit, etc so that I can make this type of knowledge open
source such that all the static analysis tools can start to incorporate?


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

[SC-L] OWASP Publicity

[McGovern, James F (HTSC, IT)]

I have observed an interesting behavior in that the vast majority of IT
executives still haven't heard about the principles behind secure
coding. My take says that we are publishing information in all the wrong
places. IT executives don't really read ACM, IEEE or other the sporadic
posting from bloggers but they do read CIO, Wall Street Journal and most
importantly listen to each other.

What do folks on this list think about asking the magazines and
newspapers to publish? I am willing to gather contact information of
news reporters and others within the media if others are willing to
amplify the call to action in terms of contacting them. 



*
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] OWASP Publicity

[McGovern, James F (HTSC, IT)]

The vast majority of IT executives are unfamiliar with all of the
principles of security, firewalls, coding, whatever.

Are they unfamiliar because of background or they feel that their staff
has a handle on it and therefore don't need to pay much atention to it.
Both have different characteristics in terms of getting the word out.

The important thing to understand is that such principles are below
their granularity; then are *right* to not care about such principles,
because they can't do anything about them. Their granularity of decision
making is which products to buy, which strategies to adopt, which
managers to hire and fire. Suppose they did understand the principles of
secure coding; how then would they use that to decide between firewalls?
Web servers? Application servers?

Executives don't need to care about the details but they can care enough
to embrace the notion of procuring secure software. They can care about
the fact that much of their code that they outsource doesn't have any
metrics attached to them and that acceptance shouldn't be on meeting
functionality alone.

If anything, the idea that needs to be pitched to IT executives is to
pay more attention to "quality" than to shiny buttons & features. But
there's the rub, what is "quality" and how can an IT executive measure
it?

The best way for IT executives to measure things are metrics that
indicate a trend. Regardless of what they decide to measure, it should
trend positive.

I have lots of informal metrics that I use to measure quality, but they
largely amount to synthesized reputation capital, derived from reading
bugtraq and the like with respect to how many vulnerabilities I see with
respect to a given product, e.g. Qmail and Postifx are extremely secure,
Pidgin not so much :)

But as soon as we formalize anything like this kind of metric, and get
executives to start buying according to it, then vendors start gaming
the system. They start developing aiming at getting the highest
whatever-metric score they can, rather than for actual quality. This
happens because metrics that approximate quality are always cheaper to
achieve than actual quality.

This is a very, very hard problem, and sad to say, but pitching articles
articles on principles to executives won't solve it.

My notion wasn't just pitching to them as this is what has occured to
date. I was also suggesting that the media take on secure coding has to
go well beyond the frequent consultant and vendor types that post here.
If you think for a moment about other successful marketing campaigns in
IT such as CMMi, ITIL, etc, the vast majority of executives know and
embrace it but can't tell you who even invented it as the community let
it grow past the founding members. We haven't yet came to same
realization here...

Crispin

--
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work





*
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] Code Coverage and Code Quality tools

[McGovern, James F (HTSC, IT)]

I think you will see static analysis tools such as Ounce Labs and
Fortify emerge with COBOL coverage shortly. I do think it would be
intriguing for them to extend their coverage to PL1 though. Assembler
and Natural would be a waste of time as most enterprises that do have
mainframes should have upgraded back in the 80s




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of avi shvartz
Sent: Sunday, December 09, 2007 3:38 AM
To: sc-l@securecoding.org
Subject: [SC-L] Code Coverage and Code Quality tools



Hello list,

Apologies if a little bit off topic, but I will appreciate any help.

I wonder what tools are used for Code Coverage and Code Quality for 

 various languages in the enterprise.
IBM mainframe : COBOL, PL1, NATURAL, ASSEMBLER, JAVA.

Open : JAVA, VB6, C++, C#, VB.NET..

Regards,

Avi Shvartz



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

[SC-L] Interesting Blog Entry on Tools Coverage

[McGovern, James F (HTSC, IT)]

 http://www.matasano.com/log/906/random-thoughts-on-owasp


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

[SC-L] Secure Coding in the Hartford CT Area

[McGovern, James F (HTSC, IT)]

 I am launching the Hartford CT area chapter of OWASP and figured I
would ask if anyone on this list is from my side of town. Likewise, if
you know of others that would like to attend our users group, have them
subscribe to our mailing list: http://www.owasp.org/index.php/Hartford

I am pretty well connected to the enterprisey folks but tend to not run
across the local startups, small shops, the university professor crowd,
game development companies, etc.


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

[SC-L] OWASP: The Application Security Desk Reference

[McGovern, James F (HTSC, IT)]

OWASP needs your help with a new important project.

We're creating the OWASP Application Security Desk Reference (ASDR) to
capture and organize all the foundational knowledge in application
security. Like the Physicians' Desk Reference for doctors, this book is
a well-organized reference work that anyone working in application
security will want on their desk.

The OWASP ASDR covers application security principles, threat agents,
attacks, vulnerabilities, controls, technical impacts, and business
impacts. A 900-page alpha draft is available for your review. We need
your help to get a final version created by August 25, 2008!

Here is a link to the draft: http://www.lulu.com/content/2538516


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

[SC-L] Silver Bullet

[McGovern, James F (HTSC, IT)]

Wouldn't it be interesting if upcoming Silver Bullets featured CIOs and
Enterprise Architects of Fortune enterprises? The perspectives regarding
secure coding are complimentary yet different...


*
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] Silver Bullet

[McGovern, James F (HTSC, IT)]

 Women to include are:

Diana Kelley of SecurityCurve
Chenxi Wang of Forrester
Window Synder of Mozilla
Mary Ann Davidson of Oracle

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gary McGraw
Sent: Monday, September 29, 2008 12:21 PM
To: McGovern, James F (HTSC, IT); SecureMailing List
Subject: Re: [SC-L] Silver Bullet

Good idea James.  If you take a look at the list of victims, you'll see
a mix of academics, gurus, and CSOs.  My next victim (Matt Bishop) is
already slated.  After that I will see what I can do to get a CIO for
November.

BTW, if anyone has suggestions along those lines, I'm all ears.  I would
particularly like to get more women on the podcast.

gem



*
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] (fwd) informIT: A Software Security Framework

[McGovern, James F (HTSC, IT)]

 The framework that Pravir put together is pretty good. Brian and I did
have a conversation awhile back regarding donating it to OWASP for
continuation. I plan on making our firm one of the public case studies
once they contribute. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk
Sent: Wednesday, October 15, 2008 8:32 AM
To: Secure Coding
Subject: [SC-L] (fwd) informIT: A Software Security Framework

[Posted on behalf of Gary McGraw, who is without comms right now but
wanted this to go out today. KRvW]

hi sc-l,

Brian Chess and I have been working hard on a software security
framework that we are using in a scientific study of many of the top
software security initiatives.  Our plan of action is to interview the
people running the top ten large-scale software security initiatives
over the next few weeks and then build a maturity model with the
resulting data.

That's right, we're actually using real data from real software security
programs.

Brian and I co-authored my informIT column this month, which just so
happens to be about the software security framework.  Please check it
out, we're interested to know what you think!

http://www.informit.com/articles/article.aspx?p=1271382

gem

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





*
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] Language agnostic secure coding guidelines/standards?

[McGovern, James F (HTSC, IT)]

 Awhile back, I got asked the same question and realized that at some
level the question is flawed. Many large enterprises have standards
documents that sit on the shelf and the need to create more didn't feel
right. Instead, we feel to the posture that we should inverse the
problem and instead find a tool that automates the code review process
(aka static analysis) where we can not only measure compliance to the
standard but get the standards off the shelf.

In terms of products, check out Ounce Labs, Coverity, Klocwork, etc.
Most will have coverage for C, Java, .NET, etc. The challenge with some
of the other languages you have is that pretty much no one in the
security community has ever spent much time analyzing the weaknesses in
COBOL. There is some stuff out there, but it is light when compared to
Java...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pete Werner
Sent: Wednesday, November 12, 2008 7:22 PM
To: Secure Coding
Subject: [SC-L] Language agnostic secure coding guidelines/standards?

Hi all

I've been tasked with developing a secure coding standard for my
employer. This will be a policy tool used to get developers to fix
issues in their code after an audit, and also hopefully be of use to
developers as they work to ensure they are compliant. The kicker is it
needs to cover things ranging from cobol running on a mainframe, in
house network monitoring software in c and perl through to web and
desktop applications in java or .net.

I've been doing some searching to see if there is anything similar
online, but everything i've found is mostly focussed on web applications
or language/platform specific. Does anyone know of something that may be
what I'm looking for?

It's basically going to be a checklist where every item will be
something that can be audited, and the things that aren't relevant to a
given application can be ignored. The broad sections I have so far
are:

Input/Output handling
Session Control and Management
Memory allocation and Management
Authentication Management
Authorisation Management
Data Protection
Logging and Auditing
Application Errors and Exceptions

Thanks in advance
Pete


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] How Can You Tell It Is Written Securely?

[McGovern, James F (HTSC, IT)]

Enumerating all of the potential weaknesses in software as a requirement
to be put into a contract is somewhat problematic on several levels. I
guess you can take something like CWE as a starting point and filter
down the headers to thinks that only apply to your particular
implementation.  A better approach would be to filter providers based on
security before you even get to the contract stage. For example, ask if
they would be willing to procure a copy of a static analysis tool from a
vendor such as Ounce Labs, Coverity, etc and then check on the backside
to see how many seats they have purchased (e.g. reference check).
 
You can also use as a "proxy" the level of participation by inquiring
how deeply and frequently do they participate in local user groups such
as OWASP. If they have folks that speak at OWASP events, then they are
probably much more security conscious than those who don't. If they
don't speak but do attend, that is also better than simply getting the
person on the asian vendors side simply telling you whatever is required
to close the deal.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Manico
Sent: Thursday, November 27, 2008 4:38 PM
To: Mark Rockman
Cc: Secure Mailing List
Subject: Re: [SC-L] How Can You Tell It Is Written Securely?


>  OK.  So you decide to outsource your programming assignment to Asia
and demand that they deliver code that is so locked down that it cannot
misbehave.  How can you tell that what they deliver is truly locked
down?  Will you wait until it gets hacked?  What simple yet thorough
inspection process is there that'll do the job?  Doesn't exist, does it?

This most important thing you can do is provide very specific security
requirements as part of your vendor contract BEFORE you hire a vendor -
and the process of building these security requirements might call for
bringing in a security consultant if you do not have the expertise
in-shop.

Requirements that allow a vendor to actually provide security are line
items like (assuming its a web app):

"Provide input validation for every piece of user data. Do so by mapping
every unique piece of user data  to a regular expression that is placed
inside a configuration file." 
"Provide CSRF protection by creating and enforcing a form nonce for
every user session"

After you build this list for your company, it should provide you with a
core list of security requirements that you can add to any PO.

- Jim



 
 
MARK ROCKMAN
MDRSESCO LLC  




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



-- 
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security(tm)
Securing your applications at the source
http://www.aspectsecurity.com

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] FW: How Can You Tell It Is Written Securely?

[McGovern, James F (HTSC, IT)]

 Asking about security in terms of an RFP is a big joke and reminds me
of tactics I used in sixth grade when I used to figure out creative ways
of answering a question by turning the question into an answer. One has
to acknowledge that RFPs are not authoratative and are usually completed
by sales teams who don't have adequate detail.

So, instead of focusing on comprehensive documentation, you need to be
agile and think more about working software. I believe that penetration
tests are sadly too late in the process in order to be meaningful and
only have value in scenarios where you can mandate that the presses be
stopped and that they fix immediately before you give them a single
penny.

Avoid the contract stuff as well as you can't really put meaningful
things into agreements. You have to acknowledge that if I were
successful in putting say a clause into our next EMC agreement requiring
all document management software to support XACML and be OWASP Top Ten
free, do you think that a developer on the other end would even have a
chance to read it and address going forward? Way too many degrees of
separation between those who write contracts and those who implement
software.

Again, I think you need to measure developers and their participation in
groups such as OWASP since it is observable and measurable without
requiring a lot of effort. It is not a guarantee but can be a
predictor...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Herman Stevens
Sent: Monday, December 01, 2008 1:55 PM
To: Marcin Wielgoszewski
Cc: SC-L@securecoding.org
Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely?

Hello Marcin,

I agree with your statement that many companies have some requirements
in their SLA's with outsourced development firms. However, if these are
really F-100 businesses they usually have all non-core processes
out-sourced (because a Big4 company told them that would reduce costs),
the relationship management with the outsourced companies is also
out-sourced (probably to the same Big4). This means after a few years
all knowledge has left the company and if a Request For Proposal needs
to be written (e.g. for a new application supporting their core business
functions) this is outsourced again to the same Big4 since the company
itself does not even have the required knowledge to write its own RFPs
..

I really doubt that anything that goes in that RFP (and ultimately in
the contracts) will have any _real_ security value. 

Using penetration tests and vulnerability requirements might be part of
the acceptance process, but I do not call these tests _security_
requirements. They are acceptance requirements ...

The original request asked for how can someone determine if an
application is written in a secure manner. My reasoning is that this is
the wrong question (the application must _be_ secure and for this there
is no direct link with coding practices). And even if one can proof the
application is written in a secure manner, this will not be enough to be
secure (e.g. about 99% of all security relevant features are nowadays in
the configuration, the customer will never issue a change request for a
new java library of javascript library yet in many of my penetration
tests I 'break' the application because of old libs, ...).  

I do not think that penetration tests and vulnerability assessments are
a 'proof' that an application is written securely. I've seen many
applications that were written horrendously but were very secure (in the
sense that they abided to all security-relevant business requirements)
and I have seen many applications written using the 'best practices' in
coding and developed with very mature processes that could be hacked in
minutes.

So, are there any studies that proof that a company that performs some
tests (e.g. pen-tests) or include security requirements in the contracts
ultimately is better off than a company that does not do what we
consider 'best practices'? And if we don't have that proof, shouldn't we
be very prudent in what we advise to our customers? 

Please note that my company sells security related software and performs
vulnerability assessments, so I'm not saying that these are useless
(:)), but maybe there are better methods than penetrate & patch or
enforcing very heavy processes on innocent development teams... So, this
is question to this list: Are we on the right track? Is application
security really improving? Do we measure the correct things and in the
correct way? My point of view is that only certain vulnerabilities are
less common than in the early days just because of more mature
frameworks, but not due to better processes or after the fact testing.
Does this mean all efforts were vain? Or did the threat landscape
change? And yes, there are many vendor driven statistics floating around
but they really cannot be considered unbiased ... Lots of questions,
maybe not all relevant for the Secure Coding list, but Secure 

Re: [SC-L] FW: How Can You Tell It Is Written Securely?

[McGovern, James F (HTSC, IT)]

I am of the belief that the examples you provided are more requirements
for your own staff. For example, shouldn't your business analysts define
regular expressions and include them as functional requirements where
the firm simply calls them?

If you want regex's externalized into properties files, shouldn't this
be more about specifying acceptance criteria for the overall design vs
waiting to measure it against code.

For number three, you would have to think about such a clause as it is
an out if performance isn't met. 

If you work for a large enterprise, I would think that number 4 would be
encompassed into asking them to align with consistent DB access
practices where you hand them your coding standards. 

It is different to have coding standards and having clauses that ask
others to adhere to them vs embedding coding type requirements into the
contracts themselves.

-Original Message-
From: Jim Manico [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 01, 2008 4:44 PM
To: McGovern, James F (HTSC, IT)
Cc: SC-L@securecoding.org
Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely?

I think adding clear security requirements at the contractual level is
*fundamental and necessary* when yes?
yesworking with vendors who are writing software for you.

Don't we talk about software security as being just another integrated
part of writing software, not as an external activity?

I'm not talking about foolish general requirements like "Be OWASP top 10
free" that does not help anyone.

I'm talking about clear, somewhat undebatable requirements like:

1) Add in CSRF protection by using a form nonce
2) Make every field maps to a unique regular expression.  Ensure that
this regular expression exists in a properties file so it can be
configured without needing to recompile code.
3) Ensure that every piece of user-driven data is encoded via HTML
Entity Encoding before it is displayed to any user.
4) Use only prepared statements and binding of variables when selecting
from a database

Etc.

Sure, we want our vendors to be security educated (good luck finding
them these days). But really, we need to get the job done. We need to
hire vendors. It's likely that software development vendors are not
super security educated since software security is so new. We need to
communicate contractual requirements anyways and those agreements do
indeed matter. Our best bet is to add in clear functional security
requirements to our contractual agreements if we have any hope of them
being built in in a cost effective manner.

- Jim



>  Asking about security in terms of an RFP is a big joke and reminds me

> of tactics I used in sixth grade when I used to figure out creative 
> ways of answering a question by turning the question into an answer. 
> One has to acknowledge that RFPs are not authoratative and are usually

> completed by sales teams who don't have adequate detail.
>
> So, instead of focusing on comprehensive documentation, you need to be

> agile and think more about working software. I believe that 
> penetration tests are sadly too late in the process in order to be 
> meaningful and only have value in scenarios where you can mandate that

> the presses be stopped and that they fix immediately before you give 
> them a single penny.
>
> Avoid the contract stuff as well as you can't really put meaningful 
> things into agreements. You have to acknowledge that if I were 
> successful in putting say a clause into our next EMC agreement 
> requiring all document management software to support XACML and be 
> OWASP Top Ten free, do you think that a developer on the other end 
> would even have a chance to read it and address going forward? Way too

> many degrees of separation between those who write contracts and those

> who implement software.
>
> Again, I think you need to measure developers and their participation 
> in groups such as OWASP since it is observable and measurable without 
> requiring a lot of effort. It is not a guarantee but can be a 
> predictor...
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Herman Stevens
> Sent: Monday, December 01, 2008 1:55 PM
> To: Marcin Wielgoszewski
> Cc: SC-L@securecoding.org
> Subject: Re: [SC-L] FW: How Can You Tell It Is Written Securely?
>
> Hello Marcin,
>
> I agree with your statement that many companies have some requirements

> in their SLA's with outsourced development firms. However, if these 
> are really F-100 businesses they usually have all non-core processes 
> out-sourced (because a Big4 company told them that would reduce 
> costs), the relationship management with the outsourced companies is 
> also out-sourced (probably to the same Big4). This means after a few 
> years all knowledge has

Re: [SC-L] FW: How Can You Tell It Is Written Securely?

[McGovern, James F (HTSC, IT)]

Some other thoughts that I haven't heard others mention?

1. OK, if you find that they didn't meet all the security requirements,
will your business customers still want you to put it into production
anyway? If the answer is yes, do you still want them to support it? How
do we quantify who is responsible if a breach happens and you gave them
a waiver.

2. security clauses have a side effect in contracts that others need to
noodle. If you have a clause that can only be measured over a longer
timespan, it tickers with revenue recognition. So, how long do you want
folks to certify that things are secure.

3. I like secure coding as much as the next guy and checking for CSRF is
a good thing. How about noodling requirements around logging such that
if they didn't get it right upfront that you at least have something
forensically useful for after the fact?

4. While we are all developers, do you think there is merit in
addressing roles of vendors especially non-development? For example, is
it valuable to have them have on staff a security architect with lots of
credentials that is separate from the development lifecycle (distinct
from being totally ivory tower or hands-off)?

5. How much more are folks willing to pay to build security in? This
kinda doesn't align with going offshore to get cheapest resource. It is
in their best interest to be an impediment to this goal and you need to
define things in a more friendly manner. Coming out of the gate by
throwing others under the bus probably will not get you what you desire
(of course, it is a tactic I use way too much)

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] OWASP interviews McGraw (oh my)

[McGovern, James F (HTSC, IT)]

 Some questions that I would have asked:

1. The trend towards offshoring software development is increasing. When
do you think customers will be able to have confidence in the ability of
outsourcing vendors to develop secure software without it being
considered a "special" service?

2. Do you think industry analysts and the media at large are doing a
good enough job of helping raise awareness? What do you think magazines
such as InformationWeek, CIO and Forbes should be doing that they
aren't?

3. While you are an employee of Cigital, what other security firms do
you think offer high quality consulting services in this space?

4. Many organizations no longer budget for "developer" tools. Do you
think that static analysis will fail economically if funding for
development has shifted away from developer activities?

5. What are the gaps that OWASP and other security-oriented communities
aren't yet thinking about?

6. Name some examples of Fortune enterprises whom you think are thinking
about software security correctly?

7. Microsoft is the industry whipping boy and if we acknowledge that
customers may not want them to be more secure as core changes may break
backward compatibility, is software security always doomed to
mediocrity?

8. To become a competent software security professional, what do you
think the ideal career path looks like?

9. What bloggers do you think can bring insight into understanding
secure coding practices?

10. Any opinions on whether Sun, EMC, Oracle and CA are making adequate
progress towards software security being built into their products?

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw
Sent: Monday, January 26, 2009 12:59 PM
To: Secure Code Mailing List
Subject: [SC-L] OWASP interviews McGraw (oh my)

hi sc-l,

OWASP just posted an interview with me as part of their budding podcast
series.  It's nice to have the tables turned after doing all the Silver
Bullet (and Reality Check) interviews!  It's also nice to be able to
answer some of the questions that OWASP types have about Cigital's
approach to software security.

Download the podcast here: https://www.owasp.org/index.php/Podcast_5

The OWASP interviewer is Jim Manico, and he did a great job.  He was a
little worried about some of the questions he asked.  In fact, off the
record he kept saying he was sorry and telling me that I did not have to
address certain questions.  Personally, I enjoyed the questions he asked
immensely.  Though some of his questions were loaded, I do hope that my
answers may serve to clarify our position and eliminate OWASP concerns.

Here are a few of the many more questions I address in the podcast:

 *   Why do you insist on use of the term "software security" as opposed
to "application security"?
 *   What is static analysis good for and what is it no good for?
 *   What is the exact relationship between Cigital and Fortify?
 *   Why do you think your "top 19" is any better than the OWASP top 10
or the CWE top 25?  (Special note, the 19 Sins work is Mike Howard's and
John Viega's...I was not involved.)
 *   Why does Cigital have a proprietary approach to IP?
 *   What makes the Touchpoints any better than the SDL or CLASP?
 *   What is your relationship with Allan Paller and SANS?
 *   Who picked the "porn music" theme for Silver Bullet?

As an extra bonus, the theme music for this episode is a song written
and recorded by my band Where's Aubrey.

Anyway, enjoy the podcast, and let me know what you think about my
answers!

gem

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

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 host

[SC-L] OWASP Hartford: Scott Ambler - Agility and Security: Two Great Tastes Which Go Great Together

[McGovern, James F (HTSC, IT)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-05.00) Eastern Time (US & Canada)
X-MICROSOFT-CDO-TZID:10
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20090330T143451Z
DTSTART;TZID="(GMT-05.00) Eastern Time (US & Canada)":20090413T16
SUMMARY:OWASP Hartford: Scott Ambler - Agility and Security: Two Great Tast
 es Which Go Great Together
UID:04008200E00074C5B7101A82E00800C2F6766DA1C901000
 01000B14FB087881D2045868040C7C5345AF0
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Secure Co
 ding":MAILTO:SC-L@securecoding.org
ORGANIZER;CN="McGovern, James F (HTSC, IT)":MAILTO:james.mcgov...@thehartfo
 rd.com
LOCATION:The Hartford: 55 Farmington Avenue\, The Great Room
DTEND;TZID="(GMT-05.00) Eastern Time (US & Canada)":20090413T18
DESCRIPTION:The Hartford Chapter of OWASP is pleased to announce Scott Ambl
 er as our first speaker of the year. This event is 100% free to attend. Se
 ating is limited. We will be starting promptly at 4pm…\N\NAgility and Se
 curity: Two Great Tastes Which Go Great Together\N\NSecurity is usually an
  afterthought on software development projects\, regardless of the paradig
 m being followed\, but it doesn't have to be this way. Traditional approac
 hes would have you add a lot of additional bureaucracy to your process and
  the agile extremists will tell you to write up some stories on index card
 s. Good luck with those strategies. Disciplined agile teams\, particularly
  those working at scale\, have discovered ways to address enterprise issue
 s such as security in effective manners which gets the job done without un
 necessary bureaucracy\, albeit with more sophisticated tools than a stack 
 of index cards. This presentation overviews the Agile Process Maturity Mod
 el (APMM)\, what it means to scale agile approaches to meet your real-worl
 d needs\, and strategies for addressing security concerns in a disciplined
  agile manner.\NScott W. Ambler is the Practice Leader for Agile Developme
 nt at IBM Corporation. He works in the IBM Methods group developing proces
 s materials and travels the world helping clients to understand and adopt 
 software processes that are right for them. A prolific author\, Scott has 
 received awards for several books\, including those focused on the Unified
  Process\, agile software development\, Unified Modeling Language\, and de
 velopment based on the CMM (Capability Maturity Model). A widely recognize
 d expert on Agile Process\, he is a regular speaker at international IT co
 nferences and a senior contributing editor for Dr. Dobb’s Journal. Scott
  also writes the Agile Software Development at Scale blog on IBM Developer
 Works.\N\NPrior to working for IBM\, Scott led the development of several 
 software processes\, including Agile Modeling (AM)\, Agile Data (AD)\, Ent
 erprise Unified Process (EUP)\, and Agile Unified Process (AUP). He holds 
 a BSC in computer science and a MS in information science from the Univers
 ity of Toronto. \N
SEQUENCE:1
PRIORITY:5
CLASS:
CREATED:20090413T133809Z
LAST-MODIFIED:20090413T133809Z
STATUS:CONFIRMED
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-OWNERAPPTID:-735365159
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20090413T121631Z
X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20090330T143451Z
END:VEVENT
END:VCALENDAR
___
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] Work in the Secure Development/Secure Code Review Area?

[McGovern, James F (HTSC, IT)]

The market for doing freelance writing has all but disappeared. You
could consider writing a book but you would probably earn more money
working at MacDonalds bagging fries than writing. In terms of
presentations, most conferences/events also do not pay. If you managed
to however put together training courses, there is some possibility.

Being involved in OWASP will help you network with others who actually
have money to spend on your services. Many OWASP meetings are held in
space of major corporations (e.g.
http://www.owasp.org/index.php/Hartford) 

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews
Sent: Thursday, June 18, 2009 6:04 PM
To: sc-l@securecoding.org
Subject: [SC-L] Work in the Secure Development/Secure Code Review Area?


What kinds of positions/work are available in this area now?  Could
someone make a living doing freelance research/articles/presentations in
this area?

I will be leaving my company at the end of August and I am actively
planning my future now.  If you have some good thoughts or ideas, please
let me know.  I have plenty of ideas, but I thought this list might have
some people who would know things I might not have thought about.

I plan on being more active in OWASP, but that won't pay anything, so I
need to find a way to make enough to support work like that.

I would also like to put anything I find into an article/paper/something
because I figure the "career question" is of interest to a lot of
people.  :)

-- 

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




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

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] Integrated Dynamic and Static Scanning

[McGovern, James F (HTSC, IT)]

Sometimes integration is a good and bad thing. I hope that my Ounce
enhancement request for integration with HP Quality Center and Archer
GRC doesn't get deprioritized over rebranding efforts.

Likewise, this also has the potential of causing many more IBM employees
than current to pay attention to the needs of secure code. 

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews
Sent: Tuesday, July 28, 2009 5:03 PM
To: sc-l@securecoding.org
Subject: [SC-L] Integrated Dynamic and Static Scanning


Partnering is not the same thing as having a single owner for both
tools.  I also believe WhiteHat is "hire them and they do it" model,
though they do put hardware in your enterprise.  IIRC, you could not do
all the work yourself if you had whatever components they provided.

I don't think AppScan and the Ounce programs will be integrated to this
extent soon, but it would be much easier, since they are both in  
the same company.That level of integration is highly unlikely  
without the "common owner" this deal provides.

The end result may or may not be better, especially if they take the IBM
trend of charging more rather that the simpler model Ounce was taking
recently.  (Though was that sustainable?)

I would be interested in hearing how the Fortify/WhiteHat integration
worked.

-- 

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


> Fortify (www.fortify.com) has Partnered with WhiteHat Security   
> (www.whitehatsec.com) too

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

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?

[McGovern, James F (HTSC, IT)]

Here is where my enterpriseyness will show. I believe the answer to the
question of where secure coding belongs in the curiculum is somewhat
flawed and requires addressing the curiculum holistically.
 
If you go to art school, you are required to study the works of the
masters. You don't attempt to paint a Picasso in the first semester, yet
us IT folks think it is OK to write code before studying the differences
between good code and bad code. If a student never learns good from bad
and over time develops bad habits, then teaching security at ANY stage
later in life is the wrong answer. We need to remix the way IT is taught
in Universities and revisit the fundamentals of how to approach IT as a
whole.
 
My second and conflicting opinion says that Universities shouldn't be
teaching secure code as they won't get it right. Students should
understand the business/economic impact that lack of secure coding
causes. If this is left strictly to Universities, it will most certainly
feel academic (in the bad sense). A person doesn't become a real IT
professional until they have a few years of real-world experience under
their belts and therefore maybe this is best left to their employers as
part of professional development and/or Master's programs that are
IT-focused but not about the traditional computer-science/software
engineering way of thinking...
 
http://twitter.com/mcgoverntheory

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?

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