IP: Re: "The Great Hack Attack"

[David Farber <dave () farber net>]

> Date: Sat, 10 Mar 2001 10:17:06 -0800
> From: Mark Seiden <mis () seiden com>
> To: dave () farber net
> Subject: Re: [dave () farber net: IP: "The Great Hack Attack"]
> User-Agent: Mutt/1.2.5i
>
> well, i read the entire article, and i'm not sure he really gets it.
> (this has been my area of work for > the last 5 years.)
>
> yes, the current state of things seems miserable, and education about
> applying patches would mitigate some of the problems, but that's
> trying to win in an ultimately losing endgame.
>
> writing tools to look for specific vulnerabilities is useful, but
> how does that solve the bigger problems?
>
> this particular problem is a bit deeper than unapplied patches: those
> ecommerce sites apparently all run microsoft software on machines
> exposed to the internet.
>
> monocultures are not that good at surviving in the long term, compared
> with biologically diverse systems.
>
> large programs full of features have always been full of bugs, and
> suitably motivated bad guys will find the bugs before they are fixed,
> and exploit them.  (it isn't just microsoft IIS -- look at the history
> of sendmail or bind.  but at least you can *find* the bugs in open source
> software, if you take the time to look, or pay someone to do so.)
>
> neither software developers (working for vendors) nor merchants
> understand the principles of good software design (for security, for
> usability, for reliability).  (in their defense, "software design" is
> taught neither in design schools, nor in computer science departments.
> those interested in this subject might visit the association for software
> design, http://hci.stanford.edu/asd/)
>
> these e-businesses are in too much of a hurry to use good security
> design practices, e.g. defense in depth, multi-tier design,
> protocol-aware firewalls, database design that treats readers and
> writers differently and limits database operations to specific stored
> procedures, and using crypto correctly to protect sensitive or
> private information.
>
> i'll bet most of them don't have a security policy or any mechanisms
> for enforcing one.
>
> i'll bet many of them outsource their network, their hosts, or
> operations to third party companies, which makes they think security
> is "not their problem".  (this makes their insider problem much
> bigger, since now it emcompasses not only their employee, but their
> vendor's employees, and all the visitors to their colocation
> facility!)
>
> i'll bet few of them ever had a third party expert review of their
> architectures and implementations, even a one-day checkup, or if
> they did it was a one-time event.
>
>         (in the last several years, several companies have approached us
>         (www.securify.com) to do such reviews only because they were
>         about to go IPO, and were worried that they'd be hit by a denial
>         of service attack on their first day out!)
>
> it's clueless tastelessness that's causing them to be exposed in the first
> place.
>
> bruce schneier's recent book, "secrets and lies" goes into some of these
> areas at much greater depth.
>
> the other big problem: the credit card as a basic concept.  i won't
> get started here, but i believe the card associations are
> fundamentally at fault for not going faster and doing better at this.
>
> the card associations fine merchants for excessive chargebacks due
> to fraud.  they should also fine merchants for losing databases
> of credit card numbers due to negligence, since there are real costs
> to both the card issuers and the cardholders every time this happens.
>
> here's another upcoming BIG problem:
>
> credit cards all have a second factor authenticator, variously named
> the cvc2 (or cid or cvv2) (it's the 4 digit number which is only
> printed on the signature panel, and not embossed on the card or on the
> magstripe) and many merchants are insiting on the numbers when doing
> charges.  (possession of the number proves presence of the physical
> card, at one time, anyway...)
>
> i hope they're not storing those numbers in their insecure databases,
> since when their databases are stolen (by insiders or outsiders)
> they're completely devaluing them for the rest of the world.  (to them
> it's just another number, and the computing imperative seems to still
> be "if you've got it, store it or log it".)
>
> > ----- Forwarded message from David Farber <dave () farber net> -----
> >
> > Subject: IP: "The Great Hack Attack"
> ...
> > > http://www.arstechnica.com/wankerdesk/01q1/greathack-1.html
> > >
> > > The Great Hack Attack
> > > Or why the weakest link in security is always human neglect
> > >    by Arian Evans
> > >
> > >  (Or, why Ars thinks you should be distressed about the state of 
> security in
> > > e-commerce right now)
> > >
> > > Well it finally happened. The Big One. A coordinated hacking attempted on
> > > over 40 companies in the United States, and an unknown total world-wide.
> > > Industry doomsayers have been predicting this for years. Security 
> consulting
> > > firms have been holding this over our head for years. Security product 
> firms
> > > have been spending more time slinging dirt at each other, and patting
> > > themselves on the back, than dealing with the potential for a coordinated
> > > attack of this caliber. (Secret Clue: these attacks aren't about lack of
> > > *super-high-tech* security products. It's about education; something the
> > > majority of security product vendors give lip service too, while 
> focusing on
> > > hype.)
>
> --
> mark seiden, cissp mis () seiden com, 1-(650) 592 8559 (voice) Pacific Time Zone
> see www.securify.com for more details.



For archives see: http://www.interesting-people.org/