FYI this is part of a notice that went out to financial institutions recently.
Complete Financial Institution Letter: http://www.fdic.gov/news/news/financial/2004/fil12104.html Highlights: 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. Distribution: FDIC-Supervised Banks (Commercial and Savings) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. I, 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 greed, money, bells, whistles. But while I support Dev I still do not understand how some companies development departments can include tight secured coding in a short time frame and others seem to provide excuses or just do not care. Customers are now looking at the security of programs. Slowly, consumers are finally looking at security flaws mainly because of the media coverage that computer softwares are creating. While it may only be top contenders in the software field customers are now questioning other programs they have which I support fully. I can see this in the rise of subscribers to certain 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 a downslide in purchases. It is happening to one major company as we email each other on issues. Regards, George Greenarrow1 InNetInvestigations-Forensics ----- Original Message ----- From: "George Capehart" <[EMAIL PROTECTED]> To: <[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 wrote: > > 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 at > > 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 much > time for the lists as I used to. > > I have read the rest of this thread, and I didn't see any comments that > 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 it > 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 was > designed at the keyboard with absolutely *no* thought for security. > That guy didn't know security from Adam's house cat and cared less. It > 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 in > 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 developers > and project managers who have a clue, but it doesn't matter if they are > 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