Force client to see new Tamper Protection configuration?

Hello Steve Custer,

you did
3. Disable Tamper Protection
from Central Admin, and just for this device or globally?

What does Central Admin show for TP in the device's details page and does it alert on policy non-compliance?
I'm not a Central user so I can't test it and don't know how it behaves. Generally I don't think that endpoint management considers a "warp-back in time". check in and see suggests that you disabled TP from Central Admin. I conjecture what happens in this case is the following:

• after installation the device is compliant, TP is on, the snapshot is taken
• you set TP to disabled, Central notes it has a pending policy change for this device
• the device checks for changed policies and commands, Central sends the TP setting
• the device applies this setting and reports compliance to Central, Central "ticks off" the pending change
• you revert the VM, it sends its status including that it is compliant from its POV
• Central has no pending change for this device so it doesn't send the TP setting

Under normal operation there are three scenarios w.r.t. policies:

1. a change is made in Central Admin - Central waits for the device to fetch and apply the policy and report compliance
2. a change is made locally on the device that subsequently reports non-compliance (differs) - Central waits for some time (can't say whether two hours or four hours) until it raises an alert and sends the Central policy to the endpoint
3. the local agent detects (either while trying to apply a changed policy or when performing the periodic checks) that the actual settings differ from the policy (possibly because of an error)

Neither is the case here. In the on-premise product it was always the endpoint (device) that computed compliance, dunno if this has changed and Central compares the status received from the device with the desired settings.
The on-premise SEC has a Comply with ... command but anyway it's not automatic.

Christian

You are correct, I disabled TP from the console.  The machine shows green and in compliance all the way through.

I attempted to change its group without effect.  After looking around for a way to run the "Comply With" thing you were talking about I stumbled on an old thread about deleting \ProgramData\Sophos\Remote Management System\3\Agent\AdapterStorage, but apparently the TP or something else is preventing me from taking ownership or deleting that even as SYSTEM.

I'm not tracking with why the client hasn't noticed that its policy doesn't match.  Is it the *server* saying, "nope, I already updated you the other day, I'm not giving you another one?"  That seems backwards compared to how GPO does it where the client compares its version of the GPO to what's in AD and pulls it down if it's older.

I'm also a little frustrated that there doesn't seem to be a way to clobber the old policies and reapply whatever is current even if it doesn't think there's a change.

Hello Steve Custer,

why the client hasn't noticed that its policy doesn't match
because this is not how it's designed. It's "going forward" and driven by changes - either on Central or the client. AFAIK "arbitrary" snapshotting is not supported.
Can't say why it has been implemented in this way. I assume the Central backend is different from the on-premise SEC insofar as SEC immediately enqueues changes and commands when they are requested with a TTL. The messages are purged when they expire and therefore a Comply with ... is available - but it can only be issued manually.

Christian

because this is not how it's designed. It's "going forward" and driven by changes - either on Central or the client. AFAIK "arbitrary" snapshotting is not supported.

Well I'm not sure how that makes sense; sure, on the workstation it's a *little* unusual, but on the infrastructure side we snap servers all the time: Before upgrades, for testing, before configuration changes, and so on.  Is it Sophos' official position that we can't snapshot a server and revert to a previous snap?

Hello Steve Custer.

I'm not Sophos (nor do I have an official statement here)
the problem only arises when you change a policy/setting while the device is still active after taking the snapshot.
It's debatable whether you should be able to "replay" the changes like in the case of software updates. Don't forget that the device is not solely a consumer. Assuming some threat has been detected on this device after the snapshot. Do you expect the corresponding alert to disappear when the device is reverted? Note that this could have affected other devices. Admittedly the TP policy is a very simple case but OTOH it's just part of a general framework and thus I wouldn't expect some exceptional behaviour.
Normally a policy change after the device has gone offline is processed as expected (i.e. sent to the device when it comes online again, whether in the last state or from a snapshot). All in all I don't see a real defect in the design.

Christian

You don't think it's a defect to fail to enforce a policy because you think you did it already?  That's not how I would expect it; I expect policies to be enforced.  If a machine deviates from policy, it should be reapplied.  Cisco AMP, IIRC, was really good about that.

What if an attacker managed to somehow manually edit the policy locally on a machine?  Wouldn't it be better to have that policy updated when the client realizes it's inconsistent with the server's version?

Hello Steve Custer,

an attacker
How should the local agent or the backend be able to discern an attacker and a legitimate change by an admin? And I don't think this applies here.

There's no perfect solution - if you make local changes you don't want the policy to be enforced immediately (or at an inappropriate moment). But then you'd want the policy to be enforced in case of someone forgetting to set it back. What's the "correct" interval - one hour, two ...? Assuming the agent permits non-compliance for two hours. You make a local change in order to perform some task, you make the first steps then take a snapshot, do more work, decide to revert. Now you are back in the middle of your task but suddenly the changes are reset as two hours have passed and you run into an error.

Christian