good distinction
it's not true that it can never work.
the security mechanism(detection or blocking), with a core conceptual weakness, can work, so long as that weakness hasn't been exploited. I have caught malware by running netstat -an, on a compromised host, so to say it never works is false.
A (uncompromised!) network firewall, logging, would be a better way but that requires another machine, set up for that. And, logging by process name, cannot AFAIK be done by a network firewall.
that'd be better, but it'd require a) a second host b)set up for that.
regarding b what are the options?
*nix network firewall, windows network firewall(MS ISA? - the proxy firewall), ..... ?
Well, it's easy to include your LAN's subnet(s) in the whitelist. That's the first and almost the only thing in the whitelist. That and perhaps some computers on microsoft's domain.
I'm not sure what you mean by "only for microsoft's network", I think this needn't be done on a 'network level', but on the windows host itself. Infact, I think it'd have to be for it to restrict by process svchost.exe. That, + monitoring outgoing traffic (by process), on the compromised host .
I do see that there is a conceptual problem in detecting on a compromised host . Though I think there is still some defence for it, which i've written here. Also, what I suggest here, detection looking at process names, can't be done from a network fw.