FYI this is part of a notice that went out to financial institutions

Complete Financial Institution Letter: 

Management is responsible for ensuring that commercial off-the-shelf
(COTS) software packages and vendor-supplied in-house computer system
solutions comply with all applicable laws and regulations.
The guidance contained in this financial institution letter will assist
management in developing an effective computer software evaluation
program to accomplish this objective. 

An effective computer software evaluation program will mitigate many of
the risks - including failure to be regulatory compliant - that are
associated with software products throughout their life cycle. 

Management should use due diligence in assessing the quality and
functionality of COTS software packages and vendor-supplied in-house
computer system solutions.

FDIC-Supervised Banks (Commercial and Savings) 

-----Original Message-----
On Behalf Of Greenarrow 1
Sent: Monday, November 29, 2004 6:08 PM
To: George Capehart
Subject: Re: [SC-L] How do we improve s/w developer awareness?

Words could not be spoken better.  This is my argument from the get go.
to, am tired of seeing everyone blame it on the Dev department when the
orders from above are I want this now and fast.  Maybe, we can focus and
convince upper level management that security is as important as the
money, bells, whistles.  But while I support Dev I still do not
how some companies development departments can include tight secured
in a short time frame and others seem to provide excuses or just do not

Customers are now looking at the security of programs.  Slowly,
are finally looking at security flaws mainly because of the media
that computer softwares are creating.  While it may only be top
in the software field customers are now questioning other programs they
which I support fully.  I can see this in the rise of subscribers to
Security Flaw Alerts which has risen over 71% within the last 3 months.

Just a word of warning as consumers become more aware of security in the
softwares they purchase companies that do not secure will start showing
downslide in purchases.  It is happening to one major company as we
each other on issues.


----- Original Message -----
From: "George Capehart" <[EMAIL PROTECTED]>
Sent: Sunday, November 28, 2004 5:18 PM
Subject: Re: [SC-L] How do we improve s/w developer awareness?

> On Thursday 11 November 2004 10:26, Kenneth R. van Wyk allegedly
> > Greetings,
> >
> > In my business travels, I spend quite a bit of time talking with
> > Software Developers as well as IT Security folks.  One significant
> > different that I've found is that the IT Security folks, by and
> > large, tend to pay a lot of attention to software vulnerability and
> > attack information while most of the Dev folks that I talk to are
> > blissfully unaware of the likes of Full-Disclosure, Bugtraq, PHRACK,
> > etc.  I haven't collected any real stats, but it seems to me to be
> > least a 90/10% and 10/90% difference.  (Yes, I know that this is a
> > gross generalization and there are no doubt significant exceptions,
> > but...)
> >
> > I believe that this presents a significant hurdle to getting Dev
> > folks to care about Software Security issues.  Books like Gary
> > McGraw's Exploiting Software do a great job at explaining how
> > software can be broken, which is a great first step, but it's only a
> > first step.
> Apologies for the two-week latency in this reply.  I don't have as
> time for the lists as I used to.
> I have read the rest of this thread, and I didn't see any comments
> address a dimension that is, for me, the most salient.  I feel like a
> broken record because this topic crops up on one security-related list
> or another at least once a quarter and I end up saying the same thing
> every time.  I'm going to say it again, though, because I really
> believe that it is important . . . Dev folks will care about security
> when their managers care about security.  If time-to-market and bells
> and whistles are more important to "management" than security is,
> that's where dev folks will spend their time.  It is their job to do
> what their managers tell them to do.  When "management" decides that
> is more important to deliver a product that is based on a robust
> security architecture and which is built and tested with security in
> mind, it will be.  Until then, it won't.  At one time or another in my
> career, I have held just about every position in the software
> development food chain.  I have had the president of the company tell
> me:  "I don't care what it takes, you /*will*/ have this project done
> and delivered in four months!"  Well, we delivered a
> less-than-half-assed piece of software, but you can be sure that it
> designed at the keyboard with absolutely *no* thought for security.
> That guy didn't know security from Adam's house cat and cared less.
> was not my job to deliver *secure* software.  It was my job to deliver
> /*what we'd promised the customer*/ in four months.  Security wasn't
> the spec, so security wasn't in the product.
> It is not fair to beat up on the developers . . . or even the project
> managers.  This is a governance/risk management problem.  This is a
> C-/board-level problem.  It's not going to be solved until the people
> giving the orders give orders to "do it right."  I know many
> and project managers who have a clue, but it doesn't matter if they
> not allowed to exercise it.
> My 0.02$CURRENCY.
> Cheers,
> George Capehart
> --
> George W. Capehart
> Key fingerprint:  3145 104D 9579 26DA DBC7  CDD0 9AE1 8C9C DD70 34EA
> "With sufficient thrust, pigs fly just fine."  -- RFC 1925

Reply via email to