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/