IP: Re: "The Great Hack Attack"

[David Farber <dave@farber.net>]

>From: ARIAN EVANS <AEVANS@uscentral.org>
>To: "'farber@cis.upenn.edu'" <farber@cis.upenn.edu>
>Subject: RE: Re: "The Great Hack Attack"
>
>Dave, thanks for the commentary.  Your points
>are valid and true, for the most part.  Where
>I disagree is mainly matter of opinion.
>
>I'll throw a few things out, because I'm
>curious what your specific thoughts are.  This
>will probably be longer than prudent, but if
>you have time to peruse it, I'd like your
>feedback. First I'll clarify a few things:
>
>I do have to apologize for the quality of
>the article posted.  I made the decision it
>was more important to post /something/ than
>to wait until the weekend when I could post
>something /well-written/.  That was my choice,
>and I should certainly be held accountable.
>
>That said, we agree on a number of points that
>apparently I either:
>1.  Failed to qualify clearly, or state coherently
>2.  Felt were outside the scope of discussion,
>which I wanted to hold to the specific situation
>at hand.  In a nutshell:
>Why it happened, and who should be directly accountable.
>
>Here's the first thing I'll tackle:
>">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."
>
>1.  No, unfortunately, virtually all the e-businesses I've
>consulted with DON'T do the above (appropriately).  They talk
>about it; they even have documents discussing how they've accounted
>for it.  In many cases, they've purchased and deployed technology to
>help facilitate the above.
>
>In those cases they actually have the right technology, it's
>very frequently *not* deployed and/or utilized appropriately.
>
>This again, is based upon my subjective experience.  It is
>quite feasible that I have seen a skewed sampling of companies,
>due to the nature of the work they'd call me in for.
>
>2.  Your point on monocultures is taken, but not well made (IMO).
>
>There is a large degree of 'biological diversity', IMO, in
>companies who take MS's base platform, and deploy their own
>custom environments on top of it.  My current endeavor is
>one encompassing a large, heterogeneous environment, with
>applications designed with a variety of 3rd party tools. MS's
>products are just one element among an array of products utilized.
>
>That's a bit different than a shrink-wrapped operating
>system and mail server combo, prepackaged from the vendor
>(which is where I believe your argument applies).
>
>The issues with the compromises covered in my article are
>not directly related to shrink-wrap, OOB product experiences.
>They are a /direct/ result of neglect and incompetence.
>Indirectly, yes, MS's software design paradigm puts them
>in a position where, by mathematical default, they are going
>to have a large number of vulnerabilities, patches, etc.
>
>However much MS is to blame for the underlying issue and
>their perpetuation of it, the fact remains that all the
>risks and variables in the current compromise scenarios
>/were accounted for by Microsoft/.
>
>Failure to apply recommended patches, and follow recommended
>design documents, is the fault of the consumer.
>
>
>">i'll bet most of them don't have a security policy or any mechanisms
> >for enforcing one."
>
>That's part of the above issue.  Security policy and
>internal mechanisms for enforcing one, are not highly
>important, but not paramount to security in the Enterprise.
>Good security practices should account for, and include,
>design, technology, practices and policy, etc.
>
>However, it is possible to have policy and internal
>procedure (driven by audit, risk-management, etc.) that
>is very thorough, very specific, and doesn't account for
>the appropriate things.
>
>I couldn't agree more with you that most developers and
>software vendors are failing to cover the major points
>of good software design.  The exact same argument can
>be made of security *professionals*, and organizations
>like the ISSA (I think ISSA has good motivations and
>intent.  However, it's staffed, run, and attracts a large
>number of people who like to talk and, to use your phrase,
>'don't get it'.  This observation is based strictly upon
>the chapters and members I've had the opportunity to work
>with.  I'd also welcome any positive input on ISSA, if
>you are a member.)
>
>I was just involved with a Director of Information Security
>being removed from a company, after a fairly long series of
>conflicts.  Thanks to the ISSA, he managed to maintain
>a pretty tight strangle-hold on his position within
>the organization (Internal Audit personnel, and several other
>influential members of the organization are ISSA chapter
>sponsors/members.  Most of them, including this director,
>are CISSP's).  He took his magic show on the road, and is
>now Director of Information Security for one of the larger
>e-commerce companies on the web.
>
>Now, I happen to like the guy, he means well, and can
>speak very articulately about security.  However, he
>doesn't understand technology at all, can't prioritize
>risk (essential!), and lacks the ability to balance
>business-driven requirements with pure technology concerns
>(which most pure *technologists* do).
>
>People like this are driving the security industry, and
>IMO that's a much bigger concern than technology.
>
>Most of the rest of what you state I implicitly agree
>with, and again, am clearly at fault that I didn't
>communicate that appropriately in my article.
>
>Hopefully I didn't intrude by sending you an email of
>this length, and there are elements contained in dialogue
>towards the latter part of the email I'd prefer remained
>'internal dialogue', as hopefully you'd understand.
>
>Thanks for your time,
>
>Arian



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