security

ANTITAMPER PROBE ENABLEMENT LLD

Tamper resistance, sandboxing, remote scan policy, and security deep dives.

Anti-Tamper Probe Enablement LLD

1. Purpose

This LLD defines how anti-tamper probe execution is enabled, how runner enforcement is gated, and how diagnostics differ from enforcement.

2. Problem Statement

Users often confuse:

1. probe execution enablement
2. process-protection enforcement enablement
3. policy action after detection

This design separates these decisions clearly.

3. Inputs

3.1 Master Probe Gate

runtime setting

1. Value 1 means probes run.
2. Any other value means probes are skipped.

3.2 Process Protection Gate

runtime setting

1. Evaluated by runner process-protection path.
2. Default enabled when unset.
3. Disabled by: 0, false, off, no.

3.3 Policy Inputs

1. runtime setting
2. runtime setting
3. secure/compat/dev mode context

4. Decision Model

5. Caller Semantics

5.1 Runner

1. Uses focused 5-probe enforcement set.
2. Applies confidence threshold (>= 80).
3. Triggers policy action on threshold hit.

5.2 Builtins

1. Use broader probe sets for diagnostics.
2. Return probe signals to scripts/users.
3. Do not directly enforce runner blocking path.

6. Observability

Telemetry events:

1. anti_tamper_probe_invoked
2. anti_tamper_probe_error
3. process_protection_detected

7. Risks and Mitigations

Risk:

1. False negatives if probe gate is left disabled.

Mitigation:

1. Document production recommended env posture.
2. Add deployment checks for required security runtime settings.

Risk:

1. False positives when a single heuristic is noisy.

Mitigation:

1. Keep confidence thresholding and multi-probe context.
2. Review detail field before escalation.

8. Student Takeaway

There are three separate questions:

1. Did probes run?
2. Was enforcement enabled?
3. What did policy decide?

Keeping these separate prevents most operational confusion.