Dealing with False Positives in general

Hello Marcus,

thanks for your thoughts. Personally I prefer to see more suggestions and discussions on the forum.

Recently Patch Assessment has been added and hearsay has it that it might be expanded to Patch Management. Not surprisingly - and likely in response to customers' wishes - more (security and compliance related) features are considered. Contemplating the existing functions I can imagine that adding a feature like Software Inventory/Control is feasible. 

Vendors in other sectors also extend their suites and functions already overlap. Take Protect Computers in SEC - it is one way to get Sophos on the endpoints, and not a few use other methods. Naturally a vendor doesn't want to be the odd one out - so its software should be installable by common methods. OTOH customers shouldn't be required to buy an additional product or develop their own tools, so some deployment method has to be built in. Perhaps some way to pre-configure the target machines would be handy. And suddenly you find yourself competing with vendors from other sectors.

There are other areas Sophos has to address - especially the integration of the various product lines. SafeGuard Configuration Protection is "ahead" of Endpoint in many aspects. Basic Encryption has crept in but all other SafeGuard components require their own management. NAC has done so years ago but has never been integrated (and I wonder about the future of NAC Advanced). Just to name a few.

But I digress - on to your suggestions (oh, and I'm not Sophos so this is my personal view only):

1. disable entire Sophos on the endpoints

This is likely not that simple. Keep in mind that SEC requires you to put in credentials when you want administrative access to a client (Protect Computers). To have transparent administrative access through SEC would be a major change in the architecture (and the security implications are another matter). Obviously you can't use RMS to trigger the desired actions on the client. How it could be implemented aside - I can see that it would be handy in certain exceptional situations, could you give a real life example where you'd need it?

2. just copy the necessary program files like the vbs script

3. improving the deploy-/redeploy process

Basically you can do it now (if I understood Jak's post correctly) by hijacking the Protect Computers started task. It wouldn't have been necessary at all - the missing files were only a problem due to the Installer configuration. Guess there will be some research on what can be done here and how the Installer's features can be leveraged. I don't think that dispensing with the more or less proprietary approach was a bad idea - so don't expect that it will revert to "old ways".

the fixit tool (or its predecessor msicuu2.exe) basically removes the product-related Installer information so that another install attempt takes the this is the first install path. The product itself is not affected (e.g. installed services keep running), nothing is removed. Thus the fixit has to be followed by an install with an appropriate (usually the same) product version (and

if applicable all applied upgrades) - otherwise you won't get a clean state. There is quite some room for actually make problems worse than solving them, in fact you can even both a perfectly running system this way. Thus you'd first have to (or rather SEC has to) assure that the client is broken. Just presenting Do you really want to ... is IMO calling for troubles.  

4. Maybe a check if the necessary services are running, if not try to start them

In principle this should be doable - the question is to what extent. Keep in mind that settings might be centrally set or deployed by some means. It might also not quite fit the current concept of no more than necessary interference. An then it might be required to revert the machines to their previous state - not easily done though. Protect Computers might fail at various stages, "walking the path" before actual deployment might not be very efficient.

Just my thoughts

Christian

Hello Marcus,

thanks for your thoughts. Personally I prefer to see more suggestions and discussions on the forum.

Recently Patch Assessment has been added and hearsay has it that it might be expanded to Patch Management. Not surprisingly - and likely in response to customers' wishes - more (security and compliance related) features are considered. Contemplating the existing functions I can imagine that adding a feature like Software Inventory/Control is feasible. 

Vendors in other sectors also extend their suites and functions already overlap. Take Protect Computers in SEC - it is one way to get Sophos on the endpoints, and not a few use other methods. Naturally a vendor doesn't want to be the odd one out - so its software should be installable by common methods. OTOH customers shouldn't be required to buy an additional product or develop their own tools, so some deployment method has to be built in. Perhaps some way to pre-configure the target machines would be handy. And suddenly you find yourself competing with vendors from other sectors.

There are other areas Sophos has to address - especially the integration of the various product lines. SafeGuard Configuration Protection is "ahead" of Endpoint in many aspects. Basic Encryption has crept in but all other SafeGuard components require their own management. NAC has done so years ago but has never been integrated (and I wonder about the future of NAC Advanced). Just to name a few.

But I digress - on to your suggestions (oh, and I'm not Sophos so this is my personal view only):

1. disable entire Sophos on the endpoints

This is likely not that simple. Keep in mind that SEC requires you to put in credentials when you want administrative access to a client (Protect Computers). To have transparent administrative access through SEC would be a major change in the architecture (and the security implications are another matter). Obviously you can't use RMS to trigger the desired actions on the client. How it could be implemented aside - I can see that it would be handy in certain exceptional situations, could you give a real life example where you'd need it?

2. just copy the necessary program files like the vbs script

3. improving the deploy-/redeploy process

Basically you can do it now (if I understood Jak's post correctly) by hijacking the Protect Computers started task. It wouldn't have been necessary at all - the missing files were only a problem due to the Installer configuration. Guess there will be some research on what can be done here and how the Installer's features can be leveraged. I don't think that dispensing with the more or less proprietary approach was a bad idea - so don't expect that it will revert to "old ways".

the fixit tool (or its predecessor msicuu2.exe) basically removes the product-related Installer information so that another install attempt takes the this is the first install path. The product itself is not affected (e.g. installed services keep running), nothing is removed. Thus the fixit has to be followed by an install with an appropriate (usually the same) product version (and

if applicable all applied upgrades) - otherwise you won't get a clean state. There is quite some room for actually make problems worse than solving them, in fact you can even both a perfectly running system this way. Thus you'd first have to (or rather SEC has to) assure that the client is broken. Just presenting Do you really want to ... is IMO calling for troubles.  

4. Maybe a check if the necessary services are running, if not try to start them

In principle this should be doable - the question is to what extent. Keep in mind that settings might be centrally set or deployed by some means. It might also not quite fit the current concept of no more than necessary interference. An then it might be required to revert the machines to their previous state - not easily done though. Protect Computers might fail at various stages, "walking the path" before actual deployment might not be very efficient.

Just my thoughts

Christian