RE: Learn from history?

["Alerta Redsegura" <alerta () redsegura com>]

> I work in SME environments. Those guys don't have the resource and money,
> nor the knowledge to begin to understand.
> It's also about practical stuff.

I work for SMEs too, and many of them understand the threats and are ready
to spend money (according to their possibilities) to minimize the threats.
Some of them of course don't have a clue and won't ever have a clue.


> > 1. Keep informed.
>
> Sure. I'll inform all my 300 customers MS release a bug today,
> and I'll drop by to all of them to patch tomorrow.

I must not go and install the patches myself. My customers must know how to
do it, otherwise, I have not done a good job as a consultant.  Reminding
them that there is a new patch however is a good idea: they generally keep
to busy with other matters to remember when it is patch-day.

What MS releases is patches or updates, not bugs. (right?  ;-) )
Patches can be buggy? Yes, of course. But the problem with patches, more
than "bugs" is dependencies with other components and 3rd party software. In
the specific case of MS patches, language locale sometimes creates issues as
well.

This is why some testing is necessary before applying patches, especially in
servers.



> > 2. Install patches as soon as possible
>
> That would involve runnning Windows Automated Update every night
> automagically...

Why in heavens check for Windows Updates every day, if MS is only issuing
patches *Once A Month*, between the 10 and 15?
And even if an "extraordinary" patch is issued or updated, the news is
immediately spread via security advisories and mailing lists?
Remember it was 17 days here between MS04-11 and Sasser.  Enough time to
test, apply the patch, or use workarounds.

Several updates a day is applicable to anti-virus software, and checking for
signature updates is done automatically these days.



> > 2. If a patch cannot be installed, find workarounds
>
> That does not work with the workarounds customer need to facilitate life
> (security <> easy of use, remember)

In the particular case of Sasser, workarounds indicated in KB 835732 and/or
making sure TCP 445 is closed to the outside world was enough and not
difficult to achieve.


> > 3. If it is a port-related threat, find out if such ports are
> > in use, and if
> > not, make sure they are closed. (Of course there would
>
> Once the virus is on the LAN it can do whatever it wants.

Precisely, *It Should Not Get To The LAN*.
Contact to the outside must be *only* through protected, controlled
channels. (Not only the Internet: CDs, floppies, USB memory devices, etc).
Preventing Dial-up issues, and other "leaks", is a matter of user education,
and having the technical means to enforce policies.
Expensive? Sometimes yes, but a good cost-benefit solution can be achieved
in most instances.



> > Will they learn from history? Only history will tell.
>
> I'm pretty sure they won't. Even most tech guys don't have a clue.

Those who do not learn will simply end up out of business.
It is a matter of evolution by means of natural selection.




Iñigo Koch
Red Segura

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html