Run a Forcepoint war-room — one transaction, named Action

1. Why a war-room is not a dashboard tour

The weak close is “I opened Security Manager.” The strong close is one named field on a timestamp for the same user who called. Operators collapse three products into one shout. Web policy blocked an attachment. An NGFW Access rule Discarded 443 after a 02:00 install. DLP still Blocks on the Web channel because the action plan never changed — or Deploy never ran. Those are three first clicks and three different consoles.

This page is the command center for the bridge. The session factory taught the message path. The evidence desk maps first tool to proof field. Here you learn the war-room order: lock the sample, form a falsifiable hypothesis, open only the console that can prove it, then change one object — or hand off the package.

Hero · request, filter, policy stamp

2. Mental model — one transaction, three consoles

Concept first. Forcepoint is not one dashboard. A war-room ticket lands on Web (Filtering Service / cloud proxy), NGFW (SMC Logs), or DLP (incident list). Each console is allowed to prove one claim. Over-claiming a field is how you ship a bad Deploy at 02:10.

Path second. Write the sample, then pick the surface. Do third — Side A, B, C below — only after the diamond says so.

3. Decision flow — lock, then pick the surface

Flowchart first. Do not open Policy Management, an NGFW Access policy, or DLP Severity & Action until a diamond says so.

Path · client, steer, policy, event

War-room timeline (keep it separate from the hypothesis list)

Time-ordering stops two classic failures: treating a yesterday incident as tonight’s proof, and blaming the 02:00 install only because it is nearby.

Hypothesis ladder — allowed vs falsified

Write the hypothesis as a sentence you can kill. If it cannot be killed by one official field, it is not a hypothesis — it is a vibe.

4. How to choose — first console + live field

Print this next to the bridge. If you cannot recite the live field, you are not ready to change anything. The evidence desk is the field map. This table is the war-room pick.

5. Runbook Side A → B → C

Concept: three sides, one sample. Path: Web first (most tickets start as “a site is broken”), then NGFW if the Web grid is empty or the symptom is a port, then DLP if Slack said “data / payroll / USB.” Do: the steps below. On a messy Sev-2, walk them in order until a field lights up. Then stop opening consoles.

Side A — Transaction Viewer (Web request)

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 locked sample. 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, or go to Side B. 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). Official tabs: General lists user, policy, action, Web category, risk class. Request Details lists full URL, source and destination IP, referrer, request method. Advanced lists HTTP status, authentication method, user agent. 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. Empty User is data. It is not “Forcepoint is down.”

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. Official first step when traffic is incorrectly stopped: add a quick filter for both source and destination IP in the Query pane, then Apply. 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 click 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. Official troubleshoot article: if the connection is discarded or refused by a rule, click the Rule Tag link in the log entry to open that Access rule. Also quote Src Addr, Dst Addr, Service, Situation, and Auth. User when identity is on the rule.

3. If several Access rules match, the topmost applied rule wins

   Official: open Search Rules, drag the matching elements, Show Only Matching Rules, deselect Do Not Match ANY. The topmost matching Access rule is applied unless the Source VPN cell does not match. Then check Protocol Agent / Service, Connection Tracking, NAT (dynamic NAT is TCP/UDP only), and routing — packets drop when the engine has no route.

4. 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. Cloud Incident Manager Detail View tabs: Matches / Source & Destination / Properties.

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. The default after a dismissed Confirm is configured on Settings → General → Endpoint (Block or Permit) — quote that if the channel is Endpoint.

4. If the editor says Monitor but the incident still says Block, ask Deploy

   Official Deploy button: OK saves to the management server; Deploy activates across protectors, agents, gateways, and endpoint hosts. The button to the left of Deploy shows last-deployment status. A component that was down misses the push and receives pending updates when it returns. Quote incident time versus Deploy time. Do not argue with Finance from the rule tree.

LOCKED SAMPLE
  User / Src:    priya@lab.example  ·  203.0.113.41
  Destination:   (URL or Dst Addr + Service)
  UTC window:    01:50–02:20
  Expected:      (Allowed / Permit / upload succeeds)

WEB  path:  Reporting → Report Center → Transaction Viewer
WEB  quote: Action + Policy + Category + User / Source IP + URL
            (empty grid = forwarding — not a category Allow)

NGFW path:  SMC Logs → Records
NGFW quote: Action + Rule Tag + Event + Src Addr + Dst Addr
            (Discard / Refuse → click Rule Tag)

DLP  path:  Data → Main → Reporting → Data Loss Prevention
            (cloud: Reporting → Report Center → Incident Manager)
DLP  quote: ID + Policy + Action + Channel + Source + Severity
            Deploy time vs Incident Time

CHANGE: one object · owner · rollback · success field
CLOSE:  same sample, old failing field gone

6. Four war-room tickets

These four land on the same bridge. Times and identities below are lab-only. Memorise the first console and the live field — not the Slack title.

Proof · named field, then Closed

FPCC-01 — Lock the sample before anyone clicks

01:38 · P2. Slack is a pile of screenshots. L1 already drafted a tenant-wide category Allow. Network wants Save and Install. DLP wants Deploy. Nobody can name the user.

First move: write one sample on the bridge: priya@lab.example or 203.0.113.41, destination, 01:42 UTC, expected result. Then pick Side A, B, or C from the diamond. Do not open three consoles on three different people.

Proof field: the written sample. Until it exists you are not in RCA. A second laptop is a second ticket — it can confirm blast radius after the first sample has a field.

FPCC-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 console: Transaction Viewer. Filter User + Cloud App / URL + last hour. Enable Detail View. Official General tab lists policy and action; Request Details lists the full URL.

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. When risk class is Security, Threat Details appears — quote it if L1 called this “malware.”

FPCC-03 — Prove the NGFW connection (click Rule Tag)

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 console: SMC Logs → Records. Filter Src Addr for the branch and the destination you still think is allowed, 01:50–02:20 UTC. Official article: Troubleshoot traffic that is incorrectly stopped.

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

FPCC-04 — Prove the live DLP action (incident + Deploy)

03:00 · P2. Finance: “We changed the payroll rule to monitor. Uploads of customer records still block. Normal reports go through.” Someone typed Sev-1 and drafted a Web category Allow.

First console: Data → Main → Reporting → Data Loss Prevention → Incidents (last 3 days). Filter Source + Channel = Web. Cloud tenants: Incident Manager.

Proof field: incident ID + Policy + live Action + Channel + Severity + Incident Time. Then ask: did Deploy run after the editor change? Official: OK saves; Deploy activates. If live Action is still Block, the action plan on the matching rule is still Block — or another policy (EDM / IDM / dictionary) still matches with a Block plan. If live Action is Audit only, the product permitted the upload and logged it — that is not a Block. A category Allow will not change an action plan.

7. Traps + evidence package

Sources

• Forcepoint Help — Using the Transaction Viewer (Reporting → Report Center → Transaction Viewer; Detail View tabs; View Transactions from Report Builder)
• Forcepoint Help — Web attributes (Action, Policy, Category, User / Not available, Source IP, Authentication Method, Filtering Source)
• Forcepoint Help — Transaction Viewer display options (Detail View: General, Request Details, Cloud Apps, Threat Details)
• Forcepoint Help — Using the Transaction Viewer (on-prem Web) (Report Center → Transaction Viewer; filters and columns)
• 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; 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 NGFW Help — Troubleshoot traffic that is incorrectly stopped by the firewall (filter source and destination; click the Rule Tag link; topmost matching Access rule; Protocol Agent; NAT; routing)
• Forcepoint NGFW Help — Define Action options in Access rules (Allow, Continue, Discard, Refuse)
• Forcepoint DLP Help — Viewing the incident list (Data → Main → Reporting → Data Loss Prevention)
• Forcepoint DLP Help — Table Properties tab (ID, Policy, Action, Channel, Source, Severity; Event vs incident)
• Forcepoint DLP Help — Possible actions for an action plan (Permit, Block, Audit only, Quarantine, Confirm)
• Forcepoint DLP Help — Deploy button (OK saves; Deploy activates across protectors, agents, gateways, endpoint hosts)
• Forcepoint Help — Using the Incident Manager (Reporting → Report Center → Incident Manager; Matches / Source & Destination / Properties)

Related: Forcepoint evidence desk — first tool + proof field · Forcepoint session factory · Forcepoint DLP channels · Forcepoint DLP policies and rules · Forcepoint interview hub · All lessons