Dealing with False Positives in general

Hello SMI, sorry about the trouble you have had and I am glad that you have resolved your current issues. I will pass that on to our product managers, if you could pass that back to your sales rep as well then it will at least get tracked to a specific customer. 

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

Hi Christian,

thanks for your reply. Concerning:

1. disable entire Sophos on the endpoints

This should not be a real problem. I am shure Sophos could use the same mechanism as Windows would use for disabling/stopping services from remote. Regarding the credentials, we have a setup with sync'd AD groups and automatic deployment of Sophos, so we have to supply an AD account with local admin rights anyway. Problem solved so far.

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

3. improving the deploy-/redeploy process

Basically I don't want to hijack anything and I don't want to touch an endpoint locally. You are right with  the Fixit Tool/Msicuu2.exe. They don't remove the services. This should not be a problem. Just call or builtin the functionality of the sc command. So one may be able to delete services. After calling the fixit or msicuu2.exe or what else.

4. Maybe a check if the necessary services are running, if not try to start them
At least the service check and starting if one is not running would be a benefit.

I suggested all of the above in concern of the false positive event that happened. We have a installation of around 6000 client computers. So touching a client locally without using the SEC must be an exception for us.

Regards,

Marcus Deubel

Hello Marcus,

1. disable entire Sophos on the endpoints

the devil's in the details - you are correct about the saved credentials in conjunction with AD sync. Recently there have been inquiries about an audit trail in connection with policy changes and I think that the same concerns would apply here - you'd probably want to know who has stopped the services and for what reason. If just a restart would be implemented the it'd be perhaps less of a problem. Then consider that SEC should as far as possible correctly display the status of the client - so it'd have to keep track of the commands issued and their outcome. As more than one administrator might use the console at the same time the display would have to be consistent to avoid confusion - if you stop, say, the Anti-Virus service then the client is not only non-compliant with respect to the AV policy but also the update status changes to unknown. Admittedly this is the same whether you do it from inside SEC or by an external command, but it's good practice to indicate that it has been done by SEC. 

Controlling the Sophos services from SEC might be handy if e.g. you want to restart the Agent. If the Installer encounters a problem which you want to resolve this way you'd probably need to do more than just stop a service though. In addition SEC would ideally have to be aware of the services and their semantics (and thus to have a way to "understand" uplevel SAV versions - something which is not implemented at the moment)

2./3. install(er) issues

If my observations are correct the install sequence has lately been revised to better handle existing installations. Previously Protect Computers (i.e. the sequence run by setup.exe) was rather reckless and while - if employed correctly - it could overcome issues like the ones of late it had also the potential of messing things up. Can't say what exactly spurred this revision but I assume it hasn't been done just for the fun of it.

I'm sure Sophos is looking into addressing the issues encountered - and of course I'd welcome any changes which make central management easier. I'm just trying to illustrate that it might not be as simple as it looks on the surface. If it were that simple (and innocuous) then the MS Installer would have an option ignore all product's data and perform an unconditional initial install, wouldn't it?

Christian