Ctrlk
HomepageSystem Status
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Gate 4: Data Protection

Data Protection — Protected Directories (Windows)

Audience: Windows administrators deploying a layered Keeper EPM anti-ransomware baseline.

For an overview of the layered anti-ransomware model and how this gate fits in, see Anti-Ransomware Policies.

This policy is the data protection gate in a layered Keeper EPM anti-ransomware deployment on Windows. Where the other three gates stop ransomware from executing, escalating, or destroying recovery options, this gate protects the data itself. File Access policy modifies the NTFS ACL on protected directories to deny READ, WRITE, and DELETE access unless the policy control (Approval, MFA, or Justification) is satisfied. The protection is enforced by the operating system itself — even a ransomware encryption process running under the user's full token cannot overwrite or delete files in a protected directory, because Windows refuses the I/O at the file system layer.

This is the last line of defense. If Gates 1, 2, and 3 have all failed and ransomware is actively encrypting, this gate is what preserves the data.

Step-by-Step: Create the Policy

1

Identify the Directories to Protect

Not every directory needs protection — broad protection creates friction without proportional benefit. Focus on directories whose loss would constitute a material incident:

  • Finance and accounting share roots (general ledger, AR/AP working files, payroll exports)

  • Source code repositories on developer endpoints (C:\repos, C:\src, C:\dev)

  • Executive shares and board materials

  • HR data (employee records, benefits, performance documentation)

  • Legal hold and litigation directories

  • Backup staging directories (before backups are written to off-host destinations)

  • Engineering documentation, IP, and design files

  • Customer data exports and CRM working files

Do not protect entire drives or user profile roots. Broad protection creates excessive approval traffic and trains users to click through without reading. Focused protection on the directories that actually matter creates a meaningful control with manageable operational overhead.

2

Create the Application Collection

Application Collections for File Access policies on directories use a different pattern from executable collections: each entry is a directory path rather than a filename. Path variables ({userprofile}, {public}, etc.) help where appropriate, but most data-protection use cases use literal paths.

  1. From the Keeper Admin Console, navigate to Endpoint Privilege Manager → Collections → Applications.

  2. Click New Collection.

  3. In the New Collection modal:

    • Type: Applications

    • Name: Protected Data Directories (Windows)

    • Click Next.

  4. In the Add Item to Collection modal, check Manually define resource.

  5. Add each protected directory as a custom resource. Example entries:

    • C:\Finance

    • C:\Legal\LitigationHold

    • C:\repos

    • C:\Executive

    • C:\HR\Records

    Adjust paths to match your environment. For network shares mapped to drive letters on user endpoints, use the mapped path the user sees (e.g., S:\Finance).

When you save the collection, note the collection's UID.

About the ACL behavior: File Access policy enforcement on non-executable paths uses the native NTFS ACL — Keeper adds an explicit DENY ACE for in-scope users on the protected path. When a user requests access and the policy control is satisfied, Keeper modifies the ACE to allow the user read/write for the duration of the grant. The protection is enforced by Windows itself, which is why it survives even when the ransomware process has the user's full token.

3

Create the Policy

  1. Navigate to Endpoint Privilege Manager → Policies and click Create Policy.

  2. Fill in the policy details:

    • Policy Name: Protect Sensitive Data Directories (Windows)

    • Policy Type: File Access

    • Status: Monitor for the initial pilot. Monitor mode logs which users would have been prompted without actually applying the ACL, giving you a preview of approval traffic before enforcement.

4

Add the Approval Control

  1. Click Add Control.

  2. Select Admin Approval.

Control choice: Approval is the default recommendation for data protection because it preserves legitimate access through an audited request workflow. Alternatives:

  • Require Justification for lower-friction directories where audit trail is sufficient and you don't need a human approver

  • Require MFA for directories where the user already has legitimate access but you want to add a credential-binding step

  • Deny for directories where no user should write under any circumstances (rare for data directories; more common for system locations)

5

Set Filters

  1. Accounts: Select All Accounts (wildcard). Specific exemptions (service accounts running legitimate backup software, for instance) should be handled by a separate higher-priority Allow policy.

  2. Machine Collections: Select your Windows endpoint collection. For directories that only exist on certain endpoints (e.g., C:\repos only on developer machines), scope this to a developer-specific machine collection.

  3. Applications: Select the Protected Data Directories (Windows) collection from Step 2.

  4. Leave Date & Time Window unset.

6

Set the Notification in Advanced Mode

  1. Notification Message: Keeper EPM protects this directory because it contains sensitive business data. Please submit your access request with a brief description of what you need to do. Your administrator will be notified to approve.

7

Save and Pilot

  1. Click Save. The policy is pushed to all in-scope endpoints within approximately 30 minutes.

  2. Run in Monitor mode for at least one week. Review the audit log to understand normal access patterns:

    • Which users routinely access each protected directory?

    • What is the approval traffic going to look like in enforcement mode?

    • Are there legitimate automated processes (backup agents, indexing services) that need to be exempted via a separate Allow policy?

  3. Build out exemption policies for legitimate automation. The most common case: enterprise backup software (Veeam, CommVault, Backup Exec) needs read access to the protected directories. Create an Allow policy scoped to the backup service account.

  4. When Monitor data is understood and exemptions are in place, edit the policy and change Status to Enforce. The NTFS ACL changes apply within approximately 30 minutes; users attempting access without an approved request will be denied at the OS layer.

Reference: Policy JSON

The following JSON is the exported form of the finished policy. The <generated-policy-uid> and <uid-of-Protected-Data-Directories-collection> placeholders are filled in by the Admin Console when the policy and collection are created.

Why This Gate Matters

The first three gates aim to stop ransomware before it does damage. This gate exists because no preventive control is perfect, and the consequence of failure is data loss. Even in the worst-case scenario where ransomware has evaded execution gating, has somehow obtained admin rights, and has successfully removed shadow copies and backups, the encryption process still has to write to the file system — and the operating system itself, configured by Keeper EPM's ACL modifications, refuses the write.

That is the value of defense in depth: each gate makes the attacker's job harder, and the last gate makes the attack's payload impotent even when every other defense has failed.

PreviousGate 3: Recovery-DestructionNextEnable and Start the Watchdog Service

Last updated