Re: The bugs stop here

From: Susan Bradley, CPA aka Ebitz SBS Rocks [MVP] (sbradcpa_at_pacbell.net)
Date: 05/24/03 

Date: Sat, 24 May 2003 00:09:22 -0700

rtf

"Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" wrote:

> The bugs stop here
> This past winter, a worm known as Slammer rattled
> the Internet violently enough to become what you
> might call a "CNN-level virus" -- that is, it
> burrowed its way into the national consciousness.
> Nearly everything about the SQL Slammer was old.
> It was an old hack that exploited a year-old
> vulnerability found in an old target, Microsoft
> Corp. software. There was a patch to block Slammer
> that was six months old, and that patch suffered
> from an old patch problem: It was so kludgy to
> install that the patch needed a patch. Above all,
> the reaction to Slammer -- the call to use the
> event to build security awareness -- was so old
> it called Bob Hope "kid." But this much was new:
> Everyone agreed that Slammer was your fault.
> http://computerworld.com/securitytopics/security/story/0,10801,81440,00.html
>
> The bugs stop here
> http://computerworld.com/securitytopics/security/story/0,10801,81440,00.html
>
> "Use freely available security standards
>
> Start with NSTISSP No. 11 (PDF format), the national security standard
> that mandates that any software used in a national security setting must
> pass certain government audits. Learn the criteria, and then demand that
> your developers and vendors meet them.
>
> The government has many other security standards. None is a defining
> standard but virtually every one of them contains something useful.
> Special Publication 800-27, a NIST document, for example, contains 33
> applicationsecurity principles. (One of them: Implement least-user
> privilege, which means start with all access turned off and
> turn it on only as needed, not vice versa.)
>
> It's important to note that most of the standards are foundational. That
> is, they're most useful for software at the design and requirements
> phase, and less useful for applications that have already been developed
> and deployed.
>
> Put security in writing
>
> Ferderer now requires that his vendors do application scanning on every
> software package Mutual deploys.
>
> "The trend to put security right in contracts has become quite
> successful," says OWASP's Curphey. "It's more common and more accepted
> than ever, in part because there are the tools which, to a degree, lend
> objectivity to the security of an application."
>
> A contract signed between General Electric and the software vendor
> General Magic last year excited security experts. Section 7.3 is called
> Code Integrity Warranty, and it holds the vendor financially accountable
> for bad software and requires the vendor to fix it.
>
> Tick off these to-dos too
>
> After buying the software, re-educating your developers, poring over
> standards and hanging out with contract attorneys, you can (if you have
> the energy):
>
> Check out OWASP. Weber at IndyMac Bank lifts heavily from the OWASP
> guidelines for secure Web application development.
>
> Read Winning with Software, by Watts Humphrey, and have the developers
> read Writing Secure Code, by Michael Howard and David LeBlanc. "

Relevant Pages