Forcepoint DLP Admin cheat sheet

Policy model is three-tiered: policy → rule → action. A policy groups rules; each rule holds conditions (content classifiers, severity, destination, user/group) and an action (permit, block, encrypt, quarantine, notify, user-justification prompt).

Content classifiers come in three families: predefined (PII, PCI, HIPAA patterns), pattern/custom (regex, keyword lists, dictionaries, file fingerprints), and document properties (file type, size, metadata). Classifier match returns a severity level (Low/Medium/High) that rules can threshold on.

Predefined classifiers use validation logic (e.g., Luhn check for card numbers, checksum for national IDs), so raw pattern hits without validation do not raise severity - tune by testing with the built-in classifier test utility rather than assuming a regex match equals a violation.

Incident workflow: an action produces an incident with severity, status (New/In Progress/Closed), and evidence (matched text snippet, file, destination). Remediation actions available to the admin include release, delete, encrypt, and request justification from the end user.

Endpoint DLP (via the endpoint agent) enforces at the device layer for USB, CD/DVD, clipboard, print, and application-to-application transfers; network DLP enforces at the SMTP/HTTP proxy. A rule scoped to 'endpoint' channels will not fire on email unless the email channel is also included.

Encryption and fingerprinting: Forcepoint supports file fingerprinting (exact-file and partial-document), database fingerprinting (columns/rows from a registered DB), and protected-document templates. Fingerprints must be refreshed when the source data changes; stale fingerprints silently miss new documents.

User identification matters: DLP decisions can key on directory user, group membership, and endpoint vs. network identity. When a user is unidentified (no directory match), rules scoped to specific users/groups evaluate as non-matching - verify identity resolution before blaming the classifier.

Discovery scans (network shares, endpoints, databases, cloud) run as scheduled tasks that apply the same classifiers to data at rest; results populate the data-at-rest inventory and can trigger remediation (quarantine, delete, notify owner).

DSPM focuses on data at rest and data-in-use posture: it discovers where sensitive data lives across cloud storage (S3, SharePoint/OneDrive, Google Drive, Box), SaaS apps, and on-prem repositories, then scores exposure risk.

Core DSPM objects: data source (connector to a repository), scan (scheduled or on-demand classification run), finding (a classified file/object with sensitivity label), and risk/issue (exposure condition such as public link, over-permissioned share, or unencrypted store).

DSPM classification reuses DLP-style classifiers but evaluates posture, not transfer events: a finding is 'this file contains PII and is publicly shared', not 'a user emailed PII'. This distinction is the most common exam trap between DLP and DSPM.

Connector onboarding requires least-privilege credentials (read-only API scopes) plus, for some sources, a service account with delegated access. Missing scopes produce partial scans - a scan that reports zero findings on a known-sensitive source usually means a permission gap, not clean data.

Risk prioritization combines sensitivity (classifier severity), exposure (public/anonymous access, external sharing, missing encryption), and blast radius (number of users/groups with access). Remediation options include revoke public link, remove external share, apply label, quarantine, and notify data owner.

DSPM dashboards report posture trends: sensitive-data volume by source, top exposed repositories, findings by risk level, and remediation status. Trend deltas require comparable scan scopes - changing connector scope invalidates period-over-period comparison.

Integration with DLP: DSPM findings can feed DLP policy tuning (e.g., identify repositories that need stricter transfer rules) and DSPM labels can be consumed as DLP conditions for enforcement at egress.

Data ownership and stewardship assignment: DSPM lets admins map findings to business owners so remediation is delegated. Unassigned findings remain open and inflate the risk score until an owner closes them.

Deployment modes: on-premises Web Security (Content Gateway + policy engine), hybrid (on-prem gateway with cloud policy), and Web Security Cloud (fully hosted proxy). The policy structure (policy → rule → action) is the same across modes; where enforcement happens differs.

URL filtering uses a cloud-hosted category database with 100+ categories plus custom URLs and custom categories. Precedence: explicit custom URL entries override category assignment; a site can be recategorized per-tenant via a recategorization request.

Rule matching order is top-down within a policy; the first matching rule's action applies unless the rule uses 'continue'. Common failure: a broad Allow rule above a specific Block rule silently permits traffic - order rules most-specific-first.

Actions include Permit, Block (with custom block page), Quota/Time-based allow, Confirm (user override with justification), and SSL inspection bypass. Bandwidth and time quotas are per-user and reset on the configured schedule.

HTTPS handling: the proxy can decrypt, inspect, and re-encrypt TLS using its own CA certificate, or bypass inspection for categories/certificate-pinned apps. Bypass lists must include apps that pin certificates (banking, some SaaS) or they break silently.

Authentication options: transparent (via directory integration / DC agent), explicit (proxy authentication prompt), and SAML/IdP-based for cloud mode. Policy rules keyed on user or group require successful identification; unidentified traffic falls to a default/guest rule.

Cloud Web Security (agent-based) extends filtering to off-network users via the endpoint agent or PAC file. Agent-based and proxy-based filtering use the same policy but different enforcement points - verify which path a user's traffic takes when debugging.

Reporting and logging: per-request logs record user, URL, category, action, and bytes; SIEM export is via syslog/CEF or API. Real-time dashboards aggregate by category and user, and log retention is bounded by the appliance/cloud tier.

CASB operating modes: API-based (out-of-band, connects to sanctioned SaaS via OAuth/API for visibility and retroactive policy), forward proxy (inline via Web Security for real-time control), and reverse proxy (inline for unmanaged devices, no agent). Mode determines whether control is real-time or after-the-fact.

Shadow IT discovery identifies unsanctioned cloud apps from web logs and categorizes them by risk (based on security attributes, compliance certifications, and vendor posture). Sanctioned vs. unsanctioned status drives which policy set applies.

Inline (proxy) policies act on uploads/downloads, sharing changes, and file operations in real time: block, coach the user with a justification prompt, allow with watermark, or quarantine. API policies act post-event: remove public share, revoke external access, notify owner.

Cloud app policy conditions include app, activity (upload, download, share, delete, login), file classification (via DLP classifiers), user/group, device type, and location. DLP classifiers are the bridge between CASB and DLP - a CASB rule can call a DLP classifier for content inspection.

Data residency and tenant control: CASB API connectors require the tenant admin to grant consent to the CASB app; revoking consent stops all API visibility immediately while inline control continues. This split is a frequent exam scenario.

Threat protection features (where licensed) flag anomalous behavior: impossible travel, mass download, unusual admin activity. These are behavioral detections, not content matches - they generate their own incident type separate from DLP incidents.

Coaching and user remediation: 'coach' actions present a justification dialog and can require a business reason before allowing the action; the justification is stored with the incident for audit. Coaching only works on inline paths - API mode cannot interrupt the user.

Reporting: CASB dashboards show app usage by category, sanctioned/unsanctioned split, top users by upload volume, and policy hits. API-mode latency means incidents appear after the sync interval, not instantly.