Fwd: RE: We have the enemy, and the enemy is... you

["Olef Anderson" <olef.anderson () gmail com>]

No intention to start any flame fest or upset anybody but here is my final
verdict regarding HIPS. just speaking my mind here, bear with me please.
Also i should mention, this verdict is all about HIPS for binary-only
OSes, basically win32 and not much more (solaris, hpux, aix ? boring
details if you ask me and no HIPS vendor really seems to care either)

Verdict:

Don't buy them! Don't spend the time and the energy to get them to work
for your enterprise. There are several reasons for me to say this but i
would
like to first start offering you the alternative.

Instead:

Pay attention to what MSFT is doing!

That meaning, go to fry's/circuit-city or whatever local store or call
DELL/HP/Blah (in case of bulk orders) and make sure they ship you, DEP
available machines. Make the sales guy type the following on a functional
unit;

wmic OS Get DataExecution_Available
it should return TRUE.

Create 2 gold builds, XPSP2 for desktops and 2003SP1 for servers.
Later if you have some more left in the budget, move on to
purchasing/installing "Windows Live OneCare" OR "Microsoft Client
Protection". If not, just install  "Windows Defender" and make sure to
have scheduled scripts to enforce your desktop to visit "Windows Live
Safety Center" on an interval. (don't know how to script that, hire an
intern during summer, help boosting the economy ;) )

Use various lockdown tools provided by MS to secure your gold builds and
just burn that image to harddisks. Especially one of the recent lockdown
toolkit for desktops was quite useful but can't recall what it was called
and a quick search didn't returned much. (public access XP lockdown
toolkit, anyone ?)

Make sure automatic updates are always on and in automatic mode. At this
point I can hear, many HIPS vendors saying "Oh, but you can't install
patches without testing them to see whether they break your in-house
applications". Stop with that please! so you are telling me that your 10
person team (an optimistic estimate) will do a better job in hooking
vulnerable functions on runtime in order to prevent exploitation and will
do a safer and better job than a MS hotfix (which is backed by probably
the world's biggest QA department) ? So you are telling me that you checked
your hooks against all locale's and all 3rd parties ? Lets not fool
ourselves, I would rather trust the Microsoft's QA department doing a
better job on making sure the patch will not break unintended
application. (some of you probably will come up with examples of MS
hotfixes breaking your applications but as a HIPS veteran, I can
come up with as much, if not more, on the HIPS side of the story)

I hope this non-formal thoughts will help some of you, responsible for
making such decisions, see the perspective of a security researcher whose
sole job is to break systems on a daily basis and who came to a point that
he
sees that MS is standing in a better position than the vendors claiming to
cover
its soft spots (yes! including you AV/spyware industry).

Ok, finally here are some reasons why i bother with championing MS over
HIPS in this lengthy email (for my standards at least);

-  As somebody making a living finding and writing exploits, I am having a
harder time exploiting a heap overflow against a service running on 2003 SP1

(not even having DEP in the mix) rather than lets say breaking any HIPS
you can throw at me.

-  HIPS breaking safeSEH! yeah, they insert their non-/GS compiled
dll into each process' address space thus effectively breaking what MS had
finally manage to fix, making vanilla stack overflows a possibility again.

-  HIPS turning off DEP per process so that they can generate events
for worms and exploitation attempts. ugh! :(

-  HIPS making exploitation easier and sometimes even much reliable
by not protecting their own metadata. rw- function pointers,
.data turn-me-off dwords/bools, just to name a few  ...

-  A much weaker code security assurance process than MS (has anybody
followed Mr. Wheeler's track record against AV recently ?), meaning
opening room for more vulnerabilities, in a product thats suppose to prevent
them.
Such a tragicomedy!

-  Personally being against in securing protocols and services by writing
filters on top. Filters, meaning more parsers, doesn't really help with
the problem, if not make it worst, hint my prior comment. In recent years,
after enough embarrassment, MS is doing a decent job securing its own
code base and protocols. And I would take that as an assurance rather than
some under-payed researcher/developer determining which functions to hook
and
what to check against (dear vendors, I know how it works out there, don't
bore me with
rhetoric ;) )

Regards,
Olef.