CYART // SCHEMA · DEFENSE-LAYERS7 NODES · 7 LINKSBLOCKED HERETELEMETRYALERTTHREAT · Attacker — phish, creds, exploitTHREAT01Attackerphish, creds, exploitEDGE · Edge — WAF, DDoS, TLSEDGE02EdgeWAF, DDoS, TLSSERVICE · Identity — SSO, MFA, deviceSERVICE03IdentitySSO, MFA, deviceSERVICE · Application — input validation, authzSERVICE04Applicationinput validation, authzDATA · Data — encryption, DLP, KMSDATA05Dataencryption, DLP, KMSSTREAM · Detection — logs, EDR, SIEMSTREAM06Detectionlogs, EDR, SIEMSTREAM · Response — runbooks, isolate, rotateSTREAM07Responserunbooks, isolate, rotate

Design a data loss prevention system

Design DLP for 50,000 employees: detectors from regex with checksums to exact data match and ML classifiers, inspection at the endpoint, email gateway, SaaS APIs and network proxy, a latency budget per channel, false positives people will tolerate, and a system that does not become the biggest store of sensitive data in the company.

● Hard🔒 PRODesign problem·18 min read·Advanced → Staff
DLPdata loss preventionexact data matchLuhn checkTLS inspectionDLP false positives

01Understand the problem

✓What you will learn
  • Build detectors from regex plus checksum (Luhn), exact data match and ML classifiers, and know what each is good for
  • Place inspection at the endpoint, email, SaaS API and network and choose inline or out-of-band per channel
  • Trade latency against coverage and engineer false positives down
  • Protect the privacy of inspected data so DLP is not itself the breach
◎Interview radar

What they probe: which detector catches which data, where you can block before loss and where you can only clean up, what an upload waits for, how you stop 'every order number is a card number', and who can read the evidence. Where candidates slip: regex only, one inspection point, blocking everything on day one, storing full matched content in incidents, forgetting that TLS and encrypted files hide content.

DLP watches data leaving where it should stay: an email with 5,000 card numbers to a personal address, a customer export uploaded to a personal cloud drive, source code pasted into a public chatbot. It has two halves: detection (is this content sensitive?) and enforcement at an inspection point (log, coach the user, block, quarantine, encrypt, revoke a share).

Functional requirements

  1. Detect card numbers (PANs), national IDs, credentials, customer records, source code and labelled documents in text and files (Office, PDF, archives, images through OCR).
  2. Inspect email, web uploads through a proxy, endpoint actions (USB, clipboard, print, browser upload) and sanctioned SaaS (file storage, chat).
  3. Actions per policy: log, coach with justification, block, quarantine, encrypt, revoke a share link.
  4. An incident workflow for analysts, with masked evidence and per-rule false positive metrics.

Non-functional requirements

  1. 50,000 users; about 2M emails and 10M web uploads per day.
  2. Added latency: email < 30 s, proxy upload p99 < 300 ms, endpoint clipboard and print < 50 ms.
  3. Each inline point has a defined behaviour when detection is down.
  4. Inspected content is never stored in full; evidence masked, access audited, EU staff data processed in the EU.
▭On the whiteboard · Scope3 points
01
FR
detectors | email, proxy, endpoint, SaaS | actions | incidents + metrics
02
NFR
50k users | per-channel latency | defined failure behaviour | private evidence
03
out
classification and labelling programme, insider-risk analytics, CASB discovery of shadow IT

This is an advanced module

Design problems: data security is part of the Pro pass. 4 more sections — the deep dives, the final design, follow-ups and the test — unlock with it.

Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.