Prove Forcepoint is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The laptop never reached Content Gateway or the cloud proxy. Policy blocked the category. The NGFW Access rule Discarded the port. The directory user never authenticated, so User is blank. DLP Blocked a payroll upload on the Web channel. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught the message path. Here you learn the tools you actually open, in order, when someone asks you to prove Forcepoint is working — Web, NGFW, and DLP as the ticket requires.

Hero · five tiles, one ticket

2. Mental model — five proof surfaces

Memorise five named objects before you click. Each surface is allowed to prove one thing. Over-claiming a field is how you ship a bad change at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open Policy Management or an NGFW Access policy until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to Forcepoint Security Manager / the cloud portal / SMC. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the Web transaction and the identity on the wire. Side B proves the NGFW connection. Side C proves the DLP incident. On a messy Sev-2, do them in this order until a field lights up.

Side A — Transaction Viewer (Web)

1. Open Transaction Viewer, not the policy editor

   Path: Reporting → Report Center → Transaction Viewer. Official: Using the Transaction Viewer. Filter User or Source IP + the UTC window on the ticket. Add URL / Domain / Cloud App if you already know the destination. On-prem you can peek live on Reporting → Real-Time Monitor, but the close field still lives in the Log Database.

2. If the grid is empty, stop hunting Action

   Empty is the off-cloud sentence. Traffic never reached Content Gateway, Endpoint Web, GRE/IPsec, or the cloud connection. Quote “no Transaction Viewer row for this User / Source IP in this window.” Fix forwarding, then reload. Do not publish a category Allow from an empty report.

3. Read the columns that close a Web ticket

   Enable Detail View (or double-click the row). General lists user, policy, action, Web category, risk class. Request Details lists full URL, source and destination IP, referrer, request method. Cloud Action values: Allowed, Authentication Required, Blocked, Confirmed, Quota. Quote Action + Policy + Category.

4. Read User / Source IP before you invent a person

   Cloud Help: User can show Not available for transactions where authentication has been bypassed. Also quote Authentication Method (Basic, Downstream Authentication, Endpoint, Form-based login, NTLM, Single sign-on, or None) and Filtering Source (Cloud connection, Endpoint Web (Proxy), Endpoint Web (Direct), IPsec, GRE, EasyConnect, …). Source: Web attributes.

Side B — NGFW Logs (connection)

1. Open the SMC Logs view, not Web Report Center

   A discarded TCP port will not appear as a Web Category hit. Official: What the Logs view shows. Use the Records arrangement. Filter from the Query pane by Src Addr, engine, Service, and time. If NAT sits between your Management Client and the Log Server, select the correct Location or you will see no rows.

2. Read Action, then Rule Tag, then Event

   Exportable Firewall fields (official): Action = Allow, Discard, Refuse, Terminate, Wait for further actions, Wait for authentication. Rule Tag = rule tag of the rule that triggered the log event (RULE_ID). Event = New connection, Connection closed, Connection discarded. Also quote Src Addr, Dst Addr, Service, Situation, and Auth. User when identity is on the rule.

3. Do not treat Bytes Sent as an allow

   Bytes Sent / Bytes Rcvd are counted when accounting entries are created — often at close. A Sample of bytes is not Action = Allow on the ticket that just died. Quote the connection Event that flipped.

Side C — DLP incident (data hit)

1. Open the incident list, not Transaction Viewer Category

   On-prem: Forcepoint Security Manager → Data → Main → Reporting → Data Loss Prevention → Recent Reports → Incidents (last 3 days) or Incidents (last 7 days). Official: Viewing the incident list. Cloud Web: Reporting → Report Center → Incident Manager. A Web Category of Webmail is not a DLP Channel.

2. Quote ID, Policy, Action, Channel, Source

   Table properties (official): ID (incident, a policy violation), Event ID (any transaction the engine saw), Policy, Action (from the action plan), Channel (Email, Web, FTP, Endpoint application, Endpoint printing, Network printing), Source, Destination, Severity (High / Medium / Low), Status, Incident Time. Select the row — the preview pane shows the rest.

3. Read the action plan, not the Slack verb

   Possible actions (official): Permit, Block, Audit only, Quarantine, Confirm, Encrypt, Drop attachments, and channel-specific variants. Audit only permits the activity and logs an incident. If Slack said “DLP blocked us” and Action is Audit only, the product did not block. Confirm is a user prompt, not a silent Block.

UTC window:      01:50–02:20
Web path:        Reporting → Report Center → Transaction Viewer
Web quote:       Action + Policy + Category + User / Source IP + URL
NGFW path:       SMC Logs → Records
NGFW quote:      Action + Rule Tag + Event + Src Addr + Dst Addr
DLP path:        Data → Main → Reporting → Data Loss Prevention
                 (cloud: Reporting → Report Center → Incident Manager)
DLP quote:       ID + Policy + Action + Channel + Source + Severity
If Web empty:    forwarding — not a category Allow

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

Proof · named field, then Closed

FEVD-01 — Prove the Web row (Transaction Viewer)

01:42 · P2. Priya on a hotel network. Endpoint icon looks green-ish on a phone photo. L1 already drafted a new category Allow.

First tool: Reporting → Report Center → Transaction Viewer. Filter User = priya@lab.example or Source IP = her current address, last 15 minutes.

If empty: quote “no Transaction Viewer row for this User / Source IP in this window.” She is not going through Filtering Service or the cloud proxy. Next check is forwarding — PAC returning DIRECT, Endpoint Web down, missing GRE/IPsec, or a bypassed location — not Policy Management.

If a row exists: you are allowed to read Action + Policy. Cloud: also quote Filtering Source so you know whether Endpoint Web, GRE, or a Cloud connection carried her. The row is not a DLP incident.

FEVD-02 — Prove the SaaS transaction (Action + Policy)

02:05 · P2. Outlook on the Web opens. Attachments fail after last night’s policy ship. Someone wants “another Allow for outlook.office.com.”

First tool: Transaction Viewer. Filter User + Cloud App / URL + last hour. Enable Detail View.

Proof field: page host Action = Allowed; attachment host Action = Blocked and Policy = the policy you shipped (plus Category). That name is the ticket. Change that one policy — or the classifier that fed it — then re-read the same two columns. General tab also lists risk class; when it is Security, Threat Details appears.

FEVD-03 — Prove the NGFW connection (Logs)

02:20 · P1. Pune branch: every desk lost internet after a 02:00 firewall change. Transaction Viewer for that Source IP range is empty. L1 wants a Web policy republish.

First tool: SMC Logs → Records. Filter Src Addr for the branch + 01:50–02:20 UTC. Look at Event = Connection discarded, not just bytes.

Proof field: Action = Discard (or Refuse), Rule Tag of the Access rule that flipped, Dst Addr of the VIP or service you think you still allow. Simultaneous 02:00 death is almost never “everyone’s Web cookie expired together.” Empty Web is the clue the packet never reached Filtering Service.

FEVD-04 — Prove identity (User / Source IP)

02:40 · P2. Same laptop as FEVD-01, now on-cloud. Transaction Viewer shows User = Not available. L1 wants to rebuild the directory connector.

First tool: the same Transaction Viewer row. Add columns User, Source IP, Authentication Method, Filtering Source. Official cloud attribute: User can be Not available when authentication has been bypassed.

Proof field: Authentication Method = None (or a method you did not expect) + Source IP + Policy that actually applied (often the default / unauthenticated policy). That is why the category action looks “wrong.” Rebuild directory only after you prove the request never presented NTLM, SSO, or Endpoint credentials.

FEVD-05 — Prove the DLP incident

03:00 · P2. Finance: “DLP blocked the payroll upload to the vendor portal.” Someone typed Sev-1 and drafted a Web category Allow.

First tool: Data → Main → Reporting → Data Loss Prevention → Incidents (last 3 days). Filter Source + Channel = Web. Cloud tenants: Incident Manager, Detail View tabs Matches / Source & Destination / Properties.

Proof field: incident ID + Policy + Action + Channel + Severity. If Action is Audit only, the product permitted the upload and logged it — that is not a Block. If Action is Confirm, the user dismissed the prompt. A category Allow will not change an action plan.

7. Traps + close-the-ticket proof

Sources

• Forcepoint Help — Using the Transaction Viewer (Reporting → Report Center → Transaction Viewer; Detail View tabs)
• Forcepoint Help — Web attributes (Action, Policy, Category, User / Not available, Source IP, Authentication Method, Filtering Source)
• Forcepoint Help — What are attributes? (Web Security on-prem) (Report Center / Transaction Viewer attribute family; Result, Full URL)
• Forcepoint Help — Transaction Viewer display options (Detail View: General, Request Details, Cloud Apps, Threat Details)
• Forcepoint Help — Test Filtering (Toolbox; URL filtering only; category, action, reason)
• Forcepoint Help — Real-Time Monitor in multiple Policy Server deployments (Web module → Reporting → Real-Time Monitor)
• Forcepoint NGFW Help — What the Logs view shows (Records / Statistics / Details / Log Analysis; Location when NAT is in front of the Log Server)
• Forcepoint NGFW Help — Exportable Firewall and Layer 2 Firewall log entry fields (Action, Rule Tag, Event, Src Addr, Dst Addr, Auth. User)
• Forcepoint DLP Help — Viewing the incident list (Data → Main → Reporting → Data Loss Prevention)
• Forcepoint DLP Help — Viewing Incidents and Reports
• Forcepoint DLP Help — Table Properties tab (ID, Policy, Action, Channel, Source, Severity, Event vs incident)
• Forcepoint DLP Help — Properties (incident number, Severity, Status, Action, Channel)
• Forcepoint DLP Help — Possible actions for an action plan (Permit, Block, Audit only, Quarantine, Confirm)
• Forcepoint Help — Using the Incident Manager (Reporting → Report Center → Incident Manager; Matches / Source & Destination / Properties)

Related: Blog 1 · Forcepoint session factory · Forcepoint DLP channels · Forcepoint DLP Endpoint · Forcepoint DLP fingerprinting · All lessons