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

2009-08-27 Thread 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?

2009-08-27 Thread 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] Where Does Secure Coding Belong In the Curriculum?

2009-08-22 Thread 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.
___


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

2009-08-20 Thread 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] Work in the Secure Development/Secure Code Review Area?

2009-06-19 Thread 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.
___


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

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

2009-01-26 Thread 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 hosted and 

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

2008-12-01 Thread 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?

2008-12-01 Thread 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 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

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

2008-12-01 Thread 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] Language agnostic secure coding guidelines/standards?

2008-11-13 Thread 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] (fwd) informIT: A Software Security Framework

2008-10-15 Thread 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.
___


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

2008-06-16 Thread 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] Secure Coding in the Hartford CT Area

2007-12-19 Thread 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.
___


Re: [SC-L] Code Coverage and Code Quality tools

2007-12-15 Thread 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.
___


Re: [SC-L] OWASP Publicity

2007-11-19 Thread 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.
___


[SC-L] OWASP Publicity

2007-11-15 Thread 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] IT industry creates secure coding advocacy group

2007-11-01 Thread 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 community.
___


[SC-L] Mainframe Security

2007-11-01 Thread 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.
___


Re: [SC-L] Software process improvement produces secure software?

2007-08-29 Thread 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/

Re: [SC-L] Security Testing track: Software Testing Conference:Washington DC

2007-08-28 Thread 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

2007-08-28 Thread 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] mailto:[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] how far we still need to go

2007-08-28 Thread 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.
___


Re: [SC-L] Resources to fix vulns

2007-07-19 Thread 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] mailto:[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

2007-07-19 Thread 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] Instead of the next frontier, how about another frontier

2007-06-28 Thread 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

2007-06-28 Thread 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:

?xml version=1.0 encoding=UTF-8?
FVDL xmlns=xmlns://www.fortifysoftware.com/schema/fvdl
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.5
xsi:type=FVDL CreatedTS
xmlns=xmlns://www.fortifysoftware.com/schema/fvdl date=2007-06-27
time=16:27:37/ Build
xmlns=xmlns://www.fortifysoftware.com/schema/fvdl
BuildIDcurl-7.11.1/BuildID
NumberFiles42/NumberFiles
LOC23572/LOC
 
SourceBasePath/Users/paco/Documents/Fortify/curl-7.11.1/lib/SourceBas
ePath
SourceFiles
File size=20098 timestamp=1079527605000connect.c/File
File size=11584 timestamp=1077710136000krb4.c/File
[..snip..]
Vulnerability xmlns=xmlns://www.fortifysoftware.com/schema/fvdl
ClassInfo
ClassID28424EC3-FFAC-40C0-94D9-3D8283B2F57C/ClassID
KingdomInput Validation and Representation/Kingdom
TypeBuffer Overflow/Type
AnalyzerNamedataflow/AnalyzerName
DefaultSeverity4.0/DefaultSeverity
/ClassInfo
InstanceInfo
InstanceID005542ED81D54F3C72BF3669EA8D130A/InstanceID
InstanceSeverity4.0/InstanceSeverity
Confidence3.4/Confidence
/InstanceInfo
[..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

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

2007-06-11 Thread 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.
___


[SC-L] Perspectives on Code Scanning

2007-06-06 Thread 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] Tools: Evaluation Criteria

2007-05-23 Thread 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.
___


[SC-L] Tools: Evaluation Criteria

2007-05-22 Thread 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] Darkreading: Secure Coding Certification

2007-05-21 Thread 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.
___


Re: [SC-L] Darkreading: Secure Coding Certification

2007-05-16 Thread 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] How big is the market?

2007-04-24 Thread 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=122253WT.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

2007-04-24 Thread 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.
___


Re: [SC-L] Silver Bullet: Ross Anderson

2007-04-23 Thread 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.  SP 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?

2007-04-23 Thread 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=122253WT.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.
___


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

2007-04-04 Thread 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

2007-04-04 Thread 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

2007-04-04 Thread 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.
___


[SC-L] Darkreading: compliance

2007-04-02 Thread 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

2007-04-02 Thread 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] Economics of Software Vulnerabilities

2007-03-27 Thread 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.
___


Re: [SC-L] Economics of Software Vulnerabilities

2007-03-21 Thread 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.
___


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

2007-03-20 Thread 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 improvements in those 
areas. 

The  FUD model (used by many vendors - do this or the SOX

[SC-L] Question on User Groups

2007-03-20 Thread 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.
___


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

2007-03-19 Thread 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] Information Protection Policies

2007-03-09 Thread 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] Information Protection Policies

2007-03-08 Thread 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?

2007-03-08 Thread 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?

2007-03-08 Thread 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.
___


[SC-L] Magazines

2007-01-08 Thread 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.
___


Re: [SC-L] Building Security In vs Auditing

2007-01-03 Thread 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] Compilers

2007-01-02 Thread 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

2007-01-02 Thread 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.
___


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

2006-06-09 Thread 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 customers 
  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. Ill give you pointers to two. Theyre 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


RE: [SC-L] Comparing Scanning Tools

2006-06-08 Thread 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] Comparing Scanning Tools

2006-06-07 Thread 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


[SC-L] Comparing Scanning Tools

2006-06-06 Thread 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

2006-06-06 Thread 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