Palo Alto Logging, Log Forwarding & Reporting: Why "We Have No Logs of the Breach" Happens

Most engineers think…

Most engineers assume a Palo Alto firewall "logs everything automatically" — it's a security box, surely every session and threat is recorded and kept. So they never check the logging config until an incident forces them to.

Wrong — and it's the most expensive wrong assumption in firewall operations. PAN-OS logging is opt-in per rule. A security rule only writes Traffic logs if its Actions tab has logging enabled, and those logs only leave the box if a Log Forwarding Profile is attached. With no profile, logs sit in a quota-capped local database that overwrites the oldest entries — so on a busy box you might have only a few days of history, and a SIEM that has never seen a single traffic log. "The firewall logs everything" is the sentence that ends with "…we have no logs of the breach."

① The log types — what PAN-OS records, and on which plane

Meet Sneha, an L1 SOC analyst at Infosys. On day one her mentor tells her: "On a Palo Alto, before you trust a single dashboard, know which log you're looking at and where it came from." That's the right instinct. PAN-OS doesn't have one giant log — it has a family of them, each generated by a different part of the box. Get the family tree clear and the rest of logging falls into place.

The dataplane — the part that actually inspects and forwards your traffic — produces the security logs you'll live in: Traffic (one entry per session: who talked to whom, which app, how many bytes), Threat (anything an Antivirus, Anti-Spyware or Vulnerability profile catches), URL Filtering (web categories visited/blocked), WildFire Submission (files sent to the sandbox and their verdicts), Data Filtering (credit-card/SSN/file-blocking hits), Authentication (Auth Policy and Captive Portal events), Decryption (SSL/TLS decrypt successes and failures), Tunnel Inspection (GRE/IPsec tunnel content), and GlobalProtect (VPN logins and gateway events).

The control plane — the management brain — produces two logs you must not forget: System (the box itself: HA failovers, link state, daemon crashes, certificate expiry) and Config (every admin change: who edited which rule and when). These two matter enormously for audits and for answering "who broke production at 2 a.m.?" — and, as you'll see, they leave the box through a different door than the dataplane logs.

👉 So far: dataplane logs (Traffic, Threat, URL, WildFire, Data, Auth, Decryption, Tunnel, GlobalProtect) and control-plane logs (System, Config). Next: where they all land and why that database has a ceiling.

Every one of those logs is first written to an on-box log database on the firewall's SSD. That database is carved into a quota per type — so much percent for traffic, so much for threat, and so on. When a type's slice fills, PAN-OS doesn't stop logging and it doesn't stop passing traffic; it simply overwrites the oldest entries of that type to make room. On a busy box logging every session, the traffic slice can roll over in days. That single fact is why so many breach investigations hit a wall.

Figure 1 — The PAN-OS logging pipeline at a glance

Trace it left to right: logs are born on the dataplane/control plane, land in the quota-capped local DB, and only leave the box through a forwarding door. The red box is the blind spot — a rule with no forwarding profile keeps its logs local until the quota erases them.

The four log types you'll touch most — one tap each

Tap each card. These four are where an L1/L2 engineer spends 90% of their log-reading time.

🚦

Traffic log

tap to flip

One entry per session: src, dst, app, user, bytes, end-reason. So: your single richest source for 'what actually flowed'.

🛡️

Threat log

tap to flip

Fires when an AV/Anti-Spyware/Vuln profile matches. So: this is your IDS/IPS feed — no Threat log means no security profile fired.

🌐

URL log

tap to flip

Web category per request, allowed or blocked. So: proves where users browsed and what URL Filtering caught.

🧪

WildFire log

tap to flip

Files uploaded to the sandbox + their malicious/benign verdict. So: your zero-day evidence trail.

Daily-life analogy — the society guard's two registers

Think of your apartment society. The guard at the gate keeps a visitor register — every person and vehicle in and out (that's your Traffic log), plus a flagged page for anyone suspicious (your Threat log). Meanwhile the society office keeps a separate book of who changed the rules — new gate timings, new staff (that's your Config log). Two different people, two different registers, two different cupboards. On a Palo Alto it's the same: gate logs (dataplane) and office logs (control plane) are forwarded through two different menus.

Quick check · Q1 of 10

Rahul at TCS opens the Threat log after a phishing scare and finds it completely empty for the affected user's traffic — even though that user definitely downloaded a malicious file. Most likely explanation?

a) No security profile (AV/Anti-Spyware/Vulnerability) was attached to the rule that allowed the traffic, so nothing fired to write a Threat logb) The Threat log only stores blocked sessions, never downloadsc) Threat logs are stored on the control plane, which was rebootingd) WildFire deletes Threat logs after a verdict

Correct: a. A Threat log entry is only created when a Security Profile (Antivirus, Anti-Spyware or Vulnerability Protection) actually matches something. If the allow rule had no profiles attached, the malware passed un-inspected and no Threat log exists — the classic 'we allowed the app, but skipped the profiles' gap. The Threat log isn't limited to blocks, isn't on the control plane, and WildFire doesn't purge it.

Pause & Predict

Predict: a brand-new firewall is passing traffic fine, but your SIEM shows ZERO traffic logs from it after a full day. Before touching the SIEM, name the FIRST two firewall-side things you'd check. Type your guess.

Answer: First: are the security rules even logging? Open a rule's Actions tab and confirm 'Log at Session End' is ticked — a rule with logging off writes nothing to begin with. Second: is a Log Forwarding Profile attached to those rules? Logging locally and forwarding off-box are two separate switches; a rule can log to the local DB yet forward nothing. Only after both are confirmed do you go look at the Server Profile and the SIEM's egress path.

② Log Forwarding Profiles — the switch that decides if anyone ever sees your logs

Here is the single most important idea in this lesson, the one that separates engineers who get burned from those who don't: writing a log locally and forwarding it off-box are two completely separate actions. A security rule can happily log every session to the on-box database and forward nothing — because forwarding is controlled by a Log Forwarding Profile, and if you don't attach one, the logs stay home.

You build the profile under Objects > Log Forwarding. Click Add, give it a Name (tip: name it default and PAN-OS auto-attaches it to every new rule and zone — a great way to stop the blind spot at the source). Inside, you add a Match List: each row picks a Log Type (traffic, threat, url, wildfire, data, auth, tunnel, decryption, gtp, sctp), an optional Filter (so you can, say, only forward (action eq deny) traffic), and the destinations — Panorama/Cloud Logging, SNMP, Email, Syslog or HTTP server profiles.

Then comes the step everyone forgets: attach it. Open Policies > Security, edit each rule, go to the Actions tab, and set Log Forwarding to your profile. Same tab also has Log at Session Start and Log at Session End — leave Session End ticked. No attachment, no forwarding. A profile sitting in Objects > Log Forwarding that isn't bound to a single rule does exactly nothing.

🖥️ This is the screen you'll use — Objects > Log Forwarding > Add, then add a Match List row. (Recreated for clarity — your console matches this.)

PA-VM · Objects · Log Forwarding · Log Forwarding Profile

Name

LFP-Standard-SIEM

Match List · Name

fwd-threat-traffic

Log Type

threat

Filter

All Logs

Panorama

(unchecked)

Syslog

SP-Syslog-SIEM (TCP 514, CEF)

Figure 2 — Two logging choices that decide whether you have evidence later

Compare the columns: left is the lossy setup (Session Start only / no forwarding profile / rely on quota) that leaves you blind in an incident; right is the safe standard (Session End + a forwarding profile + off-box retention). Same firewall, opposite outcomes six weeks later.

Now the second screen — actually binding the profile so it does something. This is where the rubber meets the road, and where the missing step lives.

🖥️ The step everyone skips — Policies > Security > (your rule) > Actions. Set Log Forwarding to your profile and confirm Log at Session End. (Recreated for clarity.)

PA-VM · Policies · Security · Allow-Users-to-Internet · Actions

Action

Allow

Log at Session Start

(unchecked)

Log at Session End

✓ checked

Log Forwarding

LFP-Standard-SIEM

Profile Setting

Profile Group: PG-Strict

Common mistake — "the SIEM gets System and Config logs but no Traffic or Threat logs"

Symptom: your SOC says the Palo Alto shows up in the SIEM, but only with System and Config events — never a single Traffic or Threat log. Cause: the Server Profile is fine, but the dataplane logs need a Log Forwarding Profile attached to the security rules, while System/Config logs go out a separate door (Device > Log Settings) that you happened to configure. Fix: build a Log Forwarding Profile, add Match List rows for traffic and threat pointing at your Syslog Server Profile, and attach it to every allow and deny rule (or name it default). Re-check the SIEM — traffic and threat logs now arrive.

▶ Watch one Threat log try to reach the SOC

An Anti-Spyware profile catches command-and-control traffic from a workstation. Follow the resulting Threat log from the dataplane to the analyst's screen. Press Play for the healthy path, then Break it to see the failure.

① Profile firesAnti-Spyware matches C2 to 203.0.113.66; dataplane writes a Threat log locally

▼

② Profile lookuprule's Log Forwarding Profile has a Match List row: type=threat → Syslog SP

▼

③ Syslog outSyslog Server Profile sends it TCP 514, CEF from the mgmt interface to 10.50.0.20

▼

④ SOC sees itSIEM parses CEF, indexes it; analyst Sneha opens a case and blocks the C2 IP

Press Play to step through the healthy path. Then press Break it.

CLI — is the box actually logging and forwarding? (run on the firewall)

admin@PA-VM> show logging-status

Expected output

Type            Last Log Created           Last Log Fwded         Total Logs Fwded
Traffic         2026/06/11 14:22:07        2026/06/11 14:22:08    1842331
Threat          2026/06/11 14:21:55        2026/06/11 14:21:56    20457
System          2026/06/11 14:20:10        2026/06/11 14:20:11    9123
Config          2026/06/11 13:58:44        2026/06/11 13:58:45    412

Log forwarding agent          Connected
Syslog (SP-Syslog-SIEM)       up   10.50.0.20:514/TCP

Quick check · Q2 of 10

Priya at HCL has a flawless Syslog Server Profile and confirms System and Config logs reach the SIEM. But no Traffic or Threat logs ever arrive. What's the fix?

a) Switch the Syslog transport from UDP to TCPb) Attach a Log Forwarding Profile (with traffic/threat Match List rows) to the security rulesc) Increase the traffic log quota under Device > Setup > Managementd) Re-commit the Server Profile to refresh it

Correct: b. System and Config logs forward via Device > Log Settings (which she set up), so they arrive — but Traffic and Threat are dataplane logs that need a Log Forwarding Profile attached to the security rules. Changing transport, raising the quota, or re-committing the Server Profile do nothing for logs that are never being forwarded in the first place.

Pause & Predict

Predict: why does naming a Log Forwarding Profile exactly 'default' reduce the chance of a future blind spot? Type your guess.

Answer: Because PAN-OS automatically pre-selects a profile (and zone-protection profile, and security-profile-group) literally named 'default' for every NEW security rule and zone you create. So the next engineer who adds a rule and forgets to set Log Forwarding still inherits the default profile — the logs forward anyway. It's a guardrail: you make the safe choice the automatic one, instead of relying on everyone remembering the Actions tab.

③ Server Profiles & SIEM — getting logs out in CSV, CEF or LEEF

A Log Forwarding Profile decides which logs leave and that they leave; a Server Profile decides where they go and in what format. PAN-OS has four to know: Syslog (the workhorse for SIEMs), SNMP (traps for NMS tools), Email (alert a person on critical threats), and HTTP (POST logs as JSON to a webhook or SOAR). You build them all under Device > Server Profiles.

The Syslog one is what you'll set up most. Under Device > Server Profiles > Syslog > Add, you give the profile a Name, then add a server row: the Syslog Server (IP/FQDN, e.g. 10.50.0.20), the Transport (UDP, TCP or SSL), the Port (default 514), the Format (BSD/IETF), and the Facility (default LOG_USER). Most SIEMs want reliable delivery and structured fields, so the common production combo is TCP transport + a structured format.

On format: PAN-OS sends logs as CSV by default, but your SIEM team will almost always ask for CEF or LEEF so fields map cleanly. To switch, open the Syslog Server Profile's Custom Log Format tab, click the log type (Traffic, Threat, URL…), and paste the CEF or LEEF template. CEF is the QRadar/ArcSight/Splunk-friendly default; LEEF is QRadar-native.

👉 So far: four server-profile types, the Syslog fields, and CSV vs CEF vs LEEF. Next: the other door (Device > Log Settings) and forwarding to Panorama.

Now the second door. Remember System and Config logs are born on the control plane — they are not covered by a Log Forwarding Profile. To ship them, go to Device > Log Settings and, for the System, Config, User-ID, HIP Match and Correlation log types, pick your Syslog (or SNMP/Email/HTTP) Server Profile there. Forget this step and you'll forward every traffic log but miss the audit trail of who changed the firewall — a gap auditors love to find.

At scale you rarely point firewalls straight at a SIEM. Instead they forward to Panorama, whose Log Collectors aggregate logs from dozens of firewalls, give you one place to search, and re-forward to the SIEM. We cover that architecture in the Panorama lesson — for now, know that 'forward to Panorama' is just another destination option in the same Match List.

Figure 3 — One Threat log's journey to the SIEM — and where it dies

Five steps: profile fires → forwarding profile routes it → Syslog sends it (TCP 514, CEF) → SIEM ingests → analyst acts. The two red boxes are the death points: no forwarding profile (A) and blocked egress (B). The green box is how you prove each hop.

Karthik at ICICI faces this

Karthik, an L2 engineer, gets a ticket: the SOC's Splunk shows the ICICI perimeter firewall is 'silent' — no Palo Alto logs for the last 3 hours, though the firewall is up and passing traffic normally.

Likely cause

The Syslog Server Profile uses UDP, and a network change put a stateful device between the firewall's management interface and the SIEM that silently drops the UDP syslog. With UDP there's no delivery guarantee, so logs are sent into a black hole with no error on the firewall.

Diagnosis

Karthik separates 'is it logging?' from 'is it forwarding/arriving?'. The local logs in Monitor > Logs are fine (so logging works), but show logging-status shows the forwarded counter for Syslog flatlined and the connection not 'up'.

Monitor > Logs > Traffic (confirm local logs exist) + CLI: show logging-status (check Syslog forwarded counter + connection state)

Fix

Switch the Syslog Server Profile transport from UDP to TCP (or SSL) so delivery is connection-oriented and failures are visible, and have the network team permit TCP 514 from the firewall's mgmt IP to the SIEM. Commit.

Verify

Re-run show logging-status → Syslog connection shows up and Total Logs Fwded climbs again; Splunk starts indexing Palo Alto traffic/threat events within seconds.

Quick check · Q3 of 10

Aditya at Wipro must forward firewall logs to a QRadar SIEM that needs structured, easily-parsed fields — not raw CSV. Where in PAN-OS does he switch the syslog output to CEF or LEEF?

a) Objects > Log Forwarding > Match List > Filterb) Device > Setup > Management > Logging and Reporting Settingsc) The Custom Log Format tab of the Syslog Server Profile (Device > Server Profiles > Syslog)d) Policies > Security > Actions > Log Forwarding

Correct: c. Format is a property of the destination, so it lives in the Syslog Server Profile's Custom Log Format tab, where you paste the CEF or LEEF template per log type. The Match List filter only narrows which logs forward; Logging and Reporting Settings handle quotas; and the rule's Actions tab only selects the forwarding profile, not its format.

Pause & Predict

Predict: you forward Traffic and Threat logs perfectly to the SIEM, but during an audit you can't show WHO changed a firewall rule last month. Which log did you forget, and through which menu does it leave? Type your guess.

Answer: The Config log. It's a control-plane log, so it is NOT covered by your Log Forwarding Profile (which only handles dataplane logs like traffic/threat). Config (and System) logs leave through a separate door: Device > Log Settings, where you assign a Server Profile to each control-plane log type. Configure that, and every admin change — who edited which rule and when — flows to the SIEM for your audit trail.

④ Quotas, retention & reports — keeping evidence and turning logs into answers

You now ship logs off-box, which is exactly why the on-box quota stops being scary — the SIEM and Panorama hold the long-term copy. But you still tune the local database, because Monitor > Logs reads from it during live troubleshooting. Go to Device > Setup > Management, edit Logging and Reporting Settings, and on the Log Storage tab set a Quota (%) per log type and an optional Max Days (1–2000; blank = never expire by age). When a type's quota fills, PAN-OS deletes the oldest entries of that type first — checked each time a log file rotates.

This is where teams get burned. If you log every session and keep everything local, a busy box might hold only a few days of traffic logs. Bump the traffic quota and you starve threat or url logs, because the slices share one disk. The real fix isn't fighting over percentages — it's forwarding off-box (which you just learned) so retention lives where disk is cheap. On the firewall, size the quotas for how far back you realistically troubleshoot live; let Panorama/SIEM own the months.

On the Log Storage tab you'll see a row per log type — for example Traffic Quota (%) 38 with Max Days 30, Threat Quota (%) 12, URL Quota (%) 8, and a generous Config Max Days 365 so your audit trail survives even though its volume is tiny. The percentages must total 100% across all types, so growing one genuinely shrinks another — a hard trade you can't escape on the box alone.

Now turn logs into answers. PAN-OS ships 40+ predefined reports generated nightly — top applications, top URL categories, top threats, denied sessions — under Monitor > Reports. Need something specific? Monitor > Manage Custom Reports > Add lets you build one: pick a Database (a fast Summary database for trends, or Detailed Logs for precision), choose columns, set a filter, then enable the schedule so it runs daily and can be emailed. PDF Summary Reports bundle up to 18 charts into one document for management.

👉 So far: quotas + retention, predefined and scheduled custom reports. Next: App Scope, the filter syntax, and a recent reason logging matters more than ever.

App Scope (Monitor > App Scope) is the visual layer on top of the same data — Summary, Change Monitor, Threat Map, Network Monitor and Traffic Map views that turn weeks of logs into a glanceable picture of what changed. And the skill that ties it all together is the filter syntax, identical in Monitor > Logs and in report filters: expressions like (addr.src in 10.20.5.0/24), (addr.dst in 203.0.113.66), (action eq deny), (app eq dns), joined with and / or. Learn five operators and you can pull any session out of millions in seconds.

CLI — read and filter logs from the command line (no WebUI needed)

admin@PA-VM> show log traffic direction equal backward query equal "( addr.dst in 203.0.113.66 ) and ( action eq allow )"

Expected output

Time                 App      Src             Dst             Rule              Action  Bytes
2026/06/11 14:02:11  web-browsing 10.20.5.41   203.0.113.66    Allow-Users-Internet allow   18244
2026/06/11 13:51:08  ssl      10.20.5.41      203.0.113.66    Allow-Users-Internet allow   9322
2026/06/11 13:40:55  dns      10.20.5.10      203.0.113.66    Allow-Users-Internet allow   412

(showing 3 of 3 matched — if this returns nothing during an incident, your logs rolled over: forward off-box)

One sober, current reason all of this matters more than it used to. In February 2025 Palo Alto disclosed CVE-2025-0108, an authentication-bypass on the PAN-OS management web interface (chained with a file-read bug, CVE-2025-0111) that was actively exploited in the wild. When attackers target the firewall itself, your System and Config logs — forwarded off-box to a SIEM the attacker can't reach — may be the only untampered record of what they did. A firewall that logs only to its own disk is a firewall whose evidence an intruder can erase. Forwarding isn't just for the SOC dashboard; it's tamper-evidence.

Figure 4 — Logging & Reporting — the cheat-sheet

Your one-card map of this whole lesson — the 11 log types, the two forwarding doors, server profiles, syslog formats and ports, quota behaviour, reports, session start vs end, the filter syntax, and the first CLI you'll type. Keep it open in your first week and before any PCNSE/PCNSA logging question.

Prove your logging is incident-ready (30-second self-check)

Cold, before any audit: (1) Every allow and deny rule has a Log Forwarding Profile and 'Log at Session End' — open Policies > Security and scan the Log Forwarding column for blanks. (2) System and Config logs are assigned a Server Profile under Device > Log Settings. (3) show logging-status shows the Syslog connection up and the forwarded counters climbing. (4) The SIEM actually shows a recent Traffic and Threat event from this box. If all four are true, you'll never say 'we have no logs.'

Where logging is enabled: Security Policy fundamentals What writes WildFire logs: WildFire sandbox

Quick check · Q4 of 10

An interviewer asks Meera: "Your firewall logs only to its local disk. An attacker compromises the management interface via an auth-bypass CVE. Why is forwarding logs off-box the single most valuable control here?"

a) Off-box forwarding makes the firewall pass traffic fasterb) It increases the local log quota automaticallyc) CEF format blocks the exploitd) Logs forwarded to a SIEM the attacker can't reach are tamper-evident — local-only logs can be erased by whoever owns the box

Correct: d. Once an attacker owns the management plane, on-box logs are theirs to delete or doctor. Logs already forwarded to an out-of-reach SIEM are an independent, tamper-evident record of the intrusion — often the only trustworthy evidence. Forwarding doesn't change traffic speed or quotas, and a log format can't block an exploit.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Palo Alto docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

Type one line: In one line: why can a Palo Alto firewall be passing traffic perfectly yet send your SIEM zero traffic logs? Then compare to the expert version.

Expert version: Because logging is opt-in per rule: a security rule writes Traffic logs only if logging is enabled on its Actions tab, and those logs leave the box only if a Log Forwarding Profile is attached — with no profile, the logs sit in the quota-capped local database and the SIEM never sees them.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Logging & Reporting at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Traffic log: One entry per session — src, dst, app, user, bytes, end-reason. Your richest record of what flowed.
Threat log: Written only when an Antivirus/Anti-Spyware/Vulnerability profile matches; your IPS/IDS feed.
Log Forwarding Profile: Objects > Log Forwarding object that maps log types to destinations. Must be ATTACHED to a rule to do anything.
Match List: The table inside a Log Forwarding Profile — each row: a log type, an optional filter, and its destinations.
Server Profile: A reusable destination (Syslog/SNMP/Email/HTTP) under Device > Server Profiles — the address, port, transport and format.
Device > Log Settings: The separate menu that forwards control-plane logs (System, Config, User-ID, HIP Match, Correlation).
CEF / LEEF: Structured syslog formats (ArcSight CEF, QRadar LEEF) set in the Custom Log Format tab for easy SIEM parsing.
Log storage quota: Per-type % slice of the firewall's log disk (Device > Setup > Management). Full → oldest entries overwritten.
Max Days: Optional age-out per log type (1–2000 days); blank = never expire by age. Set under Logging and Reporting Settings.
Session Start vs End: Session End logs full byte/packet/end-reason data (default); Session Start logs early but without final counts.
Custom Report: Monitor > Manage Custom Reports — your own report over a Summary or Detailed-Logs database, schedulable and emailable.
App Scope: Monitor > App Scope — visual Summary/Change/Threat-Map/Traffic-Map views built from the same log data.

📚 Sources

PAN-OS Administrator's Guide — "Configure Log Forwarding" + "Configure a Log Forwarding Profile" (Objects > Log Forwarding; Match List per log type with filter + Panorama/SNMP/Email/Syslog/HTTP destinations; attach via Policies > Security > Actions). docs.paloaltonetworks.com/network-security/security-policy/administration/objects/log-forwarding/configure-a-log-forwarding-profile-pm
PAN-OS Web Interface Help — "Device > Server Profiles > Syslog" (Name, Syslog Server, Transport UDP/TCP/SSL, Port default 514, Format BSD/IETF, Facility LOG_USER, Custom Log Format tab for CEF/LEEF). + "Configure Syslog Monitoring" (System/Config/User-ID via Device > Log Settings; CSV/CEF/LEEF parser support). docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring
PAN-OS Administrator's Guide — "Configure Log Storage Quotas and Expiration Periods" (Device > Setup > Management > Logging and Reporting Settings > Log Storage: Quota % per type, Max Days 1–2000, blank = never expire, oldest overwritten when full, synced across HA). docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/monitoring/view-and-manage-logs/configure-log-storage-quotas-and-expiration-periods
Palo Alto LIVEcommunity — "Log Retention" + "Log file quota when reaches 100%" (busy boxes hold only days of logs; quota checked at log-file rotation; oldest purged from ~80%; Max Days for time-based age-out). live.paloaltonetworks.com/t5/community-blogs/log-retention/ba-p/306150 · live.paloaltonetworks.com/t5/general-topics/log-file-quota-when-is-reach-100/td-p/25048
Splunk Community — "PaloAlto Threat and Traffic logs not passed to Splunk but System and Config are" (real-world: forwarding profile configured but NOT attached to the security policy → only system/config arrive). community.splunk.com/t5/Getting-Data-In/PaloAlto-Threat-and-Traffic-logs-not-being-passed-to-splunk-but/td-p/671434
Palo Alto Security Advisory PAN-SA / NVD — CVE-2025-0108 (PAN-OS management web-interface authentication bypass, CVSS 8.8, actively exploited Feb 2025, chained with CVE-2025-0111 file read) — why off-box, tamper-evident System/Config log forwarding matters. nvd.nist.gov/vuln/detail/cve-2025-0108 · security.paloaltonetworks.com
Palo Alto PCNSE / PCNSA exam blueprints + LIVEcommunity "How to Create Custom Reports in PAN-OS" (Monitoring & Logging domain: Log Forwarding Profiles, Server Profiles, Panorama log collectors, predefined/custom/PDF Summary reports, App Scope). live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-create-custom-reports-in-pan-os/ba-p/514269 · paloaltonetworks.com/services/education/certification

What's next?

You can now make sure every session is logged and every log reaches the SIEM. Next we zoom out to the physical and virtual shapes the firewall itself takes — hardware appliances, VM-Series, CN-Series and Cloud NGFW — and when to choose each.

Next · Form Factors → Practice on exam.techclick.in →

Palo Alto Logging, Log Forwarding & Reporting: — Why "We Have No Logs of the Breach" Happens

🎯 By the end you will be able to

Pick where you want to start

The log types

Forwarding profiles

Server profiles & SIEM

Quotas & reports

① The log types — what PAN-OS records, and on which plane

The four log types you'll touch most — one tap each

② Log Forwarding Profiles — the switch that decides if anyone ever sees your logs

▶ Watch one Threat log try to reach the SOC

③ Server Profiles & SIEM — getting logs out in CSV, CEF or LEEF

④ Quotas, retention & reports — keeping evidence and turning logs into answers

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?