Configuring Policies

Configuring Policies

Everything CloakDLP does is governed by policies, configured from the console's Policies page. A policy defines four things: what to look for, where to look for it, what to do when it's found, and, for blocking specifically, how sure it needs to be first.

What to look for

• Credit card (regex + Luhn checksum)
• SSN (regex)
• API key / token (regex)
• Private key (PEM regex)
• Exact Data Match: a dataset of your own values (customer IDs, account numbers, whatever), hashed locally with a salt so the reference data itself is never exposed
• Document fingerprint: a fuzzy hash (CTPH) of a reference document, catching near-duplicates and excerpts, not just byte-identical copies

CloakDLP ships with one auto-created policy, "Credit Card Entry," covering the credit card data type. Everything else is opt-in.

Where to look

A policy can apply to any combination of: file, clipboard, print, and network (which also covers the browser extension, since typed card entry reports over the same channel as network-proxy traffic).

What happens on a match

Three actions, in increasing severity:

• Log only: recorded in the Incidents feed, nothing else happens.

• Flag for review: same as log, shown with a "Flagged" badge so it stands out in the feed.

• Block: the match is actually stopped, not just recorded. What "stopped" means depends on the channel:

  Channel	What happens
  Clipboard	The clipboard is cleared
  Print	The print job is canceled
  Network (proxy)	The request is rejected with an HTTP 403, never forwarded
  Browser extension	The form submission is stopped before it goes out; a warning is shown, and if a re-check later says it's not actually blocked, the submission is automatically replayed

Blocking decisions are made by the console, on every single match, not cached or assumed by whatever reported it, so a policy change takes effect on the very next match after you save it.

Simulate mode

Every policy has a Simulate mode switch, on by default for new policies. While it's on, a Block action behaves exactly like Flag: recorded and visible, never actually enforced. This exists so you can turn a policy's action to Block, watch what it would have caught for a while, and only flip Simulate off once you trust it. If you set a policy to Block and nothing is actually stopping, check this switch first: it's the most common reason a "block" policy isn't blocking.

Risk-based blocking (network / browser extension only)

A Block policy can optionally require the destination domain's risk score to be at least Low, Medium, or High before it actually blocks: everything else about the match still gets flagged for review, just not stopped outright. This lets you block only the genuinely suspicious destinations (freshly-registered domains, known malware/phishing hosts) while typing a card into a well-established site you actually shop at just gets logged.

Risk scoring uses two free, no-API-key sources:

• The URLhaus malware/phishing hostname blocklist: an instant "High" if the domain is listed.
• A WHOIS domain-age lookup: newer domains score higher risk than long-established ones.

This only applies to matches with an actual domain attached (network-channel traffic and the browser extension); clipboard, print, and plain file matches have nothing to score, so a risk-threshold condition on those channels is a no-op and just falls back to flagging.

Worth knowing before turning this on aggressively: domain age is a coarse signal. A legitimate brand-new business reads identically to a freshly-registered scam domain under this heuristic. It's a real, useful input, not a guarantee.

Why a "Flagged" incident sometimes doesn't match what you configured

Two things worth checking if a policy isn't behaving the way you expect:

1. Simulate mode (above): the single most common cause.
2. Which policy actually governed the incident. Click into the incident and check its policy. If you have more than one policy for the same data type and disabled or replaced one after the desktop agent or browser extension had already paired, it can take a few minutes (up to one heartbeat cycle) for the client to notice the change and start using the new one. See Troubleshooting if it seems stuck longer than that.